OCR got to toot its own horn in a big press release on Feb 7. Not only did they announce another settlement that happened in December that we had not heard about but they also recapped the record-setting year they had with enforcement cases in 2018. The last OCR settlement for 2018 involved two different breaches due to IT mistakes.
We’ve already discussed their enforcement efforts and how the financial totals were really boosted by a $16m Anthem deal. We kept expecting one more before year end but it never came. Not sure why we just get the big news in Feb but there was one more. It was one that starts way back in 2013. Cottage Health was also involved in some other cases with these breaches which may have delayed this settlement but who knows.
They already settled with the California AG about these breaches. They were also sued by their cyber insurance carrier. Added to that was the class action suits that involved both breaches. Now, they settled with OCR which may be the end of it.
As usual, let’s learn how we could avoid making the same mistakes as Cottage Health made in the past. First, let’s see what the press release about the $3m settlement included for Severino’s quote because that is usually the point we think they want us to pay attention in the settlement.
“Our record year underscores the need for covered entities to be proactive about data security if they want to avoid being on the wrong end of an enforcement action,” said OCR Director Roger Severino. “The Cottage settlement reminds us that information security is a dynamic process and the risks to ePHI may arise before, during, and after implementation covered entity makes system changes.”
Here are the facts laid out in the settlement agreement (emphasis mine):
“On December 2, 2013, and December 1, 2015, OCR received notifications from CH regarding breaches of unsecured electronic protected health information (ePHI) affecting the ePHI of approximately 33,349 individuals and 11,608 individuals, respectively. On December 26, 2013, OCR initiated an investigation of CH. On July 2, 2014, CH provided notification updating the number of individuals affected by the first breach to 50,917.
The first breach arose from the removal of electronic security protections from one of CH’s servers by a CH contractor. As a result, patient names, addresses, dates of birth, diagnoses/conditions, lab results, and other treatment information was available to anyone outside CH with access to its server and the ability to download files without a username and password.
The second breach traced back to an employee activating the wrong website on a SQL server. As a result, 11,608 individuals’ ePHI was accessible on the internet. The ePHI included patient names, addresses, dates of birth, social security numbers, diagnoses/conditions, and other treatment information.”
Both breaches caused by IT failures in configuring devices and systems. The articles about the CA AG settlement linked to above and others had more details. They settled that time for $2 million. If the state had gone for the whole enchilada they could have gotten as much as $275 million.
According to the complaint filed in Santa Barbara Superior Court, surgical records of more than 50,000 patients were openly available on Cottage data servers between 2011 and 2013, including names, addresses, dates of birth, and medical information. Google accessed the information hundreds of times, making the data available to anyone who searched. It was an Arizona man researching on Google who notified Cottage in December 2013 that he could see medical records, which must be kept confidential by law. Cottage “was running outdated software, failing to apply software patches, not resetting default configurations, not using strong passwords, failing to limit access to sensitive PII [personally identifying information], and failing to conduct regular risk assessments, among other things,” the complaint alleges.
The second breach occurred over two weeks in 2015. This time, the lack of a server firewall exposed 4,596 patient records to online searches, including names, addresses, social security numbers, and employment information, the complaint states.
Here are perfect examples as to why we ask for IT vendors to use a checklist and document these sorts of system changes or upgrades. If you have to review your checklist and confirm you did everything properly you may actually pay attention to it when filling it out! It is especially important if you are putting your name with a date and time saying that you did make sure you installed the patch and then afterward made sure things were still secured properly.
It was very interesting to see some specifics covered in the problems noted by OCR. Of course, you know number one is that they “failed to conduct an accurate and thorough analysis of the potential risks and vulnerabilities to the ePHI”. As per usual, that is followed by “failed to implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level”.
The next two were the ones I was really interested in reviewing.
- CH failed to perform a technical evaluation in response to CH’s contractor installing Windows OS.
- CH failed to obtain satisfactory assurances from a particular contractor, in the form of a written business associate agreement, that the contractor would appropriately safeguard ePHI that the contractor maintained on behalf of CH.
That first point there is spot on with the title of this episode. There are your 3 million reasons you should be paying attention to what tech teams are doing even if they are your trusted MSP contractor. Also, if you are the MSP please pay attention right now! We ask for checks and balances because we know people make mistakes. We ask for documentation to make sure those human mistakes don’t get made. For those of you who have a great relationship with your trusted MSP, you should ask them about doing documentation to make sure you are covered for things like this. Trust but verify is all we are saying.
Ok, so the second one is what we just ranted about last week. But, this is different. It isn’t just how they didn’t have one in place it was that they didn’t have one in place AND the contractor screwed up royally. If you aren’t making sure these people know how important it is to do things like a checklist and proper testing and documentation maybe they really do not know what to do. Wow, what a scary thought! I could be letting someone who has no idea how to handle my systems getting full access to expose thousands of people in a matter of seconds!
We have gotten used to them saying the CAP is “robust”. But, this one is 3 years. Normally, they are 1 or 2 years. The terms are no different than the normal stressful report and approval cycles we normally see. But, being put on what we can basically see as 3-year probation means they got in real trouble.
We can only say it 3 million times with this settlement – audit and pay attention to what your tech staff is doing. You aren’t doing it because you don’t trust them. You are doing it because “I’m only human after all”. Yes, another 80s flashback this time from the Human League! Ahh, the fashion, the earrings, the hair there really was nothing like it. The tears I cry…