Supercompliance with HL7 CCDA Versions

I've written several times about C-CDA Release 2.0 and issues with template versioning which are pretty close to resolution, and I've also written previously about the 2015 Certification criteria and backwards compatibility with 2014 criteria.

What I'd like to expand upon now is an issue that could occur if C-CDA Release 2.0 was adopted as optional criteria for 2015 and how we could arrange things so that a 2014 system could receive it.  It draws in part on what I described previously as a Dual Compatible CCD, but is slightly different because CCDA 2.0 is largely backwards compatible with CCDA 1.1.

The issue is that when System N (for new) sends a CCDA 2.0 document to System O (for old) that understands CCDA 1.1 there are three things that could happen:

1. System O would correctly identify the fact that the CCDA 2.0 document did NOT comply with CCDA 1.1 and would reject it.
2. System O would NOT correctly identify this fact because the template identifiers are similar enough, and some don't understand the details of how to match identifier values in HL7 Version 3 and CDA, and so it would incorrectly try to process it.  System O would handle these as follows: 
1. Where these templates are backwards compatible:, System O would handle the 2.0 templates correctly where they are backwards compatible with 1.1, BUT, 
2. Where they are not, System O would have issues with interpretation of the content.

There are FEW cases where 2.b. would occur based on a preliminary analysis of CCDA 2.0, BUT, we need to spend more time looking into those details.  One case that has been identified is the templates for Smoking Status, where there are differences in interpretation of the effectiveTime element on the observation.

What I would propose that systems using CCDA 2.0 do is be "Super Compliant" (this is really independent of what my thoughts are on the 2015 certification rule).  Super Compliant means that they send documents which conform to both CCDA 2.0 rules, and CCDA 1.1 rules, and only send the same information twice when ABSOLUTELY NECESSARY (as in the case for Smoking Status), and only in very controlled ways.

It would mean that a sector or entry could declare conformance to both CCDA 1.1 and 2.0 except where that wasn't feasible (e.g., Smoking Status).  That last little note also means that we need to examine more carefully where backwards compatibility isn't the case. 

The benefit of this is that systems which understand CCDA 1.1 will, if properly interpreting the guide and underlying CDA Release 2.0 standards, work correctly.  Even if they don't fully interpret the CDA Release 2.0 standard properly (e.g., get confused about the Instance Identifier data type and similar but not identical identifiers), could and likely would still get the correct result.

This allows systems supporting CCDA 2.0 to work with systems only understanding 1.1.  It does mean that newer systems supporting CCDA 2.0 would still have to support CCDA 1.1 as input, because not every system available would be able to send CCDA 2.0, but that is already pretty likely to be the case for MOST Certified EHR products in use today.

I'll talk a little bit more tomorrow about flavors of compatibility and breaking changes (also called substantive changes) and how we could develop some policies for advancing standards that allows new features to be created, and problems to be fixed but still ensure that systems

MeaningfulUse 2015 Posts

It's only been five days and already I need a table of contents for my posts on Meaningful Use 2015.  If I need it, you might too:

1. Predictions on the 2015 Certification Rule
   My predictions on what would be in the rule.  How did I do?
2. Meaningful Use 2015 Certification Rule
   My initial observations about the 2015 Certification NPRM
3. Postel's Principal, CDA and Meaningful Use
   In which I discuss the challenges to applying Postel's Principal to incorporation and reconciliation of CDA content into an EHR. 
4. CCDA Versions and Meaningful Use 2015 Certification
   In which I ruminate on how to ensure compatibility between CEHRT certified under different regulations.  No solutions yet, just chewing the cud.
5. ONC Meaningful Use Presentation
   Steve Posnack shared this presentation with attendees at an ONC Educational Event at HIMSS14 and he shared it with me so I could share it with you.
6. Meaningful Use 2014 - 2015 Crosswalk
   This great crosswalk is supplied by Hans Buitendijk of Siemens to help you figure out what the differences are between the two rules.
7. An HL7 Specification for Addressing Meaningful Use Driven Standards Ballots
   Some thoughts for how HL7 could address the ballot demand due to Meaningful Use Initiatives.

I'll try to keep this list up to date, but you can also find these and any additional posts using the mu2015 category on this blog.

MeaningfulUse 2014 - 2015 Crosswalk

In the spirit of industry cooperation which often accompanies new regulation, Hans Buitendijk, a standards colleague in HL7 by day (and my favored candidate for HL7 Chair), and a competitor at Seimens the rest of the time, has shared the following comparison of the 2014 Certification Criteria against the 2015 Criteria.

He notes:

• It only compares 2014 FR with 2015 proposed amended language for part 170 starting page 205.
• Various standards are referenced in the pre-amble (e.g., HQMF, UCUM, etc.) that are not in the proposed amended language.I did not attempt to include those as I have not delved into the pre-amble yet.
• The text in red indicates variances that matter.
• For example, splitting CPOE into three criteria or combining two ToC criteria into one and adding 4 transmit criteria does not turn everything red as there are chunks that really did not change. I think in the process I caught all, but I may still have missed something.

Please join me in thanking Hans and his employer for sharing this greatly valuable resource!

---

Updated with the latest version. See the link above to download this file.

---

MeaningfulUse presentation by ONC at HIMSS14

On Tuesday, Steve Posnack, Jodi Daniels, and Jacob Reider presented an overview of the Meaningful Use 2015 criteria. Steve was kind enough to share his slides with me so I could share them with you.

Keith

---

Updated with his most recent deck, which has a small change to slide 7. See the link above to download the presentation.

---

CCDA Versions and MeaningfulUse 2015 Certification

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!

Postel's Principle, CDA and MeaningfulUse

If you've been reading the Meaningful Use 2015 NPRM as I recently did, you probably came across the discussion around requiring certified products to accept 95% of CDA documents.  I can see Doug Fridsma's hand in this. One of his favorite laws of standards is Postel's Principle.  In fact, he quite gleefully looked over my shoulder as I tweeted a comment from heckler's row to the effect that ONC is applying Postel's law to CCDA during Steve Posnack's review of the 2015 certification criteria.

This will be a challenging certification requirement to implement in many ways.  The way it is currently worded below, it appears as if you can only test it after the fact.

§ 170.212 Performance standards for health information technology.The Secretary adopts the following performance standards for health information technology:
(a) EHR technology must successfully electronically process documents validly formatted in accordance with the standard specified in § 170.205(a)(4) no less than 95% of the time.

How would you measure or certify for this?

There are a couple of challenges.  The first thing is in the definition of "success".  What does it mean to successfully process a CDA document?  There are several key processes specified in Meaningful Use.  One of them is to reconcile and incorporate the content of the document for problems, medications and medication allergies.  But there is also a need to incorporate other material, such as laboratory results, or narrative sections into the EHR.  A more careful definition of success is certainly needed here.

Another key issue is the measure of validity.  How would validity be determined.  I've often mentioned that for Meaningful Use, the current TTT validator requires conformance to all required capabilities of Meaningful Use.  That is to say it verifies the maximum possible CDA that a product must be capable of sending.  There are other provisions of Meaningful Use which require the product to offer the physician the ability to customize what is sent so as to include only relevant data in a summary.  Those provisions enable a physician to create a valid CCDA that will not pass validator testing because it doesn't demonstrate all required fields (e.g., there may not be any procedures recorded if none were done).  We must further distinguish cases where a medication is reported but no code is known, or a disease is reported but no code is present in the specified coding system.  For example, suppose that Influenza Type a subtype H7N2 (a bird flu) becomes capable of infecting humans.  Find a SNOMED CT code for it.  You won't be able to.  You'd have to live with a supertype (Influenza Type a subtype H7). What about the case where a medication can be identified, but the dose and frequency aren't available.  So all of these variants are possible, and we'd have to define what it meant to be able to successfully import these.

There are two ways to approach this offhand:  Statistically, or through detailed analysis.  The former method simply says "get a large number of varying but valid samples", and require the EHR to successfully demonstrate incorporation of each.  It's easy, and it gets you to some degree of reliability quickly and easily, but it will certainly miss some non-obvious cases that someone somewhere will eventually program into a system.  The second method is by doing a detailed analysis.  This is more difficult, because it requires someone experienced enough with the standard to determine the legal range of possible variation, but not so well entrenched in it to miss the obvious sources of variation that a practitioner well trained in best practices will simply ignore because they've had that variation trained out of them.

Based on Meaningful Use statistics, you can probably identify a small number of products producing CCDA's that represent 95% of the physicians already using a CEHRT.  You could build a test set from those vendors.  Who's going to build that set, and what is in it for the vendor to contribute to that effort?  Many vendors are hesitant in giving out examples of what their product can do without certain assurances that the material will not be used in ways that allow other vendors to compete.  This is the reality of being in business.

One of the biggest values of IHE is that it provides an environment where vendors can do that sort of testing and gather that sort of test data on profiles they care about, in a way that ensures those samples are protected by non-disclosure agreements.  What happens between vendors at Connectathon stays there, it's part of the agreement we all sign when we show up, and that includes how we deal with the testing data.

But Certification testing isn't done in that sort of environment.  So either the data has to be gathered ahead of time, or be developed in a painstaking manner.

I'm not against the idea, but the mechanism by which it is implemented needs quite a bit more description before I'd be willing to say that this regulation is ready for prime time.

Some of the SHARP work, specifically the SMART-CDA Scorecard could be of assistance here.  I'm still ruminating on this one.

MeaningfulUse 2015 Certification Rule

A quick summary of what is new and different in the recently published Voluntary 2015 Edition Electronic Health Record Certification Criteria: Interoperability Updates and Regulatory Improvements.  You can also find the Word version here, and I recommend it to you for making comments.  Kudos to ONC for making that version available, as it helps both them and us review the material and effectively make comments.

This is but a summary of what I ready between 5:30pm Friday afternoon, and finished reviewing sometime Sunday morning.  It's amazing that I've already had three deep discussions about this content with three other people who've also read it through, and it has yet to be officially published in the Federal Register (but will be there by the time most of you are reading this post).  Note that I started reading this document in Virginia returning from "vacation", and finished my first pass Sunday morning around 9:30am before taking off for HIMSS 2015.  I spent around 90 minutes on this Friday, 15 on Saturday, and about two hours Sunday morning.  While I read, I tweeted the highlights using the hashtag #mu2015 as a way to keep notes.

Some tips when reading NPRM's.  I read them through several times.  The first time, to get the gist of it, I start after the boilerplate and history and regulatory authority, and stop as soon as it gets to the financial impact statement.  So, I don't actually read the proposed regulation, just all of the commentary around what they proposed and considered.  That's the essential stuff you need to know for commenting, while all else is useful, the meat is in that chunk.  It cuts about 25 pages from the front half, and another 75 from the back, so I only had to read 150 pages, not all 252.  Normally, I'd go through 150 pages in about 2.5 hours, but remember that I'm also taking notes while doing this, so not bad for four hours.  I know people who've already put 8 hours into this thing.  So what you are getting is just the gist from that first read through.  Note that in the following, all page numbers are in the pre-publication public inspection version of the rule (and the ONC Word Version), not the prettily formatted Federal Register version that will be published Monday.

• Many criteria have been split to better support modular certification, which is the only form expected to be supported henceforth.  It makes sense because not everyone needs a "Complete EHR" or has one from a single source.
• The first of these to be split out is CPOE, separately for labs, imaging and medications. (p26-29)
• The standard to use for transmitting orders to labs will be the S&I Framework LRO Guide balloted through HL7.
• Additional criteria has been added for labs, and the NPRM strongly hints at future ramifications regarding CLIA requirements for labs interfacing with 2015 Certified EHR technology.  This was my second predicted standard back in December.  I also made some points about possible CLIA ramifications almost a year ago that got some attention, and may be in the works if I read between the lines correctly.
• I complained quite loudly about how ONC messed up the selection of the standard for language codes by selecting a different standard than was already in CDA.  It appears they are considering how to fix this problem now.  I'm all for using RFC 5646 which is what the Internet understands (and so does CDA).
• P38 of the rule offers explanation of how AHA recommends BP be taken. Have you ever had you BP done this way?  Me neither.  Lets use LOINC for the vocabulary as suggested in the NPRM.
• Note, many criteria are unchanged, for example, the need to record current problems, medication allergies and medications.  I skip a lot of this, as well as minor version updates of standards.  The point is that a summary should only address those things that are pertinent and relevant.
• P39-44 explains rationale for use of #HL7 Health eDecisions and DSS guides.  There's a lot of explaining here, and probably for good reason.  That standard needs quite a bit of work still to harmonize with everything else already in the MeaningfulUse architecture.  Prediction #3 came mostly true.  I'll count this one in full because the key was HeD, and not VMR.  DSS implies VMR in any case.
• P44 searching across electronic notes added.  This is a pretty significant change.  Dare I say, they want to be able to Google within a patient record?
• P48 smoking status unchanged.  This is one of the unchanged things that really matters to people.
• P49 access image results unchanged.  And another one.
• P49-50 covers changes to family history, and this is going to be a whole blog post.  Family health history to be recorded using HL7 Pedigree standard, as SNOMED CT dropped.  The key challenge here is that the Pedigree standard is a model, not an XML expression.  How do you test conformance to a model?
• From P25 to page 51 there are at least four references to FAQs which have adopted into regulation thus far.  I see a pattern developing.  Check the FAQs
• In the HL7 InfoButton standard, there's no real way to do a patient education or CDS based information request based on a lab result value, only the lab result code.  Thus, I can request information on A1C, but not on a value of 7% in an A1C result.
• If the patient has a device that has a GUDID, then it appears in their record.  I missed that in my predictions, and it should have been obvious in retrospect given the big splash back in the September HL7 meeting that the FDA and others were trying to make.  I don't know that missed predictions count against me though ;-)
• P62 begins the discussion of splitting the create and transmit to be separate criteria.  I know a few interface engine vendors who cobbled together a CCDA just to get certified to support create and transmit because you couldn't separate them in order to meet their customer's needs to be able to use that engine to support transmit.  You needn't show create to certify for transmit & versa visa! +1 for @johnmoehrke
• P65 "would no longer require testing and certification to the primary Direct Project specification" supports more flexible approach, which simply involves demonstrating that you can get your message to a Direct address.
• In my tweet I said OMG, but I really wanted to say something much stronger when I realized they actually named CCDA Release 2.0.  As that standard presently stands during reconciliation in HL7, the template identifiers are completely different and it will be largely incompatible with MU 2014 certified systems.  So only 2015 certified systems will understand it, and that will cause a HEAP of hurt because 2015 is an optional criteria, which now means we are back to two standards, CCDA 1.1 and CCDA 2.0, and the two at present don't have a backwards compatible path for 2014 Certified EHR products.  Another prediction right (although I later withdrew it thinking, or perhaps hoping they wouldn't make that mistake.  Then again, it's still correctable because 2.0 is still in surgery right now (ballot reconciliation).
• ONC added a performance measure that "EHR technology would need to be able to receive no less than 95% of all" valid CCDA documents.  This is pretty significant, especially since ONC never really defines what "receive" means.  To me, that means successfully import. This is where I hoped they would name the TOC Guide instead of CCDA 2.0, and they didn't.  So, I think between CCDA and TOC, I get a half a point.
• P74-75 discusses name matching criteria that includes first, middle, last, dob, place of birth, maiden name, sex, and current & historical address.  For name matching purposes, some of these are good confirmatory elements, and others are good elements to confirm or reject a match, but the criteria doesn't say how to use which ones.
• Note that the above criteria, and the addition of GUDID means that the Common MU Data Set will likely be changing to support those additional data elements.
• P78 In one place, two requirements were merged: The requirements for reconciliation and incorporation requirements were combined.  I keep telling people that the IHE Reconciliation profile is a good profile to adopt for these requirements.  IHE is going to be updating it this year to simplify the requirements and make it easier for systems to declare conformance.  Maybe ONC could adopt it?  They did ask.
• P83-86 discusses #HL7's #HQMF release 2 standard, proposed for EHRs to interpret Clinical Quality Measures.  Another prediction right.
• P88 CEHRT must be able to filter populations by several criteria before producing measures.  This one seems kind of silly, since a measure already has a population criteria which filters the population to which the measure applies.  It may well be that some don't understand how measures or HQMF really work.
• P90 They asked for feedback on support for two factor authentication for ePrescribing of controlled substances and remote EHR access.
• P97 Contains a spoiler alert "given our proposal to discontiinue the Complete EHR concept ..."
• P101 WCAG level AA proposed instead of level A for View capability
• P103 Imaging is back into play for patients. This was proposed for 2014 but later dropped.  Shouldn't patients be able to get diagnostic quality images?
• P109-113 Both CDA and QRDA standards were proposed for syndromic surveillance in ambulatory space.  Both might work.  The former would be used as specified and the surveillance would occur by simple inspection of that appeared without a lot of net new exchange requirements.  However, we'd be utilizing QRDA instead of using it for this purpose.
• P129 ONC provides a 2014 to 2015 equivalency table that will save many of us a lot of work understanding the rule.  Thanks!
• P149 Finally Meaningful Use gets meaningful brand identification with introduction of a certification mark 
• Questions about 2017 criteria start at p154, and so I stopped reading there, since my review was strictly to address 2015 criteria.

Of significant note, BlueButtonPlus didn't make it into the proposed criteria, and was barely discussed in such as way as it could be included.  However, there's a way forward.  But first some discussion about regulations.

There's rules about regulations, not surprising.  One of those rules is that if it wasn't discussed or asked in the proposed regulation, it cannot be done in the final rule.  So if there is no discussion about Blue Button + in the regulation, it couldn't be in the final rule, right?  Except there is a big hole in the second paragraph of Page 100 which says: "We seek comment on whether we should require another transmission method as part of this certification criterion in addition to the one just discussed."

There's the opening for Blue Button +, which is after all, a transmission protocol.  So, if you want Blue Button + to be part of the 2015 criteria, that appears to be your opening.  It is such a close thing to what is already required in VDT, couldn't we just go there?

As a summary, this is pretty long.  Let me make a long story short.  My grade on predicting appears to be 3.5 right out of 5, with one major missed prediction (GUDID).  I can live with that score, especially since I don't know many others who were willing to go out on such a limb.

     Keith

P.S.  I proposed in my Project Management class to take on planning a project to do an assessment of the 2015 criteria.  Now that we have half a clue what it is, my team can proceed to the next step.