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, March 29, 2012

The Road to Hell...

... is paved with good intentions.  -- Anonymous
My current frustration is with a proposal in HL7 Structured Documents to modify the CDA Consolidation guide to add clarifications needed for the proposed Standards and Certification rule.

I think it is the right idea, but the wrong approach for several reasons:

The idea that the industry needs guidance and clarification on how to implement the standard to meet the regulation is dead on.  The problem is that we don't know what the regulation will say until it is finalized this summer.

Let's take a simple example:  As currently specified, the guide uses the Problem Observation template for both the Problem List section, and several of the diagnoses sections (e.g., Discharge Diagnoses).  That template says that the vocabulary for the problem @code SHOULD be selected from SNOMED CT.  But the rule says that Diagnoses should be encoded using ICD-10-CM, and problems in SNOMED CT.  So we could "fix" the guide to make ICD-10-CM one of the allowed vocabularies.

Now, the ICD-10-CM / SNOMED CT issue is already drawing a lot of attention in the proposed rule.  There are three possible things that could happen, and some of them depend on what CMS does with respect to ICD-10-CM compliance.  CMS could delay enforcement on the use of ICD-10, or they could choose not to.  If they delay enforcement, it could be 6 months, it could be a year, we just don't know.  Then, ONC could respond to what CMS does and to comments by:  Dropping ICD-10 altogether and just using SNOMED CT (avoiding any issues), or staying the course (hoping that certification and meaningful use could help CMS with its ICD-10 issues), or allowing ICD-9 or ICD-10 or SNOMED CT (thinking that will create the path of least resistance for all involved).

There are good arguments for any of the three responses, and I'm hard pressed to predict what will happen.  In every possible alternative, the Consolidated CDA guide actually supports the menu of choices that seem likely, because SNOMED CT is a SHOULD, not a SHALL requirement.  If we guess right, there's no problem.  If we guess wrong, then we've simply wasted our time, because we'll have to reclarify subsequently.

Let's look at another suggestion:  Strengthen the CDA General Header constraints to require certain demographic fields and vocabularies: preferred language, race and ethnicity.  As presently written, the General Header constraints are pretty good, and CDA already supports all the required fields.  I'd actually like to see these constraints be adopted a bit more internationally.  Strengthening the constraints weakens the ability to reuse the general header internationally (remember, IHE contributed a lot of its work to this effort, and it is used internationally).  If we make Consolidated CDA too MU-centric, we confine it in a box that could prevent others from using it more broadly.  As it stands today, the general header constraints work quite well  in other guides, for example, in an EMS guide currently being balloted by HL7.  But, if we modify them to support MU, then some data elements which may not be available at an accident site now become required.  Yes, you could say "I don't know", but it's still more work.

I'm not a great shot.  I'd much rather try to shoot a sitting duck (the final rule), rather than try to hit a duck in flight at night (the proposed rule).

What I really want to see is HL7 put together an informative document that teaches people how to USE the CDA Consolidation Guide to meet meaningful use requirements AFTER we know what those requirements are.  What seems likely though, is that we'll put together something that doesn't address what implementers needs fully, and we may likely be having to go back and fix things later.  That is a distraction, and a waste of valuable volunteer effort.  This comes at a time when I'm trying to give developers a good grounding in what we already have; I feel in some ways like I'm trying to build a foundation in sand.

The choices to me are pretty clear cut:

  1. Build something now to hit a target we can not identify well, and limit ourselves to those things that we are pretty sure we can predict, and fix it fully later, or;
  2. Build something in a few months that will address all of the issues that industry needs.
It seems to me that our efforts would be better spent on #2.  As I posted previously, and David Tao, and others in the S&I Framework efforts have determined, Consolidated CDA meets the requirements of the proposed regulations.  We should stop trying to "fix it" to meet requirements that aren't even done yet,  give the industry the time it needs to understand it, and then explain how to use it in a guide.   If we take that approach, I'll be happy to help as much as I can.  

1 comment:

  1. Unfortunately, the CDA Header cardinality constraints [0..1] for race and ethnicity are inadequate for countries where multiples of these are permitted in EHRs. For example, here in New Zealand where up to 3 ethnicities can be recorded.

    ReplyDelete