I recently had the opportunity to review an article by Michael Koploy of Software Advice titled “HHS Data Tells the True Story of HIPAA Violations in the Cloud“. While the article has great data about the historical breaches, I think it’s fair to say that not enough time has passed for us to know the real implication of companies moving EMRs into the cloud. HIPAA violations in an IT-centric environment like cloud or software-as-a-service providers are harder to detect, and the general awareness of rules around HIPAA violations are lower than that in the hospitals. In fact, that’s one of the basic problems with people deciding to move their data into the “cloud;” it requires a lot of blind trust.
Also, it’s important to keep in mind that a lot of physical theft reported by hospitals has nothing to do with someone actively seeking to steal PHI, and everything to do with someone losing a box of medical records in the warehouse or making their laptop easy for a thief to steal. Comparing this to electronic hacking of EMR is simply like comparing apples and oranges, unless you can prove that all instances of physical theft were motivated by someone looking for the medical records.
On the whole, I would suggest that we simply don’t have enough information to make a risk determination for storing EMR in the cloud or whether it’s a good idea. All we have is the “Wall of Shame” from HHS and the data that can be interpreted in many ways and support a variety of conclusions. For example, since 12/15/09, there have been 292 total reported incidents, of which 58 involved a breach caused by a Business Associate (BA). Also, the statistics showed that 50% of incidents reported by BAs involved a physical theft or loss of data, closely followed by “Unauthorized Access / Disclosure” category at 43%. This means that approximately 20% of all breaches involved a third-party, and in reality the statistics for breaches caused by BAs are not much different than healthcare providers. Applying an unfair twist to this statistic I could argue that a decision to not move data into the cloud would reduce chances of a breach by 20%, which would not be any less accurate than stating that the cloud will reduce the number of reported breaches. The truth is that there is simply not enough historical data, and companies need to exercise great due-diligence when they decide to trust a third-party with sensitive data.
At a recent networking event I heard a manager express frustration over managing an employee who got caught up in her own fairy tales that resulted in a very embarrassing termination. She told her co-workers that she was diagnosed with cancer and needed time off for surgery and treatment. The company responded with genuine concern and care, assuring her that she will have all the support and time off she will need. However, after an attempt to send her flowers to the hospital, they discovered that she was not there, and a little more probing confirmed that she never had cancer in the first place. Once I got over the ridiculousness of this lie, I started thinking about the implications of being able to determine whether someone is at the hospital…
Is letting someone know that a patient is not at a particular hospital at a specific time considered Protected Health Information (PHI)? What about calling the hospital, asking for the room where Mr. Kravchenko is located and promptly being routed to my room? Isn’t the simple fact of agreeing to route the call already considered PHI? I realize that this may not be the biggest or most prominent HIPAA violation for most hospitals, requiring some familiarity with the patient in order to make the inquiry effective. However, this also seems like this would allow for targeted inquiries into individual’s health records, all without having consent. I can also see how interested but not authorized parties can start checking for attendance to substance abuse or psychological treatments simply by calling at the time when the patient is suspected to be there.
Obviously, HIPAA was not created to protect compulsive liars from being able to deceive their employers and it hard to feel bad for the person who would lie about being sick with a terminal disease. However, this example does highlight the need for staff at hospitals and out-patient facilities to be trained on handling incoming inquiries, including deliveries of balloons and flowers. This also means that hospitals may need to come up with a different / better way of handling incoming calls to patient rooms, and may even need to start using “passwords” before routing a call. While many such incidents are anecdotal and often do not create a lot of sympathy for the “patient”, this does highlight just how easy it is for unauthorized disclosure of PHI to happen.
One of the most promising technologies for automatically enforcing compliance with sensitive data handling practices is Data Loss Prevention (DLP) technology and it is quickly gaining popularity and adoption across many industries. Does this mean that DLP is the answer to all sensitive information handling concerns?
In short, I am sorry to say that while DLP offers excellent solutions within a limited range of data, such as payment cards, social security numbers, and other easily identifiable data, it does not offer great solutions for HIPAA compliance. Most recently a case of an employee being fired from Oakwood Hospital in Michigan has once again highlighted the utter impossibility of automatically enforcing HIPAA compliance. In this case, Cheryl James made some comments on Facebook which were interpreted as a violation of HIPAA requirements. This was not the case of medical records being leaked out, but rather a comment made by a medical professional. More information about the incident can be obtained here. (http://www.fiercehealthcare.com/story/hospital-worker-fired-over-facebook-comments-about-patient/2010-08-01)
More and more people are using websites such as Facebook as a part of their everyday conversations with their friends and family. However, a comment made to a spouse in the privacy of one’s home is clearly not the same as posting that comment on Facebook. Since this is not the first time a comment made on a social networking website has landed a hospital employee in trouble, it’s clear that it will take some time before everyone fully realizes the risks of communication of sensitive data on social networking websites. Naturally the question that begs to mind is if there is anything that hospitals can do to prevent such incidents in the future.
The advantage of DLP technology is that if you are able to define the pattern or a structure for the data that can be automatically identified as sensitive, the DLP technology will be able to prevent most inappropriate transfers of such data, including posting on social websites. However, with regard to healthcare, data that falls in the range of being considered PHI is very diverse and does not allow for automated identification. Therefore, techniques for reducing risks of inappropriate disclosure must fall back on the low-tech controls such as training and blocking high-risk websites like Facebook for all employees.
Even though the full extent of the HIPAA and HITECH requirements will not be required for Business Associates until 2011, my experience with helping organizations reach compliance with appropriate security requirements suggests that compliance efforts should begin right away. Proposed changes to the rules can be viewed at regulations.gov (http://www.regulations.gov/search/Regs/home.html#documentDetail?R=HHS-OCR-2010-0016-0001).The deadline for submitting comments has passed on August 13th; however I would be surprised to find significant changes from those that have been proposed.
With Business Associates having to comply with the same requirements as Covered Entities, there are many important requirements with regard to handling ePHI. Companies should quickly become familiar with:
Performing periodic risk assessments that include ePHI – Organizations may decide to use guidance provided by HHS or use their own discretion.
Ability to respond to ePHI access inquiries – Just as covered entities, BAs need to be able to respond to requests regarding access to individual’s ePHI.
Incident investigation timeframe – In accordance with the HITECH requirements, responding to security incidents and issuing appropriate breach notifications must take place within a relatively short timeframe. While 60 days may not seem very short, having participated in a number of incident investigations, I can assure that this is not a lot of time.
Implementation of the above mentioned requirements may warrant creating new or modifying existing policies, implementing new security controls, and providing training for IT staff and other ePHI custodians. Failure to comply with policies and practices may cause the company to be viewed as negligent, triggering significantly higher fines and possible consequences for company leadership.
For those companies who have relatively new security and privacy programs, I strongly recommend referencing HITRUST Common Security Framework (CSF) for detailed implementation requirements for individual HIPAA and HITECH controls. While this may be seen as over-kill for small Business Associate organizations, the range of control implementation considerations will help organizations realize all possible consequences of these healthcare regulatory requirements. With implementation of some of the more technical controls requiring considerable cost and operational changes, organizations should take advantage of the time before the requirements have been mandated and companies fall into the scope of the HIPAA and HITECH enforcement efforts.
One of the common and consistent themes at HIMSS (Healthcare Information and Management Systems Society) this year was achieving “Meaningful Use” requirements so that healthcare providers can apply for EHR (Electronic Health Record) stimulus money. The “Meaningful Use” requirements focus on:
- Improving quality, safety, efficiency, and reduce health disparities
- Engaging patients and families
- Improving care coordination
- Improving population and public health
- Ensuring adequate privacy and security protections for personal health information
Naturally, my interest is within the last item in the list, and within this post I hope to bring more clarity to a small subset of what clearly is becoming the newest “hot-item” of the healthcare industry. Based on the “Meaningful Use” matrix created by the HIT (Health IT) Policy Committee, here are the security and privacy goals that need to be reached within the next year and a half:
2011 Objectives:
Compliance with HIPAA Privacy and Security Rules and state laws
Compliance with fair data sharing practices set forth in the Nationwide Privacy and Security Framework
2011 Measures:
Full compliance with HIPAA Privacy and Security Rules
An entity under investigation for a HIPAA privacy or security violation cannot achieve meaningful use until the entity is cleared by the investigating authority
Conduct or update a security risk assessment and implement security updates as necessary
What the above means is that healthcare companies need to conduct (or update an existing) security risk assessment, and implement the appropriate controls to meet HIPAA requirements. However, since conducting risk assessments is technically a part of HIPAA / HITECH compliance, the requirements could be further simplified to say that by the end of 2011, companies need to be HIPAA compliant.
One thing that companies really need to address is making sure that HIPAA compliance goes beyond EMR (Electronic Medical Record) applications, and includes the litany of small applications and medical devices that process, store, or transmit PHI. In order to ensure and demonstrate a comprehensive and complete state of compliance, healthcare providers need to make sure that risk assessments take into account all applications and medical devices, and provide clear supporting documentation of implemented controls and regulatory compliance.
For additional information, I have provided future 2013 and 2015 objectives below:
2013 Objectives:
Use summarized or de-identified data when reporting data for population health purposes (e.g. public health, quality reporting, and research) where appropriate, so that important information is available with minimal privacy risk
2013 Measures:
Provide summarized or de-identified data, when sufficient, to satisfy a data request for population health purposes
2015 Objectives:
Provide patients, on request, with an accounting of treatment, payment, and health care operations disclosures
Protect sensitive health information to minimize reluctance of patients to seek care because of privacy concerns
2015 Measures:
Provide patients, on request, with a timely accounting of disclosures for treatment, payment, and health care operations, in compliance with applicable law
Incorporate and utilize technology to segment sensitive data
