Work Group Maturity Level: 2 | Standards Status: Trial Use |
For the purposes of the Clinical Reasoning module, a Knowledge Artifact is a structured, computable, and shareable representation of clinical knowledge. A comprehensive definition of clinical knowledge is beyond the scope of this module, but we effectively mean any knowledge relevant to improving patient care. For example, "Patients with diabetes should have regular comprehensive foot examinations to identify risk factors predictive of ulcers and amputations" is a statement of clinical knowledge. A knowledge artifact would then be some representation that can be used to integrate that knowledge into existing healthcare delivery systems.
There are any number of ways to accomplish this integration of clinical knowledge, ranging from direct implementation within an existing EHR system to the use of high-level representation and reasoning systems that can adapt clinical workflow to provide cognitive support to clinicians. Within this module, we aim to provide a representation that is both flexible enough to represent a broad range of knowledge artifacts, but simple and specific enough to enable automated integration of the content.
To achieve these goals, we define several components that are present in a broad variety of knowledge artifacts:
Component | Description |
---|---|
Artifact Identity | Information used to uniquely identify an artifact. |
Metadata | Information about the knowledge artifact such as lifecycle status, publisher, documentation, and supporting evidence. |
Action Definitions | Descriptions of actions to be taken as part of the implementation of knowledge |
Trigger Definitions | Information about what events should trigger the use of the artifact |
Expression Logic | Expressions used to represent reasoning such as whether or not some criteria is satisfied, or calculation of new values from existing ones. |
As with any FHIR resource, the instance identity is specified by the id element. Knowledge artifacts also have a canonical identifier, specified by the url
element that serves as the globally unique, "canonical URL" for the artifact that always identifes the resource. The canonical URL is a special kind of logical (or business) identifier, and artifacts may define any number of additional logical identifiers based on the content or behavior they provide, such as the CMS or NQF identifiers for measure content. These logical identifiers can be provided in the identifier
element defined on each resource.
In addition to identity, the version
element can be used to specify a content version for the artifact. In general, version numbers are required for published, non-experimental artifacts, and optional otherwise.
The following fragment shows the use of the logical identifier and version elements:
<url value="http://motivemi.com/artifacts/PlanDefinition/low-suicide-risk-order-set"/>
<identifier>
<use value="official"/>
<system value="http://motivemi.com/artifacts"/>
<value value="mmi:low-suicide-risk-order-set"/>
</identifier>
<version value="1.0.0"/>
When using the identifier
element to provide the Entity Identifier for a service 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 |
scopingEntityUri | Identifier.system | com.clinica |
version | Artifact.version | 1.0.0 |
Each of the various knowledge artifact resources defines a set of elements that provide consistent representation of metadata such as title, description, and usage, repository indexing and publication information, as well as additional supporting documentation and evidence:
Element | Description |
---|---|
name | A machine-friendly name for the artifact example |
title | A user-friendly title for the artifact example |
status | The lifecycle status for the artifact (draft, active, or inactive) example |
experimental | Whether the artifact is for testing purposes, rather than production usage example |
description | A natural language description of the artifact example |
purpose | Describes the purpose of the artifact example |
usage | Describes the clinical usage of the artifact example |
approvalDate | The date when this artifact was approved by the publisher example |
lastReviewDate | The date this version of the artifact was last reviewed example |
effectivePeriod | The effective date range for the artifact example |
useContext | Describes the context of use for this artifact example |
topic | Descriptional topics for the artifact example |
contributor | A content contributor example |
publisher | The name of the publisher (either an organization or an individual) example |
contact | Contact details for the publisher example |
copyright | Legal copyright description for the artifact example |
relatedArtifact | Related resources for the artifact, including additional documentation, supporting evidence, or knowledge management dependencies example |
General documentation elements, including description, purpose, and usage, provide immediately available documentation as part of the artifact. Additional documentation can be provided using the relatedArtifact
element to link to more detailed information, supporting evidence, and to additional required artifacts as appropriate.
<title value="Appropriate Testing for Children with Pharyngitis"/>
<status value="active"/>
<experimental value="true"/>
<description value="Percentage of children 2-18 years of age who were diagnosed with pharyngitis, ordered an antibiotic and
received a group A streptococcus (strep) test for the episode."/>
<purpose value="The Infectious Diseases Society of America (IDSA) "recommends swabbing the throat and testing for GAS
pharyngitis by rapid antigen detection test (RADT) and/or culture because the clinical features alone do not reliably discriminate
between GAS and viral pharyngitis except when overt viral features like rhinorrhea, cough, oral ulcers, and/or hoarseness are present""/>
<topic>
<coding>
<system value="http://loinc.org" />
<code value="57024-2" />
</coding>
</topic>
For information on the useContext
and topic
elements, refer to the Knowledge Artifact Distribution section.
The status
element describes the lifecycle status of the artifact, indicating whether it is a draft, 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 Service (DSS) standard:
Experimental? | Status | CDS KAS Mapping | DSS Mapping |
---|---|---|---|
true | draft | Draft, InTest | DRAFT, DEFINED |
true | active | InTest | DEFINED |
true | retired | Inactive | REJECTED |
false | draft | Draft | DRAFT |
false | active | Active | APPROVED, PROMOTED |
false | retired | Inactive | REJECTED, RETIRED |
Note that the experimental
element can be used independent of the lifecycle status, allowing the full lifecycle of an artifact to be tested.
Actions describe the "output" actions of the knowledge artifact. These actions may be in the form of messages (such as reminders), structured clinical acts (e.g., a laboratory test order) that can be implemented via clinical systems such as a computerized provider entry system or a documentation system, or they may create new events (e.g., declaration of a patient state such as failure of a treatment). Each action definition contains the following basic information:
Description | Descriptive information such as identifier, label, title, and textEquivalent. |
Documentation | Supporting documentation, citations, or evidence in support of the action. |
Related Action Definitions | Each action definition can specify relationships to other actions, allowing timings and offsets to be expressed. |
Trigger Definitions | Triggering events for the action. See the section on trigger definitions below for more information. |
Condition | An optional condition specifying whether the action definition applies. |
Timing | A description of when the action definition should occur. |
Behavior | Various behaviors that communicate the intended semantics of groups and actions (e.g. selection behavior, grouping behavior, etc.) |
Type | The type of action to be performed (e.g. create, update, delete, etc.) |
Activity Definition | A description of what activity is to be performed. To enable reuse and modularity, ActivityDefinition resources may be reused by multiple action definitions. |
Dynamic Values | Expressions that can be used to specify dynamic values for the resulting activity. |
Child Actions | Each action may contain any number of child actions, allowing a hierarchy of actions to be described (for example, sections in an order set). |
The following fragment shows a simple referral creation action from an example order set for suicide risk assessment and management:
Note: the provided examples can be used formally, but can also be informational. The intent of the structures is to enable communication of the behavior. For systems that support calculation, they would be formal, but for systems that don't support calculation, the resource should still provide enough information to communicate the behavior.
<action>
<textEquivalent value="Refer to outpatient mental health program for evaluation and treatment of mental health conditions now"/>
<definition value="#referralToMentalHealthCare"/>
<dynamicValue>
<path value="timing.event"/>
<expression>
<language value="text/cql"/>
<expression value="Now()"/>
</expression>
</dynamicValue>
<dynamicValue>
<path value="specialty"/>
<expression>
<language value="text/cql"/>
<expression value="Code '261QM0850X' from SuicideRiskLogic."NUCC Provider Taxonomy" display 'Adult Mental Health'"/>
</expression>
</dynamicValue>
<dynamicValue>
<path value="occurrenceDateTime"/>
<expression>
<language value="text/cql"/>
<expression value="SuicideRiskLogic.ServiceRequestFulfillmentTime"/>
</expression>
</dynamicValue>
<dynamicValue>
<path value="subject"/>
<expression>
<language value="text/cql"/>
<expression value="SuicideRiskLogic.Patient"/>
</expression>
</dynamicValue>
<dynamicValue>
<path value="requester.agent"/>
<expression>
<language value="text/cql"/>
<expression value="SuicideRiskLogic.Practitioner"/>
</expression>
</dynamicValue>
<dynamicValue>
<path value="reasonCode"/>
<expression>
<language value="text/cql"/>
<expression value="SuicideRiskLogic.RiskAssessmentScore"/>
</expression>
</dynamicValue>
<dynamicValue>
<path value="reasonReference"/>
<expression>
<language value="text/cql"/>
<expression value="SuicideRiskLogic.RiskAssessment"/>
</expression>
</dynamicValue>
</action>
The example describes how to create a ServiceRequest
resource using information available from the context in which the order set is applied. The definition includes expressions for retrieving contextual information using the dynamicValue
element of the ActivityDefinition
resource. For more information on using expressions to provide dynamic values as part of a definition, refer to the Using Expressions topic in this module.
Each action may specify the type of action to perform:
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.
Note that this element is optional, and is used to indicate what type of action is to be taken with the associated activity definition. For example, an action that indicates create
with an activity definition that defines a referral request means that the referral request should be realized and the resulting resource created (i.e. applied to the patient's record). An action that indicates update
with an activity definition would indicate that an existing resource on the patient's record should be updated based on the new resource content.
Each action may have any number of triggers associated to indicate what events should trigger the action to be taken. The following types of triggers may be defined:
A named event is an event identified by the implementation environment. This type of event allows Event-Condition-Action (ECA) rules to be triggered by any event generated within the implementation environment. A periodic 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.
For triggered PlanDefinitions, the event means the PlanDefinition apply process should be performed. How that actually happens within an implementation is not prescribed.
As examples, the following fragments illustrate the use of a named event, a scheduled event, and a data event as part of an ECA rule definition:
<trigger>
<type value="named-event"/>
<name value="Admission"/>
</trigger>
<trigger>
<type value="periodic"/>
<timingDate>10/12/2015</timingDate>
</trigger>
<trigger>
<type value="data-added"/>
<data>
<type value="Condition"/>
<codeFilter>
<path value="code"/>
<valueSet value="urn:oid:2.16.840.1.113883.3.464.1003.111.12.1006"/>
</codeFilter>
</data>
</trigger>
Each action may have associated conditions that specify whether the action is applicable, or when it should be started and stopped. The $apply
operation is used to apply a plan definition, and the parameters to apply are available as context to expressions within the plan definition, including the applicable condition and the dynamic value expressions.
For example, the following fragment shows the condition element of an action definition used in an ECA rule. The condition references the named expression "NoScreening":
<condition>
<kind value="applicability"/>
<expression>
<language value="text/cql"/>
<expression value="NoScreening"/>
</expression>
</condition>
The Clinical Reasoning module defines several resources, including Library, PlanDefinition, and Measure to represent each of the components described above. By combining these components in different ways, several different types of knowledge artifacts can be represented:
Artifact Type | Description | Example |
---|---|---|
Library | A general purpose container for clinical knowledge, potentially defined in non-FHIR structures. For example, a sharable package of clinical logic expressed in Clinical Quality Language. | Expressions that define the criteria that must be met to determine whether or not a patient has diabetes. |
Event-Condition-Action (ECA) Rule | A decision support rule of the form [on Event] if Condition then Action , defining actions that should be taken whenever some condition is met in response to a particular event. | On a patient checking in to a clinic appointment, if the patient has diabetes and has not had a recent foot examination, place an unsigned order for a comprehensive foot exam. |
Order Set | 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). Order sets are used within electronic health record systems as a checklist for physicians when treating a patient with a specific condition or in a specific context. An order set is a structured collection of orders presented to the physician in a computerized physician order entry system (CPOE). | The specific orders to be placed when a patient presents with diabetic ketoacidosis. |
Protocol | A pre-defined procedural method for standardizing a set of activities. As examples, protocols can be used within laboratory settings to standardize handling of specimens for specific tests; standardize the treatment steps for a particular condition; or standardize the steps to be taken in a particular research trial. | The specific tasks that should be performed to provide effective treatment for a new diagnosis of diabetes. |
Documentation Template | A structured form for recording information on a patient into a set of predefined data slots. | A form describing the information that should be gathered during a comprehensive diabetic foot exam. |
Measure | A quantitative tool to assess the performance of an individual or organization with respect to a specified process or outcome via the measurement of actions, processes, or outcomes of clinical care. Quality measures are often derived from clinical guidelines and are designed to determine whether the appropriate care has been provided given a set of clinical criteria and an evidence base. | Percentage of patients aged 18-75 years of age with diabetes who had a foot exam during the measurement period. |
The Library resource is a general purpose container for clinical knowledge that may be defined in non-FHIR representations. For example, a Clinical Quality Language expression library can be represented as a Library resource so that it can be referenced as part of other knowledge artifacts.
For example, the following fragment shows a Library that contains the CQL logic for Chlamydia Screening decision support:
<Library>
<id value="example"/>
<identifier>
<use value="official"/>
<value value="ChalmydiaScreening_Common"/>
</identifier>
<version value="2.0.0"/>
<title value="Chlamydia Screening Common Library"/>
<status value="draft"/>
<type>
<coding>
<code value="logic-library"/>
</coding>
</type>
<date value="2015-07-22"/>
<description value="Common Logic for adherence to Chlamydia Screening guidelines"/>
<topic>
<text value="Chlamydia Screening"/>
</topic>
<relatedArtifact>
<type value="depends-on"/>
<resource value="Library/library-quick-model-definition"/>
</relatedArtifact>
<dataRequirement>
<type value="Condition"/>
<codeFilter>
<path value="code"/>
<valueSet value="urn:oid:2.16.840.1.113883.3.464.1003.111.12.1006"/>
</codeFilter>
</dataRequirement>
<content>
<contentType value="text/cql"/>
<url value="library-example-content.cql"/>
</content>
</Library>
An Event-Condition-Action (ECA) rule is an artifact with the general syntax "on event, if condition is true, then do action." The event triggers the invocation of the rule; the condition is a logical test that, if satisfied or evaluates "true", causes an action; while the action describes a set of activities to be performed. These actions may in turn cause further events to occur, which may in turn cause other ECA rules to fire.
Note that the "activity" to be performed may be to document a patient-specific assessment performed by a clinical decision support service (e.g. patient has a 37% chance of a heart attack in the next 5 years), not just recommendations/recommended actions. In this case, the action would be to "create" a RiskAssessment.
The PlanDefinition resource can be used to represent an ECA rule using the action
element. A single, top-level action
represents the overall rule, with the trigger
element used to specify the triggering event(s), the condition
element used to specify the applicable condition for the rule, and the action
element describing the action to be performed.
For example, the following fragment illustrates a simple use of PlanDefinition to expose a Chlamydia Screening ECA rule:
<PlanDefinition>
<id value="chlamydia-screening-intervention"/>
<identifier>
<use value="official"/>
<value value="ChlamydiaScreening_CDS_UsingCommon"/>
</identifier>
<version value="2.0.0"/>
<title value="Chalmydia Screening CDS Example Using Common"/>
<status value="draft"/>
<date value="2015-07-22"/>
<description value="Chlamydia Screening CDS Example Using Common"/>
<topic>
<text value="Chlamydia Screening"/>
</topic>
<library value="Library/example"/>
<action>
<title value="Patient has not had chlamydia screening within the recommended timeframe..."/>
<condition>
<kind value="applicability"/>
<expression>
<language value="text/cql"/>
<expression value="NoScreening"/>
</expression>
</condition>
<dynamicValue>
<path value="$this"/>
<expression>
<language value="text/cql"/>
<expression value="ChlamydiaScreeningRequest"/>
</expression>
</dynamicValue>
</action>
</PlanDefinition>
Note that the use of $this
in the path
element here indicates that the result of the expression is the entire result for the action, rather than providing the value for a specific element of the result. In other words, the ChlamydiaScreeningRequest
expression will result in an entire ServiceRequest resource, which is the action to be performed.
The following is an example of a possible result when invoking the $apply
operation on the above ECA Rule:
<CarePlan>
<id value="chlamydia-screening-intervention-cp"/>
<contained>
<RequestGroup>
<id value="chlamydia-screening-intervention-rg"/>
<contained>
<ServiceRequest>
<id value="chlamydia-screening-service-request"/>
<status value="active"/>
<intent value="order"/>
<code>
<coding>
<system value="http://snomed.info/sct"/>
<code value="412761009"/>
<display value="Urine screen for chlamydia (procedure)"/>
</coding>
</code>
<subject>
<reference value="Patient/example"/>
</subject>
</ServiceRequest>
</contained>
<status value="active"/>
<intent value="order"/>
<action>
<type>
<coding>
<system value="http://terminology.hl7.org/CodeSystem/action-type"/>
<code value="create"/>
</coding>
</type>
<resource>
<reference value="#chlamydia-screening-service-request"/>
</resource>
</action>
</RequestGroup>
</contained>
<status value="active"/>
<intent value="order"/>
<subject>
<reference value="Patient/example"/>
</subject>
<activity>
<reference>
<reference value="#chlamydia-screening-intervention-rg"/>
</reference>
<activity>
</CarePlan>
An order set is a pre-defined and approved group of orders related to a particular clinical context (e.g., hypertension treatment and monitoring) or stage of care (e.g., hospital admission to Coronary Care Unit) or a particular grouping (e.g. pediatrics, adult, males over 50, etc.). An order set is typically used as a checklist for clinicians when managing a patient with a specific context. It is a structured collection of orders relevant to that condition or context and presented to the clinician in a computerized provider order entry system (CPOE).
The PlanDefinition resource can represent an Order Set using action definitions to define the orderable items in the order set. The items in an order set are typically organized hierarchically, as a set of sections, sub-sections, etc., with the actions themselves at the very bottom of the structure. In the PlanDefinition resource, each section, and sub-section, as well as the individual items are all represented as action definitions. Each group and/or subgroup may have behavior indicators associated with it, e.g., the number of actions that can/should/must be selected from the group of actions.
For example, the following fragment illustrates the items in a suicide risk order set:
Note that this example is a fragment of a larger example for the PlanDefinition resource, available here.<!-- Suicide Risk Assessment and Outpatient Management -->
<action>
<title value="Suicide Risk Assessment and Outpatient Management"/>
<action>
<title value="Consults and Referrals"/>
<groupingBehavior value="logical-group"/>
<selectionBehavior value="any"/>
<action>
<textEquivalent value="Refer to outpatient mental health program for evaluation and treatment of mental health
conditions now"/>
<definition value="#referralToMentalHealthCare"/>
<dynamicValue>...</dynamicValue>
</action>
</action>
<action>
<title value="Medications"/>
<groupingBehavior value="logical-group"/>
<selectionBehavior value="at-most-one"/>
<action>
<title value="First-Line Antidepressants"/>
<documentation>
<type value="citation"/>
<document>
<extension url="http://hl7.org/fhir/StructureDefinition/cqf-qualityOfEvidence">
<valueCodeableConcept>
<coding>
<system value="http://terminology.hl7.org/CodeSystem/evidence-quality"/>
<code value="high"/>
</coding>
<text value="High Quality"/>
</valueCodeableConcept>
</extension>
<contentType value="text/html"/>
<url value="http://psychiatryonline.org/pb/assets/raw/sitewide/practice_guidelines/guidelines/mdd.pdf"/>
<title value="Practice Guideline for the Treatment of Patients with Major Depressive Disorder"/>
</document>
</documentation>
<groupingBehavior value="logical-group"/>
<selectionBehavior value="at-most-one"/>
<action>
<title value="Selective Serotonin Reuptake Inhibitors (Choose a mazimum of one or document reasons for exception)"/>
<documentation>
<type value="citation"/>
<document>
<contentType value="text/html"/>
<url value="http://dailymed.nlm.nih.gov/dailymed/drugInfo.cfm?setid=6daeb45c-451d-b135-bf8f-2d6dff4b6b01"/>
<title value="National Library of Medicine. DailyMed website. CITALOPRAM- citalopram hydrobromide tablet, film coated."/>
</document>
</documentation>
<groupingBehavior value="logical-group"/>
<selectionBehavior value="at-most-one"/>
<action>
<textEquivalent value="citalopram 20 mg tablet 1 tablet oral 1 time daily now (30 table; 3 refills)"/>
<definition value="#citalopramPrescription"/>
<dynamicValue>...</dynamicValue>
</action>
<action>
<textEquivalent value="escitalopram 10 mg tablet 1 tablet oral 1 time daily now (30 tablet; 3 refills)"/>
</action>
<action>
<textEquivalent value="fluoxetine 20 mg capsule 1 capsule oral 1 time daily now (30 tablet; 3 refills)"/>
</action>
<action>
<textEquivalent value="paroxetine 20 mg tablet 1 tablet oral 1 time daily now (30 tablet; 3 refills)"/>
</action>
<action>
<textEquivalent value="sertraline 50 mg tablet 1 tablet oral 1 time daily now (30 tablet; 3 refills)"/>
</action>
</action>
<action>
<textEquivalent value="Dopamine Norepinephrine Reuptake Inhibitors (Choose a maximum of one or document reasons for exception)"/>
</action>
<action>
<textEquivalent value="Serotonin Norepinephrine Reuptake Inhibitors (Choose a maximum of one or doument reasons for exception)"/>
</action>
<action>
<textEquivalent value="Norepinephrine-Serotonin Modulators (Choose a maximum of one or document reasons for exception)"/>
</action>
</action>
</action>
</action>
In this example, the order set structure consists of:
<!-- Suicide Risk Assessment and Outpatient Management -->
<!-- Consults and Referrals -->
<!-- Refer to outpatient mental health program for evaluation and treatment of mental health conditions now -->
<!-- Medications -->
<!-- First-Line Antidepressants -->
<!-- Selective Serotonin Reuptake Inhibitors (Choose a maximum of one or document reasons for exception) -->
<!-- citalopram 20 mg tablet 1 tablet oral 1 time daily now (30 table; 3 refills) -->
<!-- escitalopram 10 mg tablet 1 tablet oral 1 time daily now (30 tablet; 3 refills) -->
<!-- fluoxetine 20 mg capsule 1 capsule oral 1 time daily now (30 tablet; 3 refills) -->
<!-- paroxetine 20 mg tablet 1 tablet oral 1 time daily now (30 tablet; 3 refills) -->
<!-- sertraline 50 mg tablet 1 tablet oral 1 time daily now (30 tablet; 3 refills) -->
<!-- Dopamine Norepinephrine Reuptake Inhibitors (Choose a maximum of one or document reasons for exception) -->
<!-- Serotonin Norepinephrine Reuptake Inhibitors (Choose a maximum of one or doument reasons for exception) -->
<!-- Norepinephrine-Serotonin Modulators (Choose a maximum of one or document reasons for exception) -->
Each group defines the selection and grouping behavior for the items in the group, as well as providing links to supporting documentation for the particular items in the order set.
A protocol is a pre-defined procedural method for standardizing a set of activities. As examples, protocols can be used within laboratory settings to standardize handling of specimens for specific tests; standardize the treatment steps for a particular condition; or standardize the steps to be taken in a particular research trial.
The PlanDefinition resource can be used to represent a Protocol, using the action definitions to define the steps of the protocol and the relationships between them. Triggering events for each action, as well as applicable conditions can all be specified using the appropriate action elements within the PlanDefinition.
As a simple example, the following fragment shows a portion of a BMI Assessment protocol:
<action>
<!-- step title -->
<title value="Measure BMI"/>
<description value="Measure, Weight, Height, Waist, Circumference; Calculate BMI"/>
<!-- description of activity -->
<textEquivalent value="Weight must be measured so that the BMI can be calculated. Most charts are based on weights
obtained with the patient wearing undergarments and no shoes. BMI can be manually calculated
(kg/[height in meters]2), but is more easily obtained from a nomogram. Waist circumference
is important because evidence suggests that abdominal fat is a particularly strong determinant
of cardiovascular risk in those with a BMI of 25 to 34.9 kg/m2. Increased waist circumference
can also be a marker of increased risk even in persons of normal weight. The technique
for measuring waist circumference is described in the text. A nutrition assessment will
also help to assess the diet and physical activity habits of overweight patients"/>
<goalId value="reduce-bmi-ratio"/>
<condition>
<kind value="applicability"/>
<expression>
<description value="The practitioner must seek to determine whether the patient has ever been overweight.
While a technical definition is provided, a simple question such as 'Have you ever been
overweight?' will accomplish the same goal. Questions directed towards weight history,
dietary habits, physical activities, and medications may provide useful information about
the origins of obesity in particular patients. For those who have not been overweight,
a 2 year interval is appropriate for the reassessment of BMI. While this time span is
not evidence-based, it is believed to be a reasonable compromise between the need to identify
weight gain at an early stage and the need to limit the time, effort, and cost of repeated
measurements."/>
<language value="text/cql"/>
<expression value="exists ([Condition: Obesity]) or not exists ([Observation: BMI] O where O.effectiveDateTime 2 years or less before Today())"/>
</expression>
</condition>
<requiredBehavior value="must-unless-documented"/>
<cardinalityBehavior value="single"/>
<definition value="#procedure"/>
</action>
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 structured data entry within an EHR or other clinical information system. Some types of clinical documents that can be represented via the documentation template artifacts are encounter summaries, procedure notes, patient-reported outcomes, and flowsheets.
The Questionnaire resource provides a basis for representing the structure of a documentation template. Using the expression extensions, the resource can be extended to provide dynamic behavior such as calculating values, showing/hiding content based on answers to questions, and other interactive functionality.
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 module introduces a CQF-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 CQF Questionnaire example illustrates the representation of this questionnaire with the required logic for computation.
The following fragment taken from that example illustrates the use of the expression extension to calculate the TotalScore answer for a PHQ-9 Depression Assessment instrument:
<item>
<extension url="http://hl7.org/fhir/StructureDefinition/cqf-expression">
<valueExpression>
<language value="text/cql"/>
<expression value="CalculateTotalScore"/>
</valueExpression>
</extension>
<linkId value="TotalScore"/>
<code>
<system value="http://loinc.org"/>
<code value="44261-6"/>
</code>
<text value="Total score"/>
<type value="integer"/>
<required value="true"/>
</item>
A quantitative tool to assess the performance of an individual or organization with respect to a specified process or outcome via the measurement of actions, processes, or outcomes of clinical care. Note that the Measure itself does not contain any logic; rather a Library resource is referenced that contains the logic required by the measure, and the various expression elements, such as population criteria, reference named expressions within that library (or libraries).
For example, the following fragment defines how to calculate the controlling high blood pressure measure:
<Measure>
<id value="cbp"/>
<status value="active"/>
<experimental value="true"/>
<description value="Controlling High Blood Pressure Cohort Definition"/>
<topic>
<coding>
<system value="http://loinc.org"/>
<code value="57024-2"/>
</coding>
</topic>
<library value="Library/cbp-logic"/>
<group>
<population>
<code value="initial-population"/>
<criteria value="In Demographic"/>
</population>
</group>
<group>
<population>
<code value="initial-population"/>
<criteria value="BP: Systolic"/>
</population>
</group>
<group>
<population>
<code value="initial-population"/>
<criteria value="BP: Diastolic"/>
</population>
</group>
</Measure>
Work Group Standards Status:Informative |
The Clinical Reasoning module provides resources and operations to enable the representation, distribution, and evaluation of clinical knowledge artifacts such as clinical decision support rules, quality measures, public health indicators, order sets, and clinical protocols. In addition, the module describes how expression languages can be used throughout the specification to provide dynamic capabilities.
Clinical Reasoning involves the ability to represent and encode clinical knowledge in a very broad sense so that it can be integrated into clinical systems. This encoding may be as simple as controlling whether or not a particular section of an order set appears based on the conditions that a patient has, or it may be as complex as representing the care pathway for a patient with multiple conditions.
The Clinical Reasoning module focuses on enabling two primary use cases:
To enable these use cases, the module defines several components that can each be used independently, or combined to enable more complex functionality. These components are:
These basic components can then be used to enable a broad variety of clinical decision support and quality measurement use cases, including knowledge sharing, decision support services, and clinical quality assessment and reporting. The topics below provide more detailed discussion on each of these components and uses:
Topic | Description |
---|---|
Overview and Background | If you are interested in the background and development of the FHIR Clinical Reasoning module, this topic covers where it came from and why it exists. See also the general FHIR introductions for clinicians, developers or architects |
Using Expressions | If you want to see how to add dynamic capabilities to FHIR resources using expressions, start here. |
Definitional Resources | If you want to see how to describe definitional resources using the ActivityDefinition resource, start here. |
Representing Knowledge Artifacts | If you want to represent knowledge artifacts such as Event-Condition-Action rules, Order Sets, or Clinical Protocols, start here. |
Sharing Knowledge Artifacts | If you want to share and distribute knowledge artifacts, start here. |
Clinical Decision Support Service | If you want to use the Clinical Reasoning module to provide or use Clinical Decision Support services, start here. |
Quality Reporting | If you want to define or report clinical quality measures, start here. |
From the perspective of a Knowledge Author, this module describes an approach to representing knowledge artifacts within FHIR.
From the perspective of a Knowledge Content Provider, this module defines search functionality for using a FHIR server as a knowledge artifact repository.
From the perspective of a Knowledge Evaluation Service Provider, this module defines operations and profiles in support of evaluating quality measures, and defining and using CDS Hooks services.
And finally, from the perspective of a Knowledge Evaluation Service Consumer, this module defines the expected available operations and behavior of a knowledge evaluation service.
Resource | Description |
---|---|
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. |
Extension | Description |
---|---|
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. Used in evaluated resource bundles as part of reporting measure results for a patient to identify resources that contributed to the patient's membership in a particular population criteria. |
qualityOfEvidence | An extension that can be applied to indicate the quality of evidence in support of a particular artifact or recommendation. |
relativeDateTime | An extension that can be applied to define a date/time value relative to another event. |
strengthOfRecommendation | An extension that can be applied to indicate the strength of a recommendation. |
Profile | Description |
---|---|
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 |
CDS Hooks PlanDefinition | Defines a PlanDefinition that implements the behavior for a CDS Hooks service |
CDS Hooks RequestGroup | Defines a RequestGroup that can represent a CDS Hooks response |
Service | Description |
---|---|
Knowledge Repository | Defines minimum service capabilities for a knowledge repository. |
Measure Processor | Defines minimum service capabilities for a measure processor. |
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. As with the decision support guidance responses, 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.
Use Case | Description |
---|---|
Providing a dynamic value for a resource element | Using expressions to define the value for an element of a FHIR resource. |
Defining a CQL library | Using the Library resource to incorporate a Clinical Quality Language library for use in FHIR resources. |
Defining a Model Definition artifact | Using the Library resource to incorporate the definition of an information model for use with expressions in FHIR. |
Defining an Event Condition Action rule | Using the PlanDefinition resource to represent an event-condition-action rule in FHIR. |
Defining a Referral Request activity | Using the ActivityDefinition resource to define a referral request activity that can be used as part of a knowledge artifact. |
Defining a Medication Request activity | Using the ActivityDefinition resource to define a medication request activity that can be used as part of a knowledge artifact. |
Defining an Order Set | Using the PlanDefinition resource to represent an order set. |
Defining a Protocol | Using the PlanDefinition resource to represent a protocol. |
Defining a Questionnaire with dynamic content | Using the Questionnaire resource and expression extensions to add dynamic functionality to a FHIR Questionnaire. |
Obtaining guidance from a Decision Support Service | Using the $evaluate operation to request and process guidance from a decision support service. |
Defining a Measure | Using the Measure resource to represent a clinical quality measure. |
Evaluating a Measure | Using the $evaluate-measure operation to request calculation of a clinical quality measure. |
Applying an ActivityDefinition | Using the $apply operation to realize the intent resource defined by an ActivityDefinition. |
Applying a PlanDefinition | Using the $apply operation to realize a plan definition for a specific context. |
Representing Quality of Evidence/Strength of Recommendation | Using the qualityOfEvidence and strengthOfRecommendation extensions to indicate ratings associated with evidence for a particular artifact or recommendation. |
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 content at this point is capable of supporting the two primary use cases of sharing and evaluation in both domains and for a broad variety of artifacts.
In particular, 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 focused on improving the measure can share a common library that describes the criteria for detecting when Chlamydia Screening is required in a patient. The decision support rule applies these criteria to determine when and how to impact a workflow, while the quality measure uses these same criteria to determine whether the screening goal has been met for a patient or population. In addition, the resources defined in this module use common patterns for describing the structure of artifacts and their associated metadata, enabling a consistent approach to the sharing and distribution of clinical knowledge artifacts.
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. This usage has generated feedback resulting in the addition of several new profiles, as well as guidance for using the Clincal Reasoning module with CDS Hooks and for quality reporting. Although this feedback resulted in some substantive changes, there were comparatively few, and the goals of the module for the next year are to push towards higher maturity levels and continue to seek implementation feedback.
The goals of the module over the next year 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 within a year.
We are actively seeking comments on all areas of the module, with particular focus on supporting the following scenarios:Feedback is welcome here.
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 effort transitioned to HL7's Clinical Quality Information (CQI) and Clinical Decision Support (CDS) Work Groups in 2016.
The Clinical Quality Framework is focused on harmonizing the historically disjointed specifications used by the Clinical Quality Measurement and Clinical Decision Support communities. Specifically, the initiative has focused on the specifications used to represent knowledge artifacts within the two communities. The strategy employed has been to break the conceptual content of knowledge artifacts into three core components, to define common standards for these core components, and to re-use these common standards for both clinical decision support and clinical quality measurement:
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, and with its core requirements realized in FHIR as the Quality Improvement Core (QICore) profiles. Ongoing work in this area is focusing on coordination with the Clinical Information Modeling Initiative (CIMI) and a methodology for producing FHIR profiles from CIMI models. Currently, the QICore FHIR profiles (which are in turn derived from the US-Core profiles) can be used to model clinical quality data, and to present a consistent model for use in authoring and evaluating clinical quality artifacts.
Finally, 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) (produced by the Health eDecisions (HeD) Standards and Interoperability (S&I) initiative), and the Health Quality Measures Format (HQMF).
As part of the ongoing CQF initiative pilot efforts, these developing specifications are being used to support knowledge artifact sharing, as well as evaluation of knowledge artifacts as part of decision support request/response and measure evaluation.
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.
The approach and representations within this guide are derived from and intended to be consistent with the following specifications:
This material includes SNOMED Clinical Terms ® (SNOMED CT®), which are used by permission of the International Health Terminology Standards Development Organisation (IHTSDO). All rights reserved. SNOMED CT was originally created by the College of American Pathologists. "SNOMED ®" and "SNOMED CT ®" are registered trademarks of the IHTSDO.
This material contains content from Logical Observation Identifiers Names and Codes (LOINC®) (http://loinc.org). The LOINC table, LOINC codes, and LOINC panels and forms file are copyright © 1995-2017, Regenstrief Institute, Inc. and the LOINC Committee and available at no cost under the license at http://loinc.org/terms-of-use.
This material contains content from the Unified Code for Units of Measure (UCUM) (http://unitsofmeasure.org). The UCUM specification is copyright © 1999-2017, Regenstrief Institute, Inc. and available at no cost under the license at http://unitsofmeasure.org/trac/wiki/TermsOfUse.
This material contains quality measure content developed by the National Committee for Quality Assurance (NCQA). The measure content is copyright (c) 2008-2017 National Committee for Quality Assurance and used in accordance with the NCQA license terms for non-commercial use.
The guidance in this module is the work of a joint project between the HL7 Clinical Quality Information and Clinical Decision Support Work Groups with the co-sponsorship of the FHIR Infrastructure, Implementable Technology Specifications, and Service Oriented Architecture Work Groups.
Work Group Maturity Level: 2 | Standards Status: Trial Use |
The Measure resource builds on the general approach to representing knowledge artifacts and adds the metadata and structure information that is specific to quality measures:
Quality measures follow a generally hierarchical structure that defines:
Population Groups: Groups of population criteria that define a particular area of measurement. A given measure may include any number of population groups, each with different criteria for the various measure components.
Population Quality Measures are often focused on evaluating from a patient perspective, but this is not always the case. The subject
element of the Measure indicates the intended subjects of a measure. If no subject
is specified, the measure subject is Patient, but Practitioners, Organizations, Locations, or even Devices can also be the subject of a measure.
The following table provides a requirements mapping from the content of an eMeasure to the elements defined in the Measure resource:
eMeasure | Cardinality | Element | Notes |
---|---|---|---|
Title | 0..1 | Measure.title | |
Identifier | 0..1 | Measure.identifier | identifier type code as http://hl7.org/fhir/cqi/ecqm/Measure/Identifier/cms |
Version Number | 0..1 | Measure.version | |
NQF Number | 0..1 | Measure.identifier | identifier type code as http://hl7.org/fhir/cqi/ecqm/Measure/Identifier/nqf |
GUID | 0..1 | Measure.identifier | identifier type code as http://hl7.org/fhir/cqi/ecqm/Measure/Identifier/guid |
Measure Steward | 0..1 | Measure.publisher | |
Measure Developer | 0..1 | Measure.contributor | type.code of author |
Endorser | 0..1 | Measure.contributor | type.code of endorser |
Description | 0..1 | Measure.description | |
Copyright | 0..1 | Measure.copyright | |
Reference | 0..* | Measure.relatedArtifact | type.code of citation |
Disclaimer | 0..1 | disclaimer | String (containing Markdown) |
Measure Scoring | 0..1 | scoring | Code, e.g. proportion, CV |
Measure Type | 0..1 | type | Code, e.g. process, outcome |
Risk Adjustment | 0..1 | riskAdjustment | String |
Rate Aggregation | 0..1 | rateAggregation | String |
Rationale | 0..1 | rationale | String (containing Markdown) |
Clinical Recommendation Statement | 0..1 | clinicalRecommendationStatement | String (containing Markdown) |
Improvement Notation | 0..1 | improvementNotation | String, e.g. Higher score indicates better quality |
Definition | 0..1 | definition | String (containing Markdown) |
Guidance | 0..1 | guidance | String (containing Markdown) |
As with other knowledge artifacts, logic is included by referencing a Library resource. Although the base resource allows for the measure to reference any number of libraries, for simplicity of managing sharing, measures should reference only one Library, the primary measure library, and that library should contain all the named expressions required to define the measure structure.
Note that this approach does not preclude sharing of logic between measures, it only requires that that sharing be explicitly done as dependencies within the referenced libraries, rather than allowing a measure to reference multiple libraries directly.
A measure can specify various types of populations, depending on the type of measure scoring being used. The following table shows which population criteria types are required (R), optional (O), or not permitted (NP) for proportion, ratio, and continuous variable measures. This table is adapted from Table 1 from the HQMF Release 1 Normative specification, and Table 2.1 from the QDM-based HQMF IG.
MeasureType | Initial Population | Denominator | Denominator Exclusion | Denominator Exception | Numerator | Numerator Exclusion | Measure Population | Measure Population Exclusion |
---|---|---|---|---|---|---|---|---|
Proportion | R | R | O | O | R | O | NP | NP |
Ratio | R | R | O | NP | R | O | NP | NP |
Continuous Variable | R | NP | NP | NP | NP | NP | R | O |
Cohort | R | NP | NP | NP | NP | NP | NP | NP |
The Measure resource then identifies specific named expressions within the referenced primary measure library that define the criteria for each population. For example, the following fragment illustrates the population criteria definitions for the CMS146 measure example:
<group id="CMS146-group-1">
<population>
<code>
<coding>
<code value="initial-population"/>
</coding>
</code>
<criteria value="CMS146.InInitialPopulation"/>
</population>
<population>
<code>
<coding>
<code value="numerator"/>
</coding>
</code>
<criteria value="CMS146.InNumerator"/>
</population>
<population>
<code>
<coding>
<code value="denominator"/>
</coding>
</code>
<criteria value="CMS146.InDenominator"/>
</population>
<population>
<code>
<coding>
<code value="denominator-exclusion"/>
</coding>
</code>
<criteria value="CMS146.InDenominatorExclusions"/>
</population>
</group>
Quality measures often specify multiple rates, with different population crtiteria for each rate. This is different than stratifying the scores for the same population. For quality measures that contain multiple rates, the Measure will contain multiple group elements, where the criteria are specified once for each group. The id
attribute of the group
element is used to uniquely identify the group within the measure, as well as within the quality reporting results.
Continuous variable measures may include a measure observation section. This section defines variables (for example, time from check-in to time of antibiotic administration) used to measure particular aspects of a process or outcome. Note that measure observations are not population criteria in that they do not filter the population in any way. Rather, measure observations are data elements, to be collected from each subject that satisfies the population criteria, which are used to calculate the results for each member of the population.
Stratifiers and supplemental data are specified using the stratifier
and supplementalData
elements of the Measure resource. Stratification criteria are specified either as a reference to a CQL named expression within a Library (e.g. CMS146.AgesUpToNine
), or as FHIR resource paths (e.g. Patient.gender
). When the stratification criteria is an expression, the stratification will yield as many result groups as the expression returns. For example, if the expression returns a boolean, then there would be two stratification groups: true and false. When the stratification criteria is a FHIR resource path, there will be as many stratification groups as possible values for the resource path. For example, specifying Patient.gender will yield four stratification groups since FHIR has four gender codes: male, female, other, and unknown.
Supplemental data elements are also specified using FHIR resource paths, however, supplemental data only results in groups in the summary measure report. For individual-level reports, supplemental data elements are reported as Observation resources and included by reference in the evaluateResource for the individual-level report.
The CMS146 example measure illustrates the stratification and supplemental data described above:
The data criteria for the primary library defines the data of interest in the measure as a set of DataRequirement elements. Each data requirement identifies specific types of data along with constraints that the data must meet. For example, one data requirement for CMS 146 identifies FHIR Condition resources that represent confirmed diagnoses of acute pharyngitis. Other data requirements for this measure include Encounters, DiagnosticReports and other FHIR resources representing specific data that is used to calculate the measure.
Specifying the data criteria in this way enables the following use cases:
Data criteria can be specified statically, or they can be inferred from the expressions referenced by the measure. The $data-requirements
operation can be invoked to retrieve the aggregate data requirements for the measure. This approach has two advantages:
module-definition
library.The Health Quality Measure Format (HQMF) defines the electronic representation of an eMeasure but does not define a mechanism for invoking an eMeasure. FHIR defines both the representation of resources and a general mechanism for interacting with them via the OperationDefinition resource. Prior sections of this specification described the Measure representation of an eMeasure, this section describes the $evaluate-measure
operation that is used to invoke an eMeasure and obtain the results.
FHIR defines a standard set of common interactions that include read, update, delete and search. In addition, FHIR defines a standard set of extended operations that can be performed on resources, resource types and system wide. The standard operations include profile validation, concept translation and value set expansion. FHIR also supports custom operations via the FHIR OperationDefinition resource. This resource offers a means to create a formal definition of a custom operation that can be performed on a FHIR server. For the purposes of measure evaluation we define a new custom operation with a code of $evaluate-measure.
The $evaluate-measure operation has the following properties:
The effect of invoking the $evaluate-measure operation is to calculate the quality measure according to the supplied parameters and to return a MeasureReport resource through which the results will be made available. Note that because measure calculation might not be instantaneous, the MeasureReport resource provides a mechanism to handle long running calculations.
GET [base]/Measure/$evaluate-measure?measure=CMS146&periodStart=2014&periodEnd=2014
GET [base]/Measure/CMS146/$evaluate-measure?periodStart=2014&periodEnd=2014
The above examples show how to obtain the results of evaluating the eMeasure with id "CMS146" for all patients over a measurement period that consists of all of 2014. Some items of note:
[base]/Measure
which is the type of resource and specifies the eMeasure to evaluate using a parameter [base]/Measure/CMS146
which is the Measure instance that represents that measure so there's no need to also include a reference to the eMeasure in the operation parametersHTTP GET
method is used since the $evaluate-measure
operation is idempotent[base]
is used as a shortcut for the base URI of the FHIR serverThe next example demonstrates how to obtain the results of evaluating the eMeasure with id "CMS146" for the patient with id "124" over a measurement period that consists of the first three months of 2014.
GET [base]/Basic/CMS146/$evaluate-measure?subject=124&periodStart=2014-01&periodEnd=2014-03
When eCQMs are represented with the Health Quality Measure Format (HQMF), a single HQMF document represents both the measure itself and the request. Meanwhile, the responses are represented as Quality Reporting Document Architecture (QRDA) documents. QRDA documents come in two flavors: Category I for individual patient reports and Category III for population reports.
When eCQMs are represented with FHIR resources, the measure is represented as a Measure resource, and the request is an HTTP GET
conforming to the OperationDefinition described above. Meanwhile, the responses are represented as MeasureReport resources. Like QRDA, the MeasureReport allows for Category I (individual), Category II (subject-list), and Category III (population) reports.
A MeasureReport will contain one group of data for each group specified in the corresponding Measure, consisting of a set of population elements, one for each criteria defined in each group.
In addition, each group will contain stratifiers with a value stratum for each value defined by the stratifier criteria, for each criteria defined in the measure.
When using a MeasureReport resource to represent the results of an individual calculation, the MeasureReport SHALL have a type-code of "individual" and SHALL have a reference to the subject of the report. In addition, the result SHOULD include a reference to a Bundle containing the subject-specific resources that were used to calculate the result.
See the MeasureReport examples for a detailed illustration of how the data elements involved in the calculation of the measure are communicated through the evaluatedResources
element.
When using a MeasureReport resource to represent a subject-list, the MeasureReport SHALL have a type-code of "subject-list" and if a subject reference is present, it SHALL be a reference to a Group. In addition, the resource SHALL include for each population a reference to a List resource that references individual level MeasureReport resources for the same measure, one for each subject in the overall population.
For example, the initial population report, in addition to providing the count, provides a reference to a List resource that identifies each of the subjects that make up that population. For each of those subjects, the List will contain a reference to an individual-level report for that subject. Note that for very large populations, implementations MAY decide to limit the size of the result, either by returning an error indicating the request is too costly, or by returning a partial result, so long as there is an indication that the report is only a partial response. In addition, we are actively seeking feedback on how best to approach evaluation of quality measures on large populations, including the use of bulk data formats.
In addition, implementations may return a MeasureReport with a status of pending, indicating that the evaluation is in progress. In this case, clients can request the MeasureReport resource until the status changes to complete.
Work Group Maturity Level: 2 | Standards Status: Trial Use |
Part of defining knowledge artifacts such as order sets, protocols, and decision support rules is describing in a patient- or context-independent way the activities to be performed. For example, when defining an order set, the orderable items must be described with enough detail to enable the creation of the items when the order set is applied. These descriptions can be thought of as templates for the creation of patient- or context-specific resources and are often referred to as definitional resources, to distinguish them from intent resources (that signal an intention to take some action for a specific patient), as well as event resources (that signal that some action has actually been taken for a patient).
In the most general case, these definitional resources only need to describe the most basic aspects of the activity to be performed, such as:
However, this level of conceptual description often does not carry enough information to enable computable description of activities. For example, medication activities will often involve specific drug and dosage information that must be captured as part of the definition. Further, it is often the case that the values for the elements of resources to be created cannot be specified exactly as part of the definition, but must be specified using a formula that allows for the calculation to be based on patient- or context-specific information.
The ActivityDefinition resource supports the description of definitional resources within FHIR:
Who | participantType | Specifies the type of participant that should perform the activity. |
What | kind and code | Specifies the type of activity to be performed. |
When | timing | Specifies when the activity should be performed. |
Where | location | Specifies where the activity should be performed. |
Why | reason, documentation | Specifies why the activity should be performed. |
For example, the following fragment illustrates a definition to create a referral request:
<ActivityDefinition>
<description value="refer to primary care mental-health integrated care program for evaluation and treatment
of mental health conditions now"/>
<kind value="ServiceRequest"/>
<code>
<coding>
<system value="http://snomed.info/sct"/>
<code value="306206005"/>
</coding>
</code>
<timingTiming>
<event>
<extension url="http://hl7.org/fhir/StructureDefinition/cqf-expression">
<valueExpression>
<language value="text/cql"/>
<expression value="Now()"/>
</valueExpression>
</extension>
</event>
</timingTiming>
<participantType value="practitioner"/>
</ActivityDefinition>
Note the use of an expression to represent the value of the timing element as Now()
.
For medication activities, the ActivityDefinition resource has some basic elements such as the product
and quantity
, and dosageInstruction
but there are cases where elements that need to be set on the resulting MedicationRequest are not present on the ActivityDefinition (such as dispenseRequest
). In those cases, the dynamicValue
expression elements can be used to describe the values for elements that are present on the target resource, but not in the definitional resource. For example:
<ActivityDefinition>
<id value="citalopramPrescription"/>
<status value="draft"/>
<category value="drug"/>
<productReference>
<reference value="#citalopramMedication"/>
</productReference>
<dynamicValue>
<path value="dispenseRequest.numberOfRepeatsAllowed"/>
<expression>
<language value="text/cql"/>
<expression value="3"/>
</expression>
</dynamicValue>
<dynamicValue>
<path value="dispenseRequest.quantity"/>
<expression>
<language value="text/cql"/>
<expression value="30 '{tbl}'"/>
</expression>
</dynamicValue>
</ActivityDefinition>
Note to implementers: Although there is currently only one definitional resource defined (ActivityDefinition), the concept is general, and this was a deliberate design decision to avoid the overhead of defining and maintaining a different definitional resource for every category of request. We anticipate that as the use cases of ActivityDefinition require more specialized elements to be added, the resource may be split.
Work Group Maturity Level: 2 | Standards Status: Trial Use |
There are many kinds of supporting documentation that can be provided with clinical quality improvement artifacts, from detailed documentation, to references to the guidelines from which artifacts are derived, to grades and scores indicating quality of evidence or the strength of a recommendation.
The relatedArtifact
element present on the Clinical Reasoning Module artifacts allows supporting documentation to be provided, either in the form of a reference to a resource, such as a DocumentReference, or as a reference to external content as an Attachment.
This same mechanism can be used to attach supporting documentation to the actionDefinition
elements of a PlanDefinition, allowing supporting documentation for specific steps in a rule or protocol, as well as to the action
elements of a RequestGroup to provide supporting documentation for individual recommendations as part of the result of a decision support evaluation.
<documentation>
<type value="justification"/>
<document>
<extension url="http://hl7.org/fhir/StructureDefinition/cqf-qualityOfEvidence">
<valueCodeableConcept>
<coding>
<system value="http://terminology.hl7.org/CodeSystem/evidence-quality"/>
<code value="high"/>
</coding>
<text value="High Quality"/>
</valueCodeableConcept>
</extension>
<contentType value="text/html"/>
<url value="http://psychiatryonline.org/pb/assets/raw/sitewide/practice_guidelines/guidelines/mdd.pdf"/>
<title value="Practice Guideline for the Treatment of Patients with Major Depressive Disorder"/>
</document>
</documentation>
In all these cases, the qualityOfEvidence and strengthOfRecommendation extensions can be used to grade the information being provided. For example, the qualityOfEvidence extension can be attached to a DocumentReference to indicate a rating for the quality of the evidence represented in the document. Similarly, a strengthOfRecommendation extension can be attached to the action element of a RequestGroup to indicate the strength of the recommendation being made.
These extensions are bound to example valuesets based on the GRADE rating systems for quality of evidence and strength of recommendation. Other rating systems could be used by defining the appropriate valuesets and profiles to make use of them.
Work Group Maturity Level: 2 | Standards Status: Trial Use |
This topic discusses the use of expression logic within FHIR resources using expression languages such as FHIRPath and Clinical Quality Language (CQL). The clinical reasoning module resources use the Expression data type to represent logic that enables dynamic functionality to be utilized directly within the Clinical Reasoning resources, as well as within FHIR resources more generally using extensions.
In general, the use of expressions involves the following elements:
This general pattern is used to represent expression logic throughout the resources in the Clinical Reasoning module and allows expression logic to be represented at different levels:
For example, the dynamicValue
element of the ActivityDefinition and PlanDefinition resources contains an expression
element directly. However, for resources that do not define these elements, the cqf-expression extension can be used to enable expression information to be associated with any FHIR resource.
The description element can be used either alone, to communicate unstructured logic, or together with the other elements to provide a natural language narrative for the formal representation. The element is typically optional to enable usage in both contexts. Note that if both an expression and a description are provided, the expression is considered to override the description element, although the description should reflect the semantics of the expression as accurately as possible.
<dynamicValue>
<path value="timing.event"/>
<expression>
<description value="Now"/>
</expression>
</dynamicValue>
The language element identifies the expression language used to represent the logic. The ExpressionLanguage code system defines support for FHIRPath, Clinical Quality Language, and FHIR Query (FHIR's RESTful query syntax), but support for other languages can also be provided.
The language element is specified using the Media Type of the language. For inline expressions using FHIRPath and Clinical Quality Language, the media type SHALL be specified as follows:
text/fhirpath
text/cql
For example, the following fragment illustrates the use of CQL to define a dynamicValue as part of an activity definition:
<dynamicValue>
<path value="timing.event"/>
<expression>
<language value="text/cql"/>
<expression value="Now()"/>
</expression>
</dynamicValue>
Note that when extensions are used, the same Expression structure is used for the extension. For example:
<event>
<extension url="http://hl7.org/fhir/StructureDefinition/cqf-expression">
<valueExpression>
<language value="text/cql"/>
<expression value="Now()"/>
>/valueExpression>
</extension>
</event>
The expression element specifes the formal representation of the expression logic in the identified expression language. The expression may be inline, as in the above examples, or it may be a reference to a named expression defined in a logic library. For example, the following fragment illustrates the use of a named expression to define a dynamicValue as part of an activity definition:
<dynamicValue>
<path value="reasonCode"/>
<expression>
<language value="text/cql"/>
<expression value="RiskAssessmentScore"/>
</expression>
</dynamicValue>
The example specifies that the reasonCode
element should be set to the result of evaluating the RiskAssessmentScore
expression. This expression is expected to be present in a Library referenced by the containing resource:
<library value="Library/mmi-suiciderisk-orderset-logic"/>
If the containing resource has a library
element (such as ActivityDefinition and PlanDefinition), and only specifies a single library, the expression is evaluated as though it is in scope in that library. However, if the resource references multiple libraries, the referenced expression must be qualified with the name of the library in order to ensure unambiguous resolution. For example, the following fragment illustrates multiple libraries being referenced by the containing resource:
<library value="Library/mmi-suiciderisk-orderset-logic"/>
<library value="Library/another-orderset-logic"/>
The following fragment illustrates how an expression reference (reasonCode) would be qualified in the case of multiple library references:
<dynamicValue>
<path value="reasonCode"/>
<expression>
<language value="text/cql"/>
<expression value=""mmi-suiciderisk-orderset-logic".RiskAssessmentScore"/>
</expression>
</dynamicValue>
Note the use of the "
escape sequence on the library scope. This escape sequence is needed for XML attributes delimited with double quotes to avoid premature closure of the attribute, which would result in malformed XML. The following is an example of how to escape double quotes in JSON:
"dynamicValue": [
"path": "reasonCode",
"expression": {
"language": "text/cql",
"expression": "\"mmi-suiciderisk-orderset-logic\".RiskAssessmentScore"
}
]
For resources that do not have a library
element, the library extension can be used to reference a library from any resource. The library extension enables a resource to add a reference to a library when it could not otherwise.
For simplicity, resources that use logic libraries SHOULD reference at most one library to avoid the need to qualify expression references. Take, for example, the case of updating a library reference in a resource. If the resource has multiple library references, then every expression qualifier that referred to the previous library must be updated. However, if the libraries were combined into a single reference, then only the reference would need to be updated.
In general, when an expression is evaluated, it is evaluated in the context of the containing resource. This means that the resource is available within the expression so that the current values of the resource can be accessed.
Note that this is the general case for establishing the evaluation context for expressions. Many of the clinical reasoning resources, such as the Measure, will define specific behavior for the evaluation context that overrides this general behavior.
For FHIRPath expressions, the expression is evaluated with the containing resource using the %context
environment variable. For example, when evaluated against a Patient resource, the following expression will return all given
elements of all name
elements for the patient:
%context.name.given
And because FHIRPath expressions can be used within CQL, the same approach works for accessing the context in a CQL expression.
In addition to the evaluation context, the expression may access parameters defined by referenced libraries. As with expression identifier resolution, the name of a parameter can be used directly so long as there is only one library referenced by the resource. Otherwise, the name of the library must be used to qualify the parameter name to avoid ambiguity.
If the expression uses parameters, a Library SHALL be used to define the required parameters.
Note that the way that parameters are bound to the expression from the evaluation context varies based on where the evaluation is taking place, but in general, the parameters are bound by name to the parameters defined in the evaluation operation. For example, in the $apply
operation, parameters defined by libraries can be provided as named parameters in the operation invocation. For more details on how parameter binding occurs within each context, refer to the specific documentation for the $apply
, $evaluate
, and $evaluate-measure
operations.
The data requirements for a given expression describe the minimum data required in order to achieve a successful evaluation of the expression. More data may in general be provided, but not less. For example, an expression may reference laboratory test results for hemoglobin A1c tests over the past two years. If a system provides data for the last three years, the expression can still be successfully evaluated, but if a system provides data for only the last year, the expression 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 an expression. 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 an expression.
Within CQL, data requirements can be inferred based on the retrieve expressions used. This process is described in detail in the Clinical Quality Language Specification, but in general, the set of data requirements is represented by elements of the DataRequirement type. This type is similar to a parameter definition, with the following differences:
codeFilter
and dateFilter
elements.mustSupport
element.For CQL expressions that contain retrieves, a Library SHOULD be used to describe the data requirements. However, the $data-requirements operation can also be used to infer the data requirements based on usage within the expression.
FHIRPath is a lightweight path-based navigation language intended to provide simple but flexible access to graph-structured data. It is defined as a general purpose specification available here.
FHIRPath is used throughout the FHIR specification whenever path selection is needed, such as in the definition of search parameters, or when describing invariants as part of the definition of resources and profiles. FHIRPath expressions generally provide a simple and effective means of navigating and accessing the elements of FHIR resources to retrieve data.
Clinical Quality Language (CQL) defines a high-level clinically-oriented syntax to enable formal representation of clinical logic. It is defined as a general purpose specification available here:
HL7 Standard: Clinical Quality Language Specification, Release 1.3.
CQL is used to describe the logic used by knowledge artifacts such as clinical decision support rules, quality measure logic, and conditions and actions within order sets and protocols. CQL expressions generally provide a means of computing new information from existing data.
Work Group Standards Status:Informative |
This Clinical Module focuses on the FHIR Resources that represent core clinical information for a patient. The information contained in these Resources are those frequently documented, created or retrieved by healthcare providers during the course of clinical care. Resources generated during the course of diagnostic studies can be found in the Diagnostics Module, whereas the Resources related to medication ordering and administration process can be found in the Medications Module.
As an introduction to FHIR APIs and Resources, please see the Developer's Introduction or Clinical Introduction in the Overview section of the Foundation Module.
The Clinical Module covers the following resources:
FHIR Resources have a low, moderate or high levels of complexity with respect to the number of primary and child elements as well as the number of referenced Resources, found in this module and others. To better understand the relationships between Resources, we recommend beginning with the lower complexity, core Resources such as Patient, Condition, and FamilyMemberHistory before addressing a high complexity Resource such as CarePlan.
The clinical resources often represent patient-related data, and as such are susceptible to data breaching. Necessary privacy and security provision must be in place for searching and fetching this information. For more general considerations, see the Security and Privacy module.
Over the next 18 months, we will continue to advance the resources through the Maturity Levels through the process of development and testing of the Resources. We anticipate more widespread implementation of core Resources such as Condition. Complex Resources such as CarePlan are dependent on the maturation of its referred Resources and are expected to mature more gradually. The clinical community will need to develop use cases to test and further mature the ServiceRequest Resource at opportunities such as the Clinicians on FHIR sessions at the HL7 Working Group Meetings.
Maturity Level: N/A | Standards Status:Informative |
CDA is HL7's most widely adopted HL7 v3 standard. It provides both a standardized header containing metadata about the document as well as the ability to convey a wide variety of clinical content organized into various sections. The document content can be un-encoded, such as a PDF, through to a fully encoded HL7 v3 instance.
NOTE: While FHIR can be used to create documents using the Composition Resource, FHIR can also be used to exchange traditional CDA R2 documents making use of the DocumentReference resource, and handling the CDA document itself as a binary attachment (as XDS does).
Clinical document focus: As its name implies, Clinical Document Architecture is limited to "clinical" use cases. The CDA model does not support exchange of content not deemed to have clinical relevance, such as financial information, and is limited to documents that deal with patients. (In some cases, such as the HL7 Structured Product Labeling standard, non-patient-specific CDA-like specifications are created to get around this limitation.) FHIR documents have no limitation on their content and can have subjects other than patients.
Human readability approach: CDA and FHIR both require that content be human-readable and define specific rules for how the human readable text is presented.
Clinical Statement vs. resources: In CDA, the "content" of the document is expressed using a complex and extremely abstract model based on HL7's "Clinical Statement" project. Its purpose is to allow implementers to express pretty much any clinical concept in any degree of rigor and granularity. (In practice, there are limitations built into the CDA model that make the expression of certain clinical concepts challenging). This model provides significant power, but also presents challenges. The first is that RIM modeling expertise is required in order to express any particular piece of clinical information. It isn't obvious how to represent things like allergies or surgery or blood pressure "out of the box". Templates are required to support interoperability. The second is that common clinical concepts can be (and frequently are) modeled differently in different circumstances. With FHIR, all clinical (and non-clinical) content in a message is handled by referencing existing resource definitions. These resources make it clear how to represent common structures like allergies and blood pressure "out of the box" and ensure that there's only one way for core content to be represented. It does however create the limitation that an appropriate resource must have been defined in order to share content. In the early stages of FHIR development, it may be necessary to make use of the Basic resource if an appropriate standard resource has not yet been defined.
Templates and Profiles: As discussed above, CDA relies on the presence of templates in order to understand the meaning of instances. While the meaning can theoretically be determined by looking at RIM attributes and codes, the reality is that this is often not safe or sufficient. As such, pretty much every CDA instance includes templateId attribute values scattered throughout the instance to define meaning. With FHIR, meaning is defined by the resource. Profiles can be used to define extensions, but they never refine the meaning of core elements. While the profiles used in constructing a particular instance can be declared within the instance via tags such declaration is not required.
Mark-up language: CDA defines its own XML syntax for narrative content, loosely based on HTML. FHIR makes use of a constrained set of XHTML which is somewhat more expressive than the CDA markup. Conversions from FHIR to CDA will need to take these constraints into account (or alternatively provide a fully rendered version of the document).
CDA is a type of HL7 v3 specification. Therefore, all considerations that apply to v3 messaging also apply to CDA. In addition, the following topics are specific to CDA implementations.
What to map: The right-hand side (clinical content) portion of the CDA model qualifies as an abstract model as discussed above. While the CDA header can reasonably be mapped to the HL7 Composition resource and related resources, mappings between FHIR and CDA should be done at the template level rather than the CDA specification itself.
Human readable granularity: With FHIR, narrative only exists for the resources at the root of each section. With CDA, narrative exists for each section. Usually this means the narrative in CDA and FHIR will correspond. However, in some cases, a section will contain other sub-sections. In CDA, these "container" sections can have narrative. In FHIR, they cannot. Applications will need to have some way of managing this if converting.
Discrete to human-readable linkages: To ensure semantic traceability, both FHIR and CDA allow establishing linkages between text in the narrative and specific discrete elements in the encoded part of a document. If converting between FHIR and CDA, these linkages need to be converted as well. However, this is complicated by the fact that the granularity at which linkages can occur is different between the two specifications. In CDA, linkages can only occur at the level of a section or one of a couple of the entry types. With FHIR, linkages can occur at any level at all, including individual data type components or even portions of extensions. Converting from CDA to FHIR will be straight-forward, however there will be information loss when converting the other way.
Maturity Level: N/A | Standards Status:Informative |
HL7 has produced a number of other standards that don't overlap with FHIR as closely as those listed above, primarily because they aren't focused solely on information exchange. However, they deserve a brief mention:
This specification defines a number of functional behaviors for Electronic Health Record systems. FHIR is a healthcare information exchange standard that can be used to satisfy some of these functional behaviors. Details on how FHIR fits into the EHR-FM can be found here
CCOW is a standard for allowing independent systems to synchronize context on a single workstation, providing a seamless interface for the user of that workstation (e.g. ensuring consistent user authentication, display of the same patient, display of the same order, etc.) In theory, FHIR resources could be used as an alternative CCOW implementation technology, however the business case for doing this is not clear. CCOW profiles include HL7 v2 mappings. These mappings can be used to help identify the equivalent FHIR data elements when establishing CCOW linkages in FHIR-based systems.
Arden Syntax is a language for defining decision support rules. These rules reference data elements that are used as part of the decision making process. However, the specification does not define how these data elements are identified. FHIR element and extension identifiers would provide one mechanism for identifying the relevant data elements.
The Virtual Medical Record is a draft specification under development by HL7 that also serves the decision support space. It defines a logical medical record that decision support rules can be constructed against. At present, this model is a custom model created specifically for VMR. However, the Decision Support work group is evaluating the possibility of using FHIR as a structure for future versions of the specification.
Maturity Level: N/A | Standards Status:Informative |
HL7 v2 was HL7's first information exchange standard and is one of its most widely adopted, being prominent in in-patient settings throughout the world, though also used in a variety of other contexts as well. HL7 v2 uses messages composed of re-usable segments to communicate healthcare-related information between a sending and receiving system as well as to invoke particular behavior (patient transfers, lab orders, etc.) It also supports one-way communication through notifications, provides support for queries and other workflows.
Event-based: FHIR supports an event-based messaging paradigm similar to the HL7 v2 messaging structure (though, unlike HL7 v2, FHIR supports other paradigms as well including documents, REST and other service models). Refer to the Message Header resource.
Granularity: HL7 v2's "Segment" structure provides re-usable chunks of data that roughly correspond to FHIR's idea of resources. However, HL7 v2 segments can't be independently manipulated. Additionally, not all segments have the characteristics of independent identity held by FHIR resources. Due to differences in scope and approach to extensibility, HL7 v2 segments and data types are frequently cluttered with data elements that are not used by (or even understood by) the majority of implementations.
Segments can be composed into repeating and/or optional collections called "groups" to represent full healthcare business objects. For example, the "Order" component of an OMP (Pharmacy/Treatment Order Message) includes:
The HL7 v2 approach to granularity emphasizes re-use of "patterns" of information. For example, timing and route information are not useful on their own, but they are useful in many circumstances. Due to the 3-level nesting limit, separate segments are also required for data structures that would otherwise nest too deeply. FHIR takes a different approach to reusability, focusing on objects that can be maintained independently. The MedicationRequest resource encompasses all of the aspects of the above segments, with the exception of some of the workflow aspects of ORC which is handled by the Task resource. The MedicationRequest resource is itself complex, having nested structures for dosage instructions, dispensing instructions, etc. that are not simple data types.
Extensibility: HL7 v2 provides an extensibility mechanism through the use of "Z-segments". The meaning of these extensions is opaque without prior manual explanation by the sender. Extensions are supposed to be restricted to data elements that do not affect the meaning of the "standard" segments. FHIR Extensions, on the other hand, can appear at any level (including within data types). ModifierExtensions may be used in circumstances where an extension can change the meaning of other elements (e.g. the introduction of a negation indicator on a record). Finally, the meaning of FHIR extensions is discoverable by resolving the URI that defines the extension. The URI approach also ensures that extensions created by independent systems won't collide. (This can be an issue with Z-segments.)
Inter-version compatibility: HL7 version 2 has strict processes for maintaining forward and backward compatibility. Content can only be added to the end of existing fields, components, etc. Applications are expected to ignore unexpected content or repetitions. FHIR promises similar compatibility rules. The path to an element within a FHIR instance will remain unchanged in future versions. Specific rules on handling "new" elements (ignoring, checking for "must understand" indicators, etc.) will be developed during the STU period.
Human readability: In general, HL7 v2 instances do not provide for human readable versions of the content exchanged. While some systems may make use of NTE segments to provide a human-readable rendering of all or part of a message payload, the rules for when or if this occurs is site-specific. FHIR requires human readable content to be provided for each resource.
Update behavior: HL7 v2 data is typically exchanged in "snapshot" mode - updates are communicated by sending a complete copy of the instance with the new data filled in. However, some segments and messages in HL7 v2 support more sophisticated exchanges where only changed data is sent and codes or special values indicate what sort of change is to occur (e.g. add this address, remove this name). Out-of-the-box, FHIR only functions using snapshot mode. While the use of ModifierExtensions to introduce equivalent behavior to HL7 v2 is possible, doing so would create interoperability issues and would make use of the resources difficult outside the messaging paradigm.
Optionality & Profiles: Both HL7 v2 and FHIR provide a similar degree of flexibility at the international standard level. Most data elements are optional. However, there are two differences. FHIR resources are much more limited in terms of what elements are included in the core specification - only those elements that the vast majority of systems will support. HL7 v2 tends to include many elements that are used in only very limited circumstances. FHIR uses extensions for those circumstances. HL7 v2 and FHIR both provide formal mechanisms for defining profiles to give guidance on the use of the specification. However, the HL7 v2 mechanism has not been widely used. FHIR Profiles form an essential component of the methodology and are built into tooling, increasing the likelihood of their use.
Mapping: One of the biggest challenges with HL7 v2 interoperability is the variation of implementation. Even when identical scenarios are being handled in similar business environments, the data elements supported can vary and even the place where a given data element is placed in an instance can vary. As a result, defining consistent mapping rules between HL7 v2 and FHIR at an international or even regional level is not terribly realistic. The FHIR mappings provided give a starting point for consideration, but mappings will generally need to be done on an implementation by implementation basis.
Extensions: While some HL7 v2 elements will map to FHIR core, a large percentage will not. Where a HL7 v2 element is not supported by core, an extension will be needed to share the information. Where there is interest, HL7 may choose to publish and maintain extensions for HL7 v2 elements that are not supported as part of the core FHIR specification. The FHIR extension registry should be searched prior to defining local extensions. If time permits, the relevant HL7 WG should be contacted with a request to define additional HL7 v2 extensions if needed ones are not present. If time does not permit, applications can define their own extensions, but should have a migration plan for if/when HL7 defines it later. For Z-segments, URIs should be defined to be specific to the system/environment that defined the Z-segment (e.g. http://acme.org/fhir/extensions/consent), not based on the name of the Z-segment itself (given that Z-segments with the same name but different meaning may exist) (e.g. http://hl7.org/ZAC).
Resource identification: HL7 v2 messages will often reference objects that have already been referred to in previous messages. When converting the messages to FHIR, these references will need to point to the same resource URI. Given that not all HL7 v2 message objects have identifiers in the message, this can be somewhat problematic. An approach to handling this issue exists for FHIR transactions. However, the ramifications of using this approach in a messaging environment have not yet been resolved. Implementers will need to explore their own strategies as part of early adoption.
Merging references and resources: HL7 v2 message instances may well reference the same "object" numerous times. For example, a message containing a patient's medication history is likely to include references to the same clinicians and clinics/hospitals many times. While in some cases, the data captured for a given object might be identical in all uses, in other cases the information might vary. For example, the sending system might convey historical phone numbers for old records and current phone numbers for newer records. Alternatively, the message design might allow expression of different amounts of detail in different portions of the message or the sending application might simply be designed to convey different amounts of detail in different portions of the message (e.g. conveying phone number for an ordering clinician, but not for a data-entry clinician). When converting to FHIR, all references to the same "object" will generally have a single resource identifier and be referenced only once in the instance - with the complete set of information needed/available. This creates two challenges:
Identified vs. Contained resources: Each HL7 v2 message will be mapped to
multiple resource instances - often 10s or even 100s of resource instances. To maintain consistency
with the HL7 v2 messaging paradigm, all resource data will typically be sent over the wire as part of the
FHIR message rather than being sent by reference as would be typical in a RESTful implementation.
However, FHIR provides two different ways of communicating the resources as part of the message bundle:
they can either be sent as "fully identified" resources (direct entries in the bundle with their
own identity, and able to be the subject of independent transactions), or they can be sent as contained
resources, meaning they are only identified relative to another resource and cannot be retrieved or
otherwise manipulated on their own. A HL7 v2 to FHIR conversion process will need to make the determination
of what data elements are or must be present, for a resource to be fully identified. In some cases, the
determination will be done at the time of mapping. In other cases, it may depend on the content of a
particular instance. As an example, an XCN containing just a name (|^Smith^John|
) doesn't
contain enough information to discern the physician from any other John Smith, so will need to be
a contained resource, whereas an XCN of |12345^Smith^John|
generally does, though the conversion
process will need to be aware of the scope and management processes around the identifier.
Generating human-readable content: FHIR requires that every resource have a human readable narrative that contains all information relevant to human decision-making. When converting from HL7 v2, developers (likely with guidance from clinicians) will need to determine what information from the message should be rendered and how to generate this content.
Nulls and update modes:In HL7 v2, "action" codes can determine whether particular segments represent information to be added, updated or deleted. Fields can be populated with "null" (two consecutive double-quotes with no other characters) to note a field is to be deleted. An omitted element or repetition is generally interpreted as "retain existing data unchanged". This contrasts with the FHIR approach of requiring all data to be present as a snapshot. Systems will either need to build in logic to generate a full snapshot of each resource or consider using the Patch Operation instead.