Can DMN Be Used to Create Shareable Knowledge Artifacts for CDS?

Decision Model and Notation (DMN) is a recent standard from the Object Management Group for modeling decision rules. Its first version was published in September 2015. With tools supporting DMN becoming more widely available, there is an increasing interest in its use.

DMN is designed to be very friendly for business users (not developers) to create and manage decision rules. More on that in a bit. DMN is also intended to be a rules language that is independent of proprietary tools — and to be executable. The latter means that a decision model created in an authoring tool can be evaluated or run by a computer program.

How DMN Models Decisions

In DMN, decisions are modeled using a visual graph notation known as a Decision Requirements Diagram. This diagram shows decisions and the inputs to a decision as nodes in the graph. The logic in a decision node is commonly specified in the form of a decision table. Decisions can be annotated with knowledge sources such as guidelines or journal articles that are the supporting evidence for the decision rule. Complex decisions can be decomposed into a series (or graph) of sub-decisions to make authoring easier.

DMN includes an expression language called FEEL — Friendly Enough Expression Language. Existing scripting languages such as JavaScript were considered not friendly for business users. S-FEEL (Simple FEEL) allows simpler expressions, while full FEEL supports very complex operations and expressions. FEEL’s syntax is friendly for humans — it is natural-language-like and even allows spaces and mathematical operators in variable names. However, this syntax makes it very challenging to implement parsers, leading to only a handful of execution engines for it to date.

As an example, a Decision Requirements Diagram might show many of the inputs that go into making a recommendation for aspirin. The diagram itself does not show how the inputs are combined logically to reach a conclusion; that level of detail is the purview of the decision node and is illustrated in a Decision Table for the “Candidate for Aspirin” decision. The diagram shows how a complex rule may be easier to understand when decomposed into simpler decisions — an approach many find easy for authoring a rule.

Such a decision can encode a guideline for the use of aspirin for the primary prevention of cardiovascular disease and colorectal cancer as a DMN rule. A complete interpretation of the guideline as a CDS rule in CQL can be found at AHRQ’s CDS Connect site. We’ll walk through a comparison of DMN vs. CQL for this same scenario in a future post.

A Four-Layered Approach to Shareable Knowledge

Can DMN be used for creating shareable knowledge artifacts for CDS? If so, we can take advantage of many DMN tools to author knowledge artifacts and implement CDS services. Jerry Osheroff, author of the HIMSS CDS Guidebook, states that “clinical decision support (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.” Accordingly, we consider a CDS rule, an order set, or a structured documentation template — among others — to be a CDS knowledge artifact.

A few years ago, my colleagues in the CDS Consortium and I published a four-layered approach to authoring shareable knowledge artifacts for CDS starting from a clinical practice guideline:

1. Level 1: Narrative — a clinical practice guideline, regulation, or policy document. In DMN, the narrative layer is associated with decision models as knowledge sources.
2. Level 2: Semi-structured — models recommendations from guidelines as decisions about possible interventions in specified clinical scenarios. Semi-structured recommendations are loosely analogous to the Decision Requirements Diagram in DMN.
3. Level 3: Structured — the decisions are specified with sufficient structure to be computable and precise. By using FEEL expressions and Decision Tables, DMN models are now structured.
4. Level 4: Executable — knowledge is structured for use within a specific type of CDS tool (e.g., a reminder), within a specific clinical information system, at a particular clinical site. In many cases, executable knowledge can be automatically translated from the Structured Recommendation of Level 3. DMN considers itself to be an executable language and can also be translated to other rules languages for execution.

Who Authors CDS Rules?

A major objective of DMN is that business users (i.e., not programmers) author the rules. For CDS rules, who are the business users? Are they practicing clinicians who perhaps best understand the business needs? Are they informaticians who understand the data and the intervention models? Are they analysts in IT? Perhaps it’s a combination: clinicians may draw the decision requirements diagram (Level 2). Informaticians model the decision tables and the inputs in more detail, including specifying value sets (Level 3). IT analysts are responsible for integrating the rule and testing it within the operational clinical platform (Level 4). DMN appears to be supportive of this layered approach to knowledge authoring.

So — Is DMN Enough?

Back to our question: can DMN be used for creating shareable knowledge artifacts for CDS? I believe DMN is insufficient for this purpose. DMN models decisions, whereas knowledge artifacts for CDS include much more — triggers, contexts, workflow integrations, and interventions. All of these elements are needed for true interoperability. Some could possibly be modeled in DMN, but would you really author a structured documentation template as a decision? If DMN were to be used for creating shareable knowledge artifacts for CDS, the standard would need to be further expanded to accommodate these elements.

There are also open questions about how DMN might fit with the HL7 Knowledge Artifact Specification, with FHIR Plan Definition, and CQL. That is a topic for a future blog post.

Many thanks to Vipul Kashyap, PhD for exchanging ideas that led to this blog post.