On the future of CDA

Sep 28, 2013

I’ve had several questions about my comments on the future of CDA in the Structured Documents working group (SDWG) this week, so I thought I’d clarify here. The context of this work was a question from the CDA R3 team whether they should close down the existing CDA R3 work, and instead focus on FHIR as a vehicle for CDA R3.

I think there was some confusion about this - in no way should this idea be understood as “abandon CDA” or even “stop working on CDA R3”, which I heard it characterized as. It’s simply proposing that the underlying format for the next release of CDA will be based on the technical vehicle of FHIR rather than the technical vehicle of the RIM Based ITS(s). The same functional use cases get carried forward to the next version of CDA, and the same basic requirement applies: that there be a conversion process to go forward from CDA R2 to CDA R3, just as there was for CDA R1 to R2.

So this isn’t about stopping work on CDA R3 - it’s just about pursuing the same goals by a different technical route. But the technical route has quite an impact on how things unfold - it’s a big decision, not a small one.

Also, this decision doesn’t impact on existing CDA R2 based work that the SDWG is mainly engaged in now. That work proceeds on the same basis it does now, irrespective of the course that future releases of CDA take - at least until the future version of CDA is considered ready to come out of the skunk works, and become the basis for implementation guide development and actual implementation.

Choices for the future

We’ve been discussing the course to take for CDA R3 for at least 5 years. For all of that time, there’s been, roughly, 3 choices the SDWG could choose to take:

  1. We could choose to do nothing at all, and stick with CDA R2 for the foreseeable future
  2. We could choose to do a minimal upgrade that retains backwards compatibility, so that new documents are still safe to handle by existing infrastructure. I will call this “CDA R2.1”
  3. We could choose to break backwards compatibility. It’s not safe to handle new documents on existing infrastructure  - and it might not be easy to handle existing documents in new infrastructure written for the new version

If we choose option #3, we have a range of choices from a little change through to a big change. Each of these choices presents a different cost/benefit trade-off. For instance:

  1.  if we stick with the existing overall framework, but extend the header, and put in a new clinical statement in the CDA entries, then that’s not much change; implementers use the same approach on a new schema, and can still use the same tranforms. On other hand, the benefits are somewhat fractional - the principal advantage I think that this approach has is that we get a bunch of new entry relationship codes to design documents with. But we don’t get to harmonise models completely with the domain workgroups’ existing models, which was a stated goal of CDA R3
  2. if we stick with the existing framework, extend the header, and replace the clinical statement with the unconstrained RIM, then that’s additional change - the implementers get an even more abstract CDA to work with. This impacts on the approach for writing CDA a little, and the approach for reading data base out even more. It does mean that we can use the existing work group models, and have harmonised content between CDA and V3 messaging - one of the stated goals of CDA R3
  3. if we go further, and just use the RIM directly with some constraints… well, the means the existing transforms stop working, but we could use CDA for messages as well as data.. oh, hang on, that’s V3 messaging. We never considered this approach

There’s more choices that this - variations on these themes, but the 3 I’ve given illustrate the range for the purposes of this argument.

One of the central questions I’ve had is, who makes this decision? Or, perhaps, when we make this decision, what is the priority? Something that makes implementer’s lives easier? Or something that makes standards developers lives easier? I’ve always thought that we counted the second too high in the decision - that the implementers of CDA documents couldn’t care less about alignment between CDA documents and V3 messaging designs (except in a few specific domains), but would care greatly for backwards compatibility.

Nevertheless, we chose that CDA R3 would take the option #3b above, principally to allow alignment with domain models. What I argued this week is that the value proposition of this is falling:

  • A lot of design activity has moved to CDA R2 anyway (principally CCDA and EPSOS)
  • V3 messaging is obviously never going to gain much more market share (in fact, it’s starting to have the hallmarks of a toxic brand, whatever it’s technical merits)
  • The domain work group work was always going to have to be revisited anyway (due to issues related to trading between message context and explicit representation of status)

Making a choice

What I want to know is that the implementers want? Based on my experience with implementers here in Australia, there’s 2 things they want:

  • To be able to leverage the investment they’ve already made
  • To get something easier to work with

Note that these are basically incompatible - if it’s easier enough to make a difference, then you can’t leverage your investment quite as well. But this trade-off is quite different to the way the CDA R3 decision was taken in the past. And what I’ve learnt about this is that if the market doesn’t agree with the choice a standards organization makes, it will vote with it’s feet and go somewhere else. So I always thought that the existing CDA R3 decision was dead wrong, and it was part of the reason I resigned as co-chair of SDWG.

I always thought there was 2 real choices:

  • Do what you can while strictly conserving backwards compatibility.
  • Completely transform the approach, so that when you make people revisit their infrastructure, they get something really big in exchange for that. But this takes longer and delivers more slowly

That’s the point at which I went off and did FHIR - you can see how this connects with the ideas here; FHIR offers a completly different way to do documents. As well as being easier, it means that the section contents are the same structures you exchange in any other way in any other contexts. There’s a bang for your buck for implementers. Note, though, that this value proposition assumes that FHIR is widely adopted for other kinds of data exchange, so that means the payoff is further off in the future. So I’ve always intended FHIR to be positioned as the long term replacement for CDA R2 (but as CDA R3, noting my comments above about what CDA R3 is). So I endorse the idea that the SDWG consider using FHIR as CDA R3 (big surprise), but there’s a lot of work to be done before that’s a real proposal.

If it’s long term, then, what are you going to do in the meantime? well, obviously, I think that we should do what we can while being backwards compatible, and preserving existing investment - both ours (HL7s) and the implementers. And isn’t that what CCDA R2 actually is? That’s certainly what I see when I look at it - it’s a best practices for using CDA, with extensions where required. So that’s the rational thing to do in the near term - and we’re already doing it.

In fact, we could call this new consolidated CDA R2C to indicate that it’s the next version of CDA.