FHIR ImagingStudy vs DICOMweb: ce conține fiecare

Q: Ce s-a schimbat în FHIR R5 pentru ImagingStudy?

R5 păstrează aceeași formă, curăță denumirile (de exemplu, procedure înlocuiește procedureReference și procedureCode ) și aliniază gestionarea locației corpului. R4 rămâne versiunea pe care o folosesc majoritatea arhivelor și profilurilor naționale.

Răspuns scurt: ImagingStudy este o resursă FHIR care spune acest pacient a făcut un CT la această dată, cu aceste serii și aceste UIDs de instanță, iar imaginile sunt acolo. DICOMweb este acolo: interfața REST a arhivei care deține pixelii. FHIR transportă descrierea și raportul; DICOM transportă imaginile. Un ImagingStudy face referire la o resursă Endpoint al cărei connectionType este dicom-wado-rs, iar un vizualizator combină cele două.

Ce conține ImagingStudy

O resursă FHIR ImagingStudy conține metadatele unui studiu imagistic: UID-ul DICOM Study Instance ca identificator, un status, subiectul Pacient, întâlnirea (encounter), ora de începere și Serviciul de comandă (ServiceRequest), coduri de modalitate din vocabularul DICOM DCM, numărul de serii și instanțe, Punctul de acces (Endpoint) unde se află imaginile și fiecare serie cu instanțele și UID-urile sale. Nu conține pixeli.

identifier: UID-ul Studiului DICOM, ca urn:oid:1.2.840… cu sistemul urn:dicom:uid;
status: registered, available, cancelled, entered-in-error, unknown;
subject: Pacientul; encounter, started, referrer, basedOn (ServiceRequest-ul care l-a comandat);
modality: coduri din vocabularul propriu DICOM (CT, MR, US, CR, DX…), sistem http://dicom.nema.org/resources/ontology/DCM;
numberOfSeries, numberOfInstances;
endpoint: unde să fie preluate imaginile;
series[]: fiecare cu UID-ul Seriei sale, modalitatea, locația corpului, instance[] cu UID-ul Instanței SOP și UID-ul Clasei SOP.

Ce nu conține: date pixel, setări de fereastră, antetul DICOM complet sau textul raportului. Raportul este un DiagnosticReport cu imagingStudy care face referire înapoi.

Un exemplu valid FHIR R4

Un exemplu valid FHIR R4 ImagingStudy include UID-ul Study Instance ca identificator cu sistemul urn:dicom:uid, statusul disponibil, o modalitate CT din sistemul de coduri DICOM DCM, pacientul, ora de începere, numărul de serii și instanțe, o referință către un Punct de acces (Endpoint) cu connectionType dicom-wado-rs și intrări de serii cu UID-urile lor, localizarea corporală și UID-ul clasei SOP.

{
  "resourceType": "ImagingStudy",
  "id": "ct-chest-2026-03",
  "identifier": [{"system": "urn:dicom:uid", "value": "urn:oid:1.2.840.113619.2.55.3.2831164356.781.1710415000.1"}],
  "status": "available",
  "modality": [{"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT"}],
  "subject": {"reference": "Patient/example"},
  "started": "2026-03-14T09:12:00+01:00",
  "numberOfSeries": 2,
  "numberOfInstances": 412,
  "endpoint": [{"reference": "Endpoint/pacs-dicomweb"}],
  "series": [{
    "uid": "1.2.840.113619.2.55.3.2831164356.781.1710415000.2",
    "number": 1,
    "modality": {"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT"},
    "bodySite": {"system": "http://snomed.info/sct", "code": "51185008", "display": "Thoracic structure"},
    "numberOfInstances": 410,
    "instance": [{
      "uid": "1.2.840.113619.2.55.3.2831164356.781.1710415000.3",
      "sopClass": {"system": "urn:ietf:rfc:3986", "code": "urn:oid:1.2.840.10008.5.1.4.1.1.2"},
      "number": 1
    }]
  }]
}

UID-ul Clasei SOP 1.2.840.10008.5.1.4.1.1.2 este CT Image Storage. Endpoint-ul arată așa:

{
  "resourceType": "Endpoint",
  "id": "pacs-dicomweb",
  "status": "active",
  "connectionType": {"system": "http://terminology.hl7.org/CodeSystem/endpoint-connection-type", "code": "dicom-wado-rs"},
  "payloadType": [{"text": "DICOM WADO-RS"}],
  "address": "https://pacs.example-hospital.org/dicomweb"
}

Un vizualizator construiește URL-ul de preluare din cele două: {Endpoint.address}/studies/{StudyInstanceUID}, apoi apelează WADO-RS pentru metadate și cadre.

Cine creează resursele ImagingStudy

Resursele ImagingStudy sunt de obicei create de o fațadă FHIR din fața PACS sau VNA, sau de un motor de integrare, atunci când un studiu este complet, adesea declanșat de mesajul HL7 v2 ORU sau DICOM MPPS. Unele arhive le generează din mers dintr-o interogare QIDO-RS. Scannerul în sine nu creează resurse ImagingStudy.

De obicei nu scanerul. O fațadă FHIR în fața PACS sau VNA, sau un motor de integrare, creează ImagingStudy atunci când studiul este complet (adesea declanșat de mesajul HL7 v2 ORU sau DICOM MPPS) și menține numberOfInstances sincronizat. Unele arhive generează ImagingStudy din mers dintr-o interogare QIDO-RS. Dacă proiectul dvs. le scrie manual, UID-urile trebuie să corespundă exact arhivei, caracter cu caracter, altfel vizualizatorul va afișa un studiu gol.

Greșeli care strică vizualizatoarele

Greșelile care strică vizualizatoarele care citesc un FHIR ImagingStudy sunt: plasarea UID-ului Studiului în id în loc de identifier, utilizarea unui cod de modalitate non-DICOM, indicarea unui Punct de acces (Endpoint) cu connectionType greșit către un server DICOMweb, lăsarea numărului de serii și instanțe neactualizată după modificarea imaginilor și așteptarea datelor pixelilor într-un FHIR Binary în loc de o arhivă DICOM.

Punerea UID-ului Studiului în id în loc de identifier; ID-urile FHIR sunt atribuite de server și nu pot fi OID-uri.
O modalitate din SNOMED sau o listă locală în loc de sistemul de coduri DICOM DCM.
Un Endpoint cu connectionType hl7-fhir-rest care indică un server DICOMweb, sau invers.
Numărarea seriilor și instanțelor o singură dată și niciodată actualizarea atunci când imaginile sunt adăugate sau șterse.
Așteptarea datelor pixel în FHIR Binary. Specificația FHIR în sine spune că imaginile aparțin DICOM, nu în Binary.

Într-un dosar Anpheros

Platforma Anpheros nu găzduiește date ImagingStudy sau DICOM. Constatările radiologice sosesc ca DiagnosticReport sau DocumentReference (raportul, cu codurile și textul său); acolo unde spitalul expune un link către un vizualizator, DocumentReference poate purta acest link ca URL de atașament. Imaginile rămân în arhiva spitalului sub regulile sale de acces.

Pagini conexe

Surse

Întrebări frecvente

Poate un server FHIR să stocheze imaginile în sine?

Tehnic, un Binary poate conține orice octeți, dar specificația FHIR recomandă împotriva acestui lucru pentru imagistică și niciun vizualizator nu funcționează în acest fel. Imaginile rămân într-o arhivă DICOM; FHIR indică spre ea.

Ce s-a schimbat în FHIR R5 pentru ImagingStudy?

R5 păstrează aceeași formă, curăță denumirile (de exemplu, procedure înlocuiește procedureReference și procedureCode) și aliniază gestionarea locației corpului. R4 rămâne versiunea pe care o folosesc majoritatea arhivelor și profilurilor naționale.

Cum se leagă raportul de imagini?

DiagnosticReport.imagingStudy face referire la ImagingStudy; DiagnosticReport.media poate purta imagini cheie ca resurse Media. ImagingStudy face referire la Endpoint pentru studiul complet.

Am nevoie de ImagingStudy dacă am deja DICOMweb?

Doar dacă alți consumatori FHIR trebuie să știe că studiul există, de exemplu o aplicație pentru pacienți, un plan de îngrijire sau un export de cercetare. Un vizualizator de radiologie singur poate funcționa pe QIDO-RS și WADO-RS.

Anpheros Daily

Î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 →

iPhone și Mac Android Deschide în browser →

Acest ghid este informativ și nu înlocuiește consultul medical. Pentru decizii despre sănătatea ta, vorbește cu medicul tău. În caz de urgență, sună la numărul de urgență local (112 în Europa).

Scris de

Echipa Anpheros

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 →