Resource names should meet the following characteristics: (for additional guidance on considerations for resource creation, refer to FHIR Resource Considerations)
- Upper camel case
- Avoid non-universal abbreviations (e.g. URL would be ok)
- Be expressed as a noun
- Be consistent with other similar resources
For discussion after Baltimore
The DecisionSupportServiceModule resource provides a mechanism for describing a unit of executable decision support logic 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
Committee Approval Date:
2016-02-24 - Meeting Minutes
Contributing or Reviewing Work Groups
FHIR Resource Development Project Insight ID
Scope of coverage
FMG note: Need clarification on scope - appears quite broad.
A DecisionSupportServicModule 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.
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, forcing 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.
Multiple decision support vendors have expressed interest in using the DecisionSupportServiceModule resource and the _evaluate_ operation to implement a FHIR-Based Decision Support Service, including OpenCDS, Partners Healthcare and others.
- 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
Guideline Appropriate Ordering
When evaluating the appropriateness of an order such an imaging study, the DecisionSupportServiceModule 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 DecisionSupportServiceModule 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 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.
The DecisionSupportServiceModule makes use of the GuidanceResponse resource to return its results.
In addition, the resource makes use of the following common data types:
May 2016 Ballot Cycle in support of the CQF IG.