Every imaging department depends on its connection to the electronic medical record. Orders arrive from it, results go back to it, and clinicians increasingly expect to see images without leaving it. Two standards carry most of that traffic, and they are better understood as partners than rivals.
HL7 v2: still doing the heavy lifting
HL7 version 2 messaging has run hospital integration for decades and still carries most real-time traffic between systems:
- ADT messages keep patient demographics and encounters in sync;
- ORM / OMG messages carry imaging orders from the EMR to the RIS and modality worklist;
- ORU messages return signed reports to the EMR.
HL7 v2 is event-driven and dependable, but every interface tends to be slightly different. An integration engine that maps, routes, queues and logs these messages is what keeps them manageable as the number of systems grows.
FHIR: the API layer
FHIR (Fast Healthcare Interoperability Resources) exposes clinical data as resources over a REST API with JSON. For imaging, the important ones are:
- ServiceRequest for the order;
- ImagingStudy to describe a study and point to where its images live, often a DICOMweb endpoint;
- DiagnosticReport for the radiology report.
FHIR is well suited to on-demand queries, patient-facing apps and new integrations. It does not replace HL7 v2 overnight; most organisations run both, with v2 for established real-time feeds and FHIR for new access patterns.
SMART on FHIR and launch in context
SMART on FHIR adds standard authorization (OAuth 2.0) and app launch on top of FHIR. A viewer or an AI result screen can launch from inside the EMR with the current patient and encounter already selected, and with the user's permissions applied. That removes the copy-and-search step that slows clinicians down and invites errors.
Information blocking
The 21st Century Cures Act and its information blocking rules mean that health IT developers, health information networks and providers cannot unreasonably interfere with access to, exchange of or use of electronic health information. Practically, that pushes organisations toward standards-based APIs and away from integrations that depend on one vendor's goodwill. Imaging results and reports are part of that picture; images themselves increasingly are too.
Designing integrations that last
- Keep one source of truth for patient identity and reconcile against it everywhere.
- Route through an integration engine instead of point-to-point connections.
- Log every message and API call with enough detail to trace a missing result in minutes.
- Test downtime and recovery: queued messages must replay in order when a system comes back.
Good integration is invisible to clinicians. They only notice it when it fails, which is the best argument for designing it carefully.