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.

Tuesday, January 8, 2013

What were we trying to do?

Wes Rishel recently posted about an ongoing discussion on the HL7 Structured Documents list.  Another discussion is also cropping up about particular wording ("such that it") used in the C-CDA specification.  And then there's the discussion about what the intent was for the C-CDA (and former CCD and C32 content) about the results organizer.

All of this stems from one challenge, which is how we incorporate requirements (or fail to in most cases) into the specifications.  The specifications tell you what to do, but in many cases, not why.  The why is very important to implementers because it explains the reason it is the way it is, rather than some other way, and provides further implementation guidance about the intent behind each template or structure.

Most HL7 V3 specifications include story boards (examples of use cases really), but CDA implementation guides usually don't because they are still written in Word.  Even so, V3 story boards are often rather incomplete with respect to details.

Some of these challenges are a result of tight deadlines.  All too often, we've been rushed to get something done because of various deadlines that aren't under our control.  It takes longer to write something that explains the rationale behind the specification in addition to writing the specification.

I've pushed for both rationale and examples (see rules 15 and 16 here), but the tooling we have today (in HL7) doesn't support either yet directly.  Back in HITSP I insisted that value sets and data elements had more than just a name.  They had to have at least a sentence defining them.  I think the same should be true for every constraint.  If we can't write a sentence explaining why it is there, then perhaps we shouldn't have it.

One of my hopes is that the ballot quality committee newly formed in the HL7 Publication workgroup will take up some of these issues to make this content easier to read.

This isn't just a problem that is experienced in Healthcare Standards.  It's fairly common in other complex standards.  One of the "bibles" used by many in the structured documentation world is Charles Goldfarb's The SGML Handbook.  That book includes the entire text of the SMGL Standards (ISO 8879), extensively annotated. Michael Kay's various books on XSLT are similarly valuable (I own XSLT 2nd Edition).  I hardly every try to do any serious HTML programming without dragging down my copy of O'Reilly's Flamingo book, Dynamic HTML, by Danny Goodman.  All of these books on my shelf have extensive tabs, post-it notes, and corner turn-downs marking important sections.  Each of them is rather large (600+, 900+ and 1300+ pages respectively).  Even though I've read SGML, XSLT, HTML and CSS standards directly, these books are my primary sources.

When I wrote The CDA™ Book, those books were how I aspired it would be used, but I could barely manage 300 pages in the year I spent on it.   While I might readily generate more than 500 pages annotating the Consolidated CDA Specification, I don't have the time (or funding) to do so, nor do many others involved in development of these specifications.  The tooling challenge has a similar issue.   I don't know exactly how to solve this problem, but I do know that it is one that needs to be solved.  Like everything else, one key ingredient to the solution will be time.