Obrazowanie medyczne

DICOMweb w pigułce: QIDO-RS, WADO-RS i STOW-RS z przykładami zapytań

DICOMweb to interfejs RESTowy standardu DICOM: QIDO-RS służy do wyszukiwania badań, WADO-RS do pobierania obrazów i metadanych, a STOW-RS do ich zapisywania. Dowiedz się, jak tworzone są adresy URL, jak wygląda format JSON, czym różni się od klasycznego sieciowego DICOM i co właściwie wywołuje przeglądarka obrazów.

autor Opublikowano 5 min czytania

Krótka odpowiedź: DICOMweb to zestaw usług internetowych zdefiniowanych w części 18 standardu DICOM. Udostępnia on archiwum DICOM przez zwykły HTTPS: QIDO-RS (Query based on ID for DICOM Objects) wyszukuje badania, serie i obiekty; WADO-RS (Web Access to DICOM Objects) je pobiera, jako pełne pliki DICOM, jako metadane w formacie JSON lub jako przetworzone obrazy JPEG/PNG; STOW-RS (Store Over the Web) przesyła nowe obiekty. Starszy WADO-URI pobiera jeden obiekt za pomocą parametrów zapytania. Przeglądarki obrazów używają DICOMweb, ponieważ nie potrafią komunikować się za pomocą klasycznego protokołu DICOM.

Klasyczny DICOM vs DICOMweb

Klasyczne sieci DICOM (części 7 i 8 standardu) wykorzystują protokół binarny przez TCP z usługami takimi jak C-FIND, C-MOVE, C-GET i C-STORE między skonfigurowanymi węzłami. DICOMweb (część 18) mapuje te same operacje na HTTP: QIDO-RS do wyszukiwania, WADO-RS do pobierania i STOW-RS do przechowywania, co działa przez internet i z przeglądarek.

Klasyczny DICOM (część 7 i 8) używa własnego protokołu binarnego przez TCP z nazwanymi usługami: C-FIND do wyszukiwania, C-MOVE lub C-GET do pobierania, C-STORE do wysyłania. Wymaga skonfigurowanego "połączenia" między dwoma znanymi węzłami (tytuły AE, adresy IP, porty), co jest dobre w obrębie szpitala i trudne przez internet. DICOMweb mapuje te same idee na HTTP:

Zadanie Klasyczny DICOM DICOMweb
Znajdź badanie C-FIND QIDO-RS: GET /studies?PatientID=…
Pobierz badanie C-MOVE / C-GET WADO-RS: GET /studies/{StudyInstanceUID}
Odczytaj tylko metadane C-FIND na poziomie obiektu WADO-RS: GET /studies/{uid}/metadata
Uzyskaj obraz do wyświetlenia pobierz, a następnie przetwórz lokalnie WADO-RS przetworzony: GET …/instances/{uid}/rendered
Wyślij obrazy do archiwum C-STORE STOW-RS: POST /studies
Zarządzaj listami pracy MWL (C-FIND na liście pracy) UPS-RS

Hierarchia zasobów jest zgodna z własnym modelem DICOM: badanie (jedna wizyta w skanerze) zawiera serie (każde jedno akwizycję), które zawierają obiekty (pojedyncze obrazy lub obiekty wieloklatkowe), każdy zidentyfikowany przez globalnie unikalny identyfikator UID.

QIDO-RS: wyszukiwanie

QIDO-RS to usługa wyszukiwania DICOMweb. Klient wysyła GET /studies, /series lub /instances z parametrami zapytania, takimi jak PatientID, StudyDate lub ModalitiesInStudy, oraz nagłówkiem Accept: application/dicom+json. Archiwum zwraca tablicę JSON, w której każdy atrybut DICOM jest kluczowany przez jego ośmiocyfrowy tag wraz z jego reprezentacją wartości i wartościami.

GET /dicomweb/studies?PatientID=12345&StudyDate=20260101-20261231&ModalitiesInStudy=CT
Accept: application/dicom+json

Odpowiedź to tablica obiektów JSON reprezentujących badania. Każdy atrybut jest kluczowany przez jego tag (grupa i element jako osiem cyfr szesnastkowych), z jego reprezentacją wartości i wartościami:

[{
  "00080020": {"vr": "DA", "Value": ["20260314"]},
  "00080060": {"vr": "CS", "Value": ["CT"]},
  "00100010": {"vr": "PN", "Value": [{"Alphabetic": "DOE^JANE"}]},
  "0020000D": {"vr": "UI", "Value": ["1.2.840.113619.2.55.3.2831164356.781.1710415000.1"]},
  "00201206": {"vr": "IS", "Value": [3]},
  "00201208": {"vr": "IS", "Value": [412]}
}]

Tutaj 00201206 to liczba serii powiązanych z badaniem, a 00201208 to liczba obiektów powiązanych z badaniem. Numery tagów są wyjaśnione w Wyjaśnienie tagów DICOM.

WADO-RS: pobieranie

WADO-RS to usługa pobierania DICOMweb. GET /studies/{StudyInstanceUID} zwraca całe badanie jako pliki DICOM część 10 w odpowiedzi multipart; sufiks /metadata zwraca nagłówki jako JSON bez danych pikseli; /frames/{n} zwraca piksele jednej klatki; a /rendered zwraca renderowany przez serwer obraz JPEG lub PNG z parametrami okna, widoku i jakości.

  • GET /studies/{study} z Accept: multipart/related; type="application/dicom" zwraca każdy obiekt jako plik DICOM Part 10, po jednej części na obiekt.
  • GET /studies/{study}/metadata zwraca nagłówki wszystkich obiektów w formacie JSON, bez danych pikseli. Przeglądarki wywołują to najpierw, aby zbudować układ, a następnie pobierają piksele klatka po klatce.
  • GET /studies/{study}/series/{series}/instances/{instance}/frames/1 zwraca dane pikseli jednej klatki, opcjonalnie transkodowane (parametr transfer-syntax).
  • GET …/instances/{instance}/rendered z Accept: image/jpeg zwraca obraz renderowany przez serwer, z parametrami window, viewport i quality. To jest to, czego używa lekki portal pacjenta do wyświetlania podglądu.

STOW-RS: przechowywanie

STOW-RS to usługa przechowywania DICOMweb. Klient wysyła POST /studies z treścią multipart/related, w której każda część jest jednym plikiem DICOM. Archiwum odpowiada listą zaakceptowanych i nieudanych instancji oraz powodem każdej porażki i sprawdza, czy dowolny Study Instance UID podany w adresie URL pasuje do przesłanych plików.

POST /dicomweb/studies
Content-Type: multipart/related; type="application/dicom"; boundary=abc

Każda część to jeden plik DICOM. Odpowiedź zawiera listę zaakceptowanych i odrzuconych obiektów wraz z przyczynami (nieprawidłowa klasa SOP, duplikat UID). Archiwa weryfikują, czy Study Instance UID w adresie URL, jeśli został podany, pasuje do plików.

Bezpieczeństwo

DICOMweb nie posiada własnego systemu logowania; opiera się na HTTPS i tym, co serwer umieści przed nim: tokeny nośnika OAuth 2.0 w większości nowoczesnych archiwów, często w połączeniu z zakresami SMART on FHIR, gdy przeglądarka jest uruchamiana z systemu EHR. Rejestrowanie, kto i jakie badanie pobrał, jest zadaniem archiwum, a nie protokołu.

Gdzie jest używany

Każdy główny PACS i neutralne archiwum dostawców oferuje teraz punkt końcowy DICOMweb, a archiwa open-source (Orthanc, dcm4chee, Google Cloud Healthcare API, Azure DICOM service) są przede wszystkim DICOMweb. Przeglądarki internetowe, takie jak OHIF, są zbudowane w całości na QIDO-RS i WADO-RS. W świecie FHIR, zasób ImagingStudy wskazuje na punkt końcowy DICOMweb; piksele nigdy nie przechodzą przez FHIR.

Anpheros nie przechowuje obrazów. Rekord pacjenta może zawierać raport radiologiczny jako DocumentReference lub DiagnosticReport, a tam, gdzie szpital go udostępnia, link do swojej przeglądarki; dane DICOM pozostają w archiwum szpitala. Aby uzyskać własne obrazy jako pacjent, zobacz Jak uzyskać swoje obrazy z tomografii komputerowej lub rezonansu magnetycznego.

Powiązane strony

Źródła

Najczęstsze pytania

Czy DICOMweb to inny standard niż DICOM?

Nie. Jest to część 18 tego samego standardu DICOM. Obiekty, tagi i identyfikatory UID są identyczne; zmienia się tylko transport z własnego protokołu DICOM na HTTP.

Jaka jest różnica między WADO-URI a WADO-RS?

WADO-URI to starsza usługa: jeden obiekt na żądanie, wybierany za pomocą parametrów zapytania (?requestType=WADO&studyUID=…). WADO-RS jest RESTful, może zwracać całe badania lub serie, metadane w formacie JSON i poszczególne klatki, i jest tym, co implementują nowe systemy.

Czy mogę używać DICOMweb bez PACS?

Potrzebujesz archiwum, które je implementuje. Serwery open-source, takie jak Orthanc i dcm4chee, udostępniają DICOMweb od razu i są powszechnie używane do rozwoju i dla małych klinik.

Czy FHIR zastępuje DICOMweb?

Nie. FHIR opisuje badanie (ImagingStudy) i raport (DiagnosticReport); DICOMweb dostarcza obrazy. Przeglądarka używa obu: FHIR, aby dowiedzieć się, że badanie istnieje, DICOMweb, aby je wyświetlić.

Anpheros Daily

Wypróbuj w Anpheros Daily

Przechowuj wyniki badań obrazowych i laboratoryjnych w jednym miejscu w Anpheros Daily, gotowe do okazania podczas następnej wizyty.

Jak to działa w aplikacji →
Ten poradnik ma charakter informacyjny i nie zastępuje konsultacji lekarskiej. Decyzje dotyczące zdrowia podejmuj z lekarzem. W nagłym wypadku zadzwoń pod lokalny numer alarmowy (112 w Europie).
Napisane przez
Zespół Anpheros

Anpheros tworzy dokumentację medyczną, nad którą pacjent ma kontrolę i którą może udostępniać dowolnej klinice, na platformie HL7 FHIR R4, z siedzibą w UE. Te przewodniki pomogą Ci zrozumieć i uporządkować informacje o Twoim zdrowiu; nie zastępują one wizyty u lekarza.

O Anpheros →