FHIR × Imaging × LLM
Architektur-Skizze: Wie Medical Imaging über FHIR an klinische IT angebunden werden könnte — fünf illustrative Cases (CT, US, PET/CT, Spine, Agent). Rechenseite: SimpleITK/ITK (vereinfacht). Eine SDK-Anbindung (z. B. ImFusion) ist hier nicht umgesetzt.
Die Demo rechnet mit SimpleITK/ITK (vereinfachte OSS-Algorithmen). Workflow- und Modulnamen sind illustrative Referenzen — kein ImFusion SDK, keine 1:1-Workflow-Übereinstimmung.
Backend:FHIR (Dev): https://atolleehealth-dev.atollee.com/fhir
FHIR könnte klinische IT, LLMs und Medical Imaging verbinden — Metadaten und Workflow in FHIR, Voxel und Algorithmen in der Bildverarbeitung. Diese Demo illustriert die Idee, nicht einen produktiven Pfad.
- LLM / AgentSprache · Tool-Aufrufe · Orchestrierung
- FHIRPatient · ImagingStudy (UIDs) · Terminology · DiagnosticReport · Observation
- BildverarbeitungSimpleITK/ITK (Demo)
- BilddatenVoxel · Volumen · Vektoren · DICOM
Demo-Cases
Fünf interaktive Cases — dieselbe Architektur-Idee, unterschiedliche Modalitäten. Am besten mit Case 1 starten.
Einstieg — interaktiver Grundloop (≈ 1 Min.)
FHIR adressiert Bilddaten
Gedanke: klinische IDs und Series-Metadaten in FHIR — darunter Voxel aus DICOM; in der Demo vereinfacht mit SimpleITK/ITK (HU-Gewebe-Karte).
LLM nutzt FHIR als Tool-API
Der Agent liest FHIR-Metadaten per Tool-API; Voxel-Verarbeitung und Algorithmen laufen außerhalb von FHIR (hier: SimpleITK/ITK).
Modalität über FHIR-Metadaten
FHIR unterscheidet Modalitäten und Domänen — der Match wählt US-Pendants (Speckle-Reduktion auf Cine-Frames, PWD-Hüllkurve; OSS, nicht klinische Quantifizierung).
Multimodal über FHIR verknüpft
Attenuationskorrigiertes PET auf CT-Referenzraster — SUV- und Fusion-Darstellung als illustrative OSS-Demo; Ergebnis in DiagnosticReport/Observation.
Befund zurück in FHIR
Strukturierte Segmentierung könnte über Observation/DocumentReference an FHIR angebunden werden — hier nur geglättetes Label-Overlay (OSS), kein DICOM-SEG-Export.
Optional: FHIR-Landschaft & Ökosystem— Hintergrund, kein Kern der Demo
FHIR (Hintergrund)
Hintergrund: FHIR kann Studien, Befunde und Workflows strukturieren — DICOM und Voxel bleiben in der Bildverarbeitung. So ließe sich eine gemeinsame Metadaten-Schicht für KIS, PACS und KI skizzieren, ohne Pixel in FHIR zu speichern.
FHIR & Bildgebung
- `ImagingStudy` führt Study-/Series-/SOP-Instance-UIDs und `series.modality` — Metadaten in FHIR, Pixel über DICOMweb (WADO-RS) oder lokale DICOM-Pfade in der Demo.
- `DiagnosticReport` verknüpft den Befund mit der Studie (`imagingStudy` in FHIR R4; in manchen Server-Snapshots via `basedOn`). `Observation` kann Kennzahlen strukturieren — Voxel-Verarbeitung bleibt außerhalb von FHIR (illustrativ).
- ONC beschreibt HL7 FHIR-REST-Ressourcen als wiederverwendbare Bausteine für KI-gestützte Workflows — mit Vorgaben zu Sicherheit, Consent, Provenance und Audit. ONC ISP · AI for Interoperability
Agenten & diese Demo
- Diese Demo illustriert ein Orchestrierungsmuster: der Copilot ruft FHIR-Tools auf (ImagingStudy, Match, Bildverarbeitung) — ohne proprietäre Dateipfade.
- Das Model Context Protocol (MCP) kann über FHIR-Schnittstellen gelegt werden: Agenten nutzen Search/Read/Write — Autorisierung, Audit und Consent bleiben am FHIR-Backend. ONC ISP · MCP + FHIR
- In einigen US-Piloten nutzt agentic AI FHIR bereits für Prior Authorization (Da Vinci CRD/DTR/PAS) — andere Domäne, gleiches Orchestrierungsmuster. HL7 News · e-PA Lifecycle
Forschung (Kontext)
- MedGemma 27B Multimodal wurde u. a. mit strukturierten EHR-/FHIR-Daten trainiert (Google Research). In dieser Demo skizziert man Bildgebung über `ImagingStudy` und `DiagnosticReport` — Architektur-Kontext, kein MedGemma-Feature. Google Research · MedGemma
Interner FHIR-Benchmark (optional, nicht Kern der Demo)
Live-FHIR: atolleeHealth R6 (TypeScript). Auszug aus lokalem Prod-Benchmark 2026-07-07 — Prod (synthetisch, passes=3).
| Metrik | atolleeHealth R6 (TypeScript) | HAPI R4 (Java) · Community-Referenz-Server |
|---|---|---|
| read (p50) | 1.60 ms | 1.54 ms |
| metadata (p50) | 0.52 ms | 40.8 ms |
| POST / PUT (p50) | 3.1–3.9 ms | 5.0–5.3 ms |
| batch 100 (p50) | 301.9 ms | 457.5 ms |
| TX-Semantik (A1–A7) | 7/7 | 4/7 |
8/17 von 17 Metriken in diesem internen Benchmark-Szenario. Interner Benchmark-Auszug: FHIR R6 (atolleeHealth) vs. HAPI R4 (Community-Referenz) — unterschiedliche Versionen und Workloads; Latenz ist kontextabhängig. Kein allgemeiner Leistungsnachweis für Produktivsysteme.
FHIR-Ökosystem
Rund um DICOM und Bilddaten nutzt FHIR verschiedene Ressourcentypen — von Patient und Auftrag über Studien-Metadaten und Terminology (LOINC, SNOMED CT, ICD-10) bis zu Befund und Messwert. Sie könnten KIS, Agenten und Bildverarbeitung verbinden; die Voxel selbst bleiben in DICOM.
- Patientsubject von ImagingStudy & DiagnosticReport
- EncounterAmbulant/stationärer Kontext
- ConditionIndikation für Bildgebung
- PractitionerAnforderer / Auswerter
- ServiceRequestBildgebungsauftrag (Modalität, Body Site)
- TaskVerarbeitungsjob, Freigabe, Agent-Orchestrierung
- ImagingStudyStudy-/Series-/Instance-UIDs, Modalität, Instanzanzahl
- ImagingSelectionAuswahl von Instanzen/Regionen (R5+)
- DeviceModalitätsgerät, Software-Version
- EndpointDICOMweb / WADO-RS — Pixelabruf neben FHIR-Metadaten
- DocumentReferenceDICOM-SR, SEG-Referenz/Overlay, PDF-Befund
- DiagnosticReportimagingStudy-Referenz, conclusion, presentedForm
- ObservationHU, SUV, Längen, Doppler — mit coding wo möglich
- MediaFoto/Video (seltener für CT-Volumen)
- CodeSystemLOINC, SNOMED CT, ICD-10-GM, DICOM-Modalitäten
- ValueSetGültige Codes für Observation, Condition, Body Site
- ConceptMapMapping zwischen Kodiersystemen (z. B. DICOM ↔ SNOMED)
- $expandValueSet auflösen — welche Codes sind erlaubt?
- $validate-codeCode + System prüfen, bevor Observation/Report geschrieben wird
- ProvenanceModell, Verarbeitungsversion, Herkunft
- ConsentDarf die KI auf diese Studie zugreifen?
Terminology in der Demo: Der Demo-FHIR-Server (atolleeHealth R6 oder lokaler Speicher) kann CodeSystem, ValueSet und ConceptMap bereitstellen — z. B. LOINC, SNOMED CT, ICD-10-GM. Wo verfügbar: $expand und $validate-code vor dem Schreiben von Observation/DiagnosticReport mit coding/conclusionCode — nicht nur Freitext in conclusion.