FHIR ImagingStudy vs DICOMweb: mi mit tartalmaz

Rövid válasz: Az ImagingStudy egy FHIR erőforrás, amely azt mondja el, hogy ez a páciens ezen a dátumon CT-vizsgálaton esett át, ezekkel a sorozatokkal és ezekkel az instance UID-kkal, és a képek ott vannak. A DICOMweb az ott: az archív REST interfésze, amely a pixeleket tárolja. Az FHIR tartalmazza a leírást és a jelentést; a DICOM pedig a képeket. Az ImagingStudy egy Endpoint erőforrásra hivatkozik, amelynek connectionType értéke dicom-wado-rs, és egy megjelenítő (viewer) a kettőt összekapcsolja.

Mit tartalmaz az ImagingStudy

A FHIR ImagingStudy erőforrás tartalmazza egy képalkotó vizsgálat metaadatait: a DICOM Study Instance UID azonosítóként, egy státusz, a vizsgált {placeholder:Patient}, a vizit, a kezdő időpont és a rendelő {placeholder:ServiceRequest}, a DICOM DCM szókincsből származó modalitási kódok, a sorozatok és példányok száma, az {placeholder:Endpoint}, ahol a képek találhatók, valamint minden sorozat a példányaival és UID-jaival. Nem tartalmaz képpontokat.

identifier: a DICOM Study Instance UID, mint urn:oid:1.2.840… a urn:dicom:uid rendszerrel;
status: registered, available, cancelled, entered-in-error, unknown;
subject: a páciens; encounter, started, referrer, basedOn (a ServiceRequest, amely megrendelte);
modality: kódok a DICOM saját szókincséből (CT, MR, US, CR, DX…), rendszer http://dicom.nema.org/resources/ontology/DCM;
numberOfSeries, numberOfInstances;
endpoint: hol lehet lekérni a képeket;
series[]: mindegyik a Series Instance UID-jával, modalitásával, testrészével, instance[] a SOP Instance UID-jával és SOP Class UID-jával.

Amit nem tartalmaz: pixeladatok, ablakbeállítások, a teljes DICOM fejléc, vagy a jelentés szövege. A jelentés egy DiagnosticReport, amely visszahivatkozik az imagingStudy-ra.

Érvényes FHIR R4 példa

Egy érvényes FHIR R4 ImagingStudy példány tartalmazza a Study Instance UID-t azonosítóként, urn:dicom:uid rendszerrel, elérhető státusszal, CT modalitással a DICOM DCM kódtárból, a beteget, a kezdő időpontot, a sorozatok és példányok számát, egy {placeholder:Endpoint} hivatkozást dicom-wado-rs kapcsolattípussal, valamint sorozatbejegyzéseket UID-jaikkal, testtájjal és SOP Class UID-val.

{
  "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
    }]
  }]
}

A 1.2.840.10008.5.1.4.1.1.2 SOP Class UID a CT Image Storage. Az Endpoint így néz ki:

{
  "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"
}

Egy megjelenítő (viewer) a két információból építi fel a lekérdezési URL-t: {Endpoint.address}/studies/{StudyInstanceUID}, majd meghívja a WADO-RS interfészt a metaadatokért és a képkockákért.

Kik hozzák létre az ImagingStudy erőforrásokat

Az ImagingStudy erőforrásokat általában egy FHIR homlokzat hozza létre a PACS vagy VNA előtt, vagy egy integrációs motor, amikor egy vizsgálat befejeződik, gyakran az HL7 v2 ORU vagy a DICOM MPPS üzenet váltja ki. Néhány archívum ezeket menet közben hozza létre egy QIDO-RS lekérdezés alapján. Maga a szkenner nem hoz létre ImagingStudy erőforrásokat.

Általában nem a szkenner. A PACS vagy VNA előtti FHIR facade, vagy egy integrációs motor hozza létre az ImagingStudy-t, amikor a vizsgálat befejeződött (gyakran az HL7 v2 ORU vagy a DICOM MPPS üzenet indítja el), és szinkronban tartja a numberOfInstances értékét. Néhány archívum az ImagingStudy-t on-the-fly generálja egy QIDO-RS lekérdezésből. Ha a projektje kézzel írja ezeket, az UID-knak pontosan meg kell egyezniük az archívummal, karakterről karakterre, különben a megjelenítő üres vizsgálatot fog mutatni.

Hibák, amelyek tönkreteszik a megjelenítőket

Azok a hibák, amelyek tönkreteszik a FHIR ImagingStudy-t olvasó megjelenítőket: a Study UID azonosítóként való elhelyezése az id helyett, nem DICOM modalitási kód használata, egy {placeholder:Endpoint} hibás kapcsolattípussal DICOMweb szerverre mutatása, a sorozatok és példányok számának elavulttá válása a képek változása után, valamint képpontadatok várakozása FHIR Binary helyett DICOM archívumban.

A Study UID id helyett az identifier-be kerül; a FHIR id-kat a szerver rendeli hozzá, és nem lehetnek OID-k.
A modalitás SNOMED vagy egy helyi lista eleme a DICOM DCM kódtár helyett.
Egy Endpoint connectionType értéke hl7-fhir-rest, amely egy DICOMweb szerverre mutat, vagy fordítva.
A sorozatok és példányok egyszeri megszámolása, és soha nem történő frissítése, amikor képeket adnak hozzá vagy törölnek.
A pixeladatok várt elhelyezése a FHIR Binary erőforrásban. Maga a FHIR specifikáció mondja, hogy a képek a DICOM-ban vannak, nem a Binary-ben.

Anpheros rekordban

Az Anpheros Platform nem tárol ImagingStudy vagy DICOM adatokat. A radiológiai leletek DiagnosticReport vagy DocumentReference (a jelentés, kódjaival és szövegével) formájában érkeznek; ahol a kórház megjelenítő linket biztosít, a DocumentReference azt melléklet URL-ként tartalmazhatja. A képek a kórház archívumában maradnak, annak hozzáférési szabályai szerint.

Kapcsolódó oldalak

Források

Gyakori kérdések

Tárolhat-e egy FHIR szerver magukat a képeket?

Technikailag egy Binary bármilyen bájtot tartalmazhat, de a FHIR specifikáció nem javasolja ezt képalkotás esetén, és egyetlen megjelenítő sem működik így. A képek egy DICOM archívumban maradnak; az FHIR csak hivatkozik rájuk.

Mi változott az R5-ös FHIR verzióban az ImagingStudy-nál?

Az R5 megtartja az ugyanazt a struktúrát, rendszerezi az elnevezéseket (például a procedure váltja fel a procedureReference és procedureCode elemeket), és összehangolja a testrész kezelését. Az R4 továbbra is az a verzió, amelyet a legtöbb archívum és nemzeti profil használ.

Hogyan kapcsolódik a jelentés a képekhez?

A DiagnosticReport.imagingStudy az ImagingStudy-ra hivatkozik; a DiagnosticReport.media kulcsfontosságú képeket tartalmazhat Media erőforrásokként. Az ImagingStudy az Endpoint-ra hivatkozik a teljes vizsgálathoz.

Szükségem van az ImagingStudy-ra, ha már rendelkezem DICOMweb-bel?

Csak akkor, ha más FHIR fogyasztóknak tudniuk kell a vizsgálat létezéséről, például egy páciens alkalmazásnak, egy gondozási tervnek vagy egy kutatási exportnak. Egy radiológiai megjelenítő önmagában is működhet QIDO-RS és WADO-RS segítségével.

Anpheros Daily

Próbáld ki az Anpheros Daily-ben

Tartsd a vizsgálati és lelet-jelentéseidet egy helyen az Anpheros Daily-ben, készen arra, hogy megmutasd a következő látogatásod alkalmával.

Hogyan működik az alkalmazásban →

iPhone és Mac Android Nyisd meg a böngésződben →

Ez az útmutató tájékoztató jellegű, és nem helyettesíti az orvosi tanácsot. Az egészségeddel kapcsolatos döntésekhez beszélj az orvosoddal. Vészhelyzetben hívja a helyi segélyhívó számot (Európában 112).

Szerző:

Az Anpheros csapata

Az Anpheros egy olyan egészségügyi nyilvántartást épít, amelyet a beteg irányít, és megoszthat bármelyik klinikával, egy EU-ban működő HL7 FHIR R4 platformon. Ezek az útmutatók segítenek megérteni és rendszerezni az egészségügyi adataidat; nem helyettesítik az orvosodat.

Tudj meg többet az Anpherosról →