We developed a shared interoperable CDS system based on CDS Hooks for a DAI check to provide a service to health care providers. The system is triggered by medication orders in the EHR system. When it is evoked, the system checks the DAI and returns recommendations back to the provider. We developed the system in the following steps: (1) requirement analysis, (2) design, (3) implementation, and (4) deployment. In the first step, we identified data elements used for DAI check and classified them into mandatory and optional. We also selected the FHIR resources for contextual information available within an EHR system. Second, we designed concept architecture and web service end points, representational state transfer (RESTful) application programming interfaces (APIs), based on the CDS Hooks structure. We profiled FHIR resources according to data elements and specified the card, a form that represented a result of decision support. We designed a rule engine including a four-step drug-allergy screening logic and knowledge base. Lastly, we implemented components and functions, and deployed the CDS system on a government-managed cloud service called G-Cloud.

The CDS service can simultaneously be used by multiple health care providers, such as tertiary hospitals, small- to medium-sized hospitals, and clinics with their own EHR systems. Health care providers can DAI check using a remote CDS service call when ordering medications. An EHR system creates a request payload with patients’ prescriptions and allergy data, and transmits it to the CDS service. The CDS service executes the DAI check logic using the request payload and then returns the result to the EHR system.

We designed a concept architecture according to the CDS Hooks structure, which consists of CDS services, CDS clients, and cards, as shown in Figure 1. The CDS clients that are EHR systems in health care providers invoke the CDS service through a hook that is an event trigger, and the CDS service provides recommendations using a card to the CDS clients. The CDS system was implemented in version 1.0 of the CDS Hooks specification.

The CDS service was designed as a cloud service and consisted of an interface engine, rule engine, authentication and authorization server, and audit trail. The interface engine has three components: the service gateway, the FHIR resource parser, and the CDS Hooks card generator. The service gateway provides a discovery end point and DAI check end point, and the FHIR resource parser parses request payload data to relay to the rule engine. The CDS Hooks card generator creates decision support results as a card to return to the CDS client. The rule engine checks the DAI using the prescription and patients’ allergy information and then returns a result of allergy screening to the CDS Hooks card generator. The authenticate and authorization server authenticates the EHR system using an issued token, and the audit trail monitors which health care providers invoke the service and when and how often they use it.

We applied the CDS Hooks security model with some variations to the CDS service. The CDS Hooks specification provides a security model, such as mutual identification, transport layer security protocol, and JSON web token. We developed the authentication and authorization server to provide a token to CDS clients. The token issued by the CDS service authenticates the CDS client. It reduces the burden on the health care provider’s authentication server development and helps a wider adoption of the CDS service. In addition, a whitelist of health care providers is managed based on our risk management strategy.

The CDS client creates an HTTP request to the CDS Hooks service with parameters that include required fields (hook, hookInstance, and context) and optional fields (fhirServer, fhirAuthorization, and prefetch). The context and prefetch fields have the FHIR resources, which are translated by the FHIR adapter. The FHIR adapter was considered instead of an FHIR server since the adoption of the FHIR standard is in its infancy in Korea.

We identified data elements for the DAI check and profiled two FHIR resources, MedicationRequest and AllergyIntolerance, based on the FHIR R4 (v4.0.1) [24] and Korea (KR) Core implementation guide (IG) v1.0.0-STU 1 [25]. The MedicationRequest resource represents a supply of the medication and administration instructions, as shown in Figure 2A [24]. There are two options for representing medication information in the MedicationRequest resource: referencing the Medication resource to the medicationReference element and assigning the medication code directly to the medicationCodeableConcept element. In this profile, we applied the latter because health care providers do not manage the Medication resource. The medicationCodeableConcept element is bound to the Korea Drug (KD) code, the national code system to identify and manage drug products [26]. The cardinality and must support constraints of the MedicationRequest resource are inherited by the KR Core MedicationRequest Profile. The CDS service uses the medication element but not the identifier nor the dosageInstruction elements, although they are marked as must support. Elements designated as a must support are necessary conditions for the FHIR resource to be exchanged, but consumers of the resource do not necessarily have to use all must support elements in principle.

The AllergyIntolerance resource represents a record of a clinical assessment of an allergy or intolerance, as shown in Figure 2B [24]. The category element with the AllergyIntoleranceCategory value set is assigned the fixed value of “medication.” The code element is bound to a proprietary value set developed by the vendor that provides the rule engine of the CDS service, since there is no national code system that identifies the allergy or intolerance.

The cardinality constraints of the AllergyIntolerance resource are inherited by the KR Core IG. The identifier, category, and code elements are marked as “must support.” The profiled resources are published to SIMPLIFIER.NET, one of the FHIR registries.

Two profiled resources are conformant to the KR Core IG in Figure 3. The KR Core IG, a national-level FHIR IG, such as the US Core [27], UK Core [28], Australian Base [29], and Canadian Baseline [30], is essential in the nationwide adoption of the FHIR standards and in building an ecosystem based on the standards. We expect that specific use case FHIR IG based on the resource profiles proposed in this study will be adopted as a national standard in Korea.

Two end points were designed and implemented: the discovery and DAI check APIs. The discovery API provides the list of CDS services, including a description of the CDS service and any requested data to be prefetched [9]. The DAI check API is the CDS service using the “order-sign” hook, as shown in Figure 4A. The order-sign hook occurs when the provider is ready to sign one or more orders for a patient, and it has the userId, patientId, and draftOrders as required fields and encounterId as optional. The userId field is included since it is required for the order-sign hook and not used for any other purposes. The CDS service does not distinguish individual providers invoking the service since it does not require a physician ID for DAI checks. The draftOrders field has a Bundle resource that lists MedicationRequest resources. The AllergyIntolerance resources are attached in the prefetch field that describes the relevant data required in the CDS service.

The CDS service responds to the CDS client with cards containing information, suggested actions, and links to launch an application. The DAI check API returns a card with a “warning” indicator, as shown in Figure 4B. The cards are JSON documents and have several fields, such as summary, indicator, and source field. The summary field is a summary message for display to the provider, and the importance of the card is represented by the following indicators: “info,” “warning,” and “critical.” The source field is a source of information displayed on this card.

We designed and developed the rule engine to check an interaction between a patient’s medication allergens and prescribed medications transmitted from a health care provider, as shown in Figure 5. The allergen data from the AllergyIntolerance resource can be a brand name, substance, or drug class. The medication data from the MedicationRequest resource is a brand name coded by the KD code managed by the HIRA. The DAI check is performed in a three-step screening process: (1) check whether allergens and prescribed medications have the same product or ingredient, (2) check whether they belong to the ingredient class, and (3) check whether they have a cross-reactive allergen.

The Drug Allergy database consists of master and relation tables. The master tables are the Drug, Drug Class, Ingredient, and Cross-Reactive Allergen. The Drug and Drug Class tables uniquely identify regulated medicinal products using the KD code as the primary key. The Ingredient table models substances that constitute a medicinal product and includes columns such as ingredient code, name, and synonym. These tables are designed based on the Identification of Medicinal Products, a suite of five International Organization for Standardization standards to facilitate the reliable exchange of medicinal product information. The Ingredient table is related to the Cross-Reactive, Drug, and Drug Class tables by each primary key. In addition to these tables, the drug allergy database has several relation tables used to perform DAI checks.

This study did not require ethics approval as no personal data was collected, and no interventions were implemented.

The study applied the CDS Hooks specification to provide the nationwide shared interoperable CDS service for the DAI check. The CDS service has been deployed on G-Cloud, and all authorized health care providers can use the service simultaneously through RESTful APIs. As of December 2021, 67 health care providers have participated in the initiative. Since the service developed in this study conforms with the CDS Hooks specification, clinical knowledge bases can be shared, and the services can be scalable.

According to the CDS service results report, the rate of warnings that occurred among the CDS service was 7.74% from 29 of the 67 participating hospitals for 1610 patients from May to August 2021. Among the warnings, the most frequent was the cross-reactive allergen check (43.55%), followed by the same drug or ingredient class check (28.77%) and the same product or ingredient check (27.68%). After warning responses from the CDS service, 9.07% of prescriptions were changed, and 90.93% were not changed [33]. Although warning responses occurred from the CDS service, physicians did not change their prescriptions, which had a rate of 90.93%. This proportion is similar to the range of average override alerts, 46.2% to 96.2% [34-36]. To induce physicians to change their prescriptions, additional information and services such as statistical data, research papers, or the SMART application could be provided as evidence.

We designed the CDS system based on serverless FHIR architecture. A CDS service can request additional data regarding the clinical workflow context to the FHIR server at providers via the hook parameters in the CDS Hooks specification. In Korea, the adoption of FHIR standards is in its infancy, and few health care providers have FHIR servers for requesting any additional data. Thus, we applied serverless FHIR architecture, identified the required data in advance, and assigned it in the prefetch field.

As awareness of national allergy codes increases, the MoHW of Korea is developing a national allergy code system. The KR Core AllergyIntolerance profile binds the KR Core AllergyIntolerance Code value set, a renamed version of the AllergyIntolerance Substance value set defined in the FHIR R4. The binding strength of the two value sets is preferred. It is meant to encourage drawing from the specified codes, but it is not required. Currently, there is no national allergy code system available in Korea, and the KR Core AllergyIntolerance Code value set is basically a placeholder for future value set development. Due to the lack of a national allergy code system, we chose to use a proprietary value set. When the national allergy code system is developed, it will replace the value set to draw from the national allergy code system with binding strength required, as well as the KR Core AllergyIntolerance Code value set.

The shared interoperable CDS service for the DAI check based on the CDS Hooks was developed and deployed. The CDS service is currently provided to 67 health care providers. The MoHW has been making efforts to build the HL7 FHIR-based ecosystem in Korea. As one of these efforts, the CDS service initiative was conducted. To promote the rapid adoption of the HL7 FHIR standards, it is necessary to accelerate the practical service development and appeal the benefits of FHIR-based standardization to policy makers; this is the primary purpose of guiding the CDS service. Lastly, with the development of various case-specific IGs based on the KR Core IG, the FHIR standards will be distributed to the health IT industry, and more shared interoperable health care services will be introduced in Korea.