Răspuns scurt: DICOMweb este setul de servicii web definite în Partea 18 a standardului DICOM. Acesta expune o arhivă DICOM peste HTTPS simplu: QIDO-RS (Query based on ID for DICOM Objects) caută studii, serii și instanțe; WADO-RS (Web Access to DICOM Objects) le preia, ca fișiere DICOM complete, ca metadate în JSON sau ca imagini redate JPEG/PNG; STOW-RS (Store Over the Web) încarcă obiecte noi. Vechiul WADO-URI preia un singur obiect prin parametri de interogare. Vizualizatoarele bazate pe browser folosesc DICOMweb deoarece nu pot comunica prin protocolul DICOM clasic.
DICOM clasic vs. DICOMweb
Rețeaua DICOM clasică (Părțile 7 și 8 ale standardului) folosește un protocol binar peste TCP cu servicii precum C-FIND, C-MOVE, C-GET și C-STORE între noduri configurate. DICOMweb (Partea 18) mapează aceleași operațiuni pe HTTP: QIDO-RS pentru căutare, WADO-RS pentru preluare și STOW-RS pentru stocare, ceea ce funcționează pe internet și din browsere.
DICOM clasic (Partea 7 și 8) folosește propriul protocol binar peste TCP cu servicii numite: C-FIND pentru interogare, C-MOVE sau C-GET pentru preluare, C-STORE pentru trimitere. Necesită o "asociere" configurată între două noduri cunoscute (titluri AE, adrese IP, porturi), ceea ce este în regulă în interiorul unui spital și dificil pe internet. DICOMweb mapează aceleași idei pe HTTP:
| Sarcină | DICOM clasic | DICOMweb |
|---|---|---|
| Găsirea unui studiu | C-FIND | QIDO-RS: GET /studies?PatientID=… |
| Preluarea unui studiu | C-MOVE / C-GET | WADO-RS: GET /studies/{StudyInstanceUID} |
| Citirea doar a metadatelor | C-FIND la nivel de instanță | WADO-RS: GET /studies/{uid}/metadata |
| Obținerea unei imagini vizibile | preluare apoi redare locală | WADO-RS redat: GET …/instances/{uid}/rendered |
| Trimiterea imaginilor către o arhivă | C-STORE | STOW-RS: POST /studies |
| Gestionarea listelor de lucru | MWL (C-FIND pe o listă de lucru) | UPS-RS |
Ierarhia resurselor urmează propriul model DICOM: un studiu (o vizită la scaner) conține serii (fiecare achiziție), care conțin instanțe (imagini individuale sau obiecte multi-cadru), fiecare identificată printr-un UID unic la nivel global.
QIDO-RS: căutarea
QIDO-RS este serviciul de căutare DICOMweb. Un client trimite GET /studies, /series sau /instances cu parametri de interogare precum PatientID, StudyDate sau ModalitiesInStudy și antetul Accept application/dicom+json. Arhiva returnează un array JSON în care fiecare atribut DICOM este cheia sa formată din opt cifre, împreună cu reprezentarea valorii și valorile.
GET /dicomweb/studies?PatientID=12345&StudyDate=20260101-20261231&ModalitiesInStudy=CT
Accept: application/dicom+json
Răspunsul este un array JSON de studii. Fiecare atribut este cheia prin tag-ul său (grup și element ca opt cifre hexazecimale), cu reprezentarea valorii și valorile sale:
[{
"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]}
}]
Aici 00201206 este Numărul de Serii legate de Studiu și 00201208 este Numărul de Instanțe legate de Studiu. Numerele tag-urilor sunt explicate în Tag-uri DICOM explicate.
WADO-RS: preluarea
WADO-RS este serviciul de preluare DICOMweb. GET /studies/{StudyInstanceUID} returnează un studiu complet ca fișiere DICOM Partea 10 într-un răspuns multipart; sufixul /metadata returnează antete ca JSON fără date pixel; /frames/{n} returnează pixeli dintr-un cadru; iar /rendered returnează o imagine JPEG sau PNG redată de server cu parametri de fereastră, vizualizare și calitate.
GET /studies/{study}cuAccept: multipart/related; type="application/dicom"returnează fiecare instanță ca fișier DICOM Partea 10, câte o parte.GET /studies/{study}/metadatareturnează antetele tuturor instanțelor ca JSON, fără date pixel. Vizualizatoarele apelează acest lucru mai întâi pentru a construi aspectul, apoi preiau pixeli cadru cu cadru.GET /studies/{study}/series/{series}/instances/{instance}/frames/1returnează datele pixel ale unui cadru, opțional transcodificate (parametrutransfer-syntax).GET …/instances/{instance}/renderedcuAccept: image/jpegreturnează o imagine redată de server, cu parametriwindow,viewportșiquality. Acesta este ceea ce folosește un portal pacient ușor pentru a afișa o previzualizare.
STOW-RS: stocarea
STOW-RS este serviciul de stocare DICOMweb. Un client trimite POST /studies cu un corp multipart/related în care fiecare parte este un fișier DICOM. Arhiva răspunde cu o listă de instanțe acceptate și eșuate și motivul fiecărui eșec, și verifică dacă orice Study Instance UID dat în URL corespunde fișierelor încărcate.
POST /dicomweb/studies
Content-Type: multipart/related; type="application/dicom"; boundary=abc
Fiecare parte este un fișier DICOM. Răspunsul listează instanțele acceptate și cele eșuate cu motive (clasă SOP greșită, UID duplicat). Arhivele validează că Study Instance UID din URL, dacă este furnizat, corespunde fișierelor.
Securitate
DICOMweb nu are autentificare proprie; se bazează pe HTTPS și pe ceea ce pune serverul în față: token-uri purtătoare OAuth 2.0 în majoritatea arhivelor moderne, adesea combinate cu scopuri SMART on FHIR atunci când vizualizatorul este lansat dintr-un EHR. Înregistrarea cine a preluat ce studiu este responsabilitatea arhivei, nu a protocolului.
Unde este utilizat
Fiecare PACS major și arhivă neutră de furnizor oferă acum un punct final DICOMweb, iar arhivele open-source (Orthanc, dcm4chee, Google Cloud Healthcare API, Azure DICOM service) sunt DICOMweb-first. Vizualizatoarele web precum OHIF sunt construite în întregime pe QIDO-RS și WADO-RS. Într-o lume FHIR, o resursă ImagingStudy indică un punct final DICOMweb; pixelii nu trec niciodată prin FHIR.
Anpheros nu stochează imagini. Fișa unui pacient poate conține raportul radiologic ca DocumentReference sau DiagnosticReport și, acolo unde un spital oferă unul, un link către vizualizatorul său; datele DICOM în sine rămân în arhiva spitalului. Pentru a obține propriile imagini ca pacient, consultați Cum să obțineți imaginile CT sau RMN.
Pagini conexe
- FHIR ImagingStudy vs DICOMweb
- Tag-uri DICOM explicate
- PACS vs RIS vs VNA
- Cum să obțineți imaginile CT sau RMN (DICOM)
- Standarde de interoperabilitate în sănătate: harta
- DICOM vs FHIR pentru dezvoltatori
Surse
- DICOM PS3.18: Web Services
- DICOM PS3.7: Message Exchange
- Prezentare generală DICOMweb (Comitetul de Standarde DICOM)
- Documentație OHIF Viewer
Întrebări frecvente
Este DICOMweb un standard diferit de DICOM?
Nu. Este Partea 18 a aceluiași standard DICOM. Obiectele, tag-urile și UID-urile sunt identice; doar transportul se schimbă de la protocolul propriu DICOM la HTTP.
Care este diferența dintre WADO-URI și WADO-RS?
WADO-URI este serviciul mai vechi: un obiect per cerere, selectat cu parametri de interogare (?requestType=WADO&studyUID=…). WADO-RS este RESTful, poate returna studii sau serii întregi, metadate ca JSON și cadre individuale, și este ceea ce implementează sistemele noi.
Pot folosi DICOMweb fără un PACS?
Aveți nevoie de o arhivă care îl implementează. Serverele open-source precum Orthanc și dcm4chee oferă DICOMweb din start și sunt utilizate frecvent pentru dezvoltare și pentru clinici mici.
Înlocuiește FHIR DICOMweb?
Nu. FHIR descrie studiul (ImagingStudy) și raportul (DiagnosticReport); DICOMweb livrează imaginile. Un vizualizator folosește ambele: FHIR pentru a afla că un studiu există, DICOMweb pentru a-l afișa.
Încearcă în Anpheros Daily
Păstrează în Anpheros Daily rapoartele de imagistică și investigații într-un singur loc, gata să le prezinți la următorul control.
Cum funcționează în aplicație →
Anpheros construiește un dosar medical pe care pacientul îl controlează și îl poate da oricărei clinici, pe o platformă HL7 FHIR R4, cu sediul în UE. Ghidurile te ajută să-ți înțelegi și să-ți organizezi sănătatea; nu înlocuiesc medicul.
Despre Anpheros →