Введение. Проблемы в области здравоохранения являются одними из самых острых в современном обществе. Количество различных проявлений и осложнений заболеваний непрерывно растет, и врачи вынуждены запоминать огромные объемы информации по разным областям медицинских знаний. Приходится учитывать различные факторы: особенности пациента и течения заболевания, показания и противопоказания методики обследования или способа лечения, усиление влияния или совместимость лекарственных препаратов, индивидуальную лекарственную непереносимость у па- циента и многое другое. Держать это в памяти и своевременно принимать правильные решения становится все сложнее [1, 2]. Как следствие, возникают врачебные ошибки, приводящие к негативным последствиям.

В настоящее время активно внедряются всевозможные медицинские информационные си- стемы (МИС). Однако такие системы не име- ют функциональных возможностей поддержки принятия врачебных решений и формализации медицинских клинических документов и процессов [3]. Во многих МИС отсутствует или лишь частично реализован формализованный ввод электронной медицинской карты (ЭМК) пациента. Большинство из них являются системами поддержки организационных процессов больницы [4]. Для сокращения же врачебных ошибок нужны системы поддержки принятия врачебных решений (СППВР) [5, 6]. Однако системы поддержки таких процессов практической деятельности врача, как, например, диагностика или мониторинг лечения, могут обрабатывать истории болезни только в формализованном виде.

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

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

Большинство клинических данных вводится в МИС в неформализованном виде, что является серьезным ограничением для их интеграции с СППВР. При этом формализация ЭМК представляет собой отдельную большую задачу.

Одно из решений указанной проблемы – использование онтологического подхода. Медицинская онтология охватывает множество терминов этой предметной области и задает семантическую структуру для формирования медицинской информации. ЭМК или истории болезни пациентов формируются по этой фиксированной структуре, каждый элемент которой имеет указанный смысл. Базы знаний заполняются конкретными знаниями, например, о диагностике заболеваний, и ограничены в объемах.

Активное развитие мобильных технологий располагает к тому, чтобы СППВР были адаптированы и к мобильным устройствам. В ряде проектов мобильные приложения интегрированы в процесс наблюдения за пациентом, предоставляя возможность упростить самоконтроль, прием препаратов и давая предварительную аналитику внесенных данных [7, 8].

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

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

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

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

В данной работе представлен подход к генерации динамического интерфейса мобильного приложения для заполнения формализованных данных истории болезни пациента на основе онтологического подхода. Под динамическим интерфейсом будем понимать интерфейс, который не зависит от конкретного количества возможных данных для ввода информации в ЭМК, а сами данные (жалобы, инструментальные  и лабораторные исследования, объективное состояние и др.) могут изменяться в зависимости от заболевания без изменения программного кода интерфейса.

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

В Институте автоматики и процессов управления ДВО РАН реализована облачная платформа IACPaaS, которая удаленно доступна (https://iacpaas.dvo.ru) пользователям для разработки, управления и использования интеллектуальных ресурсов. Платформа поддер- живает модели облачных вычислений PaaS  и SaaS, предлагает средства поддержки разработки прикладных интеллектуальных облачных сервисов с реализацией решателей задач как совокупности программных единиц на Java. Платформа IACPaaS отличается от осталь- ных облачных платформ тем, что поддерживает свойство объяснения полученных результатов.

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

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

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

Формализация медицинских  клинических документов

Для наполнения ЭМК создана семантическая структура (одна из частей медицинской онтологии), в которой заданы семантически значимые отношения между идентификатором пациента и основными характеристиками его состояния и истории развития, включая множество номеров задокументированных историй болезни. Для отдельной истории болезни заданы семантически значимые отношения с ее клинически важными элементами. Все это описывает состав и формат документа, ограничения и правила формирования (http://www. swsys.ru/uploaded/image/2024-3/2.jpg), что позволяет иметь формализованные данные пациентов (на платформе IACPaaS), пригодные для компьютерной обработки. По данному формату и онтологии на платформе реализовано множество ресурсов – коллекций и архивов ЭМК, отдельных историй болезни по целому спектру нозологий, взятых из публикаций и реальной практики.

Сами ЭМК содержат конкретные данные о пациенте, которые вносятся пользователями приложения – врачами. Фрагмент ЭМК пациента на платформе IACPaaS:

▼ Боль в грудной клетке – [Признак]

   ► Характер – [Характеристика]

▼ Общая слабость – [Признак]

   ► Выраженность – [Характеристика]

▼ Объективное состояние 

   ▼ Общий осмотр

► Индекс массы тела – [Признак]

► Артериальное давление – [Признак]

► Положение больного – [Признак]

   ▼ Осмотр по системам

    ▼ Система кровообращения

     ▼ Фракция выброса левого желудочка – [Признак]

       ▼ Числовые значения

57.0%

       ► Частота сердечных сокращений – [Признак]

Для удаленной диагностики пациентов с мобильных телефонов разумно ориентироваться на работу с ЭМК. Через мобильный интерфейс можно заполнить ее конкретными данными, основываясь на структуре, заданной  в онтологии карты. Формализованное заполнение данных в ЭМК необходимо для последующей диагностики на платформе IACPaaS.

Подход к решению проблемы генерации пользовательского интерфейса  ЭМК пациента

Структура ЭМК (в рамках онтологии медицины), а также содержащихся в ней историй болезни состоит из множества различных элементов, таких как «Анамнез жизни», «Паспортная часть», «Результаты исследований» и др. Из-за ограничений в размере экрана смартфона невозможно создать удобный интерфейс заполнения ЭМК и текущей истории болезни сразу для всей содержательной структуры, описанной в онтологии. Поэтому был предложен иной подход к генерации интерфейса.

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

При заполнении конкретной ЭМК пациентов на основе рассматриваемой онтологии можно выделить три основных типа элементов:

– данные (элементы, не имеющие дочерних элементов в структуре онтологии);

– секции (элементы, имеющие некоторое множество дочерних элементов в структуре онтологии);

– элементы онтологии (незаполненные элементы ЭМК).

Каждый слой, отображаемый в приложении, визуализирует эти основные типы элементов:

▼ИБ Тест 2
19.04.2023-11:31:00 000 – [дата обращения]	Данные
► Паспортная часть ► Жалобы ► Объективное состояние ► Результаты компьютерного назначения лечения	Секции
► [ Анамнез жизни ] ► [ История настоящего  заболевания ] ► [ Исследования  лабораторные ] ► [ Исследования  инструментальные ]	Элементы  онтологии

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

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

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

В ответ на запрос с платформы придет JSON-структура запрашиваемого ресурса. Это ресурс «Архив ИЭМК v.4», созданный по онтологии, в нем содержатся конкретные данные  о медицинских картах и историях болезни пациентов, о состоянии их здоровья, заболеваниях и результатах лечения:

{

“title”: “Архив ИЭМК v.4”,

“path”: democardio@mail.ru/Мой

Фонд/Загрузки/ Архив ИЭМК v.4$;”,

“name”: “Архив ИЭМК v.4”,

“successors”: [

{

“name”: “ЭМК-q0e11”,

“type”: “НЕТЕРМИНАЛ”,

“meta”: “Онтология электронной

медицинской карты V.4”,

“successors”:   [ ]

},

{

“name”: “ЭМК-med-books.by”,

“type”: “НЕТЕРМИНАЛ”,

“meta”: “Онтология электронной

медицинской карты V.4”,

“successors”:   [ ]

},

].

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

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

После отображения интерфейса корневого слоя ЭМК в приложении можно передвигаться к следующему слою при нажатии на интересующий слой (http://www.swsys.ru/uploaded/image/ 2024-3/3.jpg).

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

Генерация динамического интерфейса на основе слоя данных ЭМК происходит в два этапа: на первом этапе по данным ЭМК формируются модели интерфейса, а на втором по моделям интерфейса формируется и визуализируется сам пользовательский интерфейс.

Технология динамической генерации  пользовательского интерфейса ЭМК

Интерфейс должен позволять заполнять данные в ЭМК пациента в формализованном виде. Распространено мнение, что не все данные ЭМК можно представить формализованно, в частности, во внедряемых на рабочие места врачей МИС анамнез жизни и даже анамнез заболевания принципиально представляются в виде текстов на естественном языке. Однако  на медицинском портале платформы IACPaaS эксплуатируется обширный справочник медицинской терминологии и наблюдений, с применением которого все факты о пациенте структурируются (http://www.swsys.ru/uploaded/image/ 2024-3/4.jpg).

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

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

Алгоритм генератора интерфейса состоит из трех основных шагов:

– определение принадлежности элемента из ЭМК к элементу пользовательского интерфейса;

– формирование модели пользовательского интерфейса из модели элемента ЭМК;

– формирование самого интерфейса в зависимости от модели пользовательского интерфейса.

Схема работы алгоритма представлена на рисунке 3.

Элементы отображаемого слоя ЭМК обрабатываются конструктором. Каждый элемент проходит проверку на соответствие элементу пользовательского интерфейса, при совпадении по элементу ЭМК строится модель пользовательского интерфейса. Пройдя проверку, все модели слоя ЭМК становятся моделями интерфейса, по которым впоследствии будет отображен сам интерфейс для наполнения конкретными жалобами и другими признаками пациента («Головная боль», «Беспокойство», «Боль в грудной клетке», «Температура» и т.п.) и фактами («Пол», «Возраст»). Конкретные названия всех признаков и фактов и их составных частей, а также все возможные значения хранятся в справочнике медицинской терминологии  и наблюдений IACPaaS для описания с их помощью конкретных состояний пациента.

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

Содержимое справочника медицинской тер- минологии и сохраняемую ЭМК мобильное приложение получает с платформы IACPaaS  по протоколу HTTP посредством отправки соответствующих запросов. Такой способ получения информации доступен благодаря реализации удаленного взаимодействия на платформе [9].

Все признаки и факты проходят через конструктор интерфейсов, где в первую очередь определяется тип элемента – факт или признак, а далее – простой это элемент или составной. Эти два свойства создают четыре варианта элемента: простой факт, составной факт, простой признак, составной признак.

Каждый вариант имеет проверку на соответствие и собственный конструктор, который в случае успешной проверки сможет создать необходимую модель интерфейса из модели данных платформы IACPaaS (рис. 4).

Сформированные модели пользовательского интерфейса состоят только из тех данных, которые необходимы для отображения конкретных элементов интерфейса, то есть они отделяют данные базы от данных, необходимых для отображения:

{

“Name”: “дата обращения”,

“Value”: “10.20.2022-12:01:33.000”,

“ComponentType”: “Date”,

}

 

{

“Name”: “Боль в глазу”,

“ComponentType”: “AttributeFact”,

“Characteristics”: [{

“Name”: “Присутствие”,

“Value”: [“Имеется”]

}, {

“Name”: “Локализация”,

“Value”: [“Правый глаз”, “Левый глаз”]

} ]

}.

{

“Name”: “Жалобы”,

 “ComponentType”: “Section”,

}

{

“Name”: “Беспокойство”,

“ComponentType”: “AttributeFact”,

“Value”: [“Имеется”]

}

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

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

Интерфейс, сгенерированный по своим моделям, визуализируется в мобильном приложении (http://www.swsys.ru/uploaded/image/2024-3/5.jpg). Реализованное мобильное приложение, используя инструменты взаимодействия с внешними системами, обменивается данными с интеллектуальной платформой IACPaaS [10].

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

С помощью создаваемых приложений врачи могут заполнять ЭМК пациентов в формализованном виде и проводить их диагностику как поддержку в принятии более точных и обоснованных решений, что на сегодня очень актуально [2, 5, 6]. Это отличает разрабатываемые в рамках предложенной технологии приложения с возможностью ввода любых текущих данных, готовых для машинной интерпретации, от распространенных раз- работок с фиксированным шаблоном для ввода данных пациента [7, 8]. Их интерфейсы позволяют легко вводить формализованные данные в условиях развиваемой предметной области: ба- за терминов может расширяться, в структуру ЭМК могут добавляться разделы.

Мобильная оболочка  по диагностике заболеваний

Подход и реализованная на платформе IACPaaS оболочка для создания СППВР по диагностике заболеваний независимо от их группы описаны в работе [10]. С использованием этой оболочки реализованы различные системы и сервисы поддержки врачебных решений. В данной статье предложено расширение разработанного ранее продукта – мобильная версия оболочки.

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

В рамках тестирования реализованной мобильной оболочки были созданы два приложения по диагностике – вирусных и кардиозаболеваний. Оба приложения независимые и позволяют осуществлять удаленную диагностику ЭМК пациентов. Они опубликованы в магазине мобильных приложений RuStore и находятся в общем доступе.

Заключение

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

При этом проблемами для мобильных устройств являются возможность вводить большой объем информации в формализованном виде и взаимодействие с ресурсоемкими компонентами СППВР (на удаленном сервере). Учитывая, что история болезни и ЭМК содержат много разделов с вложенной структурой, а количество потенциальных данных для ввода – десятки тысяч, методы их преодоления исключительно актуальны.

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

Такой подход позволил добиться

– гибкости в создании интерфейса в приложении;

– независимости от медицинской терминологии;

– повторного использования интерфейса;

– дальнейшего легкого сопровождения;

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

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

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

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

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

1.   Гусев А.В., Зарубина Т.В. Поддержка принятия врачебных решений в медицинских информационных системах медицинской организации // Врач и информационные технологии. 2017. № 2. С. 60–72.

2.   Мухаметшина В.Р. Системы поддержки принятия решений в медицине // Научные исследования молодых ученых: сб. ст. 2022. С. 22–24.

3.   Вафин Р.Р., Насыров Р.В. Разработка интерфейса системы поддержки принятия врачебных решений для комплексного обеспечения медицинского технологического процесса // Методы компьютерной диагностики в биологии и медицине. 2020. С. 64–67.

4.   Михеев А.Е., Фохт О.А., Хаткевич М.И. Один из подходов к формализации процесса внедрения МИС  в медицинской организации // Врач и информационные технологии. 2018. № 5. С. 46–62.

5.   Гончарова А.Б., Сергеева Е.И. Построение системы поддержки принятия решений в медицине // Интеграция наук. 2019. № 1. С. 272–274.

6.   Фролов С.В., Куликов А.Ю., Остапенко О.А., Стрыгина Е.В. Системы поддержки врачебных решений  в медицине // Научный журнал. 2018. № 9. С. 9–16.

7.   Omboni S. Connected health in hypertension management. Front. Cardiovasc. Med., 2019, vol. 6, art. 76.  doi: 10.3389/fcvm.2019.00076.

8.   Postel-Vinay N., Steichen O., Pebelier E. et al. Home blood pressure monitoring and e-Health: Investigation of patients’ experience with the Hy-Result system. Blood Pressure Monitoring, 2020, vol. 25, no. 3, pp. 155–161.  doi: 10.1097/MBP.0000000000000436.

9.   Тимченко В.А., Грибова В.В., Федорищев Л.А., Москаленко Ф.М. Технология взаимодействия сервисов облачной платформы IACPaaS с внешним программным обеспечением // Программные продукты и системы. 2018. Т. 31. № 2. С. 233–238. doi: 10.15827/0236-235X.122.233-238.

10. Грибова В.В., Федорищев Л.А. Онтологический подход к генерации адаптивных WIMP-интерфейсов редакторов баз знаний // КИИ-2018: тр. конф. 2018. Т. 1. С. 19–26.

References

1. Gusev, A.V., Zarubina, T.V. (2017) ‘Clinical decisions support in medical information systems of a medical organization’, Medical Doctor and Information Technologies, (2), pp. 60–72 (in Russ.).

2. Mukhametshina, V.R. (2022) ‘Decision support systems in medicine’, Proc. Conf. Sci. Research of Young Scientists, pp. 22–24 (in Russ.).

3. Vafin, R.R., Nasyrov, R.V. (2020) ‘Development of the interface of the system for supporting medical decision-making for complex provision of medical technological process’, Computer Diagnostic Methods in Biology and Medicine, pp. 64–67 (in Russ.).

4. Mikheev, A.E., Foght, O.A., Khatkevich, M.I. (2018) ‘One of approaches to formalization of the HIS deployment in healthcare institution’, Medical Doctor and Information Technologies, (5), pp. 46–62 (in Russ.).

5. Goncharova, A.B., Sergeeva, E.I. (2019) ‘Medicine decision support system design’, Integration of Sci., (1), pp. 272–274 (in Russ.).

6. Frolov, S.V., Kulikov, A.Yu., Ostapenko, O.A., Strygina, E.V. (2018) ‘Medical decision support systems in medicine’, Scientific J., (9), pp. 9–16 (in Russ.).

7. Omboni, S. (2019) ‘Connected health in hypertension management’, Front. Cardiovasc. Med., 6, art. 76. doi: 10.3389/fcvm.2019.00076.

8. Postel-Vinay, N., Steichen, O., Pebelier, E. et al. (2020) ‘Home blood pressure monitoring and e-Health: Investigation of patients’ experience with the Hy-Result system’, Blood Pressure Monitoring, 25(3), pp. 155–161. doi: 10.1097/ MBP.0000000000000436.

9. Timchenko, V.A., Gribova, V.V., Fedorishchev, L.A., Moskalenko, F.M. (2018) ‘Technology of interaction of IACPaaS cloud platform services with external software’, Software & Systems, 31(2), pp. 233–238 (in Russ.). doi: 10.15827/0236-235X.122.233-238.

10. Gribova, V.V., Fedorishchev, L.A. (2018) ‘An ontological approach to the generation of adaptive WIMP interfaces of knowledge base editors’, Proc. RCAI-2018, 1, pp. 19–26 (in Russ.).