Difference between revisions of "Remote Reporting for Imaging (TeleRadiology) - Proposal"

From IHE Wiki
Jump to navigation Jump to search
 
(6 intermediate revisions by the same user not shown)
Line 8: Line 8:
  
 
===Summary===
 
===Summary===
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 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
 
 
 
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==
 
==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 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, ther 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:
Line 42: Line 34:
 
The workflow document steps, then, could be:
 
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.
+
The primary use case is workload sharing read.
#'''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
 
# '''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:
+
For a workload sharing example, the specialty read of SPECT images is desacribed:
*'''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'''
+
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.
*Note that the remote read request can be done automatically based on local business rules:
+
 
**all studies acquired after certain time
+
The workflow document steps, then, could be:
**carrying certain procedure code (note that unifying procedure codes is out of scope)
+
# '''Remote Read Request:''' The Remote Read Requester, usually the Radiology department scheduler, has a SPECT study which requires a specialized Radiologist to perform the Read. The Remote Read Requester will collect relevant clinical documents, including the acquired SPECT images, tech notes, clinical summaries, and the original order.  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 Scheduler.  The read task locally will be removed from the local worklist.
**Include a certain urgency code (codes defined by HL7)
+
# '''Schedule Remote Read:''' Once the Remote Read Scheduler receives the request and document set, the Remote Read Scheduler will evaluate the Remote Read Request and, if it can meet the business constraints, assigns a reader(s) who are NM credentialed Radiologist.  The Remote Reade Scheduler will notify the requestor that the request has been accepted and scheduled.  The Read task will appear on the remote reader’s worklist.
**Peer review
+
# '''Remote Read:''' The Remote Reader's will select the task from their worklist.  The Remote Read Requester would be notified that the task is started.  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.  The worklist item is completed with the Remote Scheduler. 
**Remote Locum read
+
# '''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).
**VIP read (pseudo-anonymous)
+
'''Other Considerations'''
**Double Read
+
 
*or manually:
+
Uses cases for Workload sharing may include:
**Excessive read workload -for a site
+
* Specialty Read(SPECT example)
**Specialty Consultant/Second read – directed to a person or specialty pool  
+
* Site Loading (time-to-read exceeds threshold example)
'''Read Request Linkage'''
+
* Off hours coverage
* All Output documents linked via Accession Number and Accession Assigning Authority
+
* Double Read(mammography example)
* study needs to be removed from local reading list
+
* Consult(inconclusive read example)
'''Other 'ologies''''
+
* Blind Read(VIP example)
*Remote Read Workflow shall be extensible to other 'ologies' beyond Radiology
+
For Initiating the Remote Read Request
'''Specifically out of scope:'''
+
* The remote read request could be done automatically based on local business rules:
*unifying procedure codes across institutions
+
* all studies acquired after certain time
*protocoling studies across institutions (protocoling performed locally)
+
* 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==
 
==4. Standards and Systems==
Line 109: Line 101:
 
**D-SUB can act as a notification mechanism for XDW results available/completed  -OR- could be a trigger to receptionist to call Dr. XXX
 
**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==
 
==5. Technical Approach==
''<This section can be very short but include as much detail as you like.  The Technical Committee will flesh it out when doing the effort estimation.>''
 
 
''<Outline how the standards could be used/refined to solve the problems in the Use Cases.  The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>''
 
 
''<If a phased approach would make sense indicate some logical phases.  This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>''
 
 
 
===Existing actors===
 
===Existing actors===
''<Indicate what existing actors could be used or might be affected by the profile.>''
+
• See XDW, XDS-I and DSUB
 
 
 
===New actors===
 
===New actors===
''<List possible new actors>''
+
# Remote Read Requester
 
+
# Remote Read Scheduler
 +
# Remote Read Reader
 
===Existing transactions===
 
===Existing transactions===
''<Indicate how existing transactions might be used or might need to be extended.>''
+
• See XDW, XDS-I and DSUB
 
 
 
===New transactions (standards used)===
 
===New transactions (standards used)===
''<Describe possible new transactions (indicating what standards would likely be used for each.  Transaction diagrams are very helpful here.  Feel free to go into as much detail as seems useful.>''
+
None
 
 
 
===Impact on existing integration profiles===
 
===Impact on existing integration profiles===
''<Indicate how existing profiles might need to be modified.>''
+
None – New Profile is proposed.
  
 
===New integration profiles needed===
 
===New integration profiles needed===
''<Indicate what new profile(s) might need to be created.>''
+
''' Remote Read Workflow Definition (RRWD):''' 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.
  
===Breakdown of tasks that need to be accomplished===
+
==6. Support & Resources==
''<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>''
+
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.  
  
==6. Support & Resources==
+
PCC has expressed willingness to collaborate with IHE Rad.
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''
+
 
 +
VA has an extensive remote read need and would be a good candidate for working with on this profile.
  
''<Identify anyone who as indicated an interest in implementing/prototyping the Profile if it is published this cycle.>''
+
UK, Italy, the Netherlands and other regions within Europe who have deployed XDS, XDS-I and XDW.  
  
 
==7. Risks==
 
==7. Risks==
''<List technical or political risks that will need to be considered to successfully field the profile.>''
+
''As this profile is based on an established IHE profile, risks are minimal''
  
 
==8. Open Issues==
 
==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.>''
+
''none at this time''
  
 
==9. Tech Cmte Evaluation==
 
==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):
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):
:* 35% for ...
+
:* 35%
  
 
Responses to Issues:
 
Responses to Issues:
Line 162: Line 143:
  
 
Candidate Editor:
 
Candidate Editor:
: TBA
+
: Chris Lindop

Latest revision as of 09:30, 2 October 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

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

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, ther 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

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

  1. Remote Read Request: The Remote Read Requester, usually the Radiology department scheduler, has a SPECT study which requires a specialized Radiologist to perform the Read. The Remote Read Requester will collect relevant clinical documents, including the acquired SPECT images, tech notes, clinical summaries, and the original order. 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 Scheduler. The read task locally will be removed from the local worklist.
  2. Schedule Remote Read: Once the Remote Read Scheduler receives the request and document set, the Remote Read Scheduler will evaluate the Remote Read Request and, if it can meet the business constraints, assigns a reader(s) who are NM credentialed Radiologist. The Remote Reade Scheduler will notify the requestor that the request has been accepted and scheduled. The Read task will appear on the remote reader’s worklist.
  3. Remote Read: The Remote Reader's will select the task from their worklist. The Remote Read Requester would be notified that the task is started. 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. The worklist item is completed with the Remote Scheduler.
  4. 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).

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


5. Technical Approach

Existing actors

• See XDW, XDS-I and DSUB

New actors

  1. Remote Read Requester
  2. Remote Read Scheduler
  3. Remote Read Reader

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

Remote Read Workflow Definition (RRWD): 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 expressed willingness to 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

8. Open Issues

none at this time

9. Tech Cmte Evaluation

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

  • 35%

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Chris Lindop