W projektach produkcyjnych, między innymi dla mySugr/Roche (1M+ użytkowników, 52 kraje) i 9amHealth, integracja systemów w healthcare psuje się w przewidywalny sposób. Zespoły budują najpierw technicznie ciekawe warstwy i odkrywają kilka miesięcy później, że rozliczenia z ubezpieczycielami albo łączność z aptekami były prawdziwą bramą do przychodów. Wymagania compliance potraktowane jako zadanie na późniejszy etap stają się problemem re-architektury. Pipelines AI tworzą ekspozycję PHI, której nikt nie zamodelował. Te wzorce można uniknąć, jeśli integrację traktuje się jako constraint projektowy od samego początku.

W 2021 roku 9amHealth przyszło do nas bez kodu, z rozproszonym zespołem w Polsce, Austrii i USA oraz twardym deadline’em. Zanim napisaliśmy pierwszą linię kodu dla platformy klinicznej, spędziliśmy czas na zrozumieniu ich modelu biznesowego. Ta rozmowa wyznaczyła kolejność wszystkiego, co zbudowaliśmy potem.

Integracja systemów w healthcare nie psuje się w produkcji dlatego, że zespoły nie potrafią zaimplementować FHIR. Psuje się dlatego, że zespoły implementują FHIR, zanim zorientują się, która integracja faktycznie blokuje przychody. Oto czego nauczyło nas pięć projektów.

Pierwsza integracja, której platforma potrzebuje, to zazwyczaj ta, której nikt nie zaplanował

Założenie wchodzące w projekt 9amHealth było takie, że warstwą techniczną jest warstwa danych klinicznych: zasoby FHIR, dokumentacja pacjenta, dane od klinicystów. To były interesujące problemy.

Integracja, która musiała działać przed wszystkim innym, to przepływ e-recept i łączność z aptekami. Potem połączenia z ubezpieczycielami. Zdolność platformy do generowania przychodów zależała od tego, żeby te integracje były gotowe do produkcji, zanim warstwa kliniczna w ogóle kogokolwiek zainteresowała.

Ta sekwencja pojawia się w kolejnych projektach. Zespoły projektują warstwę interoperacyjności, a potem odkrywają, że API apteki z niepełną dokumentacją albo integracja z ubezpieczycielem na własnościowym protokole stoi między nimi a pierwszym płacącym użytkownikiem. Kiedy dzisiaj scopujemy pracę integracyjną, pierwsze pytanie brzmi: czego wymaga model biznesowy, żeby przetworzyć transakcję? Te integracje idą pierwsze.

Przenoszenie produkcyjnej bazy danych bez wyłączania systemu

Migracja mySugr pokazuje, jak wygląda integracja systemów w healthcare pod presją.

mySugr miał milion aktywnych użytkowników w 52 krajach na bazie MySQL. AWS Aurora 3 wymusiło migrację na PostgreSQL. Nie było żadnego okna na przestój. Wyłączenie systemu dotknęłoby pacjentów zarządzających cukrzycą w ponad 50 krajach.

Migracja trwała 9 miesięcy od koncepcji do produkcji. Uruchomiliśmy change data capture (CDC), żeby obie bazy danych były zsynchronizowane przez cały czas trwania migracji, przez 2 miesiące prowadziliśmy stary i nowy system równolegle przed przełączeniem ruchu, a koszty utrzymania spadły o 50% po cutoverze. Zero przestojów przez cały czas.

Lekcja wykracza poza bazy danych. Produkcyjne systemy healthcare nie mają czystego stanu. Każda integracja, która zakłada pauzę wystarczająco długą, żeby pracę wykonać czysto, zakłada warunki, które w produkcji nie istnieją. Zabudżetuj CDC. Zabudżetuj równoległe działanie. Zabudżetuj fakt, że użytkownicy generują nowe rekordy przez cały czas trwania procesu.

Wymagania compliance pominięte w architekturze ujawniają się jako problemy integracyjne podczas certyfikacji

Gdy dołączyliśmy do projektu Selfapy, jedyny mobilny developer odszedł kilka tygodni przed deadline’em certyfikacji BSI. Selfapy to aplikacja do terapii poznawczo-behawioralnej dla pacjentów z depresją i zaburzeniami lękowymi.

Bezpośredni problem to harmonogram. Problem głębszy był taki, że zgodność z BSI nie została wbudowana w architekturę danych od początku. Decyzje dotyczące kontroli dostępu, ścieżek audytowych i szyfrowania, które powinny były kształtować model danych, siedziały poza nim. Dostarczyliśmy 3 wersje zgodnie z planem i spełniliśmy ponad 120 wymagań BSI, ale retrofitowanie tych constraintów kosztowało więcej, niż gdybyśmy zbudowali je od razu.

Projekt Mentalyc pokazał ten sam punkt z innej strony. Mentalyc automatyzuje notatki z sesji terapeutycznych przy użyciu AI. Mieli developerów i zero frameworka testowego. Zbudowanie kompletnego frameworka od zera – Playwright, Cucumber BDD, Docker, GitHub Actions – skróciło czas testowania z kilku godzin do 24 minut. Ważniejsze dla integracji: testy ujawniły luki w pipeline danych, których zespół nie widział podczas codziennego shipowania.

Gdy AI przetwarza treść sesji terapeutycznej, każdy system w pipeline dotyka PHI: prompt, log inferencji, stos obserwowalności, każda warstwa cache przechowująca żądanie. HIPAA nie rozróżnia między celową a przypadkową ekspozycją. Jeśli te systemy nie są zamodelowane jako constrainty compliance od początku, audyt jest jedynym innym momentem, w którym się pojawiają.

Co „system legacy” faktycznie oznacza w praktyce

W każdym projekcie gdzieś w stacku jest system legacy. We wszystkich pięciu, które tu opisujemy, wzorzec jest ten sam: system działa, API jest częściowo udokumentowane, vendor odpowiada w 3 dni robocze, i jest co najmniej jedno pole w response payloadzie, którego nikt nie wspomniał podczas scopingu, a które napędza kluczowy workflow.

Zespoły, które wiedzą o tym z góry, budżetują sprint discovery przed zatwierdzeniem timeline’ów integracji. Zespoły, które traktują „integracja z istniejącym API” jako zadanie o stałym zakresie, zużywają ten sam czas kalendarzowy, tylko bez buforu.

W healthcare niedokumentowane zachowanie systemu legacy zazwyczaj oznacza niedokumentowane zachowanie wokół danych pacjenta. Odkrycie tego późno to jednocześnie problem z harmonogramem i problem z compliance.

Co faktycznie kosztuje pierwsze sześć miesięcy

Pierwsza integracja z nowym systemem – jeden partner, jeden zakres wymagań, jeden zakres compliance – zajmuje od 3 do 6 miesięcy od dostępu do sandbox do produkcji. Pokrycie wielu systemów trwa 12 do 24 miesięcy, w zależności od liczby wymaganych integracji i tego, czy w grę wchodzą timeline’y programów vendorskich.

Czynniki kosztowe, które są konsekwentnie niedoszacowywane: równoległe działanie podczas migracji, dokumentacja compliance i zmienność między środowiskami. Dwóch ubezpieczycieli albo dwa systemy szpitalne na tej samej platformie pokazują inne konfiguracje, inne edge case’y, inne dziwactwa danych. Ta zmienność nie pojawia się w wycenie pierwszego środowiska.

Co zrobilibyśmy inaczej w każdym projekcie

Scopować integrację jako constraint projektowy, zanim architektura zostanie podjęta. Zidentyfikować, która integracja blokuje przychody, i zbudować ją pierwszą. Zamodelować compliance jako constraint przepływu danych, nie jako checklistę certyfikacyjną. Zakładać, że każdy live system ma niedokumentowane zachowania i zarezerwować czas na ich znalezienie przed zatwierdzeniem timeline’u.

Każdy projekt, który przesunął integrację na drugi etap, spotkał ją jako problem pierwszego etapu z mniejszą ilością czasu na rozwiązanie. Architektura zbudowana wokół znanego constraintu jest szybsza do dostarczenia niż ta przebudowywana wokół constraintu odkrytego w produkcji.

Jeśli budujesz produkt digital health i chcesz przejść przez to, gdzie faktycznie siedzą Twoje ryzyka integracyjne, jesteśmy dostępni na tę rozmowę.