This page is part of the FHIR Specification (v1.2.0: STU 3 Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

G.2 Overview

This implementation guide focuses on three main use cases within the clinical quality domain:

1. Sharing - The representation of computable knowledge artifacts
2. Evaluation - The evaluation of knowledge artifacts
3. Distribution - The exposure of a searchable repository of knowledge artifacts

The specific domains of quality measurement and decision support each make use of the functionality defined by these use cases. As such, the objective of this section of the guide is to establish the common aspects by defining base structures that can then be extended and utilized by each specific domain.

G.2 Contents

The following table lists the resources and profiles that are involved in the IG:

Resource/Profile	Description
ModuleMetadata	Defines metadata for a quality artifact. This resource is used by specific aritfact definition resources such as DecisionSupportServiceModule, OrderSet, and Measure to specify common metadata.
ModuleDefinition	Defines data requirements and model, library, and terminology components referenced by an artifact. This resource is used by specific artifact definition resources as a common facility for describing these aspects of an artifact.
Library	Defines a library of CQL/ELM logic that can be shared and reused by various quality artifacts.

G.2 Sharing

The sharing use case is considered first, because it establishes structures that are then utilized by the other two use cases. Broadly, this use case involves enabling a Healthcare Delivery System such as an Electronic Health Record System or a Clinical Decision Support Service, to obtain a computable definition of a knowledge artifact, such as a quality measure, or a decision support rule. This section of the implementation guide uses the ModuleMetadata and ModuleDefinition structures, which describe the elements common to knowledge artifacts from both domains.

The ModuleMetadata structure is then used by the quality measurement and decision support domains to support the representation of domain specific modules and artifacts.

At the common level, the ModuleMetadata structure contains the following general categories of elements:

• Module identity and versioning
• Description and documentation
• Publication and stewardship information
• Repository metadata

In addition, the ModuleDefinition structure defines the following categories of elements:

• Models - The models referenced by the artifact.
• Libraries - The libraries referenced by the artifact.
• Terminology - The code systems and value sets referenced by the artifact.
• Data Requirements - The data requirements for the artifact.

G.2.1 Module Identity

As with any FHIR resource, the instance identity is specified by the id element. In addition, modules may have logical identifiers based on the content or behavior they provide. For example, the CMS or NQF identifiers for measure content. These identifiers can be provided in the identifier element.

In addition to identity, the ModuleMetadata structure allows, but does not require, a version to be specified.

When using the identifier element to provide the Entity Identifier for a module consistent with the Decision Support Service (DSS) specification, the following mappings apply:

DSS Model Element	FHIR Element	Example
businessId	Identifier.value	hemoglobin-control-rule
scopingEntityId	Identifier.system	com.clinica
version	KnowledgeModule.version	1.0.0

G.2.2 Documentation

The KnowledgeModule structure provides several elements related to documentation of the module, including title, description, purpose, and usage. In addition to these elements, additional supporting documentation, citations, and evidence can be provided via the relatedResource element.

G.2.3 Publication Information

The status element of the ModuleMetadata structure describes the lifecycle status of the module, indicating whether the module is a draft, test, active, or retired artifact. This representation is consistent with the states described by the Quality Metadata Conceptual Model. The following table provides a mapping from the states defined here, to the states as defined in the Clinical Decision Support Knowledge Artifact Specification (CDS KAS), as well as the Decision Support Services (DSS) standard:

Status	CDS KAS Mapping	DSS Mapping
draft	Draft	DRAFT
test	InTest	DEFINED
active	Active	APPROVED, PROMOTED
inactive	Inactive	REJECTED, RETIRED

In addition, the ModuleMetadata structure provides elements for tracking publication information including contributor, publisher, steward, and rightsDeclaration.

G.2.4 Repository Metadata

To support the ability of a repository to allow searching for knowledge modules and artifacts, the ModuleMetadata structure defines the topic and keyword elements. For more information on these elements, refer to the Distribution section.

G.2.5 Data Requirements

The data requirements for a knowledge module describe the minimum data required in order to achieve a successful evaluation of the module. More data may in general be provided, but not less. For example, a given module may state that the lab results for A1C tests over the past two years are required. If a system provides data for the last three years, the module can still be successfully evaluated, but if a system provides data for only the last year, the module may produce incorrect results based on the absence of the expected data.

In the scenario that an evaluation service is not colocated with the clinical information, the service has no general way of knowing whether or not a request has fulfilled the stated data requirements for a module. As such, this is a critical aspect of implementation, the service assumes the stated data requirements will be provided as part of a request, and requesters shall provide at least the data specified by the data requirements when requesting evaluation for a module.

The ModuleDefinition structure provides for the definition of two types of data requirements:

1. Patient-independent information - Specified as named parameters
2. Patient-dependent information - Specified as types of information

G.2.5.1 Parameters

Patient-independent information consists of data that is not known based on the patient or population under evaluation. For example, an A1C control artifact may have as a parameter the threshold A1C level that is considered "poorly controlled."

Within the ModuleDefinition structure, patient-independent data requirements are modeled using the parameters element. These elements are defined in the same way that parameters are defined for operation definitions within the FHIR infrastructure.

G.2.5.2 Data

Patient-dependent information consists of data that is related to the patient or population under evaluation, and is specified by the data element. The set of data of interest for a particular evaluation is specified by identifying the type of data, such as MedicationStatement or Encounter, an optional profile or profiles to which the data must conform, and optional filters for code- and/or date-valued attributes.

Note that because this data is dynamically filtered, it cannot be completely described with profiles. In addition, the data requirements as specified here map directly to the way that patient-specific information is accessed within retrieve expressions in Clinical Quality Language (CQL), and are therefore not named the way that parameters are in order to be accessed.

G.2.6 Examples

The following examples illustrate the use of the ModuleMetadata, ModuleDefinition, and Library resources to define stand alone modules and libraries:

• ModuleMetadata Example: Chlamydia Screening Decision Support Rule
• ModuleDefinition Example: Module definition for Chlamydia Screening Common Library
• Library Example - Chlamydia Screening Common Library

G.2 Evaluation

Because evaluation is specific to the type of artifact being evaluated, the evaluation scenarios are described as operations against each type of artifact (when evaluation is an appropriate operation).

G.2 Distribution

The distribution use case involves enabling knowledge artifacts to be distributed as documents via a FHIR server. The search and read interactions defined by the FHIR infrastructure can be used for this purpose. The ModuleMetadata structure defines several search parameters to enable searching based on the various attributes of a knowledge module. The FHIR search interaction specifies that search results are returned in a Bundle, and the entries in that bundle allow a score to be specified, consistent with the Decision Support Service (DSS) relevance result. Note that the DSS score range is 1 to 100, while the FHIR score range is 0..1.

The following table lists the search criteria elements defined by the Decision Support Service (DSS) standard along with their appropriate representation in FHIR:

DSS Search Criteria	FHIR Equivalent
Maximum Results	_count global search parameter
Minimum Score	KnowledgeModule.minScore search parameter
Knowledge Module Trait	Knowledge search parameters (identifier, keyword, topic, title, description, version)
Knowledge Module Status	KnowledgeModule.status search parameter
Evaluation Result Semantics	Not Implemented
Data Requirements	Not Implemented
Relationships to specific Knowledge Modules	Not Implemented

Support for exclusion criteria as described in the DSS is provided by the :not search parameter modifier of FHIR.

NOTE: Providing the ability to search on Evaluation Result Semantics, Data Requirements, and Relationships to specific Knowledge Modules was deferred. We seek comment on whether these requirements are seen as vital to a quality service implementation.