What the phrase really means, the twelve engineering steps in brief, and what you can honestly tell a customer's security team when you are done.
This is the overview post in an eight-part guide to building healthcare software that holds up under a hospital security review. It covers what "HIPAA-compliant app" means, the twelve steps in brief, what the work costs, and what you can put in writing at the end. Each step and each platform has its own post with the details.
Key takeaways
"HIPAA-compliant app" is shorthand for something real: an application built so the organisation using it can meet its HIPAA obligations, with nothing in the software standing in the way. What it is not is a badge the code carries by itself — compliance is organisational, there is no HIPAA certificate, and a verified system drifts. So what you hand a security reviewer at the end is evidence: "implements the technical safeguards required by 45 CFR §164.312, verified on [date], with these items outstanding."
HIPAA reaches covered entities, business associates and their subcontractors. A direct-to-consumer health app is usually none of those — and is regulated instead by the FTC Health Breach Notification Rule and state consumer health laws. Being outside HIPAA is not being unregulated.
The 18 "HIPAA identifiers" are not a definition of PHI. They are the list you strip to de-identify data under Safe Harbor.
Start with two things, not with code: signed Business Associate Agreements, and an accurate risk analysis. A missing or stale risk analysis is the most-cited failure in HIPAA enforcement.
"HIPAA-eligible" is not "HIPAA-compliant." AWS, GCP and Azure sell a BAA plus a list of eligible services in covered regions. Correct configuration is still yours.
The control most often missing is a record-level audit log. CloudTrail records who changed a security group. It does not record who opened which patient's chart. §164.312(b) expects the second.
Encryption is the highest-leverage control, because properly encrypted ePHI is not "unsecured PHI" and its loss triggers no breach notification.
Platform specifics matter: third-party scripts on authenticated web pages, PHI in mobile push payloads, and vector indexes built from clinical notes with no per-patient authorisation filter are the three failure modes we find most often.
What "HIPAA-compliant app" actually means
You came here to find out how to develop a HIPAA-compliant application, and that is exactly what this guide covers. Two minutes on the phrase itself first, though — because it is shorthand, and knowing what it is shorthand for is what keeps a project out of the most expensive mistakes in this field.
The plain version: a "HIPAA-compliant app" is an application built so that the organisation using it can meet its HIPAA obligations, with nothing in the software making that harder than it needs to be. That is a real goal, it is achievable, and it is what the twelve steps in this series are for.
What the phrase does not mean is that compliance is a property the software carries on its own. Three things sit behind that, and each one changes how you build.
1. Compliance is something an organisation does, and your app either supports it or gets in the way. The Security Rule splits into three groups of requirements, and your code can fully satisfy one of them: the technical safeguards in §164.312. The administrative safeguards in §164.308 ask for a named Security Officer, a documented risk analysis, staff training and signed Business Associate Agreements — things a company does, not things software does. That is not a limitation of your app. It is a division of labour, and your side of it is to make the organisation's half possible, and ideally easy.
2. There is no HIPAA certificate to earn, so what you produce instead is evidence. HIPAA establishes no certifying body, which means nobody can audit software against it and issue a badge — unlike SOC 2, where a real report exists and can be handed over. A vendor advertising "HIPAA Certified" is pointing at something that does not exist. What a hospital's security reviewer actually asks for is a dated record of what was checked, on which system, by whom, with the exports behind it. Producing that is a normal part of shipping, and what "done" looks like sets out exactly what goes in it.
3. It is a state you keep, not a line you cross. A system that was correct on Tuesday says nothing about the following Tuesday. Someone widens a security group. Someone restores a production snapshot into staging to chase a bug. Configuration drift is the ordinary reason a good system stops being a compliant one, and it is usually noticed during an incident rather than before one. That is why the last of the twelve steps is about keeping it true, and why it is not optional.
None of this makes the goal smaller. It makes it precise — which is what lets you say something strong and defensible when a customer's security team asks.
What you can put in writing
Here is a claim that is true, defensible, and more useful to a reviewer than the broad one:
This application implements the technical safeguards required by the HIPAA Security Rule (45 CFR §164.312) and supports our customer's administrative and physical safeguard obligations. Each control was verified on [date] against the evidence listed in the accompanying pack. The customer remains responsible for its own compliance programme.
Three properties make it credible. It is specific — it names the safeguards, control by control, with citations. It is dated — it says when each control was observed. It is bounded — it says what was not verified, and what remains somebody else's job.
The bounded part is what a good reviewer looks for first. A claim with no stated limits reads as unexamined. A claim that names its own gaps reads as competent.
And the careful version sells better
The instinct is that the broad claim sells and the careful one does not. In a real security review the opposite holds.
A reviewer's job is to find the gap between what you claim and what you can show. A broad claim invites them to go looking, and they will find something — every system has an open item. A specific, dated, bounded claim with evidence attached gives them nothing to catch you on. Naming your own outstanding items is the strongest move available: a vendor who volunteers the limits of its own verification stops being audited and starts being trusted.
Everything below is about how to earn that narrow claim.
Does HIPAA apply to you? The short answer
HIPAA reaches three kinds of organisation: covered entities (health plans, clearinghouses, and providers who bill electronically), business associates (anyone handling PHI on a covered entity's behalf — if you build and host a hospital's patient portal, this is you), and subcontractors of business associates, all the way down the chain.
Two things trip teams up. "We never look at the data" does not exempt you: OCR's cloud guidance is explicit that a provider merely storing encrypted PHI is still a business associate. And selling to consumers usually puts you outside HIPAA rather than above it — a direct-to-consumer symptom tracker with no covered entity behind it is typically neither a covered entity nor a business associate, and is regulated instead by the FTC Health Breach Notification Rule and by state consumer health laws such as Washington's My Health My Data Act.
Design to the Security Rule either way. It is the best-documented baseline available, and the day a health system wants to buy your product you will need it.
→ Does HIPAA apply to your app? covers the decision path, the conduit exception, the FTC rule, and the state and sector laws that sit alongside HIPAA.
What counts as PHI? The short answer
Protected health information is individually identifiable health information created, received, maintained or transmitted by a covered entity or business associate. Health information is broader than diagnoses — an appointment, a billing record, a prescription refill all count. And the last clause does real work: the same data is PHI in a hospital's database and is not PHI in a consumer app's. Who holds it decides.
The "18 HIPAA identifiers" you will find on most blogs are not a definition of PHI. They are the list you strip to de-identify data under the Safe Harbor method. A name on a mailing list is not PHI; a name in a clinic's patient index is.
→ What is PHI, and what are the 18 HIPAA identifiers? has the corrected list, the detail each item is usually missing, and how Safe Harbor, Expert Determination and a Limited Data Set differ.
What are the HIPAA safeguards, and which ones can your code satisfy?
The Security Rule is deliberately technology-neutral and, under §164.306(b), scalable: a two-person telehealth startup and a national payer are held to the same standards with different implementations. That flexibility is not a loophole. It means you must reason and record, rather than tick.
The twelve steps at a glance
Each step below is a section in the technical safeguards checklist or in the post on PHI leaks, breach notification and staying compliant. This is the map; those are the details.
Sign the BAAs before you choose the architecture. No cloud provider sells a "HIPAA-compliant backend". They sell a Business Associate Addendum plus a list of HIPAA-eligible services in covered regions. Eligible is not compliant. Every vendor that could touch PHI needs its own agreement, all the way down the chain.
Draw the PHI boundary and write it down. Decide where PHI is allowed to live before you build, and produce a data inventory: what each store holds, why, who can reach it, how long it keeps it, and which BAA covers it. Enforce the patient scope in the data layer, not only in the API layer.
Encrypt in transit. TLS 1.2 minimum, 1.3 preferred, HSTS on, and internal service-to-service and database traffic included. "It is inside our network" is not an argument a reviewer accepts.
Encrypt at rest, including the copies you forgot. Every store, not only the PHI-bearing ones — and then the snapshots, replicas, backups, exports, warehouse loads and log archives. This is the highest-leverage control you can implement, because properly encrypted ePHI is not "unsecured PHI" and its loss triggers no breach notification.
One identity per human, and multi-factor authentication. No shared logins, MFA on every path to PHI, a documented break-glass procedure, and session timeouts. Using an email address as a username is fine; what matters is what you require alongside it.
Build an audit log that answers "who read whose record?" CloudTrail records who changed a security group. It does not record who opened which patient's chart, and §164.312(b) expects the second. This is the control most often missing at a first hospital security review.
Keep PHI out of the eleven places it leaks. Logs, error trackers, URLs, analytics SDKs, push payloads, email, support tickets, staging environments, AI prompts, CI pipelines and generated files. Nearly every exposure we find in a code review is PHI somewhere nobody meant it to be.
Protect integrity, and prove your restores. Amend clinical records, never overwrite them. Then run a real restore into an isolated environment on a schedule — an untested backup is a hypothesis.
Test it like an adversary, on a schedule. SAST, dependency scanning, IaC scanning and authorisation tests in every pull request; DAST, vulnerability scans and an annual penetration test on the calendar.
Decide retention, then dispose properly. HIPAA sets no medical-record retention period — state law does. It does require six years for documentation. Disposal means every copy, and a soft-delete flag is not disposal.
Plan for the bad day. A contingency plan and breach notification are two different obligations. Notification is due to individuals within 60 days of discovery, with a separate route and threshold for breaches of 500 or more.
Keep it true after launch. Alert on drift the day it happens, re-run the risk analysis on material change, review access quarterly, and re-verify before you make a claim again.
Web, mobile and AI: what changes per platform
The twelve steps apply to any system. Three surfaces add problems the general list will not catch, and each has its own post.
Web applications. The one that has cost health systems the most is third-party tracking scripts on authenticated pages. The regulatory position genuinely changed — OCR's 2022 bulletin was partly vacated in June 2024 and HHS dropped its appeal that August — and the post explains what still stands and what does not. Plus PHI in URLs, browser and CDN caching of PHI responses, and session handling.
Mobile apps. The device is not yours, and it may be lost. Keychain and Keystore, PHI in push notification payloads, the app-switcher snapshot, local caches excluded from platform backups, crash reporters, and why Face ID is a local unlock rather than an authentication factor your backend can verify.
AI features. The newest and least documented. A prompt containing PHI is a disclosure and the model provider is a business associate. The mistake we see most often is a retrieval index built from clinical notes that inherits none of your row-level access control.
What "done" looks like
Not a certificate. An evidence pack and a dated verification record.
When we finish an engagement, the deliverable is a set of documents whose centre of gravity is exports from the live account, not policies. Policies describe intent; a reviewer at handover wants proof. If you can only produce one of the two, produce the proof.
What that looks like:
A verification record — every technical control, checked against the running system on a stated date, by a named person, with the evidence for each and an explicit list of what was not verified.
The evidence itself — configuration exports, encryption settings, key policies, IAM and MFA reports, TLS policy, security group rules, a backup and restore-test record, an audit-log sample, the CI gate run.
A control mapping — each Security Rule specification against its implementation and its evidence reference. Reviewers read this first, and they read the evidence column, not the description column.
An as-built architecture document with the PHI data inventory and the per-component boundary. Not the kickoff design — the thing that shipped.
A subprocessor register with agreement status against each vendor.
A responsibility split saying who owns what now: which controls transferred, which remain the customer's, which are shared.
An open-items register with owners and dates. This is the section that earns trust. Every system has one; a vendor that presents theirs unprompted is a different kind of vendor.
One caution about starter document packs, including ours. A set of drafted policy templates is a starting point, not a compliance programme. An unsigned risk analysis is not a risk analysis. An unadopted policy governs nobody. Describe what was handed over in exactly those terms — "we have prepared the starter set; adoption and completion are yours" — and record the rest as outstanding. Implying that a customer's obligations are met because they hold the templates is the same written-representation problem this guide opened with.
A note on how we work, since it is relevant to what you should expect from anyone doing this. We build tooling that reads a codebase and reports what it can and cannot see about each control, and it is deliberately incapable of reporting a control as verified. The strongest thing a code read can produce is "the code declares this, here is the file and line". Verification requires somebody looking at the running system. If a vendor's report tells you a control is confirmed because a scanner read your repository, the report is claiming more than the method supports.
How much does HIPAA-compliant app development cost, and how long does it take?
The earlier version of this post invited readers to ask how long it takes and then never answered. A straight answer, with the caveat that it varies with what you already have:
The calendar is usually gated by paperwork and decisions, not by code. The two long poles are getting BAAs executed — a cloud BAA is same-day, but a hospital customer's own legal review can take weeks — and completing an honest risk analysis, which requires people who are busy. Start both on day one.
The engineering delta is smaller than people fear if you start early, and much larger if you do not. Building to this baseline from the beginning typically adds a modest percentage to a product build: most of the twelve steps are things a competent team does anyway, and the genuinely additional work is the record-level audit log, the PHI data inventory, the de-identified non-production dataset, and the evidence collection. Retrofitting is a different exercise entirely — the expensive parts are usually adding audit logging to an application that never had it, unpicking PHI from logs and analytics that have retained it for two years, and replacing a vendor that will not sign a BAA.
The recurring cost is real and permanent. Annual risk analysis review, penetration testing, access reviews, training, vendor register maintenance, drift monitoring, and re-verification. Budget for it as an operating cost, not a project.
The one number worth internalising: the cheapest moment to do any of this is before the first real patient record enters the system. Everything gets more expensive after that, because from that point every fix is a migration.
The mistakes we see most often
Believing a "HIPAA-compliant" cloud, host or vendor makes the product compliant. It makes PHI permitted there. Nothing more.
No record-level audit log, with infrastructure logs presented as though they were one.
Production data in staging. Every time.
A risk analysis that is actually a questionnaire, or is three architectures out of date.
PHI in an analytics or error-tracking pipeline that nobody in the room knew was there.
A vector index built from clinical notes with no per-patient authorisation filter.
Sensitive content in push notification payloads.
A BAA register where several rows say "in progress" and have for months.
Backups that have never been restored.
Encryption enabled on the primary database and nowhere else — not the snapshots, not the replicas, not the exports.
Consumer health apps assuming that being outside HIPAA means being unregulated.
Writing "HIPAA compliant" in a customer-facing document, which converts every one of the above into a written representation somebody relied on.
Frequently asked questions
Can an application be HIPAA compliant?
Not on its own — and the phrase is still useful shorthand. What people mean by it is real and achievable: an application built so that the organisation using it can meet its HIPAA obligations, with nothing in the software in the way. What software cannot do by itself is satisfy the administrative safeguards in §164.308, which require a named Security Officer, a documented risk analysis, workforce training and signed Business Associate Agreements. Those are organisational acts. So the accurate claim is that a system implements the technical safeguards in §164.312, verified on a stated date, with its open items named.
Is there a HIPAA certification for software?
No. HIPAA establishes no certifying body and no accreditation scheme, so no auditor can certify software against it. A "HIPAA Certified" badge describes something that does not exist. This differs from SOC 2, where a real report exists and can be produced.
What does a HIPAA-compliant app cost to build?
The engineering delta is modest if you build to the baseline from the start — most of the twelve steps in this guide are things a competent team does anyway — and substantial if you retrofit, where the expensive items are adding audit logging to an application that never had it and unpicking PHI from logs and analytics that have retained it for years. The calendar is usually gated by BAAs and the risk analysis rather than by code. The cheapest moment to do any of it is before the first real patient record enters the system.
What is the most common HIPAA gap in healthcare software?
A record-level audit log. Teams present infrastructure logs such as CloudTrail as though they satisfied §164.312(b), but those record who changed a security group, not who opened which patient's chart. The second has to be written into the application, and it is the control most often missing when a product reaches its first hospital security review.
Where Bitsol fits
We build healthcare software on AWS, and we do the compliance engineering as part of building it rather than as a phase at the end.
What we can honestly offer:
A read of your codebase and cloud account against the technical safeguards, with a file-and-line citation for every control we find declared and a plain statement of every gap — including the things no code read can settle.
Design and build for web, mobile and AI features on a PHI boundary that is written down before the first table is created.
A launch gate before the first real patient record, verified against the running system rather than against the repository, with what we could not verify listed as such.
The document pack and the evidence pack your customers' security reviewers will ask for, with the open items named.
What we will not offer: a statement that your application is HIPAA compliant, or a certification. Those do not exist, and a vendor who offers them is telling you something useful about themselves.
If you are starting a healthcare product, or you have one that is about to meet its first hospital security questionnaire, we are happy to look at where you are. Get in touch.
What changed in this rewrite
The original version of this post was published in April 2023. This is a rewrite rather than an update, for three reasons.
It had errors we would rather correct in public than leave up. The most significant: it described selecting a "HIPAA-compliant backend" as step one, which is not a thing that exists; it presented the 18 Safe Harbor de-identification identifiers as a definition of PHI, which they are not; it defined data "at rest" as data "not shared with anyone", which is wrong; and it stated that logging in with an email address was the least secure option for HIPAA, which is not a real finding. It also promised that we could make an application HIPAA compliant, which is the claim this rewrite opens by refusing. Its step numbering skipped Step 5, and the content of that step had been absorbed into its neighbour.
The regulatory picture moved. The FTC's Health Breach Notification Rule amendments took effect in July 2024 and explicitly reach non-HIPAA health apps. OCR's tracking-technology bulletin was partly vacated in June 2024 and the appeal withdrawn that August. HHS proposed a substantial Security Rule update in January 2025 that is still not final. The 42 CFR Part 2 compliance deadline arrived in February 2026. Penalty amounts were adjusted in January 2026.
It never mentioned AI, mobile or web specifics. Those now have a post each, because that is where the current work is.
And it was one page. The corrected material runs to about 20,000 words, which is a reference library rather than an article. So this URL is now the overview, and the detail sits in seven companion posts — listed at the foot of this page. Nothing was cut to make that split; the steps and platform sections moved intact.
One editorial note, since a reader may notice it. The first version of this rewrite opened by saying there is no such thing as a HIPAA-compliant application. That is defensible but unhelpful — it reads as a contradiction of the title, and the phrase is genuinely useful shorthand for something real. The opening now defines what the shorthand stands for and what it does not, which lands the same point without picking a fight with the reader's own question.
