Enabling SWF on FHIR

1. Proposed Workitem: Enabling SWF on FHIR

• Proposal Editor: Brian Bialecki
• Editor: Brian Bialecki
• Domain: Radiology

Summary

Access to information that resides in the Electronic Health Record (EHR) is critical to effective patient care throughout the Scheduled Workflow (SWF) process. The data that resides with FHIR resources can be enriched with additional information that the currently profiled SWF objects do not provide. For example a FHIR ServiceRequest provides benefits beyond a modality worklist query for orders in that in may provide the indications for the exam , time of the order or patient history which can be valuable to the technologist. Ensuring that radiologists have direct API access to EHR data to improve their reporting efficiencies and content using SMART on FHIR applications require the ImagingStudy resource not only exist, but is maintained.

DICOM has mechanisms, IOCM, to notify other entities of changes that can be monitored and leveraged to maintain the ImagingStudy resource. The ImagingStudy and ServiceRequest resources currently are at maturity level 4 in the latest release of FHIR. SWF has these changes documented in existing profiles using DICOM and HL7. The conversion of HL7v2 to FHIR has a published implementation guide. The protocols for exchanging, updating and removing FHIR resources exists.

Today, although these FHIR resources have matured, the inclusion in EHR systems is limited and as USCDI proceeds closer to inclusion of these resources in an upcoming version, the workflow to ensure these are created and maintained consistently is critical. IHE having participation from the community can ensure that these object remain consistent with the current SWF artifacts so that enriching their content with further EHR data is not only possible, is certain to be consistent across implementations.

These resources are a key stepping stone towards exchange of diagnostic imaging. While not all Health IT systems currently capture, maintain, or share information to access and view DICOM images, the ability to exchange these in methods such as your lab results or other FHIR health records are today, when available would significantly advance the ability for individuals and providers to access and use diagnostic images and data files utilizing broadly available technology and would support current implementations of DICOM image file access and use within or outside networks such as Carequality and the Trusted Exchange Framework (TEFCA).

2. The Problem

FHIR is the emerging clinical information standard that industry has adopted world-wide. Scheduled Workflow is the most widely adopted IHE profile throughout the world. However, it provides no guidance on implementing FHIR. HL7 provides minimal guidance with regards to implementing FHIR for Imaging.

This leaves vendors and users to develop their own implementations for deploying FHIR-based imaging workflows. The result is apparent. Each deployed site will be unique. Vendors will need to adopt and implement a unique configuration for every clinical site's deployed environment.

The key to enabling SWF on FHIR will be the creation and management of the ImagingStudy resource.

USCDI includes Level 2 Data Element updates to Diagnostic Imaging to include Imaging Reference. Community guidance will be essential in assisting Radiology practices to be compliant and vendors to ensure systems follow best practice standards for their implementations.

3. Key Use Case

The data that resides with FHIR resources can be enriched with additional information that the currently profiled SWF objects do not provide. For example a FHIR ServiceRequest provides benefits beyond a modality worklist query for orders in that in may provide the indications for the exam , time of the order or patient history which can be valuable to the technologist. Ensuring that radiologists have direct API access to EHR data to improve their reporting efficiencies and content using SMART on FHIR applications require the ImagingStudy resource not only exist, but is maintained.

The key use cases are:

• Create the ServiceRequest resource
• Update the ServiceRequest resource
• Host the ServiceRequest resource
• Search for existing ServiceRequest resources
• Create the ImagingStudy resource
• Update the ImagingStudy resource
• Host the ImagingStudy resource
• Search for existing ImagingStudy resources

For this workitem, the proposed scope is to be limited. Primary focus should be on the creation and management of the FHIR resources ServiceRequest and ImagingStudy. DICOM messaging will not be addressed with the exception references to existing parallel transactions or as event triggers.

USCDI includes Level 2 Data Element updates to Diagnostic Imaging to include Imaging Reference, Accession Number and Requested Procedure Identifier. Community guidance will be essential in assisting Radiology practices to be compliant and vendors to ensure systems follow best practice standards for their implementations.

4. Standards and Systems

Relevant Systems

• Image Manager
• ADT
• Department System Scheduler/Order Filler
• FHIR Resource Creator - DOC_SOURCE?
• FHIR Resource Repository - DOC_REPOSITORY?

Relevant Standards

• IHE Scheduled Workflow
• IHE Mobile access to Health Documents
• IHE IOCM
• HL7 FHIR
• DICOM
• USCDI

5. Discussion

A comprehensive inclusion of FHIR with the existing SWF is a major effort. This level of effort should not inhibit IHE Radiology from starting this project. This project proposal scope needs to be limited to a focused component of the overall transformation to a FHIR-based workflow. The initial proposed scope is to focus on enabling SWF on FHIR by ensuring there is a consistent process for creating and managing the basic FHIR resources required for SWF as well as USCDI compliance.

This project needs to collaborate with existing profiling work that is either in progress or completed by other IHE domains, for example "MHD" and HL7.

The joint DICOM WG20/HL7 Imaging Integration Working group has a workitem to address gaps with the HL7 v2/FHIR mapping relevant to imaging. An initial draft of the Imaging Orders mapping to FHIR is in the HL7 Confluence page "FHIR Imaging Service Request Resource Mapping"

IHE is the owner of SWF. IHE is the appropriate venue for incorporating FHIR with the profile. IHE has the most expertise on this subject.

Realizing that this is an extensive and most significant update requested of SWF, the level of effort should be constrained in the first cycle to basic resource creation and management.

Actors for creating and hosting FHIR resources are proposed. Potentially these would be DOC_SOURCE and DOC_REPOSITORY and how they are used to manage these transactions.

There has been some work to do basic testing and implantations at "FHIR Connectathons" and with SMART Imaging Access through the Argonaut Project, see the "draft specification."

NOTE: Current IMR Profile and proposed IDR Profile rely heavily on the existence of these resources whose creation and maintenance to this point IHE has been silent on.

Currently IMR falls short in discussing how to use ImagingStudy and ServiceRequest resources that may already exist in it's "RAD-141 transactions"

The creation of the storage transaction for IMR includes the Provide transactions already for ImagingStudy and ServiceRequest resources. "IMR Store Multimedia Report Bundle"

IMR profiled the "ServiceRequest" and "ImagingStudy" resources already

IMR Find Multimedia DiagnosticReports "RAD-143" provides bases and mechanisms that can be used for other imaging related resources.

6. Technical Approach

Expanding the concepts that were presented in Mobile access to Health Documents (MHD) to mirror transactions in SWF that are parallel and optional where ImagingStudy and ServiceRequest are created and managed. Also using concepts from IOCM to manage as well.

The diagrams below provide the actors and transactions in scope colored in yellow, while the actors and transactions colored in blue are for reference.

Sample ImagingStudy Diagram

---

Sample ServiceRequest Diagram

---

Actors (NEW)

• None

Actors Used (EXISTING)

• DSS/Order Filler
• Acquisition Modality
• Evidence Creator
• ImageManager/Archive
• Change Requester
• Image Display

Actors Referenced (EXISTING)

• Document Source
• Document Recipient
• Document Consumer
• Document Responder

Transactions (EXISTING)

• Provide Document Bundle ITI-65 - handles initial and updates
• Find Document Lists ITI-66
• Find Document References ITI-67
• Retrieve Document ITI-68

Transactions (TO DISCUSS)

• Delete Document

Profile

• Describe optional transactions as they complement the current RAD transactions in SWF
• Describe features and use cases where new object are different from RAD artifacts
• Describe when and how these resources are created, updated or deprecated
• Update SWF to add in these new options
• Update transaction examples to include new use cases

Decisions/Topics/Uncertainties

Do these transactions and actors get shown as stand alone or should they be discussed in the context of being used in conjunction with another actor, such as an Acquisition Modality as Document Consumer or a Document Recipient.

Is there a need for a new Delete Document transaction, or should these just be revoked or entered in error for ServiceRequest, but what about ImagingStudy?

Is the current Provide Document Bundle [ITI-65] transaction too general?

Credibility point

The Interoperability Standards Work Group (ISWG), a part of ONC’s Health Information Technology Advisory Committee recommended the USCDI Level 2 elements for inclusion in the final version 4. The Argonaut Project is working to identify and address critical next steps to include standards-based access to referenced DICOM images, which this profile directly support.

The FHIR ServiceRequest provides benefits beyond a modality worklist query for orders in that in may provide the indications for the exam , time of the order or patient history which can be valuable to the technologist. Ensuring that radiologists have direct API access to EHR data to improve their reporting efficiencies and content using SMART on FHIR applications require the ImagingStudy resource not only exist, but is maintained.

7. Support & Resources

The ACR and RSNA support this proposal.

It has been vetted and can be reviewed with DICOM WG20 and HL7 II.

The Argonaut Project using this general framework had approximately 30 different companies and institutions participating in their work.

Brian Bialecki from ACR plans to lead the editing and personal assistance from others has been offered.

There is a standard Friday ACR call slot that can be used to work on this effort.

8. Risks

SWF is a large profile and scope creep will be something that is actively monitored.

The Argonaut Project, as it is ongoing could find a roadblock.

What is the copyright IHE may want vs HL7 on any work done in Imaging ServiceRequest?

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

xx% for MUE yy% for MUE + optional Editor:

TBA SME/Champion:

TBA <typically with a technical editor, the Subject Matter Expert will bring clinical expertise; in the (unusual) case of a clinical editor, the SME will bring technical expertise>