How to Build a HIPAA Compliant App: A Plain Guide

First, find out if HIPAA applies to you

Not every health app falls under HIPAA. The rules apply to covered entities, such as clinics, hospitals and health plans, and to business associates, which are the companies that handle protected health information on their behalf.

If you are building an app for a clinic that stores or sends patient information, you are almost certainly a business associate. The United States Department of Health and Human Services publishes guidance for app developers that walks through the common cases. Read it before you scope anything.

What counts as protected health information

Protected health information is health information that can be tied to a person. Names, dates, phone numbers, email addresses, photos and record numbers all count when they sit beside health details. HHS lists 18 identifiers.

The practical rule: if your app knows who someone is and anything about their health or care, treat it as protected.

What the Security Rule asks for

The Security Rule groups its requirements into three kinds of safeguards. In build terms, they look like this.

Administrative. A named person responsible for security. A written risk assessment. Staff training. A plan for what happens if something goes wrong.

Physical. Control over the devices and facilities where data lives. With cloud hosting, much of this is handled by the provider, but you remain responsible for choosing one that will sign an agreement with you.

Technical. This is where most of the engineering goes:

• Access control. Each user has their own login and sees only what their role allows.
• Audit logs. A record of who viewed or changed what, and when.
• Encryption. Data protected in transit and at rest.
• Integrity. Protection against records being altered or destroyed improperly.
• Automatic logoff and session limits.

Agreements you need in place

A business associate agreement is a contract that sets out how protected health information will be handled. You need one with the clinic or organization you serve, and with every vendor that touches the data: your cloud host, your messaging provider, your analytics tool.

Check this early. If a service will not sign one, you cannot send it patient data, and that can rule out tools you were planning to use.

Decisions that are hard to change later

Some choices are cheap in week one and expensive in month six.

1. Where data is stored. Choose hosting that supports your obligations before you write data to it.
2. How users are identified. Shared logins break access control and audit logs at once.
3. What is logged. Audit logging added late means reworking most screens.
4. What goes into notifications. Text messages and emails should not carry health details.
5. Third-party tools. Analytics and crash reporting can capture data you did not intend to share.

How much work it adds

Compliance is a real part of the build. In our planning, HIPAA work is about 280 hours on top of the features themselves. That covers access controls, logging, encryption, documentation and review.

It is far cheaper as part of the first build than as a retrofit.

What it looks like done well

A group of clinics across the United States and Canada replaced paper intake with a compliant digital intake app. In an illustrative set of 12 clinics, intake time fell 61 percent, 89 percent of forms were completed before arrival, and form errors dropped 72 percent. Read the case study.

A short checklist

1. Confirm whether you are a covered entity or a business associate.
2. Map the data and cut what you do not need.
3. Choose hosting and vendors that will sign an agreement.
4. Build access control, audit logs and encryption from the start.
5. Write down your risk assessment and your incident plan.