The series so far:

1. Introduction to HIPAA and SOX — Part 1
2. HIPAA and Database Administration — Part 2
3. SOX and Database Administration — Part 3
4. SQL Server Auditing for HIPAA and SOX — Part 4

In the first article in this series, I introduced you to the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and the Sarbanes-Oxley Act of 2002 (SOX). The article provided an overview of each standard and some of their more relevant requirements. In this article, I focus exclusively on HIPAA and what database administrators (DBAs) need to know if managing and securing electronic protected health information (PHI).

The HIPAA regulations comprise a set of rules that define a covered entity’s obligations for protecting PHI data. The Privacy Rule and Security Rule are the most relevant to organizations handling patient data in electronic form. However, a covered entity should understand all HIPAA rules inside and out—a point I can’t emphasize enough.

A covered entity is a health care provider, health plan, or health care clearinghouse that handles confidential patient data. The HIPAA rules also apply to business associates of the covered entity if they also handle PHI data.

To comply with the HIPAA regulations, DBAs must ensure the confidentiality, integrity, and availability of all electronic PHI data in their charge, whether the data is sitting at rest in their databases or being accessed across the network by users or applications. The DBA must prevent unauthorized individuals from viewing, altering, or destroying the data, while providing authorized users with the access they need when they need it, without giving them any more access than required. The DBA must also identify and protect against anticipated threats as well as impermissible uses or disclosures.

Although the HIPAA regulations are quite explicit about an organization’s responsibility to safeguard PHI, they leave it up to the individual organization to determine the best way to protect the data. That said, the regulations do state that, when formulating a plan, the organization should consider its own size, complexity, capabilities, and current infrastructure, along with the costs of implementing security measures and the likelihood that the PHI is at risk.

Complying with the HIPAA regulations is an organization-wide effort, and database teams need to work with other teams to ensure that all aspects of the HIPAA rules are being addressed. As part of that effort, DBAs can take a number of steps to protect the PHI data stored in their databases and to make certain that no database-related operations put patient data at risk.

Educating and Training the Workforce

Section 164.530 of the Privacy Rule includes a number of subsections that describe a covered entity’s obligation to develop a set of written policies and procedures that outline how the organization will ensure HIPAA compliance. In addition, the section states that the covered entity must designate a privacy official responsible for developing and implementing the policies and procedures as well as a contact person or office responsible for receiving complaints. The section also provides details about keeping the policies up-to-date and about handling changes that impact them.

Another important part of Section 164.530 is related to workforce training. A covered entity must train all workforce members on the policies and procedures with respect to protecting PHI data. In addition, the section describes how a covered entity should apply sanctions against workforce members who fail to comply with the policies and procedures.

Section 164.308 of the Security Rule also emphasizes the importance of developing policies and procedures, appointing a security official, and training workforce members, stating that the covered entity must implement a security awareness and training program for all workforce members, including management. In addition, Section 164.316 of the Security Rules re-emphasizes the need to implement written policies and procedures that must be made available to those individual responsible for implementing those procedures.

The extent to which the database team and DBAs will participate in the process of writing policies and procedures or training workforce members will depend on the organization and their circumstances. Regardless of their participation, DBAs should have access to these policies and procedures and understand them fully when managing PHI data or implementing systems that will support PHI data. They should also fully understand the risks associated with violating HIPAA regulations and what steps to take if they discover a violation.

Securing the Environment

One of the most important HIPAA requirements is to implement the safeguards necessary to protect the PHI data wherever it resides. Section 164.530 of the Privacy Rule states that a “covered entity must have in place appropriate administrative, technical, and physical safeguards to protect the privacy of protected health information.” This includes protecting the data from any “intentional or unintentional use or disclosure that is in violation of the standards.”

This is a fairly open-ended description of what an organization is required to do. For more specific information, you need to refer to the Security Rule, which provides more details about the required steps. For example, Section 164.308 specifies that the covered entity must assess the potential risks and vulnerabilities to the electronic PHI and then implement security measures to reduce those risks. In addition, the organization must implement procedures for guarding against malicious software as well as for managing and protecting passwords.

Section 164.310 of the Security Rule includes a number of regulations aimed at safeguarding the physical infrastructure. For instance, the organization must implement mechanisms for limiting and controlling physical access to systems and facilities that house PHI data, while providing for disaster recovery and emergency access. In addition, the organization must implement safeguards that protect workstations accessing PHI data, along with any other hardware or electronic media used for sensitive data. The entity is also responsible for the proper disposition of PHI data from any hardware or media on which it has resided.

Another important section in the Security Rule is 164.312, which states that the covered entity must protect electronic PHI from “improper alteration or destruction,” as well as guard against unauthorized access to or modification of the data when “being transmitted over an electronic communications network.” Finally, the section states that the data must be encrypted whenever “deemed appropriate.”

The bottom line is that DBAs must take whatever steps necessary to ensure that PHI data at rest or in motion (when in their control) cannot be accessed or altered in any way that would impact the integrity of the data or violate a patient’s privacy. These steps can include performing periodic risk assessments, implementing password and key management, applying service packs and security patches, encrypting database objects, backing up databases, minimizing attack surfaces, or taking any number of other steps to prevent security violations.

Controlling Data Access

Another important step that DBAs can take to comply with HIPAA regulations is to control access to the data. According to Section 164.308 of the Security Rule, the covered entity must ensure that workforce members have “appropriate access” to electronic PHI, based on their roles in the organization. To this end, the covered entity must implement procedures for authorizing workforce members, supervising their access to data, determining whether that access is appropriate, and terminating that access when required.

Section 164.312 of the Security Rule builds on these access requirements by specifying that the covered entity should implement procedures that “allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4),” which further limits access to electronic PHI. For example, the subsection specifies that procedures should be implemented for making the data available “through access to a workstation, transaction, program, process, or other mechanism.”

Section 164.312 also states that a covered entity must assign a unique ID to each user for identifying and tracking that user’s activities. Plus, the organization must implement procedures for obtaining PHI data during an emergency, terminating electronic sessions after a predetermined time of inactivity, and encrypting and decrypting PHI data.

Using the principle of least privilege, DBAs should implement the mechanisms necessary to control access to PHI data at a granular enough level to minimize any security risks. In addition, DBAs should prevent shared accounts from being used to access data so user activity can be properly logged. They should also minimize the use of privileged accounts.

Many steps the DBA takes to control access to PHI data will be based on the technologies available to the database management systems that their organizations have implemented. For example, if they’re working with SQL Server, they might disable or rename the sa account, limit access to Windows Authentication mode, or implement Policy-Based Management. Regardless of the tools, however, the goal is the same: to ensure that only authorized users can access PHI data and that those users can carry out only the operations defined by their roles.

Auditing and Monitoring Systems

An effective auditing and monitoring strategy is essential to complying with HIPAA regulations. According to Section 164.308 of the Security Rule, a covered entity must “regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.”

The section also requires that the covered entity implement procedures for monitoring log-in attempts and reporting discrepancies, as well as perform periodic technical and nontechnical evaluations that establish “the extent to which a covered entity’s or business associate’s security policies and procedures meet the requirements.”

Section 164.312 of the Security Rule takes this a step further by instructing the covered entity to implement “hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.” In addition, the covered entity must implement electronic mechanisms to verify that the PHI data has not been “altered or destroyed in an unauthorized manner.”

Covered entities must be able to verify that they’re monitoring all relevant systems and can account for all data access and modifications. In other words, organizations must demonstrate that they have the mechanisms in place to catch any potential or actual security breaches.

For the DBA, this means implementing comprehensive auditing mechanisms that track which users are accessing what data and how they’re modifying that data. The DBA needs to audit all accounts, including those with privileged access. The DBA must also ensure that all log files are protected and cannot be overwritten or manipulated.

Auditing must be an ongoing process, using tools such as alerts and key performance indicators (KPIs) to ensure that security issues are identified and addressed as quickly as possible.

Preparing for Security Incidents

The HIPAA regulations provide a number of guidelines for how to prepare for and handle compliance-related incidents. For example, Section 164.530 of the Privacy Rule states that a covered entity must provide individuals with a process for making complaints about the organization’s policies and procedures or about its compliance with those policies and procedures. The section also states that the covered entity cannot retaliate against individuals who exercise their rights, as provided by the Privacy Rule. In addition, the entity must take the steps necessary to mitigate any harmful effects that result from PHI data being compromised.

Unlike the Privacy Rule, the Security Rule includes regulations that apply more to the DBA’s day-to-day operations. For example, Section 164.308 states that the covered entity must identify and respond to “suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity or business associate; and document security incidents and their outcomes.”

In addition, the section states that the organization must put into place procedures for responding to emergencies, such as fires, system failures, or natural disasters. As part of this process, the organization must create and maintain an exact copy of the PHI data, as well as implement a disaster recovery plan that allows the organization to carry out critical business operations during an emergency, while continuing to protect the data.

The Security Rule is full of references that directly or indirectly apply to security incidents. For example, Section 164.308 states that the covered entity must apply appropriate sanctions against a workforce member who fails to comply with security policies, Section 164.310 describes the need to create a “retrievable, exact copy” of the PHI data before moving any equipment, and Section 164.312 states that a covered entity’s business associates must report any security incidents to the covered entity.

For many DBAs, meeting at least some of these requirements should be fairly straightforward because they’re already backing up their databases and have disaster recovery plans in place. What’s most important, however, is that the DBA is able to respond to security incidents as soon as possible, which ties back to having an effective monitoring strategy in place.

DBAs should refer to the rest of the HIPAA documentation for more details about how to respond to data breaches.

Documenting Everything

Perhaps the simplest part of the HIPAA requirements to understand is the need to document everything. Throughout the Privacy and Security rules, you’ll find a variety of references to documentation requirements. For example, Section 164.530 of the Privacy Rule states that sanctions against workforce members must be documented, as well as all policies and procedures. In addition, documentation must be retained for six years from the creation date or when it was last in effect, whichever is later.

Section 164.310 of the Security Rule adds to these requirements, stating that the covered entity must maintain a “record of the movements of hardware and electronic media and any person responsible therefore.” Section 164.316 of the Security Rule goes on to reiterate the need to document policies and procedures and retain that documentation for six years. The section also states that the documentation should be updated as needed in response to environmental or operational changes.

The HIPAA regulations state that all required actions, activities, complaints, assessments, and security incidents must be documented. The degree to which these requirements will impact the DBA depends on the specific circumstances. The safest bet is to document all operations to ensure that any actions related to protecting the PHI data can be verified. As with most aspects of the HIPAA regulations, database teams need to work closely with other teams in the organization to ensure that they’re complying with those regulations.

Complying with HIPAA

As this article shows, DBAs must take into account a wide range of requirements when trying to comply with the HIPAA standards. They should also keep in mind that HIPAA regulations are far more complex than what’s been covered here. This information in this article is meant only as a starting point to give DBAs a sense of what they’re up against when trying to protect PHI data.

Fortunately, database management systems such as SQL Server include many of the features necessary to achieve HIPAA compliance. That said, such features are no substitute for a carefully planned and executed security strategy. DBAs must take every precaution necessary to ensure that only authorized members of the workforce can access PHI data, while preventing unauthorized access and minimizing the possibility that personal data will be compromised.