ВВЕДЕНИЕ

Государственное реформирование здравоохранения поставило перед лечебными учреждениями принципиально новые задачи. Скорость и качество получения и обработки информации стали важнейшим условием повышения уровня оказываемой медицинской помощи. Эту задачу нельзя решить без внедрения новых информационных технологий.
В последние годы в России появился целый ряд уникальных разработок в области комплексных медицинских информационных систем (МИС), предназначенных для автоматизации работы учреждений здравоохранения. Одними из самых интересных являются: информационная система «Интерин» (Институт программных систем РАН), МИС «Артемида», МИС «Амулет» и некоторые другие. Эти системы не только разработаны, но и активно развиваются - распространение и признание в практическом внедрении они получили в последние 2-3 года. Наметилась тенденция на комплексное решение разносторонних задач лечебного учреждения, что особенно радует и свидетельствует о качественном росте отечественных разработчиков в области медицинской информатики.
Однако при более глубоком изучении этого процесса все сильнее выделяется существенная проблема: несмотря на наличие глубоко проработанных программных решений, прак-тически отсутствует опыт полного перехода на электронный принцип хранения и обработки информации в лечебном учреждении. Имеется ряд серьезных преград, через которые не могут перешагнуть даже современно оснащенные клиники в своем стремлении отказаться от бумажных носителей информации и повысить эффективность в организации своей работы. Все они могут быть объединены в несколько групп.
Во-первых, существующая в России правовая база не обеспечивает должного уровня юридической защиты медицинских работников, применяющих информационные технологии в повседневной практике.
Во-вторых, финансовые ресурсы большинства учреждений здравоохранения пока не могут позволить им приобрести достаточное количество компьютерной техники и дорогостоящего программного обеспечения для комплексной автоматизации. Поэтому этот процесс успешно протекает лишь в некоторых, зачастую далеких от медицинской направленности, разделах работы ЛПУ: статистика, бухгалтерия, автоматизация работы административного звена и т.д.
В третьих, в России практически отсутствует школа, которая бы готовила профессионалов высокого уровня в области разработки и внедрения именно комплексных медицинских информационных систем, работающих на стыке сложнейших наук - медицины и прикладной математики. Для становления отечественной школы в этой области творческим коллективам необходимо обмениваться наблюдениями и мнениями в разработке программных продуктов, накапливая тем самым специальные знания и формируя потенциально выгодные направления в поиске эффективных решений разработки и внедрения комплексных МИС.
Во время разработок медицинских информационных систем изучена на практике эффективность различных подходов. Для управления базами данных в информационных систе-мах применялись Microsoft FoxPro разных версий, CA Clipper, Lotus Notes, СУБД Microsoft SQL Server, Microsoft Access, Borland Paradox, MySQL и IBM DB2. Апробирован также вариант написания программного обеспечения на Borland Delphi, сервлеты на Java, применялись Lotus Designer и мультиплатформенный Lotus Script и некоторые другие технологии. Сервер-ная часть системы проектировалась под управлением Microsoft Windows NT Server, Microsoft Windows 2000 Server и Red Hat Linux 6.0. В качестве клиентской операционной системы при-менялись все версии Windows, начиная с Microsoft Windows 95.
Дипломный проект посвящен проектированию информационной системы муниципального учреждения здравоохранения №3 Хостинского района, поликлинического отделения.
Поликлиника – специализированное медицинское учреждение, обеспечивающее консу-льтацию и амбулаторное лечение больных. Численность обслуживаемого населения - 25961 человек (на 2005г.), и в подразделениях поликлиники собирается и обрабатывается значительный объем информации о поступлении, диагностике и лечении больных. Деятельность поликлиники не автоматизирована, медицинская документация хранится в бумажном архиве, операции по обработке информации выполняются вручную. С целью упростить обработку документации, было принято решение о проектировании информационной системы.
Использование технологий автоматизированного учета в сфере здравоохранения развивается. Последнее время появляется все большее число разработок по комплексной компьютеризации медицинских учреждений. В этих системах автоматизируются все этапы медико-технологического процесса (диагностика, контроль состояния пациентов и др.), а не только «традиционные» управленческие функции (бухгалтерия, отдел кадров, статистика). Такие примеры показывают, что компьютеризация – это не роскошь, которую можно себе позволить, (как думает большинство медицинских руководителей), а в высшей степени эффективное средство для повышения качества работы. По мнению медицинских учреждений, уже использующих информационные системы, такое решение позволяет совершенствовать наблюдение пациентов, повысить эффективность диагностики и лечения.
Цель дипломного проекта – совершенствования существующей организации обработки информации в поликлинике №3 за счет автоматизации процессов и проектирование информационной системы поликлиники.
Для достижения цели проекта были поставлены и решались следующие задачи:
выполнен анализ существующей организации обработки информации и информационные потоки организации;
проведен обзор и анализ представленных на рынке программных изделий, используемых для автоматизации обработки медицинской информации;
исследована эффективность различных методик проектирования базы данных МИС.
разработана концептуальная, логическая модели и модель предметного воплощения системы управления документооборотом поликлиники;
разработаны общие направления автоматизации работы поликлиники №3 Хостинского района и структура информационной системы;
определены очередность разработки и внедрения модулей информационной системы;
в качестве первого этапа автоматизации работы поликлиники разработано автоматизированное рабочее место работника регистратуры поликлиники.
В процессе решения задач применялись следующие методы проектирования:
- по степени автоматизации - компьютерное проектирование, которое производит генерацию или конфигурацию (настройку) проектных решений на основе использования специальных инструментальных программных средств;
- по степени использования типовых проектных решений - оригинальное (индивидуальное) проектирование, когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к ЭИС.[10]
Использовались инструментальные средства CASE - специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС: BPwin и ERwin.
Для разработки автоматизированного рабочего места работника регистратуры поликлиники применялась СУБД Access.

Алгоритм решения комплекса задач и его программная реализация тесно взаимосвязаны. Чем детальней будут проработаны алгоритмы обработки данных, тем легче будет реализовать их на практике.
Демонстрацию алгоритмов, используемых в разработке ПС, легче всего продемонстрировать на основе диаграмм UML.
Диаграмма в UML - это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями).

2.2.1 Диаграмма случаев использования Use Case (Main)
Диаграммы случаев использования показывают элементы модели случаев использования. Модель случаев использования представляет функциональные возможности системы или класса как они проявляются при внешнем взаимодействии с системой.
Диаграмма случаев использования - это граф действующих лиц, набора случаев использования, заключенных в границы системы, ассоциаций связи (участия) между действующими лицами и случаями использования, и обобщений между случаями использования.
На данной диаграмме можно увидеть какие возможности предоставляет пользователю следующее меню:
Файл
Предприятия
Отчеты
Расчеты
Справочники
см. диаграмму 1.1
2.2.2 Диаграмма классов Logical View (Unit1)
Диаграммы классов это набор декларативных (статических) элементов модели, таких как классы, интерфейсы и их отношения, соединенные друг с другом в виде графа. Диаграммы классов могут быть организованы из пакетов, каждый с образующей его моделью, или как отдельные пакеты, которые основываются на образующих модель пакетах.
Диаграмма классов представляет собой граф из элементов классификатора (classifier) соединенных различными постоянными отношениями. (Заметим, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже экземпляры (instance), такие как объекты и связи. Возможно, более правильным было бы название "структурная статическая диаграмма", но "диаграмма классов" короче и уже присвоено.)
Диаграмма показывает имеющиеся классы и их атрибуты, методы. Представленны следующие классы:
TForm
TObject
TCloseAction
TStatusBar
TToolBar
TMainMenu
TTollButton
TSpeedButton
TMenuItem
TForm1
Все отношения идут от TForm1 к остальным классам.
TObject и TCloseAction соединены с TForm1 зависимостью Dependency.
Зависимость показывает семантическое отношение между двумя (или более) элементами модели. Она касается непосредственно элементом модели и не требует набора экземпляров для назначения. Она указывает ситуацию, в которой изменение целевого элемента может потребовать изменения элемента источника зависимости.
Зависимость показывается пунктирной стрелкой между двумя элементами модели. Элемент модели на хвосте стрелки зависит от элемента модели на острие стрелки. Стрелка может быть помечена необязательным стереотипом и необязательным названием.
Все остальные классы соединены зависимостью обобщение. Обобщение является таксономическим отношением между общим элементом и специфичным элементом, который полностью непротиворечив первому элементу и добавляет к нему дополнительную информацию. Оно используется для классов, пакетов, случаев использования и других элементов.
Обобщение показывается как сплошной путь от специфичного элемента (например, подкласса) к общему элементу (например, суперклассу), с большим полым треугольником на конце пути в точке соединения с общим элементом.
см. диаграмму 1.2


2.2.3 Диаграмма компонентов Component View
Компонентная диаграмма показывает зависимости между программными компонентами, включая компоненты исходного текста, компоненты двоичного кода и выполнимые компоненты. Программный модуль может быть представлен как компонентный тип. Некоторые компоненты существуют во время компиляции, некоторые во время линковки, другие во время выполнения; некоторые существуют более чем в один момент времени. Компонент только компиляции представляет собой компонент, который значим только во время компиляции; компонент времени выполнения в этом случае был бы выполняемой программой.
Компонентная диаграмма содержит только представление типа, а не экземпляра. Чтобы показать экземпляры компонентов, используется диаграмма развертывания (возможно вырожденная без узлов).
Компонентная диаграмма изображается как граф компонентов, соединенных отношениями зависимости. Компонент может также быть присоединен к компонентам с помощью физического включения, представляющего отношение композиции.
Содержащая типы компонентов и типы узлов диаграмма может использоваться для показа зависимостей компилятора, которые показываются пунктирными стрелками (зависимостями) от компонента клиента к компоненту поставщику, от которого он неким образом зависит. Виды зависимостей являются специфическими для языка и могут показываться как стереотипы зависимостей.
Диаграмма может использоваться так же для показа интерфейсов и зависимостей вызова между компонентами, с помощью пунктирных стрелок от компонентов к интерфейсам других компонентов.
На данной диаграмме показаны все имеющиеся Unit'ы, формы, база данных и запускной файл.
Соединены компоненты соединены зависимостью Dependency которая была описана выше.
см. диаграмму 1.3

2.2.4 Диаграмма действий (State/Activity model)
Модель активности является вариантом конечного автомата, в котором состояния являются деятельностью, отображающей выполнение операций, а переходы инициированы завершением операций. Она представляет собой конечный автомат из процедур; процедура является реализацией операции, принадлежащей классу.
Диаграмма активности является частным случаем диаграммы состояний, в которой все (или, по крайней мере, большинство) состояний являются состояниями действий и, в которой все (или, по крайней мере, большинство) переходов, инициируются завершением действий в состояниях источниках. Диаграмма активности связывается (через модель) с классом или с реализацией операции или со случаем использования. Назначение этой диаграммы сконцентрироваться на потоках управляемых внутренней обработкой (в противоположность внешним событиям). Диаграмма активности используется в ситуациях, когда все или большинство событий означают завершение внутренне порожденных действий (то есть, процедурный поток управления). Обычная диаграмма состояний используется в ситуациях, в которых встречаются асинхронные события.
На диаграмме видно, что в начале происходит событие создания формы, после чего система переходит в состояние ожидания. Далее после события создания или активации чего-либо происходи инициализация базы данных. Следующим шагом является выбор действия посредством нажатия какой-либо кнопки N3 - заполнение справочников, N12 - расчеты и N15 - отчеты. Если выбраны справочники или расчеты, то происходит заполнение данных и если все введено верно, то данные сохраняются и работа завершается, если нет выдается сообщение об ошибке. Если же выбирается генерация отчетов, то необходимо ввести данные об отчете и если такой отчет существует, то он выводится на экран и работа завершается, а если отчет не существует - выводится сообщение об ошибке.
см. диаграмму 1.4

2.2.5 Диаграмма последовательности (Список автомобилей)
Шаблон взаимодействия между объектами показывается на диаграмме взаимодействия. Диаграммы взаимодействия имеют две основанные на общей информации формы, но каждая выделяет ее конкретный аспект: диаграммы последовательности и диаграммы сотрудничества.
Диаграммы последовательности показывают взаимодействие во времени. В частности она показывает объекты, участвующие во взаимодействии посредством "линий жизни" и сообщений, которыми они упорядоченно обмениваются во времени. Она не показывает ассоциаций между объектами.
Диаграммы последовательности имеют несколько немного различных форматов предназначенных для различных целей.
Диаграмма последовательности может существовать в обобщенной форме (описывающей все возможные последовательности) и в форме экземпляра (описывающей одну последовательность, согласующуюся с обобщенной формой). В случае без циклов и ветвей обе формы изоморфны.
Диаграммы последовательности и диаграммы сотрудничества выражают похожую информацию, но показывают ее различными путями. Диаграммы последовательности явно показывают последовательность сообщений и лучше для спецификаций реального времени и для сложных сценариев. Диаграммы сотрудничества показывают отношения между объектами и лучше для понимания всех эффектов для данного объекта и для процедурного проектирования.
Диаграмма последовательности представляет собой Взаимодействие, которое является набором передаваемых между объектами сотрудничества сообщений для достижения желаемой операции или цели.
Диаграмма последовательности имеет два измерения: вертикальное измерение представляет время, горизонтальное измерение представляет различные объекты. Обычно время распространяется вниз страницы. (При необходимости размерность может быть обращена.) Обычно важна только последовательность событий, однако в приложениях реального времени ось времени могла бы иметь реальную метрику. Горизонтальное упорядочение объектов не имеет никакого значения. На диаграмме объекты могут быть сгруппированы в "дорожки процессов".
см. диаграмму 1.5

2.3 Технология программирования, разработка и отладка рабочих программ
Для разработки программного средства учет автотранспорта мной бала выбрана среда программирования Delphi этот выбор был обусловлен целым рядом ключевых особенностей среды Delphi:
Интегрированная среда разработки приложений (IDE – Integrated Development Environment) – позволяет создавать, компилировать, тестировать и редактировать проект или группу проектов в единой среде программирования.
Визуальная технология разработки программ – позволяет быстро создавать приложения путем размещения в форме стандартных компонентов. При этом соответствующий код программы автоматически генерируется Delphi. Такая технология освобождает разработчика от рутинной работы по созданию пользовательского интерфейса и позволяет уделить внимания внутренней организации программы и обработке данных.
Технология Two Ways Tools делает более эффективной работу с компонентами. При изменении программного кода в окне редактора кода Delphi соответствующим образом изменяются и сами компоненты. С другой стороны, изменение свойств компонентов при помощи инспектора объектов Delphi немедленно отражается в окне редактора кода.
Библиотека компонентов содержит множество стандартных компонентов, которые можно использовать при создании приложений.
Поддержка баз данных в среде Delphi осуществляется двояко. С одной стороны в ней широко используются компоненты, предназначенные для работы с базами данных. С их помощью можно создавать простые приложения, предназначенные для обработки данных, и приложения типа клиент/сервер. Особенностью этих приложений является то, что уже во время создания приложения Delphi отображает результаты обработки данных и позволяет проанализировать различные ситуации, которые могут сложиться при работе программы. С другой стороны, поддержка баз данных в Delphi осуществляется с помощью набора драйверов соединения с SQL-серверами – Borland SQL links for Windows, которые позволяют интегрированному в Delphi ядру процессора баз данных Borland, BDE (Borland Database Engine), получать доступ к локальным базам данных Paradox, dBASE, Access и FoxPro, а также к SQL-серверам InterBase, Informix, Oracle, Sybase, DB2 и Microsoft SQL.

Заключение
Разработанная мной программа дала мне хороший опыт в создании продуктов для конкретного заказчика. Помогло оценить степень моей подготовленности к работе техником программистом в будущем. Так же созданный продукт ощутимо облегчил труд работников сразу нескольких отделов, помог сократить время на выполнение заказов и актуализировал данные о транспортных средствах.
После окончания работы над индивидуальным проектом были решены следующие задачи:
1) Был изучен процесс учета автотранспортных средств на предприятии «Фосфорит»
2) Разработано программное средство средствами Delphi, позволяющее:
систематизировать и актуализировать данные об автотранспорте на АТП;
обеспечить более оперативный доступ информации о текущем состоянии автотранспорта для администрации АТП;
отразить реальную стоимость услуг предоставляемых АТП;
вести учет автотранспорта и прохождения им технического обслуживания;
существенно сократить трудоемкость и, как следствие, сокращение времени выполнения основных технологических операций в АТП;
значительно сократить срок выполнения заказов, поступающих от физических лиц и организаций, пользующихся услугами АТП;
обеспечить возможность оперативного анализа хранящейся в АТП информации по различным критериям
3) Разработана программа внедрения и методическое обеспечение (руководство пользователя)

Список литературы.

Баас Р., М. Фервай, Х. Гюнтер Delphi 5 для пользователя. Издательская группа BHV, Киев, 2000. Издательство «Ирина», Киев, 2000.
Вендров А.М. Один из подходов к выбору средств проектирования баз данных и приложений. "СУБД", 1995, №3.
ГОСТ Р ИСО/МЭК 12207:2000. Информационная технология. Процессы жизненного цикла программного обеспечения.
ГОСТ Р ИСО/МЭК 9126:1993. Информационная технология. Оценка программной продукции. Характеристики качества и руководство по их применению.
ГОСТ Р ИСО/МЭК 12119-2000. Информационная технология. Пакеты программ. Требование к качеству и тестирование.
ГОСТ Р ИСО/МЭК ТО 9294:1993. Информационная технология. Руководство по управлению документированием программного обеспечения.
ГОСТ Р ИСО 9127:1994. Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов.
ГОСТ Р ИСО/МЭК 15910-2002. Информационная технология. Процесс создания документации пользователя программного средства.
ГОСТ Р ИСО/МЭК 15408-3-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Требования доверия к безопасности.
ГОСТ Р ИСО/МЭК 14764-2002. Информационная технология. Сопровождение программных средств.
ГОСТ Р ИСО/МЭК 15026-2002. Информационная технология. Уровни целостности систем и программных средств.
ГОСТ Р ИСО/МЭК ТО 12182-2002. Информационная технология. Классификация программных средств.
ГОСТ Р ИСО/МЭК ТО 15271-2002. Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств).
ГОСТ Р ИСО/МЭК 15408-1-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель.
ГОСТ 28195:1989. Оценка качества программных средств. Общие положения.
Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учебное пособие. М., Центр Информационных Технологий, 1996
Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). М., "Лори", 1996.
Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. М., "МетаТехнология", 1993.
Международные стандарты, поддерживающие жизненный цикл программных средств. М., МП "Экономика", 1996
Плю Р., Стефенс Р. Освой самостоятельно SQL за 24 часа. Издательский дом «Вильямс», 2000
Создание информационной системы предприятия. "Computer Direct", 1996, N2
Эбнер М. Delphi 5. Руководство разработчика. Издательская группа BHV, Киев, 2000.