# DICOM vs FHIR: obrazová a klinická data

> DICOM přenáší lékařské snímky, FHIR klinická data kolem nich: co každý pokrývá, jak se ImagingStudy a DiagnosticReport propojují a co kam ukládat.

Source: https://developers.anpheros.com/cs/guides/dicom-vs-fhir

**DICOM a FHIR nejsou konkurenti: DICOM je standard pro lékařské snímky — pixely a technická metadata rentgenu, CT nebo MRI — zatímco HL7 FHIR je standard pro klinická data kolem nich, jako je žádanka, zpráva radiologa, nálezy a pacient, ke kterému patří.** Typický obrazový pracovní postup používá oba: skener a PACS komunikují v DICOM, nemocniční a klientské aplikace komunikují ve FHIR a FHIR zdroje odkazují na DICOM studii, místo aby ji kopírovaly. Tato stránka vysvětluje, kde každý standard začíná a končí, jak se propojují a co by FHIR backend, jako je Anpheros, měl a neměl ukládat.

## Stručná odpověď

| | DICOM | HL7 FHIR R4 |
|---|---|---|
| Co přenáší | Obrázky a jejich metadata (modalita, část těla, rozestup řezů, zařízení, UID) | Klinická data: pacienti, objednávky, zprávy, pozorování, léky… |
| Typická velikost | Megabajty až gigabajty na studii | Kilobajty na zdroj |
| Jednotka dat | Studie → Série → Instance, identifikované globálně unikátními UID | Zdroje (Patient, ServiceRequest, ImagingStudy, DiagnosticReport…) s referencemi |
| Transport | Síťové služby DIMSE (C-STORE, C-FIND, C-MOVE) a DICOMweb REST (QIDO-RS, WADO-RS, STOW-RS) | REST přes HTTPS s JSON nebo XML |
| Uloženo v | PACS nebo vendor-neutral archive (VNA) | EHR, FHIR server, platforma pro zdravotní data |
| Čteno pomocí | Radiologické prohlížeče, AI modely pro obrazy, modality | Klinické aplikace, klientské aplikace, analytika, AI pracující s textem a hodnotami |

## K čemu slouží DICOM

DICOM (Digital Imaging and Communications in Medicine) definuje, jak je obraz kódován a jak si jej zobrazovací zařízení vyměňují. Každý obrazový soubor nese hlavičku se stovkami atributů — identifikátory pacienta a studie, modalita (`CT`, `MR`, `DX`, `US`…), parametry akvizice, rozlišení pixelů — vedle obrazových dat. Obrazy jsou seskupeny jako instance uvnitř sérií uvnitř studie, každá s UID jako `2.25.181945…`, takže stejnou studii lze znovu najít v jakémkoli archivu.

DICOMweb přinesl DICOM do HTTP: `QIDO-RS` pro vyhledávání studií, `WADO-RS` pro jejich načtení, `STOW-RS` pro jejich uložení. To zpřístupňuje obrazy z webových prohlížečů a cloudových služeb, ale datový obsah je stále DICOM.

Co DICOM nedělá dobře, je klinický příběh: proč byla studie nařízena, k čemu se radiolog dospěl, s jakým problémem souvisí a jak zapadá do laboratorních výsledků a medikace. To je práce FHIR.

## Co FHIR dělá v oblasti zobrazování

FHIR R4 má zdroje pro každý krok pracovního postupu zobrazování:

- **ServiceRequest** — objednávka: „RTG hrudníku, dva pohledy, podezření na zápal plic“.
- **ImagingStudy** — souhrn studie DICOM (UID, modalita, počet sérií a instancí, lokalizace těla) a `endpoint`, který říká, kde lze obrázky načíst, například adresa DICOMweb WADO-RS. Neobsahuje pixely.
- **DiagnosticReport** — zpráva radiologa: kód, stav, závěr, datum vydání a volitelně původní zpráva ve formátu PDF v `presentedForm`; `imagingStudy` ji propojuje se studií.
- **Observation** — jednotlivá zjištění nebo měření, která musí být dotazovatelná, například velikost uzlíku.
- **DocumentReference** — dokument, jako je zpráva ve formátu PDF nebo klíčový obrázek exportovaný jako JPEG.

ImagingStudy, který odkazuje na studii v PACS (platná struktura FHIR R4):

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

Zpráva o stejné studii jako DiagnosticReport (prochází [validátorem FHIR R4](https://developers.anpheros.com/tools/fhir-validator)):

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

## Jak se tyto dva systémy propojují

```
 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)
```

Pravidlo, které udržuje systémy jednoduché: **snímky zůstávají v archivu snímků; klinický záznam uchovává zprávu, důležitá zjištění a odkaz na snímky.** Kopírování studií DICOM do klinické databáze násobí rizika pro ukládání dat a ochranu soukromí, aniž by záznam byl užitečnější pro většinu jeho čtenářů.

Jiné standardy vyplňují mezery mezi nemocnicemi: profily IHE, jako je XDS-I pro sdílení obrazových dokumentů napříč organizacemi, a FHIRcast pro udržení radiologického prohlížeče a reportovací aplikace na stejném pacientovi a studii.

## Zobrazování, interoperabilita a AI

AI na lékařských snímcích (detekce, segmentace, třídění) pracuje s pixelovými daty DICOM, obvykle v rámci radiologického oddělení nebo specializované platformy. AI, která pomáhá pacientovi nebo lékaři zorientovat se v celém záznamu – „co ukázalo poslední rentgenové vyšetření hrudníku a jak souvisí s kašlem a antibiotiky?“ – pracuje s reportem, nálezy a zbytkem klinických dat, což je to, co přenáší FHIR. Oba typy AI potřebují od infrastruktury totéž: data s kódy, časy a zaznamenaným původem.

## Kam zapadá Anpheros

Anpheros ukládá záznam každého pacienta jako HL7 FHIR R4. Pro zobrazovací metody to znamená:

- **Uloženo:** radiologickou zprávu jako `DiagnosticReport`, původní zprávu nebo klíčový snímek jako `DocumentReference` (až 25 MiB na dokument), nálezy jako `Observation` a objednávku jako `ServiceRequest`. Každý zápis nese původ, a pacient rozhoduje, které aplikace si jej mohou přečíst.
- **Není uloženo:** studie DICOM. Anpheros není PACS, nemá rozhraní DICOMweb a dnes nepodporuje prostředek `ImagingStudy`, takže nemůže indexovat ani poskytovat obrázky. Nečte ani neinterpretuje obrázky.

V aplikaci Anpheros Daily může pacient vyfotografovat nebo nahrát zobrazovací zprávu a uchovávat ji ve svých dokumentech vedle zbytku svého záznamu. Pro vývojáře vytvářejícího aplikaci nebo klinickou integraci je praktické rozdělení následující: uchovávejte obrázky ve svém zobrazovacím systému, zprávu a nálezy zapisujte do FHIR záznamu pacienta. [Jak integrovat klinické systémy s backendem FHIR](https://developers.anpheros.com/cs/guides/integrate-clinic-systems-fhir) ukazuje, jak zapsat návštěvu a její dokumenty v jedné transakci, a [příklad DiagnosticReport](https://developers.anpheros.com/tools/fhir-examples/diagnostic-report) ukazuje strukturu zprávy.

## Často kladené dotazy

### Jaký je rozdíl mezi DICOM a FHIR?
DICOM kóduje a vyměňuje lékařské snímky a jejich technická metadata; FHIR vyměňuje klinická data, jako jsou objednávky, zprávy, pozorování a léky. V praxi zdroje FHIR popisují a odkazují na zobrazovací studie, zatímco samotné snímky zůstávají v DICOM.

### Může FHIR ukládat lékařské snímky?
FHIR může přenášet malé snímky jako přílohy (klíčový snímek v DocumentReference nebo Media), ale není navržen pro plnohodnotné diagnostické studie. Zdroj ImagingStudy popisuje studii DICOM a ukazuje, kde ji lze načíst; pixely zůstávají v PACS nebo archivu.

### Co je DICOMweb?
RESTful část standardu DICOM: QIDO-RS pro vyhledávání, WADO-RS pro načítání a STOW-RS pro ukládání studií přes HTTP. FHIR ImagingStudy může odkazovat na koncový bod DICOMweb.

### Který zdroj FHIR obsahuje radiologickou zprávu?
DiagnosticReport, s kategorií radiologie, kódem LOINC pro vyšetření, závěrem a v případě potřeby původní zprávou ve formátu PDF v `presentedForm`. Měření, která musí být prohledávatelná, se stávají samostatnými Observations.

### Podporuje Anpheros DICOM?
Ne. Anpheros ukládá klinickou část zobrazování – zprávy, nálezy, dokumenty a objednávky – v záznamu pacienta FHIR R4. Neukládá, neslouží ani neinterpretuje snímky DICOM a dnes nepodporuje ImagingStudy.

## Související

- [Interoperabilita zdravotnických dat](https://developers.anpheros.com/cs/guides/interoperability): standardy kolem FHIR
- [Platforma FHIR](https://developers.anpheros.com/cs/guides/fhir): 26 typů zdrojů, které Anpheros ukládá
- [FHIR vs. vlastní databáze lékařských záznamů](https://developers.anpheros.com/cs/guides/fhir-vs-custom-database)
- [API pro laboratorní výsledky](https://developers.anpheros.com/cs/guides/lab-results-api): stejný vzor pro laboratorní zprávy
- [Jak integrovat klinické systémy s backendem FHIR](https://developers.anpheros.com/cs/guides/integrate-clinic-systems-fhir)