Difference between revisions of "Cross-Enterprise Reporting for Imaging - Proposal"

From IHE Wiki
Jump to navigation Jump to search
Line 7: Line 7:
 
*Domain: Radiology [[Category:RAD]]
 
*Domain: Radiology [[Category:RAD]]
 
*Reference [ftp://ftp.ihe.net@ftp-proxy.ge.com/Radiology/iherad-2016/ProfileSelection/XDW_RRI_2015-07-013.docx XDW/XDS-I Implementation Guide - Cross-Enterprise Read of Images Prepared by Canada Infoway]
 
*Reference [ftp://ftp.ihe.net@ftp-proxy.ge.com/Radiology/iherad-2016/ProfileSelection/XDW_RRI_2015-07-013.docx XDW/XDS-I Implementation Guide - Cross-Enterprise Read of Images Prepared by Canada Infoway]
 +
 
===Summary===
 
===Summary===
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 proving the infrastructure framework for image and document exchange.
+
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 proving the infrastructure framework for image and document exchange. Cross-enterprise image sharing, beyond the initial step, has the capability to attain efficiencies and reduce cost at a macro-scale level:
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 departments by allowing any qualified radiologist in the community to read and report a study
* Improve throughput of radiology departments by allowing any qualified 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
* 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)
* 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
* Provide off-hours coverage by sharing radiologists' services off peak hours
+
While this proposal was originally accepted as part of the work scoped for 2015, the technical committee chose to complete a different profile. The profile developed by the technical committee is based on the DICOM UPS-WS standard. The intent of the proposal profile is to leverage the existing XDS infrastructure for workflow management (XDW).
 
 
While this proposal was originally accepted as part of the work scoped for 2015, the technical committee chose to complete a different profile. The profile developed by the technical committee is based on the DICOM UPS-WS standard. The intent of the original proposal profile is to leverage the existing XDS infrastructure for worflow management(XDW).
 
 
 
 
This requirement for utilizing XDS workflow is critical for minimizing the risk with large scale implementation projects based on XDS and extensibility with NON-DICOM workflows.
 
This requirement for utilizing XDS workflow is critical for minimizing the risk with large scale implementation projects based on XDS and extensibility with NON-DICOM workflows.
  
 
==2. The Problem==
 
==2. The Problem==
  
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 are 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.
+
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.
 
 
 
Cross-enterprise image sharing, beyond the initial step, has the capability to attain efficiencies and reduce cost at a macro-scale level:
 
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
+
* 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
+
* 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)
+
* 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
+
* Provide off-hours coverage by sharing radiologists' services off peak hours
 
+
IHE Radiology developed a remote read for imaging profile in 2015. However, it leverages the UPS-WS standards and not the XDW standards. The following include some of the risks and issues associated with the non-XDS method.
IHE Radiology developed a remote read for imaging profile in 2015. However, it leverages the UPS-WS standards and not the XDW standards.  The UPS-WS standards are new and unproven.  While it may eventually prove effective for a small number of systems, it lacks the scaleability of a regional workflow sharing environment.  
+
#. Unproven technology.  The UPS-WS standards are new and unproven.  Deploying a new technology which is unproven at this scale will add additional risks to develop a separate technology stack.
 +
#. Common TerminologyFor most image sharing deployments, a key element is to leverage a common vocabulary for information sharing.  This involves an expansive amount of carefully mapped local terminology to a common global vocabulary set.  Given that this is already part of the XDS registry model, the new profile would require the additional burden This process would require a separate method for managing this.
 +
#. Common Patient Identity.  A critical factor with community-based workflow is the proper patient identity management.  XDS has a proven method for patient identity management across domains.  This is not well managed in the enterprise-level remote read profile.
 +
#. NON-DICOM artifacts.  A critical element of reading is to enable the access to artifacts which are not DICOM-related.  XDS allows for all relevant information to be included.  This is not inherent to the enterprise remote read profile.  Non-imaging data in the enterprise profile is separate from the workflow and the images. Thus adding to the deployment complexity.
 +
#. Extensibility with non IHE Radiology Domains.  ITI has developed an extensible framework for workflow sharing (XDW).  This was ignored by IHE Radiology.  IHE PCC has leveraged this framework for developing many workflow profiles with success.  Some of these profiles do involve imaging modalities.  IHE is about collaboration.  Building a separate method other than what is already a profile specified in the ITI Technical Framework lacks the collaboration which IHE is built upon.  For implementers, this will require development of a separate method to handle a specific sub-specialty workflow solution.
  
 
==3. Key Use Case==
 
==3. Key Use Case==

Revision as of 12:54, 27 July 2015

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

Summary

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 proving the infrastructure framework for image and document exchange. 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 departments by allowing any qualified 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

While this proposal was originally accepted as part of the work scoped for 2015, the technical committee chose to complete a different profile. The profile developed by the technical committee is based on the DICOM UPS-WS standard. The intent of the proposal profile is to leverage the existing XDS infrastructure for workflow management (XDW). This requirement for utilizing XDS workflow is critical for minimizing the risk with large scale implementation projects based on XDS and extensibility with NON-DICOM workflows.

2. The Problem

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

IHE Radiology developed a remote read for imaging profile in 2015. However, it leverages the UPS-WS standards and not the XDW standards. The following include some of the risks and issues associated with the non-XDS method.

  1. . Unproven technology. The UPS-WS standards are new and unproven. Deploying a new technology which is unproven at this scale will add additional risks to develop a separate technology stack.
  2. . Common Terminology. For most image sharing deployments, a key element is to leverage a common vocabulary for information sharing. This involves an expansive amount of carefully mapped local terminology to a common global vocabulary set. Given that this is already part of the XDS registry model, the new profile would require the additional burden This process would require a separate method for managing this.
  3. . Common Patient Identity. A critical factor with community-based workflow is the proper patient identity management. XDS has a proven method for patient identity management across domains. This is not well managed in the enterprise-level remote read profile.
  4. . NON-DICOM artifacts. A critical element of reading is to enable the access to artifacts which are not DICOM-related. XDS allows for all relevant information to be included. This is not inherent to the enterprise remote read profile. Non-imaging data in the enterprise profile is separate from the workflow and the images. Thus adding to the deployment complexity.
  5. . Extensibility with non IHE Radiology Domains. ITI has developed an extensible framework for workflow sharing (XDW). This was ignored by IHE Radiology. IHE PCC has leveraged this framework for developing many workflow profiles with success. Some of these profiles do involve imaging modalities. IHE is about collaboration. Building a separate method other than what is already a profile specified in the ITI Technical Framework lacks the collaboration which IHE is built upon. For implementers, this will require development of a separate method to handle a specific sub-specialty workflow solution.

3. Key Use Case

The primary use case is workload sharing read.

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

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.

The workflow document steps, then, could be:

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.

The workflow document steps, then, could be:

  1. Remote Read Request: The Remote Read Requester, usually the department scheduler, has a study which requires a remote read to be performed. The Remote Read Requester will collect relevant clinical documents, including the acquired images, tech notes, clinical summaries, and the original request. The Remote Read Requester will initiate the Remote Read Request specifying the tasks to be performed and the business constraints and provide the request and the document set to the Remote Read Dispatcher.
  2. Dispatch Remote Read: Once the Remote Read Dispatcher receives the request and document set, the Remote Read Dispatcher will dispatch the Remote Read Request and, if a Read Performer can meet the business constraints, provides the request.
  3. Perform Remote Read: The Read Performer will select process the request local to their system. The work item may be on their local RIS/PACS or an independent system. The Final Report and any evidence documents are the output of this task. This task may be partitioned into several subtasks to perform the read. A possible set of subtasks could be as described in the IHE Reporting Workflow profile. However, would be considered out-of-scope for this profile. The Final Report is distributed back to the Remote Read Requestor.
  4. Read Complete: The Remote Read Requester retrieves the Report and completes the Workflow.

Other Considerations

Uses cases for Workload sharing may include:

  • Specialty Read(SPECT example)
  • Site Loading (time-to-read exceeds threshold example)
  • Off hours coverage
  • Double Read(mammography example)
  • Consult(inconclusive read example)
  • Blind Read(VIP example)

For Initiating the Remote Read Request

  • The remote read request could be done automatically based on local business rules:
  • all studies acquired after certain time
  • carrying certain procedure code (note that unifying procedure codes is out of scope)
  • Include a certain urgency code (codes defined by HL7)
  • Peer review
  • Remote Locum read
  • VIP read (pseudo-anonymous)
  • Double Read
  • or manually:
  • Excessive read workload -for a site
  • Specialty Consultant/Second read – directed to a person or specialty pool

Read Request Linkage

  • All Output documents linked via Accession Number and Accession Assigning Authority
  • study needs to be removed from local reading list

For Other 'ologies'

  • Remote Read Workflow shall be extensible to other 'ologies' beyond Radiology

Specifically out of scope:

  • unifying procedure codes across institutions
  • Cross institution Imaging Acquisition protocoling, (protocoling performed locally by the Imaging Acquisition Service)

4. Standards and Systems

Systems

  • RIS
  • PACS
  • VNA
  • Community Image Sharing Network

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
    • D-SUB 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

  1. Remote Read Requester
  2. Remote Read Dispatcher
  3. Remote Read Performer

Existing transactions

• See XDW, XDS-I and DSUB

New transactions (standards used)

None

Impact on existing integration profiles

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 Cross-Enterprise Document Workflow Integration profile.

6. Support & Resources

Canada Infoway SCWG-10 has led the development of this proposal and intends to collaborate with IHE on the development of the Remote Read Workflow Definition.

PCC has provided collaborate with IHE Rad.

VA has an extensive remote read need and would be a good candidate for working with on this profile.

UK, Italy, 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 IHE Radiology has no experience with XDW. An alternative development strategy may be to have PCC lead the development with RAD support.

8. Open Issues

none at this time

9. Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Cmte Bandwidth):

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Chris Lindop