Standards-Based Implementation of CDC Recommendations as a CDS Hooks Web Service

The CDS Hooks interoperability framework was used for the integration of the guideline recommendations into EHR systems. This framework was chosen primarily due to EHR vendors including Epic, Cerner, Allscripts, and Athena Health expressing their strong support of the framework and in anticipation that these EHR vendors will support the framework in the near future. This framework enables an EHR system to call out to an external CDS Web service to obtain patient-specific guidance in the form of "cards". A graphical overview of the CDS Hooks framework from its Web site is shown below.

The core components of this standards-based knowledge resource are described below.

Solution Component # 1: Medication and Terminology Knowledge Base

Three Microsoft Access databases called LocalDataStore_RxNav_OpioidCds.accdb, LocalDataStore_UMLS_OpioidCds.accdb, and LocalDataStore_VSAC_OpioidCds.accdb were created to enable the definition of the medication and terminology knowledge required. Also, an important desire was to be able to continually update this database when new concept codes entered the system. This was accomplished by developing the Terminology Knowledge Builder, described in the next section.

A visual representation of the database is shown below:

In essence, this database enables the use of RxNorm's RxNav API interface to build and maintain a medication knowledge base. After seeding the knowledge base with medication ingredients of interest in MED_INGREDIENT and MED_INGREDIENT_TYPE, the system queries the latest version of RxNorm hosted by the National Library of Medicine (NLM) to identify which drugs contain those ingredients; what dose forms they take; what components they have (important for combination drugs); the strength of those drugs; and the ingredients of those components (so that opioid vs. non-opioid ingredients can be distinguished).

The database also uses queries on this knowledge base to identify opioid types of interest, such as extended-release opioids, opioids abused in ambulatory care, etc.

LocalDataStore_MLS_OpioidCds.accdb uses the Unified Medical Language System (UMLS) hosted by the NLM. It allows the specification of value sets in terms of "ancestor concepts" (e.g., metastatic cancer, urine opioid testing). It then uses the UMLS API to identify all descendant concepts, which can then be aggregated to identify appropriate value sets.

LocalDataStore_VSAC_OpioidCds.accdb uses the Value Set Authority Center (VSAC) and allows the retrieval of concept codes managed in VSAC for use in the CDS system.

Solution Component # 2: Terminology Knowledge Builder

The terminology knowledge builder consists of three stand-alone Java programs that populate and update the medication and terminology knowledge bases. They each identify when particular entries and value sets have been updated, so that a client system can use them to determine if the database used by the CDS system needs to be updated.

Solution Component # 3: Core Logic Processing Java Class

The core of the CDS Hooks Web service is a set of Java classes, located in the opioids-lib package. The main entry point (UtilsOpioid.java) used by the knowledge module uses FHIR STU2 resources as the input. Below is a high-level overview of how the CDS logic is implemented for one of the CDC guideline recommendations (#5), which provides guidance around opioid morphine milligram equivalence (MME).

• Identifies whether all inclusion and exclusion criteria are met:
  • There is a draft (about-to-be-prescribed) order for an opioid with abuse potential
  • There are no draft or active orders for opioids indicating end of life
  • There are no active conditions indicating end of life
  • The patient has been on an opioid abused in ambulatory care consistently for the past 3 months
    • This calculation uses the days' supply of medications based on the sig to calculate coverage. For example, if an opioid was prescribed for 1 tab q6hrs (4 times a day), and 60 tabs were prescribed with 0 refills, the days' supply is calculated as extending only 15 (60/4) days. The intent of this calculation is to avoid situations where a patient receiving only a small quantity of opiates is labeled as a chronic opioid user because they have an old but active medication in their medication list.
  • For the MME rule:
    • The total morphine milligram equivalent (MME) daily dose is >= 50 MME/day. In this calculation, PRN (as needed) mediations are considered to be taken at the maximum allowed dosage, and the CDC recommendations provided by the CDC team as an Excel spreadsheet were used.
  • For the urine drug testing rule:
    • There are no urine opiate tests available from the past 12 months
• Where action is needed, creates CDS Hooks information "Cards" that provide a summary, details, and links for the assessment and recommended course of action.

Solution Component # 4: OpenCDS Knowledge Modules

OpenCDS knowledge modules utilize the UtilsOpioid Java class to take in FHIR resources as the input and return CDS Hooks cards as the output.

Solution Component # 5: Epic CDS Hooks Adapter

While Epic is working on native support for CDS Hooks, such support is not currently available. We have therefore created an adapter/middleware for CDS Hooks on top of Epic to support this project. This adapter essentially translates the Epic-specific Best Practice Advisory (BPA) Web service interface into a CDS Hooks interface. Included in this adapter is a translator for converting the "markdown" output format used by CDS Hooks into the HTML display format used within Epic.

Solution Component # 6: Local EHR and Configuration

The local EHR is configured to use the CDS Hooks CDC knowledge module. In this case, the Epic EHR and its BPA configuration was used. In this environment, we can specify such elements as:

• Where it is to be invoked (ambulatory clinics)
• For whom it is to be invoked (physicians)
• When it is to be invoked
  • When signing orders for the MME rule, due to the need for full prescription information to calculate the MME
  • When first entering the opiate order for the urine drug testing rule (note this can be locally configured otherwise)
• Other restrictions (primarily to reduce the cases for which the external CDS service would be invoked, to reduce system load). E.g., the prescription is for an opioid.
• Acknowledge reasons allowed in response to the CDS guidance, and how long and for whom the CDS should be "snoozed" in response.

End Output

Below is a sample screenshot of the end output from the MME rule in Epic. It is currently in operational use at University of Utah Health. Other recommendations have similar outputs. Note that the user-interface displayed here is part of the implementation of these artifacts at a health system. The responses provided by the artifacts here only provide the test for the user-interface.