Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

DICOM против FHIR: данные визуализации и клинические данные

DICOM содержит медицинские изображения, FHIR — клинические данные вокруг них: что покрывает каждый стандарт, как связаны ImagingStudy и DiagnosticReport, и что где хранить.

DICOM и FHIR не являются конкурентами: DICOM — это стандарт для медицинских изображений — пикселей и технических метаданных рентгеновского снимка, КТ или МРТ — в то время как HL7 FHIR — это стандарт для клинических данных, связанных с ними, таких как заказ, отчет рентгенолога, результаты и пациент, к которому они относятся. Типичный рабочий процесс обработки изображений использует оба стандарта: сканер и PACS работают с DICOM, а больничные и пациентские приложения работают с FHIR. Ресурсы FHIR указывают на исследование DICOM, а не копируют его. На этой странице объясняется, где начинается и заканчивается каждый стандарт, как они связаны, и что должен и не должен хранить бэкенд FHIR, такой как Anpheros.

Краткий ответ

	DICOM	HL7 FHIR R4
Что переносит	Изображения и их метаданные (модальность, часть тела, расстояние между срезами, устройство, UID)	Клинические данные: пациенты, заявки, отчеты, наблюдения, лекарства…
Типичный размер	Мегабайты до гигабайт на исследование	Килобайты на ресурс
Единица данных	Study → Series → Instance, идентифицируемые глобально уникальными UID	Ресурсы (Patient, ServiceRequest, ImagingStudy, DiagnosticReport…) со ссылками
Транспорт	Сетевые службы DIMSE (C-STORE, C-FIND, C-MOVE) и DICOMweb REST (QIDO-RS, WADO-RS, STOW-RS)	REST поверх HTTPS с JSON или XML
Хранится в	PACS или нейтральном архиве поставщика (VNA)	EHR, FHIR-сервер, платформа медицинских данных
Читается	Просмотрщики радиологии, модели ИИ для изображений, модальности	Клинические приложения, приложения для пациентов, аналитика, ИИ, работающий с текстом и значениями

Назначение DICOM

DICOM (Digital Imaging and Communications in Medicine) определяет, как кодируется изображение и как медицинское оборудование обменивается им. Каждый файл изображения содержит заголовок с сотнями атрибутов — идентификаторы пациента и исследования, модальность (CT, MR, DX, US…), параметры получения, пространственное разрешение пикселей — рядом с данными пикселей. Изображения группируются как экземпляры внутри серий внутри исследования, каждый с UID, таким как 2.25.181945…, чтобы одно и то же исследование можно было снова найти в любом архиве.

DICOMweb перенес DICOM в HTTP: QIDO-RS для поиска исследований, WADO-RS для их получения, STOW-RS для их хранения. Это делает изображения доступными из веб-просмотрщиков и облачных сервисов, но полезная нагрузка по-прежнему является DICOM.

Что DICOM не делает хорошо, так это клиническую историю: почему было назначено исследование, к какому выводу пришел рентгенолог, с какой проблемой оно связано и как оно соотносится с результатами лабораторных исследований и назначенными лекарствами. Это задача FHIR.

Что FHIR делает в области обработки изображений

FHIR R4 имеет ресурсы для каждого этапа рабочего процесса обработки изображений:

ServiceRequest — заказ: «Рентген грудной клетки, два вида, подозрение на пневмонию».
ImagingStudy — сводка исследования DICOM (UID, модальность, количество серий и экземпляров, локализация тела) и endpoint, указывающий, где можно получить изображения, например, адрес DICOMweb WADO-RS. Он не содержит пикселей.
DiagnosticReport — отчет рентгенолога: код, статус, заключение, время выдачи и, опционально, исходный отчет в формате PDF в presentedForm; imagingStudy связывает его с исследованием.
Observation — отдельные находки или измерения, которые должны быть доступны для запросов, например, размер узелка.
DocumentReference — документ, такой как отчет в формате PDF или ключевое изображение, экспортированное в формате JPEG.

ImagingStudy, указывающий на исследование в PACS (действительная структура FHIR R4):

{
  "resourceType": "ImagingStudy",
  "status": "available",
  "subject": {"reference": "Patient/example"},
  "identifier": [{"system": "urn:dicom:uid", "value": "urn:oid:2.25.181945102383749012843512396725468820"}],
  "started": "2026-10-03T10:20:00-05:00",
  "modality": [{"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "DX"}],
  "numberOfSeries": 1,
  "numberOfInstances": 2,
  "endpoint": [{"reference": "Endpoint/pacs-wado"}],
  "series": [{
    "uid": "2.25.30584718293846127394857102938475",
    "modality": {"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "DX"},
    "bodySite": {"system": "http://snomed.info/sct", "code": "51185008", "display": "Thoracic structure"},
    "numberOfInstances": 2,
    "instance": [{"uid": "2.25.11223344556677889900112233445566",
                  "sopClass": {"system": "urn:ietf:rfc:3986", "code": "urn:oid:1.2.840.10008.5.1.4.1.1.1.1"}}]
  }]
}

Отчет по тому же исследованию в виде DiagnosticReport (проходит валидатор FHIR R4):

{
  "resourceType": "DiagnosticReport",
  "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v2-0074", "code": "RAD", "display": "Radiology"}]}],
  "code": {"coding": [{"system": "http://loinc.org", "code": "36643-5", "display": "XR Chest 2 Views"}], "text": "Chest X-ray, 2 views"},
  "subject": {"reference": "Patient/example"},
  "effectiveDateTime": "2026-10-03T10:20:00-05:00",
  "issued": "2026-10-03T15:05:00-05:00",
  "performer": [{"display": "Springfield Imaging Center"}],
  "conclusion": "No acute cardiopulmonary abnormality.",
  "presentedForm": [{"contentType": "application/pdf", "url": "https://imaging.springfield-hospital.test/reports/RPT-8812.pdf", "title": "Radiology report"}]
}

Как они связаны

 modality (X-ray, CT, MR) ──DICOM──► PACS / VNA ◄──DICOMweb (WADO-RS)── image viewer, AI image model
                                         ▲
                     ImagingStudy.endpoint│ (where the images are)
                                         │
 order (ServiceRequest) ──► study ──► report (DiagnosticReport) ──► patient record (FHIR)
                                                                       │
                                     patient app, clinic system, AI assistant (text and values)

Правило, которое делает системы простыми: изображения остаются в архиве изображений; клиническая запись содержит отчет, важные результаты и указатель на изображения. Копирование DICOM-исследований в клиническую базу данных увеличивает объем хранения и риски конфиденциальности, не делая запись более полезной для большинства ее читателей.

Другие стандарты заполняют пробелы между больницами: профили IHE, такие как XDS-I для обмена медицинскими изображениями между организациями, и FHIRcast для синхронизации средства просмотра радиологических изображений и приложения для составления отчетов по одному и тому же пациенту и исследованию.

Обработка изображений, интероперабельность и ИИ

ИИ для медицинских изображений (обнаружение, сегментация, сортировка) работает с пиксельными данными DICOM, обычно в отделении радиологии или на специализированной платформе. ИИ, помогающий пациенту или врачу анализировать всю историю болезни — «что показал последний рентген грудной клетки и как это связано с кашлем и антибиотиками?» — работает с отчетом, результатами исследований и остальными клиническими данными, которые передаются через FHIR. Оба типа ИИ требуют от инфраструктуры одного и того же: данные с кодами, временными метками и зарегистрированным источником.

Место Anpheros в экосистеме

Anpheros хранит записи каждого пациента в формате HL7 FHIR R4. Для изображений это означает:

Хранится: радиологический отчет в виде DiagnosticReport, исходный отчет или ключевое изображение в виде DocumentReference (до 25 МиБ на документ), находки в виде Observation и направление в виде ServiceRequest. Каждая запись несет информацию о происхождении, и пациент решает, каким приложениям разрешить доступ к ней.
Не хранится: DICOM-исследования. Anpheros не является PACS, не имеет интерфейса DICOMweb и на данный момент не поддерживает ресурс ImagingStudy, поэтому не может индексировать или предоставлять изображения. Он не читает и не интерпретирует изображения.

В приложении Anpheros Daily пациент может сфотографировать или загрузить отчет об изображении и сохранить его в своих документах рядом с остальной частью своей записи. Для разработчика, создающего приложение или интеграцию клиники, практическое разделение заключается в следующем: храните изображения в вашей системе обработки изображений, а отчет и находки записывайте в FHIR-запись пациента. Как интегрировать клинические системы с бэкендом FHIR показывает, как записать визит и связанные с ним документы одной транзакцией, а Пример DiagnosticReport демонстрирует структуру отчета.

Часто задаваемые вопросы

В чем разница между DICOM и FHIR?

DICOM кодирует и обменивается медицинскими изображениями и их техническими метаданными; FHIR обменивается клиническими данными, такими как заказы, отчеты, наблюдения и медикаменты. На практике ресурсы FHIR описывают и ссылаются на радиологические исследования, в то время как сами изображения остаются в DICOM.

Может ли FHIR хранить медицинские изображения?

FHIR может передавать небольшие изображения в качестве вложений (ключевое изображение в DocumentReference или Media), но он не предназначен для полных диагностических исследований. Ресурс ImagingStudy описывает исследование DICOM и указывает, где его можно получить; пиксели остаются в PACS или архиве.

Что такое DICOMweb?

RESTful часть стандарта DICOM: QIDO-RS для поиска, WADO-RS для получения и STOW-RS для хранения исследований через HTTP. FHIR ImagingStudy может указывать на конечную точку DICOMweb.

Какой ресурс FHIR содержит радиологический отчет?

DiagnosticReport, с категорией радиологии, кодом LOINC для исследования, заключением и, при необходимости, исходным отчетом в виде PDF в presentedForm. Измерения, которые должны быть доступны для поиска, становятся отдельными Observations.

Поддерживает ли Anpheros DICOM?

Нет. Anpheros хранит клиническую сторону радиологии — отчеты, результаты, документы и заказы — в записи пациента FHIR R4. Он не хранит, не обслуживает и не интерпретирует изображения DICOM и на сегодняшний день не поддерживает ImagingStudy.

Связанные материалы

Взаимодействие медицинских данных: стандарты вокруг FHIR
Платформа FHIR: 26 типов ресурсов, которые хранит Anpheros
FHIR против пользовательской медицинской базы данных
API лабораторных результатов: тот же шаблон для лабораторных отчетов
Как интегрировать клинические системы с бэкендом FHIR

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card