Nasze uwagi do standardu CeZ: sześć rzeczy, których sam format nie rozstrzyga

Do 31 października 2026 Centrum e-Zdrowia zbiera uwagi do projektu otwartych standardów komunikacji między systemami w ochronie zdrowia. 27 października wysłaliśmy nasze: sześć uwag na dwóch stronach, każda z propozycją, jak sprawdzić jej spełnienie. Pełny tekst uwag udostępniamy w wersji wysłanej do CeZ. Można z niego korzystać przy własnym zgłoszeniu.

Jak czytałem projekt

Przeczytałem cały opublikowany pakiet w wersji roboczej 0.1.0, opartej na FHIR R4: 36 definicji struktur danych, czyli 30 profili zasobów i 6 rozszerzeń. Przy każdym elemencie oddzielałem ograniczenia dodane przez CeZ od reguł odziedziczonych z bazowego FHIR R4. Bez tego łatwo uznać za brak coś, co standard bazowy już rozstrzyga.

Projekt dobrze porządkuje format danych. To, czy wdrożenie zadziała między różnymi systemami, zależy jednak od sześciu rzeczy, których sam format nie rozstrzyga. Warto je sprawdzić niezależnie od tego, czy zgłasza się własne uwagi. Przy każdej piszę, co projekt już ma, czego w nim brakuje i jak to sprawdzić.

1. Korekty

Jak system odbiorcy dowie się, że wynik poprawiono albo dokument unieważniono, i jak wznowić pobieranie po przerwie bez luk i bez duplikatów.

• Co już jest: identyfikatory, wersje i statusy zasobów. Bazowy FHIR opisuje wyszukiwanie, stronicowanie i historię zmian.
• Czego brakuje: wspólnego scenariusza synchronizacji: zakresu danych i uprawnień, punktu odniesienia, ról systemów oraz zasad przekazywania korekt, unieważnień i usunięć. Obsługę zmian, które zachodzą w trakcie pobierania kolejnych stron wyników, FHIR zostawia implementacji.
• Jak sprawdzić: po wznowieniu odbiorca ma te same rekordy i wersje co źródło w punkcie synchronizacji, bez duplikatów.

2. Pochodzenie danych

Gdy dane przechodzą przez adapter, na przykład z HL7 v2 do FHIR, czy da się odróżnić źródło od wyniku przekształcenia i ustalić, które oprogramowanie, w jakiej wersji, je wykonało.

• Co już jest: pola autorów, wykonawców, urządzeń i dat, a z bazowego FHIR między innymi Observation.derivedFrom i Device.version.
• Czego brakuje: profilu Provenance i profilu Device dla oprogramowania, z wymaganymi polami dla importu i przekształcenia: źródło i jego wersja, rodzaj i czas operacji, oprogramowanie i jego wersja oraz powiązanie z właściwą wersją wyniku.
• Jak sprawdzić: po imporcie da się ustalić źródło i wersję adaptera, a nieznane wcześniejsze etapy pozostają nieustalone, zgodnie z opisanymi regułami.

3. Obowiązki ról

Oznaczenie MustSupport samo nie mówi, co ma zrobić system źródłowy, pośrednik i odbiorca. Bez tego dwa systemy zgodne ze standardem mogą inaczej obsłużyć tę samą wartość.

• Co już jest: liczne flagi MustSupport, krotności, pole dataAbsentReason i odziedziczona z FHIR reguła obs-6.
• Czego brakuje: macierzy obowiązków źródła, pośrednika i odbiorcy, powiązanej z elementami profili, na przykład obowiązku przekazania znanej wartości i zachowania jej przy dalszym przekazywaniu.
• Jak sprawdzić: test zgodności sprawdza obowiązki przypisane roli, na przykład czy pośrednik, który ma przekazywać dane dalej, zachowuje znaną wartość.

4. Treść, nie tylko opis

Który sposób pobrania samego dokumentu i obrazu jest obowiązkowy, żeby nie budować osobnego połączenia dla każdej instalacji.

• Co już jest: DocumentReference przewiduje adres, typ MIME, format i skrót kontrolny treści, Media dane, adres i skrót, a ImagingStudy punkty dostępu. Rozdział o bezpieczeństwie wymaga TLS i autoryzacji.
• Czego brakuje: wskazania obowiązkowego sposobu pobrania dla kategorii treści i roli systemu, na przykład FHIR Binary albo opisanego w specyfikacji dostępu HTTPS dla dokumentów i WADO-RS dla obrazów DICOM, oraz profilu Endpoint dla dostępu do DICOM.
• Jak sprawdzić: klient pobiera treść w wariancie obowiązkowym i wiąże ją z metadanymi.

5. Minimum interfejsu i testy

Jakie operacje i filtry musi obsłużyć każda instalacja. W FHIR zapisuje się to w CapabilityStatement: jeden wspólny dokument wymagań, z którym każdy system może porównać własną deklarację możliwości. Do tego test, powiązany z wersją specyfikacji, który sprawdza to w praktyce.

• Co już jest: wymóg interfejsu REST i kontroli poprawności komunikatów. Bazowy FHIR definiuje deklarację możliwości serwera pod adresem /metadata, a pakiet zawiera reguły Schematron i wyniki walidacji wydawcy.
• Czego brakuje: krajowej macierzy ról, zasobów, operacji i parametrów wyszukiwania, zapisanej w CapabilityStatement rodzaju requirements. Sam ten rodzaj dokumentu nie określa poziomu obowiązku, dlatego proponujemy podział na obowiązkowe, zalecane i opcjonalne. W pakiecie nie ma CapabilityStatement, SearchParameter, OperationDefinition ani TestScript. Ich brak nie wyłącza reguł bazowego FHIR, ale też nie mówi, czego wymagać od każdej instalacji.
• Jak sprawdzić: test zgodności wykrywa pominięcie obowiązkowego filtra, a osobna próba dwóch implementacji potwierdza, że współpracują.

6. Warunki dostępu

Wspólny format niewiele zmienia, jeśli korzystanie z interfejsu jest płatne albo zależy od zgody dostawcy systemu. Postulujemy bezpłatne korzystanie z obowiązkowego zakresu interfejsu i jawne kryteria podłączania aplikacji.

• Co już jest: silne uwierzytelnianie, autoryzacja każdego żądania i limity pobierania danych.
• Czego brakuje: zasad wdrożenia, które ograniczają zależność placówki od dostawcy. Proponujemy bezpłatne korzystanie z obowiązkowego zakresu interfejsu, bez dodatkowych licencji, abonamentu i opłat za zapytania lub wolumen danych. Wyjątkiem mogłaby być niewielka, jednorazowa opłata za udokumentowaną konfigurację klienta, z określonym limitem. Do tego termin podłączenia, jawne kryteria bezpieczeństwa i obiektywne uzasadnienie odmowy. To postulat skierowany do Ministerstwa Zdrowia i CeZ, a nie opis obecnych przepisów.
• Jak sprawdzić: aplikacja, która spełnia kryteria, uzyskuje dostęp bez opłat za standardowe korzystanie.

Czego nasze uwagi nie obejmują

Nie powtarzaliśmy tematów, które dobrze opisują publiczne stanowiska HL7 Polska z 16 października i PCSTL-LOINC z 20 października: terminologii laboratoryjnej, paneli i próbek, jednostek UCUM, zgodności z PL Base i EHDS. Warto przeczytać oba.

Moje porównanie dotyczy opublikowanego projektu i jego artefaktów, a nie działającego interfejsu. Punkty „Jak sprawdzić” to propozycje testów, a nie wyniki testów, które wykonaliśmy. Nie znamy też pełnej listy zgłoszeń do CeZ, więc nie twierdzimy, że tylko my podnosimy te tematy.

Jak zgłosić własne uwagi

Centrum e-Zdrowia przyjmuje uwagi do 31 października 2026 pod adresem konsultacje@cez.gov.pl, z tematem „Konsultacje otwartych standardów komunikacji między systemami teleinformatycznymi”. Szczegóły są w ogłoszeniu CeZ, a projekt standardu jest dostępny w całości.

Pełny tekst naszych uwag (PDF, dwie strony) można wykorzystać we własnym zgłoszeniu. Jeśli któryś z sześciu punktów jest u Was szczególnie trudny, chętnie o nim porozmawiam.