Value sets are collections of codes from one or more terminologies. They are useful for representing the specific drugs, conditions, observations, or other items of interest that have been coded in electronic health records. For example, a value set for the drug warfarin might include all clinical drug codes from the RxNorm terminology that are used when the electronic health records stores a prescription. Value sets are necessary in clinical decision support rules for two reasons. First, they help make the entities referred to in clinical decision support algorithms non-ambiguous. Second, they are used so by decision support knowledge artifacts to identify specific conditions specified in the logic of the rule.

Value sets are also referred to as “concept sets”. The figure shows some of the terminology sources that provide codes useful for constructing values sets for information items in the drug-drug interaction decision support rules on this site. Value sets may be explicitly defined by containing a terminology code for each term in the value set concepts. They can also be intensionally defined using an algorithm that, when executed by a machine (or interpreted by a human), yields a set of such elements.

Value Set Authority Center (VSAC)

Value sets for specific drugs, conditions, observations, or other codes relevant to one or more of the algorithms are hosted on the National Library of Medicine’s Value Set Authority Center (VSAC). Access to these value sets on the VSAC website requires an account with the Unified Medical Language System (UMLS). 

The pertinent value sets for this project are authored under the name “Meaningful Drug Interaction Alerts Author” and stewarded by “Meaningful Drug Interaction Alerts Steward”. Drug codes use the RxNorm terminology, while conditions use ICD9CM. The latest versions for these value sets were published as of version number “20190918” on the date September 18, 2019.

RxNorm codes were added to the value sets under the code system version “2019-08”, with ICD9CM codes using the code system version “2013”. The code system version may be important to note in some use cases since the “status” of a code may be subject to change between versions. Codes that have a status of “inactive” are not considered when looking to match a specific code with a value set. For instance, in the following screenshot, the codes “104847” and “104848” are inactive and therefore will not be available to be matched with from the value set, while the code “1086772” is active and will be available.

Clinical Quality Language (CQL)

CQL files can be used by any healthcare organization to properly identify sets of patients that require a specific message or clinical intervention. CQL is a data standard governed by Health Level 7 (HL7) that is currently a Standard for Trial Use (STU). CQL expresses logic in a human-readable document that is also structured enough for electronic processing of a query. It can be used within both the CDS and CQM domains. In this project, the CQL code is written to operate with HL7’s STU3 version of the Fast Healthcare INteroperability Resources (FHIR) specification.

The CQL code provided for each algorithm was developed and tested using the CQL Testing Framework. Each set of computable CQL code depends on the following included libraries:

  • The CDS_Connect_Commons_for_FHIRv300 and FHIRHelpers libraries included in the artifact define commonly used functions in CQL files and are not specific to the Statin Therapy for the Prevention and Treatment of Cardiovascular Disease (CVD) Electronic Clinical Quality Measure (eCQM) artifact. They are expected to be used with any other CQL file that could benefit from those functions.
  • ReusableFunctions_FHIRv300 includes helper functions that streamline some scripting processes for operating the rules and assist with human readability of the patient resources being read. Examples of these functions include “Report” functions that isolate pertinent portions of the inputted medications, conditions, etc. for a specific test case.

Drools / Docker

A JBoss Drools rule engine (version 6.5.0.Final) uses a custom Java-based controller to load data from an OMOP database. A JDBC driver links the database to the rule engine. From the database, entities for each patients’ relevant diagnoses, drugs, lab measurements, and other risk factors are identified and used in working memory. The rules written use this data to identify patients that satisfy criteria specified for each decision portrayed in the DDI decision tree. The rule engine iterates on a day-by-day basis throughout a specified study period and outputs alerts and relevant factors that occur on a specific day.

The Drools rule engine is available as a GitHub project. This project includes a Docker container  which can be used to virtualize the rule engine so that the audience can customize their own use case by choosing if they want to run one specific rule of interest, or if they have their own OMOP database connection that they wish to input to read data from.

After pulling the docker container using the command docker pull ddicds/idia_rules, The following command can be used to run the docker container over the default synthetic population:

docker run -v ~/simulated-run/:/app/simulated-run -it --rm ddicds/idia_rules:localdb simulated

To run the rules over a custom database connection and/or specify a particular rule  to isolate in the run, the following additional arguments can be added to the above command:

connectionURL={URL} ruleFolder={rule options listed below} schema={schema} user={user} password={password} sslmode=require

By default, all rules are run, but to specify individual rules, strings that can be passed into the ruleFolder argument include:

  • rules_acei_arb_ksparing_diuretics
  • rules_ceftriaxone_calcium
  • rules_citalopram_QT_agents
  • rules_clonidine_betablockers
  • rules_epi_betablockers
  • rules_fluconazole_opioids
  • rules_immunosuppressants_fluconazole
  • rules_k_ksparing_diuretics
  • rules_warfarin_antidepressants
  • rules_warfarin_nsaids
  • rules_warfarin_salicylates

OMOP Value Sets

The value sets used for running the Drools code were developed using the standard vocabulary maintained by the Observational Health Data Sciences and Informatics collaborative. This vocabulary is widely known by its original project name ‘OMOP’. Each of these value sets has a collections of codes from the RxNorm, SNOMED-CT, or LOINC terminology useful for identifying a clinical entity mentioned in the logic of the PDDI algorithms. The identifiers used in the value sets follow the conventions of the OMOP vocabulary which is designed to work with data stored in the common data model developed by the collaborative.