CDS on FHIR
Return to Clinical Decision Support Work Group
Project Co-Sponsors:
- Clinical Quality Information Work Group
- FHIR Management Group
- Service Oriented Architecture Work Group
Project Information
This project will investigate the use of FHIR in a Clinical Decision Support context with the goal of identifying best practices for the use of FHIR in support of the primary use cases of Clinical Decision Support, namely 1) Sharing Clinical Decision Support (CDS) knowledge artifacts, and 2) Obtaining Clinical Decision Support guidance as part of a clinical workflow.
In addition the project will seek to ensure, and as much as possible define, support for repository functions such as searching available knowledge modules and retrieving data requirements for a module or set of modules.
The project will also be coordinated with the eCQM FHIR-Profiles project sponsored by the Clinical Quality Information Work Group to ensure consistent approach and, as much as possible, the use of common resources and profiles.
The project will create a Universal Realm FHIR Implementation Guide, which was balloted for comment in the September 2015 cycle. We are currently incorporating changes from the reconciled ballot comments.
We are also excited to be participating in FHIR Connectathon 11. We are co-coordinating the CDS-on-FHIR Track with the CDS-Hooks group.
The latest version of the CDS-on-FHIR IG is available on the FHIR Continuous Build.
Meeting Information
The CDS on FHIR project subteam meets weekly: Conference call coordinates
Status
All comments from the Sept 2015 ballot cycle have been disposed, and we are currently incorporating changes into the IG. In particular, we are submitting the following new resource proposals:
- ModuleMetadata
- ModuleDefinition
- Library
- DecisionSupportServiceModule
- DecisionSupportRule
- OrderSet
- GuidanceResponse
Project Documents
Informative Content
This project has a github repository for tooling, supporting documentation, and other informative content that will not be included in the ballot:
In particular, overview documentation and a slide deck can be found here:
A simple .NET prototype implementation of a FHIR-Server that provides scaffolding for the CDS guidance operations can be found here:
Note that the above implementation is based on the development branch of the Spark Server, which is using the May ballot of FHIR:
FHIR Implementation Guide
The implementation guide contents are part of the FHIR continuous build, and can be found here:
Clinical Quality Improvement Framework Implementation Guide
Potential Issues Identified for FHIR Resources to be Officially Balloted in the Future
Contraindication
Should the name be something that allows non-true contraindications (e.g., interaction warnings)? E.g., Warning, or ContraindicationOrWarning. The severity attribute may be able to deal with this (e.g., absolute vs. relative contraindication). Per Lloyd, Or typical not in name. Warning in OperationOutcome so ambiguous.
What is the use case for this Resource? It seems like the primary one would be for an evaluation result by a medication CDS system (e.g., drug-drug, duplicate Rx, etc.). Occasionally might be an in-person documentation (e.g., through medication review). Other data points include evidence base, etc. But this could potentially be handled by extensions, either vendor-specific or common. May be worth getting vendors engaged.
The severity levels do not correspond to the richer levels provided by several commercial knowledge vendors.
May be the case that Communication should be the focus of the drug interaction warning, not Contraindication. Lloyd: this would be referenced by communication.
Contraindication Reason
In addition to the "implicated" element, the Contraindication resource should have a "reason" element indicating the reason for the contraindication. (This should be submitted as a FHIR Tracker Item)
