Thursday, February 2, 2012

There's a RSON for that

This question comes from a member of the Query Health team.  He asks:  In CDA Consolidation, is there a way to indicate the reason that something wasn't done?  The reason for his query is that this information is often needed for quality measures.

Yes, in fact there is, but it isn't well described in the CDA Consolidation guide, even though there are long established precedents for how to do it, and conformance statements and a template called Indication to support it (see section 5.12).

In the HL7 Version 3 RIM, there is a <reasonCode> element that can be included in any act (observation, procedure, et cetera).  It is defined as follows:
A code specifying the motivation, cause, or rationale of an Act, when such rationale is not reasonably represented as an ActRelationship of type "has reason" linking to another Act.
Unfortunately, the <reasonCode> element isn't included in any clinical statement act found in the CDA model.  However, the definition describes an alternative:  Reasonably representable as an ActRelationship of type "Has Reason". When we look in the HL7 ActRelationshipType vocabulary, we can see the definition of this relationship as follows:


RSONhas reason
The reason or rationale for a service. A reason link is weaker than a trigger, it only suggests that some service may be or might have been a reason for some action, but not that this reason requires/required the action to be taken. Also, as opposed to the trigger, there is no strong timely relation between the reason and the action.


It really does fit the bill.  You would represent the reason that something was done or not done in CDA as follows:

<act ...>
  ...
 <entryRelationship typeCode='RSON'>
   <observation moodCode='EVN' classCode='OBS'>
        ...
     <code code='...' codeSystem='...' .../>
   </observation>  
 </entryRelationship>
</act>

IHE uses this structure to document the reason for an encounter, procedure or medication being performed or ordered.  In that case, the inner act is a reference (pointer) to the original problem, allergy or other condition that is the reason for the new act.   This was incorporated into the CDA Consolidation guide as the Indication template.  That template is described as follows:

The Indication Observation documents the rationale for an activity. It can do this with the id element to reference a problem recorded elsewhere in the document or with a code and value to record the problem type and problem within the Indication. For example, the indication for a prescription of a painkiller might be a headache that is documented in the Problems Section.

But the Indication template can also used to to document the reason that something hasn't been done.  In the above, the act element could be <substanceAdministration negationInd='true'>, which means that a substance (e.g., an immunization) wasn't given. Negation only affects the "descriptive attributes" of the class, it does not affect associations, so the reason applies to why the act wasn't performed.  A similar structure was incorporated into the HITSP C83 entry to indicate the reason an immunization was not performed.

--  Keith


2 comments:

  1. I thought it Ruby Script Object Notation.

    ReplyDelete
  2. While I think the general concept might work I dont think saying use the Indication template is the right way to go. The Indication template says that the id element SHOULD point to an item in the Problem List, and that the code element should be a code from the Problem Type code system. Granted they are SHOULD's but it doen't feel very correct in doing anything else and not all negations in quality measures are from the problem list. For instance a measure negation could simply because they have not been to the doctors during the relavent measure period, should there be a negated entry for the office visit that didn't happen as well?

    ReplyDelete