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

From IHE Wiki
Jump to navigation Jump to search
Line 44: Line 44:
 
*'''PACS'''
 
*'''PACS'''
 
*'''VNA'''
 
*'''VNA'''
*
+
*'''Community Image Sharing Netwrk'''
 +
 
 
===Standards===
 
===Standards===
 
*'''XDS-I''' for hosting Images and reports
 
*'''XDS-I''' for hosting Images and reports

Revision as of 11:27, 9 July 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

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. eReferral specifies a Workflow Definition 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 this 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)

3. Key Use Case

The primary use case is workload sharing. Workload Sharing could include:

  • Specialty Read(SPECT example)
  • Site Loading (time-to-read exceeds threshold example)

Other special cases to consider include:

  • Double Read(mammography example)
  • Consult(inconclusive read example)
  • Blind Read(VIP example)

A specialty read of SPECT images will be used for this example.

The community hospital has a NM acquisition system fully capable of acquiring SPECT Images, but lacks a credentialed NM Radiographer to read SPEC. 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.

  1. 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.
  2. Schedule Remote read:Once the document set is received by the image sharing network, the affinity domain scheduler evaluates the Remote Request Request and assigns a reader. The assignment is encapsulated in an HL7 procedure scheduled message to the Remote Reader's RIS/PACS. The Workflow document is updated.
  3. 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. The additional subtasks are as follows:
    1. Prep for Read creates local Patient in database, if necessary. Retrieves remote images and relevant priors to local cache.
    2. Unread or Ready for Read On reading Worklist
    3. Preliminary Unsigned report released
    4. Final Final Report released to the Regional Image Sharing Network
  4. Read Complete: The Remote Read Requester retrieves the Report and completes the Workflow. Billing system is notified. Final Report distributed to patient's care team.

4. Standards and Systems

Systems

  • RIS
  • PACS
  • VNA
  • Community Image Sharing Netwrk

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

<Include additional discussion or consider a few details which might be useful for the detailed proposal>

<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>

<What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>

<What are some of the risks or open issues to be addressed?>

<This is the brief proposal. Try to keep it to 1 or at most 2 pages>