Difference between revisions of "Remote Reporting for Imaging (TeleRadiology) - Proposal"
|Line 140:||Line 140:|
==6. Support & Resources==
==6. Support & Resources==
the proposal and to the .
the is .
Revision as of 20:34, 21 September 2014
1. Proposed Workitem: Remote Reporting for Imaging (TeleRadiology) Workflow Definition
- Proposal Editor: Chris Lindop on behalf of IHE Canada/Canada Infoway
- Editor: <Name of candidate Lead Editor for the Profile, if known>
- Date: N/A (Wiki keeps history)
- Version: N/A (Wiki keeps history)
- Domain: Radiology
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.
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
XDW has the Web Services infrastucture to meet this workflow need for web-based preporting. XDW uses workflow definition documents to specifiy the workflow description.
Reading Workflow is based on retired DICOM DMSE SOP Classes. This profile is a candidate for retirement. Recently DICOM has placed for ballot a RESTful Services version of Unified Procedure Step. These transactions are also Web compatible and would be a good candidate to compliment the XDW profile with a RESTful implementation.
Canada has the world's largest image sharing infrastructure. There is a great desire to implement a standards-based Remote Reading capability in this region of the world. Any region which leverages remote reading workflow would be a potential benefactor of this profile.
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. IHE PCC eReferral specifies a Workflow Definition (WD) for community referral. This WD does manage patient referrals for imaging. eReferral does not address the remote reading of images outside of the initial referral or sharing of priors. 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
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:
- Remote Read Request:The Remote Read Requester, usually the Radiology department scheduler, is triggered by an HL7 Order with a procedure code for SPECT. The Remote Read Requester will automatically collect relevant clinical documents, including Manifest of Acquired Images, Tech Notes, Clinical Summaries, and, will create the Remote Read Request and a workflow document containing the tasks to be performed. The set of documents will be pushed to the regional image sharing network for processing.
- Schedule Remote Read:Once the document set is received by the image sharing network, the Remote Read Scheduler evaluates the Remote Request Request and assigns a reader(s) who are NM credentialed Radiologist. The assignment is encapsulated in an HL7 procedure scheduled message to the Remote Reader's RIS/PACS. The Workflow document is updated.
- Remote Read:The Remote Reader's RIS/PACS receives the procedure scheduled message and initiates the Remote Read Task. The Final Report and any evidence documents (encapsulated in a New DICOM Manifest) are the output of this task. This task may be partitioned into several subtasks to perform the read. For each subtask, the workflow document may be updated and progress may be monitored in accordance with the terms of the BA and workflow document. The additional subtasks are as follows:
- Prep for Read: If step is neccessary, the Remote Read Preparer
- creates local Patient in database
- Retrieves remote images and relevant priors to local cache.
- Ready for Read: SPECT Read is placed on the Remote Reader(NM credentialed Radiologist) reading worklist
- Preliminary Read: Remote Reader(NM credentialed Radiologist) releases unsigned report
- Final Read: Remote Reader(NM credentialed Radiologist) releases Final Report to the Regional Image Sharing Network
- Prep for Read: If step is neccessary, the Remote Read Preparer
- Read Complete: The Remote Read Requester retrieves the Report and completes the Workflow. Billing system is notified(out-of-scope). Final Report distributed to patient's care team(out-of-scope).
Workload sharing can include:
- Specialty Read(SPECT example)
- Site Loading (time-to-read exceeds threshold example)
- Off hours coverage
Other specialized cases to consider include:
- Double Read(mammography example)
- Consult(inconclusive read example)
- Blind Read(VIP example)
Initiating the Remote Read Request
- Note that the remote read request can 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
- Remote Read Workflow shall be extensible to other 'ologies' beyond Radiology
Specifically out of scope:
- unifying procedure codes across institutions
- protocoling studies across institutions (protocoling performed locally)
4. Standards and Systems
- Community Image Sharing Network
- XDS-I for hosting Images and reports
- XDW underlying workflow profile framework
- Compatible with XDS/XDS-I architecture
- XDW currently does not support Cross community (XCA/XCA-I))
- Workflow is all within the same affinity domain
- This will be addressed in context with IHE ITI community
- XBeR-WD Workflow Definition
- Sufficient for Image Referral
- XDR/XDR-I for point to point
- As necessary
- 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
- UPS DICOM Webservices
- New DICOM Standard for workflow
5. Technical Approach
• DSS/Order Filler • Report Manager • Report Creator
• RAD-13 Procedure Updated: OMI to Include Status Update when Images are available
New transactions (standards used)
• RAD-X1 UPS-RS Query Reporting Worklist: UPS-RS version of RAD-46 • RAD-X2 UPS-RS Read Task Claimed: UPS-RS version of RAD-38 • RAD-X1 UPS-RS Read Task in-Progress: UPS-RS version of RAD-39 • RAD-X1 UPS-RS Read Task Completed: UPS-RS version of RAD-40 • RAD-X1 UPS-RS Read Completed: UPS-RS version of RAD-41
Impact on existing integration profiles
None – New Profiles are proposed.
New integration profiles needed
Imaging Read Workflow Definition (IRWD): 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 and the Proposed Reporting Workflow using RESTful Services.
Reporting Workflow using RESTful Services (RWRS): A workflow integration profile based on the Reporting Workflow Integration profile. The new profile will replace existing GP-MWL/GP-PPS transactions with the Unified Procedure Step – RESTful Services transaction. It would be fully compatible with the XDW-Workflow Definition Document for Imaging Reporting. Breakdown of tasks that need to be accomplished 1. Create the IRWD Content Profile 2. Create the RW-RS Integration Profile 3. Retire the Reporting Workflow Integration Profile If necessary, a phased approach, separating the two profiles as separate tasks and starting with the IRWD Content Profile designed for compatibility with XDW, followed by the RW-RS Integration Profile.
6. Support & Resources
Canada Infoway SCWG-10 has led the development of this proposal and intends to collaborate with IHE radiology with the development of the Imaging Read Workflow Definition. As Canada currently has a large scale XDS/XDS-I deployment, introducing the IRWD/XDW with the existing infrastructure is the intent. Canada deployment of Image sharing technologies is the largest and most mature globally. Other regional deployment groups have expressed interest in this proposal.
Adoption of the DICOM DIMSE-based GP-WL and GP-PPS transactions has been weak, to the extent where these SOP classes are currently retired by DICOM. The profile proposes to use the new DICOM RESTful Services for the Unified Procedure Step. It is anticipated that the DICOM RESTful Services will have a greated adoption rate. Many vendors today are now developing their software using RESTful services.
<List technical or political risks that will need to be considered to successfully field the profile.>
8. Open Issues
<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>
9. Tech Cmte Evaluation
<The technical committee will use this area to record details of the effort estimation, etc.>
Effort Evaluation (as a % of Tech Cmte Bandwidth):
- 35% for ...
Responses to Issues:
- See italics in Risk and Open Issue sections