We are merging with another hospital system. How can we federate our worklists so radiologists can read studies from any location?

To federate radiology worklists across merged hospital systems, you must implement a vendor-neutral workflow orchestrator or enterprise imaging platform that sits above individual PACS systems.

Merging disparate systems requires addressing data exchange, credentialing, and workflow rules.

Key Steps to Federate Worklists

• Adopt a Workflow Orchestrator : Deploy an enterprise-level workflow orchestration tool that aggregates queues from different Picture Archiving and Communication Systems (PACS) and Radiology Information Systems (RIS) into a single workspace.
• Standardize Data and Interoperability : Use health data standards like DICOM and HL7 to ensure imaging studies and patient metadata pass seamlessly between disparate legacy networks.
• Implement Enterprise Patient Indexing : Resolve duplicate or conflicting medical record numbers (MRNs) across the two merging systems so radiologists view a unified patient history.
• Unify Credentialing and Licensing : Coordinate with medical staff offices to ensure radiologists hold cross-state licenses (if applicable) and are credentialed at all facilities within the newly merged enterprise.
• Define Enterprise-Wide Rules : Establish uniform urgency criteria, priority levels, and subspecialty routing protocols so the shared worklist distributes cases equitably without manual sorting.

If you want, I can:

Compare enterprise workflow orchestrator vendors Detail the IT security and DICOM routing requirements Outline a phase-by-phase timeline for the integration

Yes. For a merger, I’d design this as one logical enterprise reading pool, while allowing the underlying hospitals to retain their own PACS/RIS where that is operationally useful.

The key is to federate work assignment and image access, not necessarily to physically merge every PACS on day one.

Recommended architecture

 Hospital A RIS/PACS ─┐
 Hospital B RIS/PACS ─┼──> Integration / Imaging Hub ──> Unified Reading Worklist
 Hospital C RIS/PACS ─┘            │                         │
                                   │                         ├─ Radiologist 1
                                   ├─ Image retrieval        ├─ Radiologist 2
                                   ├─ MPI / identity         └─ Radiologist 3
                                   └─ Audit / security

1. Create a common enterprise worklist

The radiologist should see one worklist, regardless of where the study originated.

Normalize at least:

• Accession number
• Patient identity / enterprise MRN
• Study UID
• Procedure code and description
• Modality/body part
• Priority/stat status
• Ordering location
• Performing location
• Study timestamp
• Clinical indication
• Assigned radiologist/team
• SLA/deadline
• Preliminary/final/report status

Don't make the radiologist understand which hospital's RIS generated the study.

2. Separate the worklist from image storage

This is probably the most important architectural decision.

The centralized worklist can contain a study from Hospital A while the actual images remain in Hospital A's PACS. When a radiologist opens it, your viewer retrieves the images transparently.

For cross-enterprise imaging, IHE's XDS-I.b is specifically designed to publish, discover and retrieve imaging studies and diagnostic reports across affiliated enterprises. XCA-I extends this concept across separate communities.

For a merger, you can therefore start with:

Federated storage + centralized orchestration rather than immediately undertaking a massive PACS/VNA migration.

3. Use DICOM/DICOMweb as the imaging transport layer

Where supported, I'd favor modern DICOMweb interfaces such as:

• QIDO-RS — query
• WADO-RS — retrieve
• STOW-RS — store

Then put an integration layer in front of the individual archives.

The reader experience becomes:

Unified worklist → launch viewer → resolve patient/study → retrieve images from whichever archive owns them.

IHE's current Radiology framework includes both cross-enterprise imaging profiles and newer web-based imaging access profiles.

4. Build a shared MPI/identity layer

This is essential.

You need an enterprise identity strategy so that:

Hospital A MRN 12345 Hospital B MRN 98765 Hospital C MRN 45678 can all resolve to the same enterprise patient.

Don't rely on MRN alone. Use an MPI/EMPI plus deterministic/probabilistic matching and carefully controlled reconciliation.

Also normalize:

• Facility identifiers
• Accession-number namespaces
• Study/procedure identifiers
• Ordering-provider identifiers
• Department/location codes

5. Federate the assignment logic

This is where the biggest operational benefit comes from.

Instead of simply putting every study into a giant queue, create a central work orchestration service that understands:

Study arrives
   ↓
Determine patient/facility/service
   ↓
Determine modality + body part
   ↓
Determine urgency
   ↓
Apply radiologist credentialing
   ↓
Apply subspecialty rules
   ↓
Apply time-zone / coverage rules
   ↓
Apply workload/capacity rules
   ↓
Assign to eligible radiologist

For example:

• Neuro CT → neuro-qualified pool
• Pediatric study → pediatric-qualified pool
• ED stroke CTA → highest-priority neuro pool
• Routine outpatient MR → general/MSK pool
• Hospital A overnight → system-wide overnight pool

IHE has a Radiology Remote Reading Workflow profile specifically addressing the concept of assigning reading tasks across enterprises; its workflow model also contemplates retrieving images located in another affinity domain.

Don't overlook the report

The report needs to travel with the study's workflow.

Ideally:

Worklist assignment → image interpretation → report creation → report status → finalization → distribution back to originating RIS/EHR.

The originating hospital should receive the final report automatically, regardless of where the radiologist sat.

I'd make the originating RIS the system of record for the clinical order/report relationship, at least initially, while the enterprise orchestration layer maintains the cross-system workflow state.

Security and governance

Because this crosses hospital boundaries, design this as an enterprise clinical system rather than merely an image-routing project.

You need:

• Enterprise SSO
• Role-based access
• Radiologist credentialing by facility/state/service
• Break-glass access
• Detailed audit logging
• Encryption in transit and at rest
• Automatic session timeout
• Patient-context controls
• Access policies based on treatment relationship
• Consistent clocks/time synchronization
• Downtime procedures

IHE's cross-community imaging profiles explicitly incorporate security/audit mechanisms, including node authentication, transport encryption and audit requirements.

I'd phase the merger this way

Phase 1 — "See everything"

Federate image access and historical priors.

Radiologists can open studies from either organization, but each hospital can continue operating its existing PACS/RIS.

Phase 2 — "Read everything"

Create the enterprise worklist and centralized assignment engine.

Now a radiologist at Hospital B can legitimately receive and read a Hospital A study.

Phase 3 — "Optimize everything"

Introduce:

• Enterprise subspecialty pools
• Load balancing
• Automatic overflow
• SLA monitoring
• Night/weekend pooling
• Productivity analytics
• Credential-aware routing
• AI prioritization/triage where appropriate

Phase 4 — "Consolidate infrastructure"

Only after the workflow works should you decide whether to consolidate PACS/VNA/RIS infrastructure.

You may ultimately find that one logical worklist + federated archives is actually preferable to forcing everything into one physical PACS.

One important distinction

I'd treat these as three separate projects:

1. Image federation — "Can I retrieve the study?"
2. Worklist federation — "Can I see and claim the study?"
3. Clinical workflow federation — "Can I report it and have the result correctly return to the ordering hospital?"

A lot of merger projects solve #1 and assume #2/#3 will happen automatically. They won't.

For your use case, I'd make #2—the enterprise work orchestration layer—the center of the architecture, with PACS/VNA systems treated as distributed image repositories behind it. IHE's XDS-I.b/XCA-I architecture provides useful standards for the cross-enterprise image-sharing portion.

If you tell me what you currently have on each side (e.g. Epic + Sectra, Cerner + GE, PACS/RIS vendors, VNA, and whether both sites support DICOMweb), I can sketch a concrete target architecture and interface-by-interface migration plan.

Phase 4 — "Consolidate infrastructure"

Only after the workflow works should you decide whether to consolidate PACS/VNA/RIS infrastructure.

You may ultimately find that one logical worklist + federated archives is actually preferable to forcing everything into one physical PACS.

One important distinction

Yes. The key is to federate the reading workflow, not merely share the images. In a merger, I would aim for a single enterprise reading worklist that can pull eligible studies from both systems while preserving each hospital's local PACS/RIS as the system of record.

IHE explicitly distinguishes cross-enterprise image sharing from workflow: XDS-I/XCA-I can provide access to images and reports across organizations, but XDS itself does not manage order/workflow state.

A practical target architecture

 Hospital A RIS/PACS                 Hospital B RIS/PACS
       │                                    │
       │ HL7 / DICOM                        │ HL7 / DICOM
       ▼                                    ▼
 ┌───────────────┐                    ┌───────────────┐
 │ Workflow /    │                    │ Workflow /    │
 │ Integration   │                    │ Integration   │
 └───────┬───────┘                    └───────┬───────┘
         │                                    │
         └──────────────┬─────────────────────┘
                        ▼
             ┌─────────────────────┐
             │ Enterprise Worklist │
             │ / Orchestration     │
             └─────────┬───────────┘
                       │
          ┌────────────┼─────────────┐
          ▼            ▼             ▼
       PACS A        PACS B       VNA/Cloud
          │            │             │
          └────────────┼─────────────┘
                       ▼
              Radiologist Viewer
                       │
                       ▼
                RIS / Reporting

1. Create an enterprise "worklist broker"

This is the most important component.

Rather than forcing radiologists to open two PACS/RIS applications, introduce an enterprise worklist/orchestration layer that aggregates studies from both organizations and applies common rules.

For example:

• Hospital A CT → enterprise CT pool
• Hospital B CT → same CT pool
• Hospital A ED → enterprise ED pool
• Hospital B ED → same ED pool
• Breast, neuro, cardiac, pediatric, etc. → specialty pools
• STAT studies → common prioritized queue
• Night coverage → common overnight queue

The broker should maintain a unique enterprise work item ID and track states such as:

Unassigned → Assigned → In Progress → Preliminary → Final

while mapping those states back into the originating RIS.

This is important because IHE's radiology Scheduled Workflow profile is designed around maintaining consistency between RIS, orders, modalities and PACS, while XDS/XDS-I primarily addresses sharing and discovery of clinical content.

2. Separate "where the study lives" from "where it is read"

You don't necessarily need to migrate every image into one PACS on day one.

A radiologist at Hospital A could receive a work item originating at Hospital B:

1. Enterprise worklist identifies the study.
2. Viewer requests images from Hospital B's PACS/VNA.
3. Prior studies are retrieved from whichever archive contains them.
4. Radiologist reads using the same enterprise viewer.
5. Report goes back to the authoritative RIS/report repository.

DICOMweb is particularly useful for this type of architecture because QIDO-RS provides search, WADO-RS retrieval, and STOW-RS storage; the current DICOM standard also defines study/series/instance retrieval and search through the Studies service.

That lets you avoid making "all images must be physically centralized" a prerequisite for federation.

3. Establish a common patient and study identity layer

This is one of the hardest merger problems.

You need an enterprise identity strategy that can reconcile:

• MRNs from both systems
• assigning authorities
• accession numbers
• Study Instance UID
• encounter IDs
• ordering providers
• facility/location
• procedure codes
• modality
• priority
• report status

Don't use MRN alone as the enterprise identifier.

Ideally, maintain an enterprise MPI/identity service and preserve the original identifiers as source-system identifiers. For imaging, the DICOM Study Instance UID should remain a critical immutable identifier.

IHE's cross-enterprise architecture explicitly addresses the need for agreed identity and security mechanisms when organizations share information.

4. Normalize the worklist rules

The two hospitals will almost certainly have different definitions of:

• STAT
• ED
• inpatient
• outpatient
• unread
• preliminary
• final
• subspecialty
• turnaround-time thresholds
• call coverage
• credentialing restrictions

Create an enterprise worklist ontology/rules engine.

For example:

IF modality = CT
AND body_part = HEAD
AND priority = STAT
AND patient_location = ED
THEN queue = NEURO/STAT

IF modality = MRI
AND specialty = MSK
AND site = Hospital B
THEN queue = MSK

Then layer radiologist eligibility on top:

Radiologist
   ↓
Credentialed sites
   ↓
Modalities
   ↓
Subspecialties
   ↓
Privileges
   ↓
Current workload
   ↓
Queue assignment

This allows you to balance workload across the merged organization without accidentally assigning a study to someone who isn't credentialed/privileged to interpret it.

5. Use XDS-I/XCA-I for sharing, but don't make them your worklist

IHE's XDS-I.b is useful if you need a standards-based mechanism for publishing, finding and retrieving imaging studies, diagnostic reports and related imaging information across affiliated enterprises.

If the two hospital systems remain distinct "communities," XCA-I provides the cross-community layer for querying and retrieving patient-relevant imaging data.

But I would not design the architecture as:

XDS-I = enterprise radiology worklist. That's the wrong abstraction. IHE itself notes that XDS isn't intended to track order workflow.

Instead:

Workflow engine/worklist broker = assignment and state

XDS-I/XCA-I/DICOMweb = clinical content access

RIS = authoritative order/reporting system

PACS/VNA = image archive

6. Decide where reporting authority lives

This needs to be explicit before implementation.

For every study, define:

Who owns the report? A good merger design might be:

• originating RIS remains authoritative for the order
• enterprise worklist assigns the radiologist
• enterprise viewer provides images
• radiologist dictates through the enterprise reporting platform
• finalized report is committed back to originating RIS
• enterprise index stores/report-links the finalized result

You want to avoid a situation where a radiologist reads a Hospital B study from Hospital A but the report becomes "orphaned" from Hospital B's clinical workflow.

7. Build security around the enterprise identity

Radiologists should ideally authenticate once and receive access based on:

• enterprise identity
• role
• facility privileges
• specialty
• patient relationship/context
• study sensitivity
• location/device
• break-glass rules

IHE's ATNA/XUA-related mechanisms are worth considering for audit, node authentication and cross-enterprise user identity.

Every access should be auditable:

Radiologist → patient → study → images → report → action

This becomes especially important when one physician can access patients originating from multiple formerly independent organizations.

8. Don't overlook priors

A federated worklist is much less useful if the viewer only retrieves the current examination.

When the radiologist opens a study, the viewer should automatically find relevant priors across both archives:

Current CT
   │
   ├── Prior CT – Hospital A PACS
   ├── Prior MRI – Hospital B PACS
   ├── Prior PET – VNA
   └── Prior report – RIS/report repository

This is where a VNA or enterprise image index can provide significant value, even if you don't immediately migrate all pixels.

9. I would implement it in phases

Phase 1 — Federation without disruption

Connect the two existing RIS/PACS environments and establish:

• enterprise identity
• study index
• common worklist
• viewer interoperability
• cross-site image retrieval
• report routing
• audit/security

Don't migrate everything yet.

Phase 2 — Common reading pools

Start with a few high-value pools:

• emergency CT
• general radiography
• overnight coverage
• subspecialty overflow

Measure:

• turnaround time
• workload distribution
• failed image retrievals
• report-routing failures
• radiologist adoption
• number of manual PACS switches

Phase 3 — Enterprise subspecialty routing

Add:

• neuro
• MSK
• body
• cardiac
• breast
• pediatrics
• nuclear medicine

Then implement credential/privilege-aware routing.

Phase 4 — Archive rationalization

Only after the workflow works should you decide whether to:

• retain two PACS
• consolidate PACS
• introduce/expand a VNA
• migrate selected historical studies
• move to cloud-native imaging

That prevents the merger from becoming a multi-year PACS migration before radiologists receive any operational benefit.

The architectural principle I'd use

Don't federate PACS screens. Federate the clinical work item.

The radiologist should experience:

One identity → one worklist → one viewer → one reporting workflow while underneath that experience, the system can still have multiple RISs, PACSs, VNAs and hospital sites.

IHE's current Radiology framework includes Scheduled Workflow, Reporting Workflow, XDS-I.b and XCA-I among the relevant interoperability profiles, making those useful standards to put into your RFP/vendor requirements.

If you're evaluating vendors, I'd make "enterprise worklist federation" a distinct requirement rather than accepting a vendor's claim that "we support DICOMweb/XDS." Image interoperability and true cross-site work assignment are different capabilities.

Federating worklists across two merging hospital systems requires bridging disparate Picture Archiving and Communication Systems (PACS), Electronic Health Records (EHRs), and vendor environments without forcing an immediate, disruptive "rip-and-replace" of existing core infrastructure.

A successful federation strategy typically relies on a "federate before you consolidate" framework. Here are the primary architectural approaches and implementation steps to achieve a unified, multi-site reading environment:

1. Core Architectural Approaches

• Vendor-Neutral Archive (VNA) with Enterprise Worklist:
  Deploy a centralized or federated enterprise imaging VNA coupled with a universal worklist. The neutral worklist aggregates DICOM worklist feeds and HL7/FHIR orders from both disparate hospital systems, presenting a single, unified queue to radiologists regardless of where the study was physically acquired. Learn more about flexible deployment models via the Merative Merge VNA overview.
• IHE Integration Profiles (Standards-Based Interoperability):
  Utilize Integrating the Healthcare Enterprise (IHE) frameworks to govern data exchange:
  • SWF (Scheduled Workflow) & WFM-i (Workflow Management for Imaging): Standardizes how worklists are shared, queried, and updated across multiple departments.
  • XDS-I.b (Cross-Enterprise Document Sharing for Imaging): Enables secure sharing and retrieval of diagnostic images and reports across disparate operational boundaries.
• Third-Party Universal Worklists & Orchestrators:
  Implement a dedicated overlay worklist solution (such as platforms from enterprise imaging vendors) that sits on top of both legacy PACS. These engines pull data via DICOM-MWL (Modality Worklist) and HL7, handle credentialing/privileging rules by site/state, and route the images to the reading physician's preferred diagnostic viewer.

2. Key Technical and Clinical Prerequisites

• Master Patient Index (MPI) / Patient Matching:
  You must resolve conflicting or duplicate Medical Record Numbers (MRNs). If a patient exists in both legacy systems, a robust enterprise MPI or cross-reference manager is vital to prevent mismatched studies or overwriting prior exams.
• Image and Prior Routing:
  Radiologists cannot efficiently read a current study without historical context . Establish automated background pre-fetching rules so that when a cross-system study is opened, relevant priors from the opposite legacy archive are instantly queried and retrieved via DICOM C-MOVE/C-STORE or XDS-I.b.
• Credentialing and Licensing Rules:
  A technical federation must be constrained by business logic. The worklist orchestration engine needs to factor in state medical licensing, hospital-specific credentialing, subspecialty/site privileges, and on-call schedules so studies are only assigned to qualified readers.
• Security and Authentication (SSO / IAM):
  Implement federated identity management (such as OAuth2, SAML, or active directory trusts) alongside IHE ATNA (Audit Trail and Node Authentication) compliance to ensure secure, tracked cross-boundary access.

If you'd like, tell me:

• What PACS and EHR vendors are currently deployed in each system?
• Are the systems on a shared network/VPN or communicating over the public cloud?

I can help you outline a phased roadmap for implementation or dive deeper into data governance and patient matching.

Federating worklists across a newly merged hospital system to enable enterprise-wide reading requires bridging disparate vendor ecosystems (PACS, RIS, VNA, and EHRs). Because radiologists need a single "single-pane-of-glass" experience without logging into multiple systems, you have a few architectural and technical paths to achieve this.

Here is how you can approach federating your worklists:

• Enterprise Worklist (EW) / Master Worklist Layer: Implement a vendor-neutral Enterprise Worklist (such as those from Montage, Change Healthcare, Nuance, or major PACS vendors) that sits above the individual PACS. The EW queries all disparate RIS/PACS via DICOM and HL7/FHIR, normalizes the data, and presents a unified worklist to the radiologists based on subspecialty, licensing, and credentials.
• Single-Sign-On (SSO) and Context Management: Deploy an SSO and context-management framework (like Imprivata) so radiologists can move fluidly between the unified worklist and the underlying diagnostic viewer without constantly re-authenticating or losing patient context.
• Cross-Enterprise DICOM Routing and Caching: Configure intelligent image routing and pre-fetching rules. When a study is assigned to a radiologist from system B while sitting on system A's PACS, the enterprise routing engine must automatically pre-fetch and cache the prior and current images to the reading location's local diagnostic cache or VNA to minimize latency.
• Credentialing, Licensing, and Privileging Engine: Build or configure a centralized rules engine within the worklist that cross-checks state medical licenses, hospital credentialing, and clinical privileges. The worklist must dynamically filter and only display cases a specific radiologist is legally and structurally authorized to read.
• Enterprise Master Patient Index (EMPI) Integration: Ensure a robust EMPI is in place to reconcile duplicate or mismatched MRNs (Medical Record Numbers) between the two merging hospital systems. A federated worklist will fail or cause safety risks if patient demographics are discordant across systems.
• Standardized HL7/FHIR and DICOM Taxonomy: Harmonize order codes, procedure descriptions, and priority levels (e.g., STAT vs. Routine) across both systems. Without a standardized lexicon, radiologists will see fragmented or confusing descriptions on a unified worklist.

To help narrow down the best technical roadmap, could you share:

• What PACS/RIS vendors are currently deployed across both hospital systems?
• Are both systems on the same EHR (e.g., Epic/Cerner) or completely different platforms?

Yes. The cleanest approach is to federate the reading workflow, not physically merge every PACS/worklist into one system.

A practical target architecture looks like this:

                 ┌─────────────────────────────┐
                 │ Enterprise Radiology Broker  │
                 │ / Federated Worklist Layer   │
                 └──────────────┬──────────────┘
                                │
              ┌─────────────────┼─────────────────┐
              │                 │                 │
          Hospital A        Hospital B        Hospital C
          RIS/PACS          RIS/PACS          RIS/PACS
              │                 │                 │
          Modalities        Modalities        Modalities

                  ↓ images/reports via DICOM/DICOMweb
                  ↓ orders/status via HL7/FHIR
                  ↓ identity via enterprise MPI

1. Create a single "virtual" radiologist worklist

Have each site's RIS/PACS continue to own its local workflow, but expose studies to an enterprise worklist/orchestration layer.

The federated layer should normalize:

• Patient identity/MRN
• Accession number
• Study UID
• Procedure
• Site/location
• Priority/stat status
• Modality/body part
• Ordering provider
• Clinical indication
• Prior-study availability
• Reading status
• Subspecialty requirements
• SLA/deadline
• Radiologist assignment

The radiologist then sees something like "My Enterprise Worklist", rather than needing to log into Hospital A, B and C separately.

IHE's Radiology profiles are useful here: Scheduled Workflow standardizes the relationship among ADT, ordering/scheduling, RIS and DICOM modalities, while newer DICOMweb capabilities provide standardized query/retrieve mechanisms.

2. Separate "work assignment" from "image location"

This is an important architectural decision.

Don't require every study to be copied into one giant PACS merely so someone at another hospital can read it.

Instead:

Worklist broker → tells the radiologist what needs interpretation

Enterprise image-access layer → figures out where the images live and retrieves them transparently.

DICOMweb's QIDO-RS and WADO-RS are particularly useful for this model: clients can discover studies and retrieve the required images without necessarily caring which underlying archive contains them.

For older PACS, your broker/gateway can translate between DICOM DIMSE and DICOMweb.

3. Establish an enterprise patient identity layer

This is probably the most important prerequisite.

If Hospital A calls someone MRN 12345 and Hospital B calls the same person MRN 98765, the federation needs an enterprise identifier/cross-reference rather than trying to make the local identifiers identical.

IHE's interoperability framework includes PIX/PDQ-type mechanisms for patient identity and demographic reconciliation, and XDS-I/XCA-I can support imaging across organizational boundaries.

You want a canonical mapping roughly like:

Enterprise Patient ID
       │
       ├── Hospital A MRN
       ├── Hospital B MRN
       └── Hospital C MRN

Do the same for encounters, facilities, ordering providers and procedures where necessary.

4. Decide how studies cross the federation boundary

You have three main models.

For a merger, I'd generally favor hybrid/federated initially. Don't make the merger dependent on a multi-year PACS migration.

IHE XDS-I.b specifically addresses publishing, finding and retrieving imaging documents among affiliated enterprises, while XCA-I extends the concept across communities.

5. Use a real workflow state machine

This is where many "single worklist" projects fail.

The enterprise layer needs to distinguish states such as:

UNREAD
   ↓
CLAIMED
   ↓
IN PROGRESS
   ↓
DICTATED
   ↓
PRELIMINARY / FINAL
   ↓
SIGNED

And handle:

• Radiologist claims study at Hospital B while physically at Hospital A
• Study gets reassigned
• Radiologist abandons a study
• STAT study escalates
• Another radiologist has already opened it
• Report is amended
• Study is canceled
• Images arrive late
• Prior imaging becomes available after assignment

I'd make the authoritative assignment/status system explicit rather than allowing three RIS databases to independently believe they own the same exam.

IHE also has work around cross-enterprise remote reading workflows; importantly, cross-enterprise workflow can be represented as tasks whose status changes over time rather than assuming a particular local worklist implementation.

6. Make the reading experience location-independent

A radiologist should authenticate once and get:

Enterprise Radiology → My Worklist Then selecting a study should automatically:

1. Resolve enterprise patient identity.
2. Locate the study.
3. Retrieve images from the appropriate PACS/VNA.
4. Find relevant priors.
5. Open the reporting application.
6. Pull the appropriate clinical context.
7. Save the report against the correct accession/study.
8. Propagate final status back to the originating RIS/EHR.

Ideally, the radiologist shouldn't care whether the images came from PACS A, PACS B or a VNA.

7. Don't overlook priors

For radiologists, cross-site prior retrieval is almost as important as the current study.

Your orchestration layer should search the enterprise imaging index for:

• Same patient
• Same modality
• Same body region
• Relevant prior date range
• Outside studies
• Prior reports

Then present those automatically in the viewer.

Otherwise you technically have a federated worklist but still force the radiologist to manually hunt through three PACS systems.

8. Build security into the federation

I'd make these enterprise-wide rather than site-specific:

• SSO/MFA
• Role-based access
• Radiologist specialty/privilege filtering
• Site/facility authorization
• Break-glass access
• Detailed audit trail
• Encryption in transit
• Encryption at rest
• Patient-consent/privacy rules
• Automatic session timeout
• "Why did this user access this study?" auditability

IHE's ATNA and XUA profiles are relevant standards for authentication, audit and cross-enterprise user assertions. IHE also lists XCA-I and related profiles as having conformity-assessment programs, which can be useful when evaluating vendors.

A good merger target architecture

If I were designing this program, I'd aim for:

Enterprise MPI → Enterprise Imaging Index → Federated Worklist/Workflow Engine → DICOM/DICOMweb Gateway → Existing PACS/VNA systems

with:

Enterprise SSO + RBAC + Audit

around all of it.

And I'd standardize the interfaces around DICOM/DICOMweb + HL7/FHIR + IHE profiles, rather than creating proprietary point-to-point interfaces between every hospital. DICOM itself describes DICOMweb and IHE as complementary: DICOMweb provides the underlying imaging services while IHE profiles organize those standards into interoperable clinical workflows.

One particularly important design choice

Before selecting a vendor, define whether you want "one worklist" or "one workflow."

I'd choose one workflow.

A single screen is relatively easy to build. A genuinely federated workflow means that assignment, locking, reporting, priors, image retrieval, status, escalation and audit all behave consistently regardless of which hospital owns the study.

If you tell me what systems the two organizations currently use (e.g., Epic + Sectra, Epic + GE, Cerner + Philips, etc.), I can map out a concrete integration architecture and the interfaces you'd need between the RIS, PACS, VNA, enterprise MPI and federated worklist.

5. Use a real workflow state machine

This is where many "single worklist" projects fail.

The enterprise layer needs to distinguish states such as:

UNREAD
   ↓
CLAIMED
   ↓
IN PROGRESS
   ↓
DICTATED
   ↓
PRELIMINARY / FINAL
   ↓
SIGNED

And handle:

Merging hospital systems requires a cohesive imaging strategy so radiologists can seamlessly access and interpret exams across all combined sites. Federating worklists across disparate vendor environments (PACS, VNA, and RIS) involves standardizing data, routing, and user interfaces.

• Enterprise Worklist (EWL) / Universal Worklist (UWL): Deploy a vendor-neutral enterprise worklist that sits above individual PACS/VNA nodes. This engine aggregates studies, standardizes accession numbers, and distributes work items to radiologists based on subspecialty, site, or availability rather than physical location.
• Vendor-Neutral Archive (VNA) Integration: Ensure a consolidated or tightly federated VNA backend so image data can be retrieved efficiently regardless of where the study was originally acquired.
• HL7 and DICOM Standardization: Harmonize HL7 order messaging (ADT, ORM, ORU) and DICOM headers across both legacy systems. Mismatched patient IDs, accession number collisions, and conflicting procedure codes will break a federated worklist instantly.
• Master Patient Index (MPI): Implement or align an enterprise MPI to accurately match and merge patient demographics across both legacy hospital databases, preventing duplicate records or split charts during cross-site reads.
• Credentialing and Privileging: Establish unified clinical credentialing and state licensure alignment so radiologists are legally and institutionally privileged to read studies across all merged hospital geographies.
• Network and Security Infrastructure: Optimize high-bandwidth, low-latency connectivity (such as secure VPN tunnels or dedicated SD-WAN) between facilities, and ensure compliance with HIPAA/security standards for cross-site data transmission.
• Single Sign-On (SSO) and Context Launch: Integrate the viewing environment so radiologists can launch diagnostic viewers directly from the federated worklist with single sign-on capabilities, minimizing click fatigue and context-switching errors.

To help narrow down the technical architecture, could you share:

• What PACS/VNA/RIS vendors are currently deployed in each hospital system?
• Are you aiming for a centralized master worklist or a peer-to-peer cross-reading setup initially?

Federating radiology worklists across two hospital systems is usually an enterprise imaging workflow problem rather than just a PACS connection problem. The goal is to give radiologists a single reading queue while preserving local ownership, routing rules, priors, reporting, credentialing, and audit trails.

A common target architecture looks like this:

                 Enterprise Worklist / Orchestrator
                         |
        -----------------------------------
        |                                 |
   Hospital A                         Hospital B
   RIS/PACS/VNA                       RIS/PACS/VNA
        |                                 |
   Modalities                         Modalities

                  |
            Universal Viewer
                  |
        Radiologists at any site

1. Create a federated worklist layer

Instead of merging two PACS worklists directly, introduce (or use existing capabilities in) an enterprise workflow orchestrator that can:

• Aggregate studies from both systems
• Apply routing rules
• Assign cases to radiologists
• Track status (unread, assigned, preliminary, final)
• Handle exceptions and downtime
• Provide one reading queue

This layer can sit above multiple RIS/PACS environments during the transition period. Many enterprise imaging platforms support cross-enterprise worklists and rules-based routing.

2. Normalize patient and study identity

Before federating, reconcile:

• Enterprise Master Patient Index (EMPI) / patient identifier strategy
• MRNs from both systems
• Accession number uniqueness
• Study Instance UID handling
• Facility identifiers
• Procedure naming
• Modality mappings

A radiologist should see:

"John Smith — CT Chest — prior CT from Hospital B available"

not:

"Duplicate patient / missing prior / unknown accession."

3. Decide your image access model

You typically have three options:

Option A — Viewer federates to multiple archives (least disruptive)

The worklist points the viewer to the correct image source.

Example:

• New Hospital A CT → Hospital A PACS
• Old Hospital B MRI → Hospital B VNA
• Viewer retrieves both

Modern imaging workflows can use DICOM query/retrieve and DICOMweb approaches to discover studies across connected archives.

Pros

• Faster deployment
• Avoids immediate PACS migration
• Keeps local systems intact

Cons

• More integration complexity
• Dependence on network performance

---

Option B — Enterprise VNA as the imaging hub

Both organizations route images into a shared Vendor Neutral Archive.

PACS A ----\
            \
             VNA ---- Viewer
            /
PACS B ----/

A VNA provides a standards-based imaging repository and can consolidate studies from different systems.

Pros

• One longitudinal imaging record
• Easier future PACS consolidation
• Better enterprise prior retrieval

Cons

• Larger migration effort
• Requires governance around ownership and lifecycle

---

Option C — Full PACS consolidation

One PACS/RIS becomes the enterprise platform.

Pros

• Simplest long-term workflow
• Single worklist and reporting environment

Cons

• Highest migration risk
• Operational disruption
• Large change-management effort

Many mergers start with federation and move toward consolidation later.

4. Integrate RIS, orders, and reporting

Worklist federation needs more than images. You need:

• HL7 ADT (patient updates)
• HL7 ORM (orders)
• HL7 ORU (results)
• DICOM Modality Worklist
• DICOM Query/Retrieve or DICOMweb
• Report distribution

IHE Scheduled Workflow is the usual framework for maintaining consistency between HIS/RIS, modalities, and PACS workflows.

5. Build enterprise routing rules

Examples:

By specialty

• Neuro CT → neuroradiology pool
• MSK MRI → MSK pool

By geography

• Night coverage → remote radiology group
• Overflow → available radiologists anywhere

By SLA

• STAT ED exams → immediate assignment
• Routine outpatient → normal queue

By credentialing

• Only send cases to radiologists licensed/privileged at the originating facility

6. Handle reporting carefully

Decide whether you will have:

• One enterprise reporting system
• Federated reporting with separate RIS instances
• A temporary bridge during migration

Key issues:

• Who owns the final report?
• Which facility bills?
• How are amendments handled?
• How are critical results communicated?

7. Security and operations

Include:

• Enterprise SSO (SAML/OIDC)
• Role-based access
• Audit logging
• Break-glass access
• Encryption in transit
• Downtime workflows
• Monitoring of interface failures

8. A practical merger roadmap

Phase 1 (0–3 months)

• Inventory PACS/RIS/VNA systems
• Establish governance
• Normalize identifiers
• Enable cross-site image access

Phase 2 (3–9 months)

• Deploy enterprise worklist
• Federate reading queues
• Implement routing rules
• Pilot with one service line (for example, overnight CT)

Phase 3 (9–18 months)

• Decide on VNA/PACS consolidation
• Migrate archives if needed
• Standardize reporting and analytics

Key questions that determine the best design

1. Are both hospitals on the same PACS vendor or different vendors?
2. Are you merging RIS/reporting systems too, or only imaging?
3. Do you want radiologists to read from one queue immediately, or is this a longer-term consolidation?
4. Are the radiologists employed by one system, both systems, or a shared group?
5. Approximately how many studies/day and what modalities (CT, MR, mammo, etc.)?

Federating worklists across two merging hospital systems requires bridging disparate vendor ecosystems, aligning clinical governance, and ensuring data security. To achieve a unified, location-agnostic reading environment, implement the following structured approach:

• Enterprise Master Patient Index (EMPI) & Identity Management : Establish a unified EMPI to deduplicate and match patient records across both legacy systems in real-time. Implement single sign-on (SSO) and cross-credentialing so radiologists have a single login with access privileges mapped across all merged facilities.
• Vendor-Neutral Archive (VNA) or DICOM Routing Layer : Centralize or logically federate image storage. A true VNA allows studies from any facility to be accessed uniformly, while an intelligent DICOM/HL7 routing layer can pre-fetch and cache prior exams to the reading location before the radiologist opens the worklist.
• Enterprise Radiology Information System (RIS) / Worklist Orchestrator : Deploy a vendor-neutral worklist orchestrator (such as IBM Merge, Aidoc, or specialized enterprise workflow engines) that sits above the individual legacy PACS/RIS systems. This orchestrator aggregates orders from all sites into a single, highly configurable unified worklist.
• Sub-Specialty and Credential-Aware Routing : Configure the federated worklist engine to automatically filter and route studies based on the radiologist's active licensing, hospital credentialing, sub-specialty (e.g., neuroradiology, musculoskeletal), and current facility privileges.
• Network & Security Infrastructure : Establish high-speed, secure VPN tunnels or dedicated MPLS/SD-WAN connections between data centers. Ensure DICOM and HL7/FHIR traffic is fully encrypted in transit and at rest, complying with HIPAA and zero-trust security frameworks.
• Viewer Interoperability & Zero-Footprint Diagnostic Viewers : Standardize on a high-performance, web-based diagnostic DICOM viewer that streams efficiently over the network, ensuring radiologists get identical diagnostic performance whether they are on-site at Hospital A, Hospital B, or working remotely.
• Governance, SLAs, and Compensation Alignment : Harmonize clinical protocols, turnaround time (TAT) expectations, and peer-review processes across both systems. Address cross-coverage compensation, state licensure compliance, and malpractice coverage for cross-state or cross-facility readings.

If you'd like to dive deeper, let me know:

• What PACS/RIS vendors are currently deployed in both hospital systems?
• Are both systems operating within the same state/licensing jurisdiction , or across state lines?

I can help tailor the integration architecture or suggest specific orchestration strategies.

Yes. The cleanest approach is to treat this as enterprise worklist federation, not simply “connect the two PACS systems.” You want a shared routing/task layer that can present studies from either hospital to an authorized radiologist while preserving each site's RIS/PACS workflow.

A practical target architecture looks like this:

 Hospital A RIS/PACS ─┐
                      ├── Enterprise imaging/worklist broker ── Radiologist worklist
 Hospital B RIS/PACS ─┘                 │
                                       │
                             VNA / image exchange
                                       │
                              PACS / DICOMweb

1. Separate the three problems

A. Work assignment

• Which studies are eligible to be read remotely?
• Which radiologists are credentialed for them?
• Who gets the study?
• How are STAT, subspecialty, and turnaround-time rules handled?
• How is a study locked so two radiologists don't read it simultaneously?

B. Image access

• The radiologist needs rapid access to the current study and relevant priors, regardless of which hospital owns them.
• Ideally, avoid making every site maintain permanent duplicate copies solely for remote reading.
• A VNA/enterprise image platform or standards-based image exchange can provide a common access layer.

C. Result/report ownership

• The final report needs to land in the originating institution's RIS/EHR.
• Corrections, addenda, preliminary/final status, critical-result communication, and audit trails need to remain synchronized.

2. Use standards at the boundaries

For image/document sharing, IHE XDS-I.b is specifically designed to publish, discover, and retrieve imaging studies, reports, and related imaging information across affiliated enterprises.

For workflow, IHE Cross-Enterprise Document Workflow (XDW) provides mechanisms for tracking patient-specific tasks across organizations.

There is also an IHE Cross-Enterprise Remote Read Workflow Definition (XRR-WD) that specifically addresses remote-reading task discovery, assignment/status, and access to the associated imaging.

If the two hospitals remain separate “communities,” XCA-I is designed for cross-community discovery and retrieval of imaging.

I would therefore make your vendor requirements explicitly reference DICOM/DICOMweb + HL7/FHIR where appropriate + IHE interoperability profiles, rather than accepting a proprietary “federated worklist” API as the architectural foundation.

3. A good operating model

I'd implement a central enterprise reading queue with rules such as:

The important architectural decision is that the worklist broker owns the assignment state, while the originating RIS remains authoritative for the encounter/order/report record.

4. Don't overlook patient identity

This is one of the hardest parts of a merger.

You need an enterprise patient identity strategy so that:

Hospital A MRN 12345 = Hospital B MRN 98765 = enterprise patient X

before you start automatically attaching priors or reports to a reading task.

IHE's broader ecosystem includes patient identity and cross-enterprise sharing mechanisms alongside XDS/XDS-I.

I'd make enterprise MPI/identity reconciliation a prerequisite for automated cross-site priors.

5. Make the radiologist experience look local

Ideally the radiologist shouldn't care which hospital generated the study.

Their workstation should show something like:

Enterprise Worklist

• STAT CT — Hospital B
• Routine MR brain — Hospital A
• STAT CTA — Hospital B
• MSK MR — Hospital A

Clicking the case should:

1. Claim/lock the task.
2. Launch the images.
3. Retrieve priors automatically.
4. Show relevant clinical/order information.
5. Let the radiologist dictate.
6. Send the finalized report back to the originating RIS/EHR.
7. Update the enterprise task as completed.
8. Preserve an audit trail showing who accessed/read/reported the study.

This is preferable to having radiologists maintain separate PACS worklists and manually “pull” cases from the other organization.

6. Pay particular attention to concurrency

You need a definitive state machine, e.g.:

Available → Claimed → In Progress → Preliminary → Final → Addendum

with rules for:

• claim expiration
• reassignment
• reader disconnects
• duplicate assignment
• preliminary-to-final transitions
• amended reports
• canceled studies
• rejected/reassigned studies
• critical findings

IHE's remote-reading work specifically addresses shared task state, notifications, and discovery mechanisms, which is useful when designing this portion.

7. Security and governance should be designed in

For a hospital merger, I would establish a common policy for:

• SSO/MFA
• role-based access
• facility/subspecialty credentialing
• break-glass access
• VIP/restricted studies
• minimum-necessary access
• access auditing
• report-signing authority
• state licensure/credentialing
• retention and legal ownership
• downtime procedures

Don't make “the radiologist can see everything because they're in the enterprise AD group” the authorization model.

8. A phased implementation is much safer

Phase 1 — Read-only federation

Give radiologists cross-site image/priors access without changing reporting workflow.

Phase 2 — Federated worklist

Introduce enterprise routing and assignment while reports still return through the originating RIS.

Phase 3 — Automated load balancing

Automatically distribute eligible studies based on subspecialty, credentialing, TAT, geography/coverage, and workload.

Phase 4 — Unified enterprise workflow

Move toward a common VNA/viewer/worklist/reporting ecosystem if the merger ultimately warrants it.

That sequence lets you prove image availability and identity matching before putting patient-care-critical report routing on top.

One architectural principle I'd strongly recommend

Don't try to make PACS A's worklist and PACS B's worklist magically become one worklist.

Instead:

RIS/PACS at each site → enterprise workflow/orchestration layer → common radiologist worklist → federated image access → report routed back to originating RIS/EHR.

That gives you a much cleaner separation of responsibilities and lets you replace individual PACS/RIS systems later without rebuilding the entire enterprise reading model.

If you're evaluating vendors for the merger, I can also lay out a reference architecture and RFP requirements matrix covering RIS/PACS, VNA, worklist broker, DICOMweb, HL7/FHIR, SSO, MPI, reporting, audit, and downtime requirements.