PACS, RIS, DICOM and HL7 explained: how a radiology department’s systems fit together

The five systems in one sentence each

• PACS (Picture Archiving and Communication System) is the server and software that store medical images and let clinicians view them.
• RIS (Radiology Information System) is the department’s administrative system: bookings, patient registration, worklists, report text, billing.
• DICOM (Digital Imaging and Communications in Medicine) is the file format and network protocol every CT and MRI scanner uses to write and send images.
• HL7 v2 is the messaging standard hospital systems use to pass orders and results between the HIS, RIS and PACS.
• FHIR (Fast Healthcare Interoperability Resources) is HL7’s modern, web-API standard for health records, and the one the Ayushman Bharat Digital Mission uses in India.

These are not competing products; a working department uses all five at once. The rest of this guide takes them in turn, then shows how a remote reporting network such as Raydiac fits alongside them.

What each system does

The open-source entries below are included because most Indian teleradiology and cloud PACS products are built on them, whether or not the vendor says so.

How a study flows from scanner to report

A CT or MRI study passes through six stages, and each stage is a hand-off between two of the systems above. Knowing the stages makes it much easier to work out where a delay or a lost study happened.

1. Order and worklist. The referrer’s request is entered in the HIS or RIS, which generates an accession number and publishes the patient to a DICOM Modality Worklist. The technologist selects the patient on the scanner console instead of typing the name.
2. Acquisition. The scanner writes each image as a DICOM instance, grouped into series (for example, axial bone window, coronal soft tissue) inside one study identified by a Study Instance UID.
3. Storage. The console sends the study to the PACS using the DICOM C-STORE service. Where a hospital uses a remote reporting network, the console or PACS also sends a copy to a gateway on the hospital network, which forwards it over HTTPS.
4. Viewing. A viewer loads the study from the PACS, either by classic DICOM retrieval or by DICOMweb. Priors from the same patient are fetched for comparison.
5. Reporting. The radiologist dictates or types the report in the RIS or a reporting platform, signs it, and the report becomes the definitive record of the examination.
6. Delivery. The signed report goes back to the RIS or HIS (HL7 ORU or FHIR DiagnosticReport where these exist), to the referrer, and to the patient, in India often as a PDF by WhatsApp, email or print at the centre.

In a managed teleradiology network the stages are the same; only stages three to five happen partly outside the hospital. The guide to what teleradiology is walks through that version of the flow.

DICOM in more depth

Files, tags and the study hierarchy

A DICOM file is pixel data wrapped in a header of tags. Each tag has a group and element number, for example (0010,0010) for Patient Name, (0008,0050) for Accession Number and (0020,000D) for Study Instance UID. Tags describe the patient, the equipment, the acquisition parameters and the position of the slice in space. The hierarchy is patient, study, series, instance: one patient has many studies, one study has several series, one series contains many instances (slices).

Classic DICOM networking

Three services do most of the work. C-STORE pushes images from one node to another. C-FIND queries a PACS for patients, studies or series matching given tags. C-MOVE asks a PACS to send matching studies to a named destination. Every node has an Application Entity title, an IP address and a port, and both ends must be configured to know each other.

DICOMweb

DICOMweb re-expresses those services as HTTPS APIs: STOW-RS to store, QIDO-RS to query and WADO-RS to retrieve. Because it runs on port 443, the same port every web application uses, it passes through hospital firewalls that would never allow an inbound classic DICOM port⁷. Orthanc can push a study to a remote DICOMweb server with a bearer token or a client certificate⁴, which is the mechanism behind most modern gateways, including Raydiac’s.

DICOM TLS

Classic DICOM is unencrypted. DICOM TLS wraps the association in TLS with certificates at both ends, and Orthanc has supported it since version 1.9.0³. In practice many installed scanners cannot do it, so the encrypted leg usually starts at a gateway inside the hospital rather than at the console.

De-identification

The DICOM standard defines de-identification profiles that list which tags to remove, replace or keep. Orthanc implements the 2008, 2017c, 2021b and 2023b profiles and exposes them through its API². Header de-identification does not remove text burned into the pixels, which mainly affects ultrasound and secondary-capture images rather than CT and MRI. Note the distinction between anonymisation, which destroys the link to the patient, and pseudonymisation, which replaces identifiers with a key that can be reversed under control. A diagnostic report must name the patient, so a reporting platform pseudonymises for reading and re-identifies at signing. Raydiac’s security page describes how that vault works.

HL7 v2 and FHIR

HL7 v2 messages are plain text with segments separated by pipes. The two that matter in radiology are ORM (an order: patient, procedure, referrer, priority) flowing from the HIS to the RIS, and ORU (an observation result: the report text and status) flowing back. Most Indian hospital information systems that integrate at all still do it this way.

FHIR is HL7’s current standard, built on REST APIs and JSON resources such as Patient, ServiceRequest, ImagingStudy and DiagnosticReport. In India, the NRCES FHIR Implementation Guide for ABDM defines a DiagnosticReportImaging profile for radiology reports⁹, and pushing such reports against a patient’s ABHA is the M2 milestone of ABDM. The Ministry of Health and Family Welfare’s EHR Standards for India, 2016 name DICOM, HL7, SNOMED CT and LOINC as the standards for Indian health records; adoption is voluntary⁸. See the ABDM guide for what a centre gains by linking reports.

Cloud PACS versus on-premise

An on-premise PACS is a server in the hospital with a licence, a maintenance contract and someone responsible for backups. A cloud PACS is the same software run by a vendor and sold per study or per month, reached through a browser. The table sets out the trade-offs.

What a small centre actually needs

A single-scanner CT or MRI centre needs four things; the rest can come later.

• A scanner that can send DICOM. Every modern console can; the IT task is to add a destination.
• Somewhere for images to live. Either a PACS (on-premise or cloud) or, at minimum, a gateway that forwards studies to whoever reads them and keeps a local copy for the retention period.
• A viewer. For the reporting radiologist, a diagnostic-grade display and a viewer with MPR and measurements; for referrers and patients, a web link or a CD or film.
• A reporting tool. Something that produces a signed report with the patient identifiers, the radiologist’s name, qualification and registration number, and keeps it for the record.

Questions to ask a vendor

1. Which DICOM services do you support: C-STORE, C-FIND, C-MOVE, DICOMweb STOW, QIDO and WADO? Which do you need from my scanner?
2. Does data leave the hospital encrypted, and by what mechanism (DICOM TLS, HTTPS, VPN)? What happens when the internet is down?
3. Where are the servers, who operates them, and is any patient data sent outside India?
4. How is patient identity handled during reading: full identifiers, anonymised, or pseudonymised and restored at signing?
5. What does the viewer support: multiplanar reconstruction, measurements, priors side by side, hanging protocols? Does it need a plugin or a download?
6. How do reports come back: PDF only, HL7 ORU, FHIR DiagnosticReport, or ABDM push? Which of these exist today and which are on the roadmap?
7. How long are images and reports retained, and how do I export everything if I leave?
8. What is the pricing unit (per study, per month, per user), what is included, and is there a lock-in period?

Vendors sometimes describe integration as “72 hours via DICOM, no hardware required”¹¹. That is achievable when the hospital already has a PACS that can push to the internet. When it does not, a gateway is the honest answer.