On October 16th, 2011 the DEA released a series of clarifications regarding the requirements for Electronic Prescriptions of Controlled Substances (EPCS). While overall this clarification was very helpful and confirmed the comprehensive nature of the certification process, it did introduce / revive a concept that triggered several calls and inquiries. More specifically, DEA listed a company that has been certified to conduct DEA EPCS Certifications, which raised excellent questions:
Why is NetSPI not listed on their website? (Answer: We don’t need to be; we meet other requirements that make us qualified certifiers)
Is NetSPI allowed to certify our application before you are listed on DEA’s website? (Answer: Yes)
According to 21 CFR 1311.300(a), there are two alternative processes for achieving the necessary qualifications:
“A third-party audit conducted by a person qualified to conduct a SysTrust, WebTrust or SAS 70 audit or a Certified Information System Auditor as stated in 21 CFR 1311.300(b), which comports with the requirements of paragraphs (c) and (d) of 21 CFR 1300.300” or
“A certification by a certifying organization whose certification process has been approved by DEA”
Therefore, the certification process emphasized within the clarification is simply one of the alternatives, and is in no way required or mandatory. While the principal consultant involved with the EPCS Certification is a Certified Information System Auditor (CISA) in good standing, there should not be any issues with qualifications. Experience with SysTrust, WebTrust, or the slightly outdated SAS-70 (in my opinion) are more a derivative of training provided by ISACA as part of CISA.
The bigger question would be whether having appropriate qualifications is the only measure by which you should select your certifying agent. This is where things like experience with certifying applications in other standards, experience in healthcare, and understanding of software development lifecycle can be significant differentiating factors. Certainly, like with any other regulatory standard, there will be (perhaps already are) many low-cost, rubber-stamp firms that might get you the certification letter you are seeking. They may let you replace application controls with policies and documentation, conduct the whole assessment by phone, and turn the whole certification process around in 24 hours. However, obtaining the certification is only the first step in the long journey of maintaining DEA EPCS compliance. If your client decides that your application does not meet requirements or is in violation of EPCS, you will have to investigate all such claims and if confirmed, announce to all of your customers that they can no longer use your application to prescribe or accept electronic prescriptions of controlled substances. (21 CFR 1311.302)
While it may seem appealing to take a run at getting through the certification fast, trust me, taking this shortcut is not a good idea, and any perceived savings of time and money will likely come back to haunt you in the future. Going for the low-cost auditor in this case may actually be the most expensive option.
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.
The Mayo Clinic recently launched Mayo Clinic Center for Social Media (http://socialmedia.mayoclinic.org/) intended to help train medical practitioners and patients about the use of social media to improve patient care. While it’s easy to see how greater access to healthcare related information can be very valuable, problems with doctors and nurses posting PHI inappropriately has made news headlines more than a handful of times. Therefore, this new development comes at a great time, just as more and more organizations are beginning to appreciate the value of a comprehensive social media strategy.
With the goal of delivering better quality care to patients, many healthcare systems are sharing EMR applications and medical data repositories and setting up interfaces between different systems. This increases exposure of medical records to a larger group of healthcare practitioners by allowing better, faster, and easier collaboration between doctors. With increased collaborative efforts, it’s become more likely that doctors will choose social media as the catalyst of collaborative efforts and patient information sharing. Therefore, organizations that act as custodians of PHI, such as hospitals, clinics, and research labs, must take active steps in educating their workforce about the dangers of social media, and how these tools can be used effectively and without violating patient confidentiality or current healthcare compliance requirements.
Through the Center for Social Media, Mayo Clinic seems to approach the problem from multiple angles. While the portal is still very young, the articles already posted address issues of creating well-designed social media policies, creating appropriate training materials, as well as provide analysis of documented cases of misuse of PHI. Overall, I view this as a very positive development and will continue to monitor this website for insightful information about the best use of social media in healthcare. After all, this technology is here to stay, and draconian policies of simply blocking access to Facebook from the workplace have proven to be ineffective. The answer to these challenges clearly point to better guidance and training for the healthcare practitioners, as well as developing tools for responsible, effective, and secure collaboration.
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.
