FHIR ImagingStudy проти DICOMweb: що де зберігається

Коротка відповідь: ImagingStudy — це ресурс FHIR, який повідомляє: цей пацієнт пройшов КТ у таку дату, з такими серіями та такими UID серій, а зображення знаходяться там. DICOMweb — це «там»: REST-інтерфейс архіву, який зберігає пікселі. FHIR містить опис та звіт; DICOM містить зображення. ImagingStudy посилається на ресурс Endpoint, connectionType якого — dicom-wado-rs, а переглядач поєднує обидва.

Що містить ImagingStudy

Ресурс FHIR ImagingStudy містить метадані одного дослідження зображень: DICOM Study Instance UID як ідентифікатор, статус, пацієнта Subject, зустріч (encounter), час початку та ServiceRequest, коди модальності з словника DICOM DCM, кількість серій та екземплярів, Endpoint, де зберігаються зображення, а також кожну серію з її екземплярами та UID. Він не містить пікселів.

identifier: UID дослідження DICOM, як urn:oid:1.2.840… із системою urn:dicom:uid;
status: registered, available, cancelled, entered-in-error, unknown;
subject: Пацієнт; encounter, started, referrer, basedOn (ServiceRequest, який його замовив);
modality: коди зі словника DICOM (CT, MR, US, CR, DX…), система http://dicom.nema.org/resources/ontology/DCM;
numberOfSeries, numberOfInstances;
endpoint: де отримати зображення;
series[]: кожен із UID серії, модальністю, ділянкою тіла, instance[] з UID екземпляра SOP та UID класу SOP.

Чого він не містить: піксельні дані, налаштування вікна, повний заголовок DICOM або текст звіту. Звіт — це DiagnosticReport з посиланням imagingStudy назад.

Приклад коректного прикладу FHIR R4

Валідний приклад FHIR R4 ImagingStudy містить Study Instance UID як ідентифікатор із системою urn:dicom:uid, статус available, модальність CT із кодової системи DICOM DCM, пацієнта, час початку, кількість серій та екземплярів, посилання на Endpoint із connectionType dicom-wado-rs та записи серій з їхніми UID, локалізацією тіла та 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
    }]
  }]
}

UID класу SOP 1.2.840.10008.5.1.4.1.1.2 — це CT Image Storage. Endpoint виглядає так:

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

Переглядач створює URL для отримання з двох: {Endpoint.address}/studies/{StudyInstanceUID}, а потім викликає WADO-RS для метаданих та кадрів.

Хто створює ресурси ImagingStudy

Ресурси ImagingStudy зазвичай створюються FHIR фасадом перед PACS або VNA, або інтеграційним рушієм, коли дослідження завершено, часто запускається повідомленням HL7 v2 ORU або DICOM MPPS. Деякі архіви генерують їх на льоту за запитом QIDO-RS. Сам сканер не створює ресурси ImagingStudy.

Зазвичай не сканер. FHIR-фасад перед PACS або VNA, або інтеграційний рушій, створює ImagingStudy після завершення дослідження (часто запускається повідомленням HL7 v2 ORU або DICOM MPPS) і підтримує numberOfInstances в актуальному стані. Деякі архіви генерують ImagingStudy на льоту з запиту QIDO-RS. Якщо ваш проєкт пише їх вручну, UID повинні точно відповідати архіву, символ за символом, інакше переглядач покаже порожнє дослідження.

Помилки, які ламають переглядачі

Помилки, які ламають переглядачі, що читають FHIR ImagingStudy: розміщення Study UID в id замість identifier, використання коду модальності, що не є DICOM, вказівка на Endpoint з неправильним connectionType на DICOMweb сервер, залишення кількості серій та екземплярів застарілими після зміни зображень, а також очікування піксельних даних у FHIR Binary замість архіву DICOM.

Розміщення UID дослідження в id замість identifier; FHIR id призначаються сервером і не можуть бути OID.
Модальність зі SNOMED або локального списку замість кодової системи DICOM DCM.
Endpoint з connectionType hl7-fhir-rest, що вказує на сервер DICOMweb, або навпаки.
Підрахунок серій та екземплярів один раз і ніколи не оновлюється при додаванні або видаленні зображень.
Очікування піксельних даних у FHIR Binary. Сама специфікація FHIR говорить, що зображення належать DICOM, а не Binary.

У записі Anpheros

Anpheros Platform не розміщує дані ImagingStudy або DICOM. Радіологічні висновки надходять як DiagnosticReport або DocumentReference (звіт з його кодами та текстом); там, де лікарня надає посилання на переглядач, DocumentReference може містити його як URL вкладення. Зображення залишаються в архіві лікарні згідно з її правилами доступу.

Пов'язані сторінки

Джерела

Поширені запитання

Чи може FHIR-сервер зберігати самі зображення?

Технічно Binary може містити будь-які байти, але специфікація FHIR не рекомендує цього для зображень, і жоден переглядач так не працює. Зображення залишаються в архіві DICOM; FHIR вказує на нього.

Що змінилося у FHIR R5 для ImagingStudy?

R5 зберігає ту саму структуру, впорядковує іменування (наприклад, procedure замінює procedureReference та procedureCode) та узгоджує обробку ділянок тіла. R4 залишається версією, яку використовують більшість архівів та національних профілів.

Як звіт пов'язаний із зображеннями?

DiagnosticReport.imagingStudy посилається на ImagingStudy; DiagnosticReport.media може містити ключові зображення як ресурси Media. ImagingStudy посилається на Endpoint для повного дослідження.

Чи потрібен мені ImagingStudy, якщо я вже маю DICOMweb?

Тільки якщо інші споживачі FHIR повинні знати про існування дослідження, наприклад, додаток для пацієнта, план догляду або експорт для досліджень. Сам по собі радіологічний переглядач може працювати на QIDO-RS та WADO-RS.

Anpheros Daily

Спробуйте в Anpheros Daily

Зберігайте звіти про сканування та аналізи в одному місці в Anpheros Daily, готові показати на наступному прийомі.

Як це працює в додатку →

iPhone та Mac Android Відкрити у вашому браузері →

Цей посібник призначений для інформаційних цілей і не замінює медичну консультацію. Для прийняття рішень щодо вашого здоров'я зверніться до лікаря. У надзвичайній ситуації телефонуйте на місцевий номер екстреної допомоги (112 у Європі).

Написано

Команда Anpheros

Anpheros створює медичну карту, яку пацієнт контролює та може ділитися з будь-якою клінікою, на платформі HL7 FHIR R4, розташованій в ЄС. Ці посібники допоможуть вам зрозуміти та організувати своє здоров'я; вони не замінюють вашого лікаря.

Про Anpheros →