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:
  • use case from ANAP in France – highlighted in red in picture.
  • 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
  • Compatible with XDS/XDS-I and XCA/XCA-I architecture
• XBeR-WD Workflow Definition
  • Sufficient for Image Referral
• DSUB for Notifications
  • 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.

Technical Details for an XDW Workflow Definition Profile:

1. Sharing Infrastructure:

A Workflow Definition Profile based on XDW, is a profile that identifies Tasks, Tasks Relationships and Participants involved in a specific workflow. XDW defines a multi-purpose tool (the Workflow Document) that enables Workflow Definition profile authors to specify additional rules applicable to specific workflows. General rules about the management/sharing of the Workflow Document itself are inherited fromby the XDW profile. XDW profile relies on well-established sharing infrastructures. These sharing infrastructures are of various types:

• Registry based document Sharing: XDS.b, PIX, PDQ;
• Point to Point Document Sharing: XDR
• Cross-Community Document Sharing XCA, XCPD.

All the three environment share for security and privacy: ATNA, ATNA RESTful Query, BPPC, XUA, SeR. Each one of these types of infrastructure may support the XDW workflow management infrastructure to take advantage from the whole set of profile identified to empower/support the document sharing itself (Security, Privacy, Auditing, Notification).

The picture below describes the scenario in which the XDW Workflow is managed by a Registry based infrastructure and shows how transactions of XDS.b, XDW and DSUB profiles operate.

Figure 1: XDW with a XDS/DSUB infrastructure

The DSUB profile provides a Notification Infrastructure that allows triggering notifications when a new document, characterized by specific metadata, is published. Workflow Participants can subscribe their participation to a specific instance of workflow, or they can be notified for any workflow document published that meets specific requirements.

The XDW approach simplifies the Actor requirements of workflow participant: those systems are required just to consume the content of a Workflow Document and update it in accordance to the workflow definition rules.

2. Task Definition:

In this section we will briefly describe main tasks identified by the Remote Read workflow. XDW profile is an integration profile that allows describing tasks across the border of enterprises, so it is out of scope for this Workflow Definition profile, the description to describe internal processes that allows to accomplish a task within an enterprise itself.

• Remote Read Request: this task allows a Read Requester to provide needed information to the Read Performer.
  • Required Task performed by the Read Requester actor.
  • INPUT:
    • Desirable: The original Referral from a distinct workflow (e.g. from the XBeR-WD workflow)
    • Desirable: The Scheduled procedure information (e.g. [RAD-4], HL7 OMI message content)
    • Desirable: Event Notification indicating clinically preformed procedure on the modality acquiring images
    • Required: URI for the path to the Image Manifest hosted by the XDS-I.b Image Document Source
  • OUTPUT:
    • Required: a Read Request document
    • Required: URI for the path to the Image Manifest referencing the acquired images and post-acquisition images and evidence documents, if any.
    • Desirable: the original imaging order or request
    • Optional: other relevant clinical content
  • Allowed TaskStatus:
    • COMPLETED: the task “born” completed or stays in this status if the output are revised.
    • FAILED: the task turn into this status if the task does not need to be completed anymore.
    • IN_PROGRESS: the task turn into an IN_PROGRESS status if output needs to be revised before the reading is requested
• Dispatch Remote Read: this task allows a Read Dispatcher actor to dispatch read requests to a set of selected Read Performer actors. It is out of scope in this profile for this task to define the rules on how Read Performers are selected.
  • Optional task performed by the remote read dispatcher actor.
  • INPUT:
    • Required: Read Request Document
  • OUTPUT:
    • none
  • Allowed taskStatus:
    • CREATED: if the request is available, but not assigned
    • READY: if the request has a Service Performer identified
    • COMPLETED: if the request is assigned, note that this task may be born completed
    • FAILED: if the Request can’t be assigned, cancelled, or changes the target for the dispatching.
• Perform Remote Read: this task allows a Read Performer actor to execute the reading requested.
  • Required task performed by the Read Performer
  • INPUT:
    • Required: a Read Request document
    • Required: URI for the path to the Image Manifest referencing the acquired images and post-acquisition images and evidence documents, if any.
    • Desirable: the original imaging order or request
    • Optional: other relevant clinical content
  • OUTPUT:
    • Required: Final Report
    • Required: Evidence Documents and additional images created while READ was performed
    • Optional: Preliminary Report
    • Optional: Addendum or Replacement of the Final Report
  • Allowed taskStatus:
    • READY: if the Dispatcher has completed the Dispatch task,
    • IN_PROGRESS: this task is added in this status when the Read Performer takes in charge the Read process
    • COMPLETED: this task is turned into status COMPLETED when the Final Report is created
    • EXITED: this task is turned into status EXITED when the Read Performer cannot complete the Read, but the Read may still be completed by another Performer.
    • FAILED: this task is turned into this status when no Performer can complete the Read.
• Read Result Acknowledged: this task allows a Read Requester to acknowledge and accept the receiving of the Final Report created by a Read Performer
  • Required task performed by the Read Requester
  • INPUT:
    • Required: Final Report
    • Required: Evidence Documents and additional images created while READ was performed
    • Optional: Preliminary Report
    • Optional: Addendum or Replacement of the Final Report
  • OUTPUT:
    • none required
  • Allowed taskStatus:
    • COMPLETED: this task is created COMPLETED when the Read Requester retrieves and processes the final Report.

6. Support & Resources

Several operational environments with XDS and XDS-I deployed including those of 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 and should continue to be involved.

US 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.

The development of this profile could proceed in four steps:

1. . December 7th-11th 2015 face to face meeting:, produce and review a complete draft (Vol. 1 and Vol. 3)
2. . February 15th-19th 2015, joint review between RAD and PCC in Germany at PCC Meeting
3. . March (?) 2015, review and deliver Public Comment version in IHE Radiology Technical Committee
4. . May (?) 2015, resolve comments and deliver Trial Implementation version in IHE Radiology Technical Committee.

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.

• During related work last year there was some confusion over publication calendar and participation of collaborators. How will that risk be resolved this time?

• BPMN is somewhat complex. Time will be needed to get everyone up to speed.

8. Open Issues

none at this time

• Breakdown of tasks section needed. Resources section includes a committee meeting calendar.

• Will XDW address Open Worklists too or just Assigned Worklists?
• During original development of XDS, questions of race conditions were dismissed under the premise that XDS is designed to be a distributed archive, not used for realtime workflow. As that point is addressed, what performance will be required of registries and repositories to ensure acceptable workflow management?
• [GE-Alexander Heck comment1] Allocating workload based on business rules by making decisions (requester or dispatcher) to assign remote read requests to 1:n performer might be challenging at a larger/national scale, especially with requester-specific or performer-specific business rules for remote reading (urgency, specialty, off hours, availability, etc.).
• [GE-Alexander Heck comment2] Like a worklist-based pool concept for reading tasks in a local department, a pool concept for remote reading tasks to be picked-up at enterprise level might help to avoid rule-based workload allocation at an affinity-domain-level.

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