Our founder, Dr. Ken Pool wrote this blog a few years ago. His ideas on health data security offer a unique angle and inspire us to innovate and improve health IT security.
You may or may not trust a man who doesn’t trust his own pants but never trust just one copy of healthcare data. This idea seems almost nonsensical or at least obvious to the most casual of observers but here it goes...
One of the lesser quoted benefits of electronic health records, is that they can be copied (not in the illegal way). So the days of a patient’s record lost in the trunk of the doctor’s car (admit it guys, you have been guilty of this at some point) can now be banished to the scary stories of our healthcare childhood. And since they can, they should. The prime directive in data management is that any important data should be duplicated. In the old days we did this by making backup tapes each night and methodically storing them in a safe place (in my trunk always seemed like a good option to me). The problem was if the original was ever destroyed (like that Sunday morning when the oil depot next to the data center blew up in Hemel Hempstead, England), then it might take a while to find the copy, find out if it was the latest and if it really worked (fortunately that copy was in a cave in Wales).
The days of tape backups are behind us (no one actually still uses them, do they?) and we have raised the bar. In the old days, having a backup as of yesterday was sufficient. That meant we could lose up to one day’s data, which is fine if it isn’t your data. I mean how would you feel if the results of your colonoscopy were lost? Today, the maximum period of data loss can reasonably be down to a few minutes or seconds. So real-time replication to another location (preferably in another part of the power grid) should now be part of the performance expectations (or service level agreements).
That should give us a nice belt but do we still need suspenders? I am afraid it is so. The focus of any high availability plan is first to eliminate every single point of failure. To find the one thing that, if it failed, would render the data (even briefly) unavailable. We do this routinely with redundant switches, power supplies, RAID drives, and as we just discussed, data centers. So what single point of failure remains to be eliminated? The company. If the company providing the healthcare repository fails (in financial terms, it bites the dust) then those data may be lost. If we are to achieve high availability we must require redundancy in the company.
This will be awkward. Company A offers healthcare repository services, but as part of that service, we require it to provide redundancy; meaning find another (unrelated or they may die at the same time) company (read competitor) to keep a copy of any data it stores. We could ask someone else to take care of this (like the provider of course, since we always dump things we don’t want to deal with on them) but if we are serious about the value of these data then supplying redundancy should be the responsibility of the repository service.
Redundancy in company is the suspenders we need to complement our belt.