How to Make an App HIPAA Compliant

First, confirm whether HIPAA applies to your app

HIPAA applies to covered entities, meaning health plans, clearinghouses and providers that conduct standard electronic transactions such as claims, and to business associates that handle protected health information on their behalf. An app a clinic gives its patients is in scope. A consumer step counter a person downloads on their own usually is not, even though it holds health data. Tepia starts every compliance engagement with this question, because the answer changes vendor choices and paperwork.

Apps outside HIPAA are not free of rules. The FTC enforces its Health Breach Notification Rule against many health apps that HIPAA does not cover, and state privacy laws such as the CCPA add their own duties. If your app will later sell to clinics or health plans, Tepia usually recommends building to HIPAA standards from day one, because those buyers will ask for a BAA.

Then write down what PHI the app will create, receive, store or send, and every place it flows. That data map drives every later step.

Steps to make an app HIPAA compliant

1. Map PHI and confirm your role. Document every place PHI is created, stored, transmitted or displayed, including logs, backups, analytics and support tools.
2. Sign BAAs and restrict services. AWS, Microsoft Azure and Google Cloud sign BAAs, but only for listed eligible services, so Tepia checks each service in the architecture against that list. The same applies to email, SMS, error tracking and help desk tools: any vendor touching PHI needs a BAA or must be kept away from it.
3. Run a risk analysis. The Security Rule requires an accurate and thorough assessment of risks to electronic PHI. Record each threat, its likelihood and impact, and the control chosen.
4. Build technical safeguards. Unique user IDs, multi factor login for staff, role based access, automatic logoff, TLS in transit, encryption at rest with managed keys, integrity checks and audit logs of who viewed or changed each record.
5. Harden the mobile client. Keep tokens in the iOS Keychain or Android Keystore, keep PHI out of push text, local logs and crash reports, hide sensitive screens in the app switcher, and require biometric or PIN reentry after inactivity.
6. Put administrative safeguards in writing. Policies, workforce training, periodic access reviews, a breach response plan and a contingency plan for backups and recovery.
7. Test and keep testing. Penetration tests before launch and after major releases, regular audit log reviews, and a fresh risk analysis whenever the architecture changes.

Security Rule safeguards translated into app features

The Security Rule says what must be protected, not which tools to use. Tepia translates each safeguard into concrete features so engineers and auditors read from the same document.

Addressable does not mean optional. It means you either implement the safeguard or document why an equivalent measure is reasonable, and for encryption that argument rarely holds up. Tepia records each decision, the control chosen and the reason in the risk analysis, so the reasoning survives staff changes and is ready when a hospital security questionnaire arrives.

How Tepia approaches HIPAA compliant app work

Whether the app is new or already live, Tepia runs the work through its six phases and produces compliance artifacts alongside the software. Tepia follows HIPAA aware architecture and SOC 2 aligned practices, while your compliance officer or counsel signs off on policies.

1. Discovery: a PHI data map, a vendor and BAA inventory, and for existing apps a review of code and infrastructure. Deliverables are an Investigation Summary, an Interview Summary and User Stories such as a nurse viewing only her assigned patients.
2. Design: questionnaire, moodboards and a style guide, plus wireframes showing exactly what appears on lock screens, notifications and shared devices.
3. Development and Testing: Alpha and Beta builds on BAA covered infrastructure using synthetic data only. Test plans add non functional security tests, log scrubbing checks and access control tests by role.
4. Training: sessions for your administrators on user provisioning, access reviews and reading audit logs.
5. Launch: encrypted data migration with record counts verified, transition from the old system, and support reps on rollout.
6. Support: issue resolution, security patching, bug tracking and feature requests, each reviewed for PHI impact.

New builds follow the usual timing: Discovery 1 to 3 months, development and QA 2 to 6 months, launch about a month. Remediating an existing app depends on what the review finds. See our process.

Common HIPAA mistakes in mobile and web apps

• Analytics and ad SDKs on signed in screens. HHS has issued guidance on online tracking technologies, and third party pixels on patient screens can disclose PHI. Tepia keeps them off those screens or uses analytics covered by a BAA.
• PHI in push notifications. A lock screen is public. Send a generic alert and show details after sign in.
• Crash reports full of patient data. Scrub logs before they leave the device.
• Shared admin accounts. Without unique IDs, the audit log proves nothing.
• Assuming the cloud makes you compliant. A BAA with your cloud provider covers its side, not your configuration.
• Buying a certificate. No official HIPAA certification exists; documented safeguards do the work.

Learn more about HIPAA compliant software development, how to choose a healthcare app developer and HIPAA aware AI chatbots, or ask Tepia to review your app.

Frequently asked questions