Разработка подсистемы триажа пациентов на плановую операцию сердца в региональной медицинской информационной системе Тюменской области

Максим Попович

Разработка подсистемы триажа пациентов на плановую операцию сердца в региональной медицинской информационной системе Тюменской области

В работе представлен опыт разработки подсистемы триажа пациентов на плановую операцию сердца в региональной медицинской информационной системе Тюменской области с использованием машинного обучения. Были построены модели для прогнозирования периода пребывания пациента в стационаре и прогнозирования вероятности выздоровления. В работе также отражен опыт использования сервиса IBM Cloud Pak и применения градиентного бустинга.

Информатика

Диссертации

Вуз: Тюменский государственный университет (ТюмГУ)

ID: 60d2dfb1e4dde5000108b2e3

UUID: c9e65a70-b620-0139-3401-0242ac180005

Язык: Русский

Опубликовано: больше 3 лет назад

Просмотры: 138

21.76

Максим Попович

Тюменский государственный университет (ТюмГУ)

Комментировать 0

Рецензировать 2

Скачать - 2,9 МБ

Поделиться работой

МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное автономное образовательное учреждение высшего образования «ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ» ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК Кафедра программной и системной инженерии РЕКОМЕНДОВАНО К ЗАЩИТЕ В ГЭК Заведующий кафедрой Д.т.н., профессор ______________А.Г. Ивашко ___________________2021 г. ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА магистерская диссертация РАЗРАБОТКА ПОДСИСТЕМЫ ТРИАЖА ПАЦИЕНТОВ НА ПЛАНОВУЮ ОПЕРАЦИЮ СЕРДЦА В РЕГИОНАЛЬНОЙ МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЕ ТЮМЕНСКОЙ ОБЛАСТИ 09.04.03 Прикладная информатика Магистерская программа «Информационные системы анализа данных» Выполнил работу студент 2 курса очной формы обучения (Подпись) Попович Максим Михайлович (Подпись) Григорьев Михаил Викторович (Подпись) Макарихин Андрей Владимирович Научный руководитель к.т.н., доцент Рецензент руководитель отдела развития МИС, ООО «1С-Медицина-Регион» г. Тюмень, 2021

2 РЕФЕРАТ Выпускная квалификационная работа – 92 с., 4 ч., 59 рис., 29 табл., 8 листингов, 22 источн., 2 прил. РАЗРАБОТКА ПОДСИСТЕМЫ ТРИАЖА ПАЦИЕНТОВ НА ПЛАНОВУЮ ОПЕРАЦИЮ СЕРДЦА В РЕГИОНАЛЬНОЙ МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЕ ТЮМЕНСКОЙ ОБЛАСТИ Объектом исследования является региональная медицинская информационная система. Цель работы – повышение эффективности взаимодействия медицинского персонала с пациентами в медицинской информационной системе. Главная идея – создание собственного инструмента, решающего задачи организации триажа пациентов на операции в рамках РМИС ТО. Основная область применения системы – диагностика пациентов медицинской информационной системы перед оперативными вмешательствами. Работа была выполнена при использовании технологий: 1С:Предприятие 8.3, Python 3.7, IBM Cloud Pak, Uvicorn ASGI-Server, XGBoost, FastAPI. Результатом работы является разработанная подсистема триажа пациентов на операции с применением методов машинного обучения в области сердечных заболеваний. Поскольку в медицинской информационной системе ТО ежедневно вносится большое количество медицинских документов, регистрирующих состояния/показания пациентов, то развитие подсистемы триажа пациентов на операции имеет прогрессивный характер. Полное внедрение проекта требует тщательного анализа и проверок со стороны квалифицированных IT-экспертов и врачей. По теме выпускной квалификационной работы была написана статья и принята к публикации в межвузовском научном сборнике «Математическое и информационное моделирование» (входит в РИНЦ), выпуск 19.

3 ОГЛАВЛЕНИЕ ВВЕДЕНИЕ .................................................................................................................. 5 ГЛАВА 1. ИНФОРМАЦИЯ О ПРЕДПРИЯТИИ ООО «1С-МЕДИЦИНАРЕГИОН» ..................................................................................................................... 7 1.1. ОБЩИЕ СВЕДЕНИЯ ....................................................................................... 7 1.2. ИНФОРМАЦИЯ О ПРОДУКТЕ ПРЕДПРИЯТИЯ....................................... 8 1.3. РЕГЛАМЕНТ РАЗРАБОТКИ И ВНЕСЕНИЯ ИЗМЕНЕНИЙ В ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ .......................................................................... 8 ГЛАВА 2. ПОСТАНОВКА ЗАДАЧИ НА РАЗРАБОТКУ ПОДСИСТЕМЫ ТРИАЖА ПАЦИЕНТОВ НА ОПЕРАЦИИ ............................................................ 11 2.1. НАЗНАЧЕНИЕ ПОДСИСТЕМЫ ................................................................. 11 2.2. ЦЕЛИ И ЗАДАЧИ СОЗДАНИЯ ПОДСИСТЕМЫ ..................................... 11 2.3. СБОР ТРЕБОВАНИЙ К ПОДСИСТЕМЕ .................................................... 12 ГЛАВА 3. РЕАЛИЗАЦИЯ ПОДСИСТЕМЫ ТРИАЖА ПАЦИЕНТОВ НА ПЛАНОВУЮ ОПЕРАЦИЮ СЕРДЦА .................................................................... 15 3.1. ПРОЕКТИРОВАНИЕ ПОДСИСТЕМЫ ТРИАЖА ПАЦИЕНТОВ........... 15 3.1.1. ОБЩАЯ СТРУКТУРА ПОДСИСТЕМЫ .............................................. 15 3.1.2. КОМПОНЕНТЫ ПОДСИСТЕМЫ ........................................................ 16 3.1.2.1. МОДУЛЬ ПРОГНОЗИРОВАНИЯ НАГРУЗКИ КОЕЧНОГО ФОНДА ОТДЕЛЕНИЯ ............................................................................................. 16 3.1.2.2. МОДУЛЬ ОРГАНИЗАЦИИ ОЧЕРЕДИ ПАЦИЕНТОВ НА ОПЕРАЦИИ ............................................................................................................... 16 3.1.2.3. ВЕБ-СЕРВИС ПРОГНОЗИРОВАНИЯ .......................................... 17 3.2. ПОСТРОЕНИЕ МОДЕЛЕЙ МАШИННОГО ОБУЧЕНИЯ ....................... 18 3.2.1. МОДЕЛЬ «ПРОГНОЗИРОВАНИЕ ПЕРИОДА ПРЕБЫВАНИЯ ПАЦИЕНТА В СТАЦИОНАРЕ» ............................................................................. 18

4 3.2.2. МОДЕЛЬ «ПРОГНОЗИРОВАНИЕ ВЕРОЯТНОСТИ ВЫЗДОРОВЛЕНИЯ» ................................................................................................ 24 3.2.3. РАЗРАБОТКА ВЕБ-СЕРВИСА ДЛЯ ВЗАИМОДЕЙСТВИЯ ............ 33 3.2.4. РАЗМЕЩЕНИЕ ВЕБ-СЕРВИСА НА ВИРТУАЛЬНОМ СЕРВЕРЕ .. 37 3.3. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПОДСИСТЕМЫ В МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЕ ....................................... 38 3.3.1. МОДУЛЬ ПРОГНОЗИРОВАНИЯ НАГРУЗКИ КОЕЧНОГО ФОНДА ...................................................................................................................... 38 3.3.2. МОДУЛЬ ДЛЯ ОРГАНИЗАЦИИ ОЧЕРЕДЕЙ ПАЦИЕНТОВ НА ОПЕРАЦИИ ............................................................................................................... 46 ГЛАВА 4. АПРОБАЦИЯ И ТЕСТИРОВАНИЕ ..................................................... 78 4.1. ПРОВЕРКА РЕЗУЛЬТАТОВ ПРОГНОЗИРОВАНИЯ МОДЕЛЕЙ .......... 78 4.2. ТЕСТИРОВАНИЕ ВЕБ-СЕРВИСА ПРОГНОЗИРОВАНИЯ .................... 78 4.3. ТЕСТИРОВАНИЕ МОДУЛЯ ПРОГНОЗИРОВАНИЯ НАГРУЗКИ КОЕЧНОГО ФОНДА ОТДЕЛЕНИЯ ...................................................................... 80 ЗАКЛЮЧЕНИЕ ......................................................................................................... 87 БИБЛИОГРАФИЧЕСКИЙ СПИСОК ..................................................................... 89 ПРИЛОЖЕНИЕ ПОКАЗАТЕЛЕЙ 1. ДИАГРАММЫ ЗДОРОВЬЯ РАСПРЕДЕЛЕНИЯ МОДЕЛИ ЗНАЧЕНИЙ ПРОГНОЗИРОВАНИЯ ВЕРОЯТНОСТИ ВЫЗДОРОВЛЕНИЯ ................................................................... 91 ПРИЛОЖЕНИЕ 2. АЛГОРИТМ ДОБАВЛЕНИЯ ПАЦИЕНТА В ОЧЕРЕДЬ НА ОПЕРАЦИЮ .............................................................................................................. 92

5 ВВЕДЕНИЕ Высокая роль внедрения информационных систем находит свое применение в медицинской сфере. Это подтверждается одним из восьми федеральных проектов, посвящённого цифровой медицине, национального проекта «Здравоохранение», который был разработан в целях выполнения майского указа Президента РФ «О национальных целях и стратегических задачах развития Российской Федерации на период до 2024 года» [1]. Автоматизация процессов, протекающих в жизнедеятельности объектов здравоохранения, существенно повышает эффективность их работы, что напрямую влияет на качество медицинского обслуживания пациентов. Оснащение медицинских учреждений качественным и современным программным обеспечением позволяет упростить задачу хранения и обработки большого количества данных, требуемых для качественного обслуживания пациентов. Вследствие этого, продуктивность врачебного персонала повышается и большинство внутренних процессов протекают без участия человека на основе автоматизации. Находят свое применение и современные технологии интеллектуального анализа данных. Подтверждением этому является внедрение на федеральном уровне вертикально-интегрированной медицинской информационной системы (ВИМИС) с 2020 года. На данный момент, одна из задач ВИМИС в области анализа данных – это прогнозирование онкологических заболеваний, но повсеместно ВИМИС захватывает и другие медицинские области. Данная работа выполнялась на базе предприятия ООО «1С-МедицинаРегион», деятельность которой связана с разработкой и поддержкой региональной медицинской информационной системы. В региональной медицинской информационной системе Тюменской области, начиная с 2015 года, накопился достаточный объем данных, нуждающихся в изучении и их анализе. Ранее, уже применялся экспериментальный опыт разработки модели машинного обучения, связанный с оценкой рисков сердечно-сосудистых заболеваний. Точность построенной модели составила 97%. Со временем открываются новые области и идеи для применения интеллектуального анализа

6 данных. Прежде всего, они достигаются путем общения напрямую с пользователями системы – врачебным персоналом. Но следует понимать, что медицина – сложная и важная область в нашей жизни, и применение таких новшеств должно происходить осознано. Использование результатов машинного обучения должно носить рекомендательный характер. Подсистема позволит обеспечить врачей вспомогательным инструментом для принятия решений при планировании работы отделения и организации плана лечения пациента. Поэтому, было принято решение о разработке и внедрении собственной подсистемы триажа пациентов на операции, которая позволила бы решать индивидуальные задачи планирования и организации работы отделения. Для успешной подготовки и защиты выпускной квалификационной работы автором ВКР использовались средства и методы физической культуры и спорта с целью поддержания должного уровня физической подготовленности, обеспечивающую высокую умственную и физической работоспособность. В режим рабочего дня включались различные формы организации занятий физической культурой (физкультпаузы, физкультминутки, занятия избранным видом спорта) с целью профилактики утомления, появления хронических заболеваний и нормализации деятельности различных систем организма. В рамках подготовки к защите выпускной квалификационной работы автором созданы и поддерживались безопасные условия жизнедеятельности, учитывающие возможность возникновении чрезвычайных ситуаций.

7 ГЛАВА 1. Информация о предприятии ООО «1С-Медицина-Регион» 1.1. Общие сведения Ресурсный центр «1С – Медицина – Регион» создан лидером российского рынка программного обеспечения фирмой «1С» совместно с ведущим партнёром в тюменском регионе ООО «Тюмень-Софт». Основная специализация – разработка и внедрение программного обеспечения в сфере здравоохранения. Юридическая информация предприятия приведена в таблице 1. Таблица 1 Юридическая информация предприятия Реквизит Значение Наименование ООО "1С-Медицина-Регион" Юридический адрес 625000, г.Тюмень, ул.Мельникайте 101А, каб.404 ОГРН 1167232081730 ИНН 7203395572 КПП 720301001 Электронная почта info@1cmr.ru Телефон +7 (3452) 680-975 В рамках организации работы ООО «1С-Медицина-Регион» главным звеном, координирующим работу по контракту, является департамент проектов. В подчинении департамента проектов находятся отдел администрирования, отдел внедрения учетных систем, отдел разработки, отдел развития МИС, отдел сопровождения МИС и отдел тестирования. Дипломная работа выполнялся в рамках отдела развития МИС. Основной продукт предприятия – это медицинская информационная система, которая объединяет все ресурсы медицинской организации: лечебнодиагностические, финансово-экономические, административные.

8 1.2. Информация о продукте предприятия В медицинской информационной системе, рассматриваются процессы автоматизации документооборота для лечебно-профилактических учреждений, которые включают в себя: − электронные медицинские карты о пациентах; − системы поддержки принятия медицинских решений; − данные медицинских исследований в цифровой форме; − средства оперативного обмена информацией между сотрудниками; − финансовая и административная информация. Основные пользователи системы: медицинские работники, руководители и органы управления здравоохранением. Система позволяет управлять всеми ресурсами лечебно-профилактических учреждений и собирать аналитико-статистическую информацию в необходимых срезах для принятия эффективных управленческих решений в отрасли здравоохранения на уровне региона. Ключевое преимущество системы заключается в интеграции медицинской части с модулями складского и бухгалтерского учета, модулем расчета заработной платы, модулем диетпитания, что позволяет создать комплексную систему, охватывающую все ресурсы медицинского учреждения, а также интеграцию с лабораторными системами. Создаваемые решения хорошо адаптируются под запросы пользователей, масштабируются и обеспечивают соблюдения законодательства в части защиты персональных данных. Среда разработки информационной системы – 1С:Предприятие 8.3 [22]. 1.3. Регламент разработки и внесения изменений в программное обеспечение В процессе разработки и изменения программного обеспечения используются несколько ролей: оператор, методологический центр, участники

9 системы (медицинские организации Тюменской области, использующие Систему для автоматизации своей деятельности) и исполнитель. Разработка осуществляется только по задачам, поставленным Операторам и зафиксированным в ИСУП (информационной системе управления проектами). Оператор при постановке задач руководствуется Регламентом управления изменениями и обеспечивает согласование задач, приоритетов с рабочей группой по развитию РС ЕГИСЗ (региональный сегмент единой государственной информационной системы в сфере здравоохранения). По каждой задаче перед ее реализацией должны быть собраны и согласованы детальные требования. Требования к реализации задачи прикрепляются в ИСУП. Схема данного процесса отображена на рисунке 1. Рис. 1. Схема процесса получения задач для разработки Разработка осуществляется Исполнителем. При разработке используется рекомендованная 1С «Технология разветвленной разработки конфигураций». Разработка ведется с использованием хранилища [20], в отдельных копиях информационных баз (базы для разработки). Для каждого разработчика создается свой экземпляр базы данных, все однотипные базы подключаются к одному хранилищу конфигураций 1С. После реализации определенного функционала, изменения помещаются в хранилище. Каждый релиз должен иметь номер заявки и описание в комментарии. Работа над задачами разбивается на 2х недельные спринты. Перечень задач на спринт определяется до его начала,

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

11 ГЛАВА 2. Постановка задачи на разработку подсистемы триажа пациентов на операции 2.1. Назначение подсистемы Подсистема триажа пациентов на плановые операции с использованием интеллектуального анализа данных предназначена для медицинской сортировки пациентов, ожидающих проведения оперативных вмешательств, с учетом их первичных показателей здоровья и других значимых факторов. Главная идея подсистемы – создание инструмента для организации электронной очереди на операции с применением машинного обучения. 2.2. Цели и задачи создания подсистемы Целью создания данной подсистемы является повышение эффективности взаимодействия медицинского персонала с пациентами в медицинской информационной системе. Понятие «эффективность» включает в себя три ключевых показателя: − уменьшение затрачиваемого времени на регистрацию пациента для проведения оперативных вмешательств; − повышение пропускной способности отделения; − сокращение числа промежуточных бюрократических этапов от первичного приема до проведения операции; Для достижения поставленной цели были определены следующие задачи: − создание модели для прогнозирования периода пребывания пациента в стационаре; − создание модели для прогнозирования вероятности выздоровления пациента; − разработка и размещение веб-сервиса прогнозирования; − разработка модуля прогнозирования нагрузки коечного фонда отделения; − разработка модуля организации очередей пациентов на оперативные вмешательства.

12 2.3. Сбор требований к подсистеме Перед разработкой подсистемы было проведено интервьюирование медицинского персонала, который будет работать с системой. В ходе обсуждения были выявлены необходимые требования к подсистеме и составлена контекстная диаграмма (см. рис. 3). Были выявлены четыре роли пользователей, которые будут непосредственно работать с подсистемой – врач, заведующий отделением, главный врач (руководители МО) и сотрудник МИАЦ. Главный врач и МИАЦ получают из системы отчеты в срезе МО, отделений, номенклатур медицинских услуг (НМУ) и по полисам (ОМС, ДМС и т.д.), также главный врач может просматривать прогнозы нагрузки на отделения. Добавлением пациентов и изменением их номеров в очереди занимаются врач и заведующий отделением. Заведующий имеет дополнительную возможность исключать пациентов из очереди и прогнозировать нагрузку на отделение. Рис. 3. Контекстная диаграмма подсистемы триажа пациентов на операции Пользовательские требования отражены с помощью дерева функции (см. рис. 4).

13 Рис. 4. Дерево функций с пользовательскими требованиями Полный список требований к подсистеме был сформирован следующий: − ведение отдельных очередей в разрезе НМУ и типов очередей (плановая, экстренная); − просмотр текущей очереди пациентов на операцию с выводом дополнительных сведений о пациенте (состояние, возраст, пол, «рейтинг», участие в «рейтинге», порядковый номер добавления в очередь); − просмотр вычисленного «рейтинга» пациента; − просмотр плановой/экстренной очереди; − добавление пациентов в очередь; − исключение пациентов из очереди; − изменение у пациента номера в очереди; − установка отметки у пациента «Не участвует в рейтинге»; − проведение пересчета «рейтинга» пациента; − при добавлении, изменении, исключении пациента в очереди регистрация истории;

14 − подпись документов изменения очереди с помощью ЭЦП; − хранение очередей на операции в системе МИС для возможности просмотра из сторонних МО; − формирование отчетов в разрезе МО, отделений, пациентов, врачей, операций, НМУ, полисам (ОМС, ДМС и т.д.); − печать списка текущих пациентов на операцию в соответствии с установленной печатной формой; − поиск пациентов в списке по выведенным столбцам; − вывод списка текущих пациентов на операцию в текстовый документ; − просмотр нагрузки на коечный фонд отделения; − выполнение прогноза нагрузки на коечный фонд отделения на определенную дату; − просмотр списка пациентов в отделении на дату прогноза; − просмотр прогнозируемого периода пребывания пациента в стационаре по каждому пациенту; − учет резервных мест при прогнозировании нагрузки по отделениям; − изменение процента резервных мест отделения.

15 ГЛАВА 3. Реализация подсистемы триажа пациентов на плановую операцию сердца 3.1. Проектирование подсистемы триажа пациентов 3.1.1. Общая структура подсистемы Подсистема триажа пациентов на плановые операции – это подсистема, предназначенная для организации электронной очереди и прогнозирования состояния коечного фонда по отделениям с применением методов интеллектуального анализа данных. Данная система является модульной, работа которых может не зависеть друг от друга [4]. Обработка и хранение полученных данных из моделей машинного обучения производится внутри медицинской информационной системы (МИС) на базе платформы 1С. Функционирование моделей ML находится вне контура МИС. На рисунке 5 изображена общая схема разрабатываемой подсистемы триажа пациентов. Рис. 5. Общая схема структуры подсистемы триажа пациентов

16 3.1.2. Компоненты подсистемы 3.1.2.1. Модуль прогнозирования нагрузки коечного фонда отделения Данный модуль предназначен для прогнозирования загруженности отделения по количеству занятых и свободных коечных мест. При прогнозировании собирается первичная информация по каждому пациенту, который находится на лечении в стационаре и по результатам, формируется возможное состояние коечного фонда на указанную дату прогноза. Пациенты в отделение могут поступать несколькими способами: планово, экстренно и путем перевода из других отделений. Для обеспечения запаса мест для экстренных пациентов, модуль учитывает процент резервных коек по каждому из отделений. Наглядная схема работы изображена на рисунке 6. Рис. 6. Схема работы модуля прогнозирования состояния коечного фонда 3.1.2.2. Модуль организации очереди пациентов на операции Работа данного модуля направлена на обеспечение локального инструмента МИС, предназначенного для организации очереди пациентов на различные операции. Ответственное лицо имеет возможность использовать модуль как вручную, так и в автоматическом режиме, с помощью оценки «рейтинга» пациента обученной моделью машинного обучения. При добавлении

17 пациента в очереди, по нему собирается первичная информация, необходимая для прогноза вероятности его выздоровления и его периода пребывания в стационаре. Затем, данные передаются в модели, которые возвращает результат в виде вероятности выздоровления пациента и периода его пребывания в стационаре. По окончанию, результирующая функция вычисляет «рейтинг» пациента и назначает ему номер в очереди. Ответственное лицо, или врач, может скорректировать итоговый результат, и добавить пациента в очередь вручную. Общая схема работы модуля представлена на рисунке 7. Рис. 7. Схема работы модуля организации очереди пациентов на операцию 3.1.2.3. Веб-сервис прогнозирования Модели машинного обучения находятся вне контура МИС. Веб-сервис предоставляет доступ к моделям посредством API-интерфейса. Описанные ранее модули обращаются к сервису с помощью POST-запроса, передавая перечень необходимых входных параметров и получают результат в формате JSON. Инструменты реализации описаны в п. 3.2.3. На рисунке 8 отражена схема работы данного модуля.

18 Рис. 8. Схема работы веб-сервиса прогнозирования 3.2. Построение моделей машинного обучения 3.2.1. Модель «Прогнозирование периода пребывания пациента в стационаре» 1. Сбор данных Поскольку основной задачей данной модели является прогнозирование периода пребывания пациента в стационаре, то был собран ряд данных, связанных непосредственно с его госпитализацией. Сбор данных осуществлялся в разрезе случаев (медицинских карт). Данные выгружались с рабочей базы Областной клинической больницы №1 города Тюмени по кардиохирургическому отделению в период с 1 января 2018 года. Данные пациентов были деперсонифицированы путем выгрузки их системных идентификаторов. В МИС, на данный момент, записывается большой объем данных по пациенту в период его лечения в стационаре, но для решения данной задачи было принято решение выделить следующий ряд данных, загружаемых из МИС (см. табл. 2).

19 Таблица 2 Выгружаемые данные из МИС для модели прогнозирования времени пребывания Наименование признака Тип Пол Текст Дата рождения Дата Дата госпитализации Дата Диагнозы Текст Дата выписки Дата Дальнейшая обработка данных для обучения модели осуществлялась в среде Python, с использованием библиотек: Pandas [14] и LabelEncoder [13]. Признак «Пол» был преобразован в категориальный признак «SEX» по принципу: «0» – женский пол, «1» – мужской пол. Большинство записей (около 67%) принадлежит мужскому полу. Распределение значений по этому признаку представлено в виде диаграммы на рисунке 9. Рис. 9. Распределение исходных данных по признаку «Пол» Признак «Дата рождения» преобразован в непрерывный признак «AGE» (возраст). Большая часть пациентов относится к возрастной группе от 50 до 70 лет. Распределение значений по этому признаку отражено в диаграмме (см. рис. 10).

20 Рис. 10. Распределение исходных данных по признаку «Возраст» Признак «Дата госпитализации» был преобразован в категориальный параметр «MONTH_OF_HOSPITALIZATION» (месяц госпитализации), закодированный по порядковому номер месяца в году. Все значения распределены равномерно, но в наиболее популярными являются летние и осенние месяцы. На диаграмме отображено распределение значений (см. рис. 11). Рис. 11. Распределение исходных данных по признаку «Месяц госпитализации» Признак «Дата выписки» изначально был преобразован в непрерывный признак «Время пребывания в стационаре» путем нахождения разности между двумя датами: госпитализации и выписки, а затем был сформирован новый признак «TIME_OF_HOSPITALIZATION_INTERVAL», который разделен на 3 класса: «до 5 дней», «от 5 до 14 дней», «от 14 дней». Разделение на такие классы

21 было согласовано с заказчиком. Этот признак, в дальнейшем будет являться целевым. Его значения распределены примерно в равных пропорциях (см. рис. 12). Рис. 12. Распределение исходных данных по признаку «Период госпитализации» В МИС диагнозы хранятся в международном формате МКБ-10 [8]. Например, диагноз с кодом «I21.3», подразумевает под собой острый трансмуральный инфаркт миокарда неуточненной локализации. При обсуждении возможных вариантов преобразования этого параметра с врачебным персоналом, было принято решение подсчитывать количество диагнозов по родительскому диагнозу в рамках одного случая. Т.е. был взят только родительский диагноз до точки, в результате из кода «I21.3» был получен диагноз «I21». Количество уникальных значений диагноза составило – 474 родительских кодов МКБ-10. Распределение диагнозов выглядит следующим образом (см. рис. 13).

22 Рис. 13. Распределение исходных данных по признаку «Диагнозы» Далее, с помощью Dummy-кодирования, для данного признака были созданы N новых признаков по шаблону «DIAGNOSIS_%диагноз%», где N – число уникальных диагнозов из выборки и %диагноз% – один из уникальных диагнозов. В результате, получили для каждого случая (медицинской карты) одну выходную строку (см. рис. 14). Рис. 14. Пример выходной строки по каждому пациенту По окончанию предобработки, было получено 5430 записей. Количество признаков – 495. 2) Построение модели Для экспериментального моделирования использовалась платформа IBM Cloud Pak for Data [12]. С помощью этой платформы можно упростить все этапы создания модели, благодаря доступному облачному сервису и наглядному интерфейсу. В качестве тестируемых алгоритмов были выбраны классификаторы дерево решений, случайный лес и градиентный бустинг [2]. Первые два алгоритма не показали хороших результатов, например у классификатора случайного леса были выявлены такие оценочные результаты (см. рис. 15).

23 Рис. 15. Оценка «плохой» построенной модели Наиболее оптимальные показатели показал последний алгоритм – градиентный бустинг, поэтому было принято решение выбрать его в качестве основного и подбирать гиперпараметры относительно него. Для повышения точности модели важную роль сыграл параметр «Максимальная глубина» (max_depth), поскольку в исходном наборе данных большое количество признаков. Итоговые гиперпараметры модели получились следующие (см. табл. 3). Таблица 3 Гиперпараметры градиентного бустинга модели прогнозирования времени пребывания Гиперпараметр Описание Значение n_estimators Число деревьев 100 eta Размер шага 0,3 gamma Минимальное значения loss изменение 0 функции для разделения листа на поддеревья max_depth Максимальная глубина дерева 30 lambda L2 регуляризация 1 alpha L1 регуляризация 1 В результате, модель показала хорошую точность, процент правильно определенных классов на обучающей выборке составил 85.43%, на тестовой –

24 84.3% (см. рис 16). Соотношение обучающей и тестовой выборки – 90 и 10% соответственно. Рис. 16. Процент правильных прогнозирований «успешной» модели Матрица ошибок обучающей и тестовой выборки представлена на рисунке 17. Рис. 17. Матрица ошибок «успешной» модели 3.2.2. Модель «Прогнозирование вероятности выздоровления» 1) Сбор данных Прогнозирование вероятности выздоровления пациента должно иметь высокую точность, поскольку от этого зависит план лечения пациента. На данный момент, в МИС содержится большой объем неструктурированных медицинских документов, данные которых вводятся врачами в свободной форме. С недавнего времени происходит внедрение вертикально- интегрированной медицинской системы на федеральном уровне, которая предназначена для сбора структурированных сведений по пациентам. Поэтому, сейчас правильно подготовленных данных не так много, и в рамках данной

25 работы было принято решение, провести эксперименты с имеющимися параметризированными данными – показателями здоровья пациента по общему анализу крови (ОАК). Задача данной модели заключалась в бинарной классификации пациентов по признаку «Выздоровление» (да/нет). В качестве предиктора выздоровления, по результатам обсуждения с врачебным персоналом, было принято решение использовать значение фракции выброса левого желудочка (ФВЛЖ). Данный параметр эхокардиографии отвечает за процент выброса крови в сосуды из левого желудочка сердца. ФВЛЖ стандартизирован и имеет интервал значений нормы (см. табл. 4). Таблица 4 Норма фракции выброса левого желудочка ФВЛЖ Интерпретация > 55% Норма 45 – 55 % Ниже нормы < 40% Сердечная недостаточность Так как главная задача модели состоит в бинарной классификации, то было принято решение преобразовать данный показатель в бинарный признак «Выздоровление» (1 – да, 0 – нет). К выздоровлению относятся те случаи, в которых ФВЛЖ перед выпиской находится в норме (> 55%). Для подготовки данных для обучения модели была произведена выгрузка с рабочей базы ОКБ-1 за период с 1 января 2018 года по всем пациентам, у которых имелся медицинский документ «Протокол эхокардиографии» и присутствуют показатели здоровья по ОАК и диастолического/систолическое давления перед выпиской. Полный список выгружаемых признаков приведен в таблице 5. показания

26 Таблица 5 Выгружаемые данные из МИС для модели прогнозирования вероятности выздоровления Наименование признака Тип Пол Текст Дата рождения Дата Вид транспортировки Текст Статус СПИД Текст Статус сифилис Текст Статус гепатит Текст Состояние Текст Срочность госпитализации Текст Диагнозы Текст Диастолическое давление Число Систолическое давление Число Процент эозинофилов Число Гематокрит Число Процент базофилов Число Процент моноцитов Число Процент лимфоцитов Число Процент нейтрофилов Число Базофилы Число Эозинофилы Число Лимфоциты Число Моноциты Число Нейтрофилы Число Тромбокрит Число Средний объем тромб Число Относительная ширина Число распределения тромбоцитов Ширина распределения Число эритроцитов Тромбоциты Число

27 Продолжение таблицы 5 Средняя концентрация Число гемоглобина в эритроците Среднее содержание Число гемоглобина в эритроците Средний объем эритроцита Число Гемоглобин Число Эритроциты Число Лейкоциты Число Процент незрелых Число гранулоцитов Незрелые гранулоциты Число СОЭ по методу Вестергрена Число ФВЛЖ Число Признак «Пол» был также как и в первой модели преобразован в категориальный признак «SEX» по принципу: «0» – женский пол, «1» – мужской пол. Также как и в первой модели, преобладают пациенты мужского пола. Распределение значений представлено на рисунке 18. Рис. 18. Распределение исходных данных по признаку «Пол» Аналогично, признак «Дата рождения» преобразован в непрерывный признак «AGE» (возраст). Аналогично первой модели, большинство пациентов возрастом от 50 до 70 лет (см. рис. 19).

28 Рис. 19. Распределение исходных данных по признаку «Возраст» Признаки «Вид транспортировки» (см. табл. 6), «Состояние» (см. табл. 7), «Срочность госпитализации» (см. табл. 8) преобразованы в категориальные. Таблица 6 Кодирование признака «Вид транспортировки» Код признака Значение 0 Может идти 1 На каталке 2 На кресле Таблица 7 Кодирование признака «Состояние» Код признака Значение 0 Крайне тяжелое 1 Тяжелое 2 Удовлетворительное Таблица 8 Кодирование признака «Срочность госпитализации» Код признака Значение 0 Планово 1 Экстренно Большинство пациентов поступало в плановом порядке, в удовлетворительном состоянии и способными передвигаться самостоятельно.

29 Распределение значений в этих поле «Вид транспортировки» представлено на рисунке 20, «Состояние» – на рисунке 21, «Срочность госпитализации» – на рисунке 22. Рис. 20. Распределение исходных данных по признаку «Вид транспортировки» Рис. 21. Распределение исходных данных по признаку «Состояние»

30 Рис. 22. Распределение исходных данных по признаку «Срочность госпитализации» От признаков «Статус СПИД», «Статус сифилис», «Статус гепатит» было принято решение отказаться, поскольку нет точной достоверности о корректности их заполнения и в дальнейшем, при экспериментах моделирования, было замечено что их использование снижает точность модели. Показатели здоровья не изменялись и не преобразовывались. Диаграммы распределения значений всех показателей здоровья представлены в приложении 1. Диагнозы были обработаны тем же способом, что и в первой модели (см. п. 3.2.1). Количество уникальных диагнозов – 345. На диаграмме представлено распределение значений, полученное по данному признаку (см. рис. 23). Рис. 23. Распределение исходных данных по признаку «Диагнозы»

31 ФВЛЖ, как уже было указано ранее, преобразован в бинарный классовый признак «Выздоровление» (1 – да, 0 – нет). В небольшой степени преобладают выздоровевшие пациенты. Распределение значений представлено на рисунке 24. Рис. 24. Распределение исходных данных по признаку «Выздоровление» В результате было выгружено 1023 записи с 382 признаками. 2) Построение модели Моделирование производилось так же, как и с первой моделью, с помощью сервиса IBM Cloud Pak for Data [12]. В качестве алгоритма был выбран – градиентный бустинг [2]. В результате, модель показала хорошую точность, процент правильно определенных классов на обучающей выборке составил 90,74%, на тестовой – 91,63% (см. рис 25). Соотношение обучающей и тестовой выборки – 90 и 10% соответственно.

32 Рис. 25. Процент правильных прогнозирований «успешной» модели Матрица ошибок обучающей и тестовой выборки представлена на рисунке 26. Рис. 26. Матрица ошибок «успешной» модели» Показатели AUC составили 0,887 для обучающей выборки и 0,906 для тестовой (см. рис. 27). Рис. 27. Показатели AUC для «успешной» модели Итоговые гиперпараметры приведены в таблице 9.

33 Таблица 9 Гиперпараметры градиентного бустинга модели прогнозирования вероятности выздоровления Гиперпараметр Описание Значение n_estimators Число деревьев 100 eta Размер шага 0,3 gamma Минимальное значения loss изменение 0 функции для разделения листа на поддеревья max_depth Максимальная глубина дерева 15 lambda L2 регуляризация 1 alpha L1 регуляризация 0 3.2.3. Разработка веб-сервиса для взаимодействия Полученные модели были повторно реализованы вручную в среде Python 3.7 для создания веб-сервиса, позволяющего взаимодействовать с МИС. Для реализации метода градиентного бустинга использовалась общедоступная библиотека XGBoost 0.90 [19]. Обученные модели экспортировались в файл формата .pkl с помощью библиотеки Pickle [15]. Для реализации API интерфейса использовался фреймворк FastAPI [10]. Доступ к каждой модели реализован в отдельных методах. Модель прогнозирования времени пребывания в стационаре доступна по адресу «/get_predict_interval_of_hospitalization», а для прогнозирования вероятности выздоровления «/get_predict_prob_of_healing» (см. рис. 28). Взаимодействие с моделями происходит посредством POST-запросов, принимающих на вход JSON определенной структуры. Перечень полей для метода получения прогноза времени пребывания в стационаре приведен в таблице 10, для прогноза вероятности выздоровления в таблице 11.

34 Рис. 28. Схема работы веб-сервиса прогнозирования Параметр "Обязательность" определяет количество возможных значений параметра. Возможны следующие значения: 0..1 – параметр является необязательным, допустима передача одного значения; 0..* – параметр является необязательным, количество передаваемых значений не ограничено; 1..1 – параметр является обязательным, допустима передача одного значения; 1..* – параметр является обязательным, количество передаваемых значений не ограничено. Таблица 10 Входные данные: «get_predict_interval_of_hospitalization» № Параметр Обязательность Описание Тип параметра 1 SEX 1..1 Пол string 2 AGE 1..1 Возраст int 3 MONTH_OF_HOSPITALIZATION 1..1 Месяц string госпитализации 4 DIAGNOSIS 1..1 Диагнозы Diagnosis

35 Продолжение таблицы 10 Тип: Diagnosis 4.1 DIAGNOS 1..* Код диагноза string МКБ-10 Таблица 11 Входные данные: «get_predict_prob_of_healing» № Параметр Описание Обязательность параметра Тип 1 SEX 1..1 Пол string 2 AGE 1..1 Возраст int 3 TRANSPORTATION 1..1 Вид string транспортировк и 4 GENERAL_STATE 1..* Общее string состояние 5 URGENCY_OF_HOSPITALIZATI 1..1 DIA string госпитализации ON 6 Срочность 1..1 Диастолическое int давление 7 SIS 1..1 Систолическое int давление 8 EOS_PERC 1..1 Процент double эозинофилов 9 HCT 1..1 Гематокрит double 10 BASO_PERC 1..1 Процент double базофилов 11 MONO_PERC 1..1 Процент double моноцитов 12 LYM_PERC 1..1 Процент double лимфоцитов 13 NEU_PERC 1..1 Процент double нейтрофилов 14 BASO 1..1 Базофилы double

36 Продолжение таблицы 11 15 EOS 1..1 Эозинофилы double 16 LYM 1..1 Лимфоциты double 17 MONO 1..1 Моноциты double 18 NEU 1..1 Нейтрофилы double 19 PCT 1..1 Тромбокрит double 20 MPV 1..1 Средний объем double тромб 21 PDW 1..1 Относительная double ширина распределения тромбоцитов 22 RDW_CV 1..1 Ширина double распределения эритроцитов 23 PLT 1..1 Тромбоциты double 24 MCHC 1..1 Средняя double концентрация гемоглобина в эритроците 25 MCH 1..1 Среднее double содержание гемоглобина в эритроците 26 MCV 1..1 Средний объем double эритроцита 27 HGB 1..1 Гемоглобин double 28 RBC 1..1 Эритроциты double 29 WBC 1..1 Лейкоциты double 30 IG_PERC 1..1 Процент double незрелых гранулоцитов

37 Продолжение таблицы 11 31 IG 1..1 Незрелые double гранулоциты 32 SOE 1..1 СОЭ по методу double Вестергрена 33 DIAGNOSIS 1..1 Диагнозы Diagnosi s Тип: Diagnosis 33. DIAGNOS 1..* Код диагноза string МКБ-10 1 Выходные данные веб-сервиса передаются также в виде строки. Для метода прогнозирования времени пребывания в стационаре возвращается одно из трех значений: до 5 дней, от 5 до 14 дней или от 14 дней. Для метода прогнозирования вероятности выздоровления возвращается числовое значение с вероятностью того, что пациент выздоровеет. 3.2.4. Размещение веб-сервиса на виртуальном сервере Для бесперебойного доступа к моделям интеллектуального анализа было принято решение разместить разработанный веб-сервис на виртуальном сервере. Характеристики сервера: CentOS 7, 15 GB SSD NVMe, 1 ядро CPU 2.35 GHz, 1 GB RAM DDR4. Используемый веб-сервер – ASGI server Uvicorn [9] с использованием uvloop [18] и httptools [11]. Адрес сервера – 95.142.38.101, порт на котором запущен веб-сервер Uvicorn – 8000. Отладка запросов осуществлялась с помощью утилиты Postman [17].

38 3.3. Разработка программного обеспечения подсистемы в медицинской информационной системе 3.3.1. Модуль прогнозирования нагрузки коечного фонда 1) Алгоритм функционирования модуля Инициатором работы алгоритма является пользователь. Для выполнения прогноза необходимо выбрать отделение, по которому будет производиться сбора данных о текущих пациентах и непосредственно, сама дата, на которую необходимо узнать загруженность палат. После выбора необходимых данных, модуль осуществляет сбор информации по текущим пациентам в отделении и выводит их список на форму. Вместе с этим, производится подсчет количества занятых/свободных коек с вычетом резервных мест, которые устанавливаются индивидуальной настройкой для каждого подразделения (отделения) больницы. После сбора необходимых данных для выполнения прогноза (пол, возраст, месяц госпитализации и диагнозы). Модуль формирует запросы к веб-сервису, на котором размещены обученные модели. Веб-сервис возвращает ответ в виде периода, который отражает какое количество дней пациент проведет в стационаре. Полученные данные обрабатываются на стороне модуля, формируется список без тех пациентов, которые будут выписаны из стационара и также выводится количество занятых и свободных коек на дату прогноза с учетом резерва. Диаграмма процесса, построенная в нотации Cross-Functional Flowchart [21], отображена на рисунке 29.

39 Рис. 29. Алгоритм прогнозирования нагрузки коечного фонда в отделении 2) Реализация объектов метаданных модуля внутри МИС Для обеспечения работы модуля необходимо было спроектировать структуру объектов метаданных таким образом, чтобы выполнялись основные парадигмы объектно-ориентированного программирования. Прежде всего, был реализован общий модуль «тмб_ПрогнозированиеВремениПребыванияВСтационаре», который позволяет обращаться к обученной модели машинного обучения прогнозирования периода пребывания в стационаре на стороннем веб-сервисе. Перечень функций и процедур, реализованных в этом модуле приведен в таблице 12.

40 Таблица 12 Перечень основных процедур и функций модуля прогнозирования нагрузки коечного фонда в отделении Наименование Тип Вход Выход Описание ВыполнитьПрогноз Функция Медицинска РезультатПрогн Главная функция, ирование (экспорт) яКарта озирования которая вызывается (ссылка) (строка) из других модулей. Из этой функции осуществляется вызов других функций и процедур необходимых для прогнозирования ПолучитьПервичн Функция Медицинска Таблица Функция, ыеДанные (экспорт) яКарта предназначенная для значений (ссылка) сбора данных первичных пациента: пол, возраст, месяц госпитализации ПолучитьСписокД Функция Медицинска Таблица Функция, иагнозовПациента (экспорт) яКарта предназначенная для значений (ссылка) сбора диагнозов пациента ПреобразоватьВJS Функция Структура Строка Функция, предназначенная для ON формирования JSON строки из структуры ПреобразоватьИзJS ON Функция Строка Структура Функция, предназначенная для формирования структуры из JSON строки

41 Продолжение таблицы 12 ОтправитьЗапросК Функция Структура, РезультатОтвет Функция, Модели (экспорт) Адрес, Путь (строка) предназначенная для отправки запроса к веб-сервису с моделью Для реализации учета резерва коек в функции подсчета количества нагрузки в отделении был реализован дополнительный объект – регистр сведений «тмб_РезервыКоекОтделений». С помощью этого регистра осуществляется хранение процента резерва коечных мест в разрезе отделения. Структура хранимых полей представлена в таблице 13. Таблица 13 Структура регистра сведений «тмб_РезервыКоекОтделений» Наименование Тип Измерения Отделение СправочникСсылка.СтруктураПредприятия Ресурсы ПроцентРезерва Число(3) 3) Описание логики хранения получаемых данных из МИС При старте прогнозирования первоначально происходит сбор текущих пациентов. Текущие пациенты определяются по регистру сведений «Движение пациентов в стационаре» по последней записи с условием по полю «Подразделение». Реквизит «Палата» хранит ссылку на элемент справочника «Палаты», откуда подгружается информация о палате, в которой находится пациент. Также важно было выгружать информацию о статусе Covid из регистра сведений «Лица, контактировавшие с Covid». Остальные данные, такие как «Возраст» и «Состояние» выгружаются из соответствующих регистров сведений «Данные пациентов» и «Данные пациентов стационар». ER-диаграмма представлена на рисунке 30. Полужирным шрифтом отмечены те поля, которые выгружаются для работ модуля.

42 Рис. 30. ER-диаграмма хранения данных пациента Данные, получаемые по пациенту, хранятся в МИС. Основная таблица для получения данных – документ «Госпитализация». В рамках одного случая (медицинской карты) регистрируется только один документ госпитализации. Из данного документа извлекается месяц госпитализации, на основе поля «Дата». В документе также хранятся два реквизита «Пациент» и «Медицинская карта» – они являются полями-ссылками для справочников «Картотека» и «Медицинские карты» соответственно. Основные данные пациента, такие как ФИО, пол, дата и место рождения и т.д. не хранятся в самом справочнике, для этого реализован регистр сведений, который хранит данные в разрезе реквизита «Пациента» (ссылка на справочник «Картотека»). Пол пациента имеет два предопределённых значения, которые хранятся в таблице перечислений «Пол пациентов». Данные по диагнозам МКБ-10 хранятся в разрезе медицинских карт. По одной медицинской карте может быть несколько записей в регистре «Диагнозы по МКБ-10». ER-диаграмма представлена на рисунке 31. Полужирным шрифтом отмечены те поля, которые выгружаются для работ модуля.

43 Рис. 31. ER-диаграмма хранения первичных данных пациента Запрос в терминах 1С, с помощью которого происходит выгрузка первичных данных представлен в листинге 1. Листинг 1 Запрос 1C для получения первичных данных пациента ВЫБРАТЬ Госпитализация.Дата КАК Дата, ДанныеПациентовСрезПоследних.Пол КАК Пол, РАЗНОСТЬДАТ(ДанныеПациентовСрезПоследних.ДатаРождения, &ТекущаяДата, ГОД) КАК Возраст ИЗ Документ.Госпитализация КАК Госпитализация ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ДанныеПациентов.СрезПоследних КАК ДанныеПациентовСрезПоследних ПО Госпитализация.Пациент = ДанныеПациентовСрезПоследних.Пациент ГДЕ Госпитализация.МедицинскаяКарта = &МедицинскаяКарта Для получения диагнозов пациента используется запрос, который приведен в листинге 2. Листинг 2 Запрос 1C для получения диагнозов пациента ВЫБРАТЬ РАЗЛИЧНЫЕ _МКБ10.Код КАК МКБ10 ИЗ РегистрСведений.ДиагнозыПоМКБ10 КАК ДиагнозыПоМКБ10 ЛЕВОЕ СОЕДИНЕНИЕ Справочник.МКБ10 КАК _МКБ10 ПО ДиагнозыПоМКБ10.МКБ10 = _МКБ10.Ссылка ГДЕ ДиагнозыПоМКБ10.МедицинскаяКарта = &МедицинскаяКарта

44 4) Реализация внешней обработки и пользовательский интерфейс Основная часть модуля реализована во внешней обработке, чтобы оставить возможность вносить изменения без выпуска релиза [3,6,7]. В обработке реализован ряд функций и процедур, предназначенных для вывода информации на форму (см. табл. 14). Таблица 14 Перечень основных процедур и функций модуля обработки прогнозирования нагрузки на коечный фонд Наименование Тип Прогнозирование Процедура Директива На клиенте Вход – Выход – Описание Главная процедура, которая обрабатывает событие нажатия на кнопку «Прогнозирование» и отправляет запрос на сервер Прогнозирование Процедура На сервере – – НаСервере Главная процедура, которая выполняется на сервере ПолучитьСписок Функция На сервере Отделение ТекущихПациент Таблица Функция, значений получения овВОтделении для списка текущих пациентов в отделении ВывестиТекущих Процедура На сервере Пациентов Список – пациентов Процедура, предназначенная для вывода текущих пациентов на форму ВывестиРезультат Прогнозирования Процедура На сервере Прогнозы по пациентам – Процедура, предназначенная вывода результатов прогнозирования на форму

45 Продолжение таблицы 14 ПолучитьОбщееК Функция На сервере Отделение Общее Функция, оличествоКоекВО без количество предназначенная тделении контекста коек для (число) общего количества получения коек в отделении ПолучитьСтатусП Функция На сервере Прогноз, Строка Функция, ациентаНаДеньПр без Количество («оранжева предназначенная огноза контекста проведенных я зона», для дней на дату «зеленая статус пациента на прогноза, зона», день прогноза оранжевая «выписан») получения зона, зеленая зона ПолучитьТекущу юДатуСеанса Функция На сервере Дата Функция, без предназначенная контекста для текущей получения даты сеанса При выводе списка пациентов учитывается резерв коек по отделению, который указывается в процентном соотношении от общего количества, в данном случае это одна койка (см. рис. 32). Введены такие понятия как «оранжевая зона» и «зеленая зона». Оранжевая зона подразумевает что до выписки пациента на день прогноза осталось два и менее дней, на рисунке 32 видно, что пациент Сидоров Сергей Алексеевич на момент прогноза пробудет в стационаре три дня, а его период прогноза составляет «до 5 дней», соответственно он подсвечивается оранжевым. Зеленая зона означает что до выписки остался один день и менее. Пациенты, которые превышают свой период пребывания, считаются выписанными.

46 Рис. 32. Главная форма обработки прогнозирования нагрузки коечного фонда отделения Вывод списка пациентов осуществляется с помощью стандартного элемента 1С – табличного документа, заполнение которого осуществляется по макету (см. рис. 33). Рис. 33. Макеты для вывода списка пациентов 3.3.2. Модуль для организации очередей пациентов на операции 1) Алгоритм функционирования модуля Инициатором работы алгоритма является пользователь. После выбора пользователем медицинской карты пациента, происходит сбор данных, необходимых для прогнозирования вероятности выздоровления. После сбора, производится отправка данных в модель ML. Модель возвращает ответ в виде числа от 0 до 1 – вероятности выздоровления пациента.

47 Далее, проводится сбор данных для второй модели – прогнозирования периода пребывания в стационаре. Ответ от модели принимается в виде строки – периода пребывания пациента в стационаре. Затем, происходит создание документа «Изменение очереди на операцию» – через него регистрируются все изменения, которые проводились с очередью на операцию. Внутри документа вычисляется рейтинг пациента по следующему принципу: Рейтинг пациента = Вероятность выздоровления * (Оценка периода пребывания в стационаре + Оценка срочности поступления + Оценка состояния). Оценка времени пребывания, срочности поступления и состояния осуществляется путем сопоставления значений с «баллом» (см. табл. 15). Таблица 15 Оценка (кодирование) входных признаков Значение Балл Период пребывания в стационаре до 5 дней 1 от 5 до 14 дней 2 от 14 дней 3 Срочность поступления Планово 1 Экстренно 3 Неотложная Состояние Удовлетворительное 1 Средней тяжести 2 Тяжелое 3 Кома 4 Агональное Крайне тяжелое 5 Затем, в соответствии с установленным рейтингом, пациенту назначается номер в очереди. Врачу предоставляется возможность скорректировать

48 результаты работы модели, и внести номер в очереди вручную, тогда пациент не будет участвовать «в рейтинге». При сохранении документа «Изменение очереди», происходит поиск документа «Очередь на операцию» и, если документа не существует, то он создается. После создания, очередь обновляется и передается результат об успешности выполнения в модуль. Кросс-функциональная схема, построенная в нотации Cross-Functional Flowchart [21], представлена в приложении 2. 2) Реализация объектов метаданных модуля внутри МИС Работа данного модуля была спроектирована таким образом, чтобы были разделены обязанности каждого из объектов участвующего в работе подсистемы Был [3,6,7]. разработан общий модуль «тмб_ПрогнозированиеВероятностиВыздоровленияПациента» с помощью которого производится обращение на веб-сервис к обученной модели машинного обучения. Перечень функций и процедур, реализованных в этом модуле приведен в таблице 16. Таблица 16 Перечень основных процедур и функций общего модуля «ПрогнозированиеВероятностиВыздоровленияПациента» Наименование Тип Вход Выход Описание ВыполнитьПрогноз Функция Медицинска РезультатПрогн Главная функция, ирование (экспорт) яКарта озирования которая вызывается (ссылка) (строка) из других модулей. Из этой функции осуществляется вызов других функций и процедур

49 Продолжение таблицы 16 ПолучитьПервичн Функция Медицинска Таблица Функция, ыеДанные (экспорт) яКарта предназначенная для значений (ссылка) сбора первичных данных пациента: пол, возраст, месяц госпитализации ПолучитьСписокД Функция Медицинска Таблица Функция, иагнозовПациента (экспорт) яКарта предназначенная для значений (ссылка) сбора диагнозов пациента ПолучитьПоказател Функция Медицинска Таблица Функция, иЗдоровья яКарта предназначенная для (экспорт) значений (ссылка) сбора показателей здоровья пациента ПреобразоватьВJS Функция Структура Строка Функция, предназначенная для ON формирования JSON строки из структуры ПреобразоватьИзJS Функция Строка Структура Функция, предназначенная для ON формирования структуры из JSON строки ПолучитьКодВида Функция Транспортировки Вид Код вида Функция, транспортир транспортировк предназначенная для овки сопоставления и (число) (строка) значения вида транспортировки с его кодом ПолучитьКодСосто яния Функция Состояние Код состояние Функция, (строка) (число) предназначенная для сопоставления …

50 Продолжение таблицы 16 … значения состояния с его кодом ПолучитьКодСроч Функция ностиПоступления Срочность Код срочности Функция, поступления поступления предназначенная для (строка) сопоставления (число) значения срочности поступления с его кодом ЗаполнитьПоказате Процедура льЗдоровья Структура, – Процедура, Имя заполняющая показателя, значения показателя Значения здоровья показателя переданной в структуре ОтправитьЗапросК Функция Структура, РезультатОтвет Функция, Модели (экспорт) Адрес, Путь (строка) предназначенная для отправки запроса к веб-сервису с моделью Для организации хранения сведений о очередях, пациентах, находящихся в ожидании, был добавлен ряд новых объектов. Основной объект – это документ «Очередь на операцию». Документ хранит информацию о пациентах, стоящих в очереди, в виде табличной части. Структура документа представлена в таблице 17. Таблица 17 Структура документа «Очередь на операцию» Наименование Тип Операция СправочникСсылка.НоменклатураМедицинскихУслуг ТипОчереди ПеречислениеСсылка. тмб_ТипыОчередейНаОперации

51 Продолжение таблицы 17 СчетчикДобавленныхПациентов Число Табличная часть «Очередь пациентов» МедицинскаяКарта СправочникСсылка.МедицинскиеКарты Рейтинг Число ПорядковыйНомерДобавленияВОчередь Число НеУчитыватьВРейтинге Булево Проведение документа (сохранение) влечет за собой регистрацию движений в соответствующих регистрах. Для этого был создан регистр сведений «тмб_ПациентыВОчередиНаОперацию». Регистры сведений используются для получения необходимой информации по документу в различных срезах, поскольку получать данные напрямую из документа считается «плохим тоном». Структура хранимых полей в регистре представлена в таблице 18. Таблица 18 Структура регистра сведений «тмб_ПациентыВОчередиНаОперацию» Наименование Тип Измерения Операция СправочникСсылка.НоменклатураМедицинскихУслуг ТипОчереди ПеречислениеСсылка.тмб_ТипыОчередейНаОперации МедицинскаяКарта СправочникСсылка.МедицинскиеКарты Ресурсы Рейтинг Число НомерВОчереди Число Каждая строка табличной части «Очередь пациентов» документа «Очередь на операцию» соответствует одной «тмб_ПациентыВОчередиНаОперацию». записи Одной в регистре записи с сведений одинаковыми измерениями не может быть зарегистрировано, т.е. может быть две записи с одинаковой операцией, типом очереди (список значений приведен в таблице 19) и медицинской картой быть не может. Ресурсы в данном случае хранят данные о рейтинге и порядковом номере пациента в очереди. Номер в очереди равен порядковому номеру строки в табличной части «Очередь пациентов».

52 Таблица 19 Доступные значения перечисления «Типы очередей на операции» Идентификатор Значение Плановая Плановая Экстренная Экстренная Поскольку стояла задача реализовать возможность отслеживать изменения, проводимые с очередью, то для этого был создан документ «тмб_ИзменениеОчередиНаОперацию». Структура полей документа приведена в таблице 20. Таблица 20 Структура документа «тмб_ИзменениеОчередиНаОперацию» Наименование ТипИзменения Тип ПеречислениеСсылка.тмб_ТипыИзмененияОчередиНаОпер ацию ДокументОчередиНаОперац ДокументСсылка.тмб_ОчередьНаОперацию ию Операция СправочникСсылка.НоменклатураМедицинскихУслуг МедицинскаяКарта СправочникСсылка.МедицинскиеКарты Пациент СправочникСсылка.Картотека НомерВОчереди Число Рейтинг Число НеУчитыватьВРейтинге Булево Причина Строка ПодписанЭП Булево Табличная часть «Электронные подписи» ДатаПодписи Дата и время ИмяФайлаПодписи Строка Комментарий Строка КомуВыданСертификат Строка

53 Продолжение таблицы 20 Отпечаток Строка Подпись Строка УстановившийПодпись Строка Сертификат Хранилище значения ДатаПроверкиПодписи Дата ПодписьВерна Булево Идентификация типа изменения очереди осуществляется с помощью значений перечисления «Типы изменения очереди на операцию» (список значений приведен в таблице 21). Таблица 21 Доступные значения перечисления «Типы изменения очереди на операцию» Идентификатор Значение Добавление Добавление Изменение Изменение Исключение Исключение После проведения документа «Изменение очереди на операцию» осуществляется запрос к основному документу очереди, ссылка на который хранится в реквизите «ДокументОчередиНаОперацию». ER-диаграмма представлена на рисунке 34. Рис. 34. ER-диаграмма хранения данных модуля очередей на операции

54 3) Описание логики хранения получаемых данных из МИС При прогнозировании вероятности выздоровления пациента происходит сбор данных в МИС. Основными источниками данных являются такие объекты как документ «Поступление пациента в стационар», регистр сведений «Диагнозы по МКБ-10» и «Показатели здоровья». Из документа поступление выгружаются данные о виде транспортировке и канале госпитализации (срочности поступления). Данные о поле, возрасте получаются из регистра сведений «Данные о пациентах». Информация о последнем состоянии пациента загружаются из регистра сведений «Данные пациентов стационар». Данные по диагнозам хранятся в разрезе медицинских карт в регистре сведений «Диагнозы по МКБ-10». Показатели здоровья регистрируются в соответствующем регистре сведений. ER-диаграмма представлена на рисунке 35. Рис. 35. ER-диаграмма хранения первичных данных пациента Процесс получения данных для модели прогнозирования периода пребывания пациента в стационаре был описан ранее в п. 3.3.1 Получение данных реализован с помощью запросов к МИС на языке 1С. Запрос для получения первичных данных представлен в листинге 3, диагнозов пациента в листинге 4 и показателей здоровья в листинге 5.

55 Листинг 3 Запрос 1C для получения первичных данных пациента ВЫБРАТЬ ПРЕДСТАВЛЕНИЕ(ДанныеПациентовСтационарСрезПоследних.Состоя ние) КАК Состояние, ПРЕДСТАВЛЕНИЕ(ПоступлениеПациентаВСтационар.ВидТранспортир овки) КАК ВидТранспортировки, ПРЕДСТАВЛЕНИЕ(ПоступлениеПациентаВСтационар.КаналГоспитали зации) КАК СрочностьПоступления, РАЗНОСТЬДАТ(ДанныеПациентовСрезПоследних.ДатаРождения, &ТекущаяДата, ГОД) КАК Возраст, ДанныеПациентовСрезПоследних.Пол КАК Пол ИЗ Документ.ПоступлениеПациентаВСтационар КАК ПоступлениеПациентаВСтационар ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ДанныеПациентов.СрезПоследних КАК ДанныеПациентовСрезПоследних ПО ПоступлениеПациентаВСтационар.Пациент = ДанныеПациентовСрезПоследних.Пациент ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ДанныеПациентовСтационар.СрезПоследн их КАК ДанныеПациентовСтационарСрезПоследних ПО ПоступлениеПациентаВСтационар.Пациент = ДанныеПациентовСтационарСрезПоследних.Пациент ГДЕ ПоступлениеПациентаВСтационар.МедицинскаяКарта = &МедицинскаяКарта Листинг 4 Запрос 1C для получения диагнозов пациента ВЫБРАТЬ РАЗЛИЧНЫЕ _МКБ10.Код КАК МКБ10 ИЗ РегистрСведений.ДиагнозыПоМКБ10 КАК ДиагнозыПоМКБ10 ЛЕВОЕ СОЕДИНЕНИЕ Справочник.МКБ10 КАК _МКБ10 ПО ДиагнозыПоМКБ10.МКБ10 = _МКБ10.Ссылка ГДЕ ДиагнозыПоМКБ10.МедицинскаяКарта = &МедицинскаяКарта

56 Листинг 5 Запрос 1C для получения показателей здоровья пациента ВЫБРАТЬ МедицинскиеКарты.Код КАК ИдМедКарты, ПРЕДСТАВЛЕНИЕ(ПоказателиЗдоровьяСрезПоследних.ВидРезультат а) КАК ПоказательЗдоровья, ПРЕДСТАВЛЕНИЕ(ПоказателиЗдоровьяСрезПоследних.ЗначениеПока зателяЗдоровья) КАК ЗначениеПоказателяЗдоровья ИЗ РегистрСведений.ПоказателиЗдоровья.СрезПоследних( , МедицинскаяКарта = &МедицинскаяКарта И ВидРезультата В (&ПоказателиЗдоровья)) КАК ПоказателиЗдоровьяСрезПоследних ЛЕВОЕ СОЕДИНЕНИЕ Справочник.МедицинскиеКарты КАК МедицинскиеКарты ПО ПоказателиЗдоровьяСрезПоследних.МедицинскаяКарта = МедицинскиеКарты.Ссылка УПОРЯДОЧИТЬ ПО ИдМедКарты Показатели здоровья пациента хранятся в системе в соответствующем регистре сведений. Получение показателей здоровья осуществляется с помощью идентификаторов – у каждого показателя свой уникальный идентификатор (см. рис. 36). Рис. 36. Пример вида показателей здоровья «Гемоглобин» Для того чтобы выгружать необходимые параметры необходимо в условии отбирать соответствующие идентификаторы, но поскольку выполнять запросы с

57 условиями по строчным параметрам считается «плохой практикой» этот процесс был реализован через системный документ «Регистрация доступных значений». Документ содержит в себе поле «Ключ» и табличную часть необходимых показателей здоровья для выгрузки. Таким образом, этот механизм позволяет изменять состав необходимых показателей без редактирования кода и выгружать этот список по уникальному ключу «ПрогнозированиеВероятностиВыздоровления_ПоказателиЗдоровья» (см. рис. 37). Рис. 37. Регистрация доступных значений видов показателей здоровья

58 4) Реализация внешней обработки и пользовательский интерфейс Основная часть модуля также реализована как внешняя обработка. Таким образом, создается возможность вносить изменения в функционал без необходимости релиза. В обработке реализован ряд функций и процедур, предназначенных для вывода информации на форму (см. табл. 22). Таблица 22 Перечень основных процедур и функций модуля формы обработки очередей на операции Наименование Тип Директива Вход Выход Описание Обработчики событий формы ПриСозданииНаС Процедура На сервере – – ервере Процедура, которая выполняется при создании формы на сервере. Заполняет базовые параметры формы Обработчики событий формы Процедура На клиенте – – Обработка события, ОчередьПациенто возникающего вПередНачаломД перед обавления добавления пациент начало в очередь Процедура На клиенте – – Обработка события, возникающего при изменении ТипОчередиПриИ очереди. зменении Подгружает типа очередь по операции на указанный тип ОперацияПриИзм енении Процедура На клиенте – – Обработка события, …

59 Продолжение таблицы 22 … возникающего при изменении операции. Обработчики событий команд формы Процедура На клиенте – – Обработка события, возникающего при нажатии на кнопку ДобавитьПациент «Добавить аВОчередь пациента в очередь» Процедура На клиенте – – Обработка события, возникающего при нажатии на кнопку РазместитьВОчер «Разместить едиНаМесто очереди в на определенное место» Процедура На клиенте – – Обработка события, возникающего при ИсключитьПацие нажатии на кнопку нтаИзОчереди «Исключить из очереди» Процедура На клиенте – – Обработка события, возникающего при ВнестиПоказател нажатии на кнопку иЗдоровья «Внести показатели здоровья» Процедура На клиенте – – Обработка события, возникающего при Печать нажатии на кнопку «Печать»

60 Продолжение таблицы 22 Обработка оповещений Процедура На клиенте – – Обработка оповещения, ВыборКартыПаци которое возникает ентаПослеЗакрыт при ия закрытии формы выбора карты пациента Процедура На клиенте – – Обработка оповещения, ИзменениеПациен которое возникает таВОчередиПосле при Закрытия формы закрытии изменения пациента в очереди Служебные процедуры и функции Функция На сервере ТипИзменен Перечислен Функция, ия иеСсылка. предназначенная тмб_ТипыИ для змененияОч ссылки ПолучитьТипИзм ередиНаОп перечисление ененияНаСервере ерацию «тмб_ТипыИзмене получения на нияОчередиНаОпер ацию» в зависимости от входной строки Процедура На сервере – – Процедура, предназначенная для УстановитьПарам етрДинамическог оСписка установки параметров (операция, тип очереди) для динамического списка на форме

61 Продолжение таблицы 22 Функция На сервере Медицинска Булево яКарта Функция, для проверки наличия у пациента необходимых ПроверитьДостат показателей очноеКоличество здоровья ПоказателейЗдоро прогнозирования. вьяПациента Возвращает Истина для – если показателей достаточно, в противном случае – Ложь Функция На сервере – ПолучитьДокуме нтОчередиНаОпе рацию ДокументС Функция, сылка. предназначенная тмб_Очеред для ьНаОперац ссылки на документ ию операции получения по выбранной операции и типу очереди Функция На сервере Медицинска Булево яКарта Функция, предназначенная для проверки закрытости карты у ПроверитьЗакрыт пациента. остьКарты Возвращает Истина – если карта не закрыта, в противном случае – Ложь Функция На сервере СсылкаНаДо Булево Функция, для ПроверитьПациен кументОчере проверки, таНаУчастиеВОче ди, участвует пациент в реди Медицинска очереди яКарта Возвращает … или нет

62 Продолжение таблицы 22 … Истина – если участвует, в противном случае – Ложь ПолучитьПациент Функция На сервере аПоМедицинской Медицинска Справочник Функция, яКарта Ссылка.Кар получения тотека на пациента по его Карте для ссылки мед. карте Функция На сервере Медицинска Булево яКарта Функция, для проверки нахождения пациента в стационаре по его ПроверитьПациен мед. таНаНахождение карте. Возвращает Истина ВСтационаре – если пациент находится в стационаре, в противном случае – Ложь Функция На сервере – Табличный Функция, для документ формирования печатной формы с ПечатьНаСервере текущим пациентов списка в очереди Функция ПолучитьСписокТ екущихПациентов На сервере – Таблица Функция, для для значений получения списка текущих пациентов в очереди Главная форма содержит в себе поля выбора для операции и типа очереди, а также поле со списком пациентов (см. рис. 38). В списке пациентов отображается первичная информация, необходимая для понимания пациента.

63 Тем пациентам, у которых стоит отметка в колонке «Не учитывать в рейтинге» номер в очереди был назначен вручную и рейтинге по ним не вычислялся. Рис. 38. Главная форма модуля очередей на операции В командной панели динамического списка размещены основные кнопки управления очередью: «Добавить пациента в очередь», «Исключить из очереди», «Разместить в очереди на определенное место», «Внести показатели здоровья», «Печать». При нажатии на кнопку «Добавить пациента в очередь» происходит открытие формы поиска медицинской карты (см. рис. 39). Рис. 39. Форма выбора пациента

64 С помощью данной формы, пользователю необходимо выбрать медицинскую карту пациента. При попытке выбрать самого пациента, отобразится информационное сообщение (см. рис. 40) Рис. 40. Окно ошибки при выборе пациента Далее, после корректного выбора медицинской карты, откроется форма документ «Изменение очереди на операцию» и в случае, если по пациенту нет возможности вычислить рейтинге, выходят соответствующие сообщение, и он помещается в конец очереди (см. рис. 41). Рис. 41. Форма документа «Изменение очереди на операцию» (добавление)

65 В случае, если по пациенту достаточно данных для вычисления рейтинга, то в поле «Рейтинг» автоматически при открытии формы подставится его значение и присвоится номер в очереди (см. рис. 42). Рис. 42. Форма документа «Изменение очереди на операцию» (назначение рейтинга) Все поля защищены от изменений (кроме ЭЦП), кроме исключительных случаев. Например, при установке отметки в поле «Не учитывать в рейтинге», поле «Номер в очереди» становится доступным для изменения. Значение рейтинга не обнуляется, чтобы в дальнейшем пациента можно было вернуть в очередь. Далее, происходит подписание документа электронной подписью. В рамках учебной работы обязательная проверка на электронную подпись отключена, чтобы не создать сложности при тестировании. На продуктивных базах, эта проверка активируется. При нажатии на кнопку с печатью, открывается окно для выбора сертификат и ввода пароля (см. рис. 43).

66 Рис. 43. Форма подписания документа «Изменения очереди на операцию» с помощью ЭЦП После нажатия кнопки «Подписать» происходить подписание документа электронной подписью и сведения о подписи вносятся в табличную часть (см. рис. 44). Рис. 44. Форма документа «Изменение очереди на операцию» (успешное подписание с помощью ЭЦП) По нажатию на кнопку «Удалить» происходит удаления сведений о выбранной подписи.

67 При проведении документа информация сохраняется в базе и в основной документ очереди добавляется новый пациент. Результат автоматически обновляется на форме (см. рис. 45). Рис. 45. Успешно добавленный пациент в очередь на операцию При нажатии на кнопку «Разместить в очереди на определенное место» открывается такая же форма «Изменения очереди на операцию», только с пометкой типа изменения «Изменение» (см. рис. 46). При открытии формы автоматически устанавливается отметка «Не учитывать в рейтинге», так как предполагается что номер в очереди будет введен вручную, но всегда можно пересчитать рейтинг и вернуть пациента в рейтинг с помощью кнопки «Пересчитать». Также при проведении данного документа необходимо обязательно ввести «Причину» изменения. Рис. 46. Форма документа «Изменение очереди на операцию» (изменение)

68 Электронные подписи работают аналогично добавлению пациента в очередь. При нажатии на кнопку «Исключить из очереди» открывается окно «Изменение очереди на операцию» с пометкой «Исключение» (см. рис. 47). В случае исключения пациента заблокированы для изменения все поля кроме «Причина» и электронных подписей. Рис. 47. Форма документа «Изменение очереди на операцию» (исключение пациента) Электронные подписи работают аналогично добавлению пациента в очередь. После проведения документа исключения, пациент автоматически удаляется из основного документа очереди и происходит смещение очереди (см. рис. 48). Рис. 48. Исключение пациента из очереди (результат)

69 В случае если по пациенту недостаточно данных для расчета рейтинга, на главную форму вынесена кнопка «Внести показатели здоровья». Данная кнопка добавлена для учебной работы и не будет отображаться в продуктивной среде, поскольку данные показателей здоровья пациента попадают в МИС более сложным способом – из лабораторной информационной системы (ЛИС). С помощью данной формы можно легким способом внести необходимые показатели для тестирования (см. рис. 49). Рис. 49. Форма внесения показателей здоровья пациента По одной операции доступно два типа очереди: плановая и экстренная. Для каждой очереди заводится отдельный документ очереди. Для переключения используется тумблер «Тип очереди» (см. рис. 50).

70 Рис. 50. Возможность выбора типа очереди Также был реализован макет для возможности печати текущего списка пациентов (см. рис. 51). Рис. 51. Макет печатной формы «Список пациентов в очереди» Для инициации формирования печатной формы используется кнопка «Печать» на главной форме, при нажатии на которую открывается отдельное окно с возможностью отправить документ на печать (см. рис. 52). Рис. 52. Формирование печатной формы «Список пациентов в очереди» При попытке вызывать печатную форму, в то время как очередь на операцию пустая, отобразится соответствующее сообщение (см. рис. 53)

71 Рис. 53. Пример сообщения при попытке сформировать печатную форму «Список пациентов в очереди» в пустой очереди Дополнительно, для работы со списком пациентов в очереди доступен еще ряд вспомогательных команд (см. рис. 54). Рис. 54. Дополнительные команды главной формы модуля очередей Например, пункт «Расширенный поиск» позволяет найти элементы списка по конкретному полю (см. рис. 55), но при этом на главной форме доступен быстрый поиск (см. рис. 56)

72 Рис. 55. Форма расширенного поиска Рис. 56. Быстрый поиск на главной форме Пользователю предоставляется возможность настраивать список по своему удобству. Среди доступных настроек присутствует отбор по условию, сортировка, условное оформление и дополнительные группировки (см. рис. 57) Рис. 57. Формирование пользовательских настроек Составленные настройки можно сохранить. Поддерживается сохранение нескольких настроек одновременно. Доступен выбор сохраненных настроек, при этом можно вернуть стандартные настройки по умолчанию (см. рис. 58)

73 Рис. 58. Сохранение и выбор пользовательских настроек Также доступен вывод списка в текстовый документ для дальнейшего возможного использования в других системах (см. рис. 59). Рис. 59. Вывод списка текущих пациентов в текстовый файл 4) Веб-сервис для получения актуальной очереди. Централизация При старте разработки проекта был поднят вопрос о необходимости централизации данных документов. В МИС централизованная архитектура баз, т.е. есть одна центральная база и периферийные, непосредственно по каждой из МО (ОКБ 1, ГП 5, ОБ3 и т.д.). Централизация документов и прочих сведений реализована с помощью программного брокера сообщений Rabbit MQ [16]. При изменении какого-либо объекта в периферии, его новая версия отправляется в центральную базу и наоборот, если это предусмотрено спецификой документа.

74 На передачу пакетов требуется время, обработка пакетов происходит по очереди, поэтому для получения новых версий в периферии требуется некоторое время. Реализация данного проекта на текущей централизации не подходит по нескольким причинам: 1. Конфликты версий – возможна ситуация, когда одну и ту же очередь откроют для редактирования несколько специалистов в разных МО. И при сохранении в центральной базе будет перезаписана только последняя версия, поскольку версия первого редактора не успеет дойти до всех периферийных баз и до самого центра. 2. Малое количество МО, которые проводят операции. Другим МО достаточно лишь получить список пациентов, ожидающих оперативного вмешательства. 3. Решение об оперативном вмешательстве пациента принимается непосредственно в самой МО, поэтому нет необходимости предоставления возможности добавления пациентов в очереди из других МО. Исходя из выполненного анализа, было принято решение дать возможность другим МО получать текущую очередь на операцию. Этот функционал достаточен для текущего этапа проекта, поскольку работа с очередями планируется в той МО, где будет производиться операция. Для обеспечения доступа к списку пациентов в очереди был разработан HTTP-сервис «tmb_QueueSurgery» на уровне 1С, работающий по методу GET [5]. Путь для доступа к методу выглядит следующим образом: http://hostname/basename/hs/queue_surgery/GetQueue/&SurgerySID/&TypeQ ueue, где hostname – адрес сервера, basename – наименование базы 1С, hs – системный тег HTTP сервиса 1С, queue_surgery – корневой URL, GetQueue – имя метода,

75 &SurgerySID – параметр «сшп_Идентификатор» справочника «Номенклатура медицинских услуг», &TypeQueue – параметр «Тип очереди», значение. Справочник «Номенклатура медицинских услуг» централизован и имеет одинаковый «сшп_Идентификатор» во всех базах, поэтому по этому полю определяется на какую операцию необходимо получить список. Тип очереди является перечислением, поэтому доступ осуществляется напрямую по значению. В HTTP-сервисе «tmb_QueueSurgery» реализован ряд функций и процедур, предназначенных для вывода информации на форму (см. табл. 23). Таблица 23 Перечень основных процедур и функций HTTP-сервиса «tmb_QueueSurgery» Наименование GetQueueGET Тип Функция Вход Запрос Выход Описание Ответ Основная (JSON) функция, выполняющая транспортную роль при работе в рамках одного запроса. Проверяет входные параметры и возвращает ответ отправителю. ПолучитьСписокТекущихПаци ентов Функция Операция Таблица , значений Функция, предназначенная ТипОчер для еди списка получения текущих пациентов …

76 Продолжение таблицы 23 … по переданным параметрам ПолучитьСсылкуНаТипОч Функция ередиПоЗначению ТипОчеред Перечисле Функция, иЗначение ние предназначенная (ссылка) для сопоставления значения перечисления с его ссылкой СформироватьHTTPСервис Функция пСтруктура Строка Функция, Ответ Ответа, предназначенная пКодСосто для яния ответа упаковки пФорматТе лаОтвета Успешно Функция – Строка Функция, возвращающая код успешного ответа (200) НеверныйЗапрос Функция – Строка Функция, возвращающая код неверного запроса (400) Ответ получается в виде JSON строки определенной структуры (см. листинг 6) Листинг 6 Структура JSON ответа от HTTP-сервиса «tmb_QueueSurgery» { "ErrorList": [], "Result": [] }

77 Если в процессе не было получено ошибок (см. табл. 24), то будет заполнено поле «Result», в противном случае – «ErrorList». Таблица 24 Список возможных ошибок работы HTTP-сервиса «tmb_QueueSurgery» № Содержание ошибки 1 Не найдена НМУ по переданному идентификатору СШП 2 Не найден тип очереди по переданному значению "TypeQueue" Пример успешного ответа приведен в листинге 7. Листинг 7 Пример успешного JSON ответа HTTP-сервиса «tmb_QueueSurgery» { "ErrorList": [], "Result": [ [ { "НомерВОчереди": 1, "Рейтинг": 0, "Пациент": "Сидоров Сергей Витальевич", "Пол": "М", "МедицинскаяКарта": "31 от 15.08.20, Амбулаторная карта", "Возраст": 54, "Состояние": "", "ПорядковыйНомерДобавленияВОчередь": 3 }, { ... } ] ] } Пример неуспешного ответа приведен в листинге 8. Листинг 8 Пример неуспешного JSON ответа HTTP-сервиса «tmb_QueueSurgery» { "ErrorList": [ "Не найдена НМУ по переданному идентификатору СШП" ], "Result": [] }

78 ГЛАВА 4. Апробация и тестирование 4.1. Проверка результатов прогнозирования моделей В рамках данного этапа была проведена проверка прогнозов, полученных с помощью построенных моделей. Проверка осуществлялась в формате экспертной оценки со стороны медицинского персонала. Для этого по каждой из моделей была отобрана выборка записей из тестовых наборов с полученным прогнозом по каждому случаю. Количество выгруженных записей для оценки – 30. Экспертная оценка правильных прогнозов по модели прогнозирования периода пребывания в стационаре составила 93,4% (28 из 30), по модели прогнозирования вероятности выздоровления пациента – 76,7% (23 из 30). 4.2. Тестирование веб-сервиса прогнозирования По итогу разработки была протестирована работа веб-сервиса для прогнозирования. Были проверены сценарии корректной и некорректной передачи данных, согласно составленным требованиям к форматно-логическому контролю (см. табл. 25). Таблица 25 Форматно-логический контроль данных веб-сервиса прогнозирования Причины Код ФЛК Наименование ФЛК Проверяемые неуспешности параметры прохождения данных ФЛК случае фиксации нарушения ФЛК Наименование Наименование Прерывание метода метода дальнейшей неизвестно работы SEX, Входной набор Сообщению WS-P- корректного … AGE, полей в JSON пользователю 2 … не … и отправка … FLC- Проверка на обращение к Результат в WS-P- существующему методу 1 FLC- Проверка на передачу

79 Продолжение таблицы 25 … набора … … … данных для MONTH_OF_HOSPITALIZ соответствует неуспешного модели ATION, необходимому ответа прогнозирования DIAGNOSIS -> DIAGNOS SEX, AGE, Входной набор Сообщению TRANSPORTATION, полей в JSON пользователю корректного GENERAL_STATE, не и отправка набора данных URGENCY_OF_HOSPITA соответствует неуспешного для модели LIZATION, DIA, SIS, необходимому ответа прогнозирования EOS_PERC, HCT, вероятности BASO_PERC, выздоровления MONO_PERC, Переданного Добавление диагноза нет в кода диагноза обученной обученной в системный модели модели файл на периода пребывания в стационаре FLC- Проверка на WS-P- передачу 3 LYM_PERC, NEU_PERC, BASO, EOS, LYM, MONO, NEU, PCT, MPV, PDW, RDW_CV, PLT, MCHC, MCH, MCV, HGB, RBC, WBC, IG_PERC, IG, SOE, DIAGNOSIS -> DIAGNOS FLC- Проверка на WS-P- наличие в 4 переданного диагноза DIAGNOSIS -> DIAGNOS сервере

80 4.3. Тестирование модуля прогнозирования нагрузки коечного фонда отделения Тестирование модуля прогнозирования нагрузки коечного фонда проходило также по составленным требованиям к форматно-логическому контролю (см. табл. 26). Таблица 26 Форматно-логический контроль данных в модуле прогнозирования нагрузки коечного фонда Причины Код Наименование Проверяемые неуспешности ФЛК ФЛК параметры прохождения данных ФЛК FLC-M1- Проверка на 1 Результат в случае фиксации нарушения ФЛК Отделение Значение в полях Сообщению ДатаПрогноза «Отделение» и «Дата пользователю и поля отделение прогноза» не прерывание и дата прогноза заполнено дальнейшей заполнение работы FLC-M1- Проверка на 2 Дата прогноза меньше Сообщению соответствие или равна текущей пользователю и даты прогноза и дате сеанса прерывание текущей даты дальнейшей сеанса работы FLC-M1- Проверка на 3 ДатаПрогноза Медциинская Переданная мед. карта Сообщение карта не существует или пользователю и закрыта пропуск пациента Медицинская По переданной мед. Сообщение карта карте не найден пользователю и документа действительный пропуск пациента госпитализации документ существование медицинской карты перед сбором данных FLC-M1- Проверка на 3 наличие госпитализации

81 Продолжение таблицы 26 FLC-M1- Проверка на 4 Диагноз По переданному Запись наличие диагнозу не нашлось пропущенного признака для соответствующего диагноза в файл на диагноза в признака в модели сервере модели машинного обучения «missing_diagnosis _model_interval_ho sp.txt» 4.4. Тестирование модуля организации очереди пациентов на операции Тестирование данного модуля было разбито на 2 части: тестирование интерфейсной части и проверка работы веб-сервиса. Для тестирования интерфейсной части были составлены отдельные требования к форматнологическому контролю – для проверки работы документа «Изменение очереди на операцию» и непосредственно работы главной формы модуля. На уровне документа «Изменение очереди на операцию» соблюдается форматно-логический контроль, который обеспечивает корректность передаваемых данных (см. табл. 27). Таблица 27 Форматно-логический контроль данных в модуле документа «Изменение очереди на операцию» Причины Код Наименование Проверяемые неуспешности ФЛК ФЛК параметры прохождения данных ФЛК FLC-M2- Проверка поля EDIT-1 Рейтинг Если рейтинг = 0 «Рейтинг» Результат в случае фиксации нарушения ФЛК Не учитывать пациента в рейтинге FLC-M2- Проверка поля EDIT-2 НомерВОчереди Тип изменения = Поместить «Номер в «изменение» И пациента в конец очереди» на … текущий номер в очереди очереди …

82 Продолжение таблицы 27 … максимально … больше, чем допустимое текущее значение количество пациентов очереди FLC-M2- Проверка EDIT-3 возвращаемого ВероятностьВыздо Вероятность Сообщение ровления выздоровления не пользователю и заполнена помещение значения вероятности пациента в конец выздоровления очереди пациента FLC-M2- Проверка EDIT-4 ПериодПребывани Период Присвоить яВСтационаре пребывания в значение по значения стационаре не умолчанию «от 5 периода заполнен до 14 дней» Значение в поле Присвоить наличия «Состояние» не значение по значения в поле заполнено умолчанию возвращаемого пребывания в стационаре FLC-M2- Проверка EDIT-5 Состояние «Состояние» «удовлетворитель но» FLC-M2- Проверка EDIT-6 СрочностьПоступл Значение в поле Присвоить ения «Срочность значения по значения в поле поступления» не умолчанию «Срочность заполнено «планово» Если тип Сообщение наличия поступления» FLC-M2- Проверка EDIT-7 Причина заполнения изменения очереди пользователю и поля = «изменение» прерывание «Причина» ИЛИ дальнейшей «исключение» работы

83 Продолжение таблицы 27 FLC-M2- Проверка EDIT-8 ДокументОчередиНа Если документа Создать новый Операцию не существует документ основного (очередь не «тмб_ОчередьНаО документа создана) перацию» и существования операции продолжить «тмб_ОчередьН запись данных по аОперацию» пациенту в него FLC-M2- Проверка EDIT-9 МедицинскаяКарта, Если тип Сообщение участия ДокументОчередиНа изменения пользователю и медицинской Операцию очереди = прерывание карты в («изменение» дальнейшей выбранной ИЛИ работы очереди при «исключение») изменении или И медицинская исключение карта не пациента зарегистрирова на в очереди FLC-M2- Проверка EDIT-10 Документ Документа с Сообщение наличия «Регистрация указанным пользователю и доступных доступных значений» ключом нет прерывание ИЛИ пустой дальнейшей значений по ключу работы «Прогнозирова ниеВероятности Выздоровления _ПоказателиЗдо ровья» На уровне формы был реализован следующий форматно-логический контроль (см. табл. 28).

84 Таблица 28 Форматно-логический контроль данных в модуле формы обработки очередей на операции Причины Код Наименование Проверяемые неуспешности ФЛК ФЛК параметры прохождения данных ФЛК FLC-M2- Доступность 1 Операция кнопок 2 случае фиксации нарушения ФЛК Поле «Операция» не Отключить заполнено доступность управления FLC-M2- Обработка Результат в кнопок упраления Медициснкая Не выбрана строка в Сообщение Карта динамическом списке, пользователю и управления либо поле прекращение «Исключить из «МедицинскаяКарта» дальнейшей очереди», не заполнено работы Медицинская По медицинской карте Сообщение наличие Карта, не зарегистрированы пользователю и достаточного ПоказателиЗд показатели здоровья активация ручного количества оровья кнопок «Разместить в очереди на определенное место», «Внести показатели здоровья» FLC-M2- Проверка на 3 добавления в показателей очередь здоровья FLC-M2- Проверка 4 медицинской карты на статус Медицинская Медицинская карта Сообщение Карта закрыта пользователю и прекращение дальнейшей работы

85 Продолжение таблицы 28 FLC-M2- Проверка на 5 наличие Пациент уже участвует Сообщение Карта в рейтинге пользователю и пациента в прекращение рейтинге при дальнейшей добавлении работы FLC-M2- Проверка на 6 Медицинская нахождение в Медицинская Пациент не находится Сообщение Карта в стационаре пользователю и стационаре ручное добавления в очередь FLC-M2- Проверка на 7 печать Список Количество текущих Сообщение текущих пациентов равно нулю пользователю о пациентов невозможности сформировать печатный документ Также в рамках данного этапа была протестирована работа веб-сервиса на стороне 1С, позволяющего получать список очереди на операцию из сторонних источников с помощью метода GET. На уровне веб-сервиса соблюдается форматно-логический контроль, передаваемых данных (см. табл. 29). который обеспечивает корректность

86 Таблица 29 Форматно-логический контроль данных в HTTP-сервисе «tmb_QueueSurgery» Код ФЛК Наименование ФЛК FLC-M2- Проверка HS-1 Проверяем ые параметры Причины неуспешности прохождения данных ФЛК Результат в случае фиксации нарушения ФЛК Если по СШП Сообщение с переданного идентификатору не ошибкой и параметра найден прерывание «SurgerySID» соответствующий дальнейшей элемент справочника работы SurgerySID «Номенклатура медицинских услуг» FLC-M2- Проверка Если по переданному Сообщение с HS-2 переданного значению не найден ошибкой и параметра соответствующий прерывание «TypeQueue» элемент перечисления дальнейшей «Типы очередей» работы TypeQueue

87 ЗАКЛЮЧЕНИЕ Процесс выполнения выпускной квалификационной работы в рамках разработки подсистемы триажа пациентов на операции был разбит на три глобальных этапа: ознакомление с рабочим процессом, постановка задачи на разработку, реализация поставленных задач, документирование полученных результатов Первый этап – ознакомление с рабочим процессом. Данный этап включал в себя предварительную подготовку к работе, а именно изучение внутренней структуры предприятия, разбор регламента и соглашения по разработке программного обеспечения, изучение процесса групповой разработки прикладных решений, прохождение вводных инструктажей. На данном этапе были изучены внутренние правила по написанию программного кода. Второй этап заключался в постановке задачи на разработку подсистемы. Для выявления требований был опрошен медицинский персонал, который в дальнейшем будет работать с разрабатываемой подсистемой и на основании интервью, были сформулированы пользовательские требования, которые отражены с помощью диаграммы дерева функций, а выявленные роли были отображены в контекстной диаграмме. Третий этап включал в себя два важных аспекта функционирования информационной системы: проектирование и реализация. Первый аспект – проектирование подсистемы включал в себя анализ и разработку различных спецификаций к проектируемой системе. На данном этапе должны быть сформулированы перечни специфических особенностей проектируемой системы, а также разработаны диаграммы, отражающие ключевые моменты в процессе жизнедеятельности системы. Также были подобраны технологии и обсуждены цели и задачи каждого компонента системы. Второй аспект, подразумевал под собой создание моделей машинного обучения, разработку пользовательского интерфейса и программную реализацию всех компонентов. Для построения моделей машинного обучения

88 был произведен сбор данных с рабочих баз ОКБ-1, на основе которых происходило обучение запланированных моделей. Полученные модели были размещены на выделенном виртуальном сервере, вне контура МИС. Далее, на основе на предыдущего этапа проектирования разрабатывалась подсистема, обладающая, необходимой в рамках поставленных задач, функциональностью. Четвертый этап был отведен для документирования полученных результатов. Заключительными этапами разработки являются внедрение и эксплуатация продукта. Поскольку данная подсистема является частью единой большой системы, от которой зависит множество факторов, влияющих на процессы внутри медицинских учреждений, то вопрос об интеграции требует тщательного анализа и проверок со стороны квалифицированных экспертов. По окончанию выполнения работ можно сделать выводы о достижении предварительно поставленных целей. Благодаря разработанной системе цифровая медицина Тюменской области получила собственный инструмент, решающий индивидуальные задачи планирования работы отделения и организации очередей пациентов на оперативные вмешательства. По теме выпускной квалификационной работы была написана статья и принята к публикации в межвузовском научном сборнике «Математическое и информационное моделирование» (входит в РИНЦ), выпуск 19.

89 БИБЛИОГРАФИЧЕСКИЙ СПИСОК 1. Указ Президента Российской Федерации "О национальных целях и стратегических задачах развития российской федерации на период до 2024 года" от 07.05.2018 № 204 — Режим доступа: URL: http://www.consultant.ru/document/cons_doc_LAW_297432/ (28.05.2021) 2. McKinney W. Python for data analysis: Data wrangling with Pandas, NumPy, and IPython. – " O'Reilly Media, Inc.", 2012. 3. Асатрян А., Голиков А. Методическое пособие по эксплуатации крупных информационных систем на платформе «1С:Предприятие 8». – 2 изд. – М.: 1С-Паблишинг, 2017. – 331 с. 4. Вендров А. CASE-технологии. Современные методы и средства проектирования информационных систем. – М.: Финансы и статистика, 2005. 5. Профессиональная разработка в системе «1С:Предприятие 8». Издание 2 / Ажеронок В.А., Под ред. Радченко М.Г. – 2 изд. – М.: 1С-Паблишинг, 2012. - 1400 с. 6. Радченко М., Хрусталева Е. 1C:Предприятие 8.3. Практическое пособие разработчика. Примеры и типовые приемы. – М.: 1С-Паблишинг, 2013. – 965 с. 7. Разработка управляемого интерфейса / Ажеронок В.А., Островерх А. В., Радченко М. Г., Хрусталева Е. Ю., – М.: 1С-Паблишинг, 2010. – 723 с. 8. Международная статистическая классификация болезней и проблем, связанных со здравоохранения здоровьем (10-й Российской пересмотр) Федерации // Министерство (НСИ). URL: https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.11.1005/version/2.18 (дата обращения: 21.05.2021). 9. ASGI-сервер Uvicorn. URL: https://www.uvicorn.org/ (дата обращения: 15.04.2021). 10. FastAPI // Github. URL: https://github.com/tiangolo/fastapi (дата обращения: 15.04.2021).

90 11. Httptool // Github. URL: https://github.com/MagicStack/httptools (дата обращения: 15.04.2021). 12. IBM Cloud Pak for Data // IBM. URL: https://www.ibm.com/ruru/products/cloud-pak-for-data (дата обращения: 20.03.2021). 13. LabelEncoder // Scikit-learn. URL: https://scikit- learn.org/stable/modules/generated/sklearn.preprocessing.LabelEncoder.html (дата обращения: 02.04.2021). 14. Pandas // Pydata. URL: https://pandas.pydata.org/ (дата обращения: 01.04.2021). 15. Python object serialization Pickle // Python Software Foundation. URL: https://docs.python.org/3/library/pickle.html (дата обращения: 21.04.2021). 16. RabbitMQ. URL: https://www.rabbitmq.com/ (дата обращения: 01.05.2021). 17. The Collaboration Platform for API Development // Postman. URL: https://www.postman.com/ (дата обращения: 25.04.2021). 18. Uvloop // Github. URL: https://github.com/MagicStack/uvloop (дата обращения: 15.04.2021). 19. XGBoost Documentation // Read the Docs. URL: https://xgboost.readthedocs.io/en/release_0.90/ (дата обращения: 23.04.2021). 20. Групповая разработка // 1С:Предприятие 8. URL: http://v8.1c.ru/overview/Term_000000603.htm (дата обращения: 20.04.2021). 21. Нотации "Процесс" и "Процедура" // Документация Business Studio. URL: https://www.businessstudio.ru/wiki/docs/current/doku.php/ru/csdesign/bpmode ling/process_procedure (дата обращения: 03.05.2021). 22. Обзор системы «1С:Предприятие 8» // 1С. https://v8.1c.ru/tekhnologii/overview/ (дата обращения: 01.06.2021). URL:

91 Приложение 1 Диаграммы распределения значений показателей здоровья модели прогнозирования вероятности выздоровления

92 Приложение 2 Алгоритм добавления пациента в очередь на операцию

Рецензии:

Авторизуйтесь, чтобы добавить рецензию

Рецензия от Максим Попович

Рецензия от руководителя предприятия

около 3 лет назад

Рецензия от Максим Попович

Отзыв от научного руководителя

больше 3 лет назад

Отзывы:

Авторизуйтесь, чтобы оставить отзыв