Sections of HIPAA

Sections of HIPAA

Last Modified: April 03, 2017

HIPAA, at it’s highest level, is divided into 3 broad areas.

  1. HIPAA Privacy Rule. This portion of HIPAA deals with protection, access, and authorization related to PHI. It sets rules for when and how PHI is disclosed. It also gives individuals ownership of their health records, as well as the right to access them and request corrections to them.

  2. HIPAA Security Rule. The Security Rule sets standards for the security of technology used to access, store, transmit, or process PHI. It is concerned with electronic PHI, or ePHI. It operationalizes much of the Privacy Rule. It’s not always prescriptive in how to secure technology, and some aspects are left to interpretation. This section of HIPAA is the most relevant to app developers from a practical standpoint. One additional thing to know is that certain implementation specifications laid out in the security rule are either required, meaning you have to do them, or addressable. Addressable specifications are ones in which an entity needs to either 1) implement the specific implementation as written, 2) implement an alternative specification, or 3) not implement anything for that specific requirements because it is not reasonable or necessary to do so. As with most things in HIPAA, the important thing is that decisions related to addressable specifications are documented.

A quick side note on documentation - as we alluded to earlier, HIPAA is not prescriptive. Therefore, the general approach has been one of being able to show that the risk of data leakage / breach has been mitigated to the extent possible and the steps taken to do so documented (and updated when changed). These reams of documentation are in place so that in case of a breach, companies can show the extent to which safeguards were implemented.

  1. Administrative Simplification. This area of HIPAA relates to the accepted coding for data exchanged in healthcare. The transactions this applies to are financial related (claims, eligibility, enrollment, etc). As the name implies, the intent is to make it administratively easier to exchange data by not having to keep track of an endless number of code sets. The common code sets range from X12 or NCPDP (pharmacy-related) and include DRG, ICD, CPT, NDC, SNOMED-CT, and LOINC amongst others.

Administration Simplification

This area of HIPAA relates to the accepted coding for data exchanged in healthcare. The transactions this applies to are financial related (claims, eligibility, enrollment, etc). As the name implies, the intent is to make it administratively easier to exchange data by not having to keep track of an endless number of code sets. The common code sets range from X12 or NCPDP (pharmacy-related) and include DRG, ICD, CPT, NDC, SNOMED-CT, and LOINC amongst others.

Here’s a quick overview of these code sets and their intended function.

They are all linked to the appropriate browsers where possible so that you can get a better idea as to what they look like.


When people talk or write about HIPAA, it’s always presumed that there’s an enforcement aspect, though enforcement is rarely explicitly discussed. As much as people and organizations value the privacy and security of the personal health information of their customers (patients, members, users/consumers), the fear of fines and other penalties are the major drivers of compliance and security efforts. Penalties, whether fines or otherwise, are quantifiable, and expose organizations to very real financial risk if proper controls, both tech and policy, aren’t put into place and followed.

HHS sets the rules for HIPAA and enforcement is carried out by The Office of Civil Rights (OCR), within HHS. OCR is tasked with the responsibility of investigating complaints. Based on an investigation, the OCR determines if the covered entity, or the business associate of a covered entity, was in compliance with the security and privacy rule. The investigation branches at whether an organization is in violation of HIPAA rules or not. If the organization is not in violation, the findings are documented and the case is closed. HIPAA is not always prescriptive, and has terms like “reasonable”, so there is some interpretation and gray area at this stage.

In a recent report by the OCR, the Security Rule accounted for the majority, or 60%, of violations, followed by Privacy Rule violations and then Breach Notification violations. That recent report also cited a lack of complete or accurate risk assessments as a widespread problem, with up to two third’s of entities lacking full and timely risk assessments. Risk assessments are incredibly valuable and should inform much of your security and privacy posture as an organization.

If the OCR finds an organization to be in violation, the following actions may take place:

There are monetary penalties associated with HIPAA violations, and the amounts of such violations were raised considerably last year as part of the HIPAA Omnibus Rule included in the HITECH act. The current financial penalties are listed below.

HIPAA Financial Penalties

Violation Category - Section 1176(a)(1) Each Violation All such violations of an identical provision in a calendar year
A. Did not know $100-$50,000 $1,500,000
B. Reasonable Cause $1000-$50,000 $1,500,000
C.i. Willful Neglect - Corrected $10,000-$50,000 $1,500,000
C.ii. Willful Neglect - Not Corrected $50,000 $1,500,000

Previous to these new rules, the fine associated with each HIPAA violation was capped at $25,000. This number is now $1.5 million per violation.

In certain extreme HIPAA cases, individuals can be exposed to criminal risk as well. When criminal action is involved with HIPAA, the OCR hands the case off to The Department of Justice. Individuals are at risk of criminal enforcement and penalties if they “knowingly” obtain, disclose, or use PHI “in violation” of HIPAA rules. You can read a very detailed, legal opinion on what constitutes legal vs civil in the case of HIPAA. There is a lengthy discussion of the terms “knowingly” and “in violation” in that document, which is why we put them in quotes.

In addition to the OCR, and the Department of Justice to a lesser extent, recently the FCC has waded into enforcing the privacy of health data through its mandate to protect consumers. The financial penalties from the FCC are lower than those from the OCR; but, the FCC has the power to require annual privacy audits, as it has done with companies like Google and Facebook, and these audits, over time, have the potential to be very expensive for companies. This move by the FCC is new, and still making its way through the courts, so it’s still uncertain how the FCC will fit with HIPAA enforcement.


The new HIPAA Omnibus (“omnibus” means something with several volumes or chapters) rules that went into effect on 9/23/2013, amongst other changes, created a category of entities called subcontractors.

Previously HIPAA rules only defined two categories of entities - covered entities and business associates. Covered entities are basically providers, payers, and clearinghouses. Business associates are basically entities that work with covered entities to perform a service or services to store, transmit, and/or process PHI. The new HIPAA rules expanded the number of categories of entities by 50% with the addition of subcontractors; for those of us in health tech, we think this is a pretty big deal.

Subcontractors are entities that business associates use to process, create, or store PHI. Subcontractors don’t have business associate agreements, or really any direct relationships, with covered entities; but, starting 9/23/2013, theses subcontractors need to have business associate agreements (BAAs) with business associates. It’s all very obvious and confusing at the same time. Essentially you can think of subcontractors as a business associate of a business associate.

The best examples of subcontractors we can think of are hosted services providers like Amazon Web Services, Visible Health, and Rackspace. Visible Health is a subcontractor for some of our customers and, as such, we do sign BAAs. We also act as a business associate directly for covered entities like enterprises, and sign BAAs in this capacity as well. We offer the same API-based services for developers in both circumstances, but the relationship is slightly different in the eyes of HIPAA.

At Visible Health we know that subcontractors, as defined by HIPAA, have existed for a long time. As more health apps and services have shifted to hosted, or cloud based, and more infrastructure tools (app dev, logging, analytics, data collections, etc) have become mainstream, covered entities and business associates have begun to rely on “subcontractors”. The new HIPAA rules now mean those subcontractors need to work with business associates to assure all parties are covered in terms of liability.

This is a very excited and major shift for health tech. HIPAA has finally acknowledged subcontractors and the role they play in creating, processing, and transmitting PHI. That’s important for health tech to build smart, scalable, and interoperable tools. As a developer in healthcare, if you’re considering acting as a business associate, or selling services to a covered entity, you need to understand if you fit into a certain entity category as defined by HIPAA.

We encourage you to read the rest of the new rules, or at least one of the commentaries that covers them in more detail, to see about the other changes that are a part of the Omnibus rule.

Privacy Rule

The HIPAA Privacy Rule sets many of the terms used for HIPAA, outlines the types of entities that need to comply with HIPAA, defines appropriate uses or disclosures of health information, and also covers penalties for HIPAA violations. The Privacy Rule is important to understand, despite the fact that it doesn’t include specific technical requirements or polices, as the Privacy Rule gives an understanding of the types of data, entities, and uses of data that HIPAA is concerned about.


The Privacy Rule defines two main categories of entities:

  1. Covered Entities (CEs). These are the traditional players in healthcare - providers, hospitals, health systems, insurers. For some reason clearinghouses are called out as they transform and process health information for payers and providers; the clearinghouse that I always think of is Emdeon.

  2. Business Associates (BAs). These are individuals and organizations that provide services and/or technology to covered entities. In the process of providing those services and technology, the business associate in some way process, transmit, or store protected health information (PHI). All software vendors in healthcare, if they somehow touch PHI, are business associates.

A third category of entity, or maybe more accurately a subcategory of business associates, was added in 2013 as part of the HIPAA Omnibus rules in the HITECH Act. The HITECH Act defined a subcontractor as an entity that “creates, receives, maintains, or transmits protected health information on behalf of the business associate.” A subcontractor is a business associate of a business associate. It can be a hosting provider, an email delivery service (email address), or even an analytics platform (IP address), if it in some way touches PHI. At Visible Health many of our customers are business associates, and we are subcontractors for them, so we meet the new definition of subcontractor.

The Omnibus Rule also defined a PHR vendor, offering a PHR through a covered entity, as a business associate.

PHI + De-identifying

Understanding the definition of PHI is important for understanding HIPAA. It’s basically personally identifiable data (name, email, phone, etc) combined with some type of health-related data (medication, diagnosis, provider name).

PHI can be de-identified by removing certain elements from the data, in a process called the Safe Harbor method, or through “expert determination”, which seems a bit fuzzy to us as it is ripe for interpretation. The idea with both methods for de-identification is to make it so you can’t identify an individual from a data set.

Use or disclosing of PHI

PHI can only be disclosed for reasons defined by the Privacy Rule, or with written permission by an individual about their own health information. Other than providing access to the individual to his/her medical record, the Privacy Rule allows for disclosing PHI for three main reasons:

  1. Treatment. Probably the most obvious reason for disclosure, exchanging PHI between providers for treatment, management, and consultation happens all the time.
  2. Payment. In order to collect payments from insurers, disclosure of PHI is essential.
  3. Operations. We think of this as the catch-all bucket. It encompasses many administrative functions such as quality reporting and different types of operational analytics. This is also where disclosures for medical education fall in.

There are some other, more obscure reasons, for disclosures. The most relevant reasons left are for legal reasons (“required by law”), worker compensation, and for restricted research purposes, amongst others.

In some select cases, in particular marketing, covered entities may disclose PHI but only with authorization from the individual.

Minimum necessary

One of the central tenants of HIPAA, as stated in the Privacy Rule, is minimum necessary use of PHI. The idea is relatively simple, don’t disclose any information that is not necessary for the reason for which the information is to be used. Example - if you’re trying to find out how much a patient owes for a particular procedure, you probably don’t need to disclose that patients allergies. In healthcare today minimum necessary is usually observed by either specific HL7 or EDI X12 message types, which confine the amount and type of data in a data exchange.

Notice of Privacy Policies

Covered entities must provide individuals with a notice informing those individuals of their rights, as well as detailing other factors such as the protections the covered entity use to secure PHI. You probably remember getting these, and signing them, every time you go to the doctor.


The Office of Civil Rights (OCR), within HHS, is responsible for enforcing the HIPAA rules. In addition to civil (financial) penalties, there are criminal penalties for knowingly disclosing PHI or obtain PHI in violation of the HIPAA Privacy Rule.##Overview The HIPAA Privacy Rule sets many of the terms used for HIPAA, outlines the types of entities that need to comply with HIPAA, defines appropriate uses or disclosures of health information, and also covers penalties for HIPAA violations. The Privacy Rule is important to understand, despite the fact that it doesn’t include specific technical requirements or polices, as the Privacy Rule gives an understanding of the types of data, entities, and uses of data that HIPAA is concerned about.

Security Rule

The HIPAA Security Rule operationalizes many of the standards set out in the Privacy Rule. Specifically the Security Rule spells out, in various levels of detail, the ways in which electronic protected health information, or ePHI, needs to be protected. The Security Rule, despite setting implementation specifications, isn’t all that specific most of the time.

The Security Rule is the section of HIPAA that gets most talked about by vendors like us and others with a background in technology. Many times developers and vendors focus specifically on the areas within the Security Rule to achieve compliance. Even with this area of focus, the specific technical controls only make up a minority of the HIPAA Security Rule.

The HIPAA Security Rule can be broken down into the three main categories below.


This is actually the largest category of safeguards in the HIPAA Security Rule, accounting for over 50% of the rule. These are not server setting or specifics around technology, they are policies and processes that need to be followed to safeguard data. The biggest and most important area covered in this section, at least for people starting out on the journey towards compliance, is the risk assessment. A risk assessment should be the first step for most organizations wanting to be compliant, and covers documenting architecture, identifying risks related to the protection of PHI, and mitigating those risks.

When you use Visible Health, we cover much of risk environment for you as we manage many aspects of the architecture. We work with you to define areas that you need to address in terms of risk, and will work closely with you if and when you decide to go forward with a full audit.

There are other areas in this category including workforce security, contingency planning, training, and a few others, all of which are necessary to examine and address, but the risk assessment is really the big one in this category.


This category is easy to understand as it’s the physical aspect of securing systems that have access to ePHI. It breaks out to workstations, facilities, and different portable and mobile media. Most data centers today, including the ones that we use at Visible Health, more than meet the requirements in the Security Rule for facilities. Typically compliant Infrastructure-as-a-Service vendors, like AWS and Firehost, cover this category of HIPAA for you.

Areas people sometimes neglect are office security and workstation security. These aren’t hard safeguards to meet but they likely involve some process changes, like not allowing cleaning people into your office without supervision, keeping doors locked and tracking visitors, encrypting employee computers, and using workstation firewalls. We control and monitor access at our offices using a smart lock from Lockitron, which provides a nice log of all access.


The technical category of safeguards is usually what people think of when they think of securing ePHI. The biggest areas are encryption, access controls, and auditing. With encryption, it has to be end to end, and it has to be at rest. At rest is typically harder. We have found that we need to use high performance SSD drives to improve performance issues that arise with encrypting data at rest.

For access controls and logging, basically all activity of servers should be logged and those logs should be monitored with appropriate alerting. All API calls should also be logged, including what was accessed (with ePHI at times), by whom, and when. We have spent a lot of time building a powerful and flexible unified logging solution to meet the requirements in this area.

Beyond the three areas above, there are a few miscellaneous requirements in the security rule. Those additional requirements relate to signing business associate agreements and having policies to, well, manage your policies.

That’s a very high high level overview of the Security Rule. You can see pretty detailed information about the Security Rule, and how Visible Health addresses the different specifications, on our HIPAA page.