Проектирование медицинской информационной системы выполняющей функции регистрации пациентов

Размещено на http://www.allbest.ru/

2

РЕФЕРАТ

Пояснительная записка 74 с., 33 рис., 9 табл., 10 источников, 1 прил.

АВТОМАТИЗАЦИЯ, УПРАВЛЕНИЕ, ОБСЛУЖИВАНИЕ, КОНЦЕПЦИЯ, МЕДИЦИНСКАЯ ИНФОРМАЦИОННАЯ СИСТЕМА, ЛОГИЧЕСКАЯ МОДЕЛЬ

Объектом исследования данной работы является процесс проектирования медицинской информационной системы для амбулаторно-поликлинического учреждения (АПУ).

Предметом исследования данной работы является автоматизация бизнес-процессов АПУ.

Цель работы - проектирование медицинской информационной системы выполняющей функции регистрации пациентов, лечения пациентов врачом и выставления счетов за лечение в страховой фонд.

В процессе работы были решены следующие задачи:

- рассмотрена реальная предметная область учета пациентов в амбулаторном отделении;

- проведено описание бизнес-процессов данной области на естественном языке;

- создана объектно-ориентированная модель бизнес-процессов данной области на языке UML;

- разработана структура базы данных;

- описана программная реализация продукта.

В результате была решена задача разработки логической модели программного обеспечения автоматизированной информационной системы регистрации пациентов в амбулаторно-поликлиническом отделении.

СОДЕРЖНИЕ

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

ВВЕДЕНИЕ

1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Амбулаторно-поликлиническое учреждение

1.2 Нотация CrossFunctionalFlowchart

1.3 Организационная структура АПУ

1.4 Описание бизнес-процессов АПУ

2. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ

2.1 Диаграммы вариантов использования

2.2 Диаграммы активности

2.3 Диаграммы классов

3. ПРОБЛЕМЫ ПРЕДМЕТНОЙ ОБЛАСТИ И ФОРМИРОВАНИЕ КОНЦЕПЦИИ МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Проблемы предметной области

3.2 Концепция информационной системы

4. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ

4.1 Диаграммы последовательности

5. ЛОГИЧЕСКАЯ МОДЕЛЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ

5.1 Модель поведения

5.2 Модель структуры

5.3 Выбор технологических средств

6. ОПИСАНИЕ БАЗЫ ДАННЫХ И ПРОГРАММНОЙ РЕАЛИЗАЦИИ

6.1 Описание базы данных

6.2 Описание программной реализации

7. БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ

7.1 Охрана труда

7.2 Общие правила безопасности при работе с ПК

7.3 Требования к рабочему месту

7.4 Нормативная база

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

АПУ -	Амбулаторно-поликлиническое учреждение
БД -	База данных
ИС -	Информационная система
Минздрав -	Министерство здравоохранения Российской Федерации
МИС -	Медицинская информационная система
МКБ-10 -	Международная классификация болезней десятый пересмотр от 25.10.1989г.
ОМС -	Обязательное медицинское страхование
ПО -	Программное обеспечение
ПК -	Персональный компьютер
ПрО -	Предметная область
ТФОМС -	Территориальный фонд ОМС
Case -	Computer-Aided System Engineering (CASE); Программное средство, автоматизирующее технологический процесс анализа, проектирования, разработки и сопровождения сложных программных систем
UML -	Унифицированный язык моделирования

ВВЕДЕНИЕ

Реалии современного мира подразумевают активную и масштабную информатизацию разных сфер деятельности человека: государственное управление, культурная и научная деятельность, правовой аппарат, здравоохранение, образование и т.д.

Информатизация - организационный социально экономический и научно-технический процесс создания оптимальных условий для удовлетворения информационных потребностей и реализации прав граждан, органов государственной власти, органов местного самоуправления организаций, общественных объединений на основе формирования и использования информационных ресурсов.

Информатизация в здравоохранении подразумевает создание единого информационного пространства, объединяющего деятельность медицинских работников (врачей, регистраторов, медицинских сестер) и административного персонала (статистиков, финансистов). Для здравоохранения информатизация является важной и неотъемлемой частью текущего развития.

Благодаря информатизации автоматизируется ряд процессов медицинского электронного документооборота. На данный момент активно внедряется Интегрированная Электронная Медицинская Карта (ИЭМК) - единый информационный ресурс, который будет накапливать и хранит всю медицинскую информацию о человеке (осмотры, диагнозы, операции, исследования) поступающая из разных медицинских организаций.

На данный момент организована возможность принятия и обработки счетов в электронном виде федеральным фондом, что значительно упрощает процесс выставления медицинских счетов на оплату и отработки ошибок по данным счетам.

Активное использование гражданами сети интернет создало потребность в электронной записи на прием к врачу, с помощью соответствующих ресурсов сети. Это значительно упрощает процесс записи: человеку достаточно сделать несколько кликов мышью вместо личного посещения медицинского учреждения «за номерком».

Ряд организаций требует предоставления листка нетрудоспособности в электронном виде. Это особенно актуально для людей, работающих удаленно в своей организации.

Для всех перечисленных вопросов медицинскому учреждению необходима медицинская информационная система (МИС). Разумеется, МИС решает и ряд других вопросов, но для решения вышеперечисленных она жизненно необходима.

На текущий момент на рынке представлено большое количество разнообразных МИС систем. Они имеют разную цену и предоставляют разнообразный функционал. Объединяет их одно - достаточно большое количество данного функционала. Практически все системы ориентированы на разные виды оплаты, на разнообразную деятельность медицинской организации. За счет этого пользователю предоставляется достаточно большое количество функций и возможностей, которые, к сожалению, ему не нужны. При этом они перегружают интерфейс, загружают работу системы, усложняют настройку. Также нельзя игнорировать существующую на данный момент низкую компьютерную грамотность существенной части медицинских работников, что еще больше усложняет работу с МИС системами.

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

Помимо прочего система должна решать следующие актуальные проблемы:

- организация единого информационного пространства между различными подразделениями АПУ путем объединения воедино регистрационно-учетной, медицинской и финансовой подсистемы;

- обеспечение своевременного получения врачом актуальной информации по прошлым и текущим заболеваниям, анализам и диагностическим исследованиям, с помощью создания и ведения электронной медицинской карты пациента (далее ЭМК);

- уменьшения риска потери информации за счет дублирования методов хранения информации (в физическом виде и в электронном виде);

- ускорение работы медицинских работников (регистраторов, врачей, медсестер, статистов) за счет автоматизации рутинных процессов ведения медицинской документации.



1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Амбулаторно-поликлиническое учреждение

Амбулаторно-поликлинические учреждения это лечебно - профилактические учреждения, оказывающие медицинскую помощь населению как непосредственно в самом учреждении, так и на дому, а также предназначенные для осуществления комплекса лечебно-профилактических мероприятий, направленных на предупреждение заболеваний.

Основной целью такой организации является наиболее быстрое и качественное лечение пациентов.

Как правило, в структуру такой организации может входить несколько поликлинических отделений, лабораторий, амбулаторий, офисов врачей общей практики, фельдшеро-акушерских пунктов. Организационные структуры в каждом подразделении похожи и дублируют друг друга.

В данной работе рассматривается АПУ, в состав которой входит взрослая поликлиника, детская поликлиника и административный отдел.

Внешней средой по отношению к нашей АПУ являются пациенты, министерство здравоохранения (выставляющее требование по учету и собирающее статистические данные) и страховой фонд, производящий оплату деятельности медицинской организации.

В данном разделе описывается сама организация и внешняя среда, с которой она взаимодействует. Основными знаниями, связывающими различные объекты предметной области в целое, являются бизнес-процессы, также представленные в данном разделе.

1.2 Нотация CrossFunctionalFlowchart

Для описания бизнес-процессов АПУ использована нотация CrossFunctionalFlowchart, иначе говоря кросс-функциональная блок схема.

С помощью нотации CrossFunctionalFlowchart представлен алгоритм (сценарий) выполнения процесса и заданы причинно-следственные связи и временная последовательность выполнения действий процесса.

Описание назначения графических символов, используемых в нотации, приведено в таблице 1.

Таблица 1 - Назначение графических символов

Название	Графический символ	Описание
Действие		Действие обозначается с помощью прямоугольника. Внутри прямоугольника расположено название действия.
Событие		Событие обозначается с помощью овала. Внутри располагается название события
Решение		Решение обозначается с помощью ромба. Обозначает ветвление ,при котором процесс может пойти только по одному сценарию из нескольких возможных. Внутри располагается название решения.
Связь предшествования		Стрелка «Связь» обозначает переход от одного действия к другому.
Дорожки		Дорожки обозначают исполнителей действий процесса - должности, подразделения, роли.

1.3 Организационная структура АПУ

Организационная структура - это совокупность взаимодействующих отделов и структурных частей в рамках одной организации для достижения цели, поставленной перед ней.

Организационная структура нашей АПУ представлена следующим образом: в состав входит взрослое поликлиническое отделение, детское поликлиническое отделение и административный отдел.

Во главе этой организации стоит главный врач. В его подчинении находятся заведующие взрослым и детским отделением. А также руководитель административного отдела (рисунок 1).

Рисунок 1 - Организационная структура АПУ

Каждый отдел, по сути, является отдельным структурным подразделением, со своей организационной структурой. Тем не менее, отделения работают в тесном сотрудничестве друг с другом.

Рисунок 2 - Организационная структура поликлинического отделения

Из взрослой и детской поликлиники пациенты направляются в лабораторию для проведения различных видов исследований. Административный отдел организовывает техническую работу всех остальных отделов, а также собирает статистические данные для последующей отправки в комитет здравоохранения.

Во главе каждой поликлиники стоят заведующие отделениями, в их подчинении находятся: регистратура, терапевтическое отделение, узкие специалисты, диагностические кабинеты (рисунок 2).

На рисунке 3 представлена схема, в которой во главе административного отдела стоит руководитель административного отдела. В его подчинении находятся отдел статистики, финансовый отдел, IT отдел, хозяйственный отдел.

Рисунок 3 - Организационная структура административного отдела

1.4 Описание бизнес-процессов АПУ

Основными знаниями предметной области компании являются бизнес-процессы, протекающие в ней. В данном разделе рассмотрены процессы, протекающие внутри каждого отдела.

Для описания бизнес-процессов использована нотация flowchart0.

Описание бизнес-процессов отдела «Регистратура»

Регистратура обеспечивает формирование и распределение потоков пациентов, своевременную запись и регистрацию больных на прием к врачу.

Изображение бизнес-процесса «Запись на прием» представлено на рисунке 4.



Рисунок 4 - Бизнес-процесс "Запись на прием"

1. «Обращение в регистратуру». Происходит обращение пациента в регистратуру с целью записи на прием к врачу. При себе пациент должен иметь паспорт и страховой полис, для подтверждения личности.

2. «Поиск карточки пациента в картотеке». Регистратор осуществляет поиск карточки пациента в картотеке на основании данных, предоставленных пациентом.

3. «Заведение новой карточки». Если поиск карточки пациента, осуществленный на шаге №2, не удался, регистратор заводит новую карточку пациента.

У регистратора должны присутствовать следующие формы, предварительно закупленные организацией:

- Медицинская карта пациента. Учетная форма 25/у, утверждена приказом Минздрава России от 15 декабря 2014г. № 834н.

- Информированное добровольное согласие на виды медицинских вмешательств. Приложение №2 к приказу Министерства здравоохранения Российской Федерации от 20 декабря 2012г. № 1177н.

Регистратор вручную вносит данные в учетные формы.

4. «Подписание документов». Происходит подписание информированного добровольного согласия на виды медицинских вмешательств пациентом.

5. «Заполнение статистического талона для пациента». Регистратор вручную заполняет основные данные в статистическом талоне.

У регистратора должны присутствовать учетная форма № 025-1/у (утверждена приказом Минздрава России от 15.12.2014 № 834н) предварительно закупленная организацией.

6. «Выдача пациенту карточки и статистического талона». Регистратор выдает пациенту на руки карточку, статистический талон и предварительно заполненный номерок. Сообщает на словах, куда именно и когда ему требуется прийти.

Описание бизнес-процессов отдела «Узкие специалисты» и отдела «Терапевтическое отделение»

Отдел «Узкие специалисты» и «Терапевтическое отделение» обеспечивают прием и лечение пациентов.

Изображение бизнес-процесса «Прием пациента» представлено на рисунке 5.

Рисунок 5 - Бизнес-процесс «Прием пациента»



1. «Ожидание времени приема в живой очереди». Происходит ожидание приема в порядке живой очереди перед кабинетом.

2. «Обращение пациента». Врач принимает пациента, выслушивает причину обращения.

3. «Поиск информации по предыдущим обращениям в карточке пациента». Врач вручную просматривает записи в карточке пациента, в поисках информации, требуемой для анализа текущего заболевания пациента.

4. «Выставление диагноза. Заполнение стат.талона». Врач ставит диагноз пациенту по справочнику МКБ-10 [2, c.68], вручную указывает всю необходимую информацию на статистическом талоне.

5. «Заполнение необходимой документации». [3, c.68] Медсестра, на основании слов врача, заполняет вручную документы, необходимые для продолжения лечения.

У медсестры должны присутствовать следующие формы, предварительно закупленные организацией:

- направление на диагностические исследования (форма 027/у или форма 057/у-04);

- направление на анализы (форма (200/у-246/у));

- направление на консультацию к другому специалисту (форма 027/у);

- номерок на повторный прием;

- направление на госпитализацию (форма № 057/у-04 утверждена приказом Минздравсоцразвития России от 22.11.2004 № 255).

6. «Заполнение карточки пациента и сопутствующей документации».

Врач вручную описывает в карточке пациента протокол осмотра. В случае необходимости пишет рецепт на лекарственные средства.

7. «Получение необходимой документации». Пациент получает от медицинских работников необходимые рецепты, направления, бланки т.д.

Описание бизнес-процесса отдела «Диагностические кабинеты»

Отдел «Диагностические кабинеты» обеспечивает диагностические исследования для пациентов.

Изображение бизнес-процесса «Диагностическое исследование» представлено на рисунке 6.

Рисунок 6 - Бизнес-процесс «Диагностическое исследование»

1. «Ожидание времени приема в живой очереди». Происходит ожидание приема в порядке живой очереди перед кабинетом.

2. «Обращение пациента. Проведение диагностического исследования». Врач-диагност проводит диагностическое исследование с помощью соответствующей медицинской аппаратуры.

3. «Описание диагностического исследования». Врач-диагност вручную заполняет протокол проведенного диагностического исследования, чтобы в будущем вклеить его в карту.

Описание бизнес-процесса отдела Статистики

Отдел статистики формирует федеральные формы отчетности и отправляет их в министерство здравоохранения.

Изображение бизнес-процесса «Формирование федеральных форм» представлено на рисунке 7.

1. «Поступление статистических талонов в отдел статистики». Статистические талоны, ранее оформленные врачами, поступают в бумажном виде в отдел статистики.

2. «Обработка данных статистических талонов. Формирование федеральных форм». Специалисты статистики вручную заполняют статистические формы и готовят их к отправке в министерство здравоохранения.

Медицинская организация обязана каждый квартал отправлять следующие статистические формы:

- Федеральная форма № 57.

- Федеральная форма № 12.

- Федеральная форма № 30.

- Федеральная форма № 39.

- Федеральная форма № 16 ВН.

Рисунок 7 - Бизнес-процесс «Формирование федеральных форм»

3. «Отправка собранных форм в министерство здравоохранения».

Специалисты отправляют подготовленные формы в министерство здравоохранения.

Описание бизнес-процесса финансового отдела

Финансовый отел производит отправку сформированных счетов в федеральный фонд.

Изображение бизнес-процесса «Процессы финансового отдела» представлено на рисунке 8.

Рисунок 8 - Бизнес-процесс "Процессы финансового отдела"

1. «Поступление статистических талонов в финансовый отдел». Статистические талоны, ранее оформленные врачами, поступают в бумажном виде в финансовый отдел.

2. «Ввод данных в программу, предоставленную ТФОМС». Сотрудники финансового отдела вручную вносят данные в программу предоставленную федеральным фондом.

3. «Отправка данных в ТФОМС». Сотрудники финансового отдела отправляют внесенные данные в фонд с помощью программы, предоставленной федеральным фондом.



Вывод

Проведенное описание предметной области выявило основную проблематику учреждения:

- хранение информации в бумажном виде, что подразумевает большие затраты времени на поиск информации, риск потери информации (человеческий фактор);

- ручной заполнение документации, что увеличивает риск ошибок и потери времени;

- необходимость перевода данных в электронный вид, несмотря на общее ведение процессов в бумажном виде, что означает двойной объем работы, наличие дополнительного персонала для выполнения этой работы и, соответственно, растраты на оплату работы данного персонала.

2. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ

Концептуальная модель - это описание системы понятной пользователю. Основная цель использования - достижение взаимопонимания между пользователем и разработчиком системы. [2, c.68]

На концептуальной модели подробно отображаются связи между объектами и их характеристиками, за счет чего ее удобно использовать для дальнейшего проектирования базы данных и перевода ее, например, в реляционную базу данных.

2.1 Диаграммы вариантов использования

Диаграммы вариантов использования показывают, что именно делает система в процессе своего функционирования, т.е. описывает функциональное назначение системы.

На нашей диаграмме ключевым понятием является амбулаторно-поликлиническое обслуживание пациента. Также все сотрудники, участвующие в оформлении, лечении и прочих действиях, осуществляемых при обращении пациента, указаны в виде персон, которые объединены классом: сотрудники. Принцип создания диаграмм вариантов использования следующий: проектируемая система представляется в виде нескольких объектов с помощью вариантов использования взаимодействующих с системой. Объектами могут являться любые сущности, извне работающие с системой. В нашем случае объектами являются люди с определенными ролями - регистраторы, врачи, статисты и т.д. Вариант использования описывает процессы, выполняемые объектами.

Диаграмма вариантов использования, моделирующих функциональную (процессную) структуру предметной области посредством вариантов использования и отношений между ними представлена на рисунке 9.



Рисунок 9 - Диаграмма вариантов использования

2.2 Диаграммы активности

Название	Графическое обозначение	Описание
Начальный узел деятельности		Узел активности с которого начинается поток
Конечный узел деятельности		Узел активности останавливающий все потоки активности
Активность		Действия необходимые для достижения цели
Узел решения		Узел решения определяет правила ветвления активностей.
Объект		Объект над которым выполняются действия (активности)

Диаграмма активности представлена на рисунке 10.

Диаграмма классов - одна из форм статистического описания системы, с точки зрения ее структуры. Т.е. диаграмма классов описывает структуры системы, демонстрируя объекты и классы, а также их взаимосвязи. На текущей диаграмме отображены класс, объект и взаимодействие.



Рисунок 10 - Диаграмма активности

2.3 Диаграммы классов

На рисунке 11 представлена диаграмма классов процессов статистического и финансового отделов.

Рисунок 11 - Диаграмма классов статистического и финансового отделов

На рисунке 12 представлена диаграмма классов процессов регистрации пациента, лечения пациента и диагностического исследования.

Рисунок 12 - Диаграмма классов процессов регистрации пациента, лечения пациента и диагностического исследования

Вывод

Создание концептуальной модели предметной области позволило детально изучить процессы, происходящие в АПУ. Выявлены все связи и взаимодействия актуальные для нашей предметной области. На основе полученной информации была разработана концепция проектируемой информационной системы.

3. ПРОБЛЕМЫ ПРЕДМЕТНОЙ ОБЛАСТИ И ФОРМИРОВАНИЕ КОНЦЕПЦИИ МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Проблемы предметной области

Проанализировав и описав предметную область, мы можем выявить следующие проблемы:

1. Большие затраты времени персонала на ручное оформление документации.

2. Большие затраты времени на поиск информации.

3. Риск потери информации из-за хранения информации в карточке в физическом виде и выдаче ее на руки пациенту.

4. Длительное ожидание пациентом приема в очереди.

5. Большое количество документов, выдаваемое пациенту при записи на прием к врачу.

6. Дублирование обработки информации (по отдельности данные обрабатывает статистический отдел и финансовый отдел).

7. Необходимость заранее закупать бланки учетной медицинской документации.

3.2 Концепция информационной системы

Основные понятия

Пациент - человек, получающий медицинскую помощь в АПУ по поводу какого-либо заболевания.

Карта пациента - медицинский документ, в котором лечащими врачами ведётся запись истории болезни пациента и назначаемого ему лечения.

Электронная карта пациента - карта пациента мед. учреждения в электронной форме.

Номерок - дата и время записи на прием к врачу, последовательность которых формирует очередность посещения врача пациентами, может быть представлен в бумажном и/или в электронном виде.

Статистический талон - медицинский документ, соответствующий учетной форме № 025-1/у (форма утверждена приказом Минздрава России от 15.12.2014 № 834н).

Живая очередь - пациенты, расположившиеся друг за другом, для получения медицинской помощи в последовательном порядке.

Регистратор - сотрудник регистратуры.

Осмотр - прием у врача, в рамках которого специалист проводит осмотр пациента, а также необходимые сопутствующие манипуляции.

Диагноз - определение болезни на основании исследования больного. Выставляется по международному классификатору МКБ-10.

Врач - сотрудник, осуществляющий лечение пациентов.

Исследование - диагностическое или лабораторное исследование, назначаемое пациенту врачом.

Протокол исследования - медицинская документация, заполняемая диагностом. медицинский информационный программный логический

Диагност - врач или медсестра, специализирующийся на диагностических или лабораторных исследованиях.

Статистик - сотрудник отдела статистики.

Федеральная форма - обязательная медицинская учетная документация, формируемая в строгом соответствии с требованиями министерства здравоохранения и предоставляемая медицинской организацией в учетный период. Программа предоставленная ТФОМС - программа, предназначенная для передачи данных в федеральный фонд ОМС и предоставляемая им же. МИС - медицинская информационная система.

Функциональные требования.

В данном разделе содержится перечень функциональных возможностей, которыми должна обладать МИС для успешного решения проблем, выявленных в результате проблемного анализа предметной области. [5, c.68]

Основные требования.

- Ведение электронной картотеки пациентов.

- Удобный и быстрый поиск пациента по картотеке.

- Вывод на печать всей необходимой документации с уже заполненными данными.

- Формирование электронной очереди пациентов к врачу.

- Ведение электронного статистического талона.

- Ведение электронной истории болезни пациента [4, c.68]

- Формирование федеральных форм на основе заведенных статистических талонов.

Обеспечивающие требования.

- Обеспечение защиты информации от не санкционируемого доступа.

- Обеспечение защиты информации от потерь (создание и хранение дампов БД). Нефункциональные требования.

В данном разделе содержится перечень нефункциональных требований к возможностям ИС, условиям ее функционирования, ограничениям реализации, требованиям к производительности, расширяемости. [6, c.68]

Основные требования.

- Современное аппаратное обеспечение.

- Удобный пользовательский интерфейс.

- Поддержка хранения больших объемов данных.

- Возможность расширения системы с учетом роста сети.

- Организация защищенного доступа к сервисам ТФОМС.

Вывод

Описание предметной области позволили выделить и описать текущие проблемы предметной области, представленные в этом разделе. Описанная проблематика и концептуальная модель позволили создать концепцию информационной системы, решающую представленные проблемы.



4. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ

В данном разделе представлены диаграммы, на концептуальном уровне моделирующие функциональные возможности и структуру программного обеспечения МИС.

Концептуальная модель МИС определяет систему сбора, накопления и выдачи информации, а также, конкретные задачи и функции, обеспечиваемых созданием и эксплуатацией информационной системы.

При разработке проекта будем использовать трехслойную архитектуру как архитектуру взаимодействия классов, организованных в три слоя (представление, предметная область, источник данных) в рамках одного приложения.

4.1 Диаграммы последовательности

Диаграммы последовательности отображают процессы взаимодействия объектов системы во времени, обмен сообщений между ними, выходные сообщения процессов.

Рисунок 13 - Диаграмма последовательности, моделирующая использование МИС в работе регистратуры

Диаграмма последовательности, моделирующая использование МИС в работе регистратуры, представлена на рисунке 13.

Диаграмма последовательности, моделирующая использование ИС в работе врача представлена на рисунке 14.

Диаграмма последовательности, моделирующая использование МИС в работе статистика представлена на рисунке 15.

Диаграмма последовательности, моделирующая использование МИС в работе сотрудника финансового отдела, представлена на рисунке 16.

Рисунок 14 - Диаграмма последовательности, моделирующая использование МИС в работе врача

Рисунок 15 - Диаграмма последовательности моделирующая использование МИС в работе статистика



Рисунок 16 - Диаграмма последовательности, моделирующая использование МИС в работе сотрудника финансового отдела

Основные высказывания по каждому слою архитектуры:

1. Слой представления: предоставляет услуги отображения данных, обработки событий пользовательского интерфейса (щелчки мыши, нажатия клавиш).

2. Слой предметной области: выполняет вычисления на основе вводимых и хранимых данных, проверку всех элементов данных и обработку команд, поступающих от слоя представления, а также передачу информации слою источника данных.

3. Слой источника данных: выполняет обращения к базе данных, обмен сообщениями, мониторинг транзакций.

Назначение классов по слоям представлены в таблице 3.

Таблица 3 - Назначение классов по слоям

№	Наименование класса	Назначение класса
Слой представления
1.	E-UI-Registr	Граничный класс, отвечающий за: - поиск пациента; - отображение списка пациентов; - создание нового пациента; - отображение расписания врачей; - запись пациента на прием;
2.	E-UI-Doctor	Граничный класс, отвечающий за: - отображение списка пациентов, записанных на прием; - отображение электронной истории болезни пациента; - создание осмотра; - заполнение стат.талона;
Продолжение таблицы 3
3.	E_UI_Statistic	Граничный класс, отвечающий за: - отображение статистических талонов; - редактирование статистических талонов; - формирование федеральных форм;
4.	E-UI-Operator	Граничный класс, отвечающий за: - создание счета; - отправка счета в тфомс;
5.	E-UI-Print	Граничный класс, отвечающий за: - отображение списка доступных печатных форм; - отправка выбранной формы на печать;
6.	Rules	Класс хранения, содержащий данные бизнес-правил.
7.	Controller	Управляющий класс, методы которого отвечают за управление приложением.
Слой предметной области
8.	Serv_vizov	Граничный класс, отвечающий за взаимодействие с классами слоя предметной области.
9.	E-Kard	Kласс хранения, содержащий индивидуальные данные пациента.
10.	E-Schedule	Kласс хранения, содержащий дату и время приема врачей.
Продолжение таблицы 3
11.	E-Doctor	Класс хранения, содержащий данные о врачах
12.	E-History	Kласс хранения, содержащий данные по истории болезни пациента
13.	E-Nomerok	Класс хранения, содержащий данные о записи пациента
14.	E-StatTalon	Kласс хранения, содержащий данные статистического талона пациента
15.	Fed_form	Граничный класс, отвечающий за формирование федеральных форм
16.	Form_schet	Граничный класс, отвечающий за формирование счетов
17.	E-Schet	Класс хранения, содержащий данные по счетам
18.	Otpravka_schet	Граничный класс, отвечающий за отправку счетов в ТФОМС
Слой источника данных
19.	Data	Граничный класс для взаимодействия с базой данных

Результат разработки концептуальной модели информационной системы, процессы регистратуры и врача, представлен на рисунке 17.

Рисунок 17 - Концептуальная модель информационной системы. Процессы регистратуры и врача

Результат разработки концептуальной модели информационной системы, процессы статистики и отдела финансов, представлен на рисунке 18.



Рисунок 18 - Концептуальная модель информационной системы. Процессы статистики и отдела финансов

Вывод

В данном разделе была разработана концептуальная модель информационной системы, отвечающая концепции информационной системы из прошлого раздела и решающая ряд проблем предметной области представленных ранее.

Также были описаны слои архитектуры и соответствующие им классы медицинской информационной системы.



5. ЛОГИЧЕСКАЯ МОДЕЛЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

5.1 Модель поведения

Разрабатывается с помощью диаграмм последовательности. Модель поведения демонстрирует взаимодействие объектов при работе МИС.

На рисунке 19 представлена диаграмма последовательности, моделирующая процесс «Обращение в регистратуру».

Рисунок 19 - Диаграмма последовательности, моделирующая процесс «Обращение в регистратуру»

На рисунке 20 представлена диаграмма последовательности, моделирующая процесс «Прием у врача».



Рисунок 20 - Диаграмма последовательности, моделирующая процесс «Прием у врача»

На рисунке 21 представлена диаграмма последовательности, моделирующая процесс отдела статистики.

Рисунок 21 - Диаграмма последовательности, моделирующая процесс отдела статистики

На рисунке 22 представлена диаграмма последовательности, моделирующая процесс финансового отдела.



Рисунок 22 - Диаграмма последовательности, моделирующая процесс финансового отдела

5.2 Модель структуры

Модель структуры разработана с помощью диаграмм классов.

На модели структуры определяются связи между основными объектами базы данных.

При построении концептуальной модели МИС были выделены основные сущности разрабатываемой базы данных (БД):

- карта пациента;

- номерок;

- расписание;

- врачи;

- история болезни;

- статистический талон;

- счет;

- федеральная форма.

На рисунке 23 представлена диаграмма классов, моделирующая процесс взаимоотношений пациента, регистратора и врача на логическом уровне.



5.3 Выбор технологических средств

Архитектура взаимодействия: клиент-сервер, что, соответственно, требует наличия сервера с базой данных.

В качестве СУБД рекомендуется использовать MySQL, в связи со следующими преимуществами:

- реляционная модель данных;

- свободно-распространяемая под лицензией GNU GPL 2;

- имеет хорошую базу технической документации и литературы;

- является активно развивающимся продуктом с большим опытом;

- низкие требования к ресурсам аппаратного обеспечения;

Рисунок 23 - Диаграмма классов, моделирующая процесс взаимоотношений пациента, регистратора и врача



Программу рекомендуется устанавливать на персональные ЭВМ со следующим набором устройств: дисплей с платой адаптера VGA, накопитель на жестком диске объемом не менее 500 Гб. Необходимая оперативная память: не менее 2048 Мб; минимальный объем свободной оперативной памяти: 256 Мб.

Вывод

В данном разделе разработана конечная, логическая модель программного обеспечения медицинской информационной системы. Она включает модель поведения, раскрывающую взаимодействие объектов в работе МИС. А также модель структуры, описывающую объекты базы данных и взаимосвязи между ними.



6. ОПИСАНИЕ БАЗЫ ДАННЫХ И ПРОГРАММНОЙ РЕАЛИЗАЦИИ

6.1 Описание базы данных

В предыдущем разделе была представлена модель структуры базы данных, реализованная с помощью диаграмм классов. В данном разделе более детально описаны субъекты и процессы, происходящие в данной медицинской информационной системе. [7, 8, c.68].

База данных состоит из 6 таблиц.

Таблица Patient. В ней содержатся данные пациентов, прикрепленных к данному медицинскому учреждению. Ключевым полем является id_patient.

В таблице 4 описана структура таблицы Patient.

Таблица 4 - Структура таблицы Patient

Наименование поля	Тип данных	Длина	Наличие ключа	Значение по умолчанию	Описание
id_patient	integer	10	Первичный	-	Уникальный идентификатор записей в таблице Patient
lastname	varchar	60	-	-	Фамилия
firstname	varchar	60	-	-	Имя
secondname	varchar	60	-	-	Отчество
sex	varchar	1	-	-	Пол
birthdate	date	-	-	-	Дата рождения
passser	integer	4	-	-	Серия документа
Продолжение таблицы 4
passnumb	integer	6	-	-	Номер документа
passissue	varchar	20	-	-	Где выдан документ
passdate	date	-	-	-	Дата выдачи
snils	varchar	14	-	-	СНИЛС
police_name	varchar	100	-	-	Наименование страховой компании
police_date	date	-	-	01.01.2000	Дата выдачи полиса
police_number	integer	16	-	-	Номер полиса
addr_registr	varchar	100	-	-	Адрес регистрации
addr_live	varchar	100	-	-	Адрес проживания
text	varchar	512	-	-	Комментарий

Таблица Doctor. В ней содержатся данные врачей, оказывающих медицинское обслуживание в данном учреждении. Ключевым полем является id_doctor.

В таблице 5 описана структура таблицы Doctor.

Таблица 5 - Структура таблицы Doctor

Наименование поля	Тип данных	Длина	Наличие ключа	Значение по умолчанию	Описание
id_doctor	integer	10	Первичный	-	Уникальный идентификатор записей в таблице doctor
FIO	varchar	100	-	-	ФИО врача
special	varchar	60	-	-	Специальность
text	varchar	512	-	-	Комментарий

Таблица Schedule. В ней содержится расписание врачей. Ключевым полем является id_schedule. Данная таблица имеет ссылку на таблицу doctor, с помощью поля id_doctor.

В таблице 6 описана структура таблицы Schedule.

Таблица 6 - Структура таблицы Schedule

Наименование поля	Тип данных	Длина	Наличие ключа	Значение по умолчанию	Описание
d_schedule	integer	10	Первичный	-	Уникальный идентификатор записей в таблице schedule
Продолжение таблицы 6
id_doctor	integer	10	-	-	Ссылка на таблицу doctor
date	date		-	-	Дата
time_start	date		-	-	Время номерка: начало
time_end	date				Время номерка: окончание
text	varchar	512	-	-	Комментарий

Таблица Nomerok. В ней содержатся данные о записях пациентов к врачу. Ключевым полем является id_nomerok. Также таблица содержит поле id_patient, тем самым ссылаясь на таблицу patient. И поле id_schedule, ссылаясь на таблицу Schedule.

В таблице 7 описана структура таблицы Nomerok.

Таблица 7 - структура таблицы Nomerok

Наименование поля	Тип данных	Длина	Наличие ключа	Значение по умолчанию	Описание
id_nomerok	integer	10	Первичный	-	Уникальный идентификатор записей в таблице nomerok
id_schedule	integer	10	-	-	Ссылка на таблицу schedule
Продолжение таблицы 7
id_patient	integer	10	-	-	Ссылка на таблицу patient
text	varchar	512	-	-	Комментарий

Таблица History. В ней содержится история болезни пациентов. Ключевым полем является id_history. Также таблица содержит поле id_patient, тем самым ссылаясь на таблицу patient. И поле id_nomerok, ссылаясь на таблицу Nomerok.

В таблице 8 описана структура таблицы History.



Таблица 8 - структура таблицы History

Наименование поля	Тип данных	Длина	Наличие ключа	Значение по умолчанию	Описание
id_history	integer	10	Первичный	-	Уникальный идентификатор записей таблице history
id_patient	integer	10	-	-	Ссылка на таблицу patient
id_nomerok	integer	10	-	-	Ссылка на таблицу nomerok
Наименование поля	Тип данных	Длина	Наличие ключа	Значение по умолчанию	Описание
Продолжение таблицы 8
date	Date		-	-	Дата осмотра
text	varchar	512	-	-	Комментарий

Таблица Stat_talon. В ней содержаться данные статистического талона, заполненного врачом. Ключевым полем является id_stat_talon. Также таблица содержит поле id_patient, тем самым ссылаясь на таблицу patient. И поле id_nomerok, ссылаясь на таблицу Nomerok.

В таблице 9 описана структура таблицы Nomerok.

Таблица 9 - структура таблицы Nomerok

Наименование поля	Тип данных	Длина	Наличие ключа	Значение по умолчанию	Описание
id_stat_talon	integer	10	Первичный	-	Уникальный идентификатор записей таблице Stat_talon
id_patient	integer	10	-	-	Ссылка на таблицу patient
id_nomerok	integer	10	-	-	Ссылка на таблицу nomerok
date	date		-	-	Дата посещения
diagnos	varchar	50	-	-	Диагноз
cel	varchar	50	-	-	Цель посещения
Продолжение таблицы 9
mesto	varchar	50	-	-	Место обслуживания
harakter	varchar	50	-	-	Характер заболевания
result	varchar	50	-	-	Результат обращения
Наименование поля	Тип данных	Длина	Наличие ключа	Значение по умолчанию	Описание
itog	varchar	50	-	-	Исход обращения

На основе описания составлена ER диаграмма структуры базы данных (рисунок 24).

Рисунок 24 - ER диаграмма структуры базы данных

6.2 Описание программной реализации

Проектируемая система позволяет автоматизировать процессы регистрации пациента, ведение истории болезни, составление статистических отчетных форм и отправку счетов. [9, c.68]

Система состоит из нескольких отдельных модулей, каждый из которых предназначен для выполнения конкретных задач, взаимодействующих с единой базой данных. Это позволит устанавливать на рабочие места пользователей только те модули, которые будут использоваться на данном рабочем месте. Таким образом минимизируются рабочие ресурсы, а пользователь не перегружается лишним интерфейсом.

Далее будет детально рассмотрен модуль «Регистратура».

После запуска программы пользователь видит основное меню, представленное на рисунке 25.

Рисунок 25 - Основное меню

В основном меню отображены три основные кнопки:

1. «Поиск пациента» - с помощью которой регистратор может сделать поиск уже зарегистрированных пациентов по базе данных.

2. «Создание пациента» - предназначена для создания нового пациента.

3. «Расписание» - предназначена для просмотра расписания врачей регистратором и создания номерка

При обращении пациента, первым делом регистратор производит поиск пациента по базе данных. Для этого регистратор нажимает на кнопку «Поиск пациента». Отображает окно с фильтрами для поиска (рисунок 26).

Поиск пациента регистратор может делать по следующим полям:

- № карты;

- фамилия;

- имя;

- отчество;

- дата рождения;

- № полиса;

Рисунок 26 - Поиск пациента

При поиске нет необходимости вводить полные данные, можно искать совпадения по части слова. После ввода данных в поля для фильтра, регистратор нажимает кнопку «Поиск». В области результатов поиска отображаются все записи, соответствующие запросу.

После выбора нужного пациента регистратор может отредактировать карточку пациента, удалить ее, а также распечатать необходимую документацию.

Для редактирования карточки пациента требуется кликнуть мышкой на нужного пациента два раза, либо выделить пациента и нажать на кнопку редактировать. При этом откроется окно «Карточка пациента» (рисунок 27).



Рисунок 27 - Карточка пациента

Регистратор может отредактировать данные в карточке пациента за исключением поля «№ карты», т.к. номером карты является id_patient, который является первичным ключом таблицы Patient и, соответственно, генерируется автоматически.

Редактируются поля:

- фамилия;

- имя;

- отчество;

- дата рождения;

- пол (выбор значения из списка);

- серия паспорта;

- номер паспорта;

- когда выдан паспорт;

- кем выдан паспорт;

- снилс;

- страховая компания, выдавшая полис (выбор из списка);

- номер полиса;

- дата выдачи полиса;

- адрес регистрации пациента;

- адрес проживания пациента;

- комментарий;

После внесения всех необходимых изменений регистратор нажимает кнопку «сохранить». Если, по каким-либо причинам», изменения вносить не надо, пользователь нажимает кнопку «отмена».

Если регистратор не смог найти нужного пациента в базе данных, он создает новую карточку пациента с помощью кнопки «Создать». В этом случае открывается окно «Карточка пациента» с пустыми полями доступными для заполнения (рисунок 28).

Рисунок 28 - Карточка пациента

Регистратор заполняет все необходимые поля в карточке, затем сохраняет новую карточку пациента.

В случае, если требуется записать пациента на прием к врачу, регистратор пользуется кнопкой «Расписание». При нажатии открывается окно с расписанием врача (рисунок 29).

Регистратор выбирает нужного врача из выпадающего списка в поле «Врач». Специальность врача отображается автоматически.

Расписание реализовано в виде календаря. На каждом дне указано количество свободных номерков на эту дату. Для записи пациента необходимо кликнуть два раза на нужный день или выбрать день и нажать на кнопку «записать». Откроется окно «Выдача номерка» (рисунок 30).

Рисунок 29 - Расписание врача

Рисунок 30 - Выдача номерка



В данном окне отображается список номерков со временем начала и окончания приема, а также список пациентов, записанных на прием. Регистратор может удалить имеющуюся запись на прием, выбрав нужную запись и нажав кнопку «удалить».

Для записи пациента пользователю требуется кликнуть два раза на нужное время. При этом откроется окно поиска пациента (рисунок 31).

Рисунок 31 - Поиск пациента

Окно реализовано точно таким же образом, как и поиск в основном окне регистратуры. Пользователь вводит данные в поля поиска и нажимает кнопку «поиск». После произведенного поиска регистратор выбирает нужного пациента из списка и нажимает кнопку «выбрать». При этом выбранный пациент записывается на прием на указанное время.

При заведении нового пациента обычно требуется распечатать ряд сопутствующих документов, таких как карточка пациента, информированное добровольное согласие на медицинское вмешательство, согласие на обработку персональных данных, статистический талон или номерок.

Для этого в основном окне пользователь нажимает кнопку «печать», при этом открывается окно с выбором печатных форм (рисунок 32).



Рисунок 32 - Окно "Печать"

Пользователь выделяет нужную форму и нажимает кнопку «выбрать». При этом нужный документ отправляется на печать.

Запросы, использованные для взаимодействия c базой данных при использовании программы, представлены в приложении А.

Вывод

В данном разделе представлена структура разрабатываемой базы данных, с описанием таблиц и связей между ними. Также описана клиентская часть, в виде описания программной реализации для модуля «регистратура». Остальные модули будут разрабатываться по аналогии с модулем «регистратура».

Описанная программная реализация решает такие проблемы, как:

- временные затраты на оформление документации;

- необходимость закупки бланков для оформления документации;

- нахождение пациентов в живой очереди (за счет введения электронной очереди приема пациентов);

- риск потери информации в физическом виде;



7. БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ

7.1 Охрана труда

Охрана труда - комплекс мероприятий, направленный на сохранение здоровья и жизни работников предприятия. Включает социально-экономические, правовые, лечебно-профилактические, реабилитационные, организационно-технические, санитарно-гигиенические и иные мероприятия.

Основную деятельность службы охраны труда составляет анализ рабочих мест, учет травматизма, заболеваний, связанных с деятельностью предприятия.

Также в обязанности службы охраны труда входит создание и утверждение инструкций по охране труда, а также инструктаж персонала.

Целью охраны труда является минимизирование вероятности заболевания или поражения персонала при максимальной производительности труда.

Безопасными условиями труда являются условия, при которых отсутствует влияние опасных или вредных производственных факторов на персонал или их влияние соответствует принятым нормативам.

При работе за компьютером выделены следующие вредные производственные факторы:

- физические: возможность замыкания электрической цепи; повышенный уровень рентгеновского, ультрафиолетового и инфракрасного излучения; запыленность воздуха в помещении; повышенный уровень пульсации светового потока, неравномерное распределение яркости; длительное нахождение в сидячем положении;

- химические: насыщенность воздуха углекислым газом, озоном, аммиаком, фенолом, формальдегидом;

- психофизиологические: напряжение внимания, памяти, зрения; монотонность труда; большой объем информации, обрабатываемый за короткий период времени.

7.2 Общие правила безопасности при работе с ПК

Необходимо, перед началом работы проверить целостность проводов, розеток, вилок. Наличие заземления на ПК.

В процессе работы необходимо:

- соблюдать аккуратность при обращении с проводами;

- в случае неисправности компьютера работать с ним запрещается;

- очищать компьютер необходимо только при его отключении от сети;

- ремонт оборудования допускается только при наличии соответствующих навыков;

- запрещается располагать вблизи компьютера жидкости;

- запрещается употребление пищи вблизи рабочего места;

- запрещается курение за рабочим местом;

- требуется проводить перерывы в работе длительностью 10-15 минут, каждый час. При аварийной ситуации:

- необходимо отключить компьютер от электросети;

- при обнаружении оголенного провода требуется исключить возможность контакта с проводом, а также оповестить окружающих;

- при возникновении пожара требуется принять меры по его тушению с помощью огнетушителей;

- при поражении человека током требуется оказать ему первую медицинскую помощь, а также вызвать скорую.

При окончании работы:

- необходимо выключить компьютер;

- организовать уборку рабочего места;

- выключить электропитание.



7.3 Требования к рабочему месту

- освещённость рабочего места должна составлять от 300 до 500 люкс;

- освещенность экрана монитора не должна превышать 30 люкс;

- чистка окон и источников света должна проводиться не реже двух раз в год;

- расстояние между рабочими местами должно превышать 2 метра;

- расстояние между видеомониторами должно превышать 1.2 метра;

- расстояние между перегородками должно превышать 1.5 метра;

- ширина рабочего стола должна составлять от 80 до 140 см;

- глубина рабочего стола должна составлять от 80 до 100 см;

- высота рабочего стола должна быть равна 7.25 см;

- расстояние от глаз до монитора должно находиться в диапазоне от 60 до 70 см;

- расстояние от клавиатуры до края стола должно находиться в диапазоне от 10 до 30 см;

- сидение должно иметь регулировку по высоте, повороту спинки и углу наклона;

- подставка для ног должна иметь ширину от 30 см, глубину от 40 см и угол наклона до 20 градусов.

Схема правильной посадки за компьютером представлена на рисунке 33.

Рисунок 33 - Схема правильной посадки за компьютером



7.4 Нормативная база

Нормативное регулирование охраны труда при осуществлении трудовой деятельности за компьютерами осуществляется посредством следующих документов [10, c.68]:

Типовая инструкция ТОИ Р-45-084-01.

- СанПиН 2.2.2. / 2.4. 1340-03 (далее - СанПиН).

- ТК РФ.

- Приказ Минздравсоцразвития РФ № 302н.

- 426-ФЗ.

Вывод

В данном разделе представлены общие предложения по охране труда для рабочих мест в АПУ. Их соблюдение существенно повысит эффективность работы персонала и снизит вероятность поражения вредным фактором при нахождении на работе.



ЗАКЛЮЧЕНИЕ

В процессе выполнения работы был разработан проект медицинской информационной системы. В процессе проектирования медицинской информационной системы были выполнены следующие задачи:

- сделано описание предметной области;

- создана концептуальная модель предметной области;

- выделены проблемы предметной области;

- сформирована концепция медицинской информационной системы;

-разработана концептуальная модель медицинской информационной системы;

- разработана логическая модель медицинской информационной системы;

- описана база данных для МИС;

- сделано описание программной реализации;

- описаны предложения по охране труда;

Спроектированная медицинская информационная система решает следующие задачи:

1. Увеличено рабочее время за счет отсутствия заполнения документации (документы распечатываются из системы).

2. Уменьшен риск потери информации за счет ее дублирования в электронном и бумажном виде.

3. Пациентам больше нет необходимости длительное время проводить в очереди за счет существования электронной очереди номерков.

4. Пациентам больше не выдаются документы на руки в связи с ведением их в электронном виде.