DSTU2 QA Preview
This page is part of the FHIR Specification (v1.0.0: DSTU 2 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
This implementation guide focuses on three main use cases within the clinical quality domain:
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.
The following table lists the CQIF profiles that are part of the IG, and the underlying FHIR resources:
| CQIF FHIR Profile | Base FHIR Resource |
|---|---|
| CQIF-KnowledgeRequest | Basic |
| CQIF-KnowledgeResponse | Basic |
| CQIF-KnowledgeModule | Basic |
| CQIF-Evidence | DocumentReference |
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 defines the KnowledgeModule structure, which establishes the elements common to knowledge artifacts from both domains.
The KnowledgeModule structure is then extended by the quality measurement and decision support domains to support the representation of domain specific modules and artifacts.
At the common level, the KnowledgeModule structure contains the following general categories of elements:
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 KnowledgeModule 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 |
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.
| Status | CDS KAS Mapping | DSS Mapping |
|---|---|---|
| draft | Draft | DRAFT |
| test | InTest | DEFINED |
| active | Active | APPROVED, PROMOTED |
| inactive | Inactive | REJECTED, RETIRED |
In addition, the KnowledgeModule structure provides elements for tracking publication information including contributor, publisher, steward, and rightsDeclaration.
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 KnowledgeModule structure provides for the definition of two types of data requirements:
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 KnowledgeModule 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.
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.
To support the ability of a repository to allow searching for knowledge modules and artifacts, the KnowledgeModule structure defines the topic and keyword elements. For more information on these elements, refer to the Distribution section.
In addition to being a description of the behavior of a quality service, the KnowledgeModule structure can be used to represent a knowledge artifact, which is defined as a shareable, computable definition of the behavior of a quality service. Most of the content actually contained within an artifact is defined by derived structures such as MeasureArtifact and GuidanceArtifact that define the content specific to the domain. However, some of the content definitions are common between both measurement and decision support, and are therefore modeled in the KnowledgeModule structure itself. Specifically, the model and library elements define the data models and libraries used within the content.
The following examples illustrate the use of the knowledge module to define stand alone modules and libraries:
The evaluation use case enables the user of a system (such as a clinical workflow system) to receive clinical guidance for a particular patient. In addition, this use enables the ability of a health care system to automatically determine the need for clinical guidance based on clinical observations. In general, the use case involves a service requestor, and a service supplier. The Decision Support Service specification defines interfaces to enable this use case; this implementation guide provides a realization of that interface using FHIR as the service.
Only the common aspects of an artifact evaluation request and response are considered here, measure- and decision-support-specific evaluation operations are defined in their respective sections.
Note that this implementation guide does not assume that the data required for an evaluation is available on the same FHIR service as the quality service. In some scenarios, a quality service vendor may be exposing a FHIR service that only supports evaluation, and requires that patient information be supplied as part of the evaluation request. In other scenarios, the patient data may be co-located with the quality evaluation service.
To support the evaluation use case, this implementation guide defines structures to capture the relevant information for a request and response. These structures are then used by the quality measurement and decision support domains to define operations appropriate to their specific use cases.
The KnowledgeRequest structure captures the information required to request evaluation of a particular module, and the KnowledgeResponse structure describes the information returned by an evaluation.
Each request instance specifies a single module to be evaluated, and results in a single response to describe the result of the evaluation. Note that the inputParameters provided as part of the KnowledgeRequest are intended to provide patient-independent information to the evaluation. Patient-specific information, if required, is provided as part of the operation interaction.
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 KnowledgeModule 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.
© HL7.org 2011+. FHIR DSTU2 (v1.0.0-6850) generated on Tue, Sep 1, 2015 14:42+1000.
Links: What's a DSTU? |
Version History |
Table of Contents |
Compare to DSTU1 
|
|
Propose a change