IHE PCC Profiles and CCDA Compatibility

One of the outstanding items that Patient Care Coordination has to address is the impact of Consolidated CDA on its profiles.  IHE contributed the PCC content to this effort, and ANSI also contributed the C32/C83/C80 specification to the effort.  As a result, we have a new HL7 implementation guide (the CCDA) that should be a valid representation of profile content such as that found in XDS-MS, XPHR, and other profiles that aren't yet final text

There are some challenges that we need to address.  The IHE PCC Technical Framework is used around the globe as a library of templates.  These are used in national and regional projects such as the French DMP, in epSOS, by the Ministry of Health in China and elsewhere.  The challenge for IHE in adopting CCDA is to do so in a way that doesn't make the technical framework to US-centric.

Three of the biggest challenges include:

1. The General Header is focused on US requirements for names and addresses.
2. Vocabulary is focused on US national selections.
3. Backwards Compatibility

Header

We also had issues with the US General Header in the Health Story guides.  In PCC, we only adopted  those requirements from the guides that were non-US specific, noting that when the realm was US, that all other requirements applied.  I imagine we could do the same here.  There is some interest in HL7 for creating an generalized, UV Realm header, which ideally would subset the US Realm header described in CCDA.  I'm adverse to duplicating this effort in IHE.  It might be well worth it to make this a joint IHE/HL7 project.

Vocabulary

Vocabulary is a lot trickier.  There is some vocabulary which should be used internationally (language and gender codes in the header), but just about everything else is negotiable due to various regional and national policies.  I expect that straight use of Consolidated CDA wouldn't fly in France.  They have particular requirements for lab results and medications that Consolidated doesn't match up with.  Perhaps we could stick with SNOMED and LOINC as a baseline, allowing national extensions to override the defaults.

Backwards Compatiblity

Backwards compatibility will be a big issue.  Structurally, the existing templates in final text profiles (XDS-MS and XPHR) are nearly identical with the CCDA templates, but the template identifiers are different, and so are not backwards compatible.  I don't see how we escape from assigning IHE template identifiers for structures that already exist in CCDA, but which have relaxed constraints to support international use.

Ideally, there would be minimal changes of systems needed to support this content in whatever new profile comes out of this effort.  More would be needed for full CCDA compatibility.  We could leave it to the US national deployment committee to deliver US regional extensions that bring the content fully into CCDA Compliance.

Another issue with respect to backwards compatibility is how we structure template identifiers.  We began (in CRS Release 1) by using template identifiers that had a root and extension, where each distinct ID represented a different concept.  Subsequently, we realized that just using root was sufficient.  Now there are some who'd like to use extension to represent "template version".  At first, this sounds like a very bad idea, but on second thought, it isn't so bad after all.

If you want to require use of a specific version of a template, you can do so.  But if you just want to bind to the template representing a specific concept, you could do that as well by just placing constraints on root, rather than root and extension.  If we had done that in CCDA, using the same template identifiers, but new extension values, we could have made things a lot simpler.  It's probably too late to go back and fix CCDA, but at the very least, we can now fix this problem for future releases in IHE.

I'll write more about this approach to template versioning tomorrow.