Rövid válasz: A DICOMweb a DICOM szabvány 18. részében meghatározott webszolgáltatások gyűjteménye. Egy DICOM archívumot tesz elérhetővé egyszerű HTTPS protokollon keresztül: a QIDO-RS (Query based on ID for DICOM Objects) tanulmányok, sorozatok és példányok keresésére szolgál; a WADO-RS (Web Access to DICOM Objects) ezek lekérdezésére, teljes DICOM fájlként, JSON formátumú metaadatként vagy renderelt JPEG/PNG képként; a STOW-RS (Store Over the Web) új objektumok feltöltésére szolgál. A régebbi WADO-URI lekérdezési paraméterekkel egyetlen objektumot kérdez le. Böngésző alapú megjelenítők a DICOMweb-et használják, mert nem tudnak klasszikus DICOM hálózatkezelést végezni.
Klasszikus DICOM vs. DICOMweb
A klasszikus DICOM hálózatépítés (a szabvány 7. és 8. része) egy TCP-n keresztüli bináris protokollt használ olyan szolgáltatásokkal, mint a C-FIND, C-MOVE, C-GET és C-STORE a konfigurált csomópontok között. A DICOMweb (18. rész) ugyanazokat a műveleteket rendeli hozzá az HTTP-hez: QIDO-RS a kereséshez, WADO-RS a lekérdezéshez és STOW-RS a tároláshoz, ami az interneten és böngészőkből is működik.
A klasszikus DICOM (7. és 8. rész) saját bináris protokollt használ TCP felett, elnevezett szolgáltatásokkal: C-FIND a kereséshez, C-MOVE vagy C-GET a lekérdezéshez, C-STORE a küldéshez. Konfigurált "asszociációra" van szükség két ismert csomópont (AE címek, IP-címek, portok) között, ami egy kórházon belül rendben van, de az interneten keresztül nehézkes. A DICOMweb ugyanazokat az ötleteket képezi le HTTP-re:
| Feladat | Klasszikus DICOM | DICOMweb |
|---|---|---|
| Tanulmány keresése | C-FIND | QIDO-RS: GET /studies?PatientID=… |
| Tanulmány lekérdezése | C-MOVE / C-GET | WADO-RS: GET /studies/{StudyInstanceUID} |
| Csak metaadatok olvasása | C-FIND példány szinten | WADO-RS: GET /studies/{uid}/metadata |
| Megtekinthető kép lekérése | lekérdezés, majd helyi renderelés | WADO-RS renderelt: GET …/instances/{uid}/rendered |
| Képek küldése archívumba | C-STORE | STOW-RS: POST /studies |
| Munkafolyamatok kezelése | MWL (C-FIND munkafolyamaton) | UPS-RS |
Az erőforrás hierarchia követi a DICOM saját modelljét: egy tanulmány (egy vizsgálat a szkennernél) sorozatokat (minden egyes akvizíció) tartalmaz, amelyek példányokat (egyetlen képek vagy több képkockás objektumok) tartalmaznak, mindegyiket egy globálisan egyedi UID azonosítja.
QIDO-RS: keresés
A QIDO-RS a DICOMweb keresési szolgáltatása. Az ügyfél GET /studies, /series vagy /instances parancsot küld olyan lekérdezési paraméterekkel, mint a PatientID, StudyDate vagy ModalitiesInStudy, valamint az Accept fejléc application/dicom+json értékkel. Az archívum egy JSON tömböt ad vissza, amelyben minden DICOM attribútumot a nyolcjegyű címkéje, az értékreprezentációja és az értékei alapján azonosítunk.
GET /dicomweb/studies?PatientID=12345&StudyDate=20260101-20261231&ModalitiesInStudy=CT
Accept: application/dicom+json
A válasz egy JSON tömb tanulmányokról. Minden attribútum a címkéje (csoport és elem nyolc hexadecimális számjegyenként) alapján van kulcsolva, az értékábrázolásával és értékeivel:
[{
"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]}
}]
Itt a 00201206 a Tanulmányhoz Kapcsolódó Sorozatok Száma, a 00201208 pedig a Tanulmányhoz Kapcsolódó Példányok Száma. A címkeszámokat a DICOM címkék magyarázata ismerteti.
WADO-RS: lekérdezés
A WADO-RS a DICOMweb lekérdezési szolgáltatása. A GET /studies/{StudyInstanceUID} parancs egy teljes vizsgálatot ad vissza DICOM Part 10 fájlokként egy multipart válaszban; a /metadata utótag a fejlécet JSON formátumban adja vissza pixelek nélkül; a /frames/{n} egy képkocka pixeleit adja vissza; a /rendered pedig egy szerver által renderelt JPEG vagy PNG képet ad vissza ablak-, nézet- és minőségi paraméterekkel.
GET /studies/{study}Accept: multipart/related; type="application/dicom"esetén minden példányt DICOM Part 10 fájlként ad vissza, minden példány egy külön részen.GET /studies/{study}/metadataaz összes példány fejlécét adja vissza JSON formátumban, képpontadatok nélkül. A megjelenítők ezt hívják először a layout felépítéséhez, majd képkockánként kérik le a képpontokat.GET /studies/{study}/series/{series}/instances/{instance}/frames/1egy képkocka képpontadatait adja vissza, opcionálisan átkódolva (transfer-syntaxparaméter).GET …/instances/{instance}/renderedAccept: image/jpegesetén egy szerver által renderelt képet ad vissza,window,viewportésqualityparaméterekkel. Ezt használja egy könnyűsúlyú betegportál az előnézet megjelenítésére.
STOW-RS: tárolás
A STOW-RS a DICOMweb tárolási szolgáltatása. Az ügyfél POST /studies parancsot küld egy multipart/related törzzsel, amelyben minden rész egy DICOM fájl. Az archívum válaszol az elfogadott és sikertelen példányok listájával, valamint az egyes hibák okával, és ellenőrzi, hogy az URL-ben megadott bármely Study Instance UID megegyezik-e a feltöltött fájlokkal.
POST /dicomweb/studies
Content-Type: multipart/related; type="application/dicom"; boundary=abc
Minden rész egy DICOM fájl. A válasz felsorolja az elfogadott és sikertelen példányokat okokkal (hibás SOP osztály, ismétlődő UID). Az archívumok ellenőrzik, hogy az URL-ben megadott Study Instance UID (ha van) megegyezik-e a fájlokkal.
Biztonság
A DICOMweb-nek nincs saját bejelentkezése; az HTTPS-re és a szerver által elé helyezett bármire támaszkodik: a legtöbb modern archívumban OAuth 2.0 bearer tokenek, gyakran SMART on FHIR hatókörökkel kombinálva, amikor a megjelenítő egy EHR-ből indul. A naplózás, hogy ki melyik tanulmányt kérdezte le, az archívum feladata, nem a protokollé.
Hol használják
Minden nagyobb PACS és vendor-neutral archive most kínál DICOMweb végpontot, és a nyílt forráskódú archívumok (Orthanc, dcm4chee, Google Cloud Healthcare API, Azure DICOM service) DICOMweb-elsőként működnek. A webes megjelenítők, mint az OHIF, teljes egészében QIDO-RS és WADO-RS alapokon épülnek. Egy FHIR világban egy ImagingStudy erőforrás mutat egy DICOMweb végpontra; a képpontok soha nem mennek át FHIR-en.
Az Anpheros nem tárol képeket. Egy beteg rekordja tartalmazhatja a radiológiai jelentést DocumentReference vagy DiagnosticReport formátumban, és ahol egy kórház biztosít ilyet, egy linket a megjelenítőjéhez; maga a DICOM adat a kórház archívumában marad. A saját képeid betegként való lekéréséhez lásd: Hogyan szerezheted meg a CT vagy MRI képeidet.
Kapcsolódó oldalak
- FHIR ImagingStudy vs. DICOMweb
- DICOM címkék magyarázata
- PACS vs. RIS vs. VNA
- Hogyan szerezheted meg a CT vagy MRI képeidet (DICOM)
- Egészségügyi interoperabilitási szabványok: a térkép
- DICOM vs. FHIR fejlesztőknek
Források
- DICOM PS3.18: Web Services
- DICOM PS3.7: Message Exchange
- DICOMweb áttekintés (DICOM Standards Committee)
- OHIF Viewer dokumentáció
Gyakori kérdések
A DICOMweb egy külön szabvány a DICOM-tól?
Nem. Ez ugyanazon DICOM szabvány 18. része. Az objektumok, címkék és UID-k azonosak; csak a szállítás változik a DICOM saját protokolljáról HTTP-re.
Mi a különbség a WADO-URI és a WADO-RS között?
A WADO-URI a régebbi szolgáltatás: kérésenként egy objektum, lekérdezési paraméterekkel kiválasztva (?requestType=WADO&studyUID=…). A WADO-RS RESTful, teljes tanulmányokat vagy sorozatokat, JSON metaadatokat és egyedi képkockákat tud visszaadni, és az új rendszerek ezt implementálják.
Használhatom a DICOMweb-et PACS nélkül?
Szükséged van egy olyan archívumra, amely implementálja azt. Nyílt forráskódú szerverek, mint az Orthanc és a dcm4chee, azonnal biztosítanak DICOMweb-et, és gyakran használják fejlesztésre és kis klinikákon.
A FHIR helyettesíti a DICOMweb-et?
Nem. A FHIR leírja a tanulmányt (ImagingStudy) és a jelentést (DiagnosticReport); a DICOMweb szállítja a képeket. Egy megjelenítő mindkettőt használja: FHIR-t, hogy megtudja, létezik-e egy tanulmány, DICOMweb-et, hogy megjelenítse azt.
Próbáld ki az Anpheros Daily-ben
Tartsd a vizsgálati és lelet-jelentéseidet egy helyen az Anpheros Daily-ben, készen arra, hogy megmutasd a következő látogatásod alkalmával.
Hogyan működik az alkalmazásban →
Az Anpheros egy olyan egészségügyi nyilvántartást épít, amelyet a beteg irányít, és megoszthat bármelyik klinikával, egy EU-ban működő HL7 FHIR R4 platformon. Ezek az útmutatók segítenek megérteni és rendszerezni az egészségügyi adataidat; nem helyettesítik az orvosodat.
Tudj meg többet az Anpherosról →