FHIR не вирішив проблему медичної інтероперабельності

Новий health-tech засновник вперше читає про FHIR і ненадовго стає оптимістом. Є стандарт. Стандарт сучасний. Стандарт заснований на REST, у форматі JSON та з аутентифікацією через OAuth. Напевно, це означає, що інтеграція з EHR — вирішена проблема.

Потім вони реально інтегруються з першим EHR — і вже через тиждень оптимізм зникає. Стандарт існує. Реалізації між собою не погоджуються. Прірва між "FHIR-сумісним" на маркетинговій сторінці та "спілкується з цим конкретним розгортанням Epic" на практиці є величезною, і саме там живе реальна робота з інтеграції.

Для чого FHIR корисний

Сам стандарт — справжнє досягнення. Він визначає форми ресурсів для сутностей, що мають значення в охороні здоров'я — пацієнти, спостереження, стани, ліки, зустрічі — способом, що є достатньо сучасним, достатньо розширюваним і набагато зручнішим за попередні альтернативи.

Якщо ви будуєте з нуля — FHIR є правильним вибором. Ваша внутрішня модель даних все одно закінчиться схожою на FHIR, навіть якщо ви не почнете з неї, тому починаючи з неї ви уникаєте неминучого переписування.

Якщо ви будуєте загальний інструмент, що споживає "FHIR-дані" без прив'язки до конкретної системи — стандарт проводить вас приблизно на 80 відсотків шляху. Для демо, прототипів і академічної роботи цього достатньо.

Де починаються проблеми

Проблеми починаються, коли вам потрібно говорити з реальним EHR у реальній лікарняній мережі. Є три окремі прірви.

Специфічна для постачальника прірва. Epic, Cerner, Meditech і Athena — всі надають FHIR endpoint-и. Але FHIR у них не однаковий. Кожен має власні особливості: поля, обов'язкові за стандартом, але відсутні в їхніх даних; розширення, що існують у їхній версії, але ніде більше; поля, наповнені різними значеннями в різних розгортаннях. Кліше в галузі — "якщо ви бачили один Epic, ви бачили один Epic." Це кліше, бо правда.

Специфічна для розгортання прірва. Навіть в рамках одного постачальника кожна лікарня налаштовує систему по-своєму. Два розгортання Epic у двох різних медичних системах повертатимуть дані, що відповідають стандарту, але мають тонко різні значення. Спосіб, яким один сайт використовує певний код спостереження, може перетинатися з тим, як інший сайт використовує зовсім інший. Без локальних клінічних знань дані одночасно правильні і незрозумілі.

Прірва історичних даних. FHIR сучасний. Дані — ні. Більшість клінічних даних у будь-якому виробничому EHR передує епосі FHIR і спочатку була закодована в HL7 v2, ICD-9, власних словниках або вільному тексті. FHIR endpoint стоїть над шаром трансляції, а шар трансляції є неповним, з втратами і повним граничних випадків. Питання "які ліки приймав цей пацієнт?" через FHIR дасть вам список. Чи повний цей список — окреме питання, і відповідь майже завжди "ні."

Що реально працює

Ми відправили в продакшн чимало EHR-інтеграцій. Кілька речей, що витримали перевірку часом.

Ставтеся до FHIR як до відправної точки, а не контракту. Будуйте доменну модель так, як вона має виглядати. Потім будуйте шар трансляції між FHIR і вашою моделлю і ставтеся до нього як до найбільш крихкої та найбільш протестованої частини кодової бази. Бо так і є.

Тестуйте на реальних (деідентифікованих) даних, а не в sandbox. Sandbox постачальника містить ідеалізовані дані, яких маркетингова команда не соромиться. Виробничі дані так не виглядають. Отримайте доступ до репрезентативних реальних даних — анонімізованих, з відповідними BAA — і запустіть свій код на них до виходу в продакшн. Баги, які ви знайдете так, — це ті самі баги, які ваші клієнти знайшли б на першому тижні.

Будуйте для поступової деградації, а не для повноти. В одних пацієнтів дані будуть. В інших — ні. Одні поля будуть заповнені. Інші — ні. Більшість медичного ПЗ зазнає невдачі у виробництві не тому, що дані неправильні, а тому що ПЗ припускає наявність даних, яких немає. Пишіть захисний код, чесно повідомляйте користувачів про прогалини і ніколи мовчки не замінюйте "без значення" на "ми не знаємо."

Майте в команді людину з клінічними знаннями. Дані медичні. Рішення про те, що робити, коли дані неоднозначні, — це медичні рішення. Якщо ваша команда не може відрізнити клінічно значущу прогалину від незначущої — продукт тихо прийматиме рішення, які жоден клініцист не схвалить.

Чесне резюме

FHIR не вирішив проблему медичної інтероперабельності. Він зробив можливим наступне десятиліття роботи — це інша і точніша річ для сказу. Реальна інтеграційна робота — та, що займає час, та, що тримає виробництво — знаходиться поверх FHIR, а не всередині нього. Будь-хто, хто каже інакше, або не відправляв реальної інтеграції, або продає її.