В настоящее время одним из механизмов развития сферы регионального здравоохранения является реализация инновационно-инвестиционных социально-экономических проектов, направленных на поддержку малого предпринимательства в этой сфере [1-3]. Современные медицинские организации производят и накапливают большие объемы информации, как о сотрудниках, так и о пациентах. Врачам нужно следить за посещением пациентов, а пациентам – иметь возможность записаться на прием, не прилагая значительных усилий. От того насколько эффективно эта информация используется врачами, руководителями, управляющими органами, зависит качество медицинской помощи, общий уровень жизни населения, уровень развития страны в целом и каждого ее территориального субъекта в частности. Поэтому необходимость использования больших, и при этом еще постоянно растущих, объемов информации при решении диагностических, терапевтических, статистических, управленческих и других задач обуславливает сегодня создание информационных систем в медицинских учреждениях [3].
Существующие автоматизированные системы учета пациентов (например, [4,5]) ориентированы на крупные медицинские учреждения (больницы, поликлиники, санатории) и с точки зрения малого бизнеса обладают рядом недостатков, основным из которых является избыточность функций и, как следствие, сложность в освоении и высокая стоимость.
Целью работы является разработка информационной системы (ИС) поддержки работы регистратуры малого предприятия сферы здравоохранения (частной поликлиники), оказывающего медицинские услуги населению.
Проектирование информационной системы
На основе анализа средств моделирования бизнес–процессов было решено использовать среду BpWin, т.к. она имеет понятный интерфейс и поддерживает три методологии моделирования: IDEF0, IDEF3, и DFD, которые было решено использовать для моделирования бизнес–процессов работы регистратуры.
Сначала была создана контекстная диаграмма «Работа регистратуры поликлиники» в методологии IDEF0 (рисунок 1).
В управление вошли:
- Инструкции.
- Федеральные законы.
- Механизмами осуществления процесса являются:
- Пользователь.
- Компьютер.
- Входными данными являются данные пользователя. Результатом работы системы будут: талоны и карточки.
Рисунок 1 – Контекстная диаграмма IDEF0
После описания контекстной диаграммы проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема, при необходимости, разбивается на более мелкие и так далее до достижения нужной степени подробности.
Контекстная диаграмма была разбита на 4 блока (рисунок 2):
- Зарегистрироваться в системе.
- Войти в систему.
- Получить информацию.
- Использовать функции системы.
Рисунок 2 – Декомпозиция контекстной диаграммы
В свою очередь блок «Войти в систему» был декомпозирован в нотации IDEF3 на следующие работы (рисунок 3):
- Ввести данные.
- Проверить логин и пароль.
- Определить полномочия.
- Вывести ошибку.
При декомпозиции процессы был использован один перекресток вида исключающее ИЛИ. После ввода логина и пароля, система проверяет его достоверность и в зависимости от этого либо определяет полномочия в системе, либо выводит ошибку и дает возможность заново ввести данные.
Рисунок 3 – Декомпозиция блока «Войти в систему»
На рисунке 4 представлена диаграмма декомпозиции блока «Получить информацию» в нотации DFD. Она содержит хранилище данных «БД», внешнюю сущность «Пользователь» и три блока:
- Получение данных пользователя.
- Формирование списка доступных услуг.
- Вывод информации пользователю.На входе в процесс у нас информация о пользователе, а на выходе информация об услугах.
- С внешней сущностью «Пользователь» процесс связан исходящим сигналом «Информация об услугах». В хранилище «БД» поступают данные пользователя, а выходит список доступных услуг.
Рисунок 4 – Декомпозиция блока «Получить информацию»
В свою очередь блок «Использовать функции системы» декомпозирован в нотации IDEF3 (рисунок 5).
Рисунок 5 – Декомпозиция блока «Использовать функции системы»
Диаграмма содержит работы:
- Выбор функции.
- Запись на прием.
- Формирование талона.
- Создание карточки.
- Заполнение данных.
- Просмотр расписания.
- Запись в БД.
- Завершение работы.
Использовались три перекрестка вида исключающее ИЛИ. Они означают, что после завершения одного предыдущего процесса только один процесс запускается.
Построенные модели бизнес–процессов работы регистратуры дают достаточную информацию для дальнейшего проектирования моделей базы данных, а так же выполнения программной реализации информационной системы.
Логическая модель данных является визуальным представлением структур данных, их атрибутов и бизнес-правил. Логическая модель представляет данные таким образом, чтобы они легко воспринимались бизнес-пользователями. Построенная логическая модель данных в дальнейшем будет востребована на этапе физического проектирования, а также на этапе эксплуатации и сопровождения уже готовой системы, позволяя наглядно представить любые вносимые в базу данных изменения.
Общим способом представления логической модели БД является построение ER–диаграмм (Entity-Relationship, сущность-связь). В этой модели сущность определяется как дискретный объект, для которого сохраняются элементы данных, а связь описывает отношение между двумя объектами. Логическая модель базы данных представлена на рисунке 6.
Рисунок 6 – Логическая модель
База данных состоит из 11 таблиц: врачи, города, карточки пациентов, поликлиники, специализации, талоны, участки, прием, пользователи, тип пользователя и расписание. Таблицы соединены между собой связью «один ко многим».
Программная реализация информационной системы
На основе анализа инструментальных средств в качестве среды разработки выбрана среда Delphi 7 на языке Object Pascal. Из рассмотренных систем управления базой данных для создания информационной системы выбрана СУБД Paradox. Для оценки системы использовались критерии [5] с применением экспертных процедур [6]. Результаты оценивания, а также опытной эксплуатации исследовательского прототипа разработанной информационной системы учета пациентов малых предприятий сферы здравоохранения могут свидетельствовать о правомочности принятых проектных решений.