PROTECTED HEALTH INFORMATION (PHI)

What is Protected Health Information (PHI)?

PHI stands for Protected Health Information and is any information in a medical record that can be used to identify an individual, and that was created, used, or disclosed in the course of providing a health care service, such as a diagnosis or treatment.

In other words, PHI is personally identifiable information in medical records, including conversations between doctors and nurses about treatment. PHI also includes billing information and any patient-identifiable information in a health insurance company's computer system.

Protected Health Information is the definition used by HIPAA (Health Insurance Portability and Accountability Act) to define the type of patient information that falls under the jurisdiction of the law. eHealth applications that collect, store or share PHI need to follow HIPAA compliance guidelines in order to be compliant with the law.

In order for health data to be considered PHI and regulated by HIPAA it needs to be two things:

1. Personally identifiable to the patient
2. Used or disclosed to a covered entity during the course of care

Examples of PHI:

• 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 health data that is not considered PHI:

• Number of steps in a pedometer
• Number of calories burned
• Blood sugar readings w/out personally identifiable user information (PII) (such as an account or user name)
• Heart rate readings w/out PII

The Difference Between Protected Health Information and Consumer Health Information

For developers, determining whether an application collects PHI or not is critical to determining whether HIPAA compliance requirements need to be met or not. So how do you know if you're dealing with protected health information (PHI) or consumer health information?

The test is straightforward: if the device or application you are building records or transmits the user's personally-identifiable health data held in the app or device and is used by a covered entity in the course of care, then you are dealing with PHI 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. However, the trend in mobile health data collection is toward the sharing of health data with health care providers—making it PHI by definition.

For example, the Nike Fuel Band does not need to be HIPAA compliant because it does not track PHI and you can't transmit that data from the device to a covered entity. Data about blood sugar and sleep patterns collected by Apple's Healthkit and accessed by an app to share with a doctor falls under HIPAA.

What is ePHI?

ePHI is Electronic Protected Health Information and is All individually identifiable health information that is created, maintained, or transmitted electronically by mHealth (link to mHealth page) and eHealth products. This includes PHI on desktop, web, mobile, wearable and other technology such as email, text messages, etc.

Protected Health Information and Developer Considerations

If you are building an application that deals with health information you may be evaluating whether the types of information collected will be considered PHI or not. One important consider for application developers and PHI is that there can be many edge cases where users add PHI to your application through their regular use, even if your application wasn't designed or intended to carry PHI.

If your application collects PHI, whether by design or not, it must be HIPAA compliant. Simply stating that the application wasn't intended to collect or store PHI is not a valid explanation during a HIPAA audit or breach.

Using a HIPAA hosting environment is also not enough to meet HIPAA requirements. HIPAA hosting typically meet just one aspect—the physical safeguards—of the law, and HIPAA requires compliance to technical, physical and administrative requirements.

What is a Covered Entity Under HIPAA?

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. Covered entities use PHI as part of their patient care.

Healthcare Providers are exactly who you think of: hospitals, doctors, clinics, psychologists, dentists, chiropractors, nursing homes, and pharmacies. All of these entities are considered Healthcare Providers and need to be HIPAA compliant

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 and need to be HIPAA compliant.

A Healthcare Clearinghouse takes in PHI from a healthcare entity, puts the data into a standard format, and then outputs the information to another entity. They need to be HIPAA compliant too.

Covered Entities Include:

• Doctor's office, dental offices, clinics, psychologists,
• Nursing home, pharmacy, hospital or home healthcare agency
• Health plans, insurance companies, HMOs
• Government programs that pay for healthcare
• Health clearinghouses

What is a Business Associate under HIPAA?

A Business Associate is a vendor or subcontractor of a covered entity who has access to PHI.

Under HIPAA, a Business Associate is defined as any entity that uses or discloses PHI on behalf of a Covered Entity. 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.

Vendors 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.

If a Business Associate (vendor) delegates a covered function or activity to someone, then that entity is considered a subcontractor.

Some vendors avoid PHI like the plague; they don't want this information anywhere near their service. But, avoidance doesn't necessarily excuse a vendor from becoming compliant.

If a Covered Entity (customer) sends PHI through a vendor, and the vendor's servers store this information, then they are considered a Business Associate and subject to the HIPAA Security Rule.

There is No PHI Safe Harbor

Unlike other laws (DMCA anyone?) there is no "safe harbor" when it comes to HIPAA and PHI. Just because you don't want to handle PHI doesn't opt you out of HIPAA compliance requirements.

Further, just refusing to sign a Business Associate Agreement doesn't absolve you of the provisions of HIPAA compliance should your services handle PHI (intentionally or not) in any way.

Here are some examples of potential Business Associates:

• Data processing firms or software companies that may be exposed to or use PHI
• Medical equipment service companies handling equipment that holds PHI
• Shredding and/or documentation storage companies
• Consultants hired to conduct audits, perform coding reviews, etc.
• Lawyers
• External auditors or accountants
• Professional translation services
• Answering services
• Accreditation agencies
• e-prescribing services
• Medical transcription services

In contrast, these folks are NOT Business Associates:

• Covered Entity's Workforce
• Individuals or companies with very limited and incidental exposure to health information, such as a telephone company, electrician, etc.
• Companies that act as a conduit for PHI, such as the postal service, UPS, private couriers, etc.