How to Integrate AI with PACS, RIS, and EMR Workflows

TL;DR

• What decides whether an AI imaging product reaches production is the workflow its result lands in. Jump to The architecture in plain terms.
• Four intake routes an AI service can use to pull a study from PACS, and what each one sets for latency, auth, and site compatibility. Jump to Where AI receives the study.
• Which DICOM object carries which kind of result, and why viewer display quietly breaks when the choice is wrong. Jump to What AI writes back to PACS.
• When a structured field belongs in RIS, and what happens to the worklist when it lands in the wrong place. Jump to What returns to RIS.
• The Cobb build in numbers, from 2,400 validation studies to 1.8 degree mean absolute error and the under 10 second budget that shaped the architecture. Jump to The Cobb build as a worked example.
• Seven failure modes that kill AI imaging pilots, and where each one hides. Jump to Failure modes to plan for.
• Eight shadow testing checks that clear an AI feature for signed clinical use. Jump to Shadow testing before clinical release.
• The one design decision that governs everything else, which is where the signed result lives. Jump to How to decide where each result lives.

The Cobb angle project started as a measurement problem. A medical imaging software company had a scoliosis workflow that was slowing radiologists and frustrating referring orthopedic surgeons. Manual Cobb angle measurement added several minutes per study. Free text dictation had to be reshaped into a 14 field scoliosis template. Prior report comparison required manual PACS search.

Every one of those bottlenecks sat in the workflow around the measurement.

Clixlogix built the AI module inside the client’s existing desktop recorder and PACS workflow. The radiologist opened the study the same way. The AI module retrieved the study from PACS through DICOM query and retrieve. It returned accepted measurements to PACS as DICOM Structured Report objects. It returned visual measurement lines and vertebral labels as GSPS overlays. Study orders arrived as HL7 ORM messages. Signed results left the reporting stack over HL7 ORU carrying structured report fields and the DICOM SR reference.

That build reached 1.8 degrees mean absolute error against consensus radiologist reads. 91% of measurements landed within 5 degrees. Report turnaround moved from around 36 hours to under 10 hours. Template field completeness rose from 62% to above 90%. The non functional requirement set the path from study open to populated sidebar under 10 seconds.

That is the integration shape this article explains.

This is written for healthtech product owners and radiology IT teams deciding where AI output should live. If you are building an AI imaging feature, map the systems (PACS, RIS, EMR), the standards (DICOM, HL7, FHIR), and the reader surface (viewer behavior, latency, sign off) before production.

Fig 1 – A practical AI imaging flow. PACS holds the study and DICOM result objects. RIS and the reporting stack handle structured fields and report status. EMR receives the signed result.

The architecture in plain terms

An AI imaging tool needs three routes.

First, it needs a study intake route through DICOM routing, DICOM query and retrieve, DICOMweb, or viewer context. Second, it needs a result return route. Image derived output should go back as a DICOM object when the result needs to travel with the study. Third, it needs a clinical result route. RIS needs structured fields when AI affects report content, worklist state, QA routing, or operational analytics. The EMR receives the signed clinical result through the site’s normal result interface.

The Royal College of Radiologists makes this point directly in its guidance on integrating AI with RIS and PACS workflows. AI findings should be communicated to PACS through DICOM and to RIS through HL7. The guidance also says AI analysis should be complete and available on PACS before the human reporter starts interpretation.

RSNA’s Radiology Reimagined program follows the same direction. It shows AI in realistic radiology scenarios using standards such as IHE AI Results, IHE AI Workflow for Imaging, interactive reporting, common data elements, and FHIRcast. Buyers want a result that moves through the same clinical systems that already move the study and report.

Native or bolt on integration

Buyers usually frame the first decision as native or bolt on.

Native integration puts the AI result inside the PACS viewer the radiologist already uses. Findings appear in the reading surface next to the images, with no second application to open. Sites favour this because it protects the read and keeps training effort low. It also ties your product to specific viewer vendors and their release cycles, so each new site can mean new work.

Bolt on integration runs the AI service alongside PACS and returns results through standards based routes. The radiologist sees results as DICOM objects in the viewer, as structured fields in the report, or in a separate review surface. This travels across sites more easily because it depends on DICOM and HL7, which every imaging site already runs.

The four intake patterns in the next section are the practical expression of that choice. Viewer context integration sits at the native end. DICOM routing, query and retrieve, and DICOMweb sit at the bolt on end.

Where orchestration platforms fit

Larger sites often add a third layer. AI orchestration platforms such as Blackford, Aidoc, deepc, CARPL, and the Nuance AI Marketplace sit between PACS and a catalogue of AI applications. The platform handles study matching, routing rules, result write back, and monitoring for every algorithm the site runs, so the site integrates once instead of once per vendor.

For a single AI feature, direct integration usually ships faster. For a site already running several algorithms from different vendors, the orchestration layer removes repeated integration work and gives governance one place to live. Ask early which model your buyer runs. A site standardised on a marketplace will expect your product to arrive through it, and that changes your packaging, your result format, and your commercial route.

Where AI receives the study

You have four common intake patterns. Pick the one that matches when the result is needed.

DICOM routing works well when the AI result can be prepared before the radiologist opens the study. DICOM query and retrieve fits tools that react to the active read. DICOMweb fits newer archives and web viewers. The DICOM PS3.18 Web Services standard defines web service access patterns for DICOM resources, including query, retrieval, and storage. Viewer integration fits products that assist the reader inside the workstation. Keep that integration boundary small. Pass study identifiers, user context, and result panel state. Keep the clinical result in the standards based flow.

What AI writes back to PACS

PACS is the imaging archive. If the AI output comes from the image and needs to remain connected to the study, PACS should usually receive a DICOM result object.

The current DICOM Standard is broad. For AI imaging products, the practical question is which DICOM object carries which result.

DICOM Structured Reporting is a strong fit for measurements because it can carry coded content, references to source images, and structured values. The DICOM information object definitions include the object model that SR and presentation states rely on. GSPS is useful when the result needs to be seen as an overlay. In the Cobb build, endplate lines and vertebral labels returned as GSPS overlays bound to the source study.

IHE’s AI Results profile points to the same operational need. AI results need to be stored, retrieved, and displayed in the radiologist’s reading environment.

What returns to RIS

RIS owns the operational radiology workflow. It tracks the order, accession, scheduling, modality context, report state, reader assignment, QA flags, and result lifecycle. If the AI result changes how the case moves, RIS needs to know.

Use RIS or the reporting stack for structured report fields, triage state, QA flags, acquisition quality warnings, report completeness checks, billing support fields, and result status events.

HL7 v2 remains common here. The HL7 v2.5.1 Observation Reporting chapter describes ORU messages for transmitting observations and results of diagnostic studies. Orders and order context often arrive through HL7 order messages, including ORM in older deployments.

FHIR may appear around newer EMR integration, patient facing products, and API based workflows. The FHIR ImagingStudy resource represents information about a DICOM imaging study. The FHIR DiagnosticReport resource represents the report. The FHIR Observation resource can represent measurements and simple assertions.

Keep the distinction clear. DICOM carries the image evidence. RIS carries operational report workflow. FHIR can expose approved clinical data through an EMR friendly API where the site supports it.

PACS, RIS, EMR, and AI platform ownership

Do this mapping before interface build. It prevents late rework.

Fig 2 – PACS, RIS, EMR, and the AI platform should each own a different part of the workflow.

The Cobb build as a worked example

The Clixlogix Cobb angle case study gives a concrete version of this architecture.

The client operated an AI based medical imaging platform serving radiology groups and orthopedic specialist clinics. The scoliosis module had to detect end vertebrae, propose landmarks, compute Cobb angles, support S curves, handle post surgical hardware, and work across standing spine radiographs and EOS studies. The radiologist had to review every measurement. The signed value had to remain the radiologist’s value.

Here is the actual integration path:

Validation ran before production on 2,400 studies. The corpus covered pediatric and adult standing spine radiographs, EOS studies, Risser stage, curve severity, acquisition modality, and post surgical status. The reference standard was consensus review by two board certified radiologists, with orthopedic spine surgeon adjudication when disagreement exceeded 3 degrees.

The production release cleared the agreed clinical thresholds:

Fig 3 – The Cobb build combined workflow integration with measurable clinical and operational results.

The key lesson is simple. The result stayed in the systems the site already trusted. PACS held the imaging evidence. The reporting stack received structured fields before sign off. HL7 carried signed results out. The AI platform kept the model metadata, confidence scores, overrides, and retraining feedback.

Failure modes to plan for

Most AI imaging pilots fail in ordinary places such as routing, worklists, latency, viewer display, and signed value traceability. Test these risks early.

RCR guidance calls out the same risk at the workflow level. AI should integrate into existing RIS and PACS workflows in a way that avoids extra burden on radiologists. RSNA’s interoperability coverage makes the vendor case too.

Shadow testing before clinical release

Shadow testing is where you find workflow defects before clinicians rely on the result.

In shadow mode, the AI service receives real workflow traffic or a representative replay. Output goes to a test destination, QA queue, or internal dashboard. Your team measures routing, identity matching, mapping, latency, viewer behavior, clinical agreement, and failure handling.

Use this table as the launch gate.

Radiology AI guidance stresses implementation and monitoring as part of responsible clinical use. The ACR Data Science Institute also frames AI around use case definition, validation data, clinical implementation, monitoring, and regulatory awareness.

Fig 4 – Shadow testing should prove routing, mapping, latency, viewer behavior, clinical agreement, and governance before clinical release.

Standards checklist for product owners

Ask these questions before build.

The FDA Clinical Decision Support Software guidance is also relevant when your feature affects clinical decisions. FDA’s digital health materials explain that software analyzing medical images may fall inside device oversight depending on intended use. Bring regulatory review into the workflow discussion early.

How to decide where each result lives

If the result is a measurement tied to a source image, plan a DICOM SR path. If the result is an overlay or label, plan GSPS. If the result is a segmentation, plan DICOM SEG. If the result is a triage state, decide whether it changes the RIS worklist, the reporting queue, or a QA dashboard. If the result is final clinical content, route it through sign off.

Some AI outputs are invisible infrastructure. A study quality check can route to a technologist queue. A prior report retrieval signal can help the reporting stack. A measurement proposal belongs in front of the radiologist. A signed observation belongs in the final result path.

Triage has value before the read. Reader assist has value during the read. QA has value after the read. Analytics has value after aggregation. The timing determines whether you should run inference after acquisition, at worklist open, at viewer open, or after sign off.

How Clixlogix approaches AI imaging integration

Clixlogix builds healthcare software around the systems buyers already run. For imaging AI, that means DICOM objects, PACS viewer behavior, RIS worklists, HL7 order and result flows, FHIR paths where appropriate, PHI boundaries, validation evidence, and audit trails. Our AI software development team maps model output to workflow, standards, and release gates.

Relevant healthcare builds include the AI Cobb angle measurement platform, a public health data platform, a cardiovascular AI care companion, and a HIPAA compliant healthcare portal.

The first workshop is usually a workflow map. We identify the study source, the system of record, the reader surface, the result destination, the sign off point, and the failure states. Then we map the AI output to the right standards path.

That work protects the product later. Your buyer wants to know how the feature handles old PACS profiles, mixed viewers, patient merges, corrected reports, low confidence cases, addenda, site specific templates, and model updates.

For an AI imaging feature, start with one question. Where will the signed result live, and what workflow has to trust it.