In this article, I posted about the U.S. Department of Health & Human Services’ (HHS) HITECH breach website.  The website list all privacy breaches affecting 500 or more individuals.  I recently went to the website to take another look at the amount of breaches.  I was interested in the total number of individuals that have been affected due to privacy breaches.   I exported the information into Microsoft Excel and added up each of the individual privacy breaches to come up with a shocking 3,459,108 individuals that have been affected.

It should be noted that most of the breaches were due to electronic data security issues but some also involved improper disposal of paper records and theft of paper records.

As I mentioned in this post – we are seeing a lot of security breaches even before the majority of health organizations make the switch from paper records to EHR.  In order for HITECH to succeed, we need a strong emphasis on patient security right now!

I have been thinking and posting a lot about HIPAA security lately.   In the meantime Entegration has been involved in a large scale EHR implementation for one of our clients.  The combination of the two activities has allowed me to come up with a theory that is downright scary.  I don’t claim to be Nostradamus and I can’t see the future but I will throw out my theory anyway.  I believe that the ongoing EHR gold rush will put a lot of patient information in electronic form and place it in the hands of inexperienced employees that have not been trained on proper security precautions.  In addition, health organizations will think about security after the EHR implementation and not properly plan security prior to an EHR implementation.  Together these events will lead to a huge amount of security breaches that will compromise patient information and could potentially derail the effort to modernize our health information systems.

As part of the ARRA stimulus package many health organizations from hospitals to solo practices are pushing to implement EHRs to receive the full Medicare reimbursement per doctor.  There will be a big up-tick in the amount of health organizations that go from paper charts to electronic health records.  There will also be a big push to start using existing EHRs to comply with the “meaningful use” standards which will require more functions and modules to be turned on within existing EHRs.  In addition, more employees at health organizations will be required to utilize computers, tablets, laptops and other computing devices to perform their jobs.  Taking all of these events together will mean a lot more patient information will be in electronic form and a lot more people will have access to the electronic information.

Over the years Entegration has been involved in many EHR implementations.  There seems to be a common theme that I have noticed throughout all of these implementations and it is pretty consistent no matter who the EHR vendor is.  Employee training of the EHR is usually a quickly thrown together process where the EHR vendor sends a trainer onsite to teach a series of group classes on how to use the EHR.  These classes range from 1 hour to half of a day depending on the employee job function and responsibility.  After the class is over the employee is sent on their way to start using the EHR.  The training the employee receives is usually focused specifically on how to use the EHR, how to navigate screens, perform functions, etc.  Rarely have I seen training that includes a security overview that discusses protecting patient information on laptops, sending patient information via email or addresses password complexity, etc.

Furthermore, many health organizations that go from paper charts to EHRs also go from simple computer networks to much more complex networks that are required for the EHR.  In the process of implementing the EHR a large amount of computer equipment has to be purchased and installed including servers, desktops, tablets, printers, upgraded Internet connections and various other equipment.  Unfortunately most health organizations that go from paper charts to EHRs do not go through a formal security review prior to the implementation.  These organizations most likely will not concern themselves with the HIPAA Security Rule because before the EHR they don’t have a lot of electronic protected health information (EPHI).  So most likely the organization will have very few if any security policies and procedures. They will probably not go through a formal risk assessment and will not perform vulnerability scans on the newly created complex network.  Employees will not go through training sessions that discuss protecting newly formed EPHI.

What you will have is a lot of health organizations that start putting patient information into EHRs that are used by employees without proper security training.  You will have health organizations that have newly created complex networks without proper security policies and procedures.  These complex networks will not have the proper vulnerability assessments.  Employees will not be trained on best security practices that discuss protecting patient information on laptops and portable devices, they will not have training on sending EPHI via email, or the use of complex passwords.  The networks will not have the proper auditing in place that monitor the event logs to determine if there has been access to information by unauthorized personnel which could be internal employees or threats from external entities.  Data will most likely be backed up but full Disaster Recovery technologies and procedures will probably not be in place.

We have seen a large number of security breaches so far in 2010.  It seems like every week we hear about more and more patient information that has been compromised.  This is happening already even before the big push by a majority of health organizations to implement EHRs.  When all the forces come together will we see the flood gates open and patient information be compromised and data breaches occuring at an alarming rate?  If this does occur will patients lose trust in their doctors and the use of EHRs?  I don’t know the answers to these questions but if my theory is correct we will see a major occurrence of patient information data breaches that will put patient’s information in jeopardy and could potentially damage the effort to modernize our health information systems.

Breaches of patient data can be very expense as was pointed out in this article about BlueCross BlueShield of Tennessee.  So far the remediation costs of the data breach are up to $7 million.  So the big question is who pays for the remediation costs?  Many medical facilities have liability insurance and there are insurance policies that can be purchased to cover the cost of HIPAA violations.

There is a very interesting case involving the University of Utah, as noted in this Dark Reading article.

According to news reports, Colorado Casualty Insurance Co. last week asked a judge to rule that it is not liable to pay a $3.3 million claim filed by its client, Perpetual Storage, after a burglar stole backup tapes containing the personal records of 1.7 million University of Utah medical patients from a Perpetual employee’s car.

The request for a ruling is in response to a lawsuit filed in April by the University of Utah, which is seeking reimbursement from Perpetual Storage and its insurers for the $3.3 million it spent to remediate potential security problems caused by the theft of the backup tapes in 2008.

At issue is who should pay those $3.3 million remediation costs: the University of Utah, which owns the patient data; Perpetual Storage, which violated policy by leaving the university’s backup tapes in a car while in transit to a secure facility; or Perpetual Storage’s insurance company, which issued a policy to protect Perpetual from costs arising from a data breach.

The case is very interesting because the data breach was the result of a stolen backup tape from a Business Associates employee’s car.  The University of Utah wants to be reimbursed for the $3.3 million that it spent to remediate the data breach.  Perpetual Storage, the Business Associate, wants it insurer the  Colorado Casualty Insurance Co. to pay for the costs.  The Colorado Casualty Insurance Co. is asking the courts to rule that it is not liable to pay the $3.3 million.

The outcome of the case will may set standards for exactly who pays for remediation costs.  No matter what the outcome of the case is, now would be a good time to start discussing with your insurance provider what your liability insurance covers and what it doesn’t cover.  As you can see, data breaches can be very expensive and knowing what your coverage is and ensuring that your have the appropriate coverage is critical.  You don’t want to start having these conversations AFTER a data breach has occurred.

Cloud computing is all the rave right now.   It is the ability to run applications, store data and access the applications and data from any computer that is connected to the Internet.  Companies utilizing cloud computing can run applications without having to worry about servers, installing software or upgrading the applications.  Data backups are handled “in the cloud” and businesses do not have to perform daily data backups.  When you look at this model it has a lot of appeal.

A company running Google’s Gmail email service is a good example of how cloud computing works.  Google manages the server and network infrastructure that Gmail runs on.  They make changes and upgrades to the service and the users of the service see the changes without having to install new client or server software (this assumes that users of Gmail are accessing the service via a web browser).  Google adds additional server capacity without users knowing or caring about the network infrastructure.  Backups of data are handled by Google without any user intervention.  The Gmail service can be accessed by any computer, tablet,  and smartphone that has an Internet connection.

When you compare the Gmail model to the traditional Microsoft Exchange / Outlook model the differences are very apparent.  A company running Microsoft Exchange email would need to have a server(s) that runs the Microsoft Exchange software.  Every computer that accesses the Exchange server would need Microsoft Outlook installed.  The server would need to  be maintained and new security patches, service packs and software upgrades would need to be applied to the server.  Upgrades to the Outlook software would need to be installed on each of the client computers as well.  The Exchange server would need to be backed up at least nightly.  Eventually the server will become outdated and will need to be replaced with newer hardware.

The big difference between the Google Gmail model and the Microsoft Exchange model is that Google handles all of the backend administration.  The Microsoft Exchange model requires that companies, not Microsoft,  handle the backend server administration.  Companies either have to have the IT skill set or they need to outsource the function to another company.

Again you can see why the cloud computing model has its appeal.  When the cloud computing model works as it supposed to, it is very hard to choose the traditional in-house server and application model over the cloud computing model.   Companies love not having to maintain a network infrastructure or greatly simplifying their network infrastructure  and they love pushing all of those backend administration functions “into the cloud” and having someone else handle them.  There are many other aspects to consider when comparing the cloud computing model to the traditional in-house server / application model.  These aspects include security of the data, compliance issues, portability of the data to another vendor/application, etc.  For this article I will not go into those details.

Dark side of cloud computing

Let’s take a look at the other side of the equation regarding cloud computing.  Companies that rely on an application that is hosted in the cloud are helpless when the application is unavailable.  The same can be said about the tradition in-house server model but at least the company can have contingencies in place which may include additional servers, redundant infrastructure, etc.  When an application that is cloud based becomes unavailable companies that utilize the service can do nothing but sit and wait until the service is restored.

Entegration utilizes a cloud based service from Intuit call QuickBase.  QuickBase is an incredibly robust application development environment that is totally cloud based.  Intuit keeps adding additional features to the service and it keeps getting better and better.  Entegration has built a Help Desk support system using QuickBase.  All of our clients access the Help Desk application via a browser and run the application within the QuickBase cloud.  Even though we are an IT company, not having to purchase infrastructure and maintain the infrastructure was very appealing to us when we choose QuickBase.  Not having to worry about server capacity and the cost associated with adding capacity, as we grew, was also appealing.  There are probably at least 10 other reasons why going with QuickBase was the right decision but I will save those for another article.

Unfortunately yesterday Intuit suffered a major outage that affected some of their websites including the QuickBase service.  The service was down from around 10pm EST on Tuesday until around midnight on Wednesday.  This outage was almost 24 hours.  During the service outage, none of our clients could access our Help Desk system.  There was nothing we could do but sit helplessly and wait until the service was restored.  Luckily for us we have alternative methods for our clients to contact us including email and phone options.

To us, our Help Desk system is an important  application.  Our clients use the application to interface with us and we have built our workflow around the application.  But as I mentioned we have contingencies in the event the Help Desk system is unavailable.  But it gets you thinking about other cloud based services and the impact of outages.

• What if your EHR / EMR is cloud based and you couldn’t access patient information for 24 hours?
• What if your Email is cloud based and you couldn’t access it for 24 hours?
• What if your Accounting system is cloud based and you needed to print pay checks but the service was unavailable for 24 hours?

Intuit is a major technology company with many products and a sophisticated network infrastructure.  This is not a small vendor that has few customers.  If a major cloud based outage can happen to Intuit, it can happen to any vendor / company.  Intuit has the personnel and knowledge required to bring the service back online.  I would venture to guess that they will learn from this event and add additional redundancies and take steps to prevent this from occurring again.   But some questions to ask are; What if a major outage happened to a smaller vendor?  What if a smaller EHR / EMR vendor had a major outage?  Would the outage last more than 24 hours?  Would they have the resources to quickly bring the service back online?

The QuickBase outage reminds us of the dangers of cloud computing.  Cloud computing has its appeals but also has its risks.  When making a decision on an application and trying to decide whether it is best to run the application in-house or go with a cloud based solution, keep the QuickBase case in mind.

In this article I discussed that the Office for Civil Rights (OCR) is getting ready to begin HIPAA Security Audits. The audits should begin by the end of this year.  In an interview with Susan McAndrew, OCR’s deputy director for privacy, she mentions the importance of performing a Risk Assessment.

OCR has published a paper called:

HIPAA Security Standards: Guidance on Risk Analysis

Below are some highlights from the paper.

We begin the series with the risk analysis requirement in § 164.308(a)(1)(ii)(A). Conducting a risk analysis is the first step in identifying and implementing safeguards that comply with and carry out the standards and implementation specifications in the Security Rule. Therefore, a risk analysis is foundational, and must be understood in detail before OCR can issue meaningful guidance that specifically addresses safeguards and technologies that will best protect electronic health information.

All e-PHI created, received, maintained or transmitted by an organization is subject to the Security Rule. The Security Rule requires entities to evaluate risks and vulnerabilities in their environments and to implement reasonable and appropriate security measures to protect against reasonably anticipated threats or hazards to the security or integrity of e-PHI. Risk analysis is the first step in that process.

The following questions adapted from NIST Special Publication (SP) 800-665 are examples organizations could consider as part of a risk analysis. These sample questions are not prescriptive and merely identify issues an organization may wish to consider in implementing the Security Rule:

• Have you identified the e-PHI within your organization? This includes e-PHI that you create, receive, maintain or transmit.
• What are the external sources of e-PHI? For example, do vendors or consultants create, receive, maintain or transmit e-PHI?
• What are the human, natural, and environmental threats to information systems that contain e-PHI?

Organizations should use the information gleaned from their risk analysis as they, for example:

• Design appropriate personnel screening processes. (45 C.F.R. §164.308(a)(3)(ii)(B).)
• Identify what data to backup and how. (45 C.F.R. § 164.308(a)(7)(ii)(A).)
• Decide whether and how to use encryption. (45 C.F.R. §§ 164.312(a)(2)(iv) and (e)(2)(ii).)
• Address what data must be authenticated in particular situations to protect data integrity. (45 C.F.R. § 164.312(c)(2).)
• Determine the appropriate manner of protecting health information transmissions. (45 C.F.R. § 164.312(e)(1).)

I encourage you to read the full paper to get a good overview of how OCR believes a Risk Assessment should be conducted.

Many years ago Entegration would respond to support calls and fix problems when they occurred.  The use of remote tools and the ability to do preventative maintenance was not mature.  Occasionally we would send a tech to a client’s office and have them do some system maintenance which included making sure backups were occurring, checking for hardware errors, applying any outstanding Microsoft Service Packs, etc.  Keep in mind that these were the days before software vendors released regularly scheduled security patches and program updates.

Unfortunately the old model which is referred to as “break / fix” led to a lot of frustration from a client perspective and from our perspective.  The reason it is called break / fix is because a client would report a problem (break) and we would repair the problem (fix).  Over time some of the same problems would occur over and over.  A client would get frustrated having to report the same problem over and over and we would be frustrated having to fix the same problem over and over.  Unfortunately at times we were not able to stay ahead of problems.

In the past few years significant changes have occurred that allowed us to move away from a break / fix model.  The first significant change was the use of remote administration tools.  All of our clients now have Internet connections.  We now can leverage the Internet to remotely and securely access our client’s networks without having to be at their office.  The second significant change was that software vendors started to release regularly scheduled software patches.  These patches fix security holes and/or program bugs.   For example, on the second Tuesday of each month Microsoft releases a set of patches that fix security holes or program bugs in certain operating systems (i.e. Windows XP, 2003 Server) or applications (MS Word, Excel, Access, etc.).

Now for every client that we support we provide preventative system maintenance.  We now use automated tools to let us know the health of a client’s network.  We know if a client’s servers are up or down or if their Internet connection has failed.  We receive notifications when data backups fail or when a virus outbreak occurs.  We work with system tools to push out vendor patches / updates on desktops, laptops, tablets and servers.  We now perform test restores of data to ensure that the backups are valid.  We can do all the preventative system maintenance without ever going to a client’s office.

The change from break / fix to preventative system maintenance had a real and positive effect.  The amount of support calls / tickets that we received from clients went down significantly.  I don’t have the exact numbers but I would guess that support calls decreased by 50% over time.  A client network that is regularly patched with operating system and application updates is much more stable and reliable.  This has a positive affect on our clients and the use of our techs.  Our clients are happy because they have a network that is much more dependable and reliable.  There is much less time and money being spent on annoying problems.  Clients can focus on implementing advanced services that make them more efficient.  From our perspective with less support calls we can take on more clients without having to hire more techs.  Preventative system maintenance has produced stable and reliable networks that don’t need as much support from us.

As a practice moves from paper charts and simple networks to full EHR / EMR implementations with complex networks, it is essential to move to a preventative system maintenance model.  Break / fix is not an option as you implement more and more network equipment.  Complex networks need to be patched at the operating system level (Windows XP, Windows 7, Windows 2003 and 2008 Server), the system application level (MS SQL, Exchange, etc) and at the desktop application level (MS Office, Adobe Acrobat, EMR client software, etc.).  As you are looking into implementing and EHR / EMR, conversations with your IT vendor should be occurring on how the network will be supported.  If you have already implemented an EHR / EMR your vendor should be doing preventative maintenance on your network.  In addition to ensuring that a network is stable and reliable, networks that are kept up to date are much more secure as I pointed out in this article.  My last thoughts on this is if you want your practice to run as smooth as possible and to make the most out of your EHR / EMR, moving to a preventative system maintenance model is a requirement.

There are many things that you can do to protect patient information.  You can put in place security policies and procedures, ensure that you do a thorough risk assessment, implement data encryption, educate your staff, etc.  But sometimes nothing you can do can prevent a data breach from occurring.

As reported here, a laptop used by a hospice employee was stolen while in use at a patients house.  The laptop was encrypted which normally would be a safe harbor and would exclude the need to notify patients of the data breach.  In this case the laptop was already turned on and in use so that the data encryption key/password had already been entered and thus the information on the laptop could be accessed.  In other words, because the employee logged in with the correct password all the data on the laptop was unencrypted.  As long as the laptop remained powered on and in use, the data could be accessed without the need for the encryption password.  Once powered off, the laptop would then require the correct encryption password to access the information.

Rainbow Hospice and Palliative Care notified patients because the laptop contained  patient names, addresses, social security numbers, insurance information, medications, treatments and diagnoses. 

I would guess that Rainbow Hospice and Palliative Care had security policies and procedures in place.  They had already gone through the effort of ensuring that the laptop was encrypted.  They had to have trained the employee on how to access the encrypted information and probably went over best security practices to protect their patient’s information.  With all these efforts they still face a data breach. 

In no way should anyone read this and think that implementing security is a waste of time and effort.  Taking the steps to protect patient information is the right thing to do and it will go a long way to protect and prevent you from facing a data breach.  But sometimes no matter what you do, you could still face the negative consequences of a data breach.

The HITECH Act has shifted the responsible for enforcing the HIPAA Security rule from the Centers for Medicare & Medicaid Services (CMS) to Office for Civil Rights (OCR) which is a part of the Department of Health and Human Services.  OCR has been enforcing the HIPAA Privacy Rule since 2003.  OCR has been gearing up to start HIPAA Security Rule enforcement.  They are working with the consulting company Booz Allen Hamilton to determine the model they are going to be using and how fast they can implement the model.

Susan McAndrew, OCR’s deputy director for privacy said in an interview with HealthcareInfoSecurity.com that:

The audits likely will be outsourced and not conducted by OCR staff.

Security audits will check that organizations have completed a risk assessment and implemented appropriate administrative, technical and physical safeguards.

Audits for compliance with the privacy rule will focus on organizations’ efforts to uphold individuals’ rights, such as their right to access their own medical records.

It seems clear that a major part of any HIPAA Security Audit will be based on how a practice conducted their risk assessment.  As I mentioned in this article, I believe the Risk Assessment is at the core of the HIPAA Security Rule.

McAndrews also mentions the importance of using encryption technology on mobile devices.  She goes on to say:

I am continually surprised by the fact that you actually have to lose your laptop before the light bulb goes on and you say, “Gee, maybe I need an encryption policy here.” You know, you are a lot better off if you can learn from your neighbor. Don’t let it happen to you; encrypt those things now and don’t wait until they are lost to suddenly decide, “Gosh that’s probably a good idea.” And the other lesson I hope people learn is that it is not good enough just to have the policy or to have that light bulb go on. Once you have established that as your policy, you really have to make sure that you train people and it is part of your culture to ensure that encryption happens because, two weeks after you issue the e-mail saying this is what you have to do, life takes over and people think it is too much trouble or they have to go see an IT person and they don’t have time and they walk out the door without getting their laptop encrypted and bad things happen. So it is to have a good policy and enforce that policy so that we don’t have to enforce that policy.

Susan McAndrews give some good insights into what is going to occur with HIPAA Security Audits.  The audits will most likely begin by the end of the year.  They will most likely be outsourced and will not be handled by OCR personnel.  A major focus of the HIPAA Security Audit will be based on a Risk Assessment and how a practice implements the Administrative, Technical and Physical safeguards.  In addition, her advice is to start using encryption on all mobile devices.

The writing is now on the wall.  Now is the time to start thinking about HIPPA security.  It does not matter what phase you are in regarding electronic personal health information (EPHI).  If you are researching EMRs a major concern should be on how the EMR fits into your overall security strategy.  If you have already implemented an EMR then you should make sure that you have completed your risk assessment and that you have implemented the steps required to protect your EPHI.

Update:  OCR has published a paper with guidelines to performing a Risk Analysis.