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-бекeнд, такий як Anpheros, повинен і не повинен зберігати.

Коротка відповідь

	DICOM	HL7 FHIR R4
Що переносить	Зображення та їх метадані (модальність, частина тіла, інтервал зрізів, пристрій, UIDs)	Клінічні дані: пацієнти, замовлення, звіти, спостереження, медикаменти…
Типовий розмір	Від мегабайтів до гігабайтів на дослідження	Кілобайти на ресурс
Одиниця даних	Study → Series → Instance, ідентифіковані глобально унікальними UIDs	Ресурси (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…), параметри отримання, просторовий інтервал пікселів — поруч із даними пікселів. Зображення групуються як екземпляри (instances) всередині серій (series) всередині дослідження (study), кожне з яких має UID, наприклад 2.25.181945…, щоб те саме дослідження можна було знайти знову в будь-якому архіві.

DICOMweb приніс DICOM в HTTP: QIDO-RS для пошуку досліджень, WADO-RS для їх отримання, STOW-RS для їх зберігання. Це робить зображення доступними з веб-переглядачів та хмарних сервісів, але корисне навантаження (payload) все ще є 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, з категорією "radiology", кодом 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