Kısa cevap: DICOMweb, DICOM standardının 18. Bölümünde tanımlanan web servisleri kümesidir. Bir DICOM arşivini düz HTTPS üzerinden sunar: QIDO-RS (DICOM Nesneleri için Kimliğe Dayalı Sorgu) çalışmaları, serileri ve örnekleri arar; WADO-RS (DICOM Nesnelerine Web Erişimi) bunları tam DICOM dosyaları olarak, JSON formatında meta veri olarak veya işlenmiş JPEG/PNG olarak alır; STOW-RS (Web Üzerinden Depolama) yeni nesneleri yükler. Daha eski olan WADO-URI sorgu parametreleri aracılığıyla tek bir nesne alır. Tarayıcı tabanlı görüntüleyiciler, klasik DICOM ağını konuşamadıkları için DICOMweb kullanır.
Klasik DICOM vs DICOMweb
Klasik DICOM ağ iletişimi (standartın 7. ve 8. bölümleri), yapılandırılmış düğümler arasında C-FIND, C-MOVE, C-GET ve C-STORE gibi hizmetlerle TCP üzerinden ikili bir protokol kullanır. DICOMweb (18. Bölüm) aynı işlemleri HTTP'ye eşler: QIDO-RS arama için, WADO-RS alma için ve STOW-RS depolama için kullanılır. Bu, internet üzerinden ve tarayıcılardan çalışır.
Klasik DICOM (Bölüm 7 ve 8), adlandırılmış hizmetler üzerinden TCP üzerinde kendi ikili protokolünü kullanır: sorgulama için C-FIND, alma için C-MOVE veya C-GET, gönderme için C-STORE. İki bilinen düğüm (AE başlıkları, IP adresleri, portlar) arasında yapılandırılmış bir "ilişki" gerektirir, bu da bir hastane içinde uygundur ve internet üzerinden zordur. DICOMweb aynı fikirleri HTTP'ye eşler:
| Görev | Klasik DICOM | DICOMweb |
|---|---|---|
| Bir çalışma bul | C-FIND | QIDO-RS: GET /studies?PatientID=… |
| Bir çalışma al | C-MOVE / C-GET | WADO-RS: GET /studies/{StudyInstanceUID} |
| Yalnızca meta veriyi oku | Örnek düzeyinde C-FIND | WADO-RS: GET /studies/{uid}/metadata |
| Görüntülenebilir bir resim al | Yerel olarak alıp işleme | WADO-RS işlenmiş: GET …/instances/{uid}/rendered |
| Bir arşive resim gönder | C-STORE | STOW-RS: POST /studies |
| İş listelerini yönet | MWL (bir iş listesinde C-FIND) | UPS-RS |
Kaynak hiyerarşisi DICOM'un kendi modelini takip eder: bir çalışma (tarayıcıya bir ziyaret) serileri (her biri bir edinme) içerir, bu da örnekleri (tek resimler veya çok çerçeveli nesneler) içerir, her biri küresel olarak benzersiz bir UID ile tanımlanır.
QIDO-RS: arama
QIDO-RS, DICOMweb arama hizmetidir. Bir istemci, PatientID, StudyDate veya ModalitiesInStudy gibi sorgu parametreleri ve Accept başlığı application/dicom+json ile birlikte GET /studies, /series veya /instances gönderir. Arşiv, her DICOM özniteliğinin sekiz haneli etiketiyle birlikte değer gösterimi ve değerleriyle anahtarlanan bir JSON dizisi döndürür.
GET /dicomweb/studies?PatientID=12345&StudyDate=20260101-20261231&ModalitiesInStudy=CT
Accept: application/dicom+json
Yanıt, çalışmaların bir JSON dizisidir. Her öznitelik, değer gösterimi ve değerleriyle birlikte etiketi (sekiz onaltılık basamak olarak grup ve öğe) ile anahtarlanır:
[{
"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]}
}]
Burada 00201206 Çalışma İlgili Seri Sayısı ve 00201208 Çalışma İlgili Örnek Sayısı'dır. Etiket numaraları DICOM etiketleri açıklandı bölümünde açıklanmıştır.
WADO-RS: alma
WADO-RS, DICOMweb alma hizmetidir. GET /studies/{StudyInstanceUID} tüm çalışmayı DICOM Bölüm 10 dosyaları olarak çok parçalı bir yanıtta döndürür; /metadata soneki piksel verisi olmadan başlıkları JSON olarak döndürür; /frames/{n} bir karenin piksellerini döndürür; ve /rendered pencere, görüntü alanı ve kalite parametreleriyle sunucu tarafından oluşturulmuş bir JPEG veya PNG döndürür.
Accept: multipart/related; type="application/dicom"ileGET /studies/{study}her örneği tek tek DICOM Bölüm 10 dosyası olarak döndürür.GET /studies/{study}/metadatatüm örneklerin başlıklarını piksel verisi olmadan JSON olarak döndürür. Görüntüleyiciler önce düzeni oluşturmak için bunu çağırır, ardından pikselleri kare kare çeker.GET /studies/{study}/series/{series}/instances/{instance}/frames/1isteğe bağlı olarak yeniden kodlanmış (transfer-syntaxparametresi) bir karenin piksel verisini döndürür.GET …/instances/{instance}/renderedAccept: image/jpegile bir sunucu tarafından işlenmiş bir resim döndürür,window,viewportvequalityparametreleriyle birlikte. Bu, hafif bir hasta portalının önizleme göstermek için kullandığı şeydir.
STOW-RS: depolama
STOW-RS, DICOMweb depolama hizmetidir. Bir istemci, her parçanın bir DICOM dosyası olduğu çok parçalı/ilişkili bir gövde ile POST /studies gönderir. Arşiv, kabul edilen ve başarısız olan örneklerin bir listesi ve her başarısızlığın nedeni ile yanıt verir ve URL'de verilen herhangi bir Study Instance UID'nin yüklenen dosyalarla eşleştiğini kontrol eder.
POST /dicomweb/studies
Content-Type: multipart/related; type="application/dicom"; boundary=abc
Her bölüm tek bir DICOM dosyasıdır. Yanıt, kabul edilen ve başarısız olan örnekleri nedenleriyle birlikte listeler (yanlış SOP sınıfı, yinelenen UID). Arşivler, URL'deki Çalışma Örnek UID'sinin, verilmişse, dosyalarla eşleştiğini doğrular.
Güvenlik
DICOMweb'in kendi oturum açma özelliği yoktur; HTTPS'ye ve sunucunun önüne koyduğu her şeye dayanır: çoğu modern arşivde OAuth 2.0 taşıyıcı belirteçleri, genellikle görüntüleyicinin bir EHR'den başlatıldığı durumlarda SMART on FHIR kapsamlarıyla birleştirilir. Hangi çalışmanın kim tarafından alındığını kaydetmek arşivin işidir, protokolün değil.
Nerede kullanılır
Her büyük PACS ve satıcıdan bağımsız arşiv artık bir DICOMweb uç noktası sunmaktadır ve açık kaynaklı arşivler (Orthanc, dcm4chee, Google Cloud Healthcare API, Azure DICOM hizmeti) DICOMweb önceliklidir. OHIF gibi web görüntüleyicileri tamamen QIDO-RS ve WADO-RS üzerine kurulmuştur. Bir FHIR dünyasında, bir ImagingStudy kaynağı bir DICOMweb uç noktasına işaret eder; pikseller asla FHIR üzerinden geçmez.
Anpheros resimleri depolamaz. Bir hastanın kaydı, radyoloji raporunu bir DocumentReference veya DiagnosticReport olarak ve bir hastanenin sağladığı durumlarda görüntüleyicisine bir bağlantı içerebilir; DICOM verileri hastanenin arşivinde kalır. Kendi resimlerinizi hasta olarak almak için BT veya MRG resimlerinizi nasıl alırsınız bölümüne bakın.
İlgili sayfalar
- FHIR ImagingStudy vs DICOMweb
- DICOM etiketleri açıklandı
- PACS vs RIS vs VNA
- BT veya MRG resimlerinizi nasıl alırsınız (DICOM)
- Sağlık birlikte çalışabilirlik standartları: harita
- Geliştiriciler için DICOM vs FHIR
Kaynaklar
- DICOM PS3.18: Web Hizmetleri
- DICOM PS3.7: Mesaj Değişimi
- DICOMweb genel bakış (DICOM Standartları Komitesi)
- OHIF Görüntüleyici belgeleri
Sık sorulan sorular
DICOMweb, DICOM'dan farklı bir standart mı?
Hayır. Aynı DICOM standardının 18. Bölümüdür. Nesneler, etiketler ve UID'ler aynıdır; yalnızca taşıma, DICOM'un kendi protokolünden HTTP'ye değişir.
WADO-URI ve WADO-RS arasındaki fark nedir?
WADO-URI daha eski hizmettir: istek başına bir nesne, sorgu parametreleriyle seçilir (?requestType=WADO&studyUID=…). WADO-RS RESTful'dur, tüm çalışmaları veya serileri, JSON olarak meta verileri ve tek tek kareleri döndürebilir ve yeni sistemlerin uyguladığıdır.
PACS olmadan DICOMweb kullanabilir miyim?
Bunu uygulayan bir arşive ihtiyacınız var. Orthanc ve dcm4chee gibi açık kaynaklı sunucular kutudan çıktığı gibi DICOMweb sağlar ve geliştirme ve küçük klinikler için yaygın olarak kullanılır.
FHIR, DICOMweb'in yerini mi alıyor?
Hayır. FHIR çalışmayı (ImagingStudy) ve raporu (DiagnosticReport) tanımlar; DICOMweb görüntüleri teslim eder. Bir görüntüleyici her ikisini de kullanır: bir çalışmanın var olduğunu öğrenmek için FHIR, onu göstermek için DICOMweb.
Anpheros Daily'de Deneyin
Tarama ve test raporlarınızı Anpheros Daily'de tek bir yerde saklayın, bir sonraki ziyaretinizde göstermeye hazır.
Uygulamada nasıl çalışır →
Anpheros, hasta kontrolünde olan ve herhangi bir klinik ile paylaşılabilecek, AB merkezli bir HL7 FHIR R4 platformu üzerinde tıbbi kayıtlar oluşturur. Bu rehberler, sağlığınızı anlamanıza ve düzenlemenize yardımcı olur; doktorunuzun yerini tutmaz.
Anpheros Hakkında →