Pracując od kilkunastu lat przy integracjach systemów medycznych, zauważyłem jedną rzecz. Problemy bardzo rzadko wynikają z technologii. Znacznie częściej ich źródłem są błędne założenia przy projektowaniu architektury.
cze 2026
Niezależnie od tego, czy mówimy o integracji HIS z laboratorium, wymianie danych przez FHIR, czy komunikacji z urządzeniami medycznymi, pewne błędy powtarzają się wyjątkowo często.
Słyszę czasem stwierdzenie:
„Przecież używamy FHIR, więc integracja będzie prosta.”
FHIR nie rozwiązuje problemów biznesowych. Definiuje sposób reprezentacji danych i komunikacji, ale nie odpowiada na pytania:
To nadal musi zostać zaprojektowane.
Jednym z najczęstszych problemów, jakie obserwuję podczas projektowania architektury systemów medycznych, jest brak jednoznacznego właściciela danych.
Na pierwszy rzut oka wszystko wygląda poprawnie. Pacjent może zmienić adres w aplikacji mobilnej, recepcjonistka w HIS, konsultant w CRM, a dodatkowo część danych synchronizowana jest z systemami zewnętrznymi.
Każdy z tych systemów potrafi zapisać nową wartość.
Problem pojawia się kilka miesięcy później.
Pacjent zgłasza, że podał nowy adres tydzień temu, jednak na skierowaniu nadal widnieje stary. CRM pokazuje jedną wartość, HIS drugą, portal pacjenta trzecią, a w hurtowni danych znajduje się jeszcze czwarta.
Technicznie wszystkie systemy działają poprawnie. Dane zostały zapisane zgodnie z zaimplementowaną logiką. Problem leży znacznie głębiej – nikt wcześniej nie zdecydował, który system jest właścicielem tej informacji.
To właśnie tutaj zaczyna się Data Governance.
W wielu organizacjach Data Governance kojarzy się z procedurami, politykami czy obowiązkami administratorów danych. W praktyce dla architekta oznacza ono przede wszystkim odpowiedź na kilka fundamentalnych pytań:
Jeżeli na etapie projektowania nie padną odpowiedzi na te pytania, prędzej czy później pojawią się niespójności.
To również częste nieporozumienie.
Nie można powiedzieć, że „HIS jest System of Record”.
Dla danych demograficznych pacjenta może nim być HIS.
Dla wyników badań laboratoryjnych – LIS.
Dla obrazów diagnostycznych – PACS.
Dla harmonogramu wizyt – system rejestracji.
Dla danych pochodzących z urządzeń medycznych – wyspecjalizowana platforma telemetryczna.
Architekt powinien patrzeć na dane domenowo, a nie systemowo. Każda domena biznesowa powinna mieć jasno określonego właściciela.
Bardzo często podczas warsztatów integracyjnych rozmawiamy o API, komunikatach FHIR, zdarzeniach czy kolejkach.
To ważne elementy rozwiązania, ale są wtórne wobec znacznie ważniejszego pytania:
Kto odpowiada za tę informację?
Dopiero gdy znamy odpowiedź, możemy świadomie zaprojektować sposób synchronizacji danych, mechanizmy publikowania zdarzeń czy strategie rozwiązywania konfliktów.
Bez tego nawet najlepiej zaprojektowane API będzie jedynie bardzo szybkim sposobem przesyłania niespójnych danych.
Diagramy często kończą się na:
Rzeczywistość wygląda inaczej.
Co jeśli:
To właśnie scenariusze wyjątków najczęściej decydują o jakości rozwiązania.
Im więcej systemów komunikuje się bezpośrednio między sobą, tym trudniej rozwijać całą platformę.
Dlatego coraz częściej warto stosować architekturę opartą o komunikaty, kolejki lub zdarzenia.
Pozwala to:
Nie oznacza to jednak, że REST jest zły. Po prostu nie każde zadanie powinno być realizowane synchronicznie.
Projekt kończy się wdrożeniem.
A później…
Telefon od klienta.
„Nie dochodzą wyniki badań.”
Jeżeli jedynym sposobem diagnozy jest przeszukiwanie logów z kilku systemów, to architektura została zaprojektowana niekompletnie.
Monitoring powinien obejmować nie tylko infrastrukturę, ale również proces biznesowy.
Architekt powinien móc odpowiedzieć na pytania:
Dobra architektura nie polega na wyborze odpowiedniego frameworka czy protokołu komunikacji.
Polega na przewidzeniu problemów, które pojawią się za rok, kiedy system będzie obsługiwał miliony komunikatów i kilkunastu partnerów.
Technologia zmienia się bardzo szybko.
Dobre decyzje architektoniczne pozostają z projektem przez wiele lat.
Komentarze (0):