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 available now, 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 also is intended to be a rules language that is independent of proprietary tools, and to be executable. The latter means that the decision model that is created in an authoring tool can be evaluated or run by a computer program.

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. The 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 the authoring easier. DMN includes an expression language called FEEL which stands for Friendly Enough Expression Languages. Existing scripting languages such as Javascript were considered not friendly for business users. S-FEEL or Simple FEEL allows simpler expressions while full FEEL supports very complex operations and expressions. FEEL’s syntax is friendly for humans as it is natural language-like; it 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.

Here’s an example of a DMN Decision Requirements Diagram:

The graph above is the Decision Requirements Diagram showing many of the inputs that go into making a recommendation for aspirin. Note that 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 below in the Decision Table for the “Candidate for Aspirin” decision. The diagram show how this complex rule may be easier to understand as it is decomposed into simpler decisions. Many may find this approach also easy for authoring a rule.

The table above shows a guideline for the use of aspirin for the primary prevention of cardiovascular disease and colorectal cancer encoded as a DMN rule. The rule is a loose and partial interpretation of the guideline. A complete interpretation of the guideline in 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.

Can DMN be used for creating shareable knowledge artifacts for CDS? If so, then we can take advantage of many of the 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 among others, a CDS rule, an order set, or a structured documentation template to be a CDS knowledge artifact. A few years ago, my colleagues in the CDS Consortium and I had published a four-layered approach to authoring shareable knowledge artifacts for CDS starting from a clinical practice guideline. In our paper, we defined the four-layers as:

1. Level 1: Narrative – this is a clinical practice guideline, a regulation, or a policy document. In DMN, the narrative layer is associated to the decision models as knowledge sources.
2. Level 2: Semi-structured – this layer models recommendations from guidelines as decisions about the interventions that are possible 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 so as to make them computable and precise. By using FEEL expressions and Decision Tables, decision models in DMN are now structured.
4. Level 4: Executable – At the Executable Layer, 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 automatically be 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.

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, there is a combination of these users: clinicians may draw the decision requirements diagram (Level 2). Informaticians model the decision tables and the inputs in more detail, such as specifying the 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 the layered approach to knowledge authoring.

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 of these 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 the elements above.

There also are questions about how DMN might fit with 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. If you would like to discuss how DMN might be used in CDS, or have topics you’d like me to discuss in future posts, please comment below, contact me on LinkedIn, or use the Contact form on this site.