What Is Protected Health Information?

Protected Health Information, or PHI, is the personally identifiable health information that HIPAA regulates and protects. But HIPAA was written nearly 20 years ago for a mostly analog world of paper files and physical x-rays—the iPhone wasn't even a dream.

In today's world of wearables, health apps, genetic sequencing and more, getting a precise definition of PHI can be confusing for developers trying to parse whether they need to be HIPAA compliant or not.

In this post we're going to look at what PHI is, what it isn't, and how you can tell the difference. Hopefully you'll be able to use this as a reference when determining if the information you're collecting requires falls under the definition of PHI as outlined by HIPAA.

Covered Entities and Business Associates

Before we can talk about protected health information we need to first discuss two important definitions in HIPAA: Covered Entities and Business Associates.

A Covered Entity is anyone who provides treatment, payment and operations in healthcare. According to the U.S. Department of Health & Human Services (HHS) Healthcare Providers, Health Plans, and Healthcare Clearinghouses are all Covered Entities. Healthcare Providers include hospitals, doctors, clinics, psychologists, dentists, chiropractors, nursing homes, and pharmacies.

Health Plans include health insurance companies, HMOs, company health plans, Medicare, and Medicaid. In addition, employers and schools that handle PHI in order to enroll their employees and students in health plans fall under the definition of a Health Plan.

Healthcare Clearinghouses are a bit harder to identify at first. A Clearinghouse takes in information from a healthcare entity, puts the data into a standard format, and then spits the information back out to another healthcare entity.

Covered Entities include:

Doctors’ offices, dental offices, clinics, psychologists

Nursing homes, pharmacies, hospitals or home healthcare agencies

Health plans, insurance companies, HMOs

Government programs that pay for healthcare

Healthcare clearinghouses

A Business Associate is a vendor or subcontractor who has access to PHI. A more legalese definition of a Business Associate is any entity that uses or discloses PHI on behalf of a Covered Entity. Furthermore, a Business Associate is any person who, on behalf of a Covered Entity, performs (or assists in the performance of) a function or activity involving the use or disclosure of PHI.

Business Associates can be data storage or document storage services (it doesn’t matter if they can view the PHI that they maintain), providers of data transmission services, portals or other interfaces created on behalf of Covered Entities that allow patients to share their data with the Covered Entity, and electronic health information exchanges.

The Definition of PHI

Now that we have those definitions down we can define Protected Health Information. PHI is any information in a medical record that can be used to identify an individual, and that was created, used, or disclosed to a covered entity and/or their business associate(s) in the course of providing a health care service, such as a diagnosis or treatment.

Protected Health Information (PHI) is the combination of health information and personally identifiable information (PII). Health information encompasses information that is created or received by a covered entity via any medium—verbal, written, electronically or otherwise. This information includes the physical or mental health condition of an individual at any point in time. PII falls under the umbrella of health information since it has the potential to reveal an individual's personal identity, which could then be linked back to the health information created or received by a covered entity.

Examples of PHI

Let’s look at some concrete examples of information that is considered PHI. If your business handles any of the information below in the service to, or on behalf of, a covered entity, then HIPAA compliance is not optional.

Patient names

Addresses — In particular, anything more specific than state, including street address, city, county, precinct, and in most cases zip code, and their equivalent geocodes.

Dates — Including birth, discharge, admittance, and death dates.

Telephone and fax numbers

Email addresses

Social Security numbers

Driver’s License information

Medical record numbers

Account numbers

Health plan beneficiary numbers

Certification/license numbers

Vehicle identifiers and serial numbers, including license plate numbers

Device identifiers and serial numbers

Names of relatives

Internet Protocol (IP) address numbers

Biometric identifiers — including finger and voice prints.

Full face photographic images and any comparable images Practically speaking, PHI can show up in a number of different documents, forms and communications, such as:

Billing information from your doctor

Email to your doctor's office about a medication or prescription you need

Appointment scheduling note with your doctor's office

An MRI scan

Blood test results

Phone records

Examples of Data Not Considered to be PHI

But not all personally identifiable information is PHI. For example, employment records of a Covered Entity and Family Educational Rights and Privacy Act (FERPA) records do not fall into the category of PHI because, despite the fact that they might contain personally identifiable information, it is not linked to health records that could compromise individual security.

In addition, some health information isn’t considered PHI because it isn’t personally identifiable or shared with a covered entity.

Examples of non-PHI data: - Number of steps in a pedometer - Number of calories burned - Blood sugar readings without personally identifiable user information (PII) (such as an account or user name) - Heart rate readings without PII

The test for PHI is pretty simple: if your device or application stores, records or transmits the user’s personally-identifiable health data to a covered entity then you are dealing with protected health information and need to be HIPAA compliant.

If you are building a wearable device or application that collects health information, but does not plan on sharing it with a covered entity at any point in time then you do not need to be HIPAA compliant. For example, the Nike Fuel Band does not track data considered protected health information because you can't transmit that data from the device to a covered entity.

No Safe Harbor for Accidental PHI

Penalties for HIPAA noncompliance are anything but lenient. Depending on the level of negligence, these fines can range from $100 to $50,000 for a single accidental violation, with a single violation due to willful neglect resulting in an automatic $50,000 fine. The fines and charges are broken down by type: “Reasonable Cause” and “Willful Neglect”.

Reasonable Cause fines can be anywhere from $100 to $50,000 per incident and does not involve any jail time. Willful Neglect ranges from $10,000 to $50,000 for each incident and can result in criminal charges.

The maximum penalty for violations of an identical provision is $1.5 million per year. 2014 saw millions of patient records compromised due to breaches and millions of dollars in fines levied to the organizations who were responsible for protecting the data.

Unlike the Digital Millennium Copyright Act (DMCA), HIPAA does not include safe harbor for accidental storage or disclosure of PHI. The DMCA makes it easy for sites like YouTube to avoid being fined for hosting copyright material as long as those sites have a clear process for accepting and acting on content takedown requests. HIPAA has no similar rule. Therefore if your system houses PHI, even without your knowledge or consent, you are still liable under HIPAA.

For example, if you’re an anonymous mHealth messaging app that allows users to ask doctors questions about a condition without disclosing personally identifiable information, and a user discloses PHI, you’re liable for that information under HIPAA. There is no protection for you simply because that was not the intended use case for your application.

How to Become HIPAA Compliant

In order to become HIPAA compliant, there are four rules you need to be aware of and compliant with:

HIPAA Privacy Rule

HIPAA Security Rule, which spells out:

Technical Safeguards

Physical Safeguards

Administrative Safeguards

HIPAA Enforcement Rule

HIPAA Breach Notification Rule

The HIPAA Privacy Rule establishes national standards to protect individuals’ medical records and applies to health plans, healthcare clearinghouses, health care providers and their business associates.

In order to fulfill the requirements for the confidentiality, integrity, and security of PHI as specified under the HIPAA Security Rule, you must properly address the Physical, Technical, and Administrative safeguards mentioned above. These three safeguards include implementation specifications—some of which are “required,” while others are “addressable.” Those implementation specifications that are required must be implemented, while addressable implementation specifications are best practices which must be implemented if it is reasonable and appropriate to do so (the choice must be documented).

The HIPAA Enforcement Rule spells out in full the investigations, penalties, and procedures for HIPAA violation hearings, which we touched on briefly above.

Finally, the HIPAA Breach Notification Rule requires that you notify Health and Human Services (HHS), the media, and the public if the breach affects more than 500 patients.

For a detailed discussion of these of these four rules or more information on just what it takes to become HIPAA compliant, read the Developer’s Guide to HIPAA Compliance.

So now that you know what protected health information is and why it’s important, now’s a great time to go back and review the types of information you’re collecting to assess whether you need to be HIPAA compliant or not. With the increased scrutiny on HIPAA violations, the massive fines associated with breaches, and the lack of a safe harbor clause for unintentional PHI, it’s better to be safe than sorry when dealing with sensitive health information.