Enabling SWF on FHIR

1. Proposed Workitem: Enabling SWF on FHIR

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

Summary

<Summarize in a few lines the existing problem . E.g. "It is difficult to monitor radiation dose for individual patients and almost impossible to assemble and compare such statistics for a site or a population.">

<Demonstrate in a line or two that the key integration features are available in existing standards. E.g. "DICOM has an SR format for radiation dose events and a protocol for exchanging them.">

<Summarize in a few lines how the problem could be solved. E.g. "A Radiation Dose profile could require compliant radiating devices to produce such reports and could define transactions to actors that collect, analyze and present such information.">

<Summarize in a line or two market interest & available resources. E.g. "Euratom and ACR have published guidelines requiring/encouraging dose tracking. Individuals from SFR are willing to participate in Profile development.">

<Summarize in a line or two why IHE would be a good venue to solve the problem. E.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">

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

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

<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) <List possible new actors> <List existing actors that may be given requirements in the Profile.> Transactions (NEW) <List 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.> <List existing transactions that may be used and which might need modification/extension.> 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.>