It would seem that poor quality information has caused some definitely embarassing and potentially risky outcomes in Google’s new on-line Patient Health Record service. The story has featured (amongst other places) :

• Here (Boston.com, the website of the Boston Globe)
• Here  (InformationWeek.com’s Global CIO Blog)

‘Patient Zero’ for this story was this blog post by “e-patient Dave” over at e-patient.net. In this blog post “e-Patient Dave” shared his experiences migrating his personal health records over to Google Health. To say that the quality of the information that was transferred was poor is an understatement. Amongst other things:

Yes, ladies and germs, it transmitted everything I’ve ever had. With almost no dates attached.

So, to someone looking at e-Patient Dave’s medical records in Google Health it would appear that his middle name might be Lucky as he had every ailment he’s ever had… at the same time.

Not only that, for the item where dates did come across on the migration, there were factual errors in the data. For example, the date given for e-Patient Dave’s cancer diagnosis was out by four months. To cap things off, e-patient Dave tells us that:

The really fun stuff, though, is that some of the conditions transmitted are things I’ve never had: aortic aneurysm and mets to the brain or spine.

The root cause that e-Patient Dave uncovered by talking to some doctors was that the migration process transferred billing code data rather than actual diagnostic data to Google Health. As readers of Larry English’s Improving Data Warehouse and Business Information Quality will know, the quality of that data isn’t always *ahem* good enough. As English tells us:

An insurance company discovered from its data warehouse, newly loaded with claims data, that 80% of the claims from one region were paid for a claim with a medical diagnosis code of  “broken leg”. Was that region a rough neighborhood? No, claims processors were measured on how fast they paid claims, rather than for accurate claim information. Only needing a “valid diagnosis code” to pay a claim, they frequently allowed the system to default to a value of “broken leg”.

(Historical note: while this example features in Larry’s book, it originally featured in an article he wrote for DM-Review (now Information-Management.com) back in 1996.)

“e-patient Dave” adds another wrinkle to this story..

[i]f a doc needs to bill insurance for something and the list of billing codes doesn’t happen to include exactly what your condition is, they cram it into something else so the stupid system will accept it.) (And, btw, everyone in the business is apparently accustomed to the system being stupid, so it’s no surprise that nobody can tell whether things are making any sense: nobody counts on the data to be meaningful in the first place.)

To cap it all off, a lot of the key data that e-Patient Dave expected to see transferred wasn’t there, and of what was transferred the information was either inaccurate or horridly incomplete:

what they transmitted for diagnoses was actually billing codes

the one item of medication data they sent was correct, but it was only my current BP med. (Which, btw, Google Health said had an urgent conflict with my two-years-ago potassium condition, which had been sent without a date). It sent no medication history, not even the fact that I’d had four weeks of high dosage Interleukin-2, which just MIGHT be useful to have in my personal health record, eh?

the allergies data did NOT include the one thing I must not ever, ever violate: no steroids ever again (e.g. cortisone) (they suppress the immune system), because it’ll interfere with the immune treatment that saved my life and is still active within me. (I am well, but my type of cancer normally recurs.)

So, it would seem that information quality problems that have been documented in the information quality literature for over a decade are at the root of an embarassing information quality trainwreck that could (potentially) have an affect on how a patient might be treated at a new hospital – considering they have all these ailments at once but appear asypmtomatic. To cap it all off, failures in the mapping of critical data resulted in an electronic patient record that was dangerously inaccurate and incomplete.

What would Dr. Gregory House make of e-Patient Dave’s notes?

e-Patient Dave’s blog post makes interesting reading (and at 2800 words + covers a lot of ground). He details a number of other reasons why quality problems exist in electronic patient records and why :

• nobody’s in the habit of actually fixing errors. (he cites an x-ray record that shows him to be a female)
• processes for data integrity in healthcare are largely absent, by ordinary business standards. I suspect there are few, if any, processes in place to prevent wrong data from entering the system, or tracking down the cause when things do go awry.
• Data doesn’t seem to get transferred consistently from paper forms to electronic records (specficially e-Patient Dave’s requirement not to have steriods).
• Lack of sufficient edit controls and governance over data and patient records, including audit trails.

e-Patient Dave is at pains to make it clear that the problem isn’t with Google Health. The problem is with the data that was migrated across to Google Health from his existing electronic patient record.

Google Health – DOA after an IQ Trainwreck.?