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.
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.
Version History
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
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>
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)
| Type | Purpose | Common event |
|---|---|---|
| ADT | Admit / Discharge / Transfer | A01 (admit), A08 (update), A03 (discharge) |
| ORM / OML | Order Message | O01 (new order) — labs, radiology, pharmacy |
| ORU | Observation Result (Unsolicited) | R01 — lab results, report text back to ordering system |
| MDM | Medical Document Management | T02 — signed radiology reports |
| SIU | Scheduling Information Unsolicited | S12 / S13 — appointment booked / cancelled |
| DFT | Detail Financial Transaction | P03 — charge posting |
| MFN | Master File Notification | M02 — staff master file update |
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
| HTTP | FHIR operation | Example |
|---|---|---|
| GET | read / search | GET /Patient/123 | GET /Patient?name=gupta |
| POST | create | POST /Patient (body = new Patient resource) |
| PUT | update (full) | PUT /Patient/123 (body = updated resource) |
| PATCH | update (partial) | PATCH /Patient/123 (body = JSON Patch) |
| DELETE | delete | DELETE /Patient/123 |
| GET | history | GET /Patient/123/_history |
Key Resources (imaging-relevant)
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 tokenA 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
Traditional DICOM Services (DIMSE)
| Service | Direction | Purpose |
|---|---|---|
| C-STORE | SCU → SCP | Push DICOM instances to the PACS archive |
| C-FIND | SCU → SCP | Query the archive for studies/series/instances |
| C-MOVE | SCU → SCP | Ask PACS to push instances to a third AE |
| C-GET | SCU → SCP | Retrieve instances directly back to the caller |
| C-ECHO | SCU → SCP | Connectivity test (DICOM ping) |
| N-ACTION (MPPS) | Modality → PACS | Notify PACS that a procedure step started/completed |
| MWL C-FIND | Modality → Worklist SCP | Fetch 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 ← acceptedSearch for studies, series, and instances without retrieving pixel data. Returns JSON metadata.
Endpoints
| Path | Description |
|---|---|
| /studies | Search for studies matching query params |
| /studies/{StudyUID}/series | Search for series within a study |
| /studies/{StudyUID}/series/{SeriesUID}/instances | Search 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 matchStudyDateRange: 20240101-20240201ModalitiesInStudyCT, MR, US, etc.AccessionNumberRIS accessionlimit / offsetPaginationRetrieve studies, series, instances, frames, or metadata. Supports bulk data retrieval and thumbnail generation.
Endpoints
| Path | Description |
|---|---|
| /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}/metadata | Retrieve metadata only (no pixel data) |
| …/instances/{SOPInstanceUID}/thumbnail | Retrieve 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 rangesStore DICOM instances or bulk data to a server over HTTP. Equivalent to DICOM C-STORE but RESTful.
Endpoints
| Path | Description |
|---|---|
| /studies | Store 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 filesAcceptapplication/dicom+json for response metadataTraditional 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.
| Aspect | DIMSE (Classic) | DICOMweb (Modern) |
|---|---|---|
| Protocol | DICOM DIMSE (binary) | HTTP/HTTPS (RESTful) |
| Transport | TCP socket, proprietary port | Standard 80/443, CDN-friendly |
| Authentication | TLS + AE Titles | OAuth 2.0, API keys, SMART on FHIR |
| Query | C-FIND | QIDO-RS (GET) |
| Retrieve | C-MOVE / C-GET | WADO-RS (GET) |
| Store | C-STORE | STOW-RS (POST) |
| Firewall friendly | No — needs open ports | Yes — standard HTTPS |
| Browser support | No | Yes — works in any browser |
| Format | Binary DICOM only | DICOM, JSON metadata, rendered JPEG/PNG |