What is HIPAA compliant app development?
HIPAA compliant app development is the process of designing, building and running a web or mobile application so that any protected health information (PHI) it handles meets the requirements of the US Health Insurance Portability and Accountability Act. In practice, that means the app, the infrastructure under it and the team that operates it all follow the HIPAA Privacy, Security and Breach Notification Rules wherever they apply.
There is no badge you can add at the end. The HIPAA Security Rule is deliberately flexible and technology neutral: it requires administrative, physical and technical safeguards that are reasonable and appropriate for your size and risks, rather than a fixed list of products. Compliance is shown through a documented risk analysis, the controls you build, your policies and your contracts. This guide explains the steps in the order most teams should take them. It is a practical engineering guide, not legal advice, so confirm your obligations with qualified counsel.
Does HIPAA apply to your app?
Start here, because the answer shapes every later decision. HIPAA applies to covered entities (health plans, health care clearinghouses and health care providers that conduct certain transactions electronically) and to their business associates. A business associate is a person or company that creates, receives, maintains or transmits PHI on behalf of a covered entity, and that includes the software vendors and cloud providers behind them.
PHI is individually identifiable health information: data about a person's health, care or payment for care that identifies them or could reasonably be used to identify them. A name, email address or device ID becomes PHI when it is linked to that kind of health information inside a regulated relationship.
| Scenario | Usually covered by HIPAA? | Why |
|---|---|---|
| A clinic's patient portal or telehealth app, built for or run on behalf of the clinic | Yes | The developer creates, receives or maintains PHI for a covered entity, so it is a business associate |
| A SaaS platform sold to hospitals or insurers that stores patient records | Yes | The vendor is a business associate of each covered entity customer |
| A consumer fitness or wellness app people download and use on their own | Often no | No covered entity is involved, but FTC rules and state privacy laws may still apply |
| A consumer app that receives records from a provider at the patient's direction | Usually no for the app | Once data reaches an app the individual chose, it is generally outside HIPAA, though other laws can apply |
If HIPAA does not apply, other rules may
Consumer health apps that fall outside HIPAA can still be regulated. The FTC's Health Breach Notification Rule requires many vendors of personal health records and related entities to notify users, the FTC and in some cases the media after a breach, and the FTC Act prohibits deceptive or unfair data practices. US states also have their own health and consumer privacy laws. HHS keeps a page of resources for mobile health app developers, including an interactive tool that points to the federal laws likely to apply to your app.
HIPAA compliant app development in 9 steps
The steps below follow the order in which decisions depend on each other. Compliance work runs alongside product work from the first sprint, rather than as an audit at the end, which is much cheaper than retrofitting controls into a finished app.
1. Confirm your role and scope
Decide whether you are a covered entity, a business associate, a subcontractor of a business associate or outside HIPAA altogether, and write the reasoning down. Then define which features will touch PHI. Many teams reduce risk and cost by keeping some features, such as marketing pages or anonymous content, completely free of PHI.
2. Map every place PHI goes
Draw a data flow diagram that shows where PHI is collected, processed, stored, transmitted, displayed and deleted. Include the less obvious paths: application logs, error trackers, analytics tools, push notifications, email and SMS, support tickets, file uploads, backups, test environments and any AI or third-party APIs. This map is the foundation of your risk analysis and of your vendor list.
Apply data minimization while you map. Every field you do not collect is one you never have to protect, so ask whether each piece of PHI is truly needed for the feature.
3. Run a documented risk analysis
The Security Rule requires an accurate and thorough assessment of risks and vulnerabilities to the confidentiality, integrity and availability of electronic PHI (ePHI). HHS publishes guidance on risk analysis that describes what it should cover. For an app, list the threats to each part of the data flow, rate likelihood and impact, record the controls you will use and keep the results in a risk register that you update when the system changes.
4. Choose infrastructure and vendors that will sign a BAA
Any vendor that creates, receives, maintains or transmits ePHI for you needs a business associate agreement (BAA). HHS guidance on HIPAA and cloud computing states that a cloud provider storing ePHI is a business associate even if the data is encrypted and it has no decryption key. Major cloud platforms offer BAAs, but they usually cover only specific services, so check that each database, storage, messaging, email, monitoring or AI service you plan to use is on the covered list before PHI touches it.
5. Design the architecture around the safeguards
Build the technical safeguards into the design rather than bolting them on. Separate PHI from non-PHI data where possible, isolate production from development and test environments, define roles before writing permission checks and plan how audit events will be captured and protected. Our guide to the mobile app development process covers the wider discovery, design and build stages that these choices sit within.
6. Build with secure engineering practices
Use code review, dependency and secret scanning, static analysis and infrastructure as code so that controls are consistent and reviewable. Keep PHI out of logs, crash reports and analytics events by default, and use synthetic or properly de-identified data outside production.
7. Test security and privacy, not just features
Add automated tests for access rules, session timeouts and audit logging alongside functional tests, then run vulnerability scans and an independent penetration test before launch and after major changes. Our test automation strategy guide explains how to keep those checks running on every release.
8. Put the paperwork in place
HIPAA compliance is not only code. You need written security policies and procedures, an assigned security official, workforce training, an incident response plan, a contingency plan covering backup and disaster recovery, and signed BAAs with customers and vendors. The Security Rule requires this documentation to be kept for six years from when it was created or last in effect, whichever is later.
9. Operate, monitor and review
After launch, review audit logs and alerts, patch promptly, rerun the risk analysis when you add features or vendors and periodically evaluate whether your safeguards still work. Customers will often ask for this evidence through security questionnaires, so keep it current.
Technical safeguards to build into the app
The Security Rule's technical safeguards are access control, audit controls, integrity, person or entity authentication and transmission security. Some implementation specifications are required and others are addressable. Addressable does not mean optional: you must implement it where reasonable and appropriate, or document why not and use an equivalent alternative.
| Safeguard | What it means in the app |
|---|---|
| Access control | Unique user accounts, role-based permissions on the principle of least privilege, automatic logoff after inactivity, emergency access procedure |
| Audit controls | Tamper-resistant logs of who viewed, created, changed, exported or deleted ePHI, with alerts on unusual activity |
| Integrity | Validation, change history and checks that detect improper alteration or deletion of records |
| Authentication | Strong sign-in, with multi-factor authentication for clinicians, administrators and support staff |
| Transmission security | TLS for all traffic, including internal services, APIs and webhooks |
| Encryption at rest (addressable) | Encrypted databases, file storage, backups and on-device caches, with managed keys and rotation |
Mobile-specific safeguards
Phones and tablets are easy to lose, so treat the device as untrusted.
- Store as little PHI on the device as possible, and use the platform's secure storage for anything that must be cached.
- Avoid showing health details in push notifications, email subjects or app switcher screenshots.
- Support remote sign-out and require re-authentication, such as biometrics or a PIN, after inactivity.
- Check third-party SDKs for analytics, advertising or crash reporting before adding them, because they can transmit identifiers and usage data to vendors without a BAA.
Where PHI most often leaks
In practice, many HIPAA problems in apps come from data ending up somewhere nobody planned for, rather than from broken encryption. Check these places early and again before every major release.
- Application logs, error trackers and performance traces that capture full request or response bodies.
- Product analytics, session replay and marketing pixels on pages that show health information.
- Support tools, shared screenshots and chat transcripts.
- Development and staging environments loaded with copies of production data.
- Prompts and responses sent to AI models or other APIs that are not covered by a BAA.
- Exports and reports emailed as attachments or saved to personal devices.
Using de-identified data for testing and analytics
Information that has been de-identified under the HIPAA Privacy Rule is no longer PHI, which makes it useful for analytics, product research and realistic test data. HHS de-identification guidance describes two methods: Safe Harbor, which removes 18 listed types of identifiers and requires no actual knowledge that the rest could identify someone, and Expert Determination, where a qualified expert documents that the risk of re-identification is very small. Removing names alone is not enough, and identifiers hidden in free-text fields count too.
If you plan to build reporting or machine learning on health data, design the de-identification pipeline as part of your data analytics strategy rather than as a one-off export.
Breach notification: plan before you need it
Under the HIPAA Breach Notification Rule, covered entities must notify affected individuals without unreasonable delay and no later than 60 days after discovering a breach of unsecured PHI, and must notify HHS and, for larger breaches, the media. Business associates must notify the covered entity within the same 60-day limit, and BAAs often set shorter deadlines. PHI encrypted to the standard in HHS guidance is not considered unsecured, which is one more reason to encrypt properly. Build the logging and alerting you will need to detect, investigate and scope an incident, and rehearse your response plan before launch.
Common HIPAA app development mistakes
These are the mistakes that most often turn into rework, failed security reviews or real exposure.
- Assuming a vendor is compliant because its marketing says so, without a signed BAA covering the specific service used.
- Treating encryption as the whole answer while ignoring access control, audit logs and backups.
- Leaving the risk analysis until just before launch, when design changes are expensive.
- Adding analytics or advertising SDKs to screens that display health information.
- Using real patient data in development and test environments.
- Claiming the app is "HIPAA certified". HHS does not certify software, so the claim is misleading.
What drives the cost of a HIPAA compliant app?
Compliance adds work to discovery, architecture, testing and documentation, so a HIPAA compliant app generally costs more than an equivalent app that handles no health data. The main drivers are:
- How much PHI the app handles and how many places it flows to.
- The number of integrations, such as electronic health record systems, labs, payment and messaging providers.
- Platforms in scope: web, iOS, Android or all three.
- Audit logging, reporting and administrative tooling requirements.
- Independent penetration testing and any additional assessments your customers require, such as SOC 2 or HITRUST.
- Hosting on BAA-covered services, monitoring and ongoing maintenance.
How InSol Technologies builds HIPAA-ready applications
InSol Technologies works with healthcare organizations and health technology companies on patient portals, clinical workflow tools and connected SaaS platforms. Our web and mobile development and software engineering teams design PHI handling and safeguards into the architecture from discovery, our cloud and DevOps engineers build environments on BAA-covered services with infrastructure as code, and our quality engineering team adds security and access tests to every release. For health tech products sold to multiple providers, our SaaS product development team designs tenant isolation and audit trails that customers' security reviews expect.
We work alongside your compliance and legal advisers rather than replacing them. If you are planning a health app or need to bring an existing one up to HIPAA requirements, talk to our team.
Frequently asked questions
- What makes an app HIPAA compliant?
- An app is HIPAA compliant when the organization behind it meets the HIPAA Privacy, Security and Breach Notification Rules for the PHI the app handles. That includes a documented risk analysis, technical safeguards such as access control, audit logging, authentication and encryption, signed business associate agreements with customers and vendors, written policies, staff training and an incident response plan.
- Is there an official HIPAA certification for apps?
- No. HHS does not certify or endorse software, apps or cloud providers as HIPAA compliant. Organizations show compliance through their risk analysis, safeguards, policies and contracts. Customers may also ask for independent assessments such as SOC 2 or HITRUST, but those are separate from HIPAA itself.
- Does a wellness or fitness app need to be HIPAA compliant?
- Not always. A consumer app that people download and use on their own, without a covered entity involved, is often outside HIPAA. It may still be subject to the FTC Act, the FTC Health Breach Notification Rule and state privacy laws. If the app is built for, or offered on behalf of, a provider or health plan and handles PHI for them, HIPAA usually applies.
- Can we use AWS, Azure or Google Cloud for a HIPAA compliant app?
- Yes, provided you sign the provider's business associate agreement and use only the services it covers, then configure them securely. Signing the BAA does not make your app compliant on its own: you remain responsible for how you configure access, encryption, logging, backups and the application itself.
- How long does it take to build a HIPAA compliant app?
- It depends on scope, platforms, integrations and how much PHI the app handles. Compliance adds time for risk analysis, security design, testing and documentation, but that time is much smaller when it is planned from the start than when controls are retrofitted. A short discovery phase gives a realistic timeline for your specific app.