Автоматизация работы врача терапевта в городской поликлинике на основе спиралевидной модели внедрения информационных систем (часть 2)

Подробности

Опубликовано: 13.01.2022 09:00

Автор: Дудкин Дмитрий Игоревич

Просмотров: 2104

Аннотация: в статье проводится детальный анализ спиралевидной методологии внедрения систем, определяются требования и формулируется список требований, проектируются процессы и оргструктур в моделях AS-IS и TO-BE нотаций ARIS VACD и UML Activity Diagram. Для каждого витка в спиралевидной модели внедрения реализуются ключевые бизнес-процессы в среде MS Access, ведется тестирование и дается количественная оценка результатов испытания. Разработанная система позволяет упорядочить и систематизировать работу врача-терапевта. А это значительно повышает качество работы, ускоряет продолжительность приёма пациентов и сокращает очереди на прием к врачу.
Скачать: PDF (статья), PDF (выпуск №17).
Ключевые слова: АРМ врача поликлиники, автоматизация городской больницы, программы для клиник, цифровое здравоохранение, диджитализация медицины, жизненный цикл разработки ПО, цифровая карта пациента, ЭМК, электронная медкарта, амбулаторная карта пациента.

2.4. Архитектура данных разрабатываемой системы

Ссылка на 1-ю часть статьи. Используя процессы и данные выше, всю информацию можно разбить на классы, приведённые в таблице 2.1.

Таблица 2.1 Классы данных

Проведем процедуру нормализации данных [6]. Стандартно все данные приводят к третьей нормальной форме (НФ), нормализации такого уровня в проектах внедрения информационных систем бывает достаточно. После разделения всех данных на классы и проведения процедуры нормализации, получается нормализованная таблица с классами данных (табл.2.2) и архитектура данных разрабатываемого приложения, приведённая на рисунке 2.8.

Таблица 2.2 Классы данных (после нормализации)

Рис. 2.8. Архитектура данных для разрабатываемого приложения

2.5. Описание разрабатываемого приложения

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

Рис. 2.9. Интерфейс базы данных

Допустим, пользователь решил занести данные о новом пациенте, либо посмотреть информацию о пациенте. Для этого следует нажать на кнопку «Добавление и поиск пациента». На экране откроется окно с информацией о пациенте, которое представлено на рисунке 2.10.

Рис. 2.10. Интерфейс «Добавление и поиск пациента»

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

Рис. 2.11. Интерфейс «Добавление даты посещения»

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

Рис. 2.12. Интерфейс «Добавление причины посещения»

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

Рис. 2.13. Интерфейс «Добавить лечение пациента»

Если врач не может точно определить, в чём заключается причина болезни, то пациент направляется на сдачу анализов. Для этого врач-терапевт должен распечатать пациенту направление на анализ. Форма для печати представлена на рисунке 2.14.

Рис. 2.14. Интерфейс «Направление на анализ»

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

Рис. 2.15. Интерфейс «Анализ крови»

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

Рис. 2.16. Интерфейс «Реабилитация пациента»

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

Рис. 2.17. Схема программы

3. Разработка приложения

3.1. Первый прототип программы (I виток спирали)

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

Основным риском на данном этапе разработки программы являются возникновение проблем с электропитанием. При возникновении данной проблемы возможен сбой работы программы. Это может привести к отказу работы базы данных, а также не исключается возможность потери каких-либо данных. Для решения данной проблемы требуется иметь дополнительный источник электропитания/электричества. На рисунках 3.1-3.2 представлены фрагменты таблиц «Личные данные пациента» и «Дата посещения», созданные в программе MS Access.

Рис. 3.1. Фрагмент таблицы «Личные данные пациента»

Рис. 3.2. Фрагмент таблицы «Дата посещения»

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

Рис. 3.3. Реализованная схема данных

3.2. Второй прототип программы (II виток спирали)

На данном этапе реализовывается возможность просмотра данных, а также возможность изменения, удаления, внесения и поиска информации о пациенте, а также для печати (рисунки 3.4-3.5). Для чего создаётся «Форма» – объект, с помощью которого пользователи могут добавлять, редактировать и отображать данные. Основным риском на данном этапе разработки программы является человеческий фактор-невнимательность врача при внесении данных пациента. Со стороны пользователя ПО: врача, необходимо быть более внимательным при работе с персональными данными пациентов.

Рис. 3.4. Форма «Добавление пациента» с возможностью поиска, удаления, добавления пациентов и печати информации

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

3.3. Конечный продукт (III виток спирали)

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

Рис. 3.6. Экран для ввода пароля

Так же следует создать начальный интерфейс для ускорения приёма пациентов и упрощения работы пользователя (рисунок 3.7).

Рис. 3.7. Главное меню приложения

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

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

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

Кнопка «Анализ крови/мочи/кала» показывает форму с результатами анализов пациентов. В ней можно посмотреть информацию о результатах анализов для принятия решения о том, чем производить лечение пациента. Девятая кнопка «Реабилитация пациента» отображает информацию о том, как происходить реабилитация пациента. В случае осложнения/ухудшения состояния назначить новые лекарства.

4. Тестирование разработанного приложения

Тестирование программного обеспечения – процесс анализа программного продукта и сопутствующей документации с целью выявления недостатков в работе и повышения его качества [7]. Обычно для проверки работоспособности разработанной программы проводят три вида тестирования: функциональное, интеграционное и нагрузочное. Акцентируем внимание на последнем виде испытаний.

Нагрузочное тестирование проводилось для исследования быстродействия таких процессов, как, запись пациента на прием (поскольку этот процесс призван уменьшить время ожидания пациентов в очередях, то предполагается, что его выполнение не должно занимать много времени) и поиск записи. Для тестирования было выбрано следующее количество записей: 5 (в среднем посетителей за час работы), 50 ( в среднем посетителей за день) и 500 (в среднем посетителей на 2 недели). Результаты нагрузочного тестирования приведены в табл.4.1.

Вначале 5 раз проводится проверка отклика системы на различные действия, ее результаты вносятся в соответствующие строки столбцов t1-t5. Далее рассчитывается среднее арифметическое всех измерений по формуле (1):

                                                                                                                    (1)

Результат заносится в столбец «Среднее время отклика» таблицы ниже. Далее находятся соответствующие средние квадратические отклонения по формуле (2):

.                                           (2)

Погрешность измерений рассчитывалась по формуле (3), где n – число измерений, σ – доверительный коэффициент Стьюдента, равный 0.95, Δt_p – абсолютная погрешность электронного секундомера равная 0,005.

.                                            (3)

В столбце «Время отклика» дано итоговое время отклика согласно формуле (4):

.                                              (4)

Таблица 4.1 – Результаты нагрузочного тестирования

Как видно из табл. 4.1, время отклика не превышает 0,5 секунд и почти не замечается пользователем. Таким образом, можно сделать вывод, что нагрузочное тестирование проведено успешно.

5. Заключение

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

• проанализированы пользовательские требования (19 требований), полученные путем опроса и изучения документации. Определены приоритеты полученных требований;
• составлены функциональные требования, которые должны были быть реализованы в разрабатываемом приложении;
• список требований разделен на 1-3 приоритета разработки;
• составлены модели AS-IS и TO-для BE ключевых бизнес-процессов организации в нотациях ARIS VACD (0-1 уровни) и UML Activity Diagram (2-3 уровень);
• проведена разработка в среде MS Access, где поэтапно были реализованы все требования, исправлены недочеты и ошибки в работе программы;
• в финале было проведено нагрузочное тестирование для различного количества записей в БД, результаты которого свидетельствовали о высокой производительности программы. 

Литература 

1. А.В. Варзунов, Е.К. Торосян, Л.П. Сажнева. Анализ и управление бизнес-процессами: учебное пособие, 2010 – 212 с.
2. И.В. Абрамов. Методические указания по дисциплине «Модели и методы ин-формационно-управляющих систем». Ижевск, 2004 – 314 с.
3. Владимир Репин, Виталий Елиферов. Процессный подход к управлению. Моделирование бизнес-процессов. М.: Манн, Иванов и Фербер, 2013 – 215 с.
4. Ю.А. Ларина. Основы объектно-ориентированного моделирования с использованием языка UML: учебное пособие, Ярославль, 2010 – 152 с.
5. Дейт К. Дж. Введение в системы баз данных / пер. с англ. и ред. К. А. Птицына – 8-е изд. – М.: Вильямс – 2016. – 327 с.
6. Штенников Д.Г. Разработка информационных систем в образовании: учебное пособие. – СПб: СПбГУ ИТМО, 2012. – 242 с.

Выходные данные статьи

Дудкин Д.И. Автоматизация работы врача терапевта в городской поликлинике на основе спиралевидной модели внедрения информационных систем (часть 2) // Корпоративные информационные системы. – 2022. – №1 (17) – С. 1-18. – URL: https://corpinfosys.ru/archive/issue-17/183-2022-17-therapistautomation.

Об авторе

Дудкин Дмитрий Игоревич – студент 4-го курса кафедры оптических и биотехнических систем и технологий физико-технологического института РТУ МИРЭА. Тема выпускной квалификационной работы бакалавра «Автоматизация ключевого бизнес-процесса врача терапевта в городской поликлинике на основе спиралевидной модели внедрения информационных систем». Электронная почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Статьи выпуска №17

1. Автоматизация работы врача терапевта (часть 2);
2. Рабочий план счетов бухгалтерского учета в КИС;
3. Акт сверки взаимных расчетов;
4. ГОСТы в корпоративных информационных системах;
5. Автоматизация процессов транспортной логистики (часть 1).