This wiki has undergone a migration to Confluence found Here


From HL7Wiki
Revision as of 06:34, 9 July 2015 by Bryn rhodes (talk | contribs)
Jump to navigation Jump to search

Return to Clinical Decision Support Work Group

Project Co-Sponsors:

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 will be balloted for comment in the September 2015 cycle, followed by a DSTU ballot in the January 2016 cycle.

Meeting Information

The CDS on FHIR project subteam meets weekly: Conference call coordinates


The Project Scope Statement for this project has been approved by the primary and co-sponsoring work groups and submitted to HL7.

The Notice of Intent to Ballot for the September 2015 cycle will be voted on at the CDS Work Group meeting on July 9th, 2015.

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:

CDS-on-FHIR GitHub Repository

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:

Furore Spark Server

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


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)