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

Named in 32% of answers

The key is to federate the work assignment while leaving image custody distributed initially. A radiologist should see one logical worklist, select an exam, and have the viewer retrieve the images from whichever PACS/VNA owns them.

1. Establish a common identity layer first

Before merging worklists, normalize:

• Enterprise patient identifier/MPI
• Accession numbers and study identifiers
• Ordering provider/location
• Procedure and modality codes
• Priority/stat status
• Exam status
• Radiologist identity, credentials and privileges
• Site and service-line ownership

IHE's Scheduled Workflow.b specifically addresses continuity of patient/order information between ADT, ordering/scheduling, RIS, PACS and modalities, including enterprise patient identification.IHE Wiki

This is particularly important because a shared worklist with inconsistent patient identity is worse than two separate worklists.

2. Create a logical enterprise worklist

Rather than forcing both hospitals to replicate every study into a single PACS, put a workflow/routing layer in front of the existing RIS/PACS systems.

The worklist should be able to answer:

“What studies is this radiologist authorized and qualified to read right now?” rather than:

“What studies exist in Hospital A's RIS?” For each candidate exam, the federation layer should evaluate things such as:

• modality/body part
• STAT/routine priority
• subspecialty
• credentialing/licensure
• site privileges
• radiologist availability
• turnaround-time requirements
• language/coverage requirements
• reading location
• payer/service-line rules where relevant

IHE has actually defined a Cross-Enterprise Remote Reading Workflow model addressing discovery of reading tasks and sharing task status across enterprises. It describes Task Requester, Task Performer and Task Manager roles and can combine remote-reading workflow with XDS-I.b image access.IHE International

3. Keep image access separate from task assignment

This is an important architectural distinction.

Worklist federation:

RIS → enterprise workflow engine → radiologist

Image federation:

radiologist → enterprise viewer → PACS/VNA that owns study

That lets you avoid a massive day-one migration of historical images.

For cross-enterprise image discovery/access, IHE's XDS-I.b supports publishing, finding and retrieving imaging studies, reports and related imaging information across affiliated enterprises. XCA-I extends that concept across separate communities.IHE Wiki+1

For a modern implementation, I'd also want the viewer/PACS environment to support DICOMweb (particularly QIDO-RS/WADO-RS/STOW-RS where applicable), rather than designing the new architecture exclusively around older DICOM query/retrieve mechanisms.

4. Give the radiologist one reading experience

Ideally:

1. Radiologist authenticates once.
2. Federated worklist presents eligible studies from both systems.
3. Clicking a study launches the same diagnostic viewer.
4. Viewer retrieves images transparently from the source PACS/VNA.
5. Prior studies are automatically located across both organizations.
6. Radiologist dictates/signs the report.
7. Report and final status flow back to the authoritative RIS/EHR.
8. The enterprise worklist immediately reflects the new state.

The radiologist shouldn't have to know whether an exam originated at Hospital A or Hospital B.

5. Decide who owns the “truth”

This is one of the most important merger decisions.

For every data element, designate an authoritative source:

Don't allow two RISs to independently believe they own the same reading task. Otherwise you can get duplicate reads, stale statuses and difficult reconciliation.

6. Build strong failure handling

Design for partial outages from day one.

For example:

• Hospital B PACS unavailable → its exams remain visible but aren't assigned if images cannot be retrieved.
• Hospital A RIS unavailable → existing assignments continue and queue locally.
• Network interruption → reading workstation has a defined fallback.
• Duplicate study → deterministic deduplication rules.
• Patient merge → propagate reconciliation to all relevant imaging systems.
• Study correction/deletion → propagate the appropriate image-object changes.

IHE's Imaging Object Change Management work addresses the problem of distributed imaging copies being updated, corrected, split, combined or deleted.Digital Health Implementer Hub

7. Treat security as part of the workflow

You'll need enterprise-wide:

• SSO/MFA
• RBAC/ABAC
• radiologist credential/privilege verification
• site/service-line authorization
• break-glass access
• detailed audit logging
• encryption in transit and at rest
• separation of administrative versus clinical privileges
• appropriate retention and consent/privacy policies

IHE specifically identifies ATNA, user authentication/assertion and access control as complementary requirements around cross-enterprise imaging sharing.IHE International

A practical merger roadmap

I'd implement it in phases:

Phase 1 — Inventory and normalize

• Map both RIS/PACS/VNA architectures.
• Establish enterprise patient identity.
• Normalize procedure/modality/status terminology.
• Define ownership of every workflow state.

Phase 2 — Federated image access

• Make both image repositories accessible through a common viewer.
• Validate current and prior-study retrieval.
• Don't migrate everything yet.

Phase 3 — Federated worklist

• Introduce centralized routing/task management.
• Start with a few modalities/subspecialties.
• Keep local RIS worklists running as a safety net.

Phase 4 — Cross-site reading

• Enable radiologists at either hospital to receive appropriately credentialed exams from the other.
• Measure turnaround time, failed image retrieval, reassignment rate and report reconciliation.

Phase 5 — Optimization

• Automated subspecialty routing
• load balancing
• overnight/weekend coverage
• enterprise priors
• capacity management
• eventual PACS/VNA consolidation if economically and operationally justified

The architectural principle I'd emphasize to the merger team is:

Federate workflow first; consolidate storage only when there is a separate business and clinical reason to do so. That gives you cross-site reading much sooner and avoids making the entire merger dependent on a huge PACS migration.

Merging disparate imaging environments requires a structured technical and operational approach to unify queues while maintaining clinical continuity.intelerad.com

Core Strategies for Worklist Federation

• Vendor-Neutral Workflow Orchestration: Deploy an overlay workflow solution (such as systems described in the Intelerad Enterprise Workflow Analysis or Merge Workflow Orchestration ) that aggregates DICOM worklists, orders, and statuses across multiple legacy PACS/RIS nodes.merge.com+1
• Enterprise Master Patient Index (EMPI): Establish robust cross-system patient matching to ensure radiologists pull accurate, complete historical imaging and priors regardless of which legacy facility generated the study.smaart.net
• Standardized Clinical Taxonomy: Harmonize priority levels (Stat, Urgent, Routine), exam codes, and subspecialty tags so that the unified worklist interprets urgency identically across both legacy organizations.intelerad.com
• Credentialing and Privileging Cross-Walks: Align state licensure, hospital credentialing, and clinical privileges so radiologists are legally and structurally authorized to read cross-system studies.
• Security and Network Interoperability: Implement secure, encrypted VPNs or cloud-hybrid DICOM routing that complies with HIPAA while allowing zero-footprint diagnostic viewing from remote locations.merative.com+1

If you'd like to dive deeper, tell me:

• What PACS/RIS vendors are currently deployed across both systems?
• Are both organizations on the same Electronic Health Record (EHR) platform (e.g., Epic, Cerner) or separate ones?

I can provide a more tailored integration roadmap for your IT architecture.

A practical target architecture

I'd separate this into four functions:

1. Image access

• Either a shared VNA/image repository or federated PACS/VNA access.
• DICOM/DICOMweb for image retrieval.
• XDS-I.b/XCA-I can provide the cross-enterprise discovery layer. XDS-I.b is explicitly designed to share imaging studies, diagnostic reports and related information across affiliated care sites.IHE Wiki+1

2. Enterprise worklist

• Create a common pool of readable studies, rather than trying to replicate every local PACS worklist.
• Include accession, modality, body part, priority, referring service, originating facility, SLA, patient identifiers, prior availability, and required subspecialty.

3. Work assignment/claiming

• A central orchestration service owns the state: unread → assigned/claimed → in progress → preliminary → final.
• Radiologists can pull from the pool or receive assignments based on credentials, subspecialty, location, workload, and coverage rules.
• IHE's remote-reading workflow describes this kind of task-based model: a reading facility discovers/claims a workitem, retrieves the images, performs the read, and returns the report/status to the requesting organization.IHE International

4. Report/result synchronization

• The final report should return to the originating RIS/EHR and become part of that site's normal clinical record.
• Don't make the radiologist manually copy/paste reports between systems.

Don't make the PACS the federation layer

This is probably the most important architectural decision.

You can establish DICOM associations between PACS A and PACS B, but that tends to produce a brittle "network of PACS" rather than a true enterprise worklist.

Instead, I'd establish:

RIS/EHR → worklist/orchestration layer → PACS/VNA

The orchestration layer determines who should read what. The image layer determines where the pixels come from.

That distinction makes it much easier to merge additional hospitals later.

Patient identity is foundational

Before you expose cross-site studies, establish an enterprise patient identity strategy.

You need reliable mapping between:

• Hospital A MRN
• Hospital B MRN
• Enterprise patient ID
• accession numbers
• encounter identifiers
• study/series/SOP Instance UIDs

IHE's Scheduled Workflow profile is useful here because it addresses consistency of patient/order information across registration, RIS, modalities and PACS.IHE Wiki

I'd also establish explicit reconciliation rules for:

• duplicate patients
• merged/unmerged charts
• corrected demographics
• duplicate studies
• amended/corrected reports
• cancelled orders
• imported outside studies

IHE's Imaging Object Change Management profile is specifically intended to deal with changes to imaging objects across systems and helps prevent divergent copies from becoming inconsistent.IHE Wiki

Design the worklist around radiologist eligibility

A useful federated worklist might calculate:

Then rank eligible studies by something like:

That lets you do things such as:

"Any credentialed neuroradiologist in the health system can read these CT/MR studies." while still enforcing:

"Only radiologists credentialed at Hospital B may finalize Hospital B ED studies." Those are different concepts and should be represented separately in the system.

Security and governance

This is where mergers often get more complicated than the technology.

You'll want centralized:

• SSO/MFA
• role-based access control
• facility-specific privileges
• radiologist credentialing
• audit logging
• break-glass procedures
• consent/privacy rules
• minimum-necessary access
• attribution of every read to the actual radiologist
• retention and amendment policies

IHE's XDS ecosystem also includes security-related profiles such as ATNA and XUA for authentication/auditing and cross-enterprise user assertions.IHE Wiki

I'd make "can this radiologist legally/organizationally finalize this study?" a first-class authorization decision, rather than relying on the PACS to infer it.

A good migration strategy

I would avoid trying to make both existing environments fully identical on day one.

Phase 1 — Federated viewing

Connect the two environments so radiologists can find and retrieve each other's studies and priors.

Phase 2 — Federated worklist

Introduce a central worklist containing studies from both hospitals, while allowing the existing RIS/PACS workflows to continue operating.

Phase 3 — Cross-site reading

Allow selected modalities/service lines—e.g. overnight CT, stroke, neuroradiology—to be read across sites.

Phase 4 — Unified enterprise workflow

Move toward common rules for assignment, reporting, critical-result communication, QA, productivity and turnaround metrics.

This gives you a relatively low-risk way to prove the model before making the entire radiology operation dependent on it.

One important wrinkle: "federated worklist" vs. "shared worklist"

I'd decide which of these you actually want:

Federated: Each hospital retains its RIS/worklist, but eligible studies are exposed to other hospitals.

Centralized: One enterprise worklist becomes the source of truth for all reads.

Hybrid: Local RIS worklists remain authoritative, but a central orchestration engine dynamically exposes/assigns studies to other sites.

For a hospital merger, hybrid is usually the safest transition architecture. It lets you preserve each site's operational workflow while gradually creating a genuine enterprise radiology service.

IHE's work on remote reading is particularly aligned with this approach: the remote task can be claimed externally, while the reading facility can proxy the study into its own local PACS/worklist and conduct the actual interpretation using its familiar workflow.IHE International

If you're planning this at the architecture level, I can also lay out a reference architecture showing RIS, PACS, VNA, DICOMweb, HL7/FHIR, identity management, worklist broker, and reporting flows, including which system should be the system of record for each piece.

To help tailor this architecture, could you let me know:

• What PACS vendors (e.g., Epic Radiant, Change Healthcare, Sectra, Philips) are currently installed in each system?
• Are both systems on the same EHR platform , or are you managing a multi-EHR environment?

If you'd like, tell me:

• What PACS/VNA vendors are currently deployed in both systems?
• Are both systems on the same EHR (e.g., Epic across the board) or mixed?

I can provide a more tailored technical integration strategy.

Key Operational & Technical Steps

1. Master Patient Index (MPI) & Identity Matching: Resolve overlapping or duplicate patient medical record numbers (MRNs) across the two merging systems to prevent misidentified studies on the shared worklist.
2. Credentialing & Privilege Mapping: Build a rules engine into the federated worklist that cross-references a radiologist’s state licensure, hospital-specific privileging, and subspecialty credentials with the incoming study's site requirements.
3. Dictation and Reporting Integration: Ensure that voice recognition and reporting platforms (e.g., Nuance PowerScribe) are integrated so that regardless of where the study is interpreted, the final report routes back to the correct originating EHR and hospital entity.
4. Network & Security Infrastructure: Establish high-bandwidth, secure VPN tunnels or dedicated WAN links between disparate data centers, alongside robust zero-trust access controls and single sign-on (SSO) for remote or cross-site readers.

To help tailor this roadmap, could you share:

• Are both systems using the same PACS/EHR vendors (e.g., Epic + Epic / Cerner + Merge), or is it a heterogeneous environment?
• Do you plan to migrate all historical data into a single archive, or maintain federated local archives?

For the workflow itself, DICOM Unified Procedure Step (UPS/UPS-RS) is worth evaluating. IHE's AI Workflow profile, for example, uses UPS-RS as the underlying task/worklist service and supports pull, triggered-pull and push workflow models.IHE International

The important design decision is that the work item has one enterprise identity even though the images may remain in different PACS/VNA environments.

2. Put an orchestration layer between the RIS/PACSs

I'd generally recommend an enterprise radiology orchestration/worklist broker:

It can ingest orders/studies from both hospitals, normalize their statuses and expose one logical queue.

This is much more flexible than attempting to make PACS A and PACS B directly behave like one PACS.

For example:

CT abdomen arrives at Hospital B → enterprise engine identifies it as an unassigned CT → sees that the current queue has capacity → assigns it to a credentialed abdominal radiologist at Hospital A → viewer retrieves images from Hospital B → report is signed → result is sent back to Hospital B's RIS/EHR.

3. Separate worklist federation from image federation

These are related but different problems.

For images, use an enterprise image-access layer capable of querying/retrieving from both systems. DICOMweb gives you QIDO-RS for search, WADO-RS for retrieval and STOW-RS for storage; the current DICOMweb ecosystem also includes UPS-RS for workflow.DICOM Standard+1

You don't necessarily have to migrate all historical images immediately.

A useful transitional architecture is:

The viewer gets the study location from the enterprise index and retrieves it from whichever repository actually owns the study.

For cross-enterprise sharing, IHE XDS-I.b was specifically designed to publish, discover and retrieve imaging studies and diagnostic reports across affiliated care sites. IHE Wiki If the two hospital systems remain technically separate "communities," XCA-I is the corresponding IHE approach for querying/retrieving imaging across communities.IHE Wiki

4. Solve patient identity before anything else

This is one of the most important pieces of the merger.

You'll need an enterprise MPI/identity service that can establish:

Then make sure the image metadata, RIS orders, reports and viewer all use the appropriate cross-reference.

IHE explicitly describes pairing XDS-I with PIX/PIXm and PDQ/PDQm mechanisms for identifying the affinity-domain patient identifier.IHE International

Don't try to solve this with a giant one-time MRN conversion. Maintain authoritative cross-references and reconciliation workflows.

5. Define the routing rules centrally

This is where the merger creates real operational value.

For example:

You can therefore move from site-centric staffing to enterprise capacity management.

IHE's cross-enterprise imaging work has explicitly identified benefits such as allowing any qualified radiologist in a community to read a study, matching resources to demand, leveraging subspecialists across sites, and providing off-hours coverage.IHE Wiki+1

6. Don't forget report ownership and legal workflow

This is where many "single worklist" projects become problematic.

Before allowing unrestricted cross-site reading, define:

• Who is the interpreting physician of record?
• Which organization employs/credentials that radiologist?
• Which medical license applies to the patient's location?
• Who receives critical-result notifications?
• Where is the final report stored?
• Who can amend a report?
• What happens if the originating RIS is unavailable?
• Which facility's billing/coding workflow owns the interpretation?
• How are preliminary vs final interpretations handled?
• What happens to studies that cross organizational boundaries?

The technical system should enforce these policies rather than merely displaying everything to everyone.

7. Federate identity and security too

I'd make the radiologist authenticate once through the enterprise identity provider, then use role/attribute-based authorization.

For example:

IHE has established security profiles around audit trails/node authentication (ATNA), user assertions (XUA), privacy/consent and related mechanisms.IHE Wiki

You want a complete audit trail answering:

Who accessed which patient's images, from where, for what workflow item, and what did they do?

8. A good migration strategy

I would not attempt a "big bang" PACS/RIS merger.

Phase 1 — Inventory

Map both organizations':

• RIS
• PACS
• VNA/archive
• modalities
• DICOM interfaces
• HL7 interfaces
• viewer
• dictation/reporting
• EHR
• identity/MPI
• authentication
• radiologist privileges

Phase 2 — Federated viewing

Make every authorized radiologist able to retrieve studies and priors from either system.

Don't change work assignment yet.

Phase 3 — Enterprise worklist

Introduce the centralized worklist/orchestration layer and initially make it read-only/mirror mode against the existing RIS queues.

Compare:

• study counts
• status
• priority
• assignment
• turnaround time

Phase 4 — Controlled cross-site reading

Start with one use case—for example, overnight CT coverage.

Allow Hospital A radiologists to read Hospital B studies, with carefully defined credentialing and report routing.

Phase 5 — Enterprise load balancing

Once reliability is demonstrated, introduce:

• subspecialty routing
• overflow
• enterprise queues
• SLA-based prioritization
• automatic reassignment
• centralized QA metrics

Phase 6 — Archive consolidation, if desired

Only after workflow federation works should you decide whether consolidating PACS/VNA infrastructure actually provides enough benefit to justify the migration.

The architecture I'd favor

For a merger, I'd aim for:

HL7/FHIR + MPI → normalize patient/order context DICOM/UPS-RS → represent imaging workflow Enterprise worklist/orchestrator → assignment and routing DICOMweb/QIDO/WADO → federated image discovery/retrieval Universal viewer → one radiologist experience RIS/EHR → source-of-truth for clinical/reporting transactions IAM + audit → enterprise security and accountability XDS-I/XCA-I where appropriate → standards-based cross-community image sharing

The important architectural principle is federate first, consolidate later. You can give radiologists an enterprise-wide reading experience without immediately forcing two PACS, two RISs and two archives into a single system.

If you tell me which RIS/PACS/VNA systems the two hospitals currently use (e.g., Epic + GE, Cerner + Philips, Sectra, Visage, Agfa, Fujifilm, Intelerad, etc.), I can map this into a concrete target architecture and identify where the worklist broker, MPI, viewer, DICOMweb and HL7 interfaces should sit.

The important architectural principle is federate first, consolidate later. You can give radiologists an enterprise-wide reading experience without immediately forcing two PACS, two RISs and two archives into a single system.

If you tell me which RIS/PACS/VNA systems the two hospitals currently use (e.g., Epic + GE, Cerner + Philips, Sectra, Visage, Agfa, Fujifilm, Intelerad, etc.), I can map this into a concrete target architecture and identify where the worklist broker, MPI, viewer, DICOMweb and HL7 interfaces should sit.

IHE explicitly describes pairing XDS-I with PIX/PIXm and PDQ/PDQm mechanisms for identifying the affinity-domain patient identifier.IHE International

Don't try to solve this with a giant one-time MRN conversion. Maintain authoritative cross-references and reconciliation workflows.

5. Define the routing rules centrally

This is where the merger creates real operational value.

For example:

You can therefore move from site-centric staffing to enterprise capacity management.

IHE's cross-enterprise imaging work has explicitly identified benefits such as allowing any qualified radiologist in a community to read a study, matching resources to demand, leveraging subspecialists across sites, and providing off-hours coverage.

6. Don't forget report ownership and legal workflow