Pretzel Logic: Have Sympathy for Your Vendor 11/8/13

Well, the season is upon us again. I’m referring of course to Meaningful Use certification and attestation time, when ONC and CMS determine who’s naughty and who’s nice. Actually with the new HIPAA rules and proposed Accounting of Disclosure rules, it’s the Office of Civil Rights who will determine who’s naughty….and who’s naughtier. But that’s another story.

You may have heard from your EHR vendor or experienced firsthand or seen recent press coverage on the difficulties that vendors are experiencing with certifying their systems to support Meaningful Use Stage 2. Headlines such as “Stage 2 proves challenging for vendors” and “Fewer certified EHRs for Stage 2 may pose problems for hospitals, doc practices” may sound like normal vendor whining. But when the normally sunny and always encouraging Dr. John Halamka jumps on the criticism bandwagon, you know there might be some trouble underfoot.

I know, I know, it’s hard to have sympathy for vendors when you clinicians have a million MU hoops to jump through, but hear me out. First I need to point out the difference between attestation and certification. Attestation is governed by CMS and refers to what providers have to do, while certification is determined by ONC and refers to what EHR vendors have to do. In theory, certification is synced with attestation, meaning that ONC doesn’t require vendors to provide tools that do anything more than what CMS is asking providers to use them for. In practice, it’s too hard for the government to resist the temptation to use the MU regulatory lever to get vendors to do more, so there are some certification hoops that EHR vendors have to jump through that most clinicians are totally unaware of. Further, certification for Stage 2 is made even more complex by crudely constructed certification definitions which get amplified by messy testing requirements permeated with cumbersome “make-work”. Here are a couple of examples.

A significant evolution in the development of EHR systems is the idea of modularity. The MU program encourages development of certified “EHR modules” focused on a single EHR function (like e-prescribing or quality measurement), which in principle allows users to mix-and-match EHR components according to their own needs and preferences. Kind of like Google’s Android Market or Apple’s App Store. Great concept, but it makes sense only to the extent that the modules are well defined. As it turns out, they’re not. (sigh)

Take the certification requirement for exchanging transition of care summaries. It’s actually broken into two certification requirements, one for sending and the other for receiving. The original idea, forged in the Direct standard, was that this would basically be secure email. Yet, the ONC rules require much more than that. In order to get certified for sending and receiving clinical documents, ONC requires that the EHR component has to be able to create the standardized clinical document as well as deliver it to the intended recipient, and it has to open and parse the document after it has received it from the sender.

That’s like saying that Gmail should be required to generate spreadsheets, or Fed Ex should only be able to deliver parcels that they package, or that cable companies should only be able to deliver programming that they create. What would happen in such a world? Well, Gmail would be very clunky, Fed Ex probably wouldn’t exist, and we’d probably see even less competition in cable services than we do today as these artificial restraints force TV programmers (like HBO) to be married to distributors (like Comcast). In all cases we’d get less choice, higher cost, and lower quality.

Similarly, in the EHR market, the artificial restraints created by the transport certification rules are forcing bundling of secure email with basic EHR services. The result is that small focused vendors of secure email are getting blocked out of the market unless they enter alliances with larger traditional EHR vendors, because the secure email vendor applications don’t create clinical documents. And while some traditional vendors, like Epic and Meditech, are implementing their services in a way that allows their customers a wide variety of choices, most other traditional vendors either are locking their customers into proprietary approaches or haven’t yet figured out what to do because the certification rule is so darned complicated and unnatural.

Another example is the certification requirement for clinical quality measures. I have personal experience in this area because my company has a quality data analytics business and we recently got certified for MU Stage 2. There are 64 MU Stage 2 ambulatory clinical quality measures, and we decided to begin by getting certified for 26 of them based on our customers’ immediate needs. As part of the testing process, we were given ONC-provided dummy patient data on 22 fictitious patients, and we were required to generate each of the 26 measures on the panel of 22 dummy patients. OK, so far, so good. Unfortunately, it didn’t stop there.

The certification rules also require that we slice and dice the patient panel and associated clinical information and put each of the results of that slicing and dicing into separate standardized “QRDA” files. So for each measure we had to calculate the measure on the full panel of patients, and then stratify the results on four dimensions: race, ethnicity, gender, and payer. Then we had to generate a physician-level standardized file (a QRDA3) which contained all measure results for all 26 measures, and then show the breakdown of each measure by race, ethnicity, gender, and payer. Then we had to generate a separate standardized file (a QRDA1) for each patient in each measure, and each patient file could only include the clinical information relevant to a specific measure. So if the same patient had diabetes and hypertension, we had to parse the medical record and create a diabetes measure file with only the diabetes information, and a separate hypertension measure file with only the medical hypertension information. I’m not joking.

The result was that we had to generate 122 persnickety, fussy report files, and that was only for a patient panel of 22 dummy patients. A typical ambulatory physician has an active patient panel of 2,000 patients, some of them very clinically complex. Generating measures on such a panel would require the EHR to generate thousands of stratified result files per physician each time the measures are calculated. I assume that someone somewhere intends to make excellent, society-enriching use of such finely minced information, but right now it’s not clear who that would be. Certainly not the physician.

It turns out that even CMS finds this output too hard to handle. Up until a few days ago, the Pioneer ACO program required that quality measures be submitted according to the QRDA approach beginning in January 2014. Many vendors have been hard at work developing these reporting functions. On November 5, CMS backtracked and announced that they could not accept the QRDA formats and all reporting for January 2014 would revert back to a manual web upload process. Doh!

These two examples are just the tip of the iceberg. They cover only five of the 49 required certification modules for Stage 2-compliant technology. I don’t have enough energy or patience to describe what lies beneath the other 44 requirments.

One of James Joyce’s readers is said to have commented that Ulysses was very difficult to read, to which he is said to have replied, you should have tried writing it! For Stage 2 MU, the same might be said for EHRs – they may be hard to use, but they are getting ever harder to program. My point in expressing sympathy for EHR vendors is not to cover up or apologize for their mercenary tendencies. Rather it’s to simply point out that there is stress on all sides right now. So if your vendor seems to be fraying at the edges consider showing them a little patience and maybe even give them a smile. And then, by all means, get right back to letting them know that their product is barely useable, their prices are too high, and their support stinks.

Micky Tripathi is president and CEO of the Massachusetts eHealth Collaborative. The views expressed are his own.