Connecting radiology to the HIS

In most Indian hospitals, the HIS and the radiology systems were bought by different committees in different years. The HIS team says the interface is "done". The radiology team says orders still come on paper, or the report is typed twice. Both are usually right. The interface exists; it just doesn't carry everything, or it breaks quietly when something changes.

This guide explains what a working HIS PACS integration actually involves, in plain terms, so that hospital administrators and radiology heads can ask better questions. First, a few words about what has to move, then the HL7 messages that carry it today, where FHIR and ABDM fit, and the failure modes we see most often.

What has to move between the HIS and radiology

Strip it down and there are only four flows:

1. Patient details from HIS to RIS-PACS: who the patient is, and any later corrections.
2. Orders from HIS to RIS: "CT brain plain for this patient, from emergency, urgent."
3. Status back to HIS: scheduled, scanned, reported.
4. Results back to HIS: the signed report, and ideally a link to view the images.

Everything else is detail. But the detail is where integrations fail. (If the split between RIS and PACS is itself unclear, our post on RIS, PACS or RIS-PACS covers which system does what.)

HL7 v2: the messages that matter

Most HIS products in India still integrate with radiology over HL7 version 2, a text-based message standard that has been around for decades. Each message is a set of lines called segments, and each segment is a row of fields separated by the pipe character (think of it as one row of a spreadsheet, with | instead of cell borders). You don't need to read the spec. You do need to recognise three message families.

ADT (Admit, Discharge, Transfer). Patient demographics and movement. The ones radiology cares about are registration and admission, updates to patient details (name spelled wrongly at registration, corrected later), and merges (two hospital numbers found to be the same person). If your interface only handles "new patient" and ignores updates and merges, your PACS will slowly fill with wrong names and duplicate records.

Orders: ORM or OMI. The HIS sends the imaging order. Older interfaces use the ORM^O01 message; HL7 v2.5 introduced OMI, a message designed specifically for imaging orders, and IHE's own proposal for updating Scheduled Workflow describes ORM as overloaded and moves imaging orders to OMI. In practice, plenty of Indian HIS still send ORM, and that is fine if both sides agree on the fields. The order should carry the patient ID, the procedure code, the ordering doctor, the priority, and the accession number. Cancellations and modifications need to work too, not only new orders.

To make this concrete, here is a simplified, illustrative ORM order for a plain CT brain (real messages carry many more fields):

MSH|^~\&|HIS|HOSPITAL|RIS|RADIOLOGY|202606021030||ORM^O01|MSG00123|P|2.3
PID|1||UHID123456^^^HOSPITAL||KUMAR^LAKSHMI||19800412|F
ORC|NW|ORD789||||||||||D1234^RAO^SURESH
OBR|1|ORD789||CTBRAIN^CT BRAIN PLAIN

MSH says what kind of message this is (an ORM order) and who sent it. PID carries the patient: the hospital ID, name, date of birth and sex. ORC is the order control segment; NW means a new order, and the same message with CA would request its cancellation, which the receiving system then accepts or rejects. OBR describes the exam itself. Where exactly the accession number and the priority sit varies between interfaces, which is precisely why both sides need a written interface specification rather than an assumption.

ORU (Observation Result). The report going back to the HIS. Usually the report text, sometimes a PDF embedded or linked, plus who signed it and when. Addenda and corrected reports must also flow back, and the HIS must show the latest version clearly.

HL7 v2 messages between HIS and radiology, with the accession number carried end to end.

If you remember one thing from this guide, make it the accession number. It is the number that ties one order to one set of images to one report. It travels in the HL7 order, gets passed to the modality through the DICOM worklist, sits in the header of every image, and comes back in the result message. When it is generated in one place, used consistently, and never retyped, everything lines up. When the HIS creates one number and the RIS creates another, or the technician types it by hand on the scanner, you get reports attached to the wrong study and images that no order claims. Decide upfront which system creates the accession number (usually the HIS or the RIS, not both) and make sure the modality worklist is switched on so it reaches the scanner untouched. Our DICOM guide explains the worklist side.

FHIR, ABDM and ABHA

FHIR (Fast Healthcare Interoperability Resources) is HL7's newer standard. It most commonly works through web APIs (it also supports messages and documents) and small, well-defined "resources" that systems can read and write. Three matter for radiology:

FHIR does not replace DICOM for images. ImagingStudy describes the study and points to where it can be fetched, typically over DICOMweb. Nor does FHIR magically fix integration; a FHIR interface with wrong patient matching fails in exactly the same way as an HL7 v2 one. Its advantage is that it is easier for modern software to build against, and it is what India's national digital health stack uses. (On the DICOM side, structured AI results travel as DICOM SR; see DICOM SR: AI findings a report can read.)

The Ayushman Bharat Digital Mission (ABDM) is the government's framework for linking health records across providers. The pieces relevant to a radiology department or diagnostic centre are:

The technical format for these records is FHIR. The FHIR Implementation Guide for ABDM, published by NRCeS, is based on FHIR R4 and includes profiles for DiagnosticReportImaging, ImagingStudy and a DiagnosticReportRecord bundle for sharing radiology and lab reports.

There has also been a financial nudge. The Digital Health Incentives Scheme, launched on 1 January 2023, paid eligible HFR-registered facilities, including diagnostic labs, based on digital records linked to patients' ABHA numbers. Check the current status of the scheme on ABDM's site before planning around it, as it has been extended in phases. For a radiology department, the practical questions are: can the RIS capture ABHA at registration, can it produce ABDM-compliant FHIR reports, and is the software integrated as a HIP (directly or through the HIS)?

Where integrations fail, and what to ask a vendor

These are the failure modes we see repeatedly.

• Only new orders work. Cancellations, modifications and repeat orders don't flow, so the radiology worklist fills with exams that were cancelled in the HIS.
• Patient updates and merges ignored. A name corrected in the HIS never reaches PACS. Two hospital numbers merged in the HIS stay as two patients in PACS, splitting the priors.
• Procedure code mismatch. The HIS order says "CT ABD" and the RIS expects "CT ABDOMEN & PELVIS WITH CONTRAST". Someone has to maintain a mapping table, and nobody owns it.
• Two systems generating accession numbers.
• Reports flow but addenda don't. The clinician reads the original report in the HIS and never sees the correction.
• Silent failures. The interface engine queues messages after a network blip and nobody notices for a day. There is no alert, no dashboard, no one checking.
• HIS upgrade breaks the interface. The HIS vendor changes a field during an upgrade, and the radiology side finds out from angry phone calls.
• Character and format issues. Names with initials and dots, dates in different formats, long addresses truncated.

None of these are about the standard. They are about scope, testing and ownership. So when you talk to a vendor, these are the questions we would put to them:

1. Which HL7 v2 message types and events do you support, inbound and outbound? Do you handle updates, merges and cancellations, not only new orders?
2. Do you support FHIR R4 ServiceRequest, ImagingStudy and DiagnosticReport? Have you implemented ABDM's FHIR profiles?
3. Which system generates the accession number in your typical setup, and how does it reach the modality?
4. Can you show a live integration with an HIS like ours, at a reference site we can call?
5. How are interface errors monitored and alerted? Who sees them, and how quickly?
6. Who maintains the procedure code mapping?
7. What happens when our HIS is upgraded? Who tests, who pays?
8. Can we send ABHA from the HIS, and can you act as or work with our HIP integration?
9. Is the interface cost included, or is it a separate line item per message type?

Get the answers in writing, and test the failure cases (cancel, update, merge, addendum) before go-live, not after.

How we approach it

The practical upshot is that a good HIS PACS integration is less about which standard is used and more about agreeing, in writing, who owns each identifier and each failure case, and then testing those cases before the first real patient.

Related reading

• DICOM explained — worklists, AE titles and the DICOM side of the same chain.
• RIS, PACS or RIS-PACS — what each system does and where the handoffs break.

FAQ

What is HIS PACS integration?

It is the connection that lets the hospital information system send patient details and imaging orders to the radiology systems, and receive status updates, signed reports and image links back, without anyone retyping information.

Which HL7 messages are used in radiology integration?

Mainly ADT messages for patient details and updates, ORM or OMI messages for imaging orders, and ORU messages for sending reports back to the HIS.

Is FHIR replacing HL7 v2?

Not yet in most Indian hospitals. HL7 v2 is still the common way HIS and RIS exchange orders and results. FHIR is growing, especially for web and mobile apps and for ABDM, where it is the required format for sharing health records.

Do diagnostic centres need to integrate with ABDM?

Whether it is required depends on your setting and any government schemes you participate in, so check current ABDM guidelines directly. Even where it is optional, registering with the Health Facility Registry and linking reports to patients' ABHA makes records easier to share. Ask your RIS-PACS vendor whether they support ABDM's FHIR profiles.