Coordinated Use of Health Level 7 Standards to Support Clinical Decision Support: Case Study with Shared Decision Making and Drug-Drug Interactions

Structured Abstract

Background:

Despite advances in interoperability standards, it remains challenging and often costly to share clinical decision support (CDS) across healthcare organizations. This is due in part to limited coordination among CDS components. To improve coordination of CDS components, Health Level 7 (HL7) has developed a suite of interoperability standards with Fast Health Interoperability Resources (FHIR) specification as a common information model. Evidence is needed to determine the feasibility of implementing these CDS components; therefore, the objective of this study was to investigate the coordination of emerging HL7 standards with modular CDS architecture components.

Methods:

We used a modular, standards-based architecture consisting of four components: data, logic, services, and applications. The implementation use-case was an application to support shared decision making in the context of drug-drug interactions (DDInteract).

Results:

DDInteract uses FHIR as the data representation model, Clinical Quality Language for logic representation, CDS Hooks for the services layer, and Substitutable Medical Apps Reusable Technologies for application integration. DDInteract was first implemented in a sandbox environment and then in an electronic health record (Epic^®) test environment. DDInteract can be integrated in clinical workflows through on-demand access from a menu or through CDS Hooks upon opening a patient’s record or placing a medication order.

Conclusion:

In the context of drug interactions, DDInteract is the first application to leverage a full stack of emerging interoperability standards for each component of modular CDS architecture. The demonstrated feasibility of interoperable components can be generalized to other modular CDS applications.

1. INTRODUCTION

Clinical decision support (CDS) can improve medical decision making across multiple domains of patient care [1–4]. Enabled through the electronic health record (EHR), “CDS provides clinicians, staff, patients or other individuals with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and health care” [5]. Despite widespread adoption of EHRs with CDS and recent advances in interoperability standards, it remains challenging and often costly to share CDS across healthcare organizations [6].

Health information technology (IT) standards are vital to facilitate interoperability of CDS among healthcare organizations. In the past three decades [7], there have been attempts to standardize the development of CDS components [8,9]. For example, Arden Syntax was designed to shared medical knowledge with Medical Logic Modules [10]. Despite the interoperability and reuse of these modules, data retrieval was accomplished through proprietary mechanisms at individual institutions. Without a common information model, coordinating standards among CDS components (e.g., logic and service layer) is challenging [11,12], resulting in CDS components with EHR-specific information models and terminologies that were adapted to clinical content and workflows at each institution [13,14]. Impeded interoperability, due to the lack of a common information model, has contributed to unsuccessful attempt at making CDS readily shareable. To improve coordination of CDS components and facilitate local workflows, Health Level 7 (HL7) has developed a suite of interoperability standards with Fast Health Interoperability Resources (FHIR) specification as a common information model. With the emergence of FHIR, CDS components can be supported by separate standards to comprise a modular service-oriented architecture with a common information model [15].

A modular architecture comprised of interoperable components can enable reuse among health care institutions and also among CDS tools, which can reduce needed resources for evidence-based guideline implementation [16]. While previous studies have investigated the implementation of certain HL7 standards, these demonstrations have not explored the feasibility of coordinating interoperability standards among components of a modular CDS architecture (i.e., data, logic, services, and applications) [17–19]. Furthermore, real-world experience is needed to understand how a common information model can enable coordinating standards among modular CDS components. The goal of the present study was to describe the experience of implementing a CDS tool with a modular service-oriented architecture, where each component uses interoperable standards with FHIR as the common information model. As a motivating use-case, we describe the implemented architecture for a novel application that supports a shared decision making process for drug-drug interactions (DDInteract) [20].

2. METHODS

We designed a modular service-oriented architecture and demonstrated its feasibility to support a CDS system for shared decision making with drug-drug interactions. A key aspect of the architecture was use of Health Level 7 (HL7) standards. At the core of the architecture was a common information model across the different components and standards. The service-oriented architecture comprised four components: data; logic; services; and applications [6]. The following standards were used for each component of the architecture: FHIR as the common information representation model, Clinical Quality Language (CQL) for representation of CDS logic, CDS Hooks for services, and Substitutable Medical Apps Reusable Technologies (SMART) for application integration with the EHR. The data component consisted of patient data and other data needed by CDS systems to perform its specific use case. The logic component used data to compute a patient assessment and provide a recommendation. CDS services encapsulated the other components and make them available to CDS applications and EHR systems as web services. The application component presents a user interface that is integrated with the EHR. The use case for the architecture was an application (DDInteract) to support decision making for the drug-drug interaction between an anticoagulant (warfarin) and nonsteroidal anti-inflammatory drugs (NSAIDs) [20].

2.1. Modular Service-Oriented Architecture

2.1.1. Data

In 2018, FHIR was available in more than 80 percent of all hospitals in the U.S. [21]. FHIR is a data communication standard to enable semantic interoperability between different healthcare systems. It is based on widely used web technologies including REST and JSON [22]. FHIR represents clinical data as distinct entities called resources. Each resource (e.g., Patient, Medication, Condition, or Observation) defines a set of attributes, associations with other resources, cardinality of those associations, and terminology bindings. For instance, gender and birthdate are part of the Patient resource. Base resources include data that are commonly supported by multiple EHR systems and are extensible to accommodate additional data fields. Changes made to the base resources can be defined as FHIR profiles, which are published as implementation guides to support to specific requirements and use cases.

2.1.2. Logic

CDS logic was implemented using CQL for the CDS service, using external terminology services and the EBMonFHIR standard. CQL is an authoring language that represents rule-based clinical knowledge [23]. The syntax is author-friendly, human readable and designed for clinical domain experts. CQL was created to enable sharing of logic across quality improvement domains including quality measurement and decision support [24]. We used terminology web services from RxNorm and the Value Set Authority Center (VSAC). The RxNorm services was used to linking brand and generic drugs to their ingredients [25]. VSAC is a repository provided by the U.S. National Library of Medicine that supports the authoring and sharing of value sets via a web service [26]. We used VSAC to retrieve value sets for relevant medications (e.g., NSAIDs) and conditions (e.g., history of gastrointestinal bleeding). We used the EBMonFHIR Evidence (FHIR R5) resource to represent supporting clinical evidence for the CDS logic. The EBMonFHIR specification leverages FHIR to enable interoperability to clinical evidence by making research results machine-interpretable to facilitate evidence synthesis and to make evidence easily shareable [27].

2.1.3. Services

CDS Hooks was used to integrate CDS capabilities within clinical workflows of the EHR [28]. CDS Hooks is based on common web technology and uses FHIR resources for data exchange, which enables sharing of CDS capabilities through interoperable web services. CDS Hooks specifies a hook-based pattern to trigger CDS services upon specific user events (i.e., hooks) in the EHR. To make CDS accessible when it is needed, the standard defines several hooks that occur through clinicians interacting with the EHR. For example, the patient-view hook is triggered when the patient record is opened, or the order-select hook is triggered when the prescriber selects an order (e.g., medication or procedure). A service request includes specific data relevant to a particular workflow context (e.g., the current selected medication). Patient data can be added to a service request from the EHR via prefetch. Additionally, the service request can include credentials for the EHR’s FHIR server. Both options allow CDS services to obtain additional patient data on demand. The CDS Hooks service provides a response in the form of a “Card” that is displayed inside the EHR. There are three types of cards: (i) information cards provide patient-specific information, such as an assessment or reference information; (ii) suggestion cards provide a recommended action (e.g., an order) in a FHIR resource; and (iii) app cards provide a link to launch a SMART on FHIR app.

2.1.4. Applications

SMART was used to provide seamless launching and authentication from inside the EHR [29]. SMART is combined with the FHIR standard in the SMART on FHIR specification, which allows external applications to access EHR data in the FHIR format [30]. SMART on FHIR applications use the open standards OAuth and OpenID Connect. OAuth is a web standard for authorizations, allowing an application to access data within a defined access scope. OpenID Connect is used for authentication with a single sign-on mechanism. This technology allows external applications to safely access patient data as FHIR resources from EHR systems. Since SMART on FHIR is agnostic of EHR implementation, it allows the sharing of CDS apps across different EHR products with apps made available through SMART Appstores [31].

2.2. Use Case; DDInteract App

DDInteract was designed to help healthcare providers and patients work together to find the best treatment option to prevent harm caused by a potential drug-drug interaction (Figure 1). The user interface was designed through an iterative user-centered design approach guided by feedback from usability sessions with target users (i.e., patients and clinicians) [20]. Key aspects of the user interface help users assess the risk of gastrointestinal bleeding when taking warfarin and adding an NSAID; furthermore, different treatment options can be explored by the patient and clinician together. Based on our prior study that describes the design and usability of DDInteract, a key requirement was sub-second risk calculation as users switch back and forth between different treatment options and risk factors to explore “what if” scenarios with their patients [20]. The user interface was implemented as a client server web application using Angular (with Typescript) as the frontend following the Material Design specification and Spring Boot (with Groovy) as the backend framework.

Figure 1.

The user interface of DDInteract comprises the following sections: The icon array (A) displaying the risk score of gastrointestinal bleeding which is based on the patient’s risk profile (B) and the decision tree (C). The informative sections (D) provide additional information to patient and clinician.

3. RESULTS

DDInteract was embedded into a service-based software architecture as a SMART on FHIR application to demonstrate the coordination of health IT standards. The program flow of the architecture comprised six steps (Figure 2): (i) Based on user activity in the EHR, a CDS Hook triggers a request to an external CDS service. For DDInteract, we implemented the patient-view and the order-select hooks, so the application can be launched either when users open the patient’s chart or when they select an order (e.g., medications, procedures). (ii) Based on data requirements of the CQL logic, the CDS Hooks service requests additional patient data from the EHR’s FHIR server. This patient data can either be already included in the CDS Hooks service request using the prefetch mechanism or can be pulled from the EHR’s FHIR server on demand from within the CQL rules. (iii) If the CDS Hooks service detects an increased risk of gastrointestinal bleeding, it returns this information back to the EHR as an app Card with a link to DDInteract. (iv) The clinician can launch DDInteract through the app link. Alternatively, the app can also be launched on demand at any time directly from the EHR and without the use of the CDS Hooks service. (v) On launch, DDInteract retrieves required patient data from the EHR’s FHIR server and executes the risk calculation. (vi) Finally, DDInteract retrieves supporting evidence for the risk formula from EBMonFHIR resources.

Figure 2.

The SMART app (DDInteract) embedded into a service-based clinical decision support software architecture.

3.1. Data

DDInteract uses multiple risk factors such as age, past medical history, and current medications to assess risk of gastrointestinal bleeding due to the interaction between warfarin and an NSAID. If a risk factor is detected, it will appear as a toggle in the user interface. FHIR resources pulled from the EHR for each risk factor are provided in Table 1. Base FHIR resources (Release 4) were used without extensions. Every risk factor can be detected with a resource and as defined in the US Core FHIR Profile (e.g., Patient, Condition and MedicationRequest [32].

Table 1.

Risk factors for gastrointestinal bleeding along with associated FHIR resources and the used attributes and terminologies. SNOMED CT: Systematized Nomenclature of Medicine - Clinical Terms. ICD-10: International Classification of Diseases.

Risk Factors	FHIR Resources - Attributes
Older than 65	Patient - birthDate
Previous gastrointestinal bleeding	Condition - code (SNOMED CT, ICD-10)
On warfarin On aspirin On clopidogrel On selective serotonin inhibitor On systemic corticosteroid	MedicationRequest - status - authoredOn - medication (RxNorm) MedicationDispense - status - whenHandedOver - medication (RxNorm) MedicationStatement - status - effective - medication

Medication data can be represented in multiple different resources; therefore, DDInteract scans the following FHIR resources: MedicationRequest for medications that are prescribed to the patient; MedicationDispense for medications that have been handed over to the patient; and MedicationStatement for medications that are reported by the patient as being taken now or have been taken in the past. A single medication could be represented by multiple different kinds of medication resources. Potential duplicates are resolved to a single resource with the most recent date and a prioritization between the different kinds of medication resources.

To reduce the number of resources obtained from the FHIR server, not every medication instance is considered. Only medication resources that are currently active or were active within the past 100 days are considered, because in the U.S., medications are typically dispensed for a maximum duration of three months (Figure 3).

Figure 3.

An example of a FHIR MedicationStatement resource for warfarin.

3.2. Logic

The CDS logic was implemented as CQL on the CDS service and as use-case specific application logic on the application. We used CQL rules within the CDS Hooks server to detect a warfarin-NSAID interaction and potentially launch DDInteract (Figure 1). Certain risk factors are based on a single ingredient and others are part of broader drug groups (e.g., selective serotonin reuptake inhibitors, proton pump inhibitors). The RxNorm REST API was used to extract drug ingredient concepts (e.g., warfarin) from prescribable concepts (e.g., warfarin sodium 0.5 MG Oral Tablet) to detect a certain risk factor (e.g., “On warfarin”). VSAC valuesets were used to check if a drug belongs to a certain drug group which is related to risk factors (e.g., “On selective serotonin reuptake inhibitors”). A VSAC valueset was also used to check for previous history of gastrointestinal bleeding. DDInteract scanns the condition resources and looks for International Classification of Diseases (ICD) or Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) codes, which are included in a valueset. To increase the performance of DDInteract and limit the number of service requests to RxNorm and VSAC, all requests are cached in memory. This allows DDInteract to recalculate the risk score in under half a second as the user changes risk parameters to explore different treatment options.

DDInteract uses a logistic regression model for the risk score calculation. The underlying evidence suporting the calculation is part of the clinical knowledge and is hosted as EBMonFHIR Evidence resources on the CDS Hooks service. EBMonFHIR resources were created for each risk factor. Evidence resources included the name of the risk parameter and statistical values for the regression model. Primary literature references for the relevant risk factors are displayed with a link to the article citation in PubMed^®. Storing evidence as FHIR resources enables maintainance of the evidence without changes to DDInteract code. To reduce the startup time of the app, the Evidence resources are only requested once and then they are cached on the backend of the CDS architecture.

3.3. Services

We deployed the preliminary CDS architecture and DDInteract in the Logica^® sandbox environment, which supports the development of SMART apps [33]. The sandbox includes an EHR simulator to simulate SMART apps embedded into the EHR; a FHIR server to access example patient data; and a CDS Hooks sandbox to trigger hooks based CDS services [34]. The sandbox enables launching the app under different scenarios, including patient-view, order-select, and on-demand. Our CDS service discovery endpoint was added to the sandbox for launching the app with CDS Hooks. After a hook is triggered and the CDS service detects a risk of gastrointestinal bleeding with its internal CQL logic, it responds with an array of CDS Hooks Cards, which are rendered inside the sandbox. All cards include a heading notifying the user that there is an increased risk of gastrointestinal bleeding, an explanation text, and a button allowing the user to launch DDInteract (Figure 4). Besides using CDS Hooks, the app can also be directly launched from within the EHR on demand.

Figure 4.

A CDS Hooks app card notifying the clinician that there is an increased risk of gastrointestinal bleeding. The button on the bottom left allows the clinician to seamlessly launch the app.

3.4. Application

While we used a sandbox environment, the use of SMART and other common web technology allowed us to deploy the CDS architecture and DDInteract in different settings. In addition to the Logica^® sandbox environment, DDInteract was deployed in an Epic^® EHR test environment at the University of Utah, and on the project website [35]. Although DDInteract supports launching through CDS Hooks via patient-view hook, we have not yet configured Epic’s CDS Hooks capabilities to call out DDInteract’s CDS Hooks service upon patient-view. The performance of DDInteract’s risk calculation was below a second on all deployed platforms.

4. DISCUSSION

In this study, we demonstrated the feasibility of coordinating a modular, standards-based architecture with a set of emerging CDS standards. The architecture was demonstrated with a SMART on FHIR application that was designed to support shared decision making for drug-drug interactions (Figure 1). What makes this architecture feasible and advantageous compared to prior interoperable CDS applications is that the selected standards were developed in collaboration among developers to cover the different service-oriented architecture components. Modular components are built in conjunction but work independently to accommodate the needs or limitations of each implementation site. Furthermore, the standards are built over common web technology (i.e., REST and JSON), which enables software developers to also use established technology. In addition to lowering implementation barriers with modular components, DDInteract uses primarily US Core FHIR resources, which are broadly adopted among healthcare institutions.

While others have investigated interoperable CDS applications with standards-based architectures, these demonstrations were focused on a subset of the emerging CDS standards. Dolin et al. developed a CDS service for pharmacogenomics that provides drug-gene interaction checking. The CDS was embedded in the EHR using FHIR and CDS Hooks [17]. Watkins et al. developed a SMART application to access genetic laboratory tests. The application used order-select CDS Hooks to bring clinician attention to important lab results [18]. Multiple SMART on FHIR applications have been used to deliver CDS to clinicians, such as a dashboard to manage chronic diseases and a bilirubin level management application [36,37]. These studies show the potential utility of individual standard-based components; however, none of these demonstrations used a full stack of emerging CDS standards for a modular architecture. In contrast, the modular components that comprise DDInteract can be shared or reused in different institutions or CDS tools.

4.1. Limitations and Future Research

First, both the application and the CDS service implement CDS logic to detect a risk of gastrointestinal bleeding. This duplication was necessary to allow launching the application with or without CDS Hooks and so that DDInteract can calculate the risk assessment in near real time. If the risk factor and treatment combination scope was large or the application required additional data after launch, calculations may need to be completed separately from the application and the responsiveness would be slower.

Second, service-oriented architectures divide responsibilities among different third parties, creating dependencies on external entities that may be beyond the control of CDS developers. This could potentially lead to performance issues and the need to share patient data outside an institution’s firewall. This architecture uses VSAC value sets, so the fit and quality of the selected value set will contribute to the application’s performance.

Third, the integration of DDInteract with a commercial EHR only included launching on demand. We plan to extend CDS Hooks capabilities for users to launch the app through a CDS Hooks Card upon triggering of the patient-view hook.

Fourth, performance testing of the CDS service was limited to the sandbox setting. Future studies will include assessing the performance of the architecture with integration commercial EHR systems in clinical settings.

5. CONCLUSION

We aimed to investigate the feasibility of a modular CDS architecture that comprised a full stack of emerging CDS standards with a common information model (i.e., FHIR). We coordinated these standards in an interoperable architecture to support a SMART on FHIR application for drug-drug interactions (DDInteract). The CDS architecture, along with DDInteract, were deployed in an EHR sandbox environment and integrated with a commercial EHR. In the context of drug interactions, DDInteract is the first application to leverage a full stack of emerging interoperability standards for each component of modular CDS architecture. The demonstrated architecture can be used to develop CDS that can be deployed in different EHR systems and healthcare organizations.

Highlights.

• Fast Health Interoperability Resources as a common information model provides new opportunities for interoperable clinical decision support

• Standards for interoperable clinical decision support were coordinated to build a completely modular system

• Future interoperable clinical decision support can apply the described architecture to new applications

Abbreviations:

CDS

clinical decision support

EHR

electronic health record

IT

information technology

HL7

Health Level 7

FHIR

Fast Health Interoperability Resources

CQL

Clinical Quality Language

SMART

Substitutable Medical Apps Reusable Technologies

NSAIDs

nonsteroidal anti-inflammatory drugs

VSAC

Value Set Authority Center

ICD

International Classification of Diseases

SNOMED CT

Systematized Nomenclature of Medicine Clinical Terms