One of the HUGE challenges introduced in the Meaningful Use 2015 certification criteria is the replacement of CCDA 1.1 with CCDA 2.0.
Here's the issue in a nutshell:
CCDAs produced by MU2014 certified product won't be able to Interoperate with CCDA'a produced by MU2015 certified product. CCDA 2.0 tightens up the rules that have to be followed in CCDA 1.1, so it should just be a slam dunk. However, it also changes the template identifiers, so it's the C32 to CCDA transition all over again for implementers. In fact, they changed just about every template identifier.
It requires an extensive and deep gap analysis to do this kind up transition to a new version. Essentially, the new templates are backwards compatible with the old (with a few minor exceptions), BUT, the template identifiers have also changed, and without a good map, getting from one to the other is difficult. And 2015 CEHRT's should be able to work with 2014 CEHRT's as well, which means they have to support both.
So not only do we handle them a difficult transition, but we also make them accept what used to be valid as well, because it only makes sense, and we don't give them an easy way to transition upwards. Easy transitions upwards in versions is another important principle in advancing standards.
This is NOT yet an insurmountable problem, but it will be if HL7 acts hastily in closing out the CCDA 2.0 ballot, or if HL7 members don't act to address the issue. I was happy to let this go back in October when the vote was cast and the position I supported lost by two votes. But that was when CCDA 2.0 was for MU Stage 3, and not when it was for 2015, just a year after we went from C32 to CCDA, and not when the new rule is optional.
It's not OK that a 2015 CEHRT won't be able to transmit a CCDA to a 2014 CEHRT because they use different versions of CCDA. It's not OK because my doctor and my hospital use two different EHR's (which is fairly common when you consider that the Ambulatory and Hospital EHR markets are in different segments), and those EHRs are more likely to NOT be able to communicate if one or the other moves up to the new criteria.
We need to solve this problem. Fortunately, CCDA is still in the operating room (finishing up the ballot), and there is still some chance that templates will finish first and a new versioning mechanisms will be in place for templates, at which time I have a good chance of being able to reopen this question, because the situation will have changed. And there's time between now and the end of August when the 2015 FR is expected to be published for HL7 to solve the problem.
That isn't a complete solution for the 2015 certification rule though. Realistically, more is needed to ensure a backwards compatibility path. Transformation from a CCDA 2.0 to a CCDA 1.1 should be both feasible and automatic (not so in the other direction). That provides a pathway to support both formats and provides a transition mechanism. I have to do more thinking about this problem too.
Keith
P.S. I know this is my second post in as many hours, but I'm getting behind on posts, so just catch up!
This is already extremely difficult to do for Stage 2. The vendors aren't ready and the EMR teams don't seem to have their acts together with respect to the data and clinical processes. In an environment where people are now actively debating abandoning the program due to the costs/complexity vs the benefits, having to redo this again will not engender a lot of support. I appreciate the intent, but this is just reeks of "clean room" design that doesn't consider the significant implementation challenges. I'd suggest rather they get out of their offices and go visit hospitals and providers - now. Ask them point blank about this and focus on the transitions of care challenges that exist today. Listen to the responses.
ReplyDeleteThis will great for vendors, though. Our experience has been that vendors are extremely slow to provide certified solutions (or even understand the technical requirements), so when they do come through at the last minute you're pretty much held captive and have to pay whatever it is they're asking. More opportunity to charge clients through the nose based on fear and penalties.
We have been aware of this issue at MDHT and our goal is to not require any modifications to any existing application using the MDHT java api; We will extend the environment to support the ability to "save as 1.1" and a "save as 2.0"; We are able to do this because we have replaced the use of template ids in the code with java objects. We will be able to dynamically swap implementations by levering the EMF factory infrastructure. We hope to have this operational in the next few months.
ReplyDeleteThis was my concern when the whole notion of Direct (HIE the Verb) versus having a central ESB (HIE the noun) that acts as an abstraction point. See http://www.directhisp.com/2012/08/version-verb-is-more-efficient-with-hie.html
ReplyDeleteIn your post you stated "And there's time between now and the end of August when the 2015 FR is expected to be published for HL7 to solve the problem." Any verdict?
ReplyDeleteI can't stress enough how F* confusing this is getting.
ReplyDeleteI see a business opportunity here for whoever creates a state of the art web site that clears this mess.