RIS, PACS i DICOM: czym się różnią i jak je zintegrować?

RIS, PACS i DICOM — trzy różne elementy jednego procesu

W diagnostyce obrazowej skróty RIS, PACS i DICOM często pojawiają się obok siebie, ale opisują różne rzeczy.

RIS organizuje proces badania: pacjenta, zlecenie, termin, status, listę pracy, opis i wynik. PACS odpowiada głównie za przechowywanie, wyszukiwanie i udostępnianie badań obrazowych. DICOM jest standardem, który opisuje między innymi format danych medycznych, identyfikatory oraz sposób komunikacji pomiędzy urządzeniami i systemami.

W praktyce dobry workflow nie polega na tym, że każdy system robi wszystko. Polega na tym, że każdy element ma jasno określoną odpowiedzialność, a dane przechodzą pomiędzy nimi bez ręcznego przepisywania.

Najprostszy model można zapisać tak:

zlecenie → RIS → modality → PACS → viewer → opis → wynik

To jednak dopiero początek. W realnym środowisku dochodzą HIS lub EDM, rejestracja, systemy rozliczeniowe, broker HL7, kilka placówek, kilka PACS-ów, różne urządzenia i różne modele autoryzacji.

Co to jest system RIS

RIS, czyli Radiology Information System, jest systemem informacyjnym wspierającym organizację pracy diagnostyki obrazowej.

Typowy RIS nie jest archiwum obrazów. Jego głównym zadaniem jest prowadzenie badania przez kolejne etapy procesu.

W zależności od organizacji może obejmować między innymi:

• rejestrację pacjenta,
• przyjmowanie lub tworzenie zleceń,
• planowanie terminów,
• przypisywanie badania do pracowni lub urządzenia,
• statusy badania,
• listy pracy techników i lekarzy,
• priorytety i kolejki,
• opis radiologiczny,
• autoryzację wyniku,
• dystrybucję wyniku,
• historię operacji,
• integrację z HIS, EDM, PACS i viewerem.

Ważne jest rozróżnienie pomiędzy danymi procesu a danymi obrazowymi. RIS może wiedzieć, że pacjent ma zaplanowane badanie CT klatki piersiowej, że badanie zostało wykonane i czeka na opis. Nie oznacza to jeszcze, że przechowuje tysiące obrazów powstałych podczas tomografii.

To zadanie zwykle należy do PACS.

Co to jest PACS

PACS, czyli Picture Archiving and Communication System, jest systemem przeznaczonym do przechowywania, indeksowania, wyszukiwania i udostępniania obrazów medycznych oraz powiązanych obiektów.

Do PACS mogą trafiać badania z takich urządzeń jak CT, MR, CR/DX, US, mammografia, angiografia czy PET.

PACS przechowuje nie tylko piksele. Badanie zawiera również metadane potrzebne do identyfikacji pacjenta, badania, serii i poszczególnych obiektów.

W architekturze DICOM typowa hierarchia wygląda tak:

Patient → Study → Series → Instance

Jedno badanie, czyli Study, może mieć wiele serii. Każda seria może zawierać wiele instancji, na przykład obrazów.

Kluczową rolę odgrywają identyfikatory UID, między innymi:

• StudyInstanceUID,
• SeriesInstanceUID,
• SOPInstanceUID.

To one pozwalają jednoznacznie odwołać się do konkretnego badania, serii albo obiektu w środowisku DICOM.

Czym różni się RIS od PACS

Najkrócej:

RIS prowadzi workflow. PACS prowadzi obrazy.

| Obszar | RIS | PACS | | --- | --- | --- | | Pacjent i zlecenie | tak | przechowuje część danych w metadanych badania | | Terminy | zwykle tak | zwykle nie | | Status procesu | tak | częściowo, zależnie od rozwiązania | | Worklista radiologa | często tak | czasem dostępna | | Opis badania | często tak | może przechowywać dokument lub wynik | | Obrazy DICOM | odwołuje się do nich | przechowuje i udostępnia | | Wyszukiwanie badań | po procesie i danych biznesowych | po metadanych obrazowych | | Viewer | może go osadzać lub otwierać | często dostarcza lub integruje |

Największa wartość pojawia się wtedy, gdy użytkownik nie musi zastanawiać się, który system aktualnie obsługuje.

Radiolog powinien móc wejść z listy badań w RIS bezpośrednio do odpowiedniego badania w viewerze. Technik nie powinien ręcznie przepisywać danych pacjenta z kartki do konsoli urządzenia. System powinien znać identyfikatory pozwalające bezpiecznie powiązać zlecenie z właściwym Study.

Co to jest DICOM

DICOM, czyli Digital Imaging and Communications in Medicine, jest standardem używanym do wymiany i reprezentacji danych obrazowych w medycynie.

DICOM opisuje znacznie więcej niż rozszerzenie pliku .dcm.

Standard definiuje między innymi:

• struktury danych,
• słownik atrybutów,
• identyfikatory,
• modele informacji o badaniu,
• klasy obiektów,
• usługi sieciowe,
• mechanizmy wyszukiwania,
• przesyłanie obrazów,
• worklisty,
• dokumentację zgodności urządzeń i systemów.

Atrybuty DICOM są identyfikowane przez tagi. Integracja nie może więc polegać wyłącznie na przesłaniu pliku z punktu A do punktu B. Systemy muszą również zgadzać się co do znaczenia danych.

DICOM DIMSE i DICOMweb — dwa sposoby komunikacji

W integracjach można spotkać dwa główne światy.

Pierwszy to klasyczne usługi DICOM oparte o DIMSE. Drugi to DICOMweb, wykorzystujący interfejsy HTTP/REST.

W środowisku klasycznego DICOM często spotyka się między innymi:

• C-ECHO — sprawdzenie komunikacji,
• C-STORE — przesyłanie obiektów,
• C-FIND — wyszukiwanie,
• C-MOVE lub C-GET — pobieranie obiektów,
• Modality Worklist — przekazywanie listy zaplanowanych badań,
• MPPS — raportowanie wykonania kroku procedury.

W DICOMweb najważniejsze usługi to:

• QIDO-RS — wyszukiwanie badań, serii i instancji,
• WADO-RS — pobieranie danych DICOM lub ich reprezentacji,
• STOW-RS — zapis obiektów DICOM.

DICOMweb jest szczególnie wygodny dla aplikacji webowych i viewerów działających w przeglądarce. Nie oznacza to jednak, że automatycznie zastępuje wszystkie klasyczne usługi DICOM w istniejącej infrastrukturze.

W wielu placówkach klasyczny DICOM i DICOMweb działają równolegle.

Jak wygląda typowy przepływ badania RIS–PACS

Dobrze zaprojektowana integracja zaczyna się od zrozumienia procesu, nie od wyboru endpointu.

Przykładowy przebieg może wyglądać tak:

1. W HIS, EDM albo RIS powstaje zlecenie.
2. RIS zapisuje dane pacjenta, typ badania, termin i identyfikatory zlecenia.
3. Urządzenie pobiera zaplanowane badania z Modality Worklist.
4. Technik wybiera właściwą pozycję zamiast ręcznie wpisywać dane.
5. Urządzenie wykonuje badanie.
6. Obrazy są wysyłane do PACS.
7. PACS zapisuje Study, Series i Instances.
8. RIS otrzymuje informację o wykonaniu lub sam wykrywa powiązane badanie.
9. Radiolog otwiera badanie z RIS w viewerze.
10. Viewer pobiera obrazy z PACS.
11. Radiolog przygotowuje opis.
12. Wynik jest zatwierdzany i przekazywany dalej.

To model orientacyjny. Konkretna implementacja zależy od możliwości urządzeń, PACS-u, RIS-u, HIS-u i przyjętego modelu integracji.

Jak podłączyć PACS do RIS

Nie istnieje jeden uniwersalny endpoint „podłącz PACS”.

Integrację zaczyna się od ustalenia, które dane mają przepływać w którą stronę.

Trzeba odpowiedzieć między innymi na pytania:

• skąd pochodzi pacjent,
• gdzie powstaje zlecenie,
• kto nadaje Accession Number,
• który system jest źródłem statusu badania,
• skąd modality pobiera worklistę,
• dokąd urządzenie wysyła obrazy,
• po czym RIS rozpoznaje właściwe Study,
• jak viewer dostaje identyfikator badania,
• kto przechowuje opis,
• gdzie trafia zatwierdzony wynik.

Dopiero potem dobiera się konkretne mechanizmy.

Krok 1: sprawdź DICOM Conformance Statement

Pierwszym technicznym dokumentem powinien być DICOM Conformance Statement każdego urządzenia i systemu biorącego udział w integracji.

Dokument powinien powiedzieć między innymi:

• jakie SOP Classes są obsługiwane,
• czy system działa jako SCU, SCP czy w obu rolach,
• jakie usługi DICOM są dostępne,
• jakie transfer syntaxes są obsługiwane,
• jakie pola są wymagane lub zwracane,
• jak konfiguruje się AE Title, host i port,
• jakie są ograniczenia implementacji.

Samo zdanie „system obsługuje DICOM” jest za mało precyzyjne.

Krok 2: ustal identyfikatory łączące proces z obrazami

Jednym z najczęstszych źródeł problemów są nie same obrazy, lecz identyfikacja.

W integracji trzeba świadomie pracować z takimi wartościami jak:

• Patient ID,
• Accession Number,
• Study Instance UID,
• Series Instance UID,
• SOP Instance UID,
• identyfikator zlecenia lub procedury.

Patient ID i StudyInstanceUID nie są tym samym.

Pacjent może mieć wiele badań. Jedno badanie może mieć wiele serii. Jedna seria może mieć wiele obrazów.

RIS powinien wiedzieć, które badanie PACS odpowiada któremu zleceniu biznesowemu.

Krok 3: skonfiguruj komunikację

W klasycznej integracji DICOM konfiguracja często obejmuje:

• AE Title,
• adres IP lub hostname,
• port,
• role SCU/SCP,
• reguły sieciowe i firewall,
• TLS, jeśli jest wspierany i wymagany,
• timeouty,
• obsługiwane usługi.

Pierwszym testem bywa C-ECHO, ale pozytywny echo test potwierdza tylko, że strony potrafią zestawić komunikację DICOM. Nie dowodzi, że wyszukiwanie, storage albo worklista są skonfigurowane poprawnie.

Krok 4: zdecyduj, jak RIS wyszukuje badania

Jeśli PACS udostępnia klasyczny DICOM Query/Retrieve, RIS lub warstwa integracyjna może używać odpowiednich zapytań DICOM.

Jeśli dostępny jest DICOMweb, aplikacja może używać QIDO-RS do wyszukania Study lub Series.

Przykładowy model aplikacyjny wygląda wtedy tak:

RIS → QIDO-RS → StudyInstanceUID → viewer

RIS nie musi pobierać wszystkich obrazów. Często wystarczy, że zna identyfikator właściwego Study i może otworzyć viewer w odpowiednim kontekście.

Krok 5: podepnij viewer

Viewer nie powinien wymagać od radiologa ponownego wyszukiwania pacjenta.

Po kliknięciu badania w RIS aplikacja powinna przekazać viewerowi kontekst pozwalający otworzyć konkretne Study.

W przypadku viewerów webowych, takich jak OHIF, często wykorzystuje się DICOMweb do wyszukiwania i pobierania danych.

Trzeba przy tym rozwiązać:

• autoryzację,
• dostęp do endpointów DICOMweb,
• CORS i reverse proxy,
• mapowanie użytkownika i uprawnień,
• wygasanie sesji,
• logowanie dostępu,
• zachowanie przy braku lub niepełnym badaniu.

Integracja viewera to nie tylko iframe albo link z UID-em. Jest częścią modelu bezpieczeństwa całego systemu.

Modality Worklist — dlaczego jest ważniejsza, niż wygląda

Bez worklisty technik może przepisywać dane pacjenta i badania ręcznie na urządzeniu.

DICOM Modality Worklist pozwala urządzeniu pobrać zaplanowane pozycje z systemu pełniącego rolę dostawcy worklisty.

Klasyczny workflow MWL wykorzystuje zapytania C-FIND.

Dzięki temu modality może otrzymać informacje o pacjencie, procedurze, terminie i identyfikatorach potrzebnych do poprawnego utworzenia badania.

Nie każdy RIS musi sam implementować serwer MWL. W części architektur robi to broker, PACS, osobny serwer DICOM albo inne rozwiązanie integracyjne.

MPPS — co dzieje się po rozpoczęciu badania

Modality Performed Procedure Step, czyli MPPS, służy do przekazywania informacji o wykonywanej procedurze.

Może pomóc odróżnić badanie zaplanowane, rozpoczęte, zakończone albo przerwane.

Nie każde środowisko wykorzystuje MPPS. W niektórych status jest wyprowadzany z innych zdarzeń, integracji albo logiki aplikacyjnej.

Gdzie w tym wszystkim są HL7 i FHIR

DICOM dobrze opisuje świat obrazowania medycznego, ale RIS często musi również komunikować się z systemami, których głównym zadaniem nie są obrazy.

Dlatego w środowisku mogą pojawić się:

• HL7 v2,
• FHIR,
• API producenta,
• kolejki komunikatów,
• inne mechanizmy integracyjne.

Przykładowo HIS może przekazać dane pacjenta lub zlecenia do RIS przez HL7, podczas gdy modality i PACS komunikują się przez DICOM.

Zasób FHIR ImagingStudy opisuje informacje o badaniu obrazowym, ale nie zastępuje samego archiwum DICOM. Obrazy nadal muszą być dostępne przez PACS, DICOMweb albo inny mechanizm przechowywania.

DICOMweb: QIDO-RS, WADO-RS i STOW-RS

W aplikacji webowej warto dobrze rozumieć trzy nazwy.

QIDO-RS

QIDO-RS służy do wyszukiwania badań, serii i instancji.

WADO-RS

WADO-RS służy do pobierania danych.

STOW-RS

STOW-RS służy do zapisywania obiektów DICOM przez interfejs webowy.

Nie każdy PACS udostępnia wszystkie trzy usługi i nie każda implementacja obsługuje ten sam zakres funkcji. Źródłem prawdy jest dokumentacja i Conformance Statement konkretnego systemu.

Najczęstsze błędy przy integracji RIS i PACS

Założenie, że „DICOM to DICOM”

Obsługa standardu nie oznacza obsługi każdego SOP Class, workflow i wariantu komunikacji.

Łączenie po nazwisku pacjenta

Nazwisko nie jest technicznym kluczem do identyfikacji badania.

Brak ustalonego źródła prawdy

Jeżeli trzy systemy mogą niezależnie zmienić te same dane, prędzej czy później pojawią się konflikty.

Ręczne przepisywanie danych na modality

To problem operacyjny i integracyjny, nie tylko problem UX.

Brak obsługi błędów częściowych

PACS może działać, ale DICOMweb nie. Obraz może się zapisać, ale RIS może nie zaktualizować statusu. Viewer może otworzyć Study, ale część Series może być jeszcze przesyłana.

Brak obserwowalności

Potrzebne są przynajmniej logi techniczne, identyfikatory śledzenia, monitoring błędów, możliwość bezpiecznego ponowienia i historia kluczowych operacji.

Bezpieczeństwo i dane medyczne

Integracja RIS/PACS dotyka danych szczególnie wrażliwych.

Projektując system trzeba uwzględnić między innymi:

• uwierzytelnianie,
• role i uprawnienia,
• ograniczenie dostępu do badań,
• szyfrowanie transmisji tam, gdzie architektura tego wymaga,
• separację sieci,
• audyt dostępu,
• retencję logów,
• backup i odtwarzanie,
• aktualizacje komponentów,
• zasady przetwarzania danych wynikające z organizacji i przepisów.

Jak testować integrację RIS–PACS

Testy powinny obejmować nie tylko happy path.

Warto przygotować przypadki takie jak:

• poprawne badanie jednego pacjenta,
• pacjent z wieloma badaniami,
• dwa podobne badania tego samego dnia,
• korekta danych pacjenta,
• brak Accession Number,
• duplikat komunikatu,
• ponowne wysłanie obrazów,
• częściowo przesłane Study,
• niedostępny PACS,
• timeout DICOM,
• niedostępny endpoint DICOMweb,
• brak uprawnień,
• badanie anulowane,
• badanie rozpoczęte i niedokończone.

Przy integracji wielosystemowej ważna jest również odpowiedź na pytanie: co system zrobi po odzyskaniu połączenia?

Checklista przed integracją

• Mamy aktualne DICOM Conformance Statement wszystkich systemów.
• Znamy role SCU i SCP.
• Wiemy, czy dostępne są QIDO-RS, WADO-RS i STOW-RS.
• Wiemy, gdzie powstaje Patient ID.
• Wiemy, gdzie powstaje Accession Number.
• Wiemy, który system tworzy StudyInstanceUID.
• Ustaliliśmy źródło prawdy dla statusów.
• Wiemy, czy używana jest Modality Worklist.
• Wiemy, czy urządzenia obsługują MPPS.
• Znamy sposób integracji z HIS lub EDM.
• Mamy model autoryzacji viewer–PACS.
• Mamy środowisko testowe lub reprezentatywne dane.
• Wiemy, jak wykrywać błędy częściowe.
• Mamy monitoring i logi integracyjne.
• Mamy plan ponowień i obsługi duplikatów.

Podsumowanie

RIS, PACS i DICOM nie są zamiennymi pojęciami.

RIS prowadzi proces diagnostyczny. PACS przechowuje i udostępnia dane obrazowe. DICOM definiuje wspólny język, którym urządzenia i systemy mogą opisywać oraz wymieniać dane.

Dobra integracja zaczyna się od mapy procesu i odpowiedzialności systemów, a dopiero później od konfiguracji protokołów.

Jeżeli RIS ma otwierać właściwe badanie w PACS, trzeba ustalić identyfikatory, źródła danych, obsługiwane usługi DICOM lub DICOMweb, model autoryzacji i zachowanie przy błędach. Jeżeli modality ma pobierać poprawne dane zlecenia, trzeba zaprojektować worklistę zamiast liczyć na ręczne przepisywanie.

Najważniejszym dokumentem na starcie jest DICOM Conformance Statement, a najważniejszym artefaktem projektu — czytelna mapa przepływu danych pomiędzy HIS/EDM, RIS, modality, PACS i viewerem.

Źródła techniczne

• DICOM Standard: https://www.dicomstandard.org/
• DICOM Modality Worklist: DICOM PS3.4, Annex K
• DICOMweb: DICOM PS3.18
• HL7 FHIR ImagingStudy: https://hl7.org/fhir/imagingstudy.html