40 years of healthcare "decision support" APIs

Medical logic modules, Arden syntax, GELLO, and CDS Hooks

Starting out in healthtech as a programmer can be daunting. Especially as a founder. The technical language and acronyms are probably not going to be familiar. HL7, DICOM, FHIR, USCore, LOINC. Unrecognizable terms to the uninitiated. Brendan Keeler’s A Brief & Opinionated History of Healthcare Standards provides an overview if you need to catch up.

If you’re trying to automate/assist clinical workflows, you’ll eventually stumble upon the term Clinical Decision Support (CDS). Or, the category of techniques and technologies that attempt to aid clinical interpretation and decision making. A simple CDS could be a Venn diagram/cheatsheet of diseases states intersecting groups of symptoms. A more sophisticated example might be an alarm system in a hospital when an abnormal heart rate pattern is detected in a patient. Orderly execution and prioritization.

You might be surprised to learn, as I was, that there have been many attempts over the last four decades to codify medical decisions into data structures, domain-specific languages, and programming protocols — to automate healthcare decision making. And that some of the challenges are the same all these years later.

I’ve tried to organize a map of this space.

Medical logic modules

A medical logic module is just the idea that we can encode a medical decision making process in an abstract way and guarantee the consistent application of that logic given new cases. The earliest electronic examples in the hospital context come from the 1980s.

Arden syntax

Arden syntax was not the world’s first domain-specific language for medical logic, but was the culmination of earlier experiments like Health Evaluation through Logical Processing (HELP).

¹

Created out of a partnership between IBM and Columbia Presbyterian Medical Center in 1989-1993, Arden is fairly readable to a programmer. There are four root-level category keys in nested key-value pairs: maintenance, library, knowledge, and resources. Defined function calls can be performed, and simple arithmetic comparisons and boolean logic can be encoded.

For example, this is the root-level library key for a diastolic blood pressure check module:

And it’s corresponding knowledge key, which includes logic for different outcomes, and writing a decision:

Interestingly enough, Arden was designed to natively support vector-based processing, inspired by APL, which would later become a feature familiar to scientific programming languages.

Notably, even back in 1989, concerns over the accuracy of machine interpretation, and the “black box” problem were raised:

Clayton [an author and organizer of the group who produced Arden] had received funding from IBM and had argued with them about the liability that might be incurred if the clinical information system gave wrong suggestions or reminders. He felt that the knowledge base should be public (as in any medical textbook) and then individuals or providers could choose to validate and use that knowledge rather than having it “baked into” a proprietary information system.

Arden continues to be supported today, through an HL7 working group. Version 2.9 was released in 2013, and annual committee meetings continue. An open source project Arden2ByteCode implements a compiler of Arden to JVM bytecode. Medexter Healthcare produces the ArdenSuite IDE.

Interoperability of input data, however, continues to be a major barrier to adoption. Even if decisions can be abstractly encoded, Arden inputs aren’t strongly typed. Slight differences between healthcare settings and systems, differences in code-mappings, all make sharing code hard - even with the “fuzzy matching” introduced in later versions. We can imagine an extension to Arden that would introduce LOINC Code type constraints.

GELLO & GLIF

A major obstacle to sharing computable clinical knowledge is the lack of a common language for specifying expressions and criteria. Such a language could be used to specify decision criteria, formulae, and constraints on data and action. Although the Arden Syntax addresses this problem for clinical rules, its generalization to HL7's object-oriented data model is limited. The GELLO Expression language is an object-oriented language used for expressing logical conditions and computations in the GLIF3 (GuideLine Interchange Format, v. 3) guideline modeling language.

GELLO (“guideline expression language, object-oriented”) emerged out of a desire to query data modelled against the “HL7 Reference Information Model”. GELLO isn’t a replacement for Arden syntax, but something more like a superset concept. In fact, GELLO expressions were designed to be used inside of Arden, like in the below example:

²

GELLO itself emerged out of GuideLine Interchange Format (GLIF) - specifically as a solution to the problem of needing a general purpose language to write guideline expressions in, separate from the structure of the relationship between decisions in the guidelines themselves.

By 2004, efforts were made to standardize GELLO - and today it is an HL7 v3 standard. However, its status date has not changed in 11 years and it hasn’t been the subject of any recent publications by its parent, the Clinical Decision Support group. Only two results in the last ten years appear on a PubMed search for “GELLO”.

CDS Hooks

The most recent development in programmatic decision support systems is CDS Hooks. Unlike the previous examples, CDS Hooks is not a syntax for describing or evaluating the conditions of a medical record, but is instead a workflow for exchange and retrieval of decisions in contextual situations. Take for example the below example of creating a pharmaceutical order. This new prescription event triggers a CDS service, that returns contextually useful information, such as expected co-pay for the patient, or generic alternatives.

The responding service can implement whatever languages or patterns it needs to determine its response. Including even Arden syntax itself. To this point, there has been recent research into delivering Arden syntax-described decision making through the CDS Hooks API.

³

Ultimately, this might present more meaningful opportunities for penetration of decision support systems into real-world clinical practice. Brendan Keeler describes the opportunity CDS Hooks present:

CDS Hooks is a relatively new standard that's going to heat up big time. Given the recent focus on AI and machine learning, the demand for real-time feedback into end-user workflows will likely grow, as it’s the most straightforward application of such technologies. Looking forward, expect other action points like note signing (or even draft saving), the addition of problems to the patient's chart, or more mundane (but very important) administrative tasks for schedulers, registration staff, or back-office users (Registration Decision Support? Admin Decision Support?) to hook into centralized, cloud-based best-practice repositories. HL7 will want to manage those standards, as will other standards bodies and vendors.

1. Hripcsak, G., Wigertz, O. B., & Clayton, P. D. (2015). Origins of the Arden Syntax. Artificial Intelligence in Medicine. doi:10.1016/j.artmed.2015.05.006

2. https://pubmed.ncbi.nlm.nih.gov/15360796/

3. http://www.meduniwien.ac.at/kpa/publications/dHealth_2020_--_Exploring_Methods_of_Implementing_Arden_Syntax_for_CDS_Hooks.pdf