“Radiology information system” and “PACS” turn up in the same sentence often enough that a product team new to imaging can be forgiven for treating them as two names for one system. They are not. A radiology information system is the department’s system of record for everything around an exam that isn’t the image itself: who ordered it, when it’s scheduled, what the report says, and what gets billed. A PACS is the system that owns the image: receiving it from the modality, storing it, and getting it to whatever screen needs to display it.
The primary seam between them is the modality worklist. At that seam, two independently built products have to agree on the same patient, the same order, and the same accession number. When a multi-vendor radiology deployment goes wrong, that handoff is the first place to look.
What a Radiology Information System Owns, End to End
A radiology information system carries the business and clinical record around an exam, not the pixels. A 2013 review in the American Journal of Roentgenology, “The Future of the Radiology Information System,” traces that scope back to the earliest departmental systems. Those systems, it says, handled “the patient identification database and the ordering physician database, as well as tracking the patient through the steps of acquiring the images and tracking report interpretation.” The same review is candid about where several RIS functions have gone since: order entry, patient registration, the report repository and the physician directory “have moved to enterprise electronic medical records.”
IHE’s own systems inventory for radiology workflow names the RIS just as plainly, as “radiology departmental information systems that manage department scheduling.” Broken into the functions a product or engineering lead actually has to plan an integration around:
- Order entry. Captures what was ordered, by whom, and why, whether it originates in the RIS itself, an EHR, or a physician portal upstream of it.
- Scheduling. Books the exam against modality availability, technologist time, and prep requirements like contrast or fasting.
- Patient tracking. Follows the exam through every step from order to final signed report, so nothing sits in an unassigned queue.
- Reporting. Houses the structured or dictated report and tracks whether a radiologist has signed it.
- Billing. Attaches the procedure codes and charge data tied to the completed exam.
None of that requires an image to exist yet. A RIS can schedule, track, and bill an exam before a single pixel has been acquired. It stays the system of record for the order and the report long after the study itself has been handed off to the PACS.
What a PACS Owns Instead
A PACS picks up exactly where the RIS’s record stops being enough: at the pixels. The direction of that handoff matters, and DICOM states it plainly. The DICOM Store service is what a modality uses to send images “to a picture archiving and communication system (PACS) or workstation.”
The modality sends; the PACS receives. From there the PACS stores the study with the metadata that makes it retrievable years later, distributes it to whatever viewer a reader needs, and attaches the signed report once one exists. What a PACS Actually Does, Explained for Product Teams walks through those four jobs and the components underneath them in full. This piece goes deeper on the RIS side, and on the point where the two systems touch.
That division holds up until deployment, where the two systems’ domains stop looking so clean. The worklist queue a reader works from often sits inside the PACS or its viewer, even though the schedule behind it originates in the RIS. A signed report frequently gets referenced from both systems: the RIS as the record of truth, the PACS as a document distributed alongside the study for convenience. The boundary is conceptually clear, but in practice it is a handoff, and handoffs are where the integration work happens.
The Seam: How the Modality Worklist Connects Them
The handoff has a name and a specific mechanism: the DICOM Modality Worklist service, MWL. DICOM’s own documentation describes it in exactly those terms: MWL “provides a list of imaging procedures that have been scheduled for performance by an image acquisition device.” The entry carries what the RIS already captured at order entry and scheduling: patient identifiers, procedure type, accession number, referring physician, and reason for exam.
Before MWL existed as a standard mechanism, all of that had to be typed in by hand at the scanner console. DICOM’s own account of the alternative is direct: “the scanner operator was required to manually enter all the relevant details. Manual entry is slower and introduces the risk of misspelled patient names, and other data entry errors.”
The service is a query, not a message stream. A scanner “queries a service provider, such as a RIS, to get this information.” That information is “then presented to the system operator and is used by the imaging device to populate details in the image metadata.” A missing worklist entry is therefore never a failed delivery, only a query that came back empty, and the cause sits on one side of it or the other:
- On the RIS side. The scheduled procedure step was never published, or it was published after the modality had already queried.
- On the DICOM side. The association itself can be refused, since DICOM defines both “calling-AE-title-not-recognized” and “called-AE-title-not-recognized” as association rejection reasons. Or the association succeeds and the query keys miss, most often Scheduled Station AE Title or Modality, both of which “shall be retrieved with Single Value Matching.”
Instrumenting both ends of that query is the first thing worth doing in a new integration.
How an Order Actually Moves From the RIS to the Scanner
IHE’s Scheduled Workflow profile documents this exact journey formally. The profile “integrates the ordering, scheduling, imaging acquisition, storage and viewing activities associated with radiology exams.” IHE’s own list of what the profile does includes bridging “the gap between HL7-based systems (like RIS) and DICOM-based systems (like acquisition modalities and PACS).”
- A referring physician or scheduler enters the order, either in the RIS directly or in an EHR that forwards it.
- The RIS records the order and schedules it: exam type, date, time, room, and technologist.
- The RIS (or the broker in front of it) makes that scheduled procedure step available through its DICOM Modality Worklist service. HL7 messaging, the standard that normally carries orders and scheduling data between a RIS and the other systems around it, does its work upstream of this point, getting the order into the RIS in the first place.
- The modality queries the DICOM Modality Worklist service and pulls the matching entry: patient identifiers, procedure description, accession number, and the rest of the order context.
- The technologist confirms the match and runs the exam. The modality sends the resulting images to the PACS over a DICOM store operation, already tagged correctly because the worklist data populated the metadata instead of a keyboard.
Steps one and two happen entirely on the RIS and HL7 side. Step three is still the RIS’s job, but it is done over DICOM: the RIS or its broker stands up the worklist service. Step four is the modality’s DICOM query against it, and step five is pure PACS territory. The order crosses from HL7 into DICOM at step three, and everything upstream of that is the RIS’s problem to get right.
How the Report Gets Back
The path back runs in roughly the same shape, reversed. Once the exam is performed, the modality reports what happened using a companion DICOM service: Modality Performed Procedure Step, or MPPS. The standard describes it as enabling the modality to “send a report about a performed examination including data about the images acquired, beginning time, end time, and duration of a study, dose delivered, etc.” IHE specifies MPPS precisely “to convey that status from the modality to the RIS and the PACS.”
That is what lets a RIS mark an order fulfilled and a PACS confirm a study is complete rather than partially received. The image itself lands and stays in the PACS. A radiologist reads the study in a DICOM viewer, dictates or enters findings, and signs the report inside whatever system owns reporting. That is usually the RIS itself, or a reporting module tightly coupled to it.
Once signed, the report leaves the RIS for the referring physician, the EHR, and the billing workflow that closes out the exam. The PACS’s part in that return trip is usually limited to making the study available to whoever needs to read it. The RIS stays the authoritative record of the report and the billing event tied to it.
Where RIS and PACS From Different Vendors Actually Break
The seam holds together cleanly when one vendor’s engineering team designed both sides of it. Split the RIS and the PACS across two vendors, and every assumption sitting on that seam has to be negotiated and tested instead. The failure modes below are the specific mechanics behind the generic “worklist mismatch” every vendor warns about:
- Stale worklist entries. A canceled or rescheduled order has to propagate from the RIS to the modality before the next query. If that update lags, a technologist can scan against an order that no longer exists, or miss one that just changed.
- Accession number drift. The accession number is supposed to be the one identifier that ties an order, a study, and a report together across every system that touches it. If the RIS and the PACS generate or reformat that number differently, the tie breaks silently, usually surfacing only when someone tries to pull a prior study.
- HL7 version and dialect mismatch. RIS platforms and integration engines don’t all speak the same HL7 version, or the same local dialect of it. A broker or interface engine frequently sits between the RIS and everything downstream to reconcile that. Skipping that layer because “it’s just HL7” is a common and expensive mistake.
- MPPS not honored. A PACS that ignores or only partially processes MPPS status updates can mark a study complete before the modality has finished sending. Or it leaves a study looking incomplete indefinitely, because the confirming message never arrived.
- Procedure code mapping. The RIS’s internal procedure codes rarely line up one to one with a modality’s or a PACS’s expected values without an explicit mapping table. An unmapped code tends to surface as the wrong protocol run at the scanner, not as a clear failure message.
None of these are exotic. They are the ordinary cost of a multi-vendor deployment, and every one of them is testable before a contract gets signed, not just after a go-live.
Questions to Ask at the Seam
Each failure mode above converts into a question, and the conversion is mechanical: ask who owns the thing that can drift, then ask what the system does once it has drifted. Run that on the accession number, the cancellation lag, the MPPS timeout, the HL7 dialect, and the procedure code mapping table.
One question does not come off that list and should be asked anyway. How does a signed report route back out, and does that path carry the procedure and billing codes the RIS needs to close the encounter? A vendor who answers each of those with a specific mechanism, not a reassurance, is describing a seam that has actually been tested.
What This Means for Your Integration
The boundary itself is rarely what costs money. The cost comes from two independent products having to agree in exactly one place: the worklist. That agreement runs through a small number of well-defined DICOM services rather than a shared database or a proprietary handshake, which means it is inspectable before anyone signs anything. So the question in front of a product team is not which RIS or which PACS is the stronger product, but which vendor owns the seam when something on it fires.
EBM mAIn PACS® sits on the PACS side of that seam, on native DICOM services: C-STORE, Query/Retrieve, Modality Worklist, and Storage Commitment. Modality Worklist on that list is not a contradiction of step three above: a PACS-side worklist service answers for a deployment that has no RIS behind it, or fronts one that does. Where a RIS is present, the RIS or its broker stays the worklist provider. The modalities and viewers on the other side of those services get a documented, standard interface to connect against instead of custom middleware.
The supported integration surface here is deliberately the DICOM side of the seam. The HL7 standard is maintained by a different organization, and the RIS side of this integration stays the RIS vendor’s responsibility: order entry, scheduling, and the HL7 messaging that carries them. For a partner packaging the DICOM side of that architecture into its own product, EBM Fabric™ is the partner platform behind EBM mAIn PACS®, designed for OEMs and VARs.
Getting the boundary right before an integration starts is what turns a multi-vendor deployment from a maintenance liability into an architecture decision that holds.