Healthcare integration, explained

A Picture Archiving and Communication System — the central archive that stores, retrieves, and distributes medical images (CT, MRI, X-ray) along with the study metadata radiologists read from.

A Radiology Information System — manages the radiology department's workflow: orders, scheduling, worklists, technologist tracking, and reporting.

An imaging device that acquires studies — CT, MRI, X-ray, ultrasound, mammography, and so on.

An Electronic Medical/Health Record — the clinical system of record for patient demographics, encounters, orders, and results across the organization.

An interface engine (e.g. Mirth, Rhapsody, Cloverleaf) that routes, filters, and transforms messages between systems.

An intermediary layer or product that sits between systems to broker, buffer, or adapt data — broader than a dedicated interface engine.

A DICOM Modality Worklist server — gives modalities the scheduled patient and procedure details so techs don't type them by hand.

A Vendor Neutral Archive — a long-term image store designed to hold studies independently of any single PACS vendor, so images outlive the system that created them.

A Practice Management System — handles scheduling, registration, and billing, common in clinics and outpatient settings.

A diagnostic or clinical viewer where radiologists and clinicians open and read images.

A generic link or adapter node representing a connection point between systems in the diagram.

A user-defined system for anything the standard palette doesn't cover — a bespoke application, script, or third-party tool.

A processing or transform step — a stage that reshapes, validates, or enriches data rather than a system that stores it.

A manual, human-performed step — someone re-keys data, carries a disk, faxes a report, or exports a file by hand.

The DICOM service that transfers image objects from a sender (SCU, e.g. a modality) to a receiver (SCP, e.g. a PACS).

The DICOM query service — asks an archive for studies, series, or images matching given criteria.

The DICOM retrieve service — instructs an archive to send matching objects to a specified destination AE.

The DICOM verification service — a lightweight "ping" confirming two Application Entities can talk.

Modality Performed Procedure Step — reports procedure status (started, completed, discontinued) from the modality back to the RIS/worklist.

An HL7 v2 order message — transmits imaging or clinical orders and order-status changes between systems.

An HL7 v2 message conveying Admission, Discharge, and Transfer events — the backbone of patient identity and location updates.

An HL7 v2 message that carries observation results — diagnostic reports, lab values, and radiology results — back to the system that ordered them.

An HL7 v2 scheduling message — broadcasts appointment events (new, modified, cancelled) from a scheduling system.

A RESTful API for exchanging FHIR R4 resources (Patient, Observation, Appointment…) over HTTP.

A manual or paper-based exchange, or a user-defined protocol — for steps that aren't a standard electronic message.

Minimal Lower Layer Protocol — the thin framing that wraps HL7 v2 messages over a raw TCP socket, marking where each message starts and ends.

Exchange by reading and writing files in a shared folder — the sender drops a file, the receiver polls and picks it up.

File transfer over FTP or, securely, SFTP — moving files between hosts across a network.

Exchange over HTTP/HTTPS — the transport under REST APIs, web services, and many modern integrations.

Integration by reading from or writing directly to another system's database.

A structured, WSDL-defined XML web-service protocol used by many older enterprise and healthcare services (e.g. IHE XDS).

The DICOM network protocol itself (DIMSE over TCP) — the transport under C-STORE, C-FIND, C-MOVE, and friends.

The internal, trusted clinical network where most hospital systems live and talk to each other.

A demilitarized zone — a buffer network between the trusted internal (clinical) network and untrusted external networks, hosting systems that must be reachable from outside.

A cloud or hosted environment — systems running in a vendor's or public cloud rather than on-premises.

An external or internet-facing zone — partners, patients, or systems outside the organization's control.

An on-premises server room or data center where core systems and databases are physically hosted.