Earlier this week, in the context of discussing of how old and forgotten databases can come back to bite us in costly databreaches, I reported on a somewhat bizarre situation involving files belonging to a Pennsylvania dentist. I have since obtained more information on that situation, and thought I would update you all.
Let’s start with the burning question of “What happened?” According to Dr. Ronald Schultz, in October of 2003, he was considering a change of computer systems. In order to “test drive” one particular computer system, he provided his patient database to the new vendor, Kapricorn (and yes, I know what most of you are thinking about him providing real data and not dummy data, but see this comment below this post).
“This involved the vendor transmitting our patient information to a protected outside server; particular credentials were required to access our files on the server,” Dr. Schultz explains. He continues:
As it turns out, we did not like the new computer system, and went with a different computer system provider. At that point, we believed that the information had been deleted or removed from the server, which was still protected and still required specific credentials for accessing it. In 2004, the company that owned the server was bought out by Atlantic Broadband, and the server was removed from the internet completely.
And that’s where things stood until the researcher who found the leak got in touch with him recently to tell him that he found some of his patients’ information online.
“We immediately began an investigation, including our own computer consultants and Atlantic Broadband,” Dr. Schultz reports. He continues:
It appears that, for reasons that are still unknown, the particular server that went offline in 2004 was brought back online for approximately 2 weeks. Additionally, during that time, the credentials requirement was removed, so that anyone who could find that server on the internet could access the information.
So for about two weeks, files that were presumably deleted 12 years ago reappeared online for reasons no one seems to know or is willing to admit to.
So now what? Is notification of patients necessary at all? In the opinion of attorney Jeff Drummond, this is not a reportable breach under HIPAA because the dentist is not a covered entity under HIPAA. While that may surprise some readers, keep in mind that HIPAA applies to health care provider “who transmits any health information in electronic form in connection with a transaction covered by this subchapter.” Because Dr. Schultz does not engage in electronic transactions of any kind, he wouldn’t be covered by HIPAA, Drummond tells DataBreaches.net.
Sometimes it pays to be a dinosaur.
But what about any notification requirements under state laws? The opinion of those who investigated the leak seemed to be that there was very low risk of finding or accessing the data. For patients in states where the threshold for notification is likelihood of harm or identity theft, then no notification would be required. The only exception might be patients from Virginia, where the statute requires notification if healthcare information is involved.
So Dr. Schultz does not need to notify HHS, and he probably doesn’t need to notify patients in three of the four states from which his patients come. Despite that, he has decided to notify all patients whose Social Security numbers might have been exposed. He explains:
In the course of our investigation, we were not able to definitively rule out that no one other than Mr. Shafer and our own practice and consultants accessed the information during the brief period it was available and unprotected. However, it was clear to us that only someone with specific skills in dental computer technology, and only someone with access to old versions of current dental computer software (such as Mr. Shafer), who also happened to be looking for that specific server, would have been able to access that information and be able to view it or use it. Based on this, by early August the practice had determined that there was a low probability that your data might have been compromised, and that no notifications were required.
On August 31, Mr. Shafer told the practice that he thought there might be other ways to view the data, if someone acquired it during the two-week period it was online. We still believe that it would be extremely difficult for anyone without specific knowledge and access to old technology. However, out of an abundance of caution, we are providing you with this notice that, through no fault of this practice, there is a slim possibility that your dental information, including your social security number, might have been accessible during that time period, and we believe that there is a small chance that you may be at risk of identity theft.
Nicely done. And I’m pleased to see that the researcher who uncovered the leak was not treated as some kind of criminal hacker or miscreant, but was treated respectfully.
So we still don’t know how files that were allegedly deleted by the vendor magically reappeared, and we don’t know how a server magically reappeared online after twelve years.
But could this happen to any of us who use vendors or third-party providers? What are you doing to protect against this type of situation?
I think the possibility exists that the ftp server was up longer then 12 days, and for that reason, and perhaps the lack of logs, is the main reason to notify. I am glad the doctor has chosen to notify.
Oh, I would like to add, that the doctor handed over live data because it is supposed to go through data conversion, and then after that there is normally a large checklist of things that must be verified.. Patient Balances, Notes, etc etc.. And without actual instead of fake data, the test conversion won’t.. REALLY be a test. Thought I would throw that in here.
Thanks for explaining that… I’ll point to your comment from my post.
Seems like a best practice for customers like this dentist would be to get a written attestation that patient/test data has been destroyed at the conclusion of a test. Then at least the customer would have something to clarify who’s responsible for breach liability.
That’s actually one of the recommendations in a report I’ve co-authored that will be released on Monday. GMTA…