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 section of the guide discusses the profiles and operation definitions used to meet the three main use cases of:
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-GuidanceRequest | Basic |
| CQIF-GuidanceResponse | Basic |
| CQIF-GuidanceArtifact | Basic |
| CQIF-Questionnaire | Questionnaire |
This implementation guide defines the following types of artifacts:
To represent these artifact types, this guide introduces the GuidanceArtifact structure. This structure derives from the KnowledgeModule structure defined in the common section, and introduces elements to enable representation of the structures involved in each of these artifact types.
The following sections discuss the use of the GuidanceArtifact structure to represent each of these artifact types.
This implementation guide introduces the notion of a Simple Rule to allow for the sharing, evaluation, and distribution of simple decision support rules that don't necessarily fit the pattern established by Event-Condition-Action rules.
For example, a decision support service may support the evaluation of creatinine levels as part of assessing renal function. A Simple Rule allows an artifact to be defined that contains only the evaluation logic involved in determining creatinine level. This logic may then be shared independently from the larger Event-Condition-Action rule describing the overall renal function assessment.
For simple rules, the rule element is used to define the logic involved in the rule, and the result of evaluating this expression is the result of the rule.
As the name implies, ECA rules define actions that should be taken whenever some condition is met in response to a particular event. This implementation guide defines three types of events that can trigger the evaluation of an ECA rule:
A named event is an event identified by the implementation environment. This type of event allows ECA rules to be triggered by any event generated within the implementation environment. A scheduled event occurs on a fixed or periodic schedule. And finally, a data event occurs in response to some data-related event in the integrated environment such as a record being added or updated.
An ECA rule may have any number of events that can trigger the rule. Note that this may also be zero, as the rule may be evaluated by direct request. Also note that because ECA rules are shareable artifacts, the definition of the triggering events must be utilized by the implementation environment to determine when to invoke the rule.
Each ECA rule must have a single condition that is evaluated whenever any of the events occur. If this condition evaluates to true, the actions defined by the rule should be performed.
And finally, each ECA rule defines actions that should be performed. This implementation guide defines the following types of actions:
The Create, Update, and Remove actions indicate that particular resources should be created, updated, or removed, and the Fire Event action indicates that a particular named event should be triggered.
To represent ECA Rules, the event element of the GuidanceArtifact is used to represent the triggering events for the artifact, the rule element is used to provide the expression for the condition of the rule, and the action element defines the actions to be performed.
The Chlamydia Screening CDS example illustrates the representation of a decision support event-condition-action rule; specifically, the example Chlamydia Screening CDS rule from the Clinical Quality Language specification.
A documentation template is a structured form for recording information on a patient into a set of pre-defined data slots. These templates are used to guide structure data entry within an EHR or other clinical information system. Some examples of clinical documents that can be represented via documentation template artifacts are encounter summaries, procedure notes, patient-reported outcomes, and flowsheets.
Within FHIR, the Questionnaire resource is available for modeling the structure of questionnaires. As such, a Documentation Template artifact is represented by using the content element of the GuidanceArtifact structure to refer to a particular Questionnaire.
However, Documentation Templates as described by the Clinical Decision Support Knowledge Artifact Specification allow not only questions to be defined, but the behavior of the questionnaire as well. For example, whether or not to display a particular question or group of questions based on answers to previously asked questions, or calculating the value of an answer based on other answers. The Questionnaire resource by itself does not provide this functionality, so this guide introduces a CQIF-Questionnaire profile of the Questionnaire resource to allow this behavior to be modeled.
As an example, the PHQ-9 Health Questionnaire contains a question that is answered by totaling the weights from the answers of each of the previous questions. The CQIF Questionnaire example illustrates the representation of this questionnaire with the required logic for computation.
The content of a documentation template artifact is then specified by referencing either a Questionnaire directly, or a CQIF-Questionnaire if behavioral functionality is required. For example, the PHQ-9 Documentation Template Module illustrates a guidance artifact that references the CQIF Questionnaire defined above.
An order set is a pre-defined and approved group of orders related to a particular clinical condition (e.g. hypertension treatment and monitoring) or stage of care (e.g. hospital admission to Coronary Care Unit). An order set is used as a checklist for the clinician when managing a patient with a specific condition. It is a structured collection of orders relevant to that condition and presented to the clinician in a computerized provider order entry system (CPOE).
Within this implementation guide, order sets are represented using the action elements of the GuidanceArtifact structure. The action element provides the ability to define hierarchical groups of actions, where each specific action defines a specific orderable item, together with behaviors that determine how the orderable items are related to eachother.
In general, each orderable is a template-level description of a specific FHIR resource, with the order set definition providing for additional behavioral components by defining expressions for the values of various components of the orderable that are evaluated in context when the order set is presented. This allows the general description of the order set to be presented structurally, while still allowing for maximum flexibility and customization of the contents based on the patient, encounter, and setting at the point-of-care.
As an example, the Respiratory Protocol example order set from the Clinical Decision Support Knowledge Artifact Specification was represented using the knowledge module structure: Respiratory Protocol Example Order Set.
Libraries were introduced into the Clinical Decision Support Knowledge Artifact Specification as a means of reusing components of artifact definitions. However, because they are generally useful for sharing components in both the quality measurement and decision support domains, libraries are implemented at the common level.
In addition to representing these artifacts directly, the use of artifact definitions that are based on the existing Clinical Decision Support Knowledge Artifact Specification is supported by allowing the content element to contain a DocumentReference that points to the actual artifact. For example, the following example illustrates how to expose the PHQ-9 Documentation Template Example from the Clinical Decision Support Knowledge Artifact Specification as a guidance artifact: Guidance Artirfact HeD Reference
In this case, the information represented in the KnowledgeModule can be inferred from the referenced artifact, and potentially generated by a simple transform.
For the evaluation use case, this implementation guide defines the GuidanceRequest and GuidanceResponse structures, derived from KnowledgeRequest, and KnowledgeResponse, respectively. These guidance-level structures introduce clinical decision support-specific information such as the requesting and recipient organizations and/or persons, as well as the workflow context.
In addition, the GuidanceResponse structure introduces elements for representing the actions to be performed in response to a guidance evaluation request.
These request response structures are then used to define the $guidance operation to allow a FHIR server to provide clinical decision support evaluation services. For example, the following request and response structures provide an illustration of the use of the $guidance operation to invoke a Guideline Appropriate Ordering knowledge module:
The distribution use case functionality as described within the common section of this implementation guide is sufficient for the clinical decision support use case. As such, this section does not introduce any new functionality in support of the distribution use case.
© 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