Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Friday, August 17, 2012

I know not vs. I Don't Know: Allergies

One of the most common requests I get is on dealing with how to express two different issues with allergies:
  1. I know the patient is not allergic to anything.
  2. I don't know whether the patient is allergic to anything.
These are confusing even in speech.  Grahame Grieve recently discussed these in his blog post on NEHTA Exclusion Statements, and adds a third:  
  1. I didn't ask whether the patient was allergic to anything.
I have a slightly different approach to what Grahame proposes for using the CCDA.  It achieves the same functionality, in a slightly different way, and purposefully ignores the fine points of semantics that he made.  Either you know NOT, or you don't know.  The "why" you wrote it that way is not material to the conversation for MOST use cases.

1. I know (or the patient asserts) a lack of allergies:
<observation classCode="OBS" moodCode="EVN" negationInd="true">
  <templateId root="2.16.840.1.113883.10.20.22.4.7"/>
  <id root="..."/>
  <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>
  <effectiveTime>
    <!-- Use value or nullFlavor, not both -->
    <low value="..." nullFlavor="UNK"/>
  </effectiveTime>
  <statusCode code="completed"/>
  <value xsi:type="CD" code="419199007"
    codeSystem="2.16.840.1.113883.6.96" displayName="Allergy to Substance"/>
</observation>

2. I don't know whether there are any allergies:
<observation classCode="OBS" moodCode="EVN" nullFlavor="NI">
  <templateId root="2.16.840.1.113883.10.20.22.4.7"/>
  <id root="..."/>
  <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>
  <effectiveTime>
    <!-- Use value or nullFlavor, not both -->
    <low value="..." nullFlavor="UNK"/>
  </effectiveTime>
  <statusCode code="completed"/>
  <value xsi:type="CD" code="419199007"
    codeSystem="2.16.840.1.113883.6.96" displayName="Allergy to Substance"/>
</observation>

3. I didn't ask whether there are any allergies (and have no other information):
<observation classCode="OBS" moodCode="EVN" nullFlavor="NASK">
  <templateId root="2.16.840.1.113883.10.20.22.4.7"/>
  <id root="..."/>
  <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>
  <effectiveTime>
    <!-- Use value or nullFlavor, not both -->
    <low value="..." nullFlavor="UNK"/>
  </effectiveTime>
  <statusCode code="completed"/>
  <value xsi:type="CD" code="419199007"
    codeSystem="2.16.840.1.113883.6.96" displayName="Allergy to Substance"/>
</observation>

There's not much difference between these three representations, so be careful in processing them.  I don't see many existing EHRs distinguishing between case 2 and case 3, but some do. Don't expect the "I didn't ask" variation to be preserved on import to all systems as anything more than "I don't know".

A couple of additional notes:
id: You may have one (especially if there is a statement in your database about the patient not having any allergies), or you may not (if there's no data).  If you have an id, fill it out, otherwise, use an appropriate nullFlavor.
effectiveTime: Use the value for when the information was recorded/reported in effectiveTime/low.  If there is an effectiveTime/high, it means that the clinical statement stops being assured of being true after effectiveTime/high, which means that we could either be no longer ignorant (in case 2 or 3), or we have new and possibly contrary information (case 1).  So, these three patterns shouldn't be used with an effectiveTime/high element.
value: If you want to be more specific, e.g., to report on medication allergies, you can use a different SNOMED CT Code in the value element (e.g., 416098002 Drug Allergy).  See the Allergy/Adverse Event Type value set.

Found a Bug in CCDA?
It's not hard to believe that a 500 page document might have a few errors in it.  While writing this post, I found one.  If you'd like to report a bug in CCDA, please do so here on the DSTU comments page.  That way, anyone can look for, and read about the issues.  Anyone with an HL7 Login (not membership, just a login) should be able to create reports on DSTUs.