Where In The Cloud Is Your PHI?

Where In The Cloud Is Your PHI?

Storing Protected Health Information (“PHI”) in the cloud can be a very useful thing for covered entities and business associates.  As we know, HIPAA does permit storing PHI in the cloud if the cloud storage provider executes a Business Associate Agreement.  However, do you know exactly where that PHI is stored by the cloud provider?  In some instances the cloud storage vendor might store, backup, or process the PHI in an overseas location.  How do you protect the PHI, and yourself, in such a situation?

HIPAA does not specifically forbid storing PHI in an offshore location (some states do forbid storing Medicaid data offshore), but it does create challenges.  First, you must determine where your cloud vendors will be storing the information, and whether it will be offshore or not.  If it is offshore, you need to determine the specific location and what local rules might apply to the PHI. Local laws in the international jurisdiction where PHI might be stored might actually allow for access to the data that would be in violation of HIPAA.  The duty is on you, as you contract with the cloud provider, to determine if the security efforts are sufficient or if the location of the data will pose any risks. Furthermore, offshore cloud providers might not be bound by HIPAA, but you – presumably operating in the United States – are.  If your international cloud provider is at fault for a breach but cannot be held accountable, you might determined to be liable even if the only action you took was selecting the wrong vendor.

Without question, storing PHI offshore brings unique challenges. Whether they are worth it or not can only be answered by you. However, if you are considering a vendor that will store PHI internationally, be sure to conduct a risk assessment to ensure you are not putting PHI in increased or unnecessary risk.

Emergency Preparedness Best Practices

Emergency Preparedness Best Practices

In the wake of two damaging hurricanes, the topic of emergency preparedness is at the top of mind for many Covered Entities and Business Associates. The goal of emergency preparedness is to ensure electronic protected health information (ePHI) is secure, and the confidentiality, integrity, and availability of ePHI is not jeopardized both during and after an emergency.

Effective emergency preparedness consists of having a contingency plan which includes a data backup plan, disaster recovery plan, and emergency mode operation plan.  The disaster recovery plan ensures that you have accurate backups of the ePHI, while the disaster recover plan is how you recover from those backups.  The emergency mode operation plan outlines how ePHI will remain secured during the course of the emergency.  While not specifically required, your organization should consider testing your contingency plan and revise it as necessary.

When thinking about putting you plan together, you can follow a seven step process,

  1. Assess your situation;

  2. Identify risks;

  3. Formulate an action plan;

  4. Decide if and when to activate your plan;

  5. Communicate the plan;

  6. Test the plan; and

  7. Treat the plan as an evolving process.

While this process is linear, these steps can take considerable time to finalize.  If you don’t have a contingency plan in place now, you should begin the process to develop and implement one as soon as possible.

What To Do About Insecure Business Associates

What To Do About Insecure Business Associates

As a Covered Entity or a Business Associate, you know you need Business Associate Agreements with entities that perform a service or a function for you which requires access to Protected Health Information (“PHI”) to carry out (these are Business Associates or subcontractors).  A required element of Business Associate Agreements is that you will not transfer PHI to entities you know are not properly securing the PHI.  Therefore, what should be done in instances when you discover a Business Associate or subcontractor that is not adequately securing PHI?

The first step is see if the issue can be resolved, or to ‘cure.’ Send the Business Associate written communication putting them on notice that they have a specific time (i.e. 30 days) to correct the issue and secure the PHI, otherwise, the contract will terminate and the exchange will end.  The best case scenario is that they cure the issue within the specified time. If the issue is not corrected in time, then the contract can terminate and the exchange of PHI should end.  The only exception would be if termination is not feasible, for instance because there are no other viable options for the service.  In which case, you must notify the HHS Office for Civil Rights of the potential breach.

As the exchange of PHI becomes more prevalent and complex, the chain of trust on which the PHI is exchanged becomes increasingly important.  If one link within that chain is weak, it must be strengthened or removed.

Take The Gray Out Of HIPAA – Risk Analysis Will Help

Take The Gray Out Of HIPAA – Risk Analysis Will Help

Most people with even a casual understanding of HIPAA realize there is a great deal of gray area involved in the implementation of the Rule. This is another way of saying lawmakers intended to provide the regulators with flexibility in HIPAA enforcement. After all, this is a Rule that applies to everything from single doctor practices to multiple-site hospital systems. It is this flexibility – specifically regarding “addressable specifications” of the Security Rule – that makes HIPAA such an implementation nightmare. However, navigating the gray areas, and determining what is “reasonable and appropriate” for your organization is not as challenging as it may seem.

First, you must establish what you need to analyze to determine whether a safeguard is “reasonable and appropriate.” HIPAA provides the factors as follows,

  • The size, complexity and capabilities of the organization;

  • The technical infrastructure, hardware, and software capabilities;

  • The costs of the safeguards being considered; and

  • The probability and criticality of potential risks to PHI.

Once the criteria is established, the method of analysis must be determined. The Rule provides the answer to that as well, a Security Risk Analysis. This is a systematic approach to identifying and determining the likelihood of organizational risks and vulnerabilities. There are many of these available on the market, HHS even provides one free of charge. The two most important things to consider when completing a risk analysis is 1) ensure it covers your entire organization, and 2) ensure it is well documented.

Once you are equipped with the information from the risk analysis, you will understand the scope of your risks.
Based on your organization’s size, complexity, technical capabilities, and associated costs you will then be able to clearly determine what safeguards are required.

Guarding Against Insider Threats

Guarding Against Insider Threats

Last week Anthem began informing 18,000 customers of a breach. It stemmed from a vendor’s employee who emailed Anthem members’ data to a personal email account. The employee was fired and is being investigated by authorities. It raises an important point that insider threats pose a significant risk to Protected Health Information (“PHI”).  Here are a few keys to mitigating this risk,

  • Screen New Hires: One of the best prevention methods is to not hire someone who turns out to be a malicious employee in the first place. You may consider completing a background check on all new hires and even periodic checks on current staff members. While not an exact science, it may help to identify potential bad actors before they cause any damage;

  • Perform Regular Access Audits: Having a process in place to review logs of who within your organization is accessing PHI and what they are accessing can be a helpful tool in spotting a snooping employee. To truly be effective, the logs need to be reviewed on a consistent basis to identify an employee who is accessing PHI unnecessarily or to pick up suspicious patterns of access; and

  • Train Staff on Sanctions: Training should include information that outlines the sanctions that can be imposed (both by you, the employer, and the authorities) for malicious actions involving the access or disclosure of PHI.

Also, keep in mind what we discussed last week with the risk of terminated users. Reasonable procedures can mitigate the risk and prevent a costly and damaging breach from the inside.

Termination of User Access

Termination of User Access

Every covered entity and business associate, whether large or small, struggles with prompt termination of user access. Whether it be interns, temporary or permanent employees it is a common struggle to have HR communicate with IT that someone has left the organization or no longer need access to PHI.  This poses a high risk by having individuals who may no longer be with the organization still having access to PHI; some of whom may be disgruntled.  Here are a few tips to help mitigate the risk.

  1. Establish a consistent process for which IT is notified by HR when anyone leaves the organizations or changes job functions to no longer need access to PHI.  HR likely has a process it goes through when an employee leaves.  Work to include communicating to IT who is leaving and when.  Often times this can be done simply by submitting a ticket to whomever provisions access to systems with PHI.

  2. For temporary users (i.e. interns, volunteers, students, auditors, temporary staff), have HR provide you with a date when the user will be leaving.  If they don’t know the exact date, have them provide a “safe” date in which the user will no longer need access.  While not ideal, it will reduce the risk of having access for terminated users for an extended amount of time.

  3. Review access logs periodically to purge users who are no longer with the organization or have not logged in for an extended period of time (i.e. 3 months).  This can be a significant amount of data to review for larger organizations with many users, therefore a log review schedule should be implemented (i.e. once a month) to remove inactive users.

The most effective method is working closely with HR to know immediately when users leave.  However, reviewing logs and establishing access termination dates can also help in mitigating the overall risk.