This one is the most challenging, because the new problem concern isn’t backwards compatible with the HITSP C32 version. It means that you cannot create something that is both a CCD 1.0 and a CCD 1.1 at the same time.
The Problem Section
Adjusting the section is just a matter of swapping out template identifiers. It is actually the entries within the section that need further alteration.
In the problem section, remove the templateId elements that have been
struck out, and add the ones in bold and underline.
The Allergy Section
Just as in the problems section, the allergies section will also require swapping out identifiers, and the real focus is on the entries.
The Problem Concern
In the CCD 1.0 and HITSP C32 (and the IHE templates in between), the “Problem Concern” did double duty, representing the “Concern” act for both problems and allergies. In the CDA Consolidation Guide, this act was split into two different templates, one to address problems, and the other to address allergies. Structurally, they are very similar. We’ll take on the changes for problem first:
As you can see, the “breaking change” was for the <code> element, and a different template for the problem observation.
The Allergy Concern
Moving on now to allergies, again, what changed was <code> and the use of a different template for the allergy observation.
Now we move into the problem and allergy observation templates. Again, I’ll start with the problem observation. Note that here you need only add the CCD 1.1 template identifier, and don’t have to remove the prior template identifiers because the two templates are compatible (but see my notes below on backwards compatibility).
The same is true for the problem status observation contained inside the problem observation. Note that HITSP C32 suggested pointing to the problem text in the value element, while CCD 1.1 does not. It’s still allowed, and gives you a way to textually describe problems which are not coded.
The allergy observation and its subordinate observations are going to require a few more adjustments because of the contained <participant> describing the allergen, and the shifting of the type of allergy from <code> to <value>, among other things.
While I showed the severity template above in the context of a reaction, the CCDA allows that it can also be used for allergies themselves. And I note that it doesn’t forbid it from being used in problems, it just didn’t suggest it. I’m suggesting it. Severity is simply a special kind of annotation on an problem, allergy, or reaction. Don’t expect it to be present, or supported by all systems, but if you have it, be kind and share it with others.
On Backwards Compatibility
The new templates for problems and allergies are functionally compatible with the HITSP C32 specifications. In other words, you can say the same things. In a few cases, they are even wire compatible. That is to say that you can create XML that would be valid in both the HITSP C32, and the CCD 1.1. The question to ask yourself though, is whether you want to take that on. My advice would be to NOT try to retain compatibility in the same package even if it is technically feasible.
CCDA takes a different enough approach that you’ll run into challenges. While this series focuses on production, consumption is a completely different story. You aren’t in control of what you are going to receive, so you have to be able to accept anything that’s valid.
That means you cannot take a path of least change to adapt your consumer the way that you can for your producer. So, create a new package for your CCDA Consumer. You can start with the same code base you used for the HITSP C32, but you’ll be making enough changes that the end result will be quite a bit different.
And remember, there will be some time when you still have to deal with both, or at least your customers will. Not everyone will be able to transition on the same day. You need to allow for asynchronous bilateral cutover. It is after all, one of the new ABC’s of interoperability.
If it says SHOULD, DO IT. You will thank me later, or at least, your customer or downstream trading partner will. SHOULD doesn’t mean “avoid this if you can”, it means that this practice is recommended for maximum interoperability.
If you used additional HITSP C32 templates in these observations, LOOK at them! I cannot cover everything here, and this post is already TL;DR length. Furthermore, I offer this information for your education. Please take responsibility for ensuring the accuracy for your own implementations.