Harmonizing IHE PCC with HL7 Consolidated CDA

How do you harmonize a US Realm CDA Specification with a set of International profiles when:

1. Requirements of the US Realm specification clearly won't work in other countries (Canadian providers neither have, nor care about the US National Provider Identifier for example).
2. Every unique identifier already coded into the profile needs to be changed,
3. Versioning of templates wasn't designed in as best as it could be.
4. Vocabularies used in one country (e.g., LOINC) need to be changed to those used in another.

These are just a few of the issues that IHE PCC has been struggling with since the release of the Consolidated CDA, and yet, these are also issues that we are committed to resolving.  Either PCC contributes nothing to users of IHE profiles in the US, or PCC must adapt itself to the latest version of the HL7 CDA templates, without alienating existing implementers of the PCC technical framework in South America, France, Italy, China, Korea, Australia and elsewhere.

It's a tricky challenge, and we will very likely take it on in several steps this year.  That decision gets made tomorrow morning.

The first step is to allow for forward motion in templates defined in the PCC technical framework.  For example, the template for the IHE PHR Extract Document (1.3.6.1.4.1.19376.1.5.3.1.1.4) requires the presence of the following templates (among others):

• Allergies Section (1.3.6.1.4.1.19376.1.5.3.1.3.13), 
• Conditions Section (1.3.6.1.4.1.19376.1.5.3.1.3.8), 
• Medications Section (1.3.6.1.4.1.19376.1.5.3.1.3.19)

 The current interpretation of this requirement is that if you have:

<ClinicalDocument xmlns="urn:hl7-org:v3">

  <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.4'/>

  ...

Then later in the document you must have:

  <section>

    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.13'/>

    ...

  </section>

And:

  <section>

    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.8'/>

    ...

  </section>

And also:

  <section>

    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.19'/>

    ...

  </section>

By making a small change to the technical framework in a CP, allowing a version identifier to be stored in extension, we would now allow:

  <section>

    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.8' extension='2' />

    ...

  </section>

Note, however, that this is NOT truly a backwards compatible change.  What could break?

A system assuming that documents asserting conformance to a template by inspecting only the value of the root attribute wouldn't detect the introduction of the extension attribute.  They would move forward expecting conformance to a prior version of the template, and in certain situations, that assumption could fail (e.g., if we were to adopt the new mechanism to represent Concerns using a code attribute instead of a nullFlavor value).  If those systems didn't validate conformance to the templates, they could be expecting information to appear where it no longer does (again, the new Concern model).  That could cause a software failure.  Alternatively, if they do validate inputs,   but don't recognize the new templates, they wouldn't be able to process the communication.  However, the validation error would be detected and could be corrected by updating the software to address new content requirements.

In my reviews of changes from CCD version 1.0 (and HITSP C32) to CCD version 1.1, there are very few cases where the locations of clinical information content has been altered with respect to the CDA Content model.  So, it seems that this could work in the real world.

After this CP, we would then need to create a set of templates that represent NEW versions of the existing PCC templates.  These templates would include new requirements for related templates as they were introduced by Consolidated CDA, and would retain existing PCC content restrictions unless they conflicted with (as in, couldn't work with), the Consolidated CDA templates.

This set of changes would allow IHE PCC to publish a technical framework which would allow a CDA document to be produced that:

1. Conformed to PCC requirements
2. Conformed to Consolidated CDA requirements. 

This is NOT possible today.

There are a few other changes we'd like to make.  Right now, IHE PCC specifies a number of value sets used with templates.  The most common example are the codes used to record vital signs.  Instead of directly specifying the value sets, what we would do in the PCC TF would be to reference Concept domains.  Thus, the "Vital Sign Value Set" referenced in the original PCC TF would become the Vital Sign Concept Domain.  References to the Vital Sign Concept Domain would be resolved through realm bindings.  A Vital Sign Value Set using LOINC (the same value set currently specified by PCC today) could be bound to the Vital Sign Concept Domain for US Realm use.

To validate a CDA document conforming to a PCC template, we'd have to look at both the template definitions, and to the realm bindings.  This is doing nothing more than utilizing the realm binding mechanism that HL7 Vocabulary has already adopted for Version 3 standards (CDA is a version 3 standard).

In PCC, we'd also need to refactor some of the Consolidated CDA requirements into Universal (and thus template) constraints, vs. Realm specific (and thus Concept Domain) constraints.  Some countries simply won't adopt the same sets of vocabulary as we have in the US.  

We will also have to address this issue for certain classes of identifiers.  For example, rather than using the US National Provider OID in the template, we'd indicate that the assigning authority must represent a legal value in the realm binding's national provider ID namespace, and define "Identifier Domains"  similar to the way that Concept Domains are defined. 

Some constrained types found in CCDA may also have to be addressed through the Realm mechanism, including for example, postal address requirements.

Fortunately for IHE PCC, much of our existing body of final text templates has already been transcribed into MDHT, as has the Consolidated CDA content.  We should be able to compare related templates between the two, and perform appropriate refactoring.

Having completed this effort, what would you have to do to adapt an implemetation of a profile from the IHE PCC technical framework for use in an environment like the US where Consolidated CDA is the representation?

Here's how I think an implementation of a PCC profile would need to change to support both the PCC TF and C-CDA if we had this today:

1. Remove all code that generates HITSP template identifiers.
2. Remove all code that generates CCD 1.0 template identifiers.
3. For each IHE PCC template identifier generated, add the new version identifier to the extension attribute.
4. For each Consolidated CDA template in the PCC->C-CDA crosswalk found in the Consolidated CDA guide, add code to generate the new template identifier to the output.
5. Tweek generation of the "Concern" act to use the fixed code value specified in C-CDA (and version 2 of the IHE templates).
6. Fix representations of not known and known not in various places in your code.
7. Tweek a few other things (a list that has yet to be established, but which I hope to extract from MDHT algorithmically once I get rolling).

Unfortunately, we don't have this today, and MU implementations of C-CDA will be implemented well before we do.  So let's look at this another way, how could you implement the PCC TF functionality on top of your existing C-CDA implementation:

1. Add the new PCC template identifiers associated with C-CDA templates to your output.
2. Adapt your code to follow additional PCC TF constraints (e.g., required linkages from entry to narrative text).  This also is a list that I expect we would be able to extract from data recorded in MDHT.

This is NOT going to be the most fun project I've ever worked on, but it is necessary.  In the end, I expect we'll have a body of computable data, stored in MDHT, that will also assist IHE PCC implementers in creating new PCC template instances and validating content of instances against the text.

While all of this goes on, there will be new work going on in IHE and HL7 generating CDA templates.  As we establish new best practices going forward (e.g., concept domain use before localized value set definition), I'll be updating them here, and promoting them to other groups working on CDA.