NEHTA Clinical Documents: Exclusion Statements

Aug 14, 2012

This is the first of a series of posts looking at implementation issues associated with NEHTA clinical documents. These are based on the common questions I get from implementers. The focus of the first few posts is going to be the “Medical History” Section in the SHS, and the related sections in other documents. But before I can consider those sections in detail, I need to talk about Exclusion Statements in general. Many sections in the NEHTA Clinical Documents include an exclusion statement. The exclusion statement idea is adapted from openEHR. A typical use is in the Adverse Reactions, where you can list an series of adverse reactions, like this:

Well, that’s a single adverse reaction, and pretty straight forward. But what does it mean if the list is empty?Well, that might mean:

  • The system didn’t populate the section at all
  • The clinical user didn’t ask (or otherwise investigate)
  • The clinical user or the patient decided not to include any adverse reactions for their own reasons (ok, that’s silly for adverse reactions, but would make more sense for a medication that betrayed some sensitive problem, for instance)
  • the patient doesn’t have any known allergies

It might be possible to try handling these through a variety of nullFlavors (NI, NASK, ?, NA?) but that would be wrong: the last three, and particularly the important last one are statements of knowledge, not reason values for missing adverse reactions.

So to handle this, there’s a positive statement, called a global exclusion statement. You either provide 1 or more items (Adverse Reactions in this case), or an exclusion statement to explain why there’s no items in the list. The possible values for the exclusion statement are:

Code displayName
01 None known
02 Not asked
03 None supplied

This would be represented in CDA like this:

<entry>
 <observation classCode="OBS" moodCode="EVN">
  <code code="103.16302.120.1.1" codeSystem="1.2.36.1.2001.1001.101" 
    displayName="Global Statement" />
  <value code="02" codeSystem="1.2.36.1.2001.1001.101.104.16299" 
    displayName="Not asked" xsi:type="CD" />
 </observation>
</entry>

The blue part - that code changes for the different exclusion statements to be clear about what the exclusion statement concerns.

Alert v3 type users might challenge the last value - none supplied; this crosses the line into nullFlavor territory. And maybe it is, but only partially. And it’s a lot cleaner to make a simple rule: either you have items, or an exclusion statement, but not both.

One issue with this is that the codes are not well defined. Here’s proper definitions for the codes above (sourced from here, but it’s behind a firewall):

“None Known” is a positive clinical statement that  investigation has not found any items:

  • For allergies, the patientor patient’s agent/guardian has asserted that he/she is not aware of any allergies (NKA – nil known all ergies)
  • For medications, the patient  or patient’s agent/guardian has asserted that the patient  is known to be taking no medications
  • For diagnoses, problems and procedures: the patientor patient’s agent/guardianhasasserted that there isno known events torecord.

“Not asked” is an affirmation from a clinical user  that they have not been able to ask the patient (for whatever reason)

“None supplied” is the default position, to be used when:

  • The patient or the clinical user choose to withhold information
  • The database lists nothing for the category, but it is not known whether the other two categories apply.

These definitions are important - programmers