Saltar a contenido

DICOM / HL7 FHIR Interoperability Roadmap — EPPA

Interop is out of scope for v1 — but must be on the roadmap

EPPA v1 (research-use phase) does not implement DICOM or FHIR integrations. The non-claim in 01-intended-use-statement.md §8 is explicit: "EPPA is not interoperable with PACS / EHR systems in the research-use phase". This document defines the target architecture for EPPA's interoperability story, so that the v1 data model can avoid decisions that would later block FHIR/DICOM mapping.

1. Document identity

Field Value
Document title DICOM / HL7 FHIR Interoperability Roadmap — EPPA
Document ID EPPA-INTEROP-001
Version 0.1 (draft)
Status Draft — not approved
Effective date n/a
Owner LABIS UCA — Software lead (pending)
Linked documents 00-overview.md, 01-intended-use-statement.md, 11-iec-62304-lifecycle.md, 90-roadmap.md

2. Standards anchors

  • DICOM PS 3 — Digital Imaging and Communications in Medicine, in particular PS 3.3 (information object definitions), PS 3.4 (service class specifications), PS 3.10 (media storage and file format) and PS 3.20 (transformation of DICOM to/from HL7 standards).
  • HL7 FHIR R4 — the current normative release, with successor R5 (2023) for forward compatibility.
  • IHE PCC — Integrating the Healthcare Enterprise, Patient Care Coordination profiles.
  • IHE PaLM — Pathology and Laboratory Medicine profiles (some apply beyond pathology).
  • IHE Radiology — XDS-I.b, Mammography Acquisition Workflow, etc.
  • ISO/HL7 27931:2009 — HL7 v2.5 messaging (relevant in legacy integration).
  • WADO-RS / STOW-RS / QIDO-RS — DICOMweb services (PS 3.18).

3. Why DICOM might still be relevant despite the photographic nature

EPPA captures consumer-grade photographs of standing patients, not radiological images. Naively, DICOM does not apply. However:

  1. Many PACS and VNA systems accept non-radiology images via the Visible Light family of DICOM IODs:
    • VL Photographic Image IOD (PS 3.3 § A.32.4).
    • VL Photographic Image Storage SOP Class (UID 1.2.840.10008.5.1.4.1.1.77.1.4).
  2. The Modality Worklist flow allows EPPA to acquire orders from a hospital's RIS, eliminating the need for manual patient entry.
  3. Hospital VNA contracts often require all clinical images to be archived through DICOM, regardless of modality.

Therefore, while EPPA does not need to produce DICOM internally, an EPPA DICOM gateway is on the roadmap for hospital deployments.

4. DICOM integration scope (Phase 4 roadmap)

4.1 Storage SCP / SCU

EPPA acts as a Storage SCU pushing VL Photographic Images to a hospital PACS Storage SCP. Required IODs and SOP classes:

Direction SOP class UID
EPPA → PACS VL Photographic Image Storage 1.2.840.10008.5.1.4.1.1.77.1.4
EPPA → PACS Secondary Capture Image Storage (annotated views) 1.2.840.10008.5.1.4.1.1.7
EPPA → PACS Grayscale Softcopy Presentation State Storage (for marker overlays) 1.2.840.10008.5.1.4.1.1.11.1
EPPA → PACS Structured Report Storage (analysis result) 1.2.840.10008.5.1.4.1.1.88.11

4.2 Modality Worklist (MWL)

EPPA acts as an MWL SCU querying a RIS for scheduled procedure steps. The Worklist response provides:

  • Patient demographics (PatientName, PatientID, PatientBirthDate, PatientSex).
  • Accession number (AccessionNumber).
  • Scheduled procedure step ID.
  • Procedure code (clinic-specific).

EPPA's intake form is pre-filled from the MWL response, eliminating manual data entry — a meaningful patient-safety control (mitigating H6 in 12-iso-14971-risk.md).

4.3 Modality Performed Procedure Step (MPPS)

After capture, EPPA reports a Modality Performed Procedure Step to the RIS, closing the workflow loop. SOP class: 1.2.840.10008.3.1.2.3.3.

4.4 DICOMweb (PS 3.18)

For modern PACS, DICOMweb services are preferred over DIMSE:

  • STOW-RS — store over RESTful services (analog of C-STORE).
  • QIDO-RS — query (analog of C-FIND).
  • WADO-RS — retrieve (analog of C-GET / C-MOVE).

DICOMweb is the recommended target for any new integration; DIMSE is maintained for legacy PACS support only.

5. HL7 FHIR R4 resource set

The FHIR mapping is the load-bearing interop track. EPPA must produce and consume the following resources.

5.1 Resources EPPA produces (write or push)

FHIR R4 resource EPPA mapping Notes
Patient EPPA's Patient entity Patient.identifier carries the EPPA UUID; Patient.name and Patient.birthDate only when retrieved from RIS via MWL or set by the clinic
Practitioner EPPA's User (clinician) Linked to professional registration via Practitioner.qualification
Organization LABIS UCA / clinic Organization.identifier carries the institutional identifier
Observation (per measurement) Each numeric metric (segment angle, alignment offset) LOINC or SNOMED CT code in Observation.code; numeric value in Observation.valueQuantity
DiagnosticReport Per view (anterior, posterior, lateral-L, lateral-R) DiagnosticReport.result references the relevant Observations; DiagnosticReport.conclusion carries the qualitative classification with the non-device disclaimer header
ImagingStudy Per session One ImagingStudy per visit; one ImagingStudy.series per view; ImagingStudy.endpoint carries the WADO-RS URL when DICOM is in scope
Media Each photographic frame (when DICOM is out of scope) Media.type = photo; Media.content is a base64-encoded JPEG or an external URL
Bundle The complete export for one session Bundle.type = document for static reports or transaction for write operations
Consent Patient consent for processing Consent.scope = patient-privacy or research; references the controller and processor
AuditEvent EPPA audit log entries (Epic E3) Aligned with FHIR audit profile and IHE ATNA
Provenance Authorship of each marker / analysis Captures the responsible clinician and timestamp

5.2 Resources EPPA consumes (read or pull)

FHIR R4 resource Use case
Patient When a hospital EHR sends the patient context (FHIR $everything or a CDS Hooks invocation)
Practitioner To resolve the operating clinician from the hospital identity provider
Organization To resolve the deploying clinic / hospital
ServiceRequest When EPPA is invoked from an EHR's order-entry workflow (replaces an MWL flow with FHIR semantics)
Encounter To anchor an EPPA session to a clinical encounter
Schedule / Slot / Appointment If EPPA participates in scheduling

5.3 Terminology

Concept Code system
Postural measurements LOINC (where coded) — verify per measurement
Postural conditions (qualitative) SNOMED CT — body site + finding
Body site (left, right, midline) SNOMED CT body site axis
Method SNOMED CT or LOINC method axis
Reference range LOINC + units of measure (UCUM)

EPPA must publish its CodeSystem (for internal codes that do not yet have LOINC / SNOMED equivalents) and its ValueSet declarations as part of the FHIR conformance package.

5.4 Profiles

EPPA must publish a StructureDefinition per resource in the previous table, profiling FHIR R4 to:

  • Constrain cardinalities (e.g. Observation.code 1..1).
  • Bind value sets (e.g. Observation.code to the EPPA postural-metrics value set).
  • Add mustSupport flags on EPPA-specific elements.
  • Pin extensions for EPPA-only data (e.g. cm/px scale factor used in the computation).

The profiles are published on a Simplifier or comparable registry.

6. IHE profiles relevant to EPPA

Profile Domain EPPA relevance
XDS-I.b — Cross-Enterprise Document Sharing for Imaging Radiology Could be used to share EPPA reports across enterprises, treating the EPPA report as an XDS-I document
PCC — Patient Care Coordination Cross-domain Various profiles for cross-care-team data sharing
PaLM — Pathology and Laboratory Medicine Lab Tangentially relevant; the Observation/DiagnosticReport mapping borrows from PaLM patterns
ITI-41 — Provide and Register Document Set-b Cross-enterprise document sharing The mechanism by which an EPPA report becomes an XDS document
ATNA — Audit Trail and Node Authentication Security EPPA's audit log must align with ATNA when the hospital uses an ATNA repository
CT — Consistent Time Security EPPA clocks synchronised to a hospital NTP source (or RFC 5905)
EUA — Enterprise User Authentication Identity SAML or OIDC SSO with the hospital identity provider; EPPA acts as an EUA Authenticated Node

7. VNA (Vendor Neutral Archive) considerations

Hospital VNAs (e.g. Hyland Acuo, Mach7, Sectra Enterprise Imaging) act as the long-term archive for all imaging across modalities. Integration considerations:

  • DICOM-only intake — most VNAs accept DICOM only; EPPA's DICOM gateway is the entry point.
  • Metadata enrichment — VNAs index DICOM metadata heavily; EPPA must emit clean, consistent values for Modality (XC for external camera), Manufacturer, ManufacturerModelName, SoftwareVersions.
  • Tagless / pixel-only images are rejected — every emitted IOD must satisfy the SOP class' Type 1 attribute requirements.
  • Patient identity reconciliation — VNAs typically rely on the MPI (Master Patient Index) of the hospital; EPPA must accept and persist the hospital PatientID alongside its own UUID, with a clear precedence rule.

8. Architecture sketch (target state, Phase 4)

   ┌────────────────────────────────────────┐
   │  Hospital EHR / RIS                    │
   │  (Cerner / Epic / Orion / hospital-OS) │
   └───────────────────┬────────────────────┘
                       │ FHIR R4 (SMART on FHIR launch)
                       │ + DICOM Modality Worklist
                       ▼
   ┌────────────────────────────────────────┐
   │  EPPA Application                       │
   │  ─ FHIR client (Patient, Practitioner)  │
   │  ─ DICOM SCU/SCP gateway                │
   │  ─ Capture + analysis kernel             │
   └───────────────────┬────────────────────┘
                       │ DICOM Storage SCU + MPPS
                       │ FHIR write (Observation, DiagnosticReport, ImagingStudy)
                       ▼
   ┌────────────────────────────────────────┐
   │  Hospital PACS / VNA + FHIR server      │
   └────────────────────────────────────────┘

9. Avoidance items for v1 (so v1 does not block v3)

To preserve future interop, the v1 data model must:

  1. Use UUIDs as the primary identifier, never the patient's name or NID.
  2. Allow external_identifier columns on Patient, User, Organization for hospital-provided IDs.
  3. Store measurements in a long-table (measurement_type, value, unit) so each measurement is a single row that maps 1:1 to an Observation.
  4. Time-stamp every record in UTC with ISO 8601 strings; render to local time only at the presentation layer.
  5. Make the analysis output a content-addressable artefact (hash of the inputs + analysis-kernel version) so that re-running produces a stable result for DiagnosticReport.identifier.
  6. Embed the non-device disclaimer in the Bundle.text narrative, so that any FHIR consumer surfaces it.

10. Open questions

  1. Profile authority — Simplifier vs HL7 IG Publisher vs custom registry.
  2. Code system gap — many postural measurements lack LOINC codes; determine whether to request LOINC additions or publish an EPPA CodeSystem.
  3. MPI integration — required for any hospital deployment but out-of-scope for the clinic deployment.
  4. DICOMweb-first vs DIMSE-first — recommend DICOMweb-first with DIMSE fallback for legacy PACS.
  5. SMART on FHIR launch context — EHR-launched or standalone-launched.

References