FHIR nie rozwiązał interoperacyjności w ochronie zdrowia

Nowy założyciel health-tech czyta o FHIR po raz pierwszy i na chwilę robi mu się optymistycznie. Jest standard. Standard jest nowoczesny. Standard jest oparty na REST, ma kształt JSON i uwierzytelnianie OAuth. Z pewnością oznacza to, że integracja EHR jest rozwiązanym problemem.

Potem rzeczywiście integruje się ze swoim pierwszym EHR i w ciągu tygodnia optymizm znika. Standard istnieje. Implementacje się z nim nie zgadzają. Przepaść między „kompatybilny z FHIR" na stronie marketingowej a „działa z tym konkretnym wdrożeniem Epic" w praktyce jest ogromna — i to tam żyje właściwa praca integracyjna.

Do czego FHIR jest dobry

Sam standard to prawdziwe osiągnięcie. Definiuje kształty zasobów dla encji ważnych w ochronie zdrowia — pacjenci, obserwacje, schorzenia, leki, wizyty — w sposób dość nowoczesny, dość rozszerzalny i znacznie bardziej praktyczny niż alternatywy, które były przed nim.

Jeśli budujesz od zera, FHIR to właściwy wybór. Twój wewnętrzny model danych i tak skończy wyglądając jak FHIR, nawet jeśli nie zaczniesz od niego — więc zaczynanie od niego oszczędza nieuchronnego przepisywania.

Jeśli budujesz ogólne narzędzie, które konsumuje „dane FHIR" nie zważając na to, z którego systemu pochodzą, standard daje Ci może 80 procent drogi. Do demo, prototypów i pracy akademickiej to wystarczy.

Gdzie zaczyna się problem

Problem zaczyna się, gdy musisz rozmawiać z prawdziwym EHR w prawdziwej sieci szpitalnej. Są trzy odrębne luki.

Luka specyficzna dla vendora. Epic, Cerner, Meditech i Athena — wszyscy udostępniają endpointy FHIR. Nie wszystkie udostępniają ten sam FHIR. Każdy ma własne dziwactwa — pola wymagane przez standard, ale nieobecne w ich danych; rozszerzenia istniejące w ich wersji, ale nigdzie indziej; pola wypełniane różnymi znaczeniami w różnych wdrożeniach. Kliszą w branży jest „jeśli widziałeś jedno wdrożenie Epic, widziałeś jedno wdrożenie Epic." To klisza, bo jest prawdą.

Luka specyficzna dla wdrożenia. Nawet w obrębie jednego vendora każdy szpital konfiguruje system inaczej. Dwa wdrożenia Epic w dwóch różnych systemach ochrony zdrowia zwrócą dane zgodne ze standardem, ale znaczące subtelnie inne rzeczy. Sposób, w jaki jeden ośrodek używa konkretnego kodu obserwacji, może pokrywać się z tym, jak inny używa zupełnie innego. Bez lokalnej wiedzy klinicznej dane są jednocześnie poprawne i niezrozumiałe.

Luka danych historycznych. FHIR jest nowoczesny. Dane nie są. Większość danych klinicznych w każdym produkcyjnym EHR poprzedza erę FHIR i była pierwotnie kodowana w HL7 v2, ICD-9, niestandardowych słownikach lub wolnym tekście. Endpoint FHIR siedzi nad warstwą tłumaczenia, a ta warstwa jest niekompletna, stratna i pełna przypadków brzegowych. Zapytanie „jakie leki kiedykolwiek brał ten pacjent?" przez FHIR da Ci listę. Czy lista jest kompletna, to oddzielne pytanie — i odpowiedź prawie zawsze brzmi: nie.

Co faktycznie działa

Dostarczyliśmy wiele integracji EHR. Kilka rzeczy, które się sprawdziły.

Traktuj FHIR jako punkt startowy, nie kontrakt. Zbuduj swój model domeny tak, jak powinien wyglądać. Następnie zbuduj warstwę translacji między FHIR a Twoim modelem i traktuj tę warstwę jako najbardziej kruchą, najlepiej przetestowaną część swojej bazy kodu. Bo taką jest.

Testuj na prawdziwych (zdeidentyfikowanych) danych, nie na sandboxie. Sandboxi vendorów zawierają wyidealizowane dane, których dział marketingu vendora nie musiałby się wstydzić. Dane produkcyjne tak nie wyglądają. Uzyskaj dostęp do reprezentatywnych prawdziwych danych — zanonimizowanych, z właściwymi BAA — i uruchom swój kod na nich przed wdrożeniem. Błędy, które w ten sposób znajdziesz, to błędy, które Twoi klienci znaleźliby w pierwszym tygodniu.

Buduj z graceful degradation, nie dla kompletności. Niektórzy pacjenci będą mieli dane. Niektórzy nie. Niektóre pola będą wypełnione. Niektóre nie. Większość oprogramowania medycznego zawodzi w produkcji nie dlatego, że dane są złe, ale dlatego, że oprogramowanie zakłada obecność danych, których nie ma. Koduj defensywnie, uczciwie sygnalizuj luki użytkownikom i nigdy po cichu nie domyślaj się „brak wartości", gdy odpowiedź mogłaby brzmieć „nie wiemy."

Miej kogoś z biegłością kliniczną w zespole. Dane są medyczne. Decyzje o tym, co zrobić, gdy dane są niejednoznaczne, to decyzje medyczne. Jeśli Twój zespół nie odróżni klinicznie istotnej luki od nieistotnej, produkt będzie po cichu podejmował decyzje, których żaden klinicysta by nie zaakceptował.

Uczciwe podsumowanie

FHIR nie rozwiązał interoperacyjności w ochronie zdrowia. Umożliwił pracę następnej dekady — co jest inną i dokładniejszą rzeczą do powiedzenia. Faktyczna praca integracyjna — ta, która zabiera czas, ta, która trzyma produkcję razem — siedzi na szczycie FHIR, nie wewnątrz niego. Ktokolwiek twierdzi inaczej albo nie dostarczył prawdziwej integracji, albo właśnie ją sprzedaje.