5 wniosków z transgranicznej integracji systemów EHR

Spędziłem miesiące na łączeniu rekordów pacjentów w dwóch różnych krajach. Współpracowałem z Lead Business Analyst z dziesięcioletnim doświadczeniem klinicznym. Jej podejście zmieniło sposób, w jaki patrzę na oprogramowanie medyczne.

Oto pięć lekcji wyciągniętych z tego projektu.

  1. Mapowanie terminologii jest trudniejsze niż mapowanie danych

Inżynierowie często traktują integrację jako problem schematu. Mapujesz pole A do pola B i gotowe. W opiece zdrowotnej to nie działa.

Jeden system używał ICD-10, a drugi ICD-11. Nie da się ich łatwo dopasować. Jeden system używał LOINC dla wyników laboratoryjnych, podczas gdy drugi korzystał ze starych, wewnętrznych kodów.

Nasza BA stworzyła mapowanie pojęć (concept crosswalk), zanim napisaliśmy kod. Przypisała lokalne kody do standardowego zestawu, takiego jak SNOMED CT. Bez tego doszłoby do zniekształcenia znaczenia klinicznego.

Błędne mapowanie pól tworzy nieprawidłowe wartości. Błędne mapowanie terminologii tworzy wartości prawdopodobne, ale klinicznie błędne. To drugie jest znacznie groźniejsze.

  1. Przepisy dotyczące danych kształtują architekturę na wczesnym etapie

Myślałem, że najpierw zaprojektujemy model danych, a kwestie zgodności (compliance) zajmiemy się później. Myliłem się.

Dane pacjentów przekraczające granice podlegają pod wiele przepisów, takich jak HIPAA czy RODO (GDPR). Niektóre kraje zabraniają przesyłania danych medycznych poza ich granice.

Nasza BA od początku współpracowała z zespołami prawnymi. Zdecydowała, które pola mogą być replikowane, a które wymagają deidentyfikacji.

To zmieniło naszą architekturę. Zamiast pojedynczej replikowanej bazy danych, zbudowaliśmy warstwę federowanych zapytań (federated query layer). Dodaliśmy tagi klasyfikacji danych bezpośrednio do naszego schematu.

Zanim zaprojektujesz model danych, zaproś do rozmów ekspertów od zgodności i BA.

  1. Standardy to za mało

Oba systemy obsługiwały HL7. Jednak jeden używał HL7 v2, a drugi FHIR R4. Nie mogły ze sobą „rozmawiać” bez warstwy tłumaczącej.

Nawet w ramach FHIR napotkaliśmy niezgodności profili. Oba systemy deklarowały zgodność, ale używały innych wytycznych implementacyjnych (implementation guides).

Nie zakładaj, że integracja będzie łatwa tylko dlatego, że system obsługuje dany standard. Zawsze pytaj o konkretną wersję i profil. Zaplanuj czas na stworzenie warstwy adaptera.

  1. Diagramy przepływu pracy wyłapują ukryte przypadki brzegowe

Kiedyś uważałem diagramy przepływu pracy za zbędną dokumentację. Myliłem się.

Nasza BA szczegółowo rozpisała procesy przekazywania pacjentów. Sprawdziła, co się dzieje, gdy pacjent zostaje przeniesiony w trakcie leczenia lub gdy wynik badań laboratoryjnych przychodzi po wypisie ze szpitala.

W szpitalu nie są to przypadki brzegowe. One zdarzają się codziennie.

Te diagramy zmieniły nasz model danych. Dodaliśmy koncepcję epizodu opieki (care episode), aby śledzić ciągłość opieki w obu systemach.

  1. Stwórz wspólny glosariusz na wczesnym etapie

Słowa takie jak „encounter