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, May 23, 2013

Ours is to Reason Why, What Others Do or Nae

What follows came up on the Structured Documents call today.  Several of us agreed to propose a fix to this.  Here's my first crack at it:

There's some inconsistency between Consolidated CDA and QRDA when reporting on reasons why something was or wasn't done.  Consolidated CDA has the Immunization Refusal Reason Template, which models refusal in the way we agreed to handle the missing reasonCode attribute on various acts in CDA Release 2.  That method specified that a reason for doing or not doing something would be represented by an entryRelationship with typeCode = RSON, in an observation where observation/code indicated the reason why.  But we have no such templates in CCDA for reasons associated with other clinical activities, such as refusal of a medication, or other procedure.

In QRDA Release 2, we have Patient and Provider preference templates. These are used as reasons why things aren't done and are defined as follows:
Preferences are choices made by patients relative to options for care or treatment (including scheduling, care experience, and meeting of personal health goals) and the sharing and disclosure of their health information.
Provider preferences are choices made by care providers relative to options for care or treatment (including scheduling, care experience, and meeting of personal health goals).
I would merge these two:
Preferences are choices made by a person relative to options for care or treatment, including scheduling, care experience and meeting of health goals, including the sharing and disclosure of information.
When preferences are expressed as the reason for doing or not doing something, they more often than not are related to the act done or not done by the RSON act relationship as above, however, in several places in QRDA Release 2, it uses the REFR act relationship. This looks like a simple mistake to me.  To make it easier, I'd just include the act relationship and vocabulary constraints within the "Reason" template, so that we stop having to say all that stuff repeatedly everywhere that the reason is used.

Rather than having a code to identify who had the preference, I'd rather have codes that indicates that indicate the judgement or assessment made (e.g., religious preference, duplicate treatment, et cetera), and let the source of the information being recorded indicate whose preference we are talking about (provider or patient).  I'm not quite sure what the correct participation is here, but responsible party (the person in this case, who has primary responsibility for the reason being specified) seems to be closest.  Within that, the role class could then indicated whether this person was the patient, the patient's guardian, the provider, et cetera.

Hopefully, that could clean up the confusion that we have today.


Post a Comment