Досвід розробки платформи управління медичними даними FHIR для забезпечення клінічної підтримки прийняття рішень

Ілля Семенов

Роман Осенєв

Сергій Герасимов

Георгій Копаниця

2 Національний центр когнітивних досліджень, Університет ІТМО, Санкт-Петербург 197101, Росія

Дмитро Денисов

Юрій Андрейчук

Анотація

1. Вступ

Цей документ є продовженням роботи, яка спочатку була представлена до pHealth 2019—16-ї Міжнародної конференції з придатних для носіння мікро- та нанотехнологій для персоналізованого здоров’я [1].

В даний час впроваджуються системи підтримки прийняття рішень (СППР) для вирішення широкого кола клінічних та екологічних завдань. Успішне впровадження системи підтримки прийняття рішень вимагає ефективних стратегій планування, загального розуміння цілей підтримки прийняття рішень, ефективності та зручності використання. Це може збільшити прийняття та зробити загальний проект успішним [2]. Завдання, які можуть бути ефективно вирішені системами підтримки прийняття рішень, варіюються від реалізації міських планів дій щодо клімату [3] та підтримки дорожнього планування до діагностики рідкісних захворювань [4].

Індустрія охорони здоров’я дедалі більше стає спільнотою, що базується на знаннях, пов’язуючи різних постачальників, зменшуючи адміністративні витрати та покращуючи якість та безперервність медичної допомоги. Це створює виклики та можливості для клінічних систем підтримки прийняття рішень (CDSS), які полегшують процедури охорони здоров’я в умовах, заснованих на знаннях [5]. CDSS - це будь-яка комп’ютерна програма, призначена для прийняття клінічних рішень [6,7]. Це визначення демонструє різноманітність та еволюцію підтримки клінічних рішень від невеликих, цілеспрямованих програм до великомасштабних платформ, здатних зберігати та управляти медичними даними для допомоги лікарям та пацієнтам шляхом надання рекомендацій [8,9].

Для забезпечення ефективної підтримки прийняття рішень необхідно інтегрувати CDSS в інформаційні системи, які регулярно експлуатуються медичними працівниками, такими як лікарняні інформаційні системи (HIS), або пацієнтами, що розгортають свої особисті медичні записи (PHR) [10]. CDSS повинні мати можливість використовувати семантику та клінічний контекст даних, що були імпортовані з інших систем та сховищ даних [11,12,13].

Семантична взаємодія стає ключовим питанням, коли йдеться про зв'язок між різнорідними інформаційними системами [14]. Одним із способів підключення різних інформаційних систем є побудова платформи, яка обробляє стандартні медичні дані та забезпечує уніфіковані інтерфейси. Використовуючи стандарти обміну клінічними даними, такі як openEHR [15], CEN/ISO EN13606 [16,17,18], HL7 CDA [19] та ресурси швидкої оперативної взаємодії в галузі охорони здоров’я (FHIR) [14] можуть забезпечити взаємодію на рівні даних. Ці стандарти визначають загальні структури даних електронної медичної картки (EHR) [20] і широко використовуються в системах клінічної підтримки прийняття рішень [21,22]. Одним з останніх форматів специфікацій даних EHR є стандарт FHIR, який забезпечує елементи даних ("ресурси") та інтерфейс прикладного програмування (API) для отримання та обміну електронними медичними записами [23].

Сучасна екосистема медичного програмного забезпечення може характеризуватися її високими інноваційними потребами, порушуючи взаємодію між системами та перешкоджаючи семантичній взаємодії [24]. Щоб уникнути таких проблем, розробники можуть згрупувати програмні додатки в невеликі, легко підтримувані функціональні блоки, які можна змінювати на вимогу, не впливаючи на інші частини програмного забезпечення. Цей підхід зазвичай називають архітектурою мікросервісів [25].

Вказуючи стандартні інтерфейси, CDS Hooks (https://cds-hooks.org), забезпечує шаблон на основі гачка для автоматичного виклику функцій CDSS в рамках звичайних клінічних робочих процесів [26]. Ця специфікація спочатку підтримує HL7 FHIR R4 для спрощення потоку даних, забезпечуючи легку інтеграцію служб HIS та CDSS.

Досвід показує, що більшість CDSS є автономними реалізаціями, орієнтованими на один клінічний стан або робочий процес [27,28,29]. Проте впровадження складних платформ підтримки прийняття клінічних рішень, які здатні забезпечити повний спектр функціональних можливостей підтримки прийняття рішень для різних медичних інформаційних систем, все ще відсутнє. Постійно існує потреба у високоякісних, ефективних платформах, які б уніфікували розробку, розробку, презентацію, впровадження, оцінку та підтримку всіх типів можливостей підтримки клінічних рішень для клініцистів, пацієнтів [30] та інших зацікавлених сторін [31]. Ми вдосконалюємо наявний досвід впровадження платформ CDS [32], додаючи стандартні інтерфейси та структури даних для надання функцій підтримки прийняття рішень у різних екосистемах охорони здоров’я.

Метою цього дослідження є розробка платформи мікросервісів на основі FHIR, яка інтегрує HIS та CDSS в єдиний інформаційний простір.

2. Методи

2.1. Архітектура платформи

Структурно платформа CDSS була розроблена як набір окремих служб, тобто вузлів, розподілених у групах. Мікросервіси взаємодіють між собою асинхронно, використовуючи протокол зв'язку REST.

2.2. Послуги

Усі послуги працюють за державними контрактами, представленими у форматі FHIR JSON, забезпечуючи унікальний ідентифікатор ресурсу (URI) ресурсів. Послуги використовують дві моделі взаємодії: віддалений виклик процедур (RPC) та взаємодію на основі подій. Журнали надсилаються до служби центрального журналу з унікальним ідентифікатором транзакції.

Модель послуг представлена на малюнку 1. Кінцеві точки бізнес-API дозволяють надсилати запити, пов’язані зі службою, наприклад, повернути конкретні артефакти або термінологію з бази знань.

Загальна модель обслуговування платформи. API: інтерфейс прикладного програмування.

Кінцева точка API подій (наприклад, HTTP/подія) дозволяє зовнішній службі надсилати запити на події. Тож служба знає статус інших сервісів платформи.

Кінцева точка API перевірки працездатності (наприклад, HTTP/здоров'я) повертає стан обробки послуги своєму обробнику для забезпечення постійного моніторингу. Обробник кінцевої точки API виконує різні перевірки, такі як

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

статус хоста, наприклад, дисковий простір;

Бізнес-логіка - це основна частина служби, яка відповідає за реалізацію функції, для якої служба призначена, наприклад, логіка завантаження фактів з бази даних у механізм виведення.

Магазин подій та Магазин бізнес-логіки відповідають за управління та збереження даних, пов’язаних із відповідним процесом послуги.

Клієнт інших послуг відповідає за активний зв'язок з іншими службами платформи, наприклад, надсилання подій та результатів роботи.

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

2.3. Клінічне моделювання

Платформа CDSS вимагає розробки набору профілів FHIR, придатних для підтримки прийняття рішень. Ми використовували Forge (https://fhir.furore.com/forge/), офіційний редактор профілів HL7 ® FHIR ®, настільну програму для моделювання та перевірки профілів. Ми використовували ідентифікатори ідентифікаторів логічного спостереження (LOINC) [33] та систематизовану номенклатуру медицини - клінічні терміни (SNOMED CT) [34] для визначення семантики медичних понять.

В якості основного ресурсу платформи було використано «Пацієнт». Для забезпечення семантичної сумісності платформа підтримує такі ресурси FHIR R4 [35] як вхідні та вихідні дані: