Contemporary clinical decision support standards using Health Level Seven International Fast Healthcare Interoperability Resources

Abstract

Objective

To facilitate the development of standards-based clinical decision support (CDS) systems, we review the current set of CDS standards that are based on Health Level Seven International Fast Healthcare Interoperability Resources (FHIR). Widespread adoption of these standards may help reduce healthcare variability, improve healthcare quality, and improve patient safety.

Target Audience

This tutorial is designed for the broad informatics community, some of whom may be unfamiliar with the current, FHIR-based CDS standards.

Scope

This tutorial covers the following standards: Arden Syntax (using FHIR as the data model), Clinical Quality Language, FHIR Clinical Reasoning, SMART on FHIR, and CDS Hooks. Detailed descriptions and selected examples are provided.

INTRODUCTION

The rationale for creating and using standards for clinical decision support (CDS) is to support explicit representation of knowledge, thereby facilitating its validation, and to foster knowledge sharing, thereby reducing the cost of knowledge engineering and facilitating dissemination. CDS standards have been around for 3 decades. The earliest of these standards—the Arden Syntax for Medical Logic Systems—was first described in 1991¹ and is now a Health Level Seven International (HL7) standard.² It supports knowledge representation in medical logic modules (MLMs), but, with no consensus at the time for such concepts in health information technology, it lacks a standard clinical data model and a standards-based data retrieval mechanism. Instead, data are retrieved from local source systems using proprietary mechanisms that typically vary from site to site (known as the “curly braces problem”), thereby limiting interoperability and reuse. An early attempt to address the patient data model problem was the Virtual Medical Record (vMR).³ In this model, electronic health record (EHR) systems would expose an interoperable data layer conforming to the vMR data model. CDS logic could then be written against this model and used across sites and with different EHRs. The HL7 vMR⁴ is the data model used in GELLO,⁵ which is an object-oriented query and expression language for CDS and also an HL7 standard.⁶ GELLO was developed as the expression language for the GuideLine Interchange Format (GLIF),⁷ which is a format for representing clinical guidelines. In the last decade, HL7 also developed the Clinical Decision Support Knowledge Artifact Specification (CDS-KAS).⁸ This specification was designed to represent event-condition-action rules, order sets, and documentation templates. The specification permitted any patient data model, but it cited the HL7 vMR as an example. Earlier iterations of CDS-KAS included a representation for expression logic, but this logic evolved into its own new standard, the HL7 Clinical Quality Language (CQL).⁹ The current version of CDS-KAS therefore uses CQL to represent expression logic.

In 2014, HL7 published the first draft version of a new standard called Fast Healthcare Interoperability Resources (FHIR).¹⁰ FHIR defines a healthcare data model as well as a set of RESTful services for exchanging healthcare data between applications. Given its potential roles in CDS, the FHIR data model is the successor of the vMR, although the scope of FHIR (all healthcare data, plus services) is much broader than the scope of vMR (focused on data to support CDS). In 2020, FHIR Release 4 (R4)¹¹ was included in regulation from the U.S. Office of the National Coordinator for Health Information Technology.¹² This regulation specifies a time frame of 2 years for use of FHIR R4 as a condition of certification of health information technology. Given the expected widespread adoption of FHIR R4 within this time frame, CDS systems that are based on FHIR R4 are likely to be more interoperable across different healthcare settings. Therefore, FHIR brings unprecedented opportunities for wider dissemination and sharing of CDS logic, capabilities, and tools. To facilitate the development of standards-based CDS systems, in this article we review the current set of CDS standards that are based on FHIR and how these standards relate to each other in the context of an example regarding a recommendation for chlamydia screening.

ARDEN SYNTAX

The Arden Syntax for Medical Logic Systems has been in use for much of the last 3 decades. During that period, it has moved from version 1.0 to version 2.10. The Arden Syntax provides a structured, executable formalism for representing clinical, administrative, and other knowledge. It was designed primarily to be used in CDS systems. As such, it functions as a programming language for such systems, allowing knowledge authors and clinical domain experts to develop and implement applications designed to improve care and support the process of healthcare delivery. Arden-based CDS is provided through groups of text-based modules called MLMs.

A key goal of the language has been to represent medical knowledge in a form accessible to medical domain experts. Arden provides the ability to express executable knowledge in an English-language syntax. This characteristic of the Arden Syntax was designed to facilitate validation of knowledge artifacts by domain experts. Moreover, Arden provides constructs for representing the evidence used in CDS, for defining the triggers used to commence execution of CDS knowledge, and for facilitating output messaging, such as a Resources category that allows mapping of output in different natural languages.

While the initial approach to expressing MLMs was in a structured textual form, recent versions of the standard have provided an Extensible Markup Language (XML)–based representation as an alternative. This form has been demonstrated to simplify conversion into executable forms such as the Drools production rule system.¹³

A key challenge for implementers and authors who have adopted the Arden Syntax has been portability of Arden-based decision support. A separate data slot was incorporated into the original Arden Syntax to support translation between data models used in the EHR systems of adopting institutions and the data representation chosen by the MLM’s author. This capability is key to referencing data elements using medically recognizable terminology. While the functionality of this data access approach was enhanced over time, the absence of a standard way to consume data from disparate EHRs made it difficult to transfer MLMs from one institution to another. While this challenge is common to any clinical knowledge representation formalism used in knowledge transfer, because Arden’s references to local EHR data elements were enclosed in curly braces, this became known as the curly braces problem.¹⁴

The uptake of the HL7 FHIR specifications for accessing clinical data appears likely to help significantly in addressing the curly braces problem. The Arden community anticipates a coming release of the standard (Arden 3.0) that will redefine the data slot in the context of a common approach to retrieving and storing EHR data based on FHIR. This update is expected to dramatically diminish the challenges of porting sets of MLMs from one clinical setting to another.

Figure 1 contains an example of how a MLM might be authored for chlamydia screening using FHIR as the data model. The logic has been simplified such that it evaluates (1) whether the patient is in the appropriate demographic, (2) whether chlamydia screening has not occurred within the past year, and (3) whether chlamydia screening has already been ordered. This representation using FHIR is meant to be an early indication of the direction of Arden 3.0, but the syntax may change as the standard gets further developed.

Figure 1.

Example of an Arden Syntax medical logic module for chlamydia screening using Fast Healthcare Interoperability Resources as the data model.

CLINICAL QUALITY LANGUAGE

CQL grew out of an effort to harmonize knowledge representation standards in use across both CDS and quality measurement, and was built as a general-purpose clinically-focused query language, suitable for use in a variety of clinical quality improvement use cases. CQL recently became a normative HL7 standard, meaning that any future changes will be backward compatible. While CQL itself supports arbitrary data models, we will focus our discussion on examples using FHIR as the data model. CQL is aligned with FHIR in 3 important ways. First, the system-defined data types in CQL are aligned directly with the base data types in FHIR, including data types for supporting quantities, intervals, and terminology. Second, FHIR uses a simple graph-traversal language called FHIRPath to support description of paths and invariants throughout the specification. CQL uses FHIRPath as its base grammar, extending FHIRPath to support libraries and general-purpose queries. Third, CQL supports terminology using first-class language constructs that align with the way terminology is represented, distributed, and accessed within the FHIR specification.

CQL is a query language, meaning that statements of the language are questions, formulated in terms of a data model (eg, FHIR) that describes the available data. These questions are represented as named expressions, which are the basic units of logic definition in CQL.¹⁵

As an example, Figure 2 illustrates CQL logic to determine whether or not chlamydia screening is indicated. This example has been simplified from the version available as part of the standard.¹⁶ In the example, we assign names to 2 value sets using their object identifiers. The members of these value sets can be found in the National Library of Medicine Value Set Authority Center repository.¹⁷ Next, we define a named expression “InDemographic,” which checks to see if the patient is in the right demographic. Similarly, we define a named expression “NoScreening” to see if the patient has a chlamydia screening result (an FHIR DiagnosticReport with a code in the Chlamydia Screening value set) issued within the last year or if an order (a FHIR ServiceRequest with a code in the Chlamydia Screening value set) has already been placed for this patient. Finally, we define a named expression “NeedScreening,” which returns TRUE if both “InDemographic” and “NoScreening” return TRUE.

Figure 2.

Clinical Quality Language example for chlamydia screening clinical decision support.

Note how this example takes advantage of what is known as the retrieve declaration in CQL. The expression [“DiagnosticReport”: “Chlamydia Screening”] returns all DiagnosticReport resources with a code in the Chlamydia Screening value set. The square brackets invoke the retrieve operation. In the example, the letter “R” following the retrieve expression assigns the results to the alias “R,” which is then used in the subsequent WHERE clause. Also note how we did not use the “Chlamydia Screening Request” in order to evaluate “NoScreening.” We will make use of this definition in the next section.

CLINICAL REASONING

Although FHIR is a healthcare data model, its scope is not limited to data describing an individual patient. The Clinical Reasoning module specifies how to use FHIR to represent clinical knowledge. In the example depicted in Figure 3, the FHIR PlanDefinition resource is used to represent an Event-Condition-Action rule that uses the CQL expressions represented in Figure 2. This example is drawn from the FHIR specification for PlanDefinition.¹⁸

Figure 3.

PlanDefinition example for chlamydia screening clinical decision support.

The first several lines of the example contain important metadata about the artifact. The rule itself is contained within a single, top level “action” element. The condition (or the IF part of an IF…THEN rule) is specified. In this case, its “kind” is “applicability,” which means that the condition describes whether the action is applicable. For the actual logic of the condition, the PlanDefinition refers to the CQL library in Figure 2, and in particular to the “NoScreening” expression. If this expression evaluates to TRUE, then the condition is satisfied.

When the condition is true, the action has several possible approaches to produce the THEN part of the rule. In the simplest case, the “textEquivalent” element of the action provides a textual description of the action to be performed. For more dynamic processing, the “dynamicValue” element allows values to be constructed by expressions as part of evaluating the rule. These can be elements of the result, such as setting the dosage on a medication request, or they can be expressions that return the entire request, as in the example in Figure 3. In this case, we use the result of the “ChlamydiaScreeningRequest” expression, which constructs a “ServiceRequest” proposal to indicate that a Chlamydia screening should be performed. Finally, the “definition” element allows the action to be specified by referencing a predefined activity definition, using the ActivityDefinition resource.

The example illustrated here shows how a single recommendation can be expressed using FHIR Clinical Reasoning and CQL, but the resources in the Clinical Reasoning module support the description of many other types of knowledge artifacts to support clinical quality improvement. For example, the PlanDefinition and ActivityDefinition resources can represent many other types of knowledge artifacts including order sets, order catalogs, documentation templates, questionnaires, processes, protocols, pathways, and computable guidelines.¹⁹

SMART ON FHIR

SMART on FHIR is a standard method to launch external applications from an EHR. The SMART (Substitutable Medical Applications, Reusable Technologies) component, which handles app launching and authentication to the EHR system’s FHIR server using the OAuth 2.0 standard, was first described by Mandl et al in 2012.²⁰ At a later date, FHIR was added as the data model and EHR data retrieval service, thereby resulting in the current SMART on FHIR standard.^21,22

The result is a standard to enable an app-based ecosystem similar in concept to the Apple App Store or Google Play. A number of apps have been described in the literature, including apps for chronic disease management,²³ risk prediction in spinal surgery,²⁴ neonatal bilirubin management,²⁵ genomic test ordering and result interpretation,^26,27 and opioid prescribing.²⁸

From a security standpoint, apps are granted access only to a defined scope of FHIR resources.²⁹ For example, the scope can be limited to certain specified resources pertaining to the current patient. This scenario would be common in apps that help manage the care of an individual patient. For other apps that might assist with the management of many patients (eg, to support clinical rounds), the scope can be specified at the user level, rather than at the patient level. In this case, the app could be provided with access to all resources that the current user could otherwise access in the EHR. For a more detailed discussion of the security and authorization components, including some excellent sequence diagrams and sample interaction payloads, we direct readers to the SMART on FHIR specification itself.²¹

Using our chlamydia screening example, a SMART on FHIR app could be developed to provide screening advice for a full range of health maintenance and chronic disease management needs, rather than just chlamydia screening. The user might launch this app to view the recommendations for a given patient along with a detailed rationale for each recommendation.

CDS HOOKS

CDS Hooks is an HL7 Standard for Trial Use that is a RESTful, JavaScript Object Notation (JSON)–based Web service specification that uses FHIR for the exchange of patient data.³⁰ One of its original goals was to alert users to the existence of a relevant SMART on FHIR app for the management of a given patient. For example, if a patient has hypertension, the CDS Hooks service might suggest that the user launch a SMART on FHIR app to manage hypertension. The current scope extends well beyond this use case to include CDS services that are unrelated to any particular SMART on FHIR app. For example, a CDS Hooks service could check for drug-drug interactions,³¹ provide preventive care reminders, evaluate the appropriateness of imaging studies,³² or even be used asynchronously for population health management purposes.³³

As the name implies, CDS Hooks relies on certain workflow “hooks” to trigger calls to the Web service. Some current examples include “patient-view” (opening the chart), “order-select” (selecting an item from an order catalog), and “order-sign” (signing fully specified orders). When these events occur, the service would be called with contextual data elements specified in the hook definition. For example, for the “patient-view” hook, the contextual elements include the userId of the current user, the FHIR Patient.id of the patient in question, and optionally, the FHIR Encounter.id of the current encounter.³⁴ Armed with these data, the service could then request the clinical data it needs from the FHIR server through a security mechanism described subsequently. Alternatively, a service could specify a “prefetch template” that specifies the FHIR data the service generally needs to perform an evaluation. In this way, the calling application could provide the FHIR data as part of the initial service call, thereby eliminating the need for the service to call back into the FHIR server to obtain clinical data. For both performance and privacy reasons, the prefetch template option might often be preferred.

CDS Hooks services return “cards” with various attributes. The content of these cards would typically be displayed to users within their workflow. The required card elements include a summary (usually one sentence, such as the text of an alert), an indicator of the card’s importance (info, warning or critical), and a source (to indicate the CDS source). The calling application may use the indicator value to determine how to present the card information to the user. For example, a card with a “critical” indicator might be presented more prominently than a card with an “info” indicator.

Optional card elements include a unique identifier for the card, detailed information, suggestions, and links. While links can be general links to websites, they can also be links to launch SMART on FHIR apps, thereby enabling the original CDS Hooks use case of recommending SMART on FHIR apps. Card suggestions represent suggested actions for the user to consider, such as modifying the dose of a medication order or ordering an alternative imaging study. These suggestions are represented as FHIR resources and allow the user to submit the suggestion to the EHR from within the card itself.

To allow the CDS service to make calls to the FHIR server, the CDS client may include fhirServer and fhirAuthorization fields in the body of the initial Web service call. The fhirServer field contains the base URL of the CDS client’s FHIR server. The fhirAuthorization field contains an OAuth 2.0 bearer access token for the FHIR server. Note that access tokens specify both an expiration time and a scope, which would determine which FHIR resources the CDS service could query and for which patient.

An example of a CDS Hooks discovery endpoint and request is shown in Figure 4, along with a card response example in Figure 5. The response example includes a suggestion, which is structured as a FHIR ServiceRequest resource to request the chlamydia screening procedure. CDS Hooks has the potential to enable cloud-based CDS services at scale from multiple service providers, all using a common set of standards.

Figure 4.

CDS Hooks discovery and request example.

Figure 5.

CDS Hooks response example.

INTEGRATING STANDARDS

Figure 6 depicts how all of these standards fit together. Local, standards-based CDS could be implemented inside the EHR using either the Arden Syntax (with FHIR as the data model) or the Clinical Reasoning artifacts with a CQL library. Users could also launch external SMART on FHIR CDS apps. These apps may choose to represent some of their business logic using Clinical Reasoning and CQL. EHRs may also choose to launch external CDS Hooks Web services. The providers of these services may choose to represent some of their business logic using Clinical Reasoning and CQL. The response cards from CDS Hooks services are displayed to users inside the EHR and may contain a link to launch a SMART on FHIR app. For both SMART on FHIR and CDS Hooks, FHIR is used to represent the patient data. Note that the figure simplifies the depiction of how these external components are launched. For SMART on FHIR, a FHIR server access token is provided, allowing the SMART on FHIR app to retrieve the necessary data from the FHIR server. For CDS Hooks, there are 2 options: the provision of a FHIR server access token or direct inclusion of prefetched FHIR data. Overall, while the individual members of this suite of standards have some overlapping characteristics, each offers different features that help healthcare organizations and healthcare information technology implementers accommodate nuanced CDS needs.

Figure 6.

An electronic health record (EHR) system may optionally choose to implement clinical decision support (CDS) locally using either Arden Syntax or Clinical Reasoning/Clinical Quality Language (CQL) artifacts (knowledge transfer standards). Users may choose to launch a SMART on FHIR app from the EHR. The SMART on FHIR app may optionally choose to use Clinical Reasoning/CQL or CDS Hooks as part of its business logic. The EHR may choose to invoke a CDS Hooks service and display the response card(s) to the user. The CDS Hooks service provider may optionally choose to use Clinical Reasoning/CQL to represent its business logic. For example, a HAPI Fast Healthcare Interoperability Resources (FHIR) Server can use FHIR Library resources to store, load, and evaluate the contents of CQL libraries containing the business logic, as well as the FHIR PlanDefinition resources representing the structure of the decision support rules. SMART on FHIR and CDS Hooks are examples of knowledge access standards.

MATURITY, ADOPTION, AND FUTURE WORK

The CDS standards described previously vary widely in terms of their levels of maturity and adoption. Most of the standards described have been developed in the last 5 years, and significant work is still underway focused on trialing, fine tuning, and expanding these standards. We provide subsequently a summary of the current state of maturity and adoption of these standards, with the caveat that the current state is changing very rapidly. We direct interested readers to the HL7 Confluence webpage (https://confluence.hl7.org/display/CDS/Standards) for the latest information on each of these standards.

Of the various standards discussed in this article, the Arden Syntax is the most mature. It has been a normative HL7 standard for almost 30 years. While it is beyond the scope of this article to discuss the capabilities of specific EHR systems, we will discuss EHR adoption in general terms. We are aware of several commercial EHR systems that incorporate the Arden Syntax into their software, but we are also aware of several major EHR systems that do not support this standard. These systems tend to use proprietary expression languages for CDS. CQL was recently approved as a normative standard. However, even though the Arden Syntax and CQL are both normative standards, there is vastly more experience with the Arden Syntax given how long it has been in use. We are aware of at least 1 commercial EHR system that is working toward supporting CQL for population health management. CQL is also incorporated into the electronic version of various CMS quality measures³⁵ using the CQL-based Health Quality Measure Format standard.³⁶ At the present time, however, the adoption of CQL has been much greater in the clinical quality measurement domain than in the CDS domain. We are unaware of any commercial EHRs that currently support CQL for real-time, patient-specific, locally developed CDS that is outside of the population health management or quality measurement domains.

The Clinical Reasoning, SMART on FHIR, and CDS Hooks standards are all Standards for Trial Use, which means that they are less mature than normative standards. We are aware of several commercial EHR systems that support the SMART on FHIR standard and offer catalogs of SMART on FHIR applications in their “app stores.” The number of SMART on FHIR apps currently on the market appears to be in the hundreds. The use of FHIR and SMART on FHIR within these apps is relatively mature when it comes to reading data from EHRs, especially for FHIR resources that are included in the US Core profile,³⁷ but it is considerably less mature when it comes to writing data back to EHRs. We are aware of several commercial EHRs that currently support CDS Hooks. The momentum behind CDS Hooks seems to be strong, with significant engagement from EHR companies, which are leading the standards development process for the CDS Hooks specification. Clinical Reasoning has been used in various guideline pilot projects, including for CDC opioid prescribing,³⁸ U.S. Preventive Services Task Force lung cancer screening³⁹ and World Health Organization antenatal care⁴⁰ guidelines. However, we are unaware of any commercial EHRs that can currently process PlanDefinition FHIR resources in a plug-and-play manner.

Future work is anticipated to include standards development, health information technology software implementation, and government regulation. On the standards development side, Arden V3.0 will incorporate FHIR to solve the curly braces problem. Ongoing work on CDS Hooks is covering areas such as new hook definitions for various workflow trigger points, security best practices, CDS response analytics, and interoperable suggestions such as for recommended prescriptions. Within the SMART on FHIR category, a new companion standard is being developed called SMART Web Messaging.⁴¹ This standard will allow SMART on FHIR apps to communicate with the parent EHR applications from which they were launched, thereby enabling orders and other actions that happen within an app to be communicated back to the parent EHR. On the health information technology implementation side, we expect more and more EHRs to build support for these standards into their software, and we expect other health information technology companies to offer products and solutions using these new standards. Some investment will likely be required on the part of health systems to recruit and train the requisite talent to use these new technologies effectively. We also anticipate expanded support for a broader set of FHIR profiles, both with read and write capabilities. This process may be accelerated by future government regulatory requirements, which would expand upon existing requirements in the 21st Century Cures Act¹² to support SMART on FHIR for provider-facing and patient-facing apps using data elements in the US Core FHIR specification. We expect the regulatory focus to move from read-only access to EHR data to include read-write capabilities.

CONCLUSION

After 3 decades of developments in CDS standards, the current set of FHIR-based CDS standards, coupled with U.S. regulatory requirements for the use of FHIR R4, has the potential to enable widespread adoption of CDS at scale. Longstanding challenges of healthcare care variability, healthcare quality, and patient safety may finally be addressed.

FUNDING

RAJ was supported by National Institute of Minority Health Disparities grants U54MD007598 and S21MD000103 and National Center for Advancing Translational Sciences grant UL1TR001881 from the U.S. National Institutes of Health. KK and GDF were supported by National Cancer Institute grants U24CA204800 and U01CA232826 and by Agency for Healthcare Research and Quality grant R18HS026198. Some standards and content development referenced in this article were funded by The Office of the National Coordinator for Health Information Technology, contract numbers HHSP233201800320G, HHSP233201700044C, and D15PD00739.

AUTHOR CONTRIBUTIONS

All the authors made substantial contributions to the conception, writing, and editing of the manuscript.