Connectathon 11 Snapshot
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 
This section of the guide discusses the profiles and operation definitions used to meet the three main use cases of:
The following links provide quick access to specific implementation scenarios described by this guide:
The following table lists the resources and profiles that are used within this IG:
| Resource/Profile | Description |
|---|---|
| GuidanceResponse | Represents the response to a decision support guidance request, including any output parameters returned by the evaluation. |
| DecisionSupportServiceModule | Defines a decision support service module, such as immunization assessment, drug-drug interaction, or guideline appropriate ordering assessment. |
| DecisionSupportRule | Defines a decision support rule of the form [on Event] if Condition then Action. |
| CQIF-Questionnaire | Defines extensions to the base Questionnaire that allow it to be used as a DocumentationTemplate with behavior specified via logic in CQL libraries. |
| OrderSet | Represents an order set definition that can be applied to a specific patient to produce a orders for an evidence-based care plan. |
In addition to the Library resource defined in the common section, the implementation guide provides mechanisms for representing the following types of artifacts:
The following sections discuss the representation of each of these artifact types.
The DecisionSupportServiceModule structure provides a mechanism for describing the functionality made available by a particular service. For example, a service provide immunization modules, or drug-drug interaction checking. From the perspective of the consumer, how this functionality is performed is irrelevant, the only aspect of interest is a description of what the module does, and the inputs and outputs it requires.
As such, this resource simply uses a ModuleMetadata resource to define the common information relevant to all quality artifacts, and then defines the input and output data requirements as parameters, similar to the way operations are defined within the FHIR core. The main difference is that the parameters to a service module are allowed to define additional filters for code and date range, in the same way that data requirements are specified within a ModuleDefinition resource. For more information on this aspect, see the Data Requirements discussion.
As an example, the functionality defined by the Guideline Appropriate Ordering IG can be expressed as a DecisionSupportServiceModule: Decision Support Service Module Example.
As the name implies, Event Condition Action (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 are returned as the result of the evaluation.
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 trigger element of the DecisionSupportRule is used to represent the triggering events for the artifact, the condition element is used to provide the name of an expression that defines 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 template for recording information about a patient into a set of pre-defined data slots. These templates are used to guide structured 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 defining extensions to allow the ModuleMetadata for the artifact to be specified, as well as to allow references to Library resources to introduce behavior to the documentation template.
Documentation Templates often include not only a description of the data to be collected, but the behavior of the template during evaluation. 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.
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 OrderSet structure. The item element provides the ability to define hierarchical groups of items, where each specific item defines an orderable item, together with behaviors that determine how the orderable items are related to eachother.
If the order set contains only static items (i.e. there are no context-dependent values that must be provided to complete the orderable), then the resource element contains a reference to a complete resource instance representing the orderable.
However, each orderable item usually needs to be completed with contextual information based on the particular patient that the order set is being used with. In this case, either the user completing the order set must provide a value, or the order set definition can provide an expression that provides the necessary value based on the patient in context. These expressions are defined for each item using the customization element. Each customization specifies a path and the name of an expression that, when evaluated in context, provides a value for the element defined by the path.
This mixture of static and dynamic description of each orderable allows the order set to be presented structurally in terms of native resources, while still allowing for complete flexibility and customization of the contents based on the patient, encounter, and setting at the point-of-care.
As an example, the Low Suicide Risk example order set from the Clinical Decision Support Knowledge Artifact Specification was represented using the OrderSet structure: Low Suicide Risk Example Order Set.
To support the evaluation use case, the DecisionSupportServiceModule and DecisionSupportRule resources both define an $evaluate operation with the same signature. The operation allows for consistent invocation of decision support functionality across a broad range of decision support artifacts, allowing consumers to implement the request/response pipeline once to enable access to any decision support functionality provided by the service.
In addition, the GuidanceResponse structure provides a general mechanism for representing the actions to be performed in response to a guidance evaluation request.
The $evaluate operation provides a complete example of a request and response using the Guideline Appropriate Ordering decision support service module: $evaluate operation example
The above example uses the profiles defined in the Guideline Appropriate Ordering IG.
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.2.0-7447) generated on Fri, Dec 11, 2015 17:42+1100.
Links: Search 
|
Version History |
Table of Contents |
Compare to DSTU1 |
|
Propose a change