Information Week ran an article this week on protecting patient data. The article wasn’t on one of the usual suspects — a HIPAA violation or a breach in a production system. Instead, this was notable because we’re finally seeing one of the hidden dangers in healthcare IT coming to light: unsecured patient data sitting in development and test systems. Our industry needs to start addressing this issue.
Information Week cited a survey where 51% of organizations don’t protect patient data used in software development and testing. Yet the per victim cost of data breaches in healthcare is $294, 44% higher than other industries. Read more on the Information Week site.
It’s a given: vendors and providers have to use real-world data to test applications, systems, HL7 interfaces, and connectivity. There’s no getting around that. Without test data — accurate, realistic test data — you don’t want to go ahead with the product launch, system go-live, or integration engine migration. There’d be too much at stake. Without a reasonable volume of real-world test data, you end up testing for too-good-to-be-true workflows and patients. The result is way too many bugs, enhancement requests, delayed projects, and (rightfully) irate clinicians down the road.
So oftentimes, the solution to robust testing is to copy over production data into the test system. There are times when providers end up sharing production data — for instance, HL7 message logs — with vendors. Under certain circumstances, these approaches can be fraught with security issues. So vendors and providers need to ensure they’re working within regulatory frameworks when they use production data for development and testing.
But instead of clamping down and setting up a governance structure that says, “Never, ever extract production data,” how about looking for ways to do it safely?
One way is to de-identify production data before porting it over to the test system. So you remove information that can identify patients while leaving real-world workflows intact. We’ve written about de-identifying HL7 data here. And provided a few de-identification definitions here.
Because of this issue, we’re working on an HL7 data de-identification tool — a data protection tool, if you will. If you’d like to learn when the software beta opens, please sign up here (don’t forget to check the beta notification box).
Comments
Any comments or insights on protecting patient data in test or development systems? We’d love to hear from you in the comments below, on Twitter, or by email (it’s at the top of this post).