This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "ServiceDefinition FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
Line 17: Line 17:
 
'''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: 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.
+
'''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.'''
+
'''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.'''
  
 
<!-- Resource names should meet the following characteristics:
 
<!-- Resource names should meet the following characteristics:
Line 48: Line 48:
  
 
==Committee Approval Date:==
 
==Committee Approval Date:==
TODO: Reapprove this proposal on 2/28/2017
+
2017-03-01 - [http://wiki.hl7.org/index.php?title=File:2017-02-15_CDS_WG_Call_Minutes.docx Meeting Minutes]
 +
 
 +
DecisionSupportServiceModule committee approval:
 
2016-02-24 - [http://wiki.hl7.org/index.php?title=File:2016-02-24_CDS_WG_Call_Minutes.docx Meeting Minutes]
 
2016-02-24 - [http://wiki.hl7.org/index.php?title=File:2016-02-24_CDS_WG_Call_Minutes.docx Meeting Minutes]
  

Revision as of 20:47, 1 March 2017


ServiceDefinition

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

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.

RIM scope

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

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:

Timelines

May 2016 Ballot Cycle in support of the CQF IG.

gForge Users

brynrhodes