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}zAccept: multipart/related; type="application/dicom"zwraca każdy obiekt jako plik DICOM Part 10, po jednej części na obiekt.GET /studies/{study}/metadatazwraca 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/1zwraca dane pikseli jednej klatki, opcjonalnie transkodowane (parametrtransfer-syntax).GET …/instances/{instance}/renderedzAccept: image/jpegzwraca obraz renderowany przez serwer, z parametramiwindow,viewportiquality. 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
- FHIR ImagingStudy vs DICOMweb
- Wyjaśnienie tagów DICOM
- PACS vs RIS vs VNA
- Jak uzyskać swoje obrazy z tomografii komputerowej lub rezonansu magnetycznego (DICOM)
- Standardy interoperacyjności w opiece zdrowotnej: mapa
- DICOM vs FHIR dla programistów
Źródła
- DICOM PS3.18: Web Services
- DICOM PS3.7: Message Exchange
- Przegląd DICOMweb (Komitet Standardów DICOM)
- Dokumentacja OHIF Viewer
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ć.
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 →
