5 уроків крос-кордонної інтеграції EHR
Я витратив місяці на з'єднання медичних записів пацієнтів у двох різних країнах. Я працював із провідним бізнес-аналітиком, яка мала десятирічний клінічний досвід. Її підхід змінив моє сприйняття програмного забезпечення для охорони здоров'я.
Ось п'ять уроків, засвоєних під час того проєкту.
- Мапування термінології складніше за мапування даних
Інженери часто розглядають інтеграцію як проблему схеми. Ви мапуєте поле А на поле Б — і готово. У сфері охорони здоров'я такий підхід не працює.
Одна система використовувала ICD-10, а інша — ICD-11. Вони не мають прямої відповідності. Одна система використовувала LOINC для лабораторних досліджень, тоді як інша — старі внутрішні коди.
Наш бізнес-аналітик розробила концептуальну таблицю відповідності (crosswalk), перш ніж ми почали писати код. Вона зіставила локальні коди зі стандартним набором, таким як SNOMED CT. Без цього ми б спотворили клінічний зміст.
Помилкове мапування полів створює неправильні значення. Помилкове мапування термінології створює правдоподібні, але клінічно невірні значення. Останнє набагато небезпечніше.
- Закони про дані визначають архітектуру на ранніх етапах
Я думав, що спочатку ми спроектуємо модель даних, а потім займемося відповідністю нормам. Я помилявся.
Перетин кордонів пацієнтськими даними підпадає під дію багатьох законів, таких як HIPAA або GDPR. Деякі країни забороняють виведення медичних даних за межі своїх кордонів.
Наш бізнес-аналітик почала працювати з юридичними командами на ранніх етапах. Вона визначила, які поля можна реплікувати, а які потребують деідентифікації.
Це змінило нашу архітектуру. Замість єдиної реплікованої бази даних ми побудували шар федеративних запитів. Ми додали теги класифікації даних безпосередньо в нашу схему.
Залучайте експертів із комплаєнсу та бізнес-аналітика ще до того, як почнете проектувати модель даних.
- Стандартів недостатньо
Обидві системи підтримували HL7. Однак одна використовувала HL7 v2, а інша — FHIR R4. Вони не могли взаємодіяти без шару трансляції.
Навіть у межах FHIR ми зіткнулися з невідповідністю профілів. Обидві системи заявляли про відповідність стандартам, але використовували різні інструкції з впровадження.
Не вважайте, що інтеграція буде легкою лише тому, що система підтримує стандарт. Завжди запитуйте про конкретну версію та профіль. Заплануйте час на створення шару адаптера.
- Діаграми робочих процесів виявляють приховані граничні випадки
Раніше я вважав діаграми робочих процесів зайвою документацією. Я помилявся.
Наш бізнес-аналітик детально розробила схеми переведення пацієнтів. Вона проаналізувала, що відбувається, коли пацієнта переводять під час лікування або коли результати лабораторних досліджень надходять після виписки.
У лікарні це не граничні випадки. Це трапляється щодня.
Ці діаграми змінили нашу модель даних. Ми додали концепцію епізоду лікування, щоб відстежувати безперервну допомогу в обох системах.
- Створіть спільний глосарій на ранніх етапах
Такі слова, як encounter або discharge, мають різні значення в різних системах. Ми витрачали час даремно, бо команди по-різному інтерпретували терміни.
Наш бізнес-аналітик створила спільний глосарій. Кожен стейкхолдер переглянув і погодив ці визначення. Ми посилалися на цей документ у кожній вимозі.
Припускайте, що кожен галузевий термін є неоднозначним. Визначте його в документі, який підпишуть обидві сторони.
Підсумок
Сильний бізнес-аналітик робить більше, ніж просто пише тікети. Вони виступають архітекторами регуляторних обмежень та клінічного змісту. Якщо ви розробляєте складне програмне забезпечення, не сприймайте цю роль як додаткові витрати. Вона запобігає ситуації, коли технічний успіх стає клінічною невдачею.
Додаткова спільнота для навчання: https://t.me/GyaanSetuAi