Georgetown University Hospital suspended a trial program with an electronic prescription-writing firm last week after a computer consultant stumbled upon an online cache of data belonging to thousands of patients, Wired News has learned.
The leaked information included patients' names, addresses, Social Security numbers and dates of birth, but not medical data or the drugs the patients were prescribed, says Marianne Worley, a spokeswoman for the Washington, D.C.-based hospital known for providing emergency care to the nation's most powerful political figures.
The hospital had securely transmitted the patient data to e-prescription provider InstantDx. But an Indiana-based consultant accidentally discovered the data on InstantDx's computers while working to install medical software for a client.
The computer consultant for the small doctor's office says it was pretty easy to access the data accidentally, as he did, which highlights the danger of having sensitive personal information such as is found in healthcare records in one central location. Nothing bad came of this. The consultant only came across social security numbers and names, not medical information. And he was an honest man who found the information accidentally, not someone looking to steal identities or blackmail a person of prominence.
Of course, he's being vilified by InstantDx anyway. It's his fault their security is so lax, evidently:
InstantDx attorney Robert Hudock, an e-health specialist at the Washington, D.C., firm Epstein Becker & Green, says two separate weaknesses conspired to create a security hole for a brief period of time, and that no malicious activity resulted. He emphasizes that Perry couldn't have accessed the data if he hadn't gone poking around in Medisoft.
'Randall is the only player in the deck here,' says Hudock. 'He was entrusted with a secured copy of the application that had been appropriately licensed and installed, and he was working ... (as) a consultant for this particular physician.
'This vulnerability wouldn't have happened if the consultant to the physician had stuck to his responsibilities as a business associate of the physician,' says Hudock.
....Reached for a follow-up interview Monday, Perry said he could no longer discuss the incident, having signed nondisclosure agreements with the hospital and InstantDx.
'It seems like they're trying to blame me for this, and it's left a very bad taste in my mouth for the whole experience,' he says. 'If I found something again, I doubt very much that I'd ever report it. It's not worth it.'
Swire says the leak of customer information might run afoul of HIPAA, the federal electronic medical record keeping law, but that the organization in charge of enforcing the law's privacy protections has not been fiercely active.
'There's over 20,000 HIPAA complaints to (the Department of Health and Human Services), but zero civil enforcement actions so far,' says Swire. 'If HHS refuses to enforce the law, then medical organizations will be less careful with patient data.... I believe that will make it harder to do the next shift towards electronic medical records.'
Look, electronic records are fine, but there's going to be a high price to pay in privacy and security if we're going to base them on large accessible centralized files of information. Especially if those files of information are going to interact freely with individual doctors' offices, such as happens with e-prescribing. In e-prescribing, the pharmacies send requests for refills directly to a doctor's electronic medical record, and the doctors send the prescriptions back directly to the pharmacies' computers. It only makes sense that the more avenues of access to any given data file, the less secure that data is going to be. That's what makes me nervous about e-prescribing, and it's the reason I haven't adopted it in my own practice. I suspect its ability to reduce errors is greatly exaggerated, and its potential to create mischief underappreciated.
"The consultant only came across social security numbers and names..." Sorry folks, this is all you need for identity theft. Social security numbers are the biggest tag anyone person has for their private information. We are also the only country in the world to use a number in such a manner.
Identity theft is a growing and costly problem. Protect that number.
after a computer consultant stumbled upon an online cache of data belonging to thousands of patients, The place has never heard of encryption? How was this data stored anyway? As plain files on disk or in some database. The former is idiotic, the latter should have some level of encryption. Really, try to get any of the confidential data from an IT company (e.g. IBM) and see if you can easily "stumble" on any of it. As far as transimission is concerned, there are ways to secure it too.
Slightly off-topic but somewhat-related to the data security. I am always entertained with every new "laptop computer stolen" news story? These places have never heard of BIOS and hard disk passwords? But a password-protected notebook hard disk is useless unless you know the password. My company requires it for all company notebooks.
Of course, he's being vilified by InstantDx anyway. It's his fault their security is so lax, evidently
I can relate. As a young computer programmer learning to solve problems in a new computing environment (new for the company AND new for me) I tripped over similar information: names, social security numbers for sure, and probably salary data. I didn't examine it closely enough to determine that, but the old volume label was suggestive.
I reported this "find" immediately to my superintendent (that's what line-managers in the engineering department were called then), and he ran it up the chain.
After receiving some frosty comments from people in the MIS department, I asked my boss what was going on. At that point I learned that my firing had been discussed at the vice-president level of the company. Fortunately for me, the VP of Engineering asked the VP of MIS evidently with the VP of Personnel listening to the discussion why it was my fault the data was not secured and what I should have done differently.
The place has never heard of encryption?
It just isn't this easy. If it were, there would be no problems.
Look, electronic records are fine, but there's going to be a high price to pay in privacy and security if we're going to base them on large accessible centralized files of information.
Accessible to whom? Records will be accessible to someone, encrypted or no. And for decades now "we" have stored what I'll call our "medical treatment history" in large accessible centralized files of information at insurance companies.
It is good that we are more sensitive now to these issues, and it is shameful that it has taken HIPAA to get especially the smaller providers and payers to pay any attention at all to this issue, but I think folks should get a grip.
It just isn't this easy. If it were, there would be no problems.
Not easy for whom? For non-IT personal, certainly. But for software developers that created the billing system - it is a requirement. The medical billing system that saves this data to disk should have encryption built-in. When this data is saved on disk, the system should encrypt it. When an authorized user uses the billing system, the system should decrypt it before presenting it to the user. The system should require a separate password for database access, not the one used to logon on the machine. The system should enforce password rules to ensure it is not something trivial like your child's name. The system should lock out the user after 3-5 attempts with the wrong password - to prevent access by a malicious program that tries all combinations - the password can then be reset by administrator (or if there is no administrator by the user himself or by restarting the system). If I were developing such a medical system, data security would be a major requirement.
For example: at work I use Lotus Notes. My Windows log on password is not the same as I use to access databases managed by Notes. The (hashed) authorized user information is stored in a separate file. All databases used by this software are encrypted. The encryption completely transparent to me as a user. If you can logon to my Windows machine even if to install something even a new version of this software you don't need to have access to the database files. Can it be broken into - probably; any software-based security can be breached with some effort. But you cannot "stumble" on my data accidentally.
> But for software developers that > created the billing system - it > is a requirement.
Well, Diora, I have more than a little experience as a software developer in healthcare, and I tell you the requirements come from the customers not alas! from the developers.
Until recently, the customers have not required much at all in the way of security. And they have refused to pay for it.
Everything you have described about passwords is easy, but isn't very secure. It has been provided for a long time now. But very often, healthcare organizations have refused to implement it because result observed the most frequently with respect to computer system security is that legitimate users are prevented from doing their work. And so you see a terminal at the nursing station logged in using a generic password, and everybody trots up to it and uses it without logging in. Why? Its quicker.
Beyond the gross access issue, should a nurse on 3W be able to see information about a patient on 5N? No, you say?
But wait!! This morning, someone called in sick, and the 3W nurse is helping out on 5W. How `bout now?
Should a billing clerk "authorized" to use "the system" be able to see clinical data at all? What about a medical records coder? But what if this isn't one of her cases to code? Even if it is, should she be allowed to see the UB92 that gets generated? Or the patient's last visit?
Until the customers nail-down roles and responsibilities, and procedures for modifying these on the fly, the computer systems can't do much more than gross access-level security and some logging to figure out who to fire after the fact. This is not an argument against passwords and other gross-level access controls.
To reiterate, data security is a requirement for the healthcare organizations, not for the software developers.
> All databases used by [Lotus > Notes] are encrypted.
So you are telling me that if you lose or forget your password that all your Lotus Notes data is lost forever? That if you leave, the company loses forever what you have got in Lotus Notes unless you are so kind as to share with them your password/encryption key?
Encrypting an entire database is reasonable for a snapshot taken off-site (say) on a laptop, but is most problematic with respect to the main production database. Think about the management oversight and compliance issues this raises! And the troubleshooting and support issues, and on, and on. I do not think I would permit it.
Security isn't so easy as you imagine -- for the organization.
Tom, you make many valid points. I admit that I am not familiar with medical systems, since I've mostly worked with general purpose software - I am a software engineer by the way, but I work in R&D, mostly middleware. My only exposure to computer security comes from a few years when I worked on anti-virus software development; but that was a while ago. I guess working purely with general purpose software rather than applications and especially in research makes me a bit insulated from real world customers ...
You are right in that there is always a trade-off beween security vs cost and usability and that some of these password rules make it more likely for someone to write passwords on the paper. But keeping open data for anybody who happens to pass by on the disk is a slightly different issue. Aside from people who can stumble on it accidentally like any IT service person, any computer connected to the network is vulnerable to outside access (I hope they at least have a firewall and their administrator account is password-protected; otherwise, it would be real fun).
It seems to me that even having a simple password-protection with a not-so-complicated password seems better than none - at the very least it may provide level of security close to paper file. Even if the billing system itself must be accessible to all hospital personal who would otherwise have access to paper files shouldn't the data stored on disk so that someone from outside doesn't stumble on it accidentally? Or someone from outside?
As far as Notes is concerned, the data in Notes databases is replicated and the password can be reset by the administrator and I have one day to change it again; so the data on the server is not lost; new id file is created. Obviously, this only applies to Notes databases - my private files and programs are my responsibility, but I do have a BIOS and hard disk passwords in case my laptop is stolen. Now if I were to forget my hard disk password it'd be a real problem; but I have a backup on the server.