FHIR ImagingStudy a DICOMweb: co gdzie jest

Krótka odpowiedź: ImagingStudy to zasób FHIR, który informuje, że ten pacjent miał wykonane badanie CT w tym dniu, z tymi seriami i tymi identyfikatorami UID instancji, a obrazy znajdują się tam. DICOMweb to właśnie to tam: interfejs REST archiwum, które przechowuje piksele. FHIR zawiera opis i raport; DICOM zawiera obrazy. ImagingStudy odnosi się do zasobu Endpoint, którego connectionType to dicom-wado-rs, a przeglądarka łączy oba te elementy.

Co zawiera ImagingStudy

Zasób FHIR ImagingStudy zawiera metadane jednego badania obrazowego: identyfikator DICOM Study Instance UID, status, pacjenta Subject, wizytę, czas rozpoczęcia i zlecenie ServiceRequest, kody modalności z systemu kodowania DICOM DCM, liczbę serii i instancji, punkt końcowy Endpoint, gdzie znajdują się obrazy, oraz każdą serię z jej instancjami i identyfikatorami UID. Nie zawiera pikseli.

identifier: identyfikator Study Instance UID z DICOM, jako urn:oid:1.2.840… z systemem urn:dicom:uid;
status: zarejestrowany, dostępny, anulowany, błąd wprowadzania, nieznany;
subject: Pacjent; encounter, started, referrer, basedOn (ServiceRequest, który go zlecił);
modality: kody ze słownictwa DICOM (CT, MR, US, CR, DX…), system http://dicom.nema.org/resources/ontology/DCM;
numberOfSeries, numberOfInstances;
endpoint: gdzie pobrać obrazy;
series[]: każdy z identyfikatorem Series Instance UID, modalnością, lokalizacją ciała, instance[] z identyfikatorem SOP Instance UID i SOP Class UID.

Czego nie zawiera: danych pikselowych, ustawień okna, pełnego nagłówka DICOM ani tekstu raportu. Raport to DiagnosticReport z polem imagingStudy wskazującym z powrotem.

Poprawny przykład FHIR R4

Poprawny przykład FHIR R4 ImagingStudy zawiera identyfikator Study Instance UID z systemem urn:dicom:uid, status available, modalność CT z systemu kodowania DICOM DCM, pacjenta, czas rozpoczęcia, liczbę serii i instancji, odniesienie do punktu końcowego Endpoint o connectionType dicom-wado-rs oraz wpisy serii z ich identyfikatorami UID, lokalizacją ciała i identyfikatorem SOP Class UID.

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

Identyfikator SOP Class UID 1.2.840.10008.5.1.4.1.1.2 to CT Image Storage. Endpoint wygląda następująco:

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

Przeglądarka buduje adres URL pobierania z tych dwóch elementów: {Endpoint.address}/studies/{StudyInstanceUID}, a następnie wywołuje WADO-RS w celu uzyskania metadanych i ramek.

Kto tworzy zasoby ImagingStudy

Zasoby ImagingStudy są zazwyczaj tworzone przez fasadę FHIR przed PACS lub VNA, lub przez silnik integracyjny, gdy badanie jest zakończone, często wyzwalane przez komunikat HL7 v2 ORU lub DICOM MPPS. Niektóre archiwa generują je w locie na podstawie zapytania QIDO-RS. Sam skaner nie tworzy zasobów ImagingStudy.

Zazwyczaj nie skaner. Fasada FHIR przed PACS lub VNA, albo silnik integracyjny, tworzy ImagingStudy po zakończeniu badania (często wyzwalane przez komunikat HL7 v2 ORU lub DICOM MPPS) i synchronizuje numberOfInstances. Niektóre archiwa generują ImagingStudy na bieżąco na podstawie zapytania QIDO-RS. Jeśli Twój projekt tworzy je ręcznie, identyfikatory UID muszą dokładnie odpowiadać archiwum, znak po znaku, w przeciwnym razie przeglądarka wyświetli puste badanie.

Błędy, które psują przeglądarki

Błędy, które psują przeglądarki odczytujące FHIR ImagingStudy, to: umieszczanie Study UID w polu id zamiast identifier, używanie kodu modalności niezgodnego ze standardem DICOM, wskazywanie punktu końcowego Endpoint z niewłaściwym connectionType na serwer DICOMweb, pozostawianie liczby serii i instancji nieaktualnymi po zmianie obrazów oraz oczekiwanie danych pikselowych w zasobie FHIR Binary zamiast w archiwum DICOM.

Umieszczenie identyfikatora Study UID w id zamiast w identifier; identyfikatory FHIR są przypisywane przez serwer i nie mogą być OID.
Modalność z SNOMED lub lokalnej listy zamiast systemu kodów DICOM DCM.
Endpoint z connectionType hl7-fhir-rest wskazujący na serwer DICOMweb lub odwrotnie.
Zliczanie serii i instancji raz i nigdy nieaktualizowanie ich po dodaniu lub usunięciu obrazów.
Oczekiwanie danych pikselowych w FHIR Binary. Sama specyfikacja FHIR mówi, że obrazy należą do DICOM, a nie do Binary.

W rekordzie Anpheros

Platforma Anpheros nie przechowuje danych ImagingStudy ani DICOM. Wyniki radiologiczne docierają jako DiagnosticReport lub DocumentReference (raport, z jego kodami i tekstem); tam, gdzie szpital udostępnia link do przeglądarki, DocumentReference może zawierać go jako adres URL załącznika. Obrazy pozostają w archiwum szpitala zgodnie z jego zasadami dostępu.

Powiązane strony

Źródła

Najczęstsze pytania

Czy serwer FHIR może przechowywać same obrazy?

Technicznie rzecz biorąc, Binary może przechowywać dowolne bajty, ale specyfikacja FHIR odradza to w przypadku obrazowania, a żadna przeglądarka tak nie działa. Obrazy pozostają w archiwum DICOM; FHIR do niego wskazuje.

Co się zmieniło w FHIR R5 dla ImagingStudy?

R5 zachowuje ten sam kształt, porządkuje nazewnictwo (na przykład procedure zastępuje procedureReference i procedureCode) i dostosowuje obsługę lokalizacji ciała. R4 pozostaje wersją używaną przez większość archiwów i profili krajowych.

Jak raport łączy się z obrazami?

DiagnosticReport.imagingStudy odnosi się do ImagingStudy; DiagnosticReport.media może zawierać kluczowe obrazy jako zasoby Media. ImagingStudy odnosi się do Endpoint dla pełnego badania.

Czy potrzebuję ImagingStudy, jeśli mam już DICOMweb?

Tylko jeśli inni konsumenci FHIR muszą wiedzieć, że badanie istnieje, na przykład aplikacja pacjenta, plan opieki lub eksport badawczy. Sama przeglądarka radiologiczna może działać na QIDO-RS i WADO-RS.

Anpheros Daily

Wypróbuj w Anpheros Daily

Przechowuj wyniki badań obrazowych i laboratoryjnych w jednym miejscu w Anpheros Daily, gotowe do okazania podczas następnej wizyty.

Jak to działa w aplikacji →

iPhone i Mac Android Otwórz w przeglądarce →

Ten poradnik ma charakter informacyjny i nie zastępuje konsultacji lekarskiej. Decyzje dotyczące zdrowia podejmuj z lekarzem. W nagłym wypadku zadzwoń pod lokalny numer alarmowy (112 w Europie).

Napisane przez

Zespół Anpheros

Anpheros tworzy dokumentację medyczną, nad którą pacjent ma kontrolę i którą może udostępniać dowolnej klinice, na platformie HL7 FHIR R4, z siedzibą w UE. Te przewodniki pomogą Ci zrozumieć i uporządkować informacje o Twoim zdrowiu; nie zastępują one wizyty u lekarza.

O Anpheros →