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 5, 2011

Comments on the CDA Consolidation Guide

This is the last thing you are going to hear from me on this topic for a little while ... at least until the HL7 Working Group Meeting later this month.

I just uploaded my ballot comments (an Excel spreadsheet) on the HL7 CDA Consolidation Guide.  I copied my comments verbatim from what IHE prepared and agreed to this afternoon.  There was barely enough time to prepare those, and all we looked at were problems, medications and allergies.  Some of the comments also came out of the CDA Documentation Work group's review of the project against  requirements the work group agreed upon.

Overall, I'm very disappointed with what has been produced to date.  I'm also uncertain as to the future of this project.  We sorely  missed our goals in this round of balloting.  There's a tendency in the Structured Documents workgroup to push to meet arbitrary and/or unreasonable deadlines (in my personal opinion).  This is especially true when there are external forces like our national agenda pushing so dreadfully hard on this project.  It's hard to get anyone to slow down.  The idea that this guide could become the basis for Meaningful Use Stage 2 still has a lot of people excited.  

The project has got a LOT of potential, and I still support it.  We need to take a step back from the current deadlines.  If they remain, I don't believe the project will succeed.

What we need is a tool that will solve the problem.  To get there, we need to understand the requirements that tool must meet.  That includes the template meta-model the tool must support, the requirements on the documentation that the tool must produce, and requirements on production of the end result.

We also need the data of the pre-existing work, entered into the tool, and vetted against existing conformance critiera.  Getting at the HL7, IHE and HITSP conformance data is not an insurmountable task.  Much of it is already in machine readable form (Schematron) and structured text (even if it is Microsoft word tables or PDF files).  Extracting and Vetting the data is tedious but doable.  I've previously extracted data from IHE and HITSP specifications before -- it truly can be mind-numbing.  It takes about a week or so (effort, not elapsed time -- that's much longer in my world).

This is what it takes to get the data:

  • For documents:  Extract table to spreadsheet.  Normalize to common format.  Generate XML from spreadsheet rows.
  • For sections:  Same general idea.
  • Conformance constraints:  Extract these from source documents based on a conformance style (I built a list of constraints in HITSP specs by ensuring all constraints used the same style, then generated a TOC using word from that style (w/o page numbers).  If no common style is used, create and apply one manually (mind-numbing but actually pretty quick work).

After we have the existing template data, we can import it into MDHT.  Then we need to modify the constraints to produce the new templates, and compare the differences.  That comparison can be automated if the template meta-model is appropriately designed.

Trying to re-architect something that took six years to develop across three organizations which includes hundreds of templates and thousands of rules should NOT be done manually.  I was involved in most of these efforts, and I did quite a bit of that work manually.  It wouldn't hold together today if it hadn't been for the efforts of one person who QA'd that work across the same set of organizations.  It won't scale.  People cannot keep up with what we need.

But what did we do in the CDA consolidation process?  We relied on people to identify inconsistencies when software would have done a better job.  We relied on people to create examples when software could have done so more accurately.  We still rely on people to produce the final schematron. We relied on people to produce a change log.  We relied on people when what we wanted to start with was automation.

Let's get smart, and go back and build the automation that we want.  MDHT is a great start.  All you need do is compare this (HL7 Genetic Testing Report Guide ZIP file using MDHT) to this (CDA Consolidation ballot).

And what should we do in the interim while we develop MDHT?  Well, six years of effort may not have produced the greatest set of implementation guides, but C83 and C80 work for us already today.  More than 250 EHRs support much of it already.  A couple of small changes in Meaningful Use stage 2 would accomplish many of the documentation goals that the Transfers of Care project has.  C83 already includes templates that support H&P, Progress Notes, Consult Notes, Emergency Deparment Encounters, Referrals and Discharge Summaries.  These come from the very same source projects that the CDA Consolidation project is working with.  If you cannot wait for harmonized output from MDHT, then the next best thing is to work with the harmonized results that we humans produced over the last six years.

0 comments:

Post a Comment