Concern on Allergies in CCDA

Mar 26, 2014

In my last post, I referred to an ongoing discussion on an HL7 forum:

On an HL7 mailing list, there’s a rather active discussion that is happening about a particular feature in CCDA (allergy lists). It turns out that one of the bits of the CCDA specification is somewhat obtuse (surprise!), and there’s more than one opinion on what it means and how it’s supposed to be used. I’ll probably end up posting on the specific subject when (if) there’s closure to the subject.

Well, the discussion seems to be coming to some closure (after some 100 emails). But rather than me say anything, I think Brian Weiss has a great summary:

Given that the “concern act” templates in C-CDA R1.1 can’t be used for “health concern tracking” in the broad sense, but at the same time given that they are required to be used with every problem or allergy observation in C-CDA, it is a bit challenging to understand how exactly they should be used and interpreted. That is the focus of this article.

I recommend anyone interested in CCDA reads the rest of Brian’s article.

More generally, I wonder how to connect Brian’s great advice - he’s got lots of it - with the implementers. Here’s what CCDA has to say on the subject:

This clinical statement act represents a concern relating to a patient’s allergies or adverse events. A concern is a term used when referring to patient’s problems that are related to one another. Observations of problems or other clinical statements captured at a point in time are wrapped in a Allergy Problem Act, or ““Concern”” act, which represents the ongoing process tracked over time. This outer Allergy Problem Act (representing the ““Concern””) can contain nested problem observations or other nested clinical statements relevant to the allergy concern

But what does that mean? how would you interpret this when producing or consuming CCDA documents? Why would an allergy have multiple observations - are they complementary or does the most recent replace the earlier ones? Implementers will made different decisions. There’s lots of cases like this in CCDA, but my experience is that implementers won’t stop to think that there might be advice to help them out. I posted quite a bit of stuff about the Australian PCEHR like this, and I know that most implementers never saw it until too late.

I guess all we can do is encourage implementers to look for advice, and in the case of CCDA, to read Brian’s work. Which is really the point of this blog post.