Application Developers Guide to HIPAA Compliance

HIPAA
COMPLIANCE
DEVELOPER
GUIDE
Brought To You By

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

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

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

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

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

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

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.

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 hello@truevault.com. 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.

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

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.

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.

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

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.

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.

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?

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

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

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

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.

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

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.

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?

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.

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

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.

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.

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

“[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

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

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?

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.

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

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.

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.

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.

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

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

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.

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

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

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

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

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

Application Developers Guide to HIPAA Compliance

Application Developers Guide to HIPAA Compliance

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (15)

Ähnlich wie Application Developers Guide to HIPAA Compliance

Ähnlich wie Application Developers Guide to HIPAA Compliance (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Application Developers Guide to HIPAA Compliance