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

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.

Sample ImagingStudy Diagram

Sample ServiceRequest Diagram

<This section describes the technical scope of the work and the proposed approach 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. The Technical Committee may revise/expand this section when doing the effort estimation.>

<If any context or "big picture" is needed to understand the transaction, actor and profile discussion below, that can be put here>

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

<The material below also serves as the breakdown of tasks that the technical committee will use to estimate the effort required to design, review and implement the profile. It helps a lot if it is reasonably complete/realistic.>

<READ PROPOSER HOMEWORK IN Proposal Effort Evaluation FOR GUIDANCE ON POPULATING THE FOLLOWING SECTIONS >

Actors (NEW)

• None

Actors (EXISTING)

• DSS/Order Filler
• Acquisition Modality
• Evidence Creator
• ImageManager/Archive
• Document Source
• Document Recipient
• Change Requester
• Document Consumer
• Image Display
• Document Responder

Transactions (NEW)

• Delete Document

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

Profile <Describe the main new profile chunks that will need to be written.> <List existing profiles that may need to be modified.> Decisions/Topics/Uncertainties <List key decisions that will need to be made, open issues, design problems, topics to discuss, and other potential areas of uncertainty> <Credibility point: A proposal for a profile with any degree of novelty should have items listed here. If there is nothing here, it is usually a sign that the proposal analysis and discussion has been incomplete.>

7. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

<Identify anyone who has indicated an interest in implementing/prototyping the Profile if it is published this cycle.>

8. Risks

<List real-world practical or political risks that could impede successfully fielding the profile.>

<Technical risks should be noted above under Uncertainties.>

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> <Delete this Category Templates line since your specific Profile Proposal page is no longer a template.>