HeyDonto FHIR R4 API - Clinical Reasoning (1.0)

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude

Scope

The Clinical Reasoning module focuses on enabling two primary use cases:

1. Sharing - The ability to represent clinical knowledge artifacts such as decision support rules, order sets, clinical protocols, and quality measures, and to do so in a way that enables those artifacts to be shared across all organizations involved in care management and delivery

2. Evaluation - The ability to evaluate clinical knowledge artifacts in the context of a specific patient or population, including the ability to request decision support guidance, impact clinical workflow, and retrospectively assess clinical quality metrics

To enable these use cases, the module defines several components that can each be used independently, or combined to enable more complex functionality:

• Expression Logic - the representation of logic using languages such as FHIRPath and Clinical Quality Language (CQL)
• Definitional Resources - resources that are not defined on any specific patient, but are used to define the actions to be performed as part of a clinical knowledge artifact such as an order set or decision support rule. These resources can be used directly, or with profiles to provide intended structure for specific types of resources
• Knowledge Artifacts - representation of clinical knowledge such as decision support rules and clinical quality measures

Index

Resources

• ActivityDefinition - A resource to represent definitional resources
• DataRequirement - A data type that represents a general data requirement for a knowledge asset such as a decision support rule or quality measure
• GuidanceResponse - Represents the result from invoking a decision support service
• Library - Provides a container for knowledge artifacts that includes logic libraries, model definitions, and asset collections
• Measure - Represents a clinical quality measure and provides evaluation through the $evaluate-measure operation
• MeasureReport - Represents the response to a specific measure evaluation request returned by the $evaluate-measure operation
• PlanDefinition - Represents the description of a plan for accomplishing a particular goal. This resource is used to represent a broad variety of clinical knowledge artifacts including decision support rules, order sets, and protocols
• RequestGroup - Represents a group of options for a particular subject that can be used to accomplish a particular goal. This resource is often, but not always, the result of applying a PlanDefinition to a particular patient

Key Extensions

• cdsHooksEndpoint - An extension applied to a PlanDefinition to indicate that it provides the behavior for a CDS Hooks service endpoint
• expression - A general purpose extension that supports the use of languages such as FHIRPath and Clinical Quality Language within FHIR
• library - A general purpose extension that supports the declaration of dependencies that can be accessed by expression logic
• measureInfo - An extension that can be applied to resources to indicate the measure criteria they satisfy
• qualityOfEvidence - An extension that can be applied to indicate the quality of evidence in support of a particular artifact or recommendation
• strengthOfRecommendation - An extension that can be applied to indicate the strength of a recommendation

Profiles

• Shareable ActivityDefinition - Enforces the minimum information set for the activity definition metadata required by HL7 and other organizations that share and publish activity definitions
• CQF-Questionnaire - Defines extensions to the base Questionnaire that allow it to be used as a DocumentationTemplate with behavior specified via logic in CQL libraries
• CDS Hooks GuidanceResponse - Defines a GuidanceResponse that represents the response container for a CDS Hooks response
• Shareable Library - Enforces the minimum information set for the library metadata required by HL7 and other organizations that share and publish libraries
• CQL Library - Represents a CQL logic library
• Shareable Measure - Enforces the minimum information set for the measure metadata required by HL7 and other organizations that share and publish measures
• Shareable PlanDefinition - Enforces the minimum information set for the plan definition metadata required by HL7 and other organizations that share and publish plan definitions
• Computable PlanDefinition - Defines a computable PlanDefinition that specifies a single library and requires all expressions referenced from the PlanDefinition to be definitions in that single library

Services

• Knowledge Repository - Defines minimum service capabilities for a knowledge repository
• Measure Processor - Defines minimum service capabilities for a measure processor

Topics

For detailed guidance on specific topics within the Clinical Reasoning module:

• Overview and Background - Background and development of the FHIR Clinical Reasoning module
• Using Expressions - How to add dynamic capabilities to FHIR resources using expressions
• Definitional Resources - How to describe definitional resources using the ActivityDefinition resource
• Representing Knowledge Artifacts - How to represent knowledge artifacts such as Event-Condition-Action rules, Order Sets, or Clinical Protocols
• Sharing Knowledge Artifacts - How to share and distribute knowledge artifacts
• Clinical Decision Support Service - How to use the Clinical Reasoning module to provide or use Clinical Decision Support services
• Quality Reporting - How to define or report clinical quality measures

Audience

• Knowledge Authors - This module describes an approach to representing knowledge artifacts within FHIR
• Knowledge Content Providers - This module defines search functionality for using a FHIR server as a knowledge artifact repository
• Knowledge Evaluation Service Providers - This module defines operations and profiles in support of evaluating quality measures and defining and using CDS Hooks services
• Knowledge Evaluation Service Consumers - This module defines the expected available operations and behavior of a knowledge evaluation service

Security and Privacy

Because Knowledge Artifacts are typically patient-independent, many of the resources in the clinical reasoning module have no patient security and privacy concerns beyond the normal sensitivity that should be paid in any electronic healthcare system environment. However, the evaluation use case, including decision support guidance request/response, as well as quality measure evaluation have significant patient security and privacy concerns.

For the clinical decision support evaluation use case, as with any patient-specific information, care should be taken to ensure that the request and response are properly secured both at rest and in-motion, and that all access to the patient's information is done via a properly authenticated and authorized mechanism. This is particularly true of decision support artifacts where the logic is ingested as part of the definition of the artifact. In this scenario, the evaluation engine must ensure that data access within the ingested logic is subject to the same authentication and authorization requirements as any other access.

For guidance services that receive patient information, ensure that logging and auditing trails do not inadvertently compromise patient privacy and security by logging potentially sensitive information in an unencrypted way. In addition, guidance and recommendations returned from the service must ensure that content that contains patient information is clearly indicated so that consuming clients can take the appropriate care in integrating and displaying the resulting guidance.

For quality measure evaluation, individual and patient-list reports have the potential to contain large amounts of patient information. Care must be taken to ensure the patient information is only accessible to properly authenticated and authorized agents, and that inadvertent breaches are minimized by following appropriate logging and auditing protocols.

In particular, because expression languages, depending on their power and scope, can provide the ability to access large amounts of data, as well as the potential for infinite recursion or looping, care should be taken to ensure that implementations adequately safeguard against Denial-of-Service-style attacks that leverage these capabilities to compromise systems by overloading capacity.

For more general considerations, see the Security and Privacy module.

Background

The FHIR Clinical Reasoning module is sponsored by the Clinical Decision Support (CDS) and Clinical Quality Information (CQI) HL7 Work Groups, with input and coordination from the FHIR Infrastructure and Service Oriented Architecture HL7 Work Groups.

The guidance in this module was prepared as a Universal Realm Specification with support from the Clinical Quality Framework (CQF) initiative, which was a public-private partnership sponsored by the Centers for Medicare & Medicaid Services (CMS) and the U.S. Office of the National Coordinator for Health Information Technology (ONC) to identify, develop, and harmonize standards for clinical decision support and electronic clinical quality measurement.

The Clinical Quality Framework is focused on harmonizing the historically disjointed specifications used by the Clinical Quality Measurement and Clinical Decision Support communities. The strategy employed has been to break the conceptual content of knowledge artifacts into three core components:

• Metadata - Descriptive information about the artifact and its content
• Clinical Information - Information about a patient or population of concern within a given artifact
• Logic - The clinical reasoning involved in an artifact

The first component has resulted in the Clinical Quality Common Metadata Conceptual Model, an informative document harmonizing metadata requirements between Quality Measurement and Decision Support artifacts.

The second component has resulted in the QUICK Conceptual and Logical Models, a harmonization of the Virtual Medical Record (vMR) used in Decision Support and the Quality Data Model (QDM) used in Quality Measurement, with its core requirements realized in FHIR as the Quality Improvement Core (QICore) profiles.

The third component has resulted in the Clinical Quality Language specification, a harmonization of the expressive capabilities of the Clinical Decision Support Knowledge Artifact Specification (CDS KAS) and the Health Quality Measures Format (HQMF).

This module continues the harmonization of quality domain specifications by defining an approach to using a FHIR server as a component of a knowledge system in both the Knowledge Repository and Knowledge Evaluation Service roles.

Developmental Roadmap

The resources defined for the Clinical Reasoning module are the result of the combined efforts of multiple communities working on the shared goal of harmonized standards and specifications for clinical decision support and quality measurement artifacts. The current state of the module reflects changes incorporated both from previous ballots on the FHIR-specific material, as well as content derived from several other balloted specifications in the CDS and CQM domains.

The use of Clinical Quality Language (CQL) as a foundational mechanism for representing clinical quality logic enables decision support and quality measurement artifacts to share common definitions. For example, a Chlamydia Screening measure and related decision support artifacts can share a common library that describes the criteria for detecting when Chlamydia Screening is required in a patient.

Over the past year of trial use, the Clinical Reasoning module has been used in both the quality measurement and decision support domains to represent, exchange, and evaluate knowledge artifacts. The goals of the module are to provide a stable basis for implementation of the sharing use case, as well as unification with the CDS Hooks specification in support of the evaluation use case. The Clinical Quality Framework Initiative will use these resources as the basis for implementation projects, targeting an FMM level of 3 or 4 for all module resources.