Introduction to HIPAA and SOX

Despite the attention to data privacy and protection caused this year because of the GDPR, regulations governing how data is handled are nothing new. In this article, Robert Sheldon provides an overview of two US regulations, HIPAA and SOX, and explains how these regulations affect DBAs.

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

More than ever, the pressure is on database administrators (DBAs) to address compliance regulations that govern how data must be protected and preserved. The regulations are usually specific to a country, region, or industry and can impose stiff penalties on organizations that don’t comply. For DBAs managing databases in the United States, two of the most important sets of regulations they can face are defined by the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and the Sarbanes-Oxley Act of 2002 (SOX).

HIPAA and SOX target very different issues and have much different requirements. The HIPAA regulations were put into place to protect patient privacy, which limits their applicability to organizations directly or indirectly involved with health care. The SOX regulations were enacted to protect investors from fraudulent financial practices, and they apply to all public companies.

Every department within an organization shares in the responsibility for ensuring that they’re complying with applicable regulations. However, database teams are often put into a unique position because they end up managing the regulated data, leaving them to deal with many of the logistical issues that go with achieving compliance. If they’re going to be successful, they need to clearly understand what rules govern which data.

If you’re on one of those teams, a good place to start is to become more familiar with the ins and outs of HIPAA and SOX. This article attempts to fill in some of the gaps about both sets of regulations, providing an overview of each one and an organization’s responsibilities in addressing them. This article is the first in a series about HIPAA and SOX. The articles to follow will get into more of the nitty-gritty about how to comply with each one.

Keep in mind, however, that HIPAA and SOX are both complex laws, with lots of pesky details and pages of legalese. Your organization is responsible for understanding all their nuances and expectations so you don’t find yourselves unexpectedly out of compliance. This article merely summarizes some of the more salient details about HIPAA and SOX. You’ll need to research these laws much more thoroughly to ensure that nothing has been missed.

Understanding HIPAA

When HIPAA was enacted in 1996, the law required the secretary of the U.S. Department of Health and Human Services (HHS) to come up with national standards for protecting the privacy and security of a patient’s personal health information. The new standards needed to safeguard individually identifiable information, govern electronic health care transactions, and establish national identifiers for health care providers and other entities.

In the early 2000s, the HHS secretary published the standards as a set of rules, with the Privacy Rule and Security Rule being the most relevant to organizations handling patient data. The final Privacy Rule was published in December 2000 and modified in August 2002. The final Security Rule was published in February 2003.

The Privacy Rule establishes a set of standards that address how patient information can be used and disclosed. The rule attempts to strike a balance between protecting a patient’s privacy and allowing information to be shared in order to deliver high-quality health care and protect public health. The Privacy Rule applies to three entity types—health care providers, health plans, and health care clearinghouses—which are referred to as covered entities.

The health care providers category includes any provider that electronically transmits patient information in connection with claims, eligibility requests, referral authorizations, or similar transactions. The applicable transaction types are specified in the HIPAA Transactions Rule. The provider category includes all institutional and non-institutional providers and any individuals who furnish, bill for, or are paid for health care services.

The health plan category includes individual and group plans that provide or pay the cost of medical care. These can include entities such as health maintenance organizations (HMOs), Medicare, Medicaid, health or dental insurers, employer-sponsored group health plans, and numerous others. Nearly all health-related plans are subject to the Privacy Rule, regardless of type.

Health care clearinghouses are entities that process patient data on behalf of health plans or health care providers. The clearinghouse usually transforms the data in some way from a nonstandard format to a standard format. This category includes such organizations as billing services or community health management information services.

The Security Rule operationalizes the protections outlined by the Privacy Rule. The Security Rule addresses technical and nontechnical standards that covered entities must adhere to in order to secure electronic protected health information (e-PHI), which is a subset of the patient information addressed by the Privacy Rule. The main goal of the Security Rule is to protect patient privacy, while letting covered entities implement technologies that improve patient care.

Addressing HIPAA

The Privacy Rule protects all individually identifiable health information that covered entities or their business associates hold or transmit, whether the information is stored electronically, printed on paper, or communicated orally. Identifiable information can include any of the following details:

  • The patient’s past, preset, or future physical or mental health
  • Any health care services that the patient has received
  • Any payment information related to the patient’s care that can be used to identify the patient

No identifiable information can be made available to or disclosed to non-authorized individuals. Identifiable information can include names, phone numbers, addresses, birthdates, Social Security numbers, and other personal information. Covered entities can disclose protected information only as the Privacy Rule permits or requires, unless the patient (or legal representative) authorizes disclosure.

The Privacy Rule follows the principle of minimum necessary, in which covered entities must make a reasonable effort to ensure that protected information is used, disclosed, and requested only to the amount necessary to deliver health care.

In addition, the Privacy Rule describes the consequences of a covered entity failing to comply with HIPAA. Violators are subject to civil money penalties, which can run between $100 to $50,000 or more per violation, with a calendar cap of $1.5 million. The exact amount depends on a number of factors, such as the date of the violation or whether the violation was a result of willful neglect.

Individuals can also face criminal penalties up to $250,000 and 10 years imprisonment, depending on the nature of the crime. The exact amount depends on whether the individual simply obtained or disclosed identifiable patient information or if the individual tried to sell, transfer, or use the information for commercial advantage, in which case, the Department of Justice is brought in to carry out criminal prosecutions.

When it comes to e-PHI data, the Security Rule requires that covered entities implement reasonable and appropriate protections, adhering to the following guidelines:

  • Ensure the integrity, confidentiality, and availability of all e-PHI data in their possession.
  • Identify and protect against anticipated threats to the e-PHI data.
  • Protect against anticipated non-permitted uses or disclosures.
  • Ensure that e-PHI data is not available to or disclosed to non-authorized individuals in the workforce.

The Security Rule does not specify how to protect e-PHI data, leaving it up to the covered entity to determine the best way to implement the necessary safeguards. However, the rule does set out a number of requirements for how to approach security:

  • Administrative protections: The covered entity must identify and analyze potential risks to e-PHI and then implement security measures to reduce those risks. The entity must also implement e-PHI security policies and procedures, designate a security official who’s responsible for developing and implementing them, and train workers in how to apply them. Regular assessments must be performed to evaluate how the policies and procedures are working.
  • Physical protections: The covered entity must control physical access to its facilities as well as implement policies and procedures that govern workstation and device security.
  • Technical protections: The covered entity must implement policies and procedures that permit only authorized access to e-PHI. In addition, the entity must implement auditing and other security measures that guard against unauthorized access to transmitted e-PHI and against e-PHI being improperly altered or destroyed.

The Security Rule also outlines a number of other requirements, such as the length of time to maintain records, what to do if a business associate violates the rule, and what steps to take if there’s been a security breach.

Understanding SOX

The 2002 SOX law was enacted to “protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws, and for other purposes.” The law, which applies to all U.S. public companies, sought to improve auditing capabilities, reduce fraudulent practices, and in general force companies to be more transparent by regulating financial reporting and other practices.

The SOX legislation also created the Public Company Accounting Oversight Board (PCAOB) to oversee public company auditing practices. The PCAOB is set up as a nonprofit corporation, rather than as an agency of the U.S. government, and is responsible for establishing the rules, standards, and quality control mechanisms that govern corporate audit reports. In addition to enforcing compliance of the SOX regulations, the PCAOB can inspect and investigate public accounting firms and carry out disciplinary proceedings against them.

The U.S. Congress enacted SOX in response to a number of major scandals that had rocked the corporate and accounting communities in the early 2000s. Enron, Tyco, and WorldCom are just of few of the companies whose financial dealings came under scrutiny, resulting in long prison terms and big-time fines. The SOX legislation sought to calm investor nerves and restore their confidence in the markets by introducing some of the most sweeping changes to financial practices in generations.

The SOX regulations are arranged into 11 titles that are each divided into sections, with some sections more relevant to compliance than others. (We’ll get into a couple of these sections in a bit.) The SOX regulations also include a number of other key provisions, such as protecting whistleblowers, prohibiting personal loans to executives, and requiring attorneys who represent public companies to report security-law violations.

Addressing SOX

All public companies must comply with SOX regulations. Unfortunately, the regulations are geared more toward accountants and attorneys than they are to DBAs and IT professionals. In fact, the term technology is mentioned only twice throughout the law and only within the context of authorizing appropriations. And when it comes to the term security, the law explicitly states that it has “the same meaning as in section 3(a) of the Securities Exchange Act of 1934 (15 U.S.C. 78c(a)).” In other words, it has nothing to do with protecting data.

Similar to HIPAA, the SOX law leaves it up to the individual corporation to come with internal control mechanisms for complying with the regulations. However, two sections within the law can help provide insight into some of the expectations that come with these regulations.

The first is Section 302, which outlines corporate responsibility for filing periodic Securities and Exchange Commission (SEC) financial reports. According to this section, a report should not contain any untrue statements or omit facts that would result in misleading information. In addition, those signing the report are responsible for establishing and maintaining internal controls as well as evaluating the effectiveness of those controls for the 90 days preceding the report. The report must also list any deficiencies or weaknesses in the internal controls, as well as any fraud related to those controls.

Another important section in the SOX law is 404, which focuses on management’s assessment of internal protections. The section states that the SEC report must include an internal control report that explicitly acknowledges management’s responsibility for establishing and maintaining an adequate internal control structure and procedures for financial reporting. The internal control report must also include an assessment of the effectiveness of the internal control structure. In addition, Section 404 states that each registered public accounting firm that prepares an audit report must attest to the client’s assessment of the internal control structure.

The gist of these two sections is that a public company needs to have the necessary controls in place for producing financial reports that accurately reflect the company’s current financial status. To this end, those responsible for these controls must ensure that no financial data is destroyed, altered, or falsified in any way that can result in presenting a misleading financial profile.

Corporate officers are responsible for certifying that each report complies with SEC regulations and that the information in the report fairly presents the company’s financial conditions. Officers that certify a report that does not “comport with all the requirements” can face stiff criminal penalties, with up to $1 million in fines, 10 years in prison, or both. If it’s determined that the officers willfully certified a report that did not comport, they could be hit with $5 million in fines, 20 years in prison, or both.

Clearly, corporate officers have a lot at stake in making sure their companies are complying with the SOX regulations. But they’re not the only ones whose careers are on the line. The SOX law also outlines penalties for registered public accountants as well as plan administrators.

HIPAA, SOX, and the DBA

Organizations that are required to comply with HIPAA or SOX must take whatever steps necessary to make sure they get it right. Even the most well-meaning company could be hit with fines or other penalties if they fail to adhere to the regulations, which can also impact the company’s reputation.

Complying with HIPAA or SOX requires a unified effort within the organization, one that will inevitably include DBAs, system administrators, and developers building data-driven applications. The better they understand what is required, the better they can prepare their systems to accommodate HIPAA and SOX requirements, which we’ll be covering in the articles to follow. The good news is that the regulations force database teams to focus on protecting data and implementing security best practices, something they should all be doing anyway.