The Solution

In CCDA Release 2.0 out for Ballot I explained that there is a problem with current content.  In a comment on that post someone involved in the effort made the statement that: "In life, things naturally improve over time, but not if there is nothing to improve upon. Some people complain, and some people deliver."

What I'm looking for is a solution to this challenge, not an excuse to stop the content from going forward.  I want to see HL7 deliver quality standards.  Not addressing a huge issue impacting the implementability of our standards when we have the opportunity is a big mistake.  Fortunately the solution is not that far off.

For all old templates X where a new template ID Y has been assigned, change the ID as follows:
Y.root = X.root
Y.extension = "2.0"

There should be no disagreement that these represent two different identifiers within HL7.  Some might argue that it changes the nature of the namespace represented by X.root.  I would agree, but I would also argue that this is a necessary "bending" of the nature of the namespace that developers will understand, and has a lot of value.

Let's look at few examples.

Gap Analysis
One quick way to do a gap analysis is to add extension="2.0" to all templateId elements found in the output of an existing CCDA implementation, and run that through a validation process for CCDA Release 2.0.  This is very easy to do in software, and will quickly identify areas of concern in your existing implementation.  It doesn't absolve developers of having to do a more thorough review, but what it does do is give them a way to quickly assess the amount of change necessary.  You can do that assessment with an existing document in a few minutes using global search and replace in your favorite text editor.  If you have to change all the template identifiers, that's going to take a few hours or more just to build the transform, and then test it, and then try it out.  The skill levels necessary are very different.  I can assign the former task to a junior engineer, the latter requires a greater degree of skill.

Software Update
After finishing your software changes for a particular template, you update the code to output the extension="2.0" attribute on the template identifier.  You don't have to look this up, remember it, memorize a 15 digit value (or an incompletely followed OID structure change), as an engineer, you just remember it.  That saves you five minutes of coding and cross-referencing.  It allows you to simply update your design documentation, which is another few minutes.  Test cases have to change, but you save a few more minutes there.  Multiply a few minutes here and there by a couple hundred templates and you've saved several days or even a week or two.

Model Updates
Until we have an interchange format, the same process that goes for software update will also have to be manually followed to update tools like MDHT.  If we start with the same template identifiers, update each model as necessary, and then add the extension attribute value.  Again, same kind of value to the implementer.

Version Compatibility Testing
Take an upgraded instance and remove all extension="2.0" attributes.  Run it through the old validator.  What happens?  You can run this test in a very short amount of time and will less skill than is necessary if we change the OID wholesale.  I can write that XSLT in 10 lines or less.  I can use search and replace and do it in seconds.   Make me change every OID and it just got more difficult.

The change I'm requesting makes it much easier to do an update.  How do I know? Because I've gone through similar processes  moving from HITSP C32 version 2.3 to 2.5 where template ID's didn't change (for the most part), and from C32 2.5 and CCDA, where they did.  It wrote the former post in about a day, whereas the latter series of posts took more than a week to get through in effort, and twice that in elapsed time.

Make it easy for us to do the update.  That's what I'm asking for in my negative ballot comments.  And do it the way that templates has already said they want to move forward if you cannot wait for that ballot.  We can even involve the templates workgroup in that discussion.  I don't want to triple the effort to move up to CCDA 2.0, because I too want to move ahead.  Spending more time than we have to in order to upgrade our software isn't going to make HL7 any more friends in the industry.

    Keith