On the future of CDA

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.

 

10 Comments

  1. qole says:

    I have implemented CDA R2 from “the ground up” and I can honestly say that it is a real mess. The real problem is that it feels like it was designed by people who haven’t done much information designing in their careers; people who are experts in health care domains, but not in information design. Software people coming to the CDA for the first time are utterly baffled by its ornate, labyrinthine structures and quirky vocabulary.
    I have also looked at all of the proposed replacements and none of them fix the inherent problems with the whole system. Any replacement needs to be completely modular, consistent, and without the arbitrary, almost random restrictions of the current model (why CAN’T you have a status element in the header for the whole report?). Modules need to be decoupled; none of these massive trees of schemas for each message. Vocab and schema structures need to be simplified and streamlined. All possible vocabulary should be included with the XML schemas for each module (or at least links to all the lookups), and the modules should be packaged separately (although a basic set can be package together as a “quick start”). I know, you’ll probably say FHIR is all this, but have you had non healthcare information designers look at it? You know, database designers. Business intelligence experts. Those folks. What did they say?

    • Grahame Grieve says:

      In the existing CDA, design principles favoured theory over practice. Part of my day job is supporting CDA implementation so I know that you are right about the outcome.

      FHIR is indeed all the things you said, and we do reach out to those kind of implementers as well as others. The more comment we can get, this better.

      • Jeremy says:

        I have to also support CDA implementations for several different flavors. There is too much redundancy and bloat. For example, there are encounter tags, with a classCode of ENC, act tags with a classCode of ACT, i mean, why not USE the tag to determine it? Requiring tags with a hard specific value? They just can’t say, hey, for this tag this is always the case, so no need to waste space putting in this tag? So for the 5 data points that I have for a record (which total to about 50-70 bytes, I have to fluff generate 2000 characters around it, in order for it to even pass a validator. With any ACTUAL patient with decent history, you are looking at a 20-40 Meg document that most email providers cannot handle. Another thing I hate is that you have to add a crap item in that represents that you have no items for that section. Sections are required even if you have no data for them. Not to mention, the craziness that is the HL7 OID.

        Although I’m sorry to say this, I think we need to drop CDA, and in effect XML as well. The whole system is extremely outdated and reminds me of the 1990-2000s when people actually used XMLHTTPRequest to actually GET XML. With libraries such has libxml being huge with a 4meg footprint and loading a 100k CDA adding another 20megs to memory, it seems there are better technologies out there that can satisfy. I think with SQL engines such as PostgreSQL adding support for and MongoDB using as its core db, that JSON documents are the way to go.

        • Peter Jordan says:

          It would have to be one hell of a patient record to produce a CDA (minus attachments) anywhere near 20Mbytes! In NZ, I’ve yet to see anything of this magnitude in NZ GP2GP CDAs, which contain the complete primary care record of a patient…and XML lends itself to high compression rates. Attaching documents to a CDA, particularly images, is of course another matter and can quickly create total file sizes that many message service providers cannot handle.

          • Qole says:

            I agree that you should be compressing your XML, and you shouldn’t be e-mailing patient data anyway; at least, not in plaintext.
            Our system uses secure web services.
            I also agree that XML, as ASCII text, won’t get huge, it would have to be binary attachments.

          • Jeremy says:

            Unfortunately, we have to conform to the direct project so “secure emails” cannot contain compressed CDA files, due to the fact that end points have to be able to “view” them. So every email has to contain the uncompressed (base64 encoded so its actually bigger) and the stylesheet.

  2. Mike Henderson says:

    What I’d give to have been in the room during that discussion… Anyway, Grahame, this looks like a well-thought vision for the future, one which — given the success you cite for C-CDA as well as the rapid early uptake of FHIR — is not only insightful but, I think, reasonably achievable along both of the paths you describe.

  3. I find this argument spot on. The short term key for CDAr2 are well defined templates that are interchangeable between different tools and recognized registries. The longer term is very likely FHIR, or at least all lights are currently green.
    Not all communities have been exposed to it merits, and each community has to be won over. In The Netherlands we have a deep investment in V2 and V3 and initially I anticipate a harder sell. The first signs from at least one decision maker however is positive. Times are getting interesting

  4. John Santmann says:

    Great Post!!!
    I am an “Implementer” and could not agree more with everything in Grahame’s post.
    HL7 v3 (and by extension CCD/CDA) is overly complex, unintuitive and seems bent on maintaining an abstract data structure at the expense solving real world problems easily and quickly.

    The incredible paucity of example CDA example documents from HL7 seems to indicate that even the standards developers have a hard time generating CDA documents.

    Although I would hate to have to redo all the CCD/CDA development work we have already done, it seems like the best way to proceed if we can get something that is a better solution for the long term. I have very limited exposure to FHIR, but maybe this is what we have been waiting for.
    Thanks.

    • Grahame Grieve says:

      John – the new CCDA (r2) has a real focus on examples – that will be a significant improvement, though it won’t solve the underlying issues

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen

*

%d bloggers like this: