Cross-Enterprise Reporting for Imaging - Proposal

1. Proposed Workitem: XRR-WD Cross-Enterprise Remote Reporting for Imaging Workflow Definition

• Proposal Editors:

Chris Lindop, Cezary.Klimczak, Ben Macerola, Canada Health Infoway (IHE Canada)

Mauro Zanardini, Claudio Saccavini, Arsenal.IT

Roberto Silverio, IHE Italy

Jean-Charles Dron, IHE France/Interop Santé

• Editors: Mauro Zanardini & Chris Lindop
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiology

Summary

This proposal introduces further flexibility in the deployment of having medical images interpreted (read) by a reading specialist who is not present at the site where the image study was acquired.

Cross-Enterprise or Community Diagnostic Image Sharing Services are increasingly part of the infrastructure landscape in the clinical community. Leading the way are IHE profiles and standards, such as XDS-I providing the infrastructure framework for cross-institutional access of the patient’s clinical images and associated reports. Many such deployments are in operation world-wide in countries such as Canada, Italy, France, England, China, Denmark, Netherlands, Germany, and Switzerland. These deployments have expanded or consider expanding in two major directions:

• The support of an increasing variety of clinical contents besides imaging such as patient summaries, laboratory results, and cardiology reports content taking advantage of the ability of their XDS and XCA infrastructures to convey such breadth of content.
• The ability to distribute the image diagnostics interpretation workload within a community of radiologists. Remote reading, has the capability to attain efficiencies and reduce cost at a macro-scale level.

While this proposal was originally accepted as part of the work scoped for 2015, the technical committee chose an approach for RRR-WF based on the DICOM UPS-RS standard (the TI version is not yet published. The intent of the present proposal is to complement the RRR-WF profile with a profile that leverages the existing XDS infrastructure for workflow management (XDW). The complementary nature of this proposal is further discussed below.

2. The Problem

2.1 The General Need

Cross-Enterprise or Community Diagnostic Image Sharing Repositories is a growing service internationally and has proven effective for sharing of previously acquired images and reports. The current IHE XDS-I.b infrastructure effectively supports this. However, there is a lack of standards for the remote read. Currently, to meet this need, HCIT suppliers have built proprietary systems with non-standard methods for managing this workflow. Proprietary methods limit the solution extensibility, in particular when larger scale regional and national deployment are targeted

Cross-enterprise image sharing, beyond the initial step, has the capability to attain efficiencies and reduce cost at a macro-scale level:

• Improve throughput of radiology depts by allowing any radiologist in the community to read and report a study
• Align the number of resources (staff, equipment) with the needs of the community as opposed to considering individual hospitals only
• Facilitate assignment of studies to physicians that are best qualified to read them (e.g., a SPECT expert may be leveraged across the community)
• Provide off-hours coverage by sharing radiologists' services off peak hours

The supporting use cases are further discussed in Section 3.

2.2 The Complementary Nature of this Proposal

IHE Radiology developed a remote read for imaging profile in 2015. However, RRR-WF leverages a central workflow task manager imposed by the UPS-RS standards. With the XDW/XDS based approach the workflow actors operate in a peer to peer mode by reusing an existing XDS infrastructure. This is one of the differences between the two approaches that makes the XDW/XDS approach complementary to the UPS-RS based one.

More specifically:

1. Reuse of Document Registry/Repository

The deployment of XDW reuses the same XDS Registry/Repositories than those used for the sharing of imaging and reports when XDS-I is already deployed. No additional task manager as a central server in the infrastructure is required to be deployed, as it would be the case of RR-RWF with a DICOM UPS-RS. In addition no new transactions beside the XDS transactions already supported by the organization sharing images and reports are needed for the support of an XDW based workflow. (versus the 10 new transactions for RRR-WF as specified by UPS-RS).

2. Common Patient Identity

A critical factor with community-based workflow is the proper reading community-wide patient identity management. As XDS/XDS-I deployments have a proven method for patient identity management across organizations sharing images and reports, not only the same protocol stack (PIX/PDQ transactions plus the associated policies) but the organizational integration are directly reused for the support of an XDW based workflow. A new integration in the context of UPS-RS, but more importantly the challenge to keep the new central UPS-RS task manager coordinated with the XDS Registry/Repository would be required and pose additional challenges.

3. Security and Privacy

The policies and their implementations with the ATNA, BPPC and XUA security and privacy profiles would require a significant additional deployment effort, when the remote read capability is deployed where an existing XDS Affinity domain exists. The communicating organizations may be provisioned more easily by reusing the existing node security certificates, addressing the privacy of XDW workflow information as would be addressed additional content. The attributes and references included in task items do require the specification of a distinct privacy implementation both in term of protocol stacks but also due to the provision of a UPS-RS task manager server.

4. Workflow Extensibility beyond Radiology

IHE ITI has developed an extensible framework for cross-institution workflow sharing (XDW). IHE PCC has leveraged this framework for developing many workflow definition profiles with success. In regional/national projects where radiology information and workflows are only a subset of the range of information and workflows to be supported among organizations, although functionally fit for the job, the use of an imaging specific base standard, DICOM UPS-RS, may pose some challenges. A more generic approach utilizing XDW/XDS workflow is critical for minimizing the risk with large scale implementation projects based on XDS. An approach to workflow that addresses the need of radiology remote read, but is consistent with other workflows already deployed (e.g. referrals) is important and may not have been full accounted for.

5. Linking of Workflows

In some cases, the output produced by a workflow triggers the initiation of another workflow. In XDW a workflow instance may use or trigger another XDW based workflow, this becoming linked by a cause / result relationship (e.g. The remote read workflow can be generated by another remote read workflow in case of a sequential consult read request triggered by the first radiologist).

6. Common Terminology

When a large scale image sharing deployment is in place, common vocabulary for imaging information sharing needs to be in pace (body parts, procedures, etc.). This involves an expansive amount of carefully mapped local terminology to a common global vocabulary set. When an XDS/XDS-I infrastructure is in place, the same value sets would be used both for acquired images, reading tasks and reports. Implementation consistency is easier to verify when all objects containing such value sets are under a single registry.

7. Alignment with Clinical and Administrative Use Cases of XDS-I

Specifically, the XDS-I use cases facilitated by the following XDS metadata attributes would be supported out of the box:

1. XDS Practice Setting Code – used in XDS-I to differentiate between radiology, cardiology, breast screening, and other settings/specialties. Similarly, in the context of remote reads, this code would be used to distinguish radiology remote reading requests in one setting from those in other settings. One group of remote readers may be focused on interpreting general-purpose radiology exams, while other may be performing breast screening reads exclusively.
2. XDS Healthcare Facility Type Code – used in XDS-I to distinguish hospital-generated exams from outpatient-facility (clinic) exams, etc. Similarly, in the context of remote reads, this code would allow, for example, separation of remote reading requests coming from hospitals in the region from those coming from the region’s clinics. Thus, various classes of remote readers could easily target different facility types in the region.
3. XDS Confidentiality Code – often used in XDS-I to hide VIP exams (XDS Registry automatically filtering them out) from the ordinary radiologist user. In the context of remote reads, this code would be used to appropriately mark the confidentiality level of each reading request and thus allow different readers to see a different set of exams in their reading worklists, depending on the role of the reader.

8. Remote Reading Worklist

The remote read requesters and the remote read performers are enterprise-level systems such as RIS and PACS. These systems are designed to manage the local acquisition and reading workflow, in which that often have some form of local worklist presented to radiologists within their enterprise. How external remotely requested reading tasks will be presented merged into the product local worklist, or in a dedicated external worklist is an implementation choice that should be left to the site along with the system vendor. Because XDW addresses the cross-enterprise side of the remote read activities, no concept of worklist is presented, only that of task with status changes as the workflow progresses.

9. Dynamic Model of Tasks

Given the dynamic nature of reading tasks, the subject referenced is commonly known as 'activity data' which are data still in high fluency. To ensure that the dynamics of all integrated systems is respected and the potential of using information that may be outdated is avoided, a “task-centric” pub/sub model should be used. This is proposed with the joint use of XDS/XDW and of the DSUB Profile. A DSUB Notification Broker is grouped with the XDS Document Registry and a DSUB Notification Recipient grouped with the Requester and Performer. This ensures that the XDS methodology (publish/query) remains the robust foundation, but that the most up-to-date information (non-patient centric notifications) is always available to Task Performers and Requester that have a business role to assume.

It is important to recognize that the RRR-WF profile (based on DICOM UPS-RS) has been designed to operate in conjunction with three mechanisms to access the data used in the reading task and for the Task Requester to access the resulting report.

The RRR-WF profile (based on DICOM UPS-RS) appears well optimized for use in conjunction with the DICOM Web and DICOM classic as mechanism for the Task Performer to access the data used in the reading task and for the Task Requester to access the resulting report.

However, the above challenges demonstrate that when the Remote Read workflow is used in conjunction with the XDS/XDS-I as mechanism for the Task Performer to access the data used in the reading task and for the Task Requester to access the resulting report, a Remote Read Profile based on XDW/XDS has considerable advantages. It is the objective of this proposal to complement the RRR-WF profile with such a new “XRR-WD” profile.

3. Key Use Case

The primary use case is workload sharing read.

For a workload sharing example, the specialty read of SPECT images is described:

The community hospital has a NM acquisition system fully capable of acquiring SPECT Images, but lacks a credentialed NM Radiographer to read SPECT. Per the institutional business rules, all SPECT images will require a NM credentialed Radiologist to perform the read. The regional image sharing network has NM credentialed Radiologists. Based on the institutional business rules, this study meets the criteria for Remote Read.

Other examples may include MR Neuroradiology reading or a cardiac stroke consultation.

For consistency with RRR-WF, it is proposed to cover the following workflow variants:

1. Assigned (Push) workflow with the following workflow steps:
   1. Remote Read Request: The Remote Read Requester initiates the Remote Read Request specifying the reading task to be performed and provide the references to images and relevant clinical documents to one or more Remote Read Performers of its choice.
   2. Perform Remote Read: The first Read Performer that claims the request is responsible to process the read request. Other Read Performer may be notified that the task has already been claimed. The Final/Intermediate Report and any evidence documents as output of this task are referenced and the Remote Read Requester notified.
   3. Read Complete: The Remote Read Requester retrieves the Report and completes the Workflow. The Read performer is notified.
2. Self-selected (Pull) Workflow with the following workflow steps:
   1. Remote Read Request: The Remote Read Requester initiates the Remote Read Request specifying the reading task to be performed and provide the references to images and relevant clinical documents to a Remote Read Dispatcher of its choice.
   2. Dispatch Remote Read: Once the Remote Read Dispatcher receives the request, the Remote Read Dispatcher will dispatch the Remote Read Request to one or more Read Performer that can meet the business constraints.
   3. Perform Remote Read: The first Read Performer that claims the request is responsible to process the read request. It notifies the Remote Read Dispatcher and other Read Performers that the task has already been claimed. The Final/Intermediate Report and any evidence documents as output of this task are referenced and the Remote Read Requester and the Remote Read Dispatcher are notified.
   4. Read Complete: The Remote Read Requester retrieves the Report and completes the Workflow. The Read Performer and the Read Dispatcher are notified.

Other Considerations Uses cases for Workload sharing may include: • Site Loading (time-to-read exceeds threshold example) • Off hours coverage • Double Read (mammography example) • Consult (inconclusive read example) Read Request Linkage • All Output documents linked via Accession Number and Accession Assigning Authority For Other 'ologies': • Remote Read Workflow shall be extensible to other 'ologies' beyond Radiology. For example, for vascular stroke support in existing XDS-I infrastructures: o use case from ANAP in France – highlighted in red in picture. o A similar use case is needed in the Veneto region in Italy. Specifically out of scope: • unifying procedure codes across institutions • Cross institution Imaging Acquisition protocoling, (protocoling performed locally by the Imaging Acquisition Service) Transaction Flow and Performance: • For an Assigned (Push) workflow, the XDW workflow document will be updated 5 times for a complete workflow. • For a Self-selected (Pull) Workflow, the XDW workflow document will be updated 6 times for a complete workflow. • Each step in the workflow may require a query or notification, retrieve, provide and register (updated document).

4. Standards and Systems

Systems • RIS • PACS • EMRs/HIS • VNA • Community Image Sharing Network and Regional/National HIEs • Patient Identification Management (e.g. MPI)

Standards • XDS-I for hosting Images and reports • XDW underlying workflow profile framework o Compatible with XDS/XDS-I and XCA/XCA-I architecture • XBeR-WD Workflow Definition o Sufficient for Image Referral • DSUB for Notifications o DSUB can act as a notification mechanism for XDW results available/completed -OR- could be a trigger to receptionist to call Dr. XXX

 

5. Technical Approach

Existing actors • • See XDW, XDS-I and DSUB New actors • Remote Read Requester • Remote Read Dispatcher • Remote Read Performer

Existing transactions • See XDW, XDS-I and DSUB

New transactions (standards used) • None Impact on existing integration profiles • This new profile XRR-WD • None – New Profile is proposed. New integration profiles needed Cross-Enterprise Remote Read Workflow Definition (XRR-WD): A content profile based on the Workflow Definition Template. This content profile captures, in a document, the Imaging Read Workflow definition for remote reading. The document is intended for use by the XDW Cross-Enterprise Document Workflow profile. This profile will be the first Workflow Definition based on XDW that will provide a structured format for the workflow definition itself. This will be based on “Workflow Definition BPMN” guidelines (a White Paper drafted by the IHE PCC Domain). Such a structured representation supports automation of several important efforts, including: • Generation of workflow documentation from the structured definition, • Construction of conformance requirements for workflow participants, • Development of test tools and simulators, • Implementation of and integration with workflow participants. .

6. Support & Resources

Several operational environments with XDS and XDS-I deployed including Canada Health Infoway have led the development of this proposal and intends to collaborate with IHE on the development of the Remote Read Workflow Definition (XRR-WD). PCC has collaborated with IHE Rad. VA has an extensive remote read need and would be a good candidate for working with on this profile. France, Italy, UK, Austria, the Netherlands and other regions within Europe who have deployed XDS, XDS-I and XDW.

7. Risks

As this profile is based on an established IHE profile, risks are minimal. It would be useful to engage the collaboration of IHE PCC, given their experience with XDW workflow definitions and the recent white paper they produced.

8. Open Issues

none at this time

9. Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Committee Bandwidth): Responses to Issues: See italics in Risk and Open Issue sections Candidate Editors: Mauro Zanardini, Chris Lindop