This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions

Responsible Owner: Work Group Clinical Decision Support

Standards Status: Informative

14.5 Clinical Decision Support Services

This section of the clinical reasoning module discusses the evaluation use case for clinical decision support and how the various knowledge artifacts can be integrated into clinical workflow. Clinical decision support can take a variety of forms, and some of these use cases have been discussed in the artifact representation and definitional resources topics. To support the application of those representations to a particular subject (typically a patient) or group of subjects, the PlanDefinition/$apply operation is used. This operation is discussed in detail in the Applying a Plan Definition topic, whereas this topic discusses options for exposing that capability as a service.

As with any clinical application, the use of decision support services must consider patient safety, security, and privacy issues. For a more complete discussion of this topic, including decision support-specific considerations, refer to the Implementer's Safety Checklist.

14.5.1 Consuming Decision Support

The PlanDefinition/$apply operation supports applying the definitions provided in the PlanDefinition to a particular subject, typically a Patient. By exposing this operation directly along-side the other RESTful operations of a FHIR server, clinical applications can simply request decision support to be provided as part of building clinical workflows, it's simply another interaction available to the clinical application:

Using this approach, applications manipulate patient data as they would for any other FHIR application, and at points in the clinical workflow where decision support should be provided (as indicated by the triggerDefinition elements of the PlanDefinitions in the system), the PlanDefinition/$apply operation is invoked, passing the current context (i.e., the subject, encounter, user, etc). The result is a series of request resources that can then be processed by the client application. These will typically be proposals to perform actions, and can be displayed to the user to determine the actual actions to be performed.

For a more detailed treatment of how this process can be represented in and applied with FHIR Clinical Reasoning resources, see the Activity Flow topic in the FHIR Clinical Guidelines implementation guide.

14.5.2 Surfacing Clinical Decision Support Guidance Using CDS Hooks

CDS Hooks is an HL7 specification focused on integrating user-facing remote clinical decision support into clinical systems. Architecturally, CDS Hooks is silent about what functions CDS services actually perform, and focuses on the integration between the client (typically an EHR) and the service that is an independent system providing the decision support:

As depicted in the above diagram, an EHR invokes a CDS Hooks request at the appropriate point in the workflow, providing the requested context and data. The CDS Service responds by performing an $apply operation against the specified PlanDefinition, and transforming the resulting RequestOrchestration into a CDS Hooks response.

Using this approach, existing EHR systems can integrate with decision support service vendors, regardless of what services they provide. Decision support vendors can use the CDS Hooks interface to expose their service capabilities, regardless of what EHR is making use of them. In the same way, Clinical Reasoning content can be exposed by providing a wrapper around the PlanDefinition $apply implementation, providing a common and consistent pattern for describing decision support that can be easily integrated using the CDS Hooks specification.

For a more detailed treatment of this approach, refer to the Using FHIR Clinical Reasoning with CDS Hooks implementation guide.