Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
DICOM ve FHIR: Görüntüleme Verileri ve Klinik Veriler
DICOM tıbbi görüntüleri taşır, FHIR ise etraflarındaki klinik verileri: her biri neleri kapsar, ImagingStudy ve DiagnosticReport nasıl bağlanır ve neleri nereye saklamalı.
DICOM ve FHIR rakip değildir: DICOM tıbbi görüntüler için standarttır — bir X-ışını, BT veya MR'ın pikselleri ve teknik meta verileri — HL7 FHIR ise bunların etrafındaki klinik veriler için standarttır, örneğin sipariş, radyolog raporu, bulgular ve ait oldukları hasta gibi. Tipik bir görüntüleme iş akışı her ikisini de kullanır: tarayıcı ve PACS DICOM ile konuşur, hastane ve hasta uygulamaları FHIR ile konuşur ve FHIR kaynakları DICOM çalışmasını kopyalamak yerine ona işaret eder. Bu sayfa, her standardın nerede başlayıp nerede bittiğini, nasıl bağlandıklarını ve Anpheros gibi bir FHIR arka ucunun neleri depolaması gerektiğini ve neleri depolamaması gerektiğini açıklar.
Kısa Cevap
| DICOM | HL7 FHIR R4 | |
|---|---|---|
| Ne taşır | Görüntüler ve bunların meta verileri (modalite, vücut bölümü, dilim aralığı, cihaz, UID'ler) | Klinik veriler: hastalar, siparişler, raporlar, gözlemler, ilaçlar… |
| Tipik boyut | Çalışma başına megabaytlar ila gigabaytlar | Kaynak başına kilobaytlar |
| Veri birimi | Çalışma → Seri → Örnek, küresel olarak benzersiz UID'lerle tanımlanır | Kaynaklar (Patient, ServiceRequest, ImagingStudy, DiagnosticReport…) referanslarla |
| Taşıma | DIMSE ağ hizmetleri (C-STORE, C-FIND, C-MOVE) ve DICOMweb REST (QIDO-RS, WADO-RS, STOW-RS) | HTTPS üzerinden REST (JSON veya XML ile) |
| Saklandığı yer | PACS veya satıcıdan bağımsız arşiv (VNA) | EHR, FHIR sunucusu, sağlık verileri platformu |
| Kimler tarafından okunur | Radyoloji görüntüleyicileri, yapay zeka görüntü modelleri, modaliteler | Klinik uygulamalar, hasta uygulamaları, analizler, metin ve değerler üzerinde çalışan yapay zeka |
DICOM'un Amacı
DICOM (Digital Imaging and Communications in Medicine), bir görüntünün nasıl kodlandığını ve görüntüleme ekipmanlarının bunu nasıl değiştirdiğini tanımlar. Her görüntü dosyası, yüzlerce öznitelik içeren bir başlık taşır — hasta ve çalışma tanımlayıcıları, modalite (CT, MR, DX, US…), edinme parametreleri, piksel aralığı — piksel verilerinin yanında. Görüntüler, bir çalışma içindeki seriler içindeki örnekler olarak gruplandırılır, her biri 2.25.181945… gibi bir UID'ye sahiptir, böylece aynı çalışma herhangi bir arşivde tekrar bulunabilir.
DICOMweb, DICOM'u HTTP'ye getirdi: çalışmalar için arama yapmak üzere QIDO-RS, bunları almak üzere WADO-RS, bunları depolamak üzere STOW-RS. Bu, görüntüleri web görüntüleyicilerinden ve bulut hizmetlerinden erişilebilir hale getirir, ancak yük hala DICOM'dur.
DICOM'un iyi yapmadığı şey klinik hikayedir: çalışmanın neden istendiği, radyoloğun ne sonucuna vardığı, hangi sorunla ilgili olduğu ve laboratuvar sonuçları ve ilaçlarla nasıl uyduğu. Bu FHIR'ın işidir.
FHIR'ın görüntüleme alanındaki işlevleri
FHIR R4, bir görüntüleme iş akışının her adımı için kaynaklara sahiptir:
- ServiceRequest — sipariş: "göğüs röntgeni, iki görünüm, şüpheli zatürre".
- ImagingStudy — bir DICOM çalışmasının özeti (UID'ler, modalite, seri ve örnek sayısı, vücut bölgesi) ve görüntülerin nerede alınabileceğini belirten bir
endpoint, örneğin bir DICOMweb WADO-RS adresi. Piksel içermez. - DiagnosticReport — radyolog raporu: kod, durum, sonuç, yayınlanma zamanı ve isteğe bağlı olarak orijinal raporun
presentedFormiçinde PDF olarak sunulması;imagingStudybunu çalışmaya bağlar. - Observation — sorgulanabilir olması gereken bireysel bulgular veya ölçümler, örneğin bir nodül boyutu.
- DocumentReference — PDF rapor veya JPEG olarak dışa aktarılan anahtar bir görüntü gibi bir belge.
Bir PACS'taki bir çalışmaya işaret eden bir ImagingStudy (geçerli FHIR R4 yapısı):
{
"resourceType": "ImagingStudy",
"status": "available",
"subject": {"reference": "Patient/example"},
"identifier": [{"system": "urn:dicom:uid", "value": "urn:oid:2.25.181945102383749012843512396725468820"}],
"started": "2026-10-03T10:20:00-05:00",
"modality": [{"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "DX"}],
"numberOfSeries": 1,
"numberOfInstances": 2,
"endpoint": [{"reference": "Endpoint/pacs-wado"}],
"series": [{
"uid": "2.25.30584718293846127394857102938475",
"modality": {"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "DX"},
"bodySite": {"system": "http://snomed.info/sct", "code": "51185008", "display": "Thoracic structure"},
"numberOfInstances": 2,
"instance": [{"uid": "2.25.11223344556677889900112233445566",
"sopClass": {"system": "urn:ietf:rfc:3986", "code": "urn:oid:1.2.840.10008.5.1.4.1.1.1.1"}}]
}]
}
Aynı çalışma üzerindeki rapor, bir DiagnosticReport olarak ( FHIR R4 doğrulayıcısını geçer):
{
"resourceType": "DiagnosticReport",
"status": "final",
"category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v2-0074", "code": "RAD", "display": "Radiology"}]}],
"code": {"coding": [{"system": "http://loinc.org", "code": "36643-5", "display": "XR Chest 2 Views"}], "text": "Chest X-ray, 2 views"},
"subject": {"reference": "Patient/example"},
"effectiveDateTime": "2026-10-03T10:20:00-05:00",
"issued": "2026-10-03T15:05:00-05:00",
"performer": [{"display": "Springfield Imaging Center"}],
"conclusion": "No acute cardiopulmonary abnormality.",
"presentedForm": [{"contentType": "application/pdf", "url": "https://imaging.springfield-hospital.test/reports/RPT-8812.pdf", "title": "Radiology report"}]
}
İki sistemin bağlantısı
modality (X-ray, CT, MR) ──DICOM──► PACS / VNA ◄──DICOMweb (WADO-RS)── image viewer, AI image model
▲
ImagingStudy.endpoint│ (where the images are)
│
order (ServiceRequest) ──► study ──► report (DiagnosticReport) ──► patient record (FHIR)
│
patient app, clinic system, AI assistant (text and values)
Sistemleri basit tutan kural: görüntüler görüntü arşivinde kalır; klinik kayıt, raporu, önemli bulguları ve görüntülere bir işaretçiyi tutar. DICOM çalışmalarını bir klinik veritabanına kopyalamak, kaydı çoğu okuyucu için daha kullanışlı hale getirmeden depolama ve gizlilik riskini katlar.
Diğer standartlar hastaneler arasındaki boşlukları doldurur: kuruluşlar arasında görüntü belgelerini paylaşmak için XDS-I gibi IHE profilleri ve bir radyoloji görüntüleyicisini ve raporlama uygulamasını aynı hasta ve çalışma üzerinde tutmak için FHIRcast.
Görüntüleme, birlikte çalışabilirlik ve Yapay Zeka
Tıbbi görüntülerdeki Yapay Zeka (tespit, segmentasyon, önceliklendirme) genellikle görüntüleme departmanında veya özel bir platformda bulunan DICOM piksel verileri üzerinde çalışır. Bir hastaya veya doktora tüm kayıt hakkında akıl yürütmesinde yardımcı olan Yapay Zeka — "son akciğer röntgeni ne gösterdi ve öksürük ve antibiyotiklerle nasıl ilişkili?" — rapor, bulgular ve FHIR'ın taşıdığı diğer klinik veriler üzerinde çalışır. Her iki tür Yapay Zeka da altyapıdan aynı şeyi gerektirir: kodlar, zamanlar ve kaydedilmiş bir kökeni olan veriler.
Anpheros Nerede Yer Alıyor?
Anpheros, her hastanın kaydını HL7 FHIR R4 olarak depolar. Görüntüleme için bu şu anlama gelir:
- Depolananlar: radyoloji raporu bir
DiagnosticReportolarak, orijinal rapor veya anahtar bir görüntü birDocumentReferenceolarak (belge başına 25 MiB'ye kadar), bulgularObservationolarak ve istek birServiceRequestolarak. Her yazma işlemi köken bilgisi taşır ve hasta hangi uygulamaların bunu okuyabileceğine karar verir. - Depolanmayanlar: DICOM çalışmaları. Anpheros bir PACS değildir, DICOMweb arayüzüne sahip değildir ve bugün
ImagingStudykaynağını desteklememektedir, bu nedenle görüntüleri indeksleyemez veya sunamaz. Görüntüleri okuyamaz veya yorumlayamaz.
Anpheros Daily uygulamasında bir hasta, bir görüntüleme raporunu fotoğraflayabilir veya yükleyebilir ve bunu belgeleri arasında kaydının geri kalanıyla birlikte saklayabilir. Bir uygulama veya klinik entegrasyonu oluşturan bir geliştirici için pratik ayrım şudur: görüntüleri kendi görüntüleme sisteminizde tutun, raporu ve bulguları hastanın FHIR kaydına yazın. Klinik sistemlerini bir FHIR arka ucuyla entegre etme bölümü, bir ziyareti ve belgelerini tek bir işlemde nasıl yazacağınızı gösterir ve DiagnosticReport örneği bir raporun yapısını gösterir.
Sıkça Sorulan Sorular
DICOM ve FHIR arasındaki fark nedir?
DICOM, tıbbi görüntüleri ve bunların teknik meta verilerini kodlar ve değiş tokuş eder; FHIR ise siparişler, raporlar, gözlemler ve ilaçlar gibi klinik verileri değiş tokuş eder. Pratikte FHIR kaynakları görüntüleme çalışmalarını tanımlar ve referans gösterir, görüntüler ise DICOM'da kalır.
FHIR tıbbi görüntüleri saklayabilir mi?
FHIR, küçük görüntüleri ekler olarak taşıyabilir (DocumentReference veya Media'da anahtar bir görüntü), ancak tam teşhis çalışmaları için tasarlanmamıştır. ImagingStudy kaynağı bir DICOM çalışmasını tanımlar ve nerede alınabileceğine işaret eder; pikseller bir PACS veya arşivde kalır.
DICOMweb nedir?
DICOM standardının RESTful kısmı: QIDO-RS aramak, WADO-RS almak ve STOW-RS HTTP üzerinden çalışmaları saklamak için kullanılır. Bir FHIR ImagingStudy, bir DICOMweb uç noktasına işaret edebilir.
Hangi FHIR kaynağı radyoloji raporunu tutar?
DiagnosticReport, radyoloji kategorisi, muayene için bir LOINC kodu, bir sonuç ve gerekirse orijinal raporu PDF olarak presentedForm içinde tutar. Aranabilir olması gereken ölçümler ayrı Gözlemler (Observations) haline gelir.
Anpheros DICOM'u destekliyor mu?
Hayır. Anpheros, görüntülemenin klinik tarafını — raporları, bulguları, belgeleri ve siparişleri — hastanın FHIR R4 kaydında saklar. DICOM görüntülerini saklamaz, sunmaz veya yorumlamaz ve bugün ImagingStudy'yi desteklemez.
İlgili Konular
- Sağlık verisi birlikte çalışabilirliği: FHIR etrafındaki standartlar
- FHIR platformu: Anpheros'un depoladığı 26 kaynak türü
- FHIR'a karşı özel bir tıbbi veritabanı
- Laboratuvar sonuçları API'si: laboratuvar raporları için aynı desen
- Klinik sistemleri bir FHIR arka ucuyla nasıl entegre edilir
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card