Enterprise AI in Healthcare Imaging: PACS Integration, AI Results, and Workflow Orchestration

Integrating imaging AI requires more than sending a study to an algorithm. A production workflow must identify eligible studies, route or de-identify images when required, submit them to the AI service, validate the response, return results to the PACS, VNA, or EHR in an appropriate format, notify clinicians, and monitor failures, latency, utilization, and model performance.

Health systems also need to determine what happens when a study cannot be processed, an algorithm returns an invalid result, a patient identifier does not match, or a destination system is unavailable. Imaging AI workflow orchestration coordinates these steps across PACS, VNA, EHR, reporting systems, cloud services, and AI applications.

What Production Imaging AI Integration Requires

A production integration should control the complete transaction, not just the connection to the algorithm. It should answer the following questions:

Which studies qualify for the algorithm?
Which images, series, relevant prior studies, or clinical details does the algorithm require?
Where will processing occur?
Does the workflow require de-identification?
How will the system associate the result with the correct patient and study?
Which result format can the PACS, viewer, reporting system, or EHR consume?
How will the workflow notify clinicians?
What happens when processing or delivery fails?
How will the organization monitor operational and clinical performance?
How will it manage algorithm updates and model versions?

The answers depend on the algorithm, clinical use case, connected systems, security requirements, and intended role of the result.

How Hospitals Connect PACS to Cloud AI

A common architecture places an AI orchestration layer between the imaging environment and one or more AI services.

The PACS, VNA, modality, router, or worklist system sends a study or workflow event to the orchestration layer. The orchestrator evaluates eligibility rules, identifies the required series, and routes the data to the selected AI service. A cloud service may receive the images through DICOMweb, a vendor API, or another supported interface.

After the algorithm processes the study, the orchestrator validates the response, associates it with the original patient and study, and delivers the result to the designated PACS, VNA, viewer, reporting system, or EHR.

De-identification is not required for every clinical cloud AI workflow. The organization should determine whether the service needs identifiable clinical data based on the intended use, architecture, contracts, security controls, and applicable policies. If a workflow de-identifies images and later returns results to a clinical system, it must maintain a protected and auditable method for restoring the correct patient and study identifiers.

End-to-End Imaging AI Architecture

A controlled imaging AI workflow typically includes the following stages.

Identify the study: A modality, PACS, VNA, worklist event, HL7 message, or EHR order can initiate the workflow.
Evaluate eligibility: The orchestration layer evaluates rules such as modality, body part, procedure code, institution, patient age, study status, scanner model, or clinical indication.
Select the required imaging data: The workflow selects the study, series, instances, frames, prior studies, or clinical context that the algorithm requires. It should avoid sending unnecessary data.
Prepare the data: Preparation may include DICOM validation, tag normalization, compression changes, series filtering, de-identification, or conversion to a format supported by the AI application.
Submit the AI task: The orchestrator sends the data to an on-premises, cloud, or hybrid AI service and records the algorithm name, model version, configuration, submission time, and transaction identifier.
Monitor processing: The workflow tracks task status, processing time, timeouts, cancellations, retries, and service availability.
Validate the result: The system confirms that the response is complete, readable, associated with the correct patient and study, and encoded in a format the destination can use.
Return and present the result: The workflow sends DICOM result objects to the PACS, VNA, or viewer. It can also send result status, report content, measurements, or study links to an EHR or reporting system through supported HL7 or FHIR interfaces.
Assess and monitor the result: The organization records whether the result reached the destination and, where the workflow supports it, whether a clinician accepted, modified, rejected, or did not review it.

Standards for Imaging AI Integration

DICOM and DICOMweb

DICOM supports the storage and exchange of images and imaging-derived results. DICOMweb provides HTTP-based services for modern applications:

QIDO-RS searches for patients, studies, series, or instances.
WADO-RS retrieves DICOM resources or supported rendered representations.
STOW-RS stores DICOM objects.

The current published standard is DICOM 2026c, released in June 2026. An implementation should still evaluate the conformance statements and supported transactions of every connected system. A system that claims DICOMweb support may implement only part of the service family.

IHE imaging AI profiles

The IHE Radiology Technical Framework includes several Trial Implementation profiles that provide useful integration patterns:

AI Workflow for Imaging, or AIW-I, defines task management using DICOM Unified Procedure Step concepts.
AI Results, or AIR, addresses the encoding and display of imaging AI results.
AI Result Assessment for Imaging, or AIRA, assesses AI-generated findings and measurements.

These profiles can help organizations define interoperable workflow states, result structures, and feedback mechanisms. Because they remain Trial Implementation profiles, teams should confirm vendor support and test each transaction before production use.

HL7 and FHIR

HL7 integration commonly provides order, patient, scheduling, status, and report context. FHIR can expose clinical resources, workflow status, diagnostic reports, and imaging references through web APIs.

The FHIR ImagingStudy resource describes a DICOM study and can provide endpoints for accessing its imaging data. It does not contain the DICOM instances themselves. DiagnosticReport can reference an ImagingStudy and present clinical conclusions or context for results.

FHIR R5 also introduces ImagingSelection, which can identify particular DICOM instances, frames, regions, segmentations, or observations. However, FHIR R5 remains a Standard for Trial Use, and many deployed EHR integrations still use FHIR R4 or vendor-specific profiles. Implementations must account for the version and capabilities of each endpoint.

How AI Results Return to PACS and EHR Systems

PACS, VNA, and diagnostic viewers generally receive AI results as DICOM objects. The selected object should align with the clinical purpose of the result and the destination’s capabilities.

An EHR may receive a result summary, status, measurement, diagnostic report, or link to the study through HL7 or FHIR. The EHR does not have to store the original DICOM result object if it can present the clinical information and provide authorized access to the imaging study or viewer.

The workflow should preserve:

Patient and study identifiers
Accession number and assigning authority
Source study references
Algorithm and model version
Processing date and time
Result status
Destination delivery status
Corrections, replacements, or retractions
Audit history

Result delivery should remain idempotent. A retry should not create multiple indistinguishable copies of the same AI result.

Which DICOM Objects Can Carry AI Results?

DICOM object	Appropriate use	Implementation consideration
Structured Report, or SR	Measurements, coded findings, probabilities, observations, and references to source images	Provides machine-readable content when the destination supports the applicable templates and coded concepts
Segmentation, or SEG	Pixel-level or voxel-level masks that identify anatomy, lesions, or other regions	Requires viewers that can display the segmentation with the correct source images
Presentation State	Display instructions, graphics, annotations, and references to images	Useful when the destination needs visual annotations without changing the source images
Secondary Capture	A rendered image showing an AI result	Broadly viewable but less structured and less useful for downstream computation

Other result types may be appropriate for specific workflows, including Key Object Selection documents, parametric maps, encapsulated documents, and specialized structured reports. The algorithm vendor and receiving-system vendor should document which objects, templates, coded terms, transfer syntaxes, and references they support.

Technical Completion Is Not Clinical Acceptance

An AI workflow should distinguish at least three states:

The processing job is completed. The AI service finished the assigned task.
A technically valid result was returned. The workflow received a readable result, matched it to the correct study, and delivered it to the required destination.
The result received a clinical assessment. A clinician accepted, modified, rejected, or otherwise evaluated the result.

Treating these states as one event can hide significant failures. An algorithm may report that it completed a job even though the result could not be
stored, displayed, or associated with the correct patient. A technically delivered result may also remain unseen or unused by the clinician.

The IHE AIRA profile provides a Trial Implementation model for capturing the assessment of imaging AI results.

Common Imaging AI Workflow Exceptions

Exception	Required response
Study does not meet eligibility criteria	Record the reason and do not submit the study
Required series or prior study is missing	Hold, retry, route without the missing data if permitted, or send the case for review
AI service is unavailable	Queue the study, apply retry limits, notify support, or route to an approved alternative
Processing exceeds the clinical time limit	Mark the result as late, notify the appropriate team, and prevent a late result from creating confusion
Result is unreadable or incomplete	Reject the result, retain evidence, and notify the AI vendor or support team
Patient or study identifiers do not match	Quarantine the result and apply a controlled patient-matching process
Destination PACS or EHR is unavailable	Queue delivery, retry, alert support, and preserve the validated result
Duplicate result arrives	Identify the transaction and version before storing or replacing the existing result
Corrected or retracted result arrives	Retain provenance and apply the destination system’s correction or replacement workflow
Model version changes unexpectedly	Stop or flag the workflow until the approved version and validation status are confirmed.

Every exception should have an owner, a response time, an escalation path, and auditable evidence.

Security Controls for Imaging AI

Imaging AI expands the number of systems, users, services, and network paths that can access clinical data. Security controls should cover the complete workflow.

Key controls include:

Strong service and user authentication
Role-based authorization
Encryption in transit and at rest
Network segmentation and controlled outbound access
Protected credential and certificate management
Audit logging across internal and cloud services
Data-minimization and retention rules
Contractual controls for cloud processing and subcontractors
Vulnerability, patch, and dependency management
Backup, recovery, and service-continuity plans
Incident response procedures
Controlled vendor support access
Validation after security or software changes

The FDA’s February 2026 cybersecurity guidance for medical devices emphasizes secure product design, resilience, documentation, and lifecycle risk management. Health systems should incorporate these principles into vendor review and deployment governance.

Monitoring AI Workflow and Model Performance

Operational monitoring and clinical monitoring answer different questions. Both are necessary. Operational and integration measures

Organizations should monitor:

Number and percentage of eligible studies submitted
AI yield, meaning the proportion of submitted exams that produce a valid, usable result
Queue depth and waiting time
Median and high-percentile processing time
Routing and submission failures
Result-validation failures
Result-delivery success
Retry frequency
Duplicate or late results
Service availability
Network and interface health
Algorithm and model version in use

AI yield is more useful than a simple job-completion count because it measures whether the complete workflow produced a valid result that the clinical system could use. Research on real-world monitoring of imaging AI supports monitoring data flow, processing time, AI yield, infrastructure status, population changes, and human interaction with AI results.

Clinical and model measures

Where reference data and governance processes permit, organizations should also evaluate:

Clinician acceptance, modification, or rejection
Concordance with final reports
False-positive and false-negative patterns
Performance by site, modality, scanner, protocol, or patient population
Changes in case mix or input data
Changes in output distribution
Utilization and bypass rates
Alert burden
Downstream workflow effects
Evidence of performance drift

Report-derived concordance can support monitoring, but it should not automatically be treated as definitive ground truth. The organization should document the limitations of the reference method.

The ACR Assess-AI program uses imaging metadata, AI results, patient demographics, report text, dashboards, and concordance measures to support real-world AI monitoring.

Training Data, Bias, and Local Validation

Regulatory authorization and vendor validation do not establish that an algorithm will perform equally well across all health systems.

Before production deployment, the organization should evaluate the algorithm against representative local data, equipment, protocols, populations, and workflow conditions. The evaluation should consider:

Patient demographics and disease prevalence
Modality and scanner manufacturers
Acquisition protocols
Image quality
Clinical setting
Relevant comorbidities
Referral patterns
Reporting practices
Intended users
Expected result prevalence

A local pilot should test both the model’s performance and its integration behavior. Current industry guidance on integrating and adopting AI in radiology workflows supports local validation, controlled pilot testing, governance, result storage, and post-deployment monitoring.

An accurate algorithm still creates clinical risk if the workflow sends the wrong studies, loses results, displays them late, or associates them with the wrong patient. Human-in-the-loop oversight remains important for identifying unexpected results and workflow failures.

When normalizing clinical and imaging data, organizations may also use controlled terminologies such as SNOMED CT and LOINC where the workflow and receiving systems support them. Dicom Systems provides configurable DICOM and HL7 tag morphing for workflows that require metadata transformation or normalization.

Managing Algorithm Updates and Model Versions

An AI vendor may update the algorithm, model weights, preprocessing, thresholds, user interface, or supported inputs. The organization should record the deployed version and define which changes require technical testing, clinical review, or local revalidation.

At a minimum, track:

Product and algorithm name
Model and software version
Configuration and thresholds
Deployment date
Intended use
Connected sites and systems
Local validation status
Approval history
Performance before and after the change
Rollback procedure

The FDA’s August 2025 guidance on Predetermined Change Control Plans applies to manufacturer-managed changes for AI-enabled device software functions. Health systems should use vendor PCCP information, when applicable, to understand authorized changes and their validation. They should still define their own operational review and local revalidation triggers.

What AI Workflow Orchestration Does

AI workflow orchestration coordinates the systems and decisions around the algorithm. Depending on the deployment, an orchestration platform can:

Receive studies and workflow events.
Apply eligibility and routing rules.
Select the required series or prior studies.
Normalize or de-identify data.
Route studies to multiple on-premises or cloud AI applications.
Track task and transaction status.
Validate returned results.
Convert or route result objects.
Deliver results to PACS, VNA, viewers, reporting systems, or EHR applications.
Queue and retry failed transactions.
Manage exceptions.
Record provenance and model versions.
Monitor workflow performance.

Orchestration does not replace clinical governance or prove that an algorithm remains clinically accurate. It provides the transaction control, visibility, and evidence that governance teams need.

Frequently Asked Questions About Enterprise AI in Healthcare Imaging

How do hospitals connect PACS to cloud AI?

Hospitals commonly use an AI orchestration layer that receives studies or workflow events from PACS, applies eligibility rules, and submits the required images to the cloud AI service through DICOMweb, a vendor API, or another supported interface. The orchestrator validates the returned results and routes them to the appropriate clinical systems.

How are images routed to AI applications?

Routing rules can use modality, procedure code, body part, institution, patient characteristics, study status, or other available metadata. The workflow should send only the images and clinical context the approved algorithm requires. It may also retrieve relevant prior studies when the algorithm requires them.

How are AI results returned to PACS and EHR systems?

PACS and VNA systems generally receive DICOM result objects such as SR, SEG, Presentation State, or Secondary Capture. EHR systems may receive result summaries, reports, statuses, measurements, or links through HL7 or FHIR.

Which DICOM objects can carry AI results?

Common objects include DICOM Structured Reports for coded findings and measurements, Segmentation objects for pixel or voxel masks, Presentation States for annotations and display instructions, and Secondary Capture images for rendered results. The appropriate object depends on the result and the receiving system’s capabilities.

What does AI workflow orchestration do?

AI workflow orchestration controls study selection, routing, preparation, task status, result validation, delivery, retries, exceptions, provenance, and operational monitoring across imaging and AI systems.

How Dicom Systems’ AI Conductor Supports Imaging AI Workflows

Dicom Systems has long approached enterprise imaging with interoperability as a foundational principle. AI Conductor, part of the Unifier platform, provides a standards-based integration and orchestration layer for AI in enterprise imaging. It connects PACS, VNA, RIS, EHR, viewers, and AI applications without requiring separate point-to-point integrations for each system and algorithm.

AI Conductor orchestrates imaging data across multiple AI applications running on-premises, in the cloud, or in hybrid environments. Health systems choose the systems and AI applications to connect. Dicom Systems configures the routing rules, tag transformations, de-identification where required, result handling, exception workflows, and operational monitoring around those connections.

How AI Conductor Orchestrates the Workflow

AI Conductor can coordinate the workflow through six controlled steps:

Receive and evaluate imaging data. The AI router receives DICOM images and related imaging objects and evaluates configured metadata on ingestion.
Select the appropriate AI application. Configurable metadata and workflow rules determine whether the study should route to one or more AI algorithms. Those algorithms may operate on-premises, in the cloud, or in a hybrid environment. When the workflow requires it, AI Conductor can de-identify DICOM metadata and pixel data before transmission.
Submit and track the AI task. The router submits the study to the configured AI service or processing container and records the transaction, allowing the workflow to track processing, timeouts, failures, and returned results.
Search for and retrieve imaging data when required. In a DICOMweb workflow, QIDO-RS searches for DICOM resources and WADO-RS retrieves the required studies, series, instances, or rendered representations. The exact transaction path depends on the interfaces supported by the connected PACS, VNA, and AI application.
Process and return the result. The AI application analyzes the study and returns its result through STOW-RS, DICOM storage, a supported API, or another configured interface.
Validate and deliver the result. AI Conductor validates the returned result and delivers it in the format expected by the receiving system. That may include DICOM SR, SEG, Presentation State, or another supported DICOM object for PACS and viewers, or HL7 and FHIR content for EHR and reporting workflows.

This process allows healthcare organizations to distribute imaging data to the appropriate AI models, control how results return to clinical systems, and monitor the transaction from submission through delivery. Whether routing a study to a cloud-based stroke application or sending an on-premises lung nodule algorithm the required images and prior studies, AI Conductor supports scalable, standards-based orchestration across the imaging environment.

Because the routing and integration logic resides in the Unifier platform, an organization can add or change AI applications without rebuilding every connection between the AI application, PACS, VNA, EHR, and reporting system.

Learn more about AI Conductor or download the AI Conductor white paper.

Meet with a Dicom Systems workflow expert to review the PACS, VNA, EHR, viewers, and AI applications you need to connect and define the study-selection, routing, security, result-return, exception, and monitoring requirements.

Request a Meeting