Update 10/27/2013: You can read part 2 of this series here
Physical Safeguards are a set of rules and guidelines outlined in the HIPAA Security Rule that focus on the physical access to Protected Health Information (PHI). In contrast, Administrative Safeguards focus on policy and procedures, while Technical Safeguards focus on data protection.
When we think about PHI, we typically think about the digital form of PHI: database records, PDF patient files, and MRI scan images. The Physical Safeguards are included in the Security Rule to establish how the physical mediums storing the PHI are safeguarded.
There are four standards in the Physical Safeguards: Facility Access Controls, Workstation Use, Workstation Security and Devices and Media Controls. We will explore the Facility Access Controls standard in this blog post.
The first standard of the Physical Safeguards is Facility Access Controls which outlines policies and procedures you must put in place to properly authenticate and authorize access to places where your PHI data is housed. In today’s world, this means putting proper procedures in place to ensure that only essential and authorized personnel have access to your data center and your server closet where your PHI data is housed. The Facility Access Controls standard has four addressable implementation specifications. Your entity must implement these four specifications but since they are marked as addressable, it is up to your entity to decide what is reasonable and appropriate and still accomplish the goals of each implementation specification.
The first implementation specification in the Facility Access Controls standards is called Contingency Operations. In short, you should have a plan in place that ensures in an emergency, the right people have access to where your PHI data is physically housed. For the most of us, this means putting a plan together so in an emergency or a data center outage, we can access and retrieve our PHI data or a backup copy of our PHI data. In your plan, you also need to make sure you have a way to restore the data elsewhere if needed. The data restoration step is typically part of a disaster recovery plan. For example, if the data center housing your application loses power, you need to be able to restore or bring up your application in a second data center. The rationale for this implementation specification is pretty straight forward. It ensures even in an emergency or an outage, access to a patient’s PHI is uninterrupted. Just because a computer system is down, doctors still need access to patient records in a timely manor.
The second implementation specification is called the Facility Security Plan. As the name implies, your entity needs to implement policies and procedures to properly secure and protect the physical facility where your PHI data is housed. Your entity should establish plans to reasonably and appropriately prevent unauthorized physical access, tampering, and theft of your PHI data. As an addressable implementation specification, your entity needs to decide what is the appropriate security and protection measure to put in place. Whether you have an on-premise server room or you host your application in a shared data center, it is your responsibility to ensure your facility is properly protected. The protection you deploy will depend on many factors, such as the size of your entity and the type of entity. Protection measures could range from making sure that your server room is locked, to adding a digital keypad to the section of the building where your server room is located, to hiring a private security company to patrol your facility. What’s important is that you have a plan in place, and that the plan is continuously tested and verified. It’s easy to set up a plan and then forget about it. Get in the habit of rotating keypad combinations, reviewing your facility’s surveillance footage, and reminding your employees to report any unknown personnel. Better yet, have a monthly penetration test where you have someone try to beat the security and protection measures that you’ve put in place. If loopholes are found, then review what happened and implement the steps necessary to plug the holes in your policies and procedures.
The third implementation specification is called Access Control and Validation Procedures. This specification calls for you to put procedures in place to ensure that the people accessing the facility where you house your PHI are indeed who they say they are, and that their access to PHI is in accordance with his or her role in the organization. If someone shows up at the place where you house your PHI claiming to be a computer server technician dispatched to replace a faulty hard drive, then the procedures you establish must ensure that you are not handing over your PHI data to any unauthorized persons. There are many procedures you can put in place that do an inadequate job of verifying the identity of people requesting access to PHI. In the above example, don’t just take the technician’s word for it that he works for Company X. Call Company X to double check that the technician is indeed an employee. Make sure a visitor request is logged by an employee before the visit to ensure the technician’s visit is legitimate. Make sure the technician is given a visitor’s badge, and that it is company policy to challenge anyone wondering the hallway without a proper visitor’s badge. Most importantly, log everything that is brought in and taken out during the visit. Sound like the procedures that you might find in a prison...well, you don’t want any PHI data to escape do you?
The fourth and final implementation specification in the Facility Access Controls standards calls for your entity to implement procedures to document any modifications to the facility where you house your PHI data that may affect the facility’s security. The procedures you put in place should document any additions, changes, removals and repairs to the physical facility housing your PHI data. Common items logged may include: replacing a broken digital keypad, upgrading your entity’s video surveillance system, rekeying server room keys and even the reissue of a security badge to an authorized personnel. It is also important to determine in the procedures the types of activities that should be documented. This will ensure that your documentation is consistent and complete.
So far we have covered all four implementation specifications in the Facility Access Controls standard. We will cover the remaining three standards in the Physical Safeguards in our next blog post.
As always, we would like to hear from you. Would you like to share what your Facility Access Controls implementation experience? Did we miss to mention an important point? Feel free to email us at blog@truevault.com.