HIPAA Security Rule, Computers, and Administrative Safeguards

It’s been almost 27 years since the Health Insurance Portability and Accountability Act of 1996 was passed by Congress. And it’s been almost 20 years since the initial adoption of the Security Standards for the Protection of Electronic Protected Health Information, also known as the HIPAA Security Rule. The HIPAA Security Rule operationalizes some of the provisions of the HIPAA law. We are now 18 years past the date of compliance for most covered entities, April 20, 2005. And it has been 10 years since the final changes to the Security Rule required by the HITECH Act of 2010. With the widespread adoption of electronic health records, it seems like a good time to review the requirements of the HIPAA Security Rule on sensitive patient data. In this post, we will specifically look at the portion of the Security Rule that covers Administrative Safeguards.

In this Article …

• Who is covered by the HIPAA Security Rule?
• What is the difference between the HIPAA Privacy Rule and the HIPAA Security Rule?
• Are Covered Entities required to meet all of the HIPAA Security Rule specifications?
• HIPAA Security Rule Categories
• What are the HIPAA Security Rule Administrative Safeguards?

Who is covered by the HIPAA Security Rule?

Covered entities generally fall into three categories:

• Covered Healthcare providers who provide medical or other healthcare services or supplies, and who transmit any health information in electronic form in connection with a transaction for which the US Department of Health and Human Services (HHS) has adopted a standard. While there are still a few healthcare organizations that do not transmit claims electronically, effectively, the Security Rule covers the vast majority of healthcare providers these days.
• Health Plans – any individual or group that provides or pays the cost of healthcare. These include health insurance companies, health maintenance organizations (HMOs), and government healthcare programs like Medicare and Medicaid.
• Healthcare clearinghouses: public or private entities that process another entity’s healthcare transactions from a standard format to a non-standard format, or vice-versa. The main transactions processed by healthcare clearinghouses are claims by providers re-transmitted to health insurance payers and information on payments sent by insurance companies to providers.
• Business associates who receive or process electronic protected health information are also covered by the HIPAA Privacy and Security rules.

What is the difference between the HIPAA Privacy Rule and the HIPAA Security Rule?

The HIPAA Privacy Rule applies to all forms of patient’s protected health information (PHI), whether electronic, written, or oral. The HIPAA Security Rule applies only to PHI that is in electronic form (ePHI), when it is created, received, maintained, or transmitted.

The HIPAA Privacy Rule requires that covered entities reasonably safeguard PHI using administrative, technical, and physical safeguards to protect the privacy of PHI. Covered entities must also reasonably limit incidental uses or disclosures made pursuant to an otherwise permitted or required use or disclosure. The HIPAA Security Rule specifies much more comprehensive security measures for securing patient data.

Are Covered Entities required to meet all of the HIPAA Security Rule specifications?

The Security Rule includes implementation specifications (or standards) that are both required and addressable. Covered entities must have policies and procedures specifying how the entity will implement all of the required specifications.

Covered entities must also assess each “addressable” specification. They must implement these specifications if it is reasonable and appropriate. If they decide implementation is not reasonable and appropriate, they must document the rationale for their decision. Furthermore, a covered entity must implement an alternative equivalent measure. If no alternative is reasonable or appropriate, a covered entity can consider its risks of unauthorized disclosures and the cost of implementation.

Ultimately, “addressable” does not mean optional. And in most covered entities of any size, all of the standards of the Security Rule should be reflected in policies and procedures. Hackers and other bad actors will eventually find a way to invade or compromise your electronic health information technology if you decide to just chance it.

HIPAA Security Rule Categories

The HIPAA Security Rule standards fall into three major categories:

• Administrative safeguards, including administrative functions that should be implemented to meet the security rule standards.
• Physical safeguards, including mechanisms to protect ePHI from threats, environmental hazards, and unauthorized intrusion.
• Technical safeguards, including automated processes to protect patient data and control access to patient data.

What are the HIPAA Security Rule Administrative Safeguards?

There are nine major categories of Administrative Safeguards. These safeguards contain 10 required implementation specifications, and 11 addressable implementation specifications.

• A security management process. This first standard actually includes four required implementation specifications:
  • A security risk analysis. This standard of the Security Rule is often found to have been overlooked whenever the Office for Civil Rights (OCR) at Health and Human Services, which enforces the HIPAA Privacy and Security Rules comes to investigate a breach at a covered entity. A risk assessment will help your organization identify potential threats to, and vulnerabilities of, information systems and their associated security risks.
    • An important component of a risk analysis is an inventory of all systems that contain ePHI.
    • Threats can be classified in three ways. Natural threats include things like floods and tornadoes. Human threats include intentional and unintentional actions. Intentional threats include actions like malicious software upload or other computer-based attacks. Unintentional actions include inadvertent or inaccurate data entry.
    • Risks of threats can be described as Low, Medium, or High. For instance, a covered entity with ePHI maintained in a facility located in a flood plain may categorize the threat of flood as medium. Most human threats may be categorized as low, but the risk of inaccurate data entry is probably always at least medium.
    • Keep in mind that a security rule risk analysis is not a one-time activity. As systems containing ePHI change over time, risk analysis should be updated for potential new threats and risks.
  • Risk Management. The second implementation specification is risk management. Risk management is the process used to identify security measures to reduce risk. It is not necessary to reduce risk to zero, but you must reduce risk to a reasonable and appropriate level based on your organization’s circumstances. Circumstances include things like the size, complexity, and capabilities of the organization.
  • Sanction Policy. The third implementation specification is having a sanction policy.
    • HIPAA compliance is not a “no harm, no foul” activity. For example, a staff member looks at the electronic protected health information of a neighbor, but has no business reason to access the information, and does not share it with anyone else or print out a copy to keep. An analysis of the risk of this unauthorized disclosure concludes the risk to the patient is low, so the unauthorized disclosure does not have to be reported to the patient or to HHS. This does not mean the staff member did nothing wrong and should not face sanctions for violating the minimum necessary standard for accessing ePHI.
    • Sanction policies and procedures should provide examples of potential violations of HIPAA privacy and security rules, and should adjust the disciplinary action based on the severity of the violation. For example, falsifying medical record entries is a termination offense, as is using PHI for personal gain. The offense in the last paragraph should result in at least counseling and some re-education on HIPAA.
  • Information System Activity Review. Covered entities must implement procedures to review records of information access management. These records include audit logs, access reports, and security incident tracking reports. Policies and procedures should address the type and frequency of review.
• Assigned Security Responsibility. The second Administrative Safeguard standard is the Assigned Security Responsibility standard. Each covered entity is required to identify a security official who is responsible for developing and implementing Security Rule policies and procedures. Of course, other staff members may be assigned duties as information security personnel, but the assignment of the duties of the Security Official to one individual must be documented in writing. An organization’s security official can also function as the Privacy Official required by the Privacy Rule.
• Workforce Security. The third Administrative Safeguard standard is Workforce Security. All members of a covered entity’s workforce that need access to ePHI must be identified, along with the information systems applications to which they need access. The procedures must ensure that only authorized personnel have access to ePHI, and that access is limited to the minimum necessary required for a workforce member to do his or her job. Workforce members include anyone who has access to ePHI, whether they are employees, volunteers, or contracted personnel. There are three addressable implementation specifications under the Workforce Security standard. Covered entities must explain why they choose not to implement policies to address these standards.
  • Authorization and/or Supervision. Covered entities are required to consider access control policies and procedures that provide for the authorization and/or supervision of workforce members who work with ePHI. For instance, in a small covered entity, it may be acceptable to grant access to all workforce members. In larger organizations, it is possible to differentiate roles and access among workforce members.
  • Workforce Clearance Procedure. When a covered entity has chosen to not address the Authorization and/or Supervision standard, it should consider procedures to ensure all workforce members with access to ePHI are authorized to have that access.
  • Termination Procedures. A Covered entity must implement procedures to remove access privileges when a workforce member no longer needs access. This could include situations where a person changes duties, voluntarily leaves the organization, or is terminated involuntarily. The lack of effective termination procedures has resulted in security breaches at many covered entities.
• Information Access Management. The fourth Administrative Safeguard standard is Information Access Management. This standard complements the Workforce Security standard. The Workforce Security standard focuses on identifying workforce members who need access to PHI based on their role in the organization. Information Access Management focuses on authorization and technical processes for granting access to workforce members. There are three addressable implementation specifications under this standard.
  • Isolating Health Care Clearinghouse Functions. This standard requires healthcare clearinghouses that are part of a larger organization to implement policies and procedures that protect ePHI from the other functions of the larger organization. For example, consider a large corporation with multiple lines of business, one of which is a healthcare clearinghouse. The clearinghouse maintaining ePHI must use security measures to keep that information secure from persons who perform duties in other business units of the corporation.
  • Access Authorization. This standard requires covered entities to implement policies and procedures for granting access to ePHI by means of specific methods. These might include access via workstations, or by means of access to specific programs. The standard also requires covered entities to have policies and procedures detailing the authorization process.
  • Access Establishment and Modification. This standard requires a covered entity to implement and manage the creation and modification of access privileges to workstations or programs.
• Security Awareness Training. The fifth major Administrative Safeguard is Security Awareness Training. This standard requires each covered entity to implement a security awareness and training program for all members of the workforce, including management. Training should be required for all new members with periodic retraining. This standard has four addressable implementation specifications.
  • Security Reminders. This implementation specification requires periodic security updates. A covered entity can use a wide range of techniques to meet this standard, from discussions at staff meetings to formal retraining on security rule policies and procedures.
  • Protection from Malicious Software. This implementation specification requires procedures for guarding against, detecting, and reporting malicious software. Since malicious software is often introduced via email attachments, workforce security training must emphasize avoiding this hazard.
  • Log-in Monitoring. Another component of security awareness training is managing attempts to log in or other mechanisms for accessing electronic protected health information. Multiple log-in attempts can represent outside attacks or poor attention to detail on the part of workforce members.
  • Password Management. A covered entity should have procedures for creating, changing, and safeguarding passwords. Security measures should include not sharing passwords and not leaving written passwords in areas that are visible to others.
• Security Incident Procedures. A sixth major Administrative Safeguard involves security incident Procedures. This implementation specification for this standard requires each covered entity to react to “security incidents”. These are defined as the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system. Each covered entity should identify and respond to suspected or known security incidents. They should mitigate harmful effects and document the incidents and their outcomes.
• Contingency Plan. A seventh major Administrative Safeguard involves having a contingency plan. There are five implementation specifications under this standard. Data Backup Plan, Disaster Recovery Plan, and Emergency Mode Operation Plan are required implementation specifications. Testing and Revision Procedures and Application and Data Criticality Analysis are addressable.
  • Data Backup Plan. This implementation specification requires a covered entity to establish and implement procedures to create and maintain exact copies of electronic protected health information. Data backup plans should address all systems that contain not only ePHI, but also electronic records such as patient account information and digital images.
  • Disaster Recovery Plan. Having backups is great, but there also has to be a plan on how to restore the information. This element of data security should address the data to be restored and copies should be available at more than one location.
  • Emergency Mode Operations Plan. A covered entity must incorporate plans to operate in an emergency into its written security policies. These internal security regulations should address alternative security measures to protect patient data during emergency operations. Emergency access procedures and telephone numbers/contact information available at multiple sites are also important elements.
  • Testing and Revision Procedures. It is important to document all processes for restoring patient health information from backups, disaster recovery, and emergency mode operations. Then it is time to test restoring patient data from your backup system.
  • Application and Data Criticality Analysis. Each covered entity should identify software applications that are important to patient care or business needs. The applications should then be prioritized for restoration as part of recovery from a disaster affecting health information technology.
• Evaluation. An eighth major Administrative Safeguard is Evaluation. This standard requires covered entities to periodically conduct a technical and nontechnical evaluation of their policies and procedures to ensure they are effective given any changes in the environment or operations that affect the security of ePHI.
• Business Associate Contracts. The ninth standard under Administrative Safeguards is contracts with business associates. A covered entity must obtain satisfactory assurances from any business associate with whom it will share ePHI. Under an update to the Security Rule, business associate obligations are essentially the same as the obligations of covered entities. Business associates must implement the same administrative, physical, and technical safeguards as covered entities. A written contract is required under the implementation standard, but even without a written agreement, any organization functioning as a business associate is responsible for HIPAA compliance.

To find more information on HIPAA security measures, visit our posts on the related physical safeguards and technical safeguards. Collectively you will gain a well-rounded understanding of the requirements coupled with actionable insights.