ServiceDefinition FHIR Resource Proposal

ServiceDefinition

NOTE: Based on the alignment efforts with CDS Hooks, the functionality provided by this resource has been replaced with guidance on the use of CDS Hooks for decision support service evaluation, and the committee decided to retract the resource proposal. The resource has been removed from the R4 specification.

For discussion after Baltimore

NOTE: This resource was originally named DecisionSupportServiceModule, but was renamed to potentially allow it to apply to a broader class of services, and changed to reference an OperationDefinition to define the interface.

NOTE: Based on discussions at the 2017 San Antonio WGM with the CDS Hooks project team, we intend to align the decision support functionality described by the Clinical Reasoning Module with the CDS Hooks specification as part of STU4. This alignment will result in changes to this resource, up to and including its elimination from the Clinical Reasoning module.

However, to support in-flight projects and ensure continuity for the CQF community during this alignment phase, we request that the resource be included in its present form in the STU3 specification. A note to implementers explaining the alignment effort and potential impact is included with the STU3 documentation.

The ServiceDefinition resource provides a mechanism for describing a unit of executable decision support functionality exposed as a callable service. The resource allows decision support functionality to be described as a searchable module, as well as defining a standard mechanism for invoking decision support that extends the core FHIR operation framework with functionality that is common to decision support use cases.

In particular, the resource and its associated _evaluate_ operation provide a mechanism for describing the triggering events, data requirements and potential results of a decision support module in a way that simplifies integration into a clinical workflow. This pattern is based on the HL7 Version 3 Standard: Decision Support Service (DSS), Release 2 currently in production use in the OpenCDS platform.

The resource is differentiated from OperationDefinition for two reasons:

1) To allow decision support services to be searched, categorized, and represented using structures that are specific to the use case and not present in general on operation definitions.

2) To allow common parameters to be specified for all decision support services, while still allowing for specific parameters to be represented on each module.

Owning committee name

Clinical Decision Support Work Group

Committee Approval Date:

2017-03-01 - Meeting Minutes

DecisionSupportServiceModule committee approval: 2016-02-24 - Meeting Minutes

Contributing or Reviewing Work Groups

• Clinical Quality Information Work Group
• Service Oriented Architecture Work Group

FHIR Resource Development Project Insight ID

1234: FHIR-Based Clinical Quality Framework (CQF-on-FHIR)

Scope of coverage

FMG note: Need clarification on scope - appears quite broad.

A ServiceDefinition is an interface-level description of decision support functionality that enables a standardized approach to invoking decision support and consuming the resulting guidance. Because it is definitional in nature, it is not a patient-specific resource. The resource is flexible enough to be used to describe behaviors for a broad range of decision support applications and could potentially be used in any discipline and locale. It is intended to be used by Decision Support Service Providers as a means of publishing their available service catalog as a searchable repository, as well as defining the public interface for consumers of that functionality.

Resource appropriateness

The delivery and integration of decision support as a service is a critical aspect of health care systems, but is often implemented as a proprietary interface, requiring consumers to build custom integrations for each Decision Support Service Provider.

The Decision Support Service Specification defines a standard, production-level mechanism for exposing a decision support service, and enabling that mechanism to be realized as FHIR resources and operations will extend the reach of that standard, as well as allow implementers to use the FHIR stack and all its associated tooling and specifications to expose the content, effectively enabling another potential role of a FHIR server as a Decision Support Service.

Expected implementations

Multiple decision support vendors have expressed interest in using the ServiceDefinition resource and the _evaluate_ operation to implement a FHIR-Based Decision Support Service, including OpenCDS, Partners Healthcare, Evinance, and others.

Content sources

• Clinical Quality Common Metadata Conceptual Model
• Clinical Decision Support Knowledge Artifact Specification
• Health Quality Measure Format
• Decision Support Service
• Decision Support Service Implementation Guide
• Infobutton Specification
• Infobutton Implementation Guide
• SOA Infobutton Implementation Guide

Example Scenarios

Guideline Appropriate Ordering

When evaluating the appropriateness of an order such as an imaging study, the ServiceDefinition can be used to describe the expected trigger, required data, and potential responses of an ordering service. The Guideline Appropriate Ordering Implementation Guide is currently being updated to use the ServiceDefinition resource to describe its evaluate functionality.

The scenario was piloted at the January 2016 Connectathon CDS-on-FHIR track by the University of Utah.

Immunization

Immunization forecasting and adherence is a complex and constantly evolving problem that is increasingly being handled by services external to the EHR. The use of this resource and operation for this purpose was piloted at the January 2016 Connectathon CDS-on-FHIR track by Partners Healthcare, and will be part of the May 2016, CQF-on-FHIR track as well.

Resource Relationships

The ServiceDefinition makes use of the GuidanceResponse resource to return its results, as well as the OperationDefinition resource to override the default evaluate signature.

In addition, the resource makes use of the following common data types:

• TriggerDefinition
• DataRequirement

Timelines

May 2016 Ballot Cycle in support of the CQF IG.

gForge Users

brynrhodes

FMG Note

FMG will re-evaluate the proposal once there is a draft resource to review.