Otwarte standardy komunikacji CeZ pod lupą OSSP: czas na pełną interoperacyjność procesową i koniec z vendor lock-in

Ogólnopolskie Stowarzyszenie Szpitali Prywatnych (OSSP) przekazało do Centrum e-Zdrowia (CeZ) oficjalne stanowisko konsultacyjne w sprawie projektu „Otwarte standardy komunikacji między systemami teleinformatycznymi” (wersja 0.1.0) – dokument do zapoznania. To kolejny, fundamentalny krok w wieloletnich działaniach naszego stowarzyszenia na rzecz cyfryzacji opartej na równych zasadach rynkowych, bezpieczeństwie pacjenta i efektywności operacyjnej placówek medycznych.

Od Manifestu Interoperacyjności do realnych regulacji: rys historyczny

Brak spójnej wymiany danych, sztuczne bariery integracyjne oraz uzależnienie podmiotów leczniczych od pojedynczych dostawców oprogramowania (vendor lock-in) od lat paraliżują rozwój polskiego szpitalnictwa. Ogólnopolskie Stowarzyszenie Szpitali Prywatnych już dwa lata temu zainicjowało skoordynowane działania na rzecz przełamania tego impasu.

Na początku zeszłego roku opublikowaliśmy Manifest Interoperacyjności Systemów Informatycznych w Ochronie Zdrowia, formułując w nim postulaty otwartości interfejsów, standaryzacji struktur danych oraz prawa szpitali do swobodnego zarządzania własną informacją medyczną. Obecne działania Ministerstwa Zdrowia i Centrum e-Zdrowia traktujemy jako częściową realizację postulatów środowiska i przełomowy krok we właściwym kierunku. Z pełną determinacją popieramy ten kierunek, wskazując jednocześnie w szczegółowym stanowisku techniczno-procesowym obszary, które wymagają jednoznacznego doprecyzowania.

Kluczowe postulaty OSSP do wersji 0.1.0 standardu CeZ

• Prawdziwa polityka wyjścia i suwerenność danych (Koniec z vendor lock-in): Szpital decydujący się na zmianę systemu HIS nie może stawać się zakładnikiem dotychczasowego dostawcy. OSSP domaga się ścisłego zdefiniowania pojęcia „eksportu całości danych” – obejmującego nie tylko suche tabele, ale kompletne powiązania relacyjne, słowniki lokalne, historię edycji wpisów oraz audyt autorstwa. Wymagamy eksportu w formatach otwartych (NDJSON dla profili FHIR, DICOM dla obrazów, nienaruszone HL7 CDA/PDF z podpisami elektronicznymi) wraz z raportem kompletności i sumami kontrolnymi.
• Jednoznaczny, testowalny kontrakt API: Sama publikacja profili struktury FHIR nie gwarantuje zgodności systemów. Wnosimy o bezwzględny obowiązek publikacji zasobu CapabilityStatement dla każdego systemu, precyzyjne określenie operacji (read, search), wprowadzenie parametru _lastUpdated do pobierania zmian przyrostowych oraz żelazną definicję flagi Must Support. Odrzucamy sztywne ucinanie wyników wyszukiwania (np. do 10 rekordów) na rzecz obowiązkowego stronicowania (pagination).
• Interoperacyjność procesowa – przejście od danych do opieki: Szpital nie jest statycznym magazynem danych, lecz dynamicznym środowiskiem procesowym. Standard musi wspierać:
  • Clinical Handover: Standaryzację przekazywania pacjenta i formalnego przejmowania odpowiedzialności medycznej (np. raporty pielęgniarskie, zmiany dyżurów, transfery SOR–oddział w modelu SBAR).
  • Patient Flow Management: Operacyjne zarządzanie ruchem pacjenta i rozróżnienie stanów zasobów (triage, rezerwacja, faktyczne zajęcie łóżka, zwolnienie do sprzątania).
  • Komunikację z pacjentem i zgody medyczne: Obsługę statusów dostarczenia zaleceń (Communication) oraz standaryzację odrębnych prawnie zgód na procedury medyczne (Consent).
• Korekta terminologii i oparcie na krajowych rejestrach: Wymóg natychmiastowego wdrożenia pełnego kodowania LOINC w 9 miesięcy jest w polskich laboratoriach nierealny. Wnosimy o etapowanie: w I etapie dopuszczenie kodów lokalnych przy obowiązkowych jednostkach UCUM, a LOINC w II etapie na bazie urzędowej listy badań. Jednocześnie wymagamy powiązania profili z systemami już stosowanymi w Polsce: ICD-9 PL dla procedur, numerami GTIN z Rejestru Produktów Leczniczych oraz słownikami P1.
• Bezpieczeństwo i autonomia działów IT podmiotów leczniczych: Uprawnienia do rejestracji aplikacji klienckich oraz nadawania ról w API (SMART on FHIR) muszą spoczywać w rękach lokalnych administratorów szpitala, a nie zależeć od płatnych zleceń u producenta oprogramowania.

Implementacja referencyjna HIS jako fundament ekosystemu

OSSP podtrzymuje fundamentalny postulat: Centrum e-Zdrowia powinno opracować i publicznie utrzymywać otwartą, referencyjną implementację zintegrowanego systemu HIS. Taki wzorzec pełniłby rolę poligonu doświadczalnego, środowiska testowego, platformy walidacji dla dostawców komercyjnych oraz gwaranta neutralności technologicznej rynku.

Wyrażamy głęboką nadzieję, że zaprezentowane uwagi zostaną wdrożone w kolejnej wersji standardu, a nowe przepisy będą konsekwentnie i skutecznie egzekwowane.

Stanowisko konsultacyjne Ogólnopolskiego Stowarzyszenia Szpitali Prywatnych – do pobrania i zapoznania.