Radiology Information System (RIS) Explained: RIS vs PACS vs EHR

What Is a Radiology Information System?

A radiology information system (RIS) is the software an imaging department uses to manage the non image side of radiology: receiving orders, scheduling exams, tracking patients through the visit, feeding worklists to scanners, capturing the radiologist's report, sending results back to the ordering physician, and generating charges for billing. It is the operational record of every imaging exam. The images themselves live in a separate system, the picture archiving and communication system (PACS).

The simplest way to hold the distinction: the RIS knows who was scanned, why, when, by whom, and what the radiologist said. The PACS knows what the pictures look like. A radiologist reading a CT uses both at once, usually from one screen, and the thing that joins them is a shared identifier called the accession number.

RIS products emerged in the 1980s and 1990s as departmental systems that sat beside the hospital information system. They matter today because imaging is one of the highest volume, highest cost, and most standards dependent workflows in a hospital. According to the Centers for Medicare and Medicaid Services, imaging is one of the largest categories of Part B physician spending, and every one of those exams passes through a RIS or a RIS module inside the EHR.

In US hospitals the standalone RIS is fading. Epic Radiant and Oracle Health (formerly Cerner) RadNet ship RIS functions as modules of the EHR, so the order, schedule, and report all live in the same database as the rest of the chart. Standalone RIS from vendors such as Fujifilm, Intelerad, and Sectra remains common in outpatient imaging centers, radiology groups, teleradiology practices, and health systems that run more than one EHR.

What a RIS Does

Every RIS, whether standalone or an EHR module, covers the same seven functions. The names differ by vendor, but the workflow underneath does not.

• Order entry and management. Receives the imaging order from the EHR or a referring practice, validates the procedure code against the exam catalog, checks for duplicate orders, captures the clinical indication, and manages prior authorization status. Under the Protecting Access to Medicare Act (PAMA), Appropriate Use Criteria consultation for advanced imaging was designed to happen at this step, though CMS paused the program in 2024.
• Scheduling. Books the patient onto a specific modality, room, and time slot. Handles protocol duration, contrast requirements, equipment constraints (for example a 1.5T versus a 3T MRI), and prep instructions. Sends reminders and manages cancellations and no shows.
• Patient tracking. Records arrival, check in, waiting, in room, exam complete, and departed. This is the status board the front desk and the technologists watch all day.
• Modality worklist. Publishes scheduled exams to scanners through DICOM Modality Worklist so the technologist selects the patient from a list instead of typing the name and ID at the console. This single feature prevents more identity errors than anything else in the department.
• Technologist workflow. Captures protocol selection, contrast dose and lot number, radiation dose, screening questionnaires, and the exam completed status that tells the RIS to release the study to the reading worklist.
• Results reporting. Maintains the radiologist reading worklist, integrates with speech recognition and structured reporting tools (Nuance PowerScribe, for example), manages preliminary and final report states, addenda, critical results notification, and distribution of the signed report to the ordering provider and the EHR.
• Billing hand off. Generates the technical and professional charges once the exam is complete and the report is signed, with the CPT code, modifiers, ICD-10 diagnosis codes, and the performing and interpreting provider, then sends them to the hospital or practice billing system.

Notice what is not on the list: storing, compressing, routing, or displaying images. A RIS may launch the viewer, but the pixels come from PACS. That boundary is why the RIS PACS relationship is the single most important interface in the department, and why we cover the integration side separately on our PACS integration page.

RIS vs PACS vs VNA vs EHR

Buyers confuse these systems because vendors bundle them, and because an EHR module can absorb the RIS entirely. The table below separates them by what data they own, what standards they speak, and who uses them.

RIS vs PACS

The RIS is the workflow system, the PACS is the image system. The RIS tells the PACS what studies to expect (the modality worklist and order messages), and the PACS tells the RIS when images have arrived (the study status update). Radiologists read from a worklist that the RIS drives and a viewer that the PACS provides. Neither replaces the other.

PACS vs VNA

A PACS is departmental and tuned for fast reading. A vendor neutral archive (VNA) is an enterprise archive designed to outlive any single PACS, to hold imaging from cardiology, pathology, dermatology, and endoscopy as well as radiology, and to survive a PACS replacement without a migration. Many health systems run PACS as a short term cache in front of a VNA, and the VNA is what feeds the enterprise viewer and the EHR image links.

RIS vs EHR

The EHR is the system of record for the patient. The RIS is the system of record for the exam. When the RIS is an EHR module (Radiant, RadNet) the distinction disappears in the database but survives in the workflow: the radiology department still has its own scheduling templates, protocols, status board, and reading worklist. When the RIS is standalone, the two systems exchange HL7 v2 messages, and that interface is where most integration effort lands. Our Epic integration work often begins exactly there.

The Imaging Order Lifecycle

Follow one chest CT from order to bill and every system, standard, and hand off becomes concrete. The IHE Scheduled Workflow (SWF) profile defines this sequence formally, and every major RIS and PACS claims conformance to it.

Order in the EHR

A physician orders a CT chest with contrast in Epic. The EHR sends an HL7 v2 ORM O01 (or in newer interfaces an OMI O23, the imaging specific order message) to the RIS. The message carries the patient identifier in PID-3, the placer order number in ORC-2, the requested procedure code in OBR-4, and the clinical reason in OBR-31. The RIS assigns the accession number, which becomes the key that every later message and every DICOM header will carry.

Scheduling and the modality worklist

The scheduler books the patient on CT room 2 at 10:40. The RIS publishes a Scheduled Procedure Step. When the technologist opens the patient list on the scanner console, the modality sends a DICOM C-FIND to the Modality Worklist service, gets back the scheduled patients with their demographics and accession numbers, and the technologist selects one. Every image the scanner produces now carries the correct Patient ID (0010,0020), Accession Number (0008,0050), and Study Instance UID (0020,000D) without anyone typing them.

Acquisition and storage

The scanner acquires the series and sends each image to the PACS with DICOM C-STORE. Many modalities also send Modality Performed Procedure Step (MPPS) messages so the RIS knows the exam started, completed, or was discontinued. When the PACS has all expected images it marks the study complete, and the RIS moves the exam to the reading worklist.

Reading, results, and billing

The radiologist opens the study from the RIS worklist, which launches the PACS viewer on the matching accession number and pulls priors. The dictated report is signed in the RIS, which sends an HL7 ORU R01 back to the EHR with the report text in OBX segments and the result status in OBR-25. The EHR files the result on the order, notifies the ordering physician, and the RIS releases a DFT P03 charge message with the CPT code (for example 71260 for CT chest with contrast) to the billing system. The whole loop is what our HL7 integration team builds and monitors for imaging clients.

Standards: HL7, DICOM, IHE, FHIR

Four standards bodies shape radiology software. HL7 International owns HL7 v2 and FHIR. NEMA and the DICOM Standards Committee own DICOM. IHE (Integrating the Healthcare Enterprise) publishes profiles that specify how to use the other standards together for a real workflow.

HL7 v2 messages

HL7 v2 is the pipe and hat text format that still carries the large majority of order and result traffic in US hospitals. For radiology the important message types are ADT (patient demographics and merges), ORM O01 and OMI O23 (orders), ORU R01 (results), SIU (scheduling), and DFT P03 (charges). Segment level detail matters: a mismatch on PID-3 assigning authority or on ORC-3 filler order number will break the accession match. If you are weighing v2 against FHIR for a new interface, our HL7 vs FHIR guide walks through the trade offs.

DICOM DIMSE services

• C-STORE pushes an image or object from one node to another. This is how a modality sends images to PACS and how PACS forwards to a VNA or an AI server.
• C-FIND queries a node for patients, studies, series, or instances that match a set of attributes. The Modality Worklist is a C-FIND against a worklist SOP class rather than an image archive.
• C-MOVE asks the archive to send matching objects to a third node, typically a workstation or a teleradiology gateway. C-GET does the same but returns them on the same association.
• C-ECHO is the DICOM ping used to verify a connection. N-CREATE and N-SET carry MPPS status updates from the modality.
• Storage Commitment (N-ACTION) lets a modality confirm the PACS has safely stored images before it deletes them locally.

DICOMweb

DICOMweb is the RESTful profile of DICOM. QIDO-RS (Query based on ID for DICOM Objects) replaces C-FIND with an HTTP GET that returns JSON or XML. WADO-RS (Web Access to DICOM Objects) retrieves studies, series, instances, frames, or rendered images over HTTP. STOW-RS (Store Over the Web) stores objects with an HTTP POST. DICOMweb is what makes browser viewers, cloud PACS, and AI pipelines practical, and it is the transport behind the viewer we describe in our browser based DICOM imaging article. The protocol level work of connecting to an archive is covered on our DICOM integration page.

IHE Scheduled Workflow and FHIR

The IHE Radiology Scheduled Workflow (SWF, and its updated SWF.b) profile is the reference architecture for everything in the lifecycle table above. It names the actors (Order Placer, Order Filler, Image Manager, Acquisition Modality, and so on) and the transactions between them, so a RIS that claims SWF conformance as Order Filler and a PACS that claims it as Image Manager should interoperate on the accession and worklist flow. IHE also publishes XDS-I.b for cross enterprise image sharing and the newer Radiology profiles built on FHIR.

FHIR R4 brings the imaging workflow into a modern API model. ServiceRequest represents the imaging order. ImagingStudy represents a DICOM study with its series and instances and points to the DICOMweb endpoint where the pixels live. DiagnosticReport carries the radiologist's findings. Epic, Oracle Health, and most cloud PACS expose these resources, which is how patient portals show images and how third party apps request them. Our FHIR integration practice uses these resources when a client wants imaging data in an app without touching DIMSE at all.

Deployment Models

RIS and PACS were built for on premise servers with dedicated storage and a private network to the scanners. That is still common, but three other models have taken meaningful share.

• On premise RIS and PACS. Servers in the hospital data center, DICOM traffic over the local network, storage sized for the retention policy (typically seven years for adults under most state medical record laws, longer for pediatrics). Predictable performance and full control, but hardware refresh cycles and disaster recovery fall on the hospital IT team.
• Cloud PACS. Image archive and viewer hosted by the vendor or in a public cloud, accessed through DICOMweb and a browser. Scanners send images to an on site gateway that forwards over TLS. Sectra, Intelerad, Philips, GE, and a number of newer vendors sell this way. It shifts capital expense to subscription and simplifies teleradiology, at the cost of dependence on WAN bandwidth and careful attention to HIPAA business associate agreements.
• Enterprise imaging. One VNA and one enterprise viewer that hold every imaging ology, with departmental RIS and PACS acting as workflow layers in front of it. This is the architecture most large US health systems are moving toward, because it makes images available in the EHR for every clinician, not only radiology.
• Open source and hybrid. Orthanc and dcm4chee are widely used as DICOM archives, routers, and test systems, and as the storage layer under custom viewers and AI pipelines. They are rarely the primary clinical PACS at a hospital, but they are common in research, in imaging startups, and as an integration buffer between vendor systems.

The RIS side follows the EHR. If the hospital runs Epic or Oracle Health, the RIS is a hosted module and the deployment question is about PACS only. If the organization is an imaging center or radiology group, a combined RIS/PACS from one vendor, increasingly cloud hosted, is the typical purchase.

Where Radiology AI Plugs In

Radiology has more FDA cleared AI devices than any other specialty. The FDA's public list of AI enabled medical devices is dominated by radiology entries, most of them cleared under the 510(k) pathway. All of them have to attach to the RIS PACS workflow somewhere, and there are three attachment points.

Worklist prioritization

An algorithm receives a copy of each study as it lands in PACS (a C-STORE forward or a DICOMweb subscription), scores it for a critical finding such as intracranial hemorrhage or pulmonary embolism, and sends a flag back. The flag updates the RIS reading worklist so the study moves to the top. The AI never changes the report; it changes the order in which a human reads. Vendors in this category include Aidoc and Viz.ai, and the integration is almost entirely about HL7 and DICOM plumbing rather than the model.

Detection and quantification

Lung nodule detection, mammography computer aided detection, fracture detection, and measurement tools (bone age, cardiac chamber volumes, brain volumetrics) return results as DICOM objects: a secondary capture overlay, a DICOM Structured Report (SR), a Grayscale Softcopy Presentation State, or a segmentation object. The PACS displays them as an extra series on the study. The radiologist accepts, edits, or discards the finding. Custom detection models built with our computer vision development team follow this same DICOM SR pattern so they appear in any viewer without vendor specific code.

Structured reporting and drafting

Newer tools read the images and the prior report and draft a structured report that the radiologist edits and signs. Because the report lives in the RIS, this integration touches the reporting module and the ORU result feed, not PACS. RSNA RadLex, the RadReport template library, and the DICOM SR templates (TID 1500 for measurements) give these tools a vocabulary and a schema, which is what makes the output queryable later.

A practical note for buyers: AI vendors quote sensitivity and specificity from their FDA submissions, and those figures are specific to the study populations and scanner types they validated on. Ask for the labeling, ask how the tool handles a study from a modality it was not validated on, and plan the integration budget as roughly equal to the license, because the routing rules, the worklist update, and the result display are where projects actually stall.

Related Guides

These guides cover the neighboring concepts this article refers to, each written in the same answer first format.

• Healthcare Interoperability Explained: HIE, TEFCA, USCDI, Cures Act and SMART on FHIR: the four levels of interoperability, TEFCA, USCDI and SMART on FHIR.
• HIPAA Privacy Rule vs Security Rule: What Each Covers, Who Complies: what the Privacy Rule and Security Rule each govern and who must comply.
• What Is Revenue Cycle Management? The 2026 Guide to Healthcare RCM: the full revenue cycle, its 12 steps and the KPIs that measure it.

Teleradiology

Teleradiology is the reading of studies by a radiologist who is not at the site where the images were acquired. It began as overnight coverage for rural hospitals and now covers subspecialty reads, overflow, and entire hospital contracts. The technology is the same RIS PACS stack, stretched across organizations.

The acquiring site sends studies to the teleradiology group by C-MOVE or C-STORE through a VPN or a DICOMweb gateway over TLS. The group's own RIS receives the order data by HL7 or through a manual requisition, assigns its own accession, and matches it to the incoming study. The radiologist reads in the group's PACS and signs in the group's RIS, which sends an ORU back to the originating hospital. Priors are the hard part: a study read without the patient's earlier exams is a worse read, so mature teleradiology integrations query the hospital PACS for priors with C-FIND and C-MOVE before the radiologist opens the case.

• Licensing. The interpreting radiologist must hold a license in the state where the patient is located, which is why national groups maintain dozens of state licenses per physician.
• Identity reconciliation. Two RIS instances mean two accession numbers and two MRNs for one exam. The interface has to carry both, or the result will not file on the right order at the hospital.
• Turnaround tracking. Contracts specify turnaround times by priority (stat, urgent, routine), so both RIS systems need timestamps at receipt, open, and sign that agree with each other.
• Compression and bandwidth. Lossless JPEG 2000 or JPEG-LS transfer syntaxes keep diagnostic quality while moving large CT and MRI studies across a WAN.

Buying and Integration Considerations

Whether you are buying a first RIS, replacing a PACS, or adding a module, the evaluation questions that matter are about interfaces, identity, and exit, not screenshots.

• Which EHR and how tight is the coupling? If you run Epic or Oracle Health, the RIS decision is largely made for you and the effort goes into Radiant or RadNet configuration and the PACS interface. If you run a smaller EHR or several, a standalone RIS with strong HL7 v2 and FHIR support is the path.
• IHE conformance statements. Ask every vendor for their IHE Integration Statement and their DICOM Conformance Statement. Confirm the RIS supports Order Filler and Modality Worklist, and the PACS supports Image Manager and Image Archive, under the Scheduled Workflow profile. Conformance statements are public documents and the vendor should hand them over without a sales call.
• Modality inventory. List every scanner with its DICOM conformance statement, supported transfer syntaxes, and whether it supports MWL and MPPS. Older ultrasound and mobile X ray units frequently do not, and that gap will drive the worklist broker and manual matching workflows. Connecting bedside and portable devices is the same problem we solve in medical device integration.
• Migration and exit. A PACS replacement means migrating years of DICOM data, often hundreds of terabytes, with tag remediation for old studies that carry inconsistent patient IDs. Ask what the vendor charges to export your data in standard DICOM at contract end. A VNA in the middle makes the next replacement cheaper.
• Reporting integration. Confirm which speech recognition and structured reporting products the RIS integrates with natively and how the result flows back (HL7 ORU with text, or with embedded PDF, or FHIR DiagnosticReport). Referring physicians care more about the report arriving in their EHR than about anything else in the project.
• Security and audit. HIPAA Security Rule controls under 45 CFR 164.312 apply to PACS and RIS as they do to any system holding protected health information: access control, audit logging, integrity, transmission security. DICOM over TLS, DICOMweb over HTTPS, and IHE ATNA audit logging are the technical answers.

Budget the interface work as its own line item. A RIS or PACS license is a known number. The HL7 feeds, MWL broker, PACS routing rules, prior fetching, and result distribution are where scope grows, and they are also the part that determines whether the department runs smoothly on day one.

Common RIS PACS Integration Failures

Most imaging integration incidents fall into a small number of categories, and almost all of them trace back to identity: who the patient is and which exam this study belongs to.

• Patient ID mismatches. The hospital MRN, the imaging center MRN, and the teleradiology MRN are different identifiers for the same person. If the ADT feed does not reach PACS, or the assigning authority in PID-3 is not configured consistently, images file under the wrong patient or under a new orphan patient. An enterprise master patient index and consistent ADT A40 merge handling are the fix.
• Accession number mismatches. The scanner was used without the worklist and the technologist typed the accession by hand, or a study was performed on a different exam than the one scheduled. The RIS shows an exam complete with no images, and the PACS shows a study with no order. Every PACS has a reconciliation queue for these; a busy department that never empties it is a warning sign.
• Duplicate studies. A modality resends after a network timeout, or two accession numbers are created for one order, and the radiologist sees the same series twice or reads the wrong one. Storage Commitment, correct Study Instance UID handling, and duplicate order checks in the RIS prevent most of these.
• Order status desync. The RIS thinks the exam is scheduled, the PACS has images, the EHR shows the order as pending. Usually an MPPS or an HL7 status message was dropped. Message level monitoring with dead letter queues catches it; hoping the interface engine logs it does not.
• Result never files. The ORU arrives at the EHR with a filler order number that does not match, so the report sits in an error queue instead of on the chart. Ordering physicians report this as the RIS being down when in fact one segment field is wrong.
• Priors not found. Historical studies under an old MRN or a pre merger PACS never link to the current patient, so the radiologist reads without comparison. Migration with tag remediation, and a VNA that resolves identities across sources, is the durable answer.

None of these are exotic. They recur because RIS and PACS are typically bought from different vendors, configured by different teams, and monitored by nobody in particular. Treating the interfaces as a product with an owner, tests, and alerts is what separates a department that trusts its systems from one that keeps a spreadsheet of missing studies.