Failure does not equal lack of progress

This week is the "public comment preparation" meeting for several IHE domains.  At this meeting, profile authors are supposed to bring content for Volume II of their profile supplements for committee review.  I'm working on the CDA Consolidation Harmonization profile, and I failed to bring any content.  I could blame it on software (the second to last bug has been fixed), illness (I had two run-ins with illness because I failed to take some basic precautions during recent travel), or just simple complexity, or the fact that I haven't yet figured out how to clone myself.

Even though I failed, we are still making progress, and I still expect this profile supplement to get published this year, though perhaps not as fast as we all want or need it to be.

You might be interested in how this is all going to work, how is IHE going to harmonize international profiling efforts with a US realm specification, and deal with the massive changes this is going to have on its existing work.

The first step is that we will be introducing template versioning into IHE profiles so that when a template has a version change, we don't have to adopt a new template identifier in templates that use the new version.  That was a big challenge caused by previous methods of handling changes to templates in CDA.

The old way of doing it was something like this:  Template A has a constraint that says that Template B appears in it one or more times.  However, when template B changes, it is given a new identity (e.g., template B').  In order to fix template A, we have to change one of its constraints (the one about template B) to say that it uses B' instead.  Because we've changed template A in a way that is not backwards compatible with the previous template, now we need to reidentify template A, so that it becomes template A'.

In the new way of doing things, Template A will have a constraint that says that some version of Template B appears in it one or more times.  When template B changes, it is given a new identity that is comprised of the identity for the set of template versions for it, and its version number.  So, now, when we create a new version of template B, template A will NOT need to change, because it can now include either Template B version 1, or Template B version 2 (and in fact always allowed that, we just didn't previously have a template B version 2 until it got created).

Versions will have major and minor number changes.  A change in a template minor number means that readers and writers can still understand the newer template, they just may not have gotten all the additional detail supplied in the new version.  A change in a template major number means that readers and writers will know that something has changed in a way that isn't backwards compatible.  If they don't know how to handle the newest stuff, they can at least be aware that the new template isn't something that they recognize.

In order to make it easy for applications to determine whether they should try to access a document, each document must also contain a Technical Framework revision number which identifies the base set of templates that must be understandable by a consumer to correctly interpret the content.  If you get a document that uses a version of the PCC technical framework that the software doesn't yet understand, it has two choices:
1.  It can just bail out, and indicate that the document version isn't supported.  This is the behavior of applications like Microsoft Word back in the 1.0 and 2.0 days.  If you tried to read a Word 2.0 file with Word 1.0, it would tell you that it didn't understand the file format.
2.  The application can make a best effort to read the document, failing only when it encounters a template that has a major revision that it doesn't understand.  This is how Adobe Acrobat Reader reports issues when it encounters a PDF document written in a version of PDF that is newer than it was designed to handle.  It only fails if it encounters something that it doesn't know how to deal with, and usually does a good enough job if the document didn't require the newer features.

How will we figure out what goes into the new templates?  That's where software comes into play. The Model Driven Health Tools project already has much of the final text of the PCC Technical Framework modeled, and also has the CDA Consolidation guide modeled.  The C-CDA guide has a cross-walk of old versus new templates in Appendix B.  I can use that crosswalk to compare the two template models, computing three sets of constraints for a template pair:

1. Constraints that are identical in both IHE and C-CDA.
2. Constraints in IHE that are not in C-CDA for a given pair.
3. Constraints that are in C-CDA that are not in IHE.

Constraints of the first type will remain untouched in the IHE Technical Framework.  This is the core of the new content for PCC.  

Constraints of the second type will be reviewed by PCC to determine whether we want to re-adopt them, or leave them out.  If we readopt them, these constraints will be added to an appendix of the the US National Extensions section in Volume 4 (not yet written).  Implementing those constraints on C-CDA will be what is needed to take a valid C-CDA and make it a valid implementation of the IHE PCC template.

Constraints of the third type will be reviewed by PCC to determine whether we want to adopt the C-CDA constraint as a new constraint on the PCC template.  If they are adopted, these constraints move back into the first set.  When they are not adopted, it won't harm use of C-CDA, they just won't be necessary in the IHE PCC Context.  We will be sure not to re-adopt any constraints from group 2 that would violate a constraint in group 3 (e.g., code on the Concern template), so as to avoid introducing any incompatibility between C-CDA and PCC templates.

Another change we will be adopting is transitioning from direct use of value set or coded terms in the PCC TF to using Concept Domains.  We have already identified a set of Concept Domains that is the union of all concept domains already existing in the HITSP C32, CCD, C-CDA, and PCC Technical Framework.  Constraints dealing with vocabulary will be assigned to concept domains where needed from both sets (there will still be a few cases where direct use of value sets or codes is appropriate).  That refactoring will shift constraints from category 2 or 3 back into category 1.  In other words, if IHE and our interpretation of the C-CDA value sets result in assigning the same concept domain to equivalent constraints in both, and that results in the constraints being identical, they can be moved into to the core set.

During this process, we will identify what C-CDA value set was reassigned to a concept domain, and note in the US National Extensions that this is the value set is bound the the concept domain.

Finally, we will internationalize some of the data type flavors, and note in the US National Extensions which data type flavor substitutions can be made.

The end result will have the side effect of creating an International flavor of the Consolidation Guide.  There's some thought that when we get finished, IHE would ballot that through HL7 through the collaborative process that HL7 and IHE announced a few months back.  I'm not even thinking about that right now.  You can see there's a lot of work to do before we get to that point.

   Keith