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.

Thursday, August 16, 2012

Is that an Active Problem?

One of the questions recently raised for Query Health is how to determine whether a problem is active or not.  This post applies to CCDA, and to Query Health, so listen up ;-)

There are a lot of ways to address reporting of the problem status:

In CCD and CCDA, there's the problem status observation, which evolved out of the problem status field in CCR.  This observation allowed one of several SNOMED CT codes to be attached to an observation associated with a problem.  I never liked the CCD value set, because it contained problem statuses like "Rule Out" and "Ruled Out", "Chronic", "Intermittent", and "Recurrent", in addition to "Active", "Inactive" or "Resolved".  That value set suffers from the Vehicle Type problem I've discussed before.  So, the HITSP C32 restricted that to Active, Inactive or Resolved, and clarified the difference between inactive and resolved.

So, that's one way you could do it.

But there's also the Problem (or Allergy) observation itself.  If there's an end date on the observation, that indicates when it stopped being a problem.  If there's no end date however, you don't know if it has stopped yet.  The assumption that the problem is still active is probably reasonable based on the documentation given, but knowledge outside of the document might tell a provider otherwise (e.g., for self-limiting problems).

Finally, though, there's the Problem Concern Act (and the Allergy Concern Act).  These acts wrap the problem (or allergy), and indicate when the problem (or allergy) became a concern to the provider (e.g., were added to the problem (or allergy) list, and when they stopped being a concern.  The concern act represents the Concern class, and was originally discussed in the HL7 Patient Care Workgroup back in early 2005 (and perhaps even earlier).  Back then, it was called Condition, but since then has been renamed Concern.  Concern is perhaps the most critical class in HL7 V3 that supports problem oriented medical records.

The concern is described in the Care Provision Domain, in the Care Structures topic, and was included in the Care Record DSTU back in 2006 if I remember correctly.  The material is currently being revised by HL7.  The Concern Act structure was adopted in CCD and CCDA, but never quite explained as well as in the original Patient Care work. The easiest place to find it (for HL7 Members) is in the 2008 Ballot Archives.

One of the key statements in that work was on the use of statusCode in the concern act. These are the meanings of the values in statusCode for that act:

new - draft (not messaged, we use these internally though)
active - currently being concerned
completed - resolved concern
aborted - a concern which we decide to drop without resolution
suspended - a concern which is active but we are setting it aside
nullified - a concern which was created in error
obsolete - a concern which has been replaced by another concern

In CCDA, the only values allowed are active, completed, aborted, and suspended.

Also, in CCDA, there are rules for the Allergy Concern Act which SHOULD be copied to the Problem Concern Act.

SHALL contain exactly one [1..1] statusCode, which SHALL be selected from ValueSet ProblemAct statusCode 2.16.840.1.113883. STATIC 2011-09-09 (CONF:7485).
SHALL contain exactly one [1..1] effectiveTime (CONF:7498).
If statusCode="active" Active, then effectiveTime SHALL contain [1..1] low (CONF:7504).If statusCode="completed" Completed, then effectiveTime SHALL contain [1..1] high (CONF:10085).
So, if you want to know my preferred way to indicate whether a problem is active or not, it's using statusCode on the concern act.  It's far simpler than any other mechanism.  If the concern act wrapping the problem or allergy has a statusCode of active, then the problem is active, and if it say's completed, then it's resolved.  Any states beyond that invoke electron-microscopy and angel detectors.

The next trick will be to express this in HQMF.  This is actually not difficult at all.  We add an inner actCriteria where the classCode = CONC (to represent the related concern for this problem), and where statusCode has the value Active.

          <id root="0" extension="HasDiabetes"/>
          <statusCode code="completed"/>
          <value xsi:type="CD" valueSet="2.16.840.1.113883.3.464.1.37"/>
            <observationReference moodCode="DEF">
              <id root="0" extension="Problem"/>
          <sourceOf typeCode="SUBJ" inversionInd="true">
            <actCriteria classCode="CONC">
              <statusCode code="active"/>

-- Keith


Post a Comment