This tip is a part of SearchCloudSecurity.com’s mini learning guide, HIPAA cloud computing advice: Ensuring cloud...
In health care, when it comes to security, it’s always been about securing patient data. Protected health information (PHI) is something health care providers are all too familiar with -- diagnostic information, images, medical records, or other data explicitly covered under the HIPAA Security Rule have always been a source of concern from a security perspective.
But, complexities arise when you introduce cloud computing into the mix, particularly public cloud. For example, what happens when organizations discover after the fact that live PHI has already been located to a public cloud provider without the involvement of the security team? This may sound like a nightmare scenario, but you’d be surprised how often it happens. Moving to the cloud securely requires planning and foresight, but -- let’s face it -- security isn’t always the first group involved in every aspect of strategic planning.
So what do organizations in this boat do? Fortunately, there are a few strategies for maintaining compliance with HIPAA security requirements should this situation occur.
Locate the PHI
The first step is to identify and locate where PHI is and on what system components, applications, or hosts the data resides. In industries outside of health care, a data inventory of this type can be an enormously expensive and time consuming undertaking, potentially involving specialized discovery tools like those offered in the data loss prevention (DLP) space. Fortunately though, health care providers can leverage existing documentation to help in this area: interface maps and business impact assessment documentation.
Most medium to large health care providers (e.g., hospitals, health systems, and some larger clinics) use a large number of specialized applications, such as electronic medical record (EMR) systems, picture archiving and communication systems (PACS), pharmacy systems and lab systems. These systems often number in the hundreds, so keeping track of how they interact is understandably important. Because of this, most organizations have interface maps that visually or logically represent communication pathways (usually using the health care-centric HL7 protocol) between applications, often by using tools like Visio or MindManager. What’s useful about this for discovery purposes is that much of this communication contains PHI; for example, admit, discharge and transfer (ADT) information. So, when syste ms or applications move outside the organizational boundary, using these maps to track flows of PHI can give us critical data about which systems are likely to contain it.
If you don’t have interface maps of this type, your business impact assessment (BIA) can also be a good source of data for this purpose instead. HIPAA security requirements specify an “application and data criticality analysis” [§ 164.308(a)(7)(ii)(E)], which many organizations have interpreted as a business impact analysis, such as you would find in traditional business continuity planning. The business impact assessment process identifies dependencies between components and applications; if one application contains PHI, and it in turn depends on another as a data source or as part of a broader workflow, chances are good the dependent application also contains PHI.
Develop an action plan for HIPAA compliance
Assuming you know (or can deduce/discover) which system components containing PHI have been migrated outside of your environment, the next step is to determine whether you are currently in compliance with HIPAA security requirements in the cloud environment(s). This starts with a gap analysis. Take careful stock of the vendor’s environment to determine whether they’ve addressed the specific standards and implementation specifications required by HIPAA.
A good starting point is to inquire of your cloud provider directly what controls they have implemented. Frame the request in a way that it is unambiguous to which controls you are asking about; for example, use a point-by-point matrix that specifically calls out each HIPAA requirement and uses the verbiage of that requirement in asking how the provider addresses it. Providers that service the health care community frequently will understand the purpose of your request and most likely will be responsive.
Secondly, look at the reporting capabilities that your cloud provider has given you and have your compliance officer to evaluate their sufficiency. Reporting and auditing have always been pain points (even for environments hosted on premises), so some extra planning and diligence in this area is beneficial, particularly in the case of cloud computing where log data may need to be brokered through your cloud provider in order for you to access it.
Throughout both of these exercises, investigate internally to determine whether or not you have signed a business associate agreement (BAA) with the cloud provider(s) in question. Remember that under HITECH, business associates are required to conform to the HIPAA Security Rule the same way you are (see, for example, the notice of proposed rulemaking on this point from HHS). So your vendor’s attestation (via the BAA) that they are a business associate gives you quite a bit of leverage in asking for changes later on down the road when/if you discover they are deficient in a particular area. It’s much easier to build a case for why they need to make changes if you can point out that they are arguably in violation of the law by not doing so.
Documentation and technology options
As you locate problem areas, make formal requests of your provider in writing asking for improvements in the areas that you view as problematic. Having a paper trail that documents your request as well as the vendor response demonstrates diligence on your part and also can serve as leverage when your contract with that vendor comes up for renewal.
If you run into a situation where you just can’t meet a particular requirement and the vendor can’t/won’t accommodate a change to support your needs, look for technical options that you can implement without vendor involvement. For example, remember that certified EHR vendors are required to provide certain security capabilities per the EHR certification criteria; technologies like encryption [§170.302(u)] and audit logging [§170.302(r)] might be available to you in certain situations depending on what the component is.
Finding out after the fact that PHI data has moved outside of your scope of control sounds scary, and is arguably a less desirable path than if security had been involved during the planning process, but it’s not the end of the world.
About the author:
Ed Moyle is a senior security strategist with Savvis as well as a founding partner of Security Curve.