FHIR ImagingStudy против DICOMweb: что где хранится

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

Что содержит ImagingStudy

FHIR-ресурс ImagingStudy содержит метаданные одного исследования изображений: DICOM Study Instance UID в качестве идентификатора, статус, пациента Subject, встречу, время начала и запрашивающую 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 →