I’m sick --- one of those winter-is-coming things that’s not remotely serious, but leaves you with a huge pile of Kleenex, a brilliantly red nose and a huge case of the crankies. So forgive me if this is a little harsh, but I think it’s well-deserved.
Are EHR developers just inept, or do they write crap on purpose?
Before you go getting all defensive, let me explain.
We have this HealthVault thing, right? Well, thanks to Meaningful Use, every day more and more people are bringing their visit summary files to us. Some because they’re lucky enough to be part of a data sharing pilot, others because they’ve discovered Direct messaging --- and yet more because they’ve just taken the initiative to demand a copy of their damn data.
The result? Sometimes it works great, and when it does, the response we get from families is fantastic. It’s like a completely new world --- they have a real immunization list, have accurate past histories when they go to new providers … shoot, they can even just print out an emergency profile page for the babysitter. Pretty freaking awesome.
But at least half the time, things aren’t nearly so rosy, because we can’t read the file they got. Now, I understand that medical information is complicated, and at the edges we’ll all have work to do helping things move seamlessly. But that’s not what I’m talking about.
Just this weekend, I received CCR documents from a mom who got them from a MAJOR EHR vendor, frustrated that they wouldn’t load into HealthVault. She was determined enough that she shared these very private files with me so I could see what was up (this happens multiple times a week btw).
Well, here’s what was up: they simply weren’t CCR documents at all. In very fundamental, basic ways, they did not follow the basic “schema” defined by the ASTM. I’m not talking about “interpretation of the standard” --- I’m talking about basic syntax errors, like random characters in the file or missing required elements. And to be clear, I’ve seen this same crap from a ton of other vendors in the last few months.
Clearly, the code to create these files was created either by somebody completely incompetent --- because even the most basic unit test would have shown them their errors --- or by somebody who really didn’t care about doing it correctly. I’d like to be more generous, but there is simply no other explanation.
If one of my developers wrote code like this --- they would not remain a HealthVault developer for long.
Unfortunately, the HIT industry has consistently rewarded this kind of nonsense. Remember, the vast majority of vendors really don’t want to interoperate --- but we’ve allowed them to claim the high ground, talking up their commitments to “interoperability” and issuing press releases, all the while churning out crap code that simply doesn’t work.
I guess there is good news here too --- at least now more people are trying to use the files, so the errors are coming to light. But the problem is, those early adopters are getting discouraged and frustrated because when they finally do squeeze out some cooperation --- they’re faced with incomprehensible technical errors and often just give up. We need all the momentum we can get, and this isn’t helping.
I’ll make all my readers a deal --- if your EHR system can spit out a CCDA, CCD or CCR --- take a sample and try to upload it to HealthVault (instructions below). If it doesn’t work, send it to me and I’ll tell you why --- if you agree that you will file a bug report with your vendor and pester them until they give you a fix. Maybe if we do that --- we’ll make some progress.
To test your file: