45
HIPAA COMPLIANCE DEVELOPER GUIDE Brought To You By

Application Developers Guide to HIPAA Compliance

Embed Size (px)

DESCRIPTION

Software developers building mobile health applications need to be HIPAA compliant if their application will be collecting and sharing protected health information. This free plain language guide gives developers everything they need to know about mobile health app development and HIPAA. Not every mHealth app needs to be HIPAA compliant. Not sure whether your mHealth application needs to be HIPAA compliant or not? Read the guide to find out!

Citation preview

Page 1: Application Developers Guide to HIPAA Compliance

HIPAACOMPLIANCEDEVELOPERGUIDE

Brought To You By

Page 2: Application Developers Guide to HIPAA Compliance

Table of Contents

01. Introduction

2013 Final Omnibus Rule Update

Why this guide?

Who is this guide for?

Build on our work

Questions/Feedback

Mandatory Disclaimer

02. What is HIPAA?

Background

2013 Final Omnibus Rule Update

The Four Rules of HIPAA

Important Terms to Know

Protected Health Information

The Difference Between PHI and Consumer Health Information

Covered Entity

Business Associate

No Safe Harbor Clause

Page 3: Application Developers Guide to HIPAA Compliance

03. Do I Need to Be HIPAA Compliant?

Who Needs to Be HIPAA Compliant?

04. HIPAA Security Rule

3 Parts to the HIPAA Security Rule

Administrative Safeguards

Technical Safeguards

Access Control Requirements

Transmission Security

Audit and Integrity

Physical Safeguards

Facility Access Controls

Device and Media Controls

Workstation Security

Required vs. Addressable Specifications

05. Becoming HIPAA Compliant

What Does HIPAA Require

What it Means for Developers

If We’re Being Honest

Page 4: Application Developers Guide to HIPAA Compliance

06. Who Certifies HIPAA Compliance

The Short Answer

But Texas

07. HIPAA Fines

Unencrypted Data

Employee Error

Data Stored on Devices

Business Associates

08. Developer Considerations

Build vs. Buy

Unintended Use Cases

HIPAA Hosting and Compliance

Does Using HIPAA Hosting Make My Application HIPAA Compliant?

What Data Should Be Stored in HIPAA Compliant Hosting Environments?

What Makes a Hosting Environment HIPAA Compliant?

Network and Application Security

High-Availability and Redundancy

Required vs. Addressable HIPAA Implementation Specifications

Page 5: Application Developers Guide to HIPAA Compliance

09. Mobile Applications

Use Cases

PHI in the Application

User Communication

Email

Database/API Calls

Push Notifications

Physical Phone Security

Using the Lock Screen

Enabling Remote Wiping of Lost Phones

10. Wearable Applications

Considerations for Wearables

Alerts and Notifications

Default Displays

APIs and Data Sharing

Medical Devices

Data Encryption

Data Synching

11. Apple HealthKit and iOS 8

TrueVault iOS 8 SDK

iOS 8 Health-Related Announcements

Apple HealthKit Announcements

Page 6: Application Developers Guide to HIPAA Compliance

12. About TrueVault

Built for Developers Like You

HIPAA Compliant

BAA + Insurance

Startups

Mobile Apps

Web Apps

Wearable Health Tech Devices

Why People Like TrueVault

Try TrueVault for Free

Page 7: Application Developers Guide to HIPAA Compliance

1 Introduction

01

HIPAA, the Health Insurance Portability and Accountability Act, was passed in 1996,

and among other things, outlines the requirements for the management of, storage and

transmission of protected health information (PHI) in both physical and digital form. And while

the original legislation pre-dates the rise of the commercial Internet (and the iPhone by a

decade) its rules govern the use of this special type of personal data by applications on the

web and mobile devices.

With any twenty year old piece of legislation that was written in a world without smartphones,

tablets, and heck, even webmail, HIPAA is full of requirements that are confusing and

challenging, particularly for software developers who have to make sense of them as they

relate to their product and the underlying technologies that we all use on a regular basis to

build and deliver applications to our customer bases.

2013 Final Omnibus Rule Update

In September of 2013, the Final Omnibus Rule Update was passed that amended HIPAA

and greatly expanded the definition of who needed to be HIPAA compliant. Previously,

only covered entities (such as doctors, hospitals, and insurers) were required to be HIPAA

compliant. With the recent rule change however, all entities that store, manage, record or

pass Protected Health Information (we’ll just call it PHI from now on) to and from covered

entities are also required to be HIPAA compliant. These entities, called Business Associates,

who were previously exempt from HIPAA, now fall under its governance.

Introduction

Page 8: Application Developers Guide to HIPAA Compliance

2 Introduction

Why this guide?

As you can imagine, complying with federal regulations around privacy and healthcare data is

no small task. That’s why we’ve created this guide—to help you wade through what you need

to know about HIPAA compliance as it relates to your application and what steps you’ll need

to take to ensure you don’t end up in violation of the law.

There is plenty to read about HIPAA guidelines, and if you want you can spend a good

chunk of the rest of the year reading up on all the details. Therefore, we’re not going to

rewrite everything here. This guide is not meant to be comprehensive, but rather give you

a framework and reference to help you understand the major portions of the law that apply

directly to the software you’re developing for mobile, web and wearable applications.

Who is this guide for?

If you’re a developer building a web, mobile or wearable software application that deals in the

collection, storage, or transmission of personally identifiable health information to covered

entities like doctors this is for you. You’ll get the ins and outs of HIPAA compliance guidelines

and the steps you’ll want to take to ensure you’re within those guidelines in the development,

hosting, and communication with your users.

From a breakdown of the terms and requirements, to specific examples of HIPAA-covered

activities, we’ve tried to give you what you need to understand the laws in plain language so

that you can make the right decisions when developing your application.

Whether you decide that your application falls under HIPAA guidelines or not, this guide will

give you the information you need to make that decision.

Build on our Work

This guide is the just the beginning. We hope you’ll help us build it out further to make it the

go-to source for information on HIPAA compliance and software development.

Page 9: Application Developers Guide to HIPAA Compliance

3 Introduction

Questions/Feedback

Feel free to leave comments directly here. We’ll be monitoring and responding to anything

here. Rather discuss something directly?

You can drop us a line any time at [email protected]. We’d love to hear from you.

Mandatory disclaimer

We’re software developers just like you, but we’ve spent countless hours researching,

studying and learning the ins and outs of HIPAA compliance. We’ve worked with industry

experts and attorneys to understand the various portion of the law. In short, we think we have

a solid handle on it.

However, we need to be clear—we’re not lawyers and you should not take this as legal

advice. If you need to make business decisions around HIPAA you’ll probably sleep better

at night knowing you paid a very expensive attorney to give their opinion on your specific

question.

Page 10: Application Developers Guide to HIPAA Compliance

What is HIPAA?02

HIPAA is short for the Health Insurance Portability and Accountability Act.

HIPAA sets the standard for protecting sensitive patient data. The law states that Covered

Entities and their Business Associates need to protect the privacy and security of protected

health information (PHI).

Background

Developed in 1996 HIPAA was initially created to help the public with insurance portability.

Back in the day you couldn’t easily switch insurances if you didn’t like the coverage or doctors

that provided services under that insurance. It was a huge pain getting your medical records

from one practitioner to another.

Along with portability came privacy concerns, to the law makers built in a series of privacy

tools and requirements to protect healthcare data.

2013 Final Omnibus Rule Update

In September of 2013, the Final Omnibus Rule Update was passed that amended HIPAA

and greatly expanded the definition of who needed to be HIPAA compliant. Previously,

only covered entities (such as doctors, hospitals, and insurers) were required to be HIPAA

compliant.

4 What is HIPAA?

Page 11: Application Developers Guide to HIPAA Compliance

5 What is HIPAA?

With the recent rule change however, all entities that store, manage, record or pass Protected

Health Information (we’ll just call it PHI from now on) to and from covered entities are also

required to be HIPAA compliant.

These entities, called Business Associates, who were previously exempt from HIPAA, now fall

under its governance.

The Four Rules of HIPAA

Like the four horsemen, these are the major pieces that govern what you do and

how you do it.

• HIPAA Privacy Rule

• HIPAA Security Rule

• HIPAA Enforcement Rule

• HIPAA Breach Notification Rule

Developers need to focus on the Technical and Physical safeguards outlined in the Security

Rule.

Important terms to know

Protected Health Information (PHI)

You will hear this term non-stop when dealing with applications that can store health

information. It’s typically called PHI although some parts of the law refer to digitally-stored PHI

as ePHI. We’ll stick with PHI for consistency.

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

Page 12: Application Developers Guide to HIPAA Compliance

6 What is HIPAA?

In other words, PHI is information in your medical records, including conversations between

your doctors and nurses about your treatment. PHI also includes your billing information and

any medical information in your health insurance company’s computer system.

Some 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 non-PHI data:

• 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

So how do you know if you’re dealing with protected health information (PHI) or consumer

health information? The test is pretty simple: if your device or application stores, records or

transmits the user’s personally-identifiable health data held in the app or device to a covered

entity (see below) 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.

Page 13: Application Developers Guide to HIPAA Compliance

7 What is HIPAA?

For example, the Nike Fuel Band is not HIPAA compliant because it does not track data

considered protected health information because you can’t transmit that data from the device

to a covered entity.

Covered Entity

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.

This one is pretty straightforward. Healthcare Providers are exactly who you might think:

hospitals, doctors, clinics, psychologists, dentists, chiropractors, nursing homes, and

pharmacies are considered Healthcare Providers and need to be HIPAA compliant.

Examples of 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.

Healthcare Clearinghouses are a little more esoteric. 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. 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 clearing houses

Page 14: Application Developers Guide to HIPAA Compliance

8 What is HIPAA?

Business Associate

Simply put, 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.

The vendors that we are talking about can be data storage or document storage services

(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 heath 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.

No safe harbor clause

Unlike other laws (DMCA anyone?) there is no “safe harbor” here. 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.

Page 15: Application Developers Guide to HIPAA Compliance

9 What is HIPAA?

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

Page 16: Application Developers Guide to HIPAA Compliance

10 Do I Need to Be HIPAA Compliant?

Do I Need to Be HIPAA Compliant?03

This is the most important question you can ask, because HIPAA violations can result in some

serious penalties.

If you handle, store or transmit protected health information (PHI) to or from a covered entity

then you need to be HIPAA compliant.

If you skipped straight here and don’t know what PHI is, read this part of the guide.

Who needs to be HIPAA compliant?

The short answer is that the HIPAA rules apply to both Covered Entities and their Business

Associates. HHS.gov

What’s a Covered Entity?

Who is considered a Business Associate?

Page 17: Application Developers Guide to HIPAA Compliance

11 HIPAA Security Rule

04

Outlines national security standards intended to protect health data created, received,

maintained, or transmitted electronically.

3 Parts to the HIPAA Security Rule

1. Administrative Safeguards

2. Technical Safeguards

3. Physical Safeguards

Administrative Safeguards

The administrative components are really important when implementing a HIPAA compliance

program; you are required to:

• Assign a privacy officer

• Complete a risk assessment annually

• Implement employee training

• Review policies and procedures

• Execute Business Associate Agreements (BAAs) with all partners who handle

protected health information (PHI)

Companies like Accountable can help with the administrative components of a compliance

program.

The HIPAA Security Rule

Page 18: Application Developers Guide to HIPAA Compliance

12 HIPAA Security Rule

• Accountable -- http://accountablehq.com

• Compliance Helper -- http://www.compliancehelper.com

• Compliancy Group -- http://compliancy-group.com

Technical Safeguards

Technical safeguards outline what your application must do while handling PHI.

While there are both required and addressable elements to these safeguards you should

implement them all. Addressable elements (such as automatic logoff) are really just best

practices.

Access Control Requirements

• Unique User Identification (required): Assign a unique name and/or number for

identifying and tracking user identity.

• Emergency Access Procedure (required): Establish (and implement as needed)

procedures for obtaining necessary ePHI during an emergency.

• Automatic Logoff (addressable): Implement electronic procedures that terminate an

electronic session after a predetermined time of inactivity.

• Authentication (required): Implement procedures to verify that a person or entity

seeking access to ePHI is the one claimed.

• Encryption and Decryption (addressable): Implement a mechanism to encrypt and

decrypt ePHI.

Transmission Security

• Integrity Controls (addressable): Implement security measures to ensure that

electronically transmitted ePHI is not improperly modified without detection until

disposed of.

• Encryption (addressable): Implement a mechanism to encrypt ePHI whenever deemed

appropriate.

Page 19: Application Developers Guide to HIPAA Compliance

13 HIPAA Security Rule

Audit and Integrity

• Audit Controls (required): Implement hardware, software, and/or procedural

mechanisms that record and examine activity in information systems that contain or

use ePHI.

• Mechanism to Authenticate ePHI (addressable): Implement electronic mechanisms to

corroborate that ePHI has not been altered or destroyed in an unauthorized manner.

Physical Safeguards

The Physical Safeguards really have to do with who has access to PHI data and how that

access is managed. Much of the Physical Safeguard requirements that developers need to

worry about are handled by HIPAA compliant hosting companies (such as TrueVault, AWS,

Firehost and Rackspace).

Other parts of the Physical Safeguards are handled by your internal rules around who can and

can’t access PHI.

Facility Access Controls

• Contingency Operations (addressable): Establish (and implement as needed)

procedures that allow facility access in support of data restoration under the disaster

recovery and emergency operations plan in the event of an emergency.

• Facility Security Plan (addressable): Implement policies and procedures to safeguard

the facility and the equipment therein from unauthorized physical access, tampering,

and theft.

• Access Control and Validation Procedures (addressable): Implement procedures to

control and validate a person’s access to facilities based on their role or function,

including visitor control, and control of access to software programs for testing and

revision.

• Maintenance Records (addressable): Implement policies and procedures to document

repairs and modifications to the physical components of a facility which are related to

security (e.g. hardware, walls, doors, and locks).

Page 20: Application Developers Guide to HIPAA Compliance

14 HIPAA Security Rule

Device and Media Controls

• Disposal (required): Implement policies and procedures to address the final

disposition of ePHI, and/or the hardware or electronic media on which it is stored.

• Media Re-Use (required): Implement procedures for removal of ePHI from electronic

media before the media are made available for re-use.

• Accountability (addressable): Maintain a record of the movements of hardware and

electronic media and any person responsible therefore.

• Data Backup and Storage (addressable): Create a retrievable, exact copy of ePHI,

when needed, before movement of equipment.

Workstation Security

• Workstation Security (required): Implement physical safeguards for all workstations

that access ePHI, to restrict access to authorized users.

• Workstation Use (required): Implement policies and procedures that specify the proper

functions to be performed, the manner in which those functions are to be performed,

and the physical attributes of the surroundings of a specific workstation or class of

workstation that can access ePHI.

Required vs. addressable specifications

Some implementation specifications are “required” and others are “addressable.” Required

implementation specifications must be implemented.

Addressable implementation specifications must be implemented if it is reasonable and

appropriate to do so; your choice must be documented.

It is important to remember that an addressable implementation specification is not optional.

When in doubt, you should just implement the addressable implementation specifications.

Most of them are best practices anyway.

Page 21: Application Developers Guide to HIPAA Compliance

15 Becoming HIPAA Compliant

05

The HIPAA Security Rule requires having the appropriate Administrative, Physical, and

Technical Safeguards in place to ensure the confidentiality, integrity, and security of protected

health information (PHI).

In other words, you need to cover all three bases in order to be compliant per the HIPAA

guidelines.

What does HIPAA require?

HIPAA as a law requires that you do the following four things.

1. Put safeguards in place to protect patient health information.

2. Reasonably limit use and sharing to the minimum necessary to accomplish your intended

purpose.

3. Have agreements in place with service providers that perform covered functions.

These Business Associate Agreements (BAAs) ensure that service providers (Business

Associates) use, safeguard and disclose patient information properly.

4. Procedures to limit who can access patient health information, and training programs

about how to protect patient health information.

What it means for developers

If you are collecting, storing or transmitting PHI to a covered entity then you definitely should

be HIPAA compliant.

Becoming HIPAA Compliant

Page 22: Application Developers Guide to HIPAA Compliance

16 Becoming HIPAA Compliant

If you’re building an application that has any reasonable likelihood of collecting, storing or

transmitting PHI you should probably be HIPAA compliant.

Your non-technical team or (co-founder, depending on your size) should worry about the

administrative compliance issues. As the developer you should focus both on the physical

and technical aspects of the law.

You can really go about it in one of three ways:

1. Decide that you’re not going to have PHI in your system and don’t need to worry about

HIPAA compliance. This is the easiest choice, but remember, there’s no safe harbor with

HIPAA.

2. Decide that you’ll build out the compliance requirements yourself. Many of the safeguards

are standard parts of today’s apps, login, auto-logout, etc. You can build many of these as

part of your core infrastructure. Others are not so easy to build and maintain.

3. You outsource your HIPAA compliance. Using a service like TrueVault you are guaranteed

compliance with the technical and physical safeguard requirements by storing any PHI in

the cloud in TrueVault’s secure data store. Learn more

If we’re being honest

It’s not worth taking the risk of HIPAA compliance audits and penalties if you have even a

small chance of managing PHI within your application.

Page 23: Application Developers Guide to HIPAA Compliance

17 Who Certifies HIPAA Compliance

06

The short answer is no one.

Unlike PCI, there is no one that can “certify” that an organization is HIPAA compliant. The

Office for Civil Rights (OCR) from the Department of Health and Human Services (HHS) is the

federal governing body that determines compliance. HHS does not endorse or recognize the

“certifications” made by private organizations.

There is an evaluation standard in the Security Rule § 164.308(a)(8), and it requires you to

perform a periodic technical and non-technical evaluation to make sure that your security

policies and procedures meet the security requirements outlined in the rule. HHS doesn’t

care if the evaluation is performed internally or by an external organization—just as long as it

happens.

That said, being evaluated by an independent, third party auditor is still a really good idea.

Even though it’s not official you should still do it. There are a number of great companies that

can help you with this process. For example, Coalfire Systems and ComplySmart offer HIPAA

Assessments that can let you know how you stack up to the requirements outlined by the

legislation.

This is important. Even if you get a “certification” from an external organization, HHS can still

come in and find a security violation. Third party audits and “certifications” do not absolve you

from your legal obligations under the Security Rule.

Who Certifies HIPAA Compliance?

Page 24: Application Developers Guide to HIPAA Compliance

18 Who Certifies HIPAA Compliance

But Texas

It is interesting to note that Texas is the first state to create a formal Covered Entity Privacy

and Security Certification Program to help eliminate this ambiguity. The program was

developed as part of Texas’ House Bill (HB) 300. The Texas Health Services Authority (THSA)

and the Health Information Trust Alliance (HITRUST) partnered to implement the Certification

Program.

They will tell you that the Texas state law protecting patients’ health information is more

stringent than HIPAA. So in theory, if you are certified by the THSA, then you are ipso facto

HIPAA compliant.

Don’t hold us to that because HHS does not endorse or otherwise recognize this claim. But,

considering the absence of a federal seal of approval, this is a fantastic program and a step in

the right direction.

Page 25: Application Developers Guide to HIPAA Compliance

HIPAA Fines07

HIPAA violations are expensive. The penalties for noncompliance are based on the level of

negligence and can range from $100 to $50,000 per violation (or per record), with a maximum

penalty of $1.5 million per year for violations of an identical provision. Violations can also carry

criminal charges that can result in jail time.

Fines will increase with the number of patients and the amount of neglect. Starting with a

breach where you didn’t know and, by exercising reasonable diligence, would not have

known that you violated a provision. To the other end of the spectrum where a breach is due

to negligence and not corrected in 30 days. In legalese, this is known as mens rea (state of

mind). So fines increase in severity from no mens rea (didn’t know) to assumed mens rea

(willful neglect).

The fines and charges are broken down into 2 major categories: “Reasonable Cause” and

“Willful Neglect”. Reasonable Cause ranges 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.

HIPAA violation categories and their respective penalty amounts are outlined in the chart below:

19 HIPAA Fines

Source: HHS, Federal Register.gov

Page 26: Application Developers Guide to HIPAA Compliance

20 HIPAA Fines

Unencrypted Data

While encryption is an addressable (rather than required) specification, it does not mean

optional. The vast majority of data breaches are due to stolen or lost data that was

unencrypted. When in doubt, you should implement the addressable implementation

specifications of the Security Rule. Most of them are best practices.

Employee Error

Breaches can occur when employees lose unencrypted portable devices, mistakenly send

PHI to vendors who post that information online, and disclose personally identifiable, sensitive

information on social networks.

These are all examples from actual cases. Employee training and adherence to security

policies and procedures is extremely important.

Data Stored on Devices

Almost half of all data breaches are the result of theft. When laptops, smartphones, etc. are

unencrypted the risk of a breach increases considerably. With TrueVault, your data is safely

stored off-premise; so that stolen laptop just has a token on it, and no PHI is compromised.

Business Associates

Almost two-thirds of data breaches involved a business associate. Meaning that you

delegated a covered function or activity to someone, and that someone messed up. So pick

your partners carefully.

Some of the largest breaches reported to HHS have involved business associates. As a result,

the final omnibus rule expanded many of the requirements to business associates and greatly

enhanced the government’s ability to enforce the law.

Page 27: Application Developers Guide to HIPAA Compliance

21 HIPAA Fines

What sort of penalties are we talking about?

Check out this chart with fines levied in years past:

Source: HHS, Case Examples and Resolution Agreements

Looking at this chart we can conclude that HHS does not like people storing unencrypted PHI

on mobile devices. What we don’t see yet are fines levied against business associates.

2014 is the first year where business associates will be audited and fined. Smart money says

that the first fines levied against business associates will be passed down toward the end of

this year.

If these fines make you nervous, then this might be a good time to revisit your decision about

whether your application needs to be HIPAA compliant or not.

The good news is that not every PHI breach ends in a fine. If you can show that you have

made a reasonable effort to comply with HIPAA then you may not be dinged.

Page 28: Application Developers Guide to HIPAA Compliance

Developer Considerations08

As you’re evaluating how to best deal with HIPAA you’ll probably have some of these

questions pop-up in your deliberations. We’ll continue to add more here, but these are ones

that we’ve heard from developers tackling HIPAA in their development process.

Build vs. Buy

Scanning the list of safeguards required by HIPAA it’s not unreasonable to think first of

building out the safeguards yourself. Functionality such as unique identifiers for users and

automatic logoff are part of any application anyway, so building those is going to happen one

way or another.

Couple that with HIPAA compliant hosting providers, and it’s easy to draw the conclusion that

a combination of an AWS instance and some best practice application security wouldn’t do

the trick.

Unfortunately, the other pieces of the security rule safeguards aren’t as easy to address or

maintain and can take a ton of people-power and time to build out not just the features but

the audit and logging functionality as well.

We think this comment from Hacker News sums up the technical debt required to roll your

own HIPAA compliant infrastructure quite accurately. This was completely unsolicited and is

not from a TrueVault customer.

22 Developer Considerations

Page 29: Application Developers Guide to HIPAA Compliance

23 Developer Considerations

“[Building our own HIPAA compliant infrastructure] took upwards of 1,000 person-hours to figure out HIPAA-compliance issues. This will continue to be an ongoing cost for us, because HIPAA is an ongoing law and it changes sometimes. It takes substantial auditing time and money.”

— jph

Looking at it as a 1,000 hour project is one way to evaluate the true cost of rolling your

own compliance infrastructure, not to mention the ongoing audit and maintenance costs

associated with your in-house solution.

Unintended use cases

As we’ve mentioned before, HIPAA isn’t like the DMCA, there is no safe harbor clause for

unintended transmission, storage or disclosure of PHI. Regardless of how you planned it,

scoped it, envisioned it or dissuaded users from including it—if PHI is in your app or on your

servers you could face HIPAA fines if you’re not in compliance.

It’s not as big of an edge case as you might think. Here’s a few examples of how easily PHI

can enter into your application.

Your app to get doctor’s advice based on anonymous symptoms could easily have PHI as

soon as the patient shares an email address, lab report, or last doctor visit.

Your diabetes management app which tracks your blood sugar and prescription information

has a note added by the user of their doctor’s dosing instructions and pharmacy Rx number.

You get the idea. Regardless of how you intend for the user to use your application, there is

a pretty decent chance that if the application is related to personal health in any way, PHI will

ultimately end up in the system.

HIPAA Hosting and compliance

HIPAA hosting refers to website, application or data storage and hosting services that comply

Page 30: Application Developers Guide to HIPAA Compliance

24 Developer Considerations

with the physical safeguard requirements of the HIPAA security rule.

HIPAA hosting is an important part of the requirements needed for application developers to

ensure HIPAA compliance of their solutions.

Does Using HIPAA Hosting Make My Application HIPAA Compliant?

The short answer is no. HIPAA hosting alone does not make you HIPAA compliant.

Compliance is determined by the adherence to the privacy and security rules outlined by

HIPAA. HIPAA Hosting only addresses one aspect of those requirements.

Hosting your application in a HIPAA compliant hosting environment such as Amazon AWS or

Firehost does not make your application HIPAA compliant as they only address the physical

safeguard requirements of the HIPAA security rule.

You are still required to meet the administrative and technical specifications of the HIPAA

Security Rule in order to be compliant.

What Data Should Be Stored in HIPAA Compliant Hosting Environments?

Not all of your application data needs to exist in a HIPAA hosting environment. But any PHI

must be in a HIPAA compliant environment.

Examples of PHI

Page 31: Application Developers Guide to HIPAA Compliance

25 Developer Considerations

What Makes a Hosting Environment HIPAA Compliant?

HIPAA compliant hosting providers typically provide two main aspects of HIPAA compliance:

They sign a Business Associate Agreement with you, which is required by service providers

managing and handling HIPAA protected information. Learn more about Business Associate

Agreements.

They address many of the Physical Safeguard requirements of the HIPAA Security rule. See a

complete list of physical safeguards.

Network and application security

Ensuring your hosting environment is HIPAA compliant is only the first step. You must

also implement network and application security best practices to protect your hosting

environment.

Health information is a popular commodity for hackers. According to a recent Information

Week article, each health record could be worth as much as $20 on the black market.

It’s easy to imagine hackers trying to breach your servers when your application becomes

popular. You need to be sure your HIPAA hosting environment is locked down and secure

from unauthorized access attempts.

High-Availability and Redundancy

A good infrastructure design eliminates all single-point-of-failures. While running one web

server and one database server may save you money in the short run, how much would it

cost your business if that one web server goes offline causing the entire hosting environment

to crumble?

Page 32: Application Developers Guide to HIPAA Compliance

26 Developer Considerations

It’s best to design your hosting environment with at least 2 web servers behind a load

balancer and 2 database servers on a active/passive failover setup.

Clearly most environments are more complicated than just a 2-tier setup, so you must

implement an infrastructure design best suited for your business. But the point remains, high-

availability and redundancy are crucial parts of your HIPAA compliant infrastructure.

Required vs. Addressable HIPAA Implementation Specifications

We’ve talked about the difference between required and addressable specifications already,

but most HIPAA hosting companies should implement the addressable specifications as they

are best practice data security features any way.

Page 33: Application Developers Guide to HIPAA Compliance

Mobile Applications09

Pundits estimate that there are more than 40,000 health-related applications in AppStores

everywhere. That’s a lot of apps for an industry that by all accounts is just starting to get its

bearings when it comes to consumer technology.

That number is sure to grow, particularly if Apple goes full on ahead with its rumored

Healthbook—which is a health-related version of its integrated Passbook application.

For sure, mobile makes a ton of sense to be the platform of choice for the next generation of

patient health management tools. Tablet sales are skyrocketing past PCs, more smartphones

are being sold to more people, and the very notion of health management lends itself to a

device that you have with you all the time.

Building a health-related mobile application does have some challenges of its own,

particularly as it relates to HIPAA compliance. These special cases are why we’ve added this

section just about mobile application development and HIPAA compliance.

Use cases

As we mentioned under Developer Considerations a thorough understanding of your

application use cases is essential. We won’t rehash it all here, but definitely read up on it in

the link above.

Needless to say, it’s important to consider whether or not your app will be used to store or

transmit protected health information, regardless of how you’ve designed it or anticipate it

being used.

27 Mobile Applications

Page 34: Application Developers Guide to HIPAA Compliance

28 Mobile Applications

Even if you’ve designed your app to collect or use anonymous data that doesn’t fall under

HIPAA by itself, if a user chooses to use your app to transmit PHI to a doctor then you are

subject to HIPAA compliance requirements. Edge case or not, as soon as PHI is involved your

app falls under HIPAA.

If your application has the chance to be used to store and transmit PHI it’s a safer bet to be

HIPAA compliant to protect yourself from inadvertently violating HIPAA guidelines.

PHI in the application

PHI is information that could be used to identify an individual and that relates to their physical

or mental health, any healthcare services they have received and any information regarding

the payment for such services.

The fact that an individual has received services from a covered entity is itself PHI. Likewise,

the name or address of an individual, although publicly available, is also PHI when it’s on a

covered entity’s computer simply because its presence suggests that the individual is or was

a patient.

PHI can also include what would otherwise be anonymous information. This includes a date of

service i.e. anything more specific than a year.

If you store, collect, manage, or transmit any protected health information to covered entities

then your app needs to be HIPAA compliant.

User communication

This is another area where developers can get tripped up when it comes to HIPAA

compliance. We’re so used to building in email and app notifications that questioning whether

they can be used at all, or in a compliant manner, is a foreign concept.

The very premise of the HIPAA is to protect sensitive information, so it is paramount that you

consider how you will communicate with subscribers once they are using your app.

Page 35: Application Developers Guide to HIPAA Compliance

29 Mobile Applications

Email

Consider email. Emails are usually not compliant with HIPAA as they often lack the ability

to encrypt their contents. Therefore sending information that may contain PHI via email is a

HIPAA violation.

Because many applications use email as a communication source with users, it’s important to

understand what can and can’t be included in those communications.

If you are sending email communications that include or might include protected health

information from your mobile app you should send those emails via a HIPAA compliant email

service provider.

Database/API calls

If your application is relying on data from any covered entity (such as a doctor’s office) it

will have to be compliant. Same goes for any integration you need to do with a business

associate of a covered entity.

If your app is not compliant these covered entities will not be able to grant your app access to

make API or database calls, nor can you search and read anything within their database.

Captain obvious says “This greatly limits the functionality of your application.”

Push notifications

As we have said before, mobile phones are particularly insecure devices and the native push

notifications that are used by many applications to notify users of updates and changes run

the risk of violating the privacy regulations outlined in HIPAA.

If you’re using notifications in your mobile app, it’s critical that you do not include any PHI in

any push notifications from your app as they can appear and be publicly visible even when a

phone is locked.

Page 36: Application Developers Guide to HIPAA Compliance

30 Mobile Applications

This goes beyond just mobile push notifications. Any time you’re making an automated,

outbound push message (whether it be mobile, email, or automated calling) the same rules

apply. Make sure you evaluate all communication touch points for potential PHI/HIPAA issues.

Physical phone security

Phones are prone to being stolen, left in the back of cabs, on the table at restaurants, and

pretty much everywhere else. Because of the natural lack of security of the phone itself you

need to ensure that PHI isn’t easily accessible to unauthorized users.

Unfortunately, as a mobile app developer, most of this is out of your hands. However you can

take a few small steps to help users ensure their PHI is protected if they should lose their

phone.

Using the lock screen

In order to secure data on an iPhone (for example), users must use a passcode to lock the

handset when not in use. You can’t control whether a user enables this functionality, but you

can recommend that users who install your app enable the feature.

An easy way to do this is suggest that the user turns on the passcode lock setting in your

welcome email to new account holders.

Enabling remote wiping of lost phones

Again, not something you can control yourself, but as in the example above you can help

users make their phones more secure by taking advantage of some of the built-in functionality

of their device.

Page 37: Application Developers Guide to HIPAA Compliance

Wearable Applications10

Wearables are popping up left and right. From bands, to watches, to shirts, earbuds and more.

All of these devices have the opportunity to collect PHI and require HIPAA compliance. While

many will choose to initially collect anonymous data that doesn’t require HIPAA protection,

the need to add true utility to the devices will likely push many of them down the road to

compliance.

As an application developer for wearables it’s important to consider whether the data you’re

collecting now will remain anonymous (such as a simple pedometer report) or if you’re

building something more ambitious that requires a larger set of personalized data that will be

transmitted to HIPAA covered entities (PHI).

If it is the latter, you’re likely better off building the software for the wearable in a HIPAA

compliant environment to begin with, to protect against unforeseen use cases, unexpected

PHI, etc.

Considerations for wearables

Today’s wearables are typically “always on” with data presentation layers that are outside of

a protected lock screen or similarly private state. Therefore careful consideration needs to be

taken related to how and when health data is presented on the device.

Alerts and notifications

Much like the push notifications on mobile devices, andy alerts generated by your application

should be anonymous in nature and devoid of any PHI.

31 Wearable Applications

Page 38: Application Developers Guide to HIPAA Compliance

32 Wearable Applications

Proactively pushing PHI as part of an alert opens up all sorts of privacy concerns. What

happens if the device is on a desk at the office, for instance?

Default displays

Similarly default displays should be carefully considered. A default display contain PHI is a big

privacy issue. Even more mundane and typically anonymous data can be troublesome due to

the fact that the device is on the person.

For example, heart rate isn’t really an anonymous data point when it’s being tracked in real

time on the watch face of the person wearing it, now is it?

APIs and data sharing

One of the most exciting aspects of wearables may be in patient health management and

compliance (e.g. does the patient get their exercise in per the doctor’s orders?) In order

for these apps to be used efficiently in this use case they need to talk seamlessly with the

applications and software being run by covered entities.

Covered entities and their business associates are required by law to be HIPAA compliant,

so any application hoping to connect to one of these entities as part of patient care must be

HIPAA compliant.

Medical devices

It is possible, based on the features and functionality that you include in your application or

wearable device that it may actually be classified as a medical device. It’s important to look

up FDA regulations and check whether your app will be considered to be a medical device or

not.

If it does fall under those definitions it may require FDA approval which brings with it a whole

host of further regulations.

Don’t launch your app until you’ve determined whether or not you are safely outside the

Page 39: Application Developers Guide to HIPAA Compliance

33 Wearable Applications

FDA’s medical device classification.

Data encryption

Because most wearables lack a user interface to add or manage security features on the

device in the event it is lost or stolen, it’s important for wearable software developers to take

the appropriate precautions to encrypt the data on the device as the default.

Data synching

HIPAA requires that data recovery be possible in the event of a disaster or emergency.

Therefore, depending on the device you are developing for, you may want to take advantage

of proactive synching features instead of waiting for the user to synch the device themselves.

If the device enables background synching over bluetooth or while connected to the main

device it’s recommended that you take advantage of that opportunity to synch your user’s

data automatically.

Page 40: Application Developers Guide to HIPAA Compliance

Apple HealthKit and iOS 811

Apple is reportedly set to announce iOS 8 as part of their World Wide Developers Conference

(WWDC). One of the expected software elements of iOS 8 is HealthKit, a centralized location

of health management information such as sleep records, emergency contact information,

hydration and more.

HealthKit, from early reports, appears to be similar to Passbook, an application that lets users

manage things like airline boarding passes, concert tickets, and more via the app. Select apps

and partners, such as United Airlines and Eventbrite, are able to push their application data

into Passbook for use there.

Learn more about HealthKit and Health.

TrueVault iOS 8 SDK

In anticipation of the new health-related features for iOS 8 and HealthKit, TrueVault is gearing

up to being development on an SDK for iOS 8 in order to launch it in time with the developer

release of iOS 8 this summer.

If you’re planning on building a health-related app for iOS 8 and/or HealthKit,

you can sign up to be notified when the TrueVault SDK launches.

34 Apple HealthKit and iOS 8

Page 41: Application Developers Guide to HIPAA Compliance

35 Apple HealthKit and iOS 8

iOS 8 health-related announcements

Apple HealthKit announcements

• Apple Announces HealthKit + Health App

• HealthKit API/Fit Sample App Code - Apple Developer Library

Page 42: Application Developers Guide to HIPAA Compliance

About TrueVault12

TrueVault is a secure API to store health data. We make HIPAA compliance easier for

healthcare applications.

Built for Developers Like You

Store and search protected health information (PHI) in any file format with a simple RESTful

API. No pre-defined schemas to follow.

HIPAA Compliant

We handle all of the technical requirements mandated by the HIPAA Security Rule. Typical

integration takes days and saves months of dev time.

BAA + Insurance

TrueVault will sign a Business Associate Agreement (BAA), and protects customers under a

comprehensive Privacy/Data Breach insurance policy.

36 About TrueVault

Page 43: Application Developers Guide to HIPAA Compliance

37 About TrueVault

TrueVault is great for:

Startups

TrueVault was built to help startups simplify the complexities of HIPAA. TrueVault will save you

hundreds of dev hours. Focus on building your software’s core functionality, and let TrueVault

protect your data at HIPAA-security levels.

Mobile Apps

Store your app’s protected health data in TrueVault. We take care of HIPAA so that you can

focus on creating healthcare apps on any platform.

Web Apps

You don’t have to worry about setting up and maintaining your own HIPAA compliant

application stack. TrueVault will handle the Physical and Technical Safeguards required by

HIPAA.

Wearable Health Tech Devices

Emerging technology dances the line between consumer health data and PHI. Sharing data

with a HIPAA-defined Covered Entity (such as a doctor) makes the data PHI and it needs to be

protected at HIPAA-security levels.

Why people like TrueVault

“Becoming HIPAA compliant as an early stage organization was a daunting task, until we found TrueVault. Their turn-key API has allowed us to check this box and get back to focusing on our core product and offering.”

— Edith Elliot, Noora Health

Page 44: Application Developers Guide to HIPAA Compliance

38 About TrueVault

Try TrueVault for free

We have a free, no credit card required trial that lasts as long as you like. You can develop

on it at no cost. Only pay when you activate your account by signing our business associate

agreement.

Once live, pricing is pay-as-you-go, just $0.001 per API call. See pricing examples here.

Try TrueVault today