Healthcare Standards

The ecosystem around medical imaging — from hospital data exchange protocols to web-native DICOM services. These standards work together so that a scan taken on any device can be stored, queried, retrieved, and reported on by any system, anywhere.

HL7
Health Level Seven

Health Level Seven Internationalis the global authority that publishes standards for the exchange, integration, sharing, and retrieval of electronic health information. "Level Seven" refers to the seventh (application) layer of the ISO OSI model.

1987
Founded
55+
Countries
500M+
Daily v2 messages

Version History

HL7 v2.x1987–present

Pipe-delimited text messages. Still dominant — over 95 % of US healthcare messages use v2. Segments like MSH, PID, OBR carry patient and order data.

MSH|^~\&|LAB|HOSP|HIS|HOSP|20240101120000||ORU^R01|MSG001|P|2.5
PID|||12345^^^HOSP^MR||Gupta^Sahil||19900115|M
HL7 v3 / CDA2005–2015

XML-based, fully modelled using RIM (Reference Information Model). Clinical Document Architecture (CDA) is its most used artefact — discharge summaries, referral letters.

<ClinicalDocument xmlns="urn:hl7-org:v3">
  <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
  <title>Discharge Summary</title>
  ...
</ClinicalDocument>
HL7 FHIR R42019–present

RESTful JSON/XML resources. Designed for modern web APIs. Supersedes v3 complexity with 150+ resource types accessible via HTTP.

GET /Patient/12345 HTTP/1.1
Host: fhir.hospital.org
Accept: application/fhir+json

→ { "resourceType": "Patient", "id": "12345", ... }

Key Message Types (v2)

TypePurposeCommon event
ADTAdmit / Discharge / TransferA01 (admit), A08 (update), A03 (discharge)
ORM / OMLOrder MessageO01 (new order) — labs, radiology, pharmacy
ORUObservation Result (Unsolicited)R01 — lab results, report text back to ordering system
MDMMedical Document ManagementT02 — signed radiology reports
SIUScheduling Information UnsolicitedS12 / S13 — appointment booked / cancelled
DFTDetail Financial TransactionP03 — charge posting
MFNMaster File NotificationM02 — staff master file update
FHIR
Fast Healthcare Interoperability Resources

FHIR(Fast Healthcare Interoperability Resources, pronounced "fire") is HL7's modern web standard, published in 2012 and now on Release 4 (R4). It models healthcare data as resources — JSON or XML documents accessible via a RESTful HTTP API, making it usable directly from web apps and mobile devices.

Core REST Operations

HTTPFHIR operationExample
GETread / searchGET /Patient/123 | GET /Patient?name=gupta
POSTcreatePOST /Patient (body = new Patient resource)
PUTupdate (full)PUT /Patient/123 (body = updated resource)
PATCHupdate (partial)PATCH /Patient/123 (body = JSON Patch)
DELETEdeleteDELETE /Patient/123
GEThistoryGET /Patient/123/_history

Key Resources (imaging-relevant)

PatientDemographics and administrative information about a person receiving care.
ObservationMeasurements and simple assertions (labs, vitals, imaging findings).
ImagingStudyRepresentation of a DICOM study and its series/instances in FHIR.
DiagnosticReportFindings and interpretation of diagnostic investigations (radiology reports).
PractitionerA person who is directly or indirectly involved in the provisioning of healthcare.
EncounterAn interaction between a patient and healthcare provider(s).
ConditionA clinical condition, problem, diagnosis, or other event relevant to the patient.
MedicationRequestAn order for both supply of a medication and the instructions for administration.
ServiceRequestA request for a procedure, imaging study, laboratory test, or referral.
EndpointTechnical details of a location that can be connected to for delivery of services (e.g. DICOM endpoint).

SMART on FHIR

SMART (Substitutable Medical Applications, Reusable Technologies) layered on FHIR provides an OAuth 2.0-based authorization framework so third-party apps can launch inside an EHR (Epic, Cerner) with a scoped token — e.g. a radiology viewer launching from within the patient chart.

# SMART launch sequence (EHR-launch)
1. EHR opens app with ?iss=https://ehr.hospital.org/fhir&launch=abc123
2. App fetches /.well-known/smart-configuration  → auth/token endpoints
3. App redirects to authorization endpoint with scope="launch patient/*.read"
4. EHR returns authorization_code
5. App exchanges code for access_token + patient context (patient ID)
6. App calls GET /Patient/{id} with Bearer token
PACS
Picture Archiving and Communication System

A PACS is the central nervous system of medical imaging in a hospital. It stores every scan taken on every modality, enables radiologists to read studies on high-resolution workstations, and distributes images to clinicians anywhere in the network. Modern PACS expose DICOMweb APIs and FHIR endpoints alongside the traditional binary DICOM services.

Architecture Components

📡
Acquisition Gateway
Receives images from modalities (CT, MR, US) via DICOM C-STORE and forwards them into the archive.
🗄️
Archive / Storage
Long-term storage of DICOM files. May use tiered storage: NVMe for recent studies, tape/object-store for older ones.
🖥️
DICOM Server
Answers DICOM queries (C-FIND), retrievals (C-MOVE/C-GET), and stores (C-STORE). Core of PACS interoperability.
📋
Worklist Broker
Provides Modality Worklist (MWL) to scanners so patients don't need to be re-entered at the modality.
🖱️
Diagnostic Workstation
High-resolution monitors + viewer software (e.g. OsiriX, Horos, Sectra). Radiologists read studies here.
🌐
Web Viewer
Zero-footprint HTML5 viewer (OHIF, Cornerstone) served via DICOMweb (WADO-RS, QIDO-RS, STOW-RS).
🔗
HL7 / FHIR Interface
Bridges PACS with HIS/RIS: receives orders via HL7, sends reports back, exposes FHIR ImagingStudy resources.
📑
RIS Integration
Radiology Information System tracks scheduling, billing, and reporting. PACS and RIS are tightly coupled.

Traditional DICOM Services (DIMSE)

ServiceDirectionPurpose
C-STORESCU → SCPPush DICOM instances to the PACS archive
C-FINDSCU → SCPQuery the archive for studies/series/instances
C-MOVESCU → SCPAsk PACS to push instances to a third AE
C-GETSCU → SCPRetrieve instances directly back to the caller
C-ECHOSCU → SCPConnectivity test (DICOM ping)
N-ACTION (MPPS)Modality → PACSNotify PACS that a procedure step started/completed
MWL C-FINDModality → Worklist SCPFetch scheduled procedure steps from RIS/HIS

Application Entity (AE) Titles

Every DICOM device is identified by an AE Title — up to 16 uppercase ASCII characters (e.g. PACS_ARCHIVE, CT_SCANNER_1). Both SCU (Service Class User, the caller) and SCP (Service Class Provider, the server) must know each other's AE title, IP address, and port to establish an association.

# Example DICOM association negotiation
SCU: VIEWER_WS  →  SCP: PACS_ARCHIVE  (host: 10.0.1.50, port: 104)

A-ASSOCIATE-RQ
  Calling AE Title: VIEWER_WS
  Called AE Title:  PACS_ARCHIVE
  Presentation Contexts:
    CT Image Storage  (1.2.840.10008.5.1.4.1.1.2)
    Explicit Little Endian Transfer Syntax

A-ASSOCIATE-AC  ← accepted
QIDO-RS
QIDO-RS — Query
GETQuery based on ID for DICOM Objects — RESTful ServicesDICOM PS 3.18

Search for studies, series, and instances without retrieving pixel data. Returns JSON metadata.

Endpoints

PathDescription
/studiesSearch for studies matching query params
/studies/{StudyUID}/seriesSearch for series within a study
/studies/{StudyUID}/series/{SeriesUID}/instancesSearch for instances within a series

Example

GET /wado/rs/studies?PatientName=Gupta*&ModalitiesInStudy=CT
Accept: application/dicom+json

→ HTTP 200
[
  {
    "0020000D": { "vr": "UI", "Value": ["1.2.3.4.5.6"] },
    "00080020": { "vr": "DA", "Value": ["20240101"] },
    "00080060": { "vr": "CS", "Value": ["CT"] }
  }
]

Key Parameters / Headers

PatientNameSupports wildcards (*)
PatientIDExact match
StudyDateRange: 20240101-20240201
ModalitiesInStudyCT, MR, US, etc.
AccessionNumberRIS accession
limit / offsetPagination
WADO-RS
WADO-RS — Retrieve
GETWeb Access to DICOM Objects — RESTful ServicesDICOM PS 3.18

Retrieve studies, series, instances, frames, or metadata. Supports bulk data retrieval and thumbnail generation.

Endpoints

PathDescription
/studies/{StudyUID}Retrieve all instances in a study (multipart)
/studies/{StudyUID}/series/{SeriesUID}Retrieve all instances in a series
/studies/{StudyUID}/series/{SeriesUID}/instances/{SOPInstanceUID}Retrieve a single instance
…/instances/{SOPInstanceUID}/frames/{FrameList}Retrieve specific frames
…/instances/{SOPInstanceUID}/metadataRetrieve metadata only (no pixel data)
…/instances/{SOPInstanceUID}/thumbnailRetrieve a JPEG thumbnail

Example

GET /wado/rs/studies/1.2.3/series/1.2.3.4/instances/1.2.3.4.5
Accept: application/dicom

→ HTTP 200
Content-Type: multipart/related; type="application/dicom"
[Binary DICOM file bytes]

# Metadata only (JSON):
GET …/instances/1.2.3.4.5/metadata
Accept: application/dicom+json

Key Parameters / Headers

Acceptapplication/dicom (file), application/dicom+json (metadata), image/jpeg (rendered)
FrameList1,3,5 or 1-5 for frame ranges
STOW-RS
STOW-RS — Store
POSTStore Over the Web — RESTful ServicesDICOM PS 3.18

Store DICOM instances or bulk data to a server over HTTP. Equivalent to DICOM C-STORE but RESTful.

Endpoints

PathDescription
/studiesStore instances (server assigns Study UID from metadata)
/studies/{StudyUID}Store instances into a specific study

Example

POST /wado/rs/studies HTTP/1.1
Content-Type: multipart/related; type="application/dicom"
Accept: application/dicom+json

--boundary
Content-Type: application/dicom
[Binary DICOM instance bytes]
--boundary--

→ HTTP 200
{
  "00081190": { "vr": "UR", "Value": ["http://server/wado/rs/studies/1.2.3"] }
}

Key Parameters / Headers

Content-Typemultipart/related; type="application/dicom" for DICOM files
Acceptapplication/dicom+json for response metadata

Traditional DIMSE vs DICOMweb

DICOMweb (QIDO-RS + WADO-RS + STOW-RS) is the RESTful successor to the binary DIMSE services. Most modern PACS and all cloud imaging platforms support both.

AspectDIMSE (Classic)DICOMweb (Modern)
ProtocolDICOM DIMSE (binary)HTTP/HTTPS (RESTful)
TransportTCP socket, proprietary portStandard 80/443, CDN-friendly
AuthenticationTLS + AE TitlesOAuth 2.0, API keys, SMART on FHIR
QueryC-FINDQIDO-RS (GET)
RetrieveC-MOVE / C-GETWADO-RS (GET)
StoreC-STORESTOW-RS (POST)
Firewall friendlyNo — needs open portsYes — standard HTTPS
Browser supportNoYes — works in any browser
FormatBinary DICOM onlyDICOM, JSON metadata, rendered JPEG/PNG