Negation Indicators Considered Risky

The HL7 Clinical Decision Support Workgroup has been looking into the behavior of a Virtual Medical Record.  One of the topics of discussion yesterday was on the use of code and actionNegationInd in the information model (actionNegationInd replaces negationInd to flag acts that didn't or shouldn't occur.)  The problem with this approach isn't that it is wrong, just that it doesn't match up with the typical way that decision support processing obtains information.

When negation indicators are stored separately from codes for the actions, you have to look in two places to determine whether something was or should be done, rather than wasn't or shouldn't be done.  Let's give an example of the issue here.  If you wanted to see if a patient had a prior history of ischemic heart disease, a naive implementation might check thus:

historyOfIschemicCardiomyopathy = false
For (problem in patient.problems)
  if (problem.code = "Ischemic Cardiomyopathy")
    then historyOfIschemicCardiomyopathy = true, exit loop

if (historyOfIschemicCardiomyopathy == true)
  then Execute Clinical Decision Support Rule

This would work MOST of the time.  Where it would fail would be cases where actionNegationInd was true, indicating "No Ischemic Cardiomyopathy".  The right way to check for this is:

historyOfIschemicCardiomyopathy = false
For (problem in patient.problems)
  if (problem.code = "Ischemic Cardiomyopathy"
      AND problem.actionNegationInd = "false")
    then historyOfIschemicCardiomyopathy = true, exit loop

if (historyOfIschemicCardiomyopathy = true)
  then Execute Clinical Decision Support Rule

It would only look at those cases where Cardiomyopathy had not been rejected.   If you think that this isn't really a problem, I can point you to a very well known case that hit the Boston Globe because a diagnosis that was meant to be "ruled out" wound up in the patient's problem list for exactly this kind of reason.  Someone forgot to cross-check the code against how it was meant to be used.

But a better way to handle this would be to look only at confirmed cases first, as in the following:

historyOfIschemicCardiomyopathy = false
For (problem in patient.confirmedProblems)
  if (problem.code = "Ischemic Cardiomyopathy")
    then historyOfIschemicCardiomyopathy = true, exit loop

if (historyOfIschemicCardiomyopathy == true)
  then Execute Clinical Decision Support Rule

This code would not confuse a rejected case with a confirmed one.  If you wanted to search for rejected cases, you might look at patient.rejectedProblems. 

The other point that we discussed in the meeting was "what is a problem list".  From the HL7 Patient Care perspective, you have a "Concern", which represents an item that is the subject of concern of a physician.  That could be a problem, an allergy, a current medication that the patient is on which requires monitoring, a past procedure (e.g., status post cholecystectomy), et cetera.  Other providers view the problem list as containing only those diagnoses that are currently active, and yet others might including findings or symptoms that are not yet diagnosed (e.g., lower back pain), and others might include the problem history as well, or at least recent history.  There are a whole slew of terms that we need to identify.  One way to go about this is to look at a variety of clinical decision support rules and guidelines and look for what those concepts are.  The problem list is obviously one of them, but others include family history, social history, current medications (what does current mean), medication history, allergy lists, et cetera.  Yes, we could wind up in a discussion of what the word "means" means, as well, but at least that way, we can be very clear about the behaviors expected of the VMR.

So another part of this we need to address are defining these concepts in a way that makes sense from the perspective of a clinical decision support implementation.  The definitions need to be formal enough that we can test the behavior of a VMR against them.

I've used the term behavior a couple of times here, and it is an important one.  The point of the VMR is that it provides a way for clinical decision support systems to access clinical information from patient medical records.  The information is already available in a number of different forms, e.g., through HL7 Version 2 messages, Version 3 messages, CDA and CCD documents, from ePrescribing systems in NCPDP SCRIPT, from payers in X12N messages, et cetera.  Part of what VMR does is bring this information to the clinical decision support system in a consistent fashion.  This isn't static modeling, rather, it is dynamic, addressing particular behaviours that the VMR supports when you ask for information.

The VMR operations are at a much finer grain than what you would see in a typically messaging solution, and that is just fine.  There's no reason why an entire message or document wouldn't be consumed by the VMR in one great big swallow.  It's how the VMR responds based on what was in that content that is the subject of discussion.

What I've been talking about in this post is User Interface design, but not in a way that we often think about it.  What we need to look at more in HL7 is how the implementers use the standards we are developing, and how we can make their jobs simpler.  An accurate representation of information is not very useful if it requires a PhD to understand it.  We need to use our knowledge to make it easier for people to use the information in the correct way.  That requires a review of how they use it, and a design that makes that easy.