Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
DICOM vs FHIR: date imagistice și date clinice
DICOM transportă imagini medicale, FHIR datele clinice din jurul lor: ce acoperă fiecare, cum se conectează ImagingStudy și DiagnosticReport și ce să stocați unde.
DICOM și FHIR nu sunt concurenți: DICOM este standardul pentru imagini medicale — pixelii și metadatele tehnice ale unei radiografii, CT sau RMN — în timp ce HL7 FHIR este standardul pentru datele clinice aferente, cum ar fi comanda, raportul radiologului, constatările și pacientul căruia îi aparțin. Un flux de lucru imagistic tipic le folosește pe amândouă: scanerul și PACS-ul folosesc DICOM, aplicațiile spitalicești și cele pentru pacienți folosesc FHIR, iar resursele FHIR indică studiul DICOM în loc să-l copieze. Această pagină explică unde începe și unde se termină fiecare standard, cum se conectează și ce ar trebui și ce nu ar trebui să stocheze un backend FHIR precum Anpheros.
Răspunsul scurt
| DICOM | HL7 FHIR R4 | |
|---|---|---|
| Ce transportă | Imagini și metadatele acestora (modalitate, parte a corpului, spațiere între felii, dispozitiv, UID-uri) | Date clinice: pacienți, comenzi, rapoarte, observații, medicamente… |
| Dimensiune tipică | Megabytes până la gigabytes per studiu | Kilobytes per resursă |
| Unitate de date | Studiu → Serie → Instanță, identificată prin UID-uri unice la nivel global | Resurse (Patient, ServiceRequest, ImagingStudy, DiagnosticReport…) cu referințe |
| Transport | Servicii de rețea DIMSE (C-STORE, C-FIND, C-MOVE) și REST DICOMweb (QIDO-RS, WADO-RS, STOW-RS) | REST peste HTTPS cu JSON sau XML |
| Stocat în | PACS sau arhivă neutră de la furnizor (VNA) | EHR, server FHIR, platformă de date de sănătate |
| Citit de | Vizualizatoare radiologice, modele AI pentru imagini, modalități | Aplicații clinice, aplicații pentru pacienți, analize, AI care lucrează cu text și valori |
La ce folosește DICOM
DICOM (Digital Imaging and Communications in Medicine) definește cum este codificată o imagine și cum echipamentele de imagistică o schimbă. Fiecare fișier imagine conține un antet (header) cu sute de atribute — identificatori de pacient și studiu, modalitate (CT, MR, DX, US…), parametri de achiziție, spațiere pixeli — alături de datele pixelilor. Imaginile sunt grupate ca instanțe în serii, în cadrul unui studiu, fiecare cu un UID precum 2.25.181945…, astfel încât același studiu poate fi regăsit în orice arhivă.
DICOMweb a adus DICOM pe HTTP: QIDO-RS pentru a căuta studii, WADO-RS pentru a le prelua, STOW-RS pentru a le stoca. Aceasta face imaginile accesibile din vizualizatoare web și servicii cloud, dar sarcina utilă (payload) este în continuare DICOM.
Ce nu face DICOM bine este povestea clinică: de ce a fost comandat studiul, la ce a concluzionat radiologul, cu ce problemă se leagă și cum se potrivește cu rezultatele de laborator și medicația. Aceasta este treaba FHIR.
Ce face FHIR în legătură cu imagistica
FHIR R4 are resurse pentru fiecare pas al unui flux de lucru de imagistică:
- ServiceRequest — comanda: „radiografie toracică, două incidențe, pneumonie suspectată”.
- ImagingStudy — un rezumat al unui studiu DICOM (UID-uri, modalitate, număr de serii și instanțe, localizare corporală) și un
endpointcare indică unde pot fi preluate imaginile, de exemplu o adresă DICOMweb WADO-RS. Nu conține pixeli. - DiagnosticReport — raportul radiologului: cod, stare, concluzie, data emiterii și, opțional, raportul original ca PDF în
presentedForm;imagingStudyîl leagă de studiu. - Observation — constatări sau măsurători individuale care trebuie să fie interogabile, cum ar fi dimensiunea unui nodul.
- DocumentReference — un document, cum ar fi un raport PDF sau o imagine cheie exportată ca JPEG.
Un ImagingStudy care indică un studiu într-un PACS (structură FHIR R4 validă):
{
"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"}}]
}]
}
Raportul despre același studiu, ca DiagnosticReport (trece validatorul FHIR R4):
{
"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"}]
}
Cum se conectează cele două
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)
Regula care menține sistemele simple: imaginile rămân în arhiva de imagistică; registrul clinic păstrează raportul, constatările importante și un indicator către imagini. Copierea studiilor DICOM într-o bază de date clinică multiplică riscul de stocare și de confidențialitate, fără a face registrul mai util pentru majoritatea cititorilor săi.
Alte standarde umplu golurile dintre spitale: profiluri IHE precum XDS-I pentru partajarea documentelor de imagistică între organizații și FHIRcast pentru a menține un vizualizator de radiologie și o aplicație de raportare pe același pacient și studiu.
Imagistică, interoperabilitate și AI
AI pe imagini medicale (detecție, segmentare, triaj) funcționează pe date pixelare DICOM, de obicei în cadrul departamentului de imagistică sau pe o platformă specializată. AI care ajută un pacient sau un medic să raționeze despre întregul dosar – „ce a arătat ultima radiografie toracică și cum se leagă aceasta de tuse și de antibiotice?” – funcționează pe baza raportului, a constatărilor și a restului datelor clinice, care sunt ceea ce transportă FHIR. Ambele tipuri de AI necesită același lucru de la infrastructură: date cu coduri, timpi și o origine înregistrată.
Unde se încadrează Anpheros
Anpheros stochează înregistrările fiecărui pacient ca HL7 FHIR R4. Pentru imagistică, aceasta înseamnă:
- Stocate: raportul radiologic ca
DiagnosticReport, raportul original sau o imagine cheie caDocumentReference(până la 25 MiB per document), constatări caObservation, și comanda caServiceRequest. Fiecare scriere poartă proveniență, iar pacientul decide ce aplicații o pot citi. - Nu sunt stocate: studii DICOM. Anpheros nu este un PACS, nu are interfață DICOMweb și nu suportă resursa
ImagingStudyastăzi, deci nu poate indexa sau servi imagini. Nu citește și nu interpretează imagini.
În aplicația Anpheros Daily, un pacient poate fotografia sau încărca un raport de imagistică și îl poate păstra în documentele sale alături de restul înregistrării. Pentru un dezvoltator care construiește o aplicație sau o integrare clinică, diviziunea practică este: păstrați imaginile în sistemul dvs. de imagistică, scrieți raportul și constatările în înregistrarea FHIR a pacientului. Cum să integrați sistemele clinice cu un backend FHIR arată cum să scrieți o vizită și documentele sale într-o singură tranzacție, iar Exemplu DiagnosticReport arată structura unui raport.
Întrebări frecvente
Care este diferența dintre DICOM și FHIR?
DICOM codifică și schimbă imagini medicale și metadatele lor tehnice; FHIR schimbă date clinice precum comenzi, rapoarte, observații și medicamente. În practică, resursele FHIR descriu și fac referire la studii de imagistică, în timp ce imaginile în sine rămân în DICOM.
Poate FHIR să stocheze imagini medicale?
FHIR poate transporta imagini mici ca atașamente (o imagine cheie într-un DocumentReference sau Media), dar nu este conceput pentru studii diagnostice complete. Resursa ImagingStudy descrie un studiu DICOM și indică unde poate fi recuperat; pixelii rămân într-un PACS sau arhivă.
Ce este DICOMweb?
Partea RESTful a standardului DICOM: QIDO-RS pentru căutare, WADO-RS pentru recuperare și STOW-RS pentru stocarea studiilor prin HTTP. Un ImagingStudy FHIR poate indica un endpoint DICOMweb.
Ce resursă FHIR deține un raport radiologic?
DiagnosticReport, cu o categorie de radiologie, un cod LOINC pentru examen, o concluzie și, dacă este necesar, raportul original ca PDF în presentedForm. Măsurătorile care trebuie să fie căutabile devin Observații separate.
Suportă Anpheros DICOM?
Nu. Anpheros stochează partea clinică a imagisticii — rapoarte, constatări, documente și comenzi — în registrul FHIR R4 al pacientului. Nu stochează, servește sau interpretează imagini DICOM și nu suportă ImagingStudy în prezent.
Conexe
- Interoperabilitatea datelor din domeniul sănătății: standardele din jurul FHIR
- Platforma FHIR: cele 26 de tipuri de resurse pe care Anpheros le stochează
- FHIR vs. o bază de date medicală personalizată
- API pentru rezultate de laborator: același model pentru rapoarte de laborator
- Cum să integrați sistemele clinice cu un backend FHIR
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card