The app works, people are using it, and somewhere inside it there are records about somebody’s health. Then a customer, an investor or your own second thought raises the rule. The rules meant here are the US ones that reach a company running software for a health plan, a clinic or anybody already acting on behalf of one of them. Not the rights a patient holds over their own chart, and not the shopping question behind every list of HIPAA compliant apps a clinician might buy: this is for the person who built the thing, not the person choosing one.
The awkward part is the order events happened in. Almost everything published on this search is written for an app nobody has built yet. Yours has users and rows in a database, and cannot be started again.
The rule asks for three separate places rather than one job. Some of what the rule asks for lives in an agreement somebody signs, some in a setting inside a platform account, and the rest in code somebody has to write. The rule names the pieces itself, and this page says which piece sits where.
This page is read out of documents rather than out of anybody’s codebase. The rule’s own words come from the text of 45 CFR parts 160 and 164 as the Government Publishing Office publishes it, in the annual revision dated 1 October 2025, read on 3 September 2026. Where a platform’s own terms decide an answer instead, the page says so and points at the page that read them. Nothing here was built, hosted, tested, audited or certified by anybody at AxonBuild, and no sentence below is legal advice or a ruling about whether a reader’s app satisfies anything.
Does the rule reach your app, or does it not?
Two definitions decide it, and both sit in one section. The rule follows a category of information and a relationship, not an industry or a feeling that data looks medical.
The information first. At 45 CFR 160.103, read on 3 September 2026, protected health information means “individually identifiable health information” transmitted or maintained in electronic media or in any other form. The same definition carves four things back out: information in education records covered by the Family Educational Rights and Privacy Act, information in the records described at 20 U.S.C. 1232g(a)(4)(B)(iv), information “[i]n employment records held by a covered entity in its role as employer”, and information “[r]egarding a person who has been deceased for more than 50 years”. Electronic protected health information, what the Security Rule is written about, is that category once transmitted or maintained electronically.
The relationship second. The same section defines a covered entity as one of three things: a health plan, a health care clearinghouse, or a health care provider who transmits health information electronically in connection with a transaction the subchapter covers. A software company is almost never any of those. What it can be is the other role in that section, the one defined by acting on behalf of a covered entity, outside its workforce, on information the subchapter regulates. That is the position most people mean by HIPAA compliance for software vendors, and it reaches a level further down: the same section extends the role to a subcontractor handling the same information for somebody already in it.
So holding health-shaped information does not by itself put a company inside this regime. A fitness tracker sold to consumers with no clinic behind it is outside the definitions above; the same code, sold to a clinic to run its patient list, is inside them. Nothing on this page decides which a particular app is, and the sentence that settles it is usually in the customer contract rather than in the code. Where a platform’s own paperwork answers half of it, what Base44’s own terms say about health data shows what that reading looks like on one builder.
Other regimes can reach the same app at the same time, with their own definitions. Which of them apply is a question for a lawyer rather than for any page on the internet.
What “HIPAA compliant app development” means once the app already exists
Read the pages ranking for this phrase and the meaning is consistent. Appinventiv’s guide, read whole on 3 September 2026 including its navigation, is built around a section titled “How to Build a HIPAA-Compliant App: Our 6-Phase Process”, with skills, a tech stack, a cost table and a closing section asking how the firm can help. That same reading finds no AI app builder named anywhere in its markup: Lovable, Replit, Base44, Supabase and Firebase return nothing, and the only hits for Bolt are the ordinary verb. HIPAA Vault’s page, which carries a publish date of 29 April 2026 and was read on 3 September 2026, does name Cursor and Replit and does use the phrase vibe coding, and its argument runs toward portable tools plus hosting it sells. Blaze’s list, marked updated 19 February 2026, ranks its own product first under “Best Overall” and states its method for the agreement question in one line: “To confirm that each platform offers a BAA, I double-checked each company’s security policies.” Those three are named for what they publish and none is linked: appinventiv.com/blog/develop-hipaa-compliant-app/, hipaavault.com/resources/hipaa-compliant-hosting-insights/hipaa-compliant-app-development/ and blaze.tech/post/hipaa-compliant-app-builder.
Every one of those pages is written the same way, and that is reasonable when nothing has been built yet. Building HIPAA compliant software from an empty folder really is a sequence: decide the architecture, pick the stack, wire the controls in as you go. HIPAA compliant mobile app development, HIPAA compliant web app development and hipaa-compliant app development are that same sequence sold to three audiences, and a bare mobile wrapper around an existing web app changes none of the answers below, because the records and the routes to them do not live in the wrapper; the moment the wrapper adds native features, local caches, push notifications, device logging or an SDK that sends data elsewhere, those become part of the data-flow review too.
Yours is not that job. An app with users cannot be built in phases, so the question is which of three places each change lives in.
A signed agreement. Somebody puts their name to a written contract, and no code changes. This is the half that platforms and vendors control, and it is either available on your plan or it is not.
A setting inside a platform account. Somebody with the right access switches something on, or moves a project, or turns a destination off. No code changes here either, but the account holder has to be the one to do it.
Code somebody has to write. A check that is not there, a record that is not kept, a field that goes somewhere it should not. No agreement and no plan upgrade reaches this part, and the rest of this page spends most of its words on it.
Those three are the spine of everything below. They have different owners, different lead times and different people who can do them, and a page that blurs them into one process leaves you unable to tell which of the three you are stuck on.
What HIPAA’s Security Rule actually names
One thing to get straight before the list. Firebase publishes a product called Security Rules, plural, which is a language for expressing database access conditions. HIPAA’s Security Rule, singular, is a part of a federal regulation. They share a name and share nothing else, and every mention below is the regulation.
Two sentences make the rest readable. First, the regulation labels each implementation specification either Required or Addressable, and at 45 CFR 164.306(d), read on 3 September 2026, addressable does not mean optional: where a specification is addressable, a covered entity or business associate has to assess whether it is a reasonable and appropriate safeguard in its environment, then implement it if it is, or, if it is not, “[d]ocument why it would not be reasonable and appropriate to implement the implementation specification” and “[i]mplement an equivalent alternative measure if reasonable and appropriate”. Skipping one silently is not one of the choices the text offers.
Second, the same section carries what it calls flexibility of approach. The text states that a covered entity or business associate may use any security measures that let it reasonably and appropriately implement the standards, and that in deciding which to use it must take into account four factors: its own size, complexity and capabilities; its technical infrastructure, hardware and software security capabilities; the costs of security measures; and the probability and criticality of potential risks to the information. That is the sentence telling a two-person company it is not being measured against a hospital system, and it is in the rule rather than in anybody’s interpretation of it.
Now the technical half, at 45 CFR 164.312, read on 3 September 2026, in the order the regulation lists it. These are the HIPAA requirements for software people usually mean by the phrase, and the second column carries the regulation’s own labels.
| What the rule names | Required or Addressable | Where the change lives | What it means in an app a builder generated |
|---|---|---|---|
| Unique user identification | Required | Your code, or the platform’s auth if it enforces it | One named account per person, never a shared login |
| Emergency access procedure | Required | A written procedure, plus code where the route needs one | A written way to reach the records when the usual route is down |
| Automatic logoff | Addressable | Your code | Sessions that end themselves after an idle period |
| Encryption and decryption | Addressable | Platform setting | Disk and transport usually on already; depends on the platform above that |
| Audit controls | Standard, no specification | Your code, platform logging, or a procedure, whichever actually records it | A queryable record of who read and changed what |
| Mechanism to authenticate ePHI | Addressable | Your code | Something that shows a record was not quietly altered |
| Person or entity authentication | Standard | Your code | Proof the account is who it claims, on every route in |
| Transmission security | Addressable, both parts | Platform setting | Depends on the platform whether every hop is covered |
Two things are worth noticing. Not one row is closed by a signature: the technical safeguards are the half nobody can sign for you, which is why an app can sit on a platform that signs everything and still have none of these true. And most of the eight land in your code or your procedures rather than in a plan setting, which is why a plan upgrade so often changes nothing a customer is worried about; check what the platform already records or enforces before assigning each row.
Two of those rows are worth having in the rule’s exact wording. Audit controls, at 164.312(b), asks for “hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information”, and it carries no implementation specification, so there is nothing labelled addressable to reason your way out of. Unique user identification, at 164.312(a)(2)(i), is one line: “Assign a unique name and/or number for identifying and tracking user identity.” An app where three people share one admin login fails that line on its own terms, and no setting fixes it.
Where a cell says the answer depends on the platform, the honest answer sits in that vendor’s own pages rather than in the regulation, and is read vendor by vendor.
The half of the rule that is not code
A large part of what people call HIPAA software requirements is things somebody has to do, decide and write down, and the regulation says which are Required.
The administrative half sits at 45 CFR 164.308, read on 3 September 2026. Under the security management process standard, risk analysis is marked Required and asks for “an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability” of the electronic records the entity holds. Risk management, also Required, asks for security measures sufficient to reduce those risks to a reasonable and appropriate level. Information system activity review, Required as well, asks for procedures to regularly review records of information system activity, “such as audit logs, access reports, and security incident tracking reports”. That last phrase is the regulation naming, in three examples, the exact thing most builder-generated apps do not have, and an app that keeps no such records cannot review them.
The same section names an assigned security responsibility standard: identify the security official responsible for these policies and procedures. In a two-person company that is a name on a page rather than a job opening, and the regulation does not say otherwise. Security incident procedures carry one Required specification, response and reporting, which asks an entity to identify and respond to suspected or known incidents, “mitigate, to the extent practicable, harmful effects” of the ones it knows about, and document them and their outcomes. Three of the five contingency-plan specifications are Required too, and the first of them is a data backup plan, described as procedures to create and maintain retrievable exact copies. An automatic backup nobody has restored from is not yet that, because the specification is about retrievable copies rather than about a switch being on. The section closes with an evaluation standard: a periodic technical and nontechnical evaluation of the extent to which the entity’s policies and procedures meet the subpart’s requirements.
Then the documentation half, at 45 CFR 164.316, read on 3 September 2026. It asks for policies and procedures in written form, which the text says may be electronic, and for a written record of any action, activity or assessment the subpart requires to be documented. Three specifications hang off it and all three are Required: a time limit, to retain that documentation “for 6 years from the date of its creation or the date when it last was in effect, whichever is later”; availability, meaning it reaches the people implementing what it describes; and updates, meaning it gets reviewed and changed as operations change.
None of that is a product, and this page offers none of it as one. Several of these items are cheap to do, expensive to have skipped, and not waiting on an engineer.
Whose signature covers what
The written-agreement half of the rule is short and specific, and it is why the answer to almost every platform question is a document rather than a setting.
At 164.308(b), read on 3 September 2026, a covered entity may hand its electronic records to another company to create, receive, maintain or transmit only on what the text calls satisfactory assurances that the company will appropriately safeguard the information, documented through a written contract or other arrangement. The same paragraph runs the identical requirement one level down, from a business associate to a subcontractor, and the written contract or other arrangement specification is marked Required.
The promises that contract has to carry appear in 45 CFR 164.314(a), read on 3 September 2026, and one clause is worth reading twice if you run software for somebody else. The contract must provide that the company will “[r]eport to the covered entity any security incident of which it becomes aware, including breaches of unsecured protected health information as required by § 164.410.” The duty covers incidents it becomes aware of, including ones it had no part in causing. The section also carries the flow-down requirement in its electronic-records form.
There is a clock attached, and it belongs to a different actor from the one most articles describe. At 45 CFR 164.410, read on 3 September 2026, a business associate that discovers a breach of unsecured protected health information has to notify the covered entity “without unreasonable delay and in no case later than 60 calendar days after discovery of a breach”. The same section counts a breach as discovered on the first day it is known, or would have been known through reasonable diligence, to anyone at the company other than the person who caused it. That is the software company’s duty toward its customer. The customer’s own duties to individuals and to the regulator are separate.
Which platforms and builders will put their name to that agreement, and on which of their plans, is a separate map, and it is the one thing every answer on this page eventually depends on. If the app was made in Lovable, the platform’s own pages on health data get read line by line elsewhere. Where the records sit in a hosted Postgres project rather than in the builder, what a signed Supabase agreement covers and what it leaves reads one such stack in full.
What any of this costs, and what the penalty tiers on the other side of it look like, is a page of its own and carries the numbers this one does not. Nothing above should be read as a view on whether a particular agreement is worth its price.
Where the records have already gone
The first general requirement of the Security Rule, at 164.306(a)(1), is to ensure the confidentiality, integrity and availability of “all electronic protected health information the covered entity or business associate creates, receives, maintains, or transmits”. Four verbs, and only one is about a database. That turns this into a question about places rather than about your schema.
An AI builder is generous with places. It creates several without being asked, and they appear in no list of your infrastructure because you never chose them.
The preview or share address. Most builders publish a working copy of the app at a second URL for review, running the same code against the same data. If real rows went in before anybody thought about that address, the records are reachable from two places rather than one, and the second was never designed to have anybody signed in.
The platform’s own build and runtime output. Errors, traces and console output get captured by default, usually in the account of whoever owns the project. A stack trace carrying a request body carries whatever was in that body.
The generated admin screen. Builders often produce a table view over the data for the person building the app. It is useful and it usually has no ownership rule of its own, because it was written for an audience of one.
Seed and demo rows. Sample data written during the build sits in the same tables as the real data, and gets copied wherever it does.
The export route. A button, an endpoint or a scheduled job that turns rows into a file. Wherever that file lands, the four verbs reach it.
The automatic backup. Copies made on a schedule, kept for a period the platform chose, in a location the platform chose.
Two more are added on purpose and forgotten fastest. A feature calling a language model sends whatever it sends to another company, and what that company retains, and for how long, is answered on that vendor’s own pages rather than in your code. A message sender, an analytics property or an error service takes whatever the app hands it, which is a relationship with its own paperwork rather than a technical detail.
An app whose data sits in Firebase has a per-service answer rather than a single one, and each service is accounted for on its own. Working out which of the destinations above exist in a given codebase is a reading job, and the work of closing the gaps a builder leaves is the general version of it. No page that has not read the code can tell you which ones your app has, including this one.
Who does this work, and what to put in writing before they touch it
Two different purchases hide under one phrase. A HIPAA compliant app development company sells a build; somebody with a running app needs a reading of the code and the data path first, and the questions below tell you which one you are being quoted for.
The services pages that rank here are honest about selling the first kind. Six phases, a stack, a team, a number. That is a good purchase for an idea and a poor fit for an app that already has rows in it, because the early phases have happened and cannot be repeated. What is left is a different job: find out where the records are, which of the named specifications above are true in the code today, and which are one change away.
So the questions to put in writing before anybody starts are not about method or price. Each comes out of a section quoted on this page, which is why they are answerable rather than rhetorical.
- Which of the eight technical specifications at 164.312 does the app satisfy today, and what is the evidence for each answer?
- What does the app record about who read and changed a health record, where does that record live, and can it be queried?
- Which of the destinations in the section above exist in this codebase, and which of them receive health records?
- For every addressable specification not implemented, where is the documented reasoning and the alternative measure 164.306(d) asks for?
- Who signs what, between us, the platform underneath and any vendor the app sends records to?
- Where is the risk analysis 164.308(a)(1)(ii)(A) names, and who is going to write it?
Getting those answered is a reading exercise on the code and the data path. Having the code read before the records go in is the general shape of it, and it produces answers rather than an opinion about whether anybody complies with anything.
The rows in the table above that land in code tend to show up as one specific fault rather than as a programme of work: a signed-in account that can open somebody else’s record, a field written to a place nobody listed, a file store that answers to anyone holding the address. Nobody here writes or argues over an agreement, nothing is hosted, nothing is certified, no penetration test is performed, and the risk analysis 164.308(a)(1)(ii)(A) names stays the entity’s own work. No sentence written by anybody at AxonBuild decides whether an app satisfies the rule, and none of this is a lawyer’s opinion.
Common questions about health data in an app you already built
Does the rule reach an app that stores health information but is not sold to a hospital?
It depends on the relationship rather than on the data looking medical. The definitions at 45 CFR 160.103, read on 3 September 2026, attach to information handled on behalf of a health plan, a health care clearinghouse or a health care provider transmitting electronically, or on behalf of somebody already in that position. An app with no such customer behind it sits outside those definitions, even holding the same kind of information. The contract with the customer usually settles it, and a lawyer is its right reader.
What does “addressable” mean, and can an addressable specification be skipped?
Addressable is a label the regulation applies to some implementation specifications and not others, and 45 CFR 164.306(d), read on 3 September 2026, says what using it costs. A covered entity or business associate assesses whether the specification is a reasonable and appropriate safeguard in its environment, then implements it if it is. If not, the text asks for documented reasoning and an equivalent alternative measure where that is reasonable and appropriate. Quietly leaving one out is not one of the routes the section describes.
Does the Security Rule say every health field in my database has to be encrypted?
Not in those words. At 45 CFR 164.312, read on 3 September 2026, encryption appears twice and both times it is labelled addressable: encryption and decryption under access control, and encryption under transmission security. So the assess, implement or document-and-substitute route at 164.306(d) applies to both, rather than a flat instruction. The section names no columns, no keys and no layer.
The column-level and key-management decision that sits under that answer is worked through, for one common database, in what a signed Supabase agreement covers and what it leaves.
Does my app need an access record of its own, and what has to be in it?
The audit controls standard at 45 CFR 164.312(b), read on 3 September 2026, asks for mechanisms that record and examine activity in systems holding electronic health records, and attaches no implementation specification, so there is nothing labelled addressable to reason around. It prescribes no fields. The companion requirement at 164.308(a)(1)(ii)(D) asks for procedures to regularly review records of information system activity, naming audit logs, access reports and security incident tracking reports. A record nobody can query is hard to review, which tends to decide the design.
If two companies are involved in running my app, does each one need its own written agreement?
The regulation runs the requirement down the chain rather than stopping at the first pair. 45 CFR 164.308(b), read on 3 September 2026, allows a covered entity to pass electronic health records to another company only on documented satisfactory assurances, through a written contract or other arrangement, and applies the same condition when that company passes them to a subcontractor. 45 CFR 164.314(a) then applies the same requirements to the second contract as to the first. The shape is a chain of written agreements rather than one.
Which platform in a given stack actually offers such an agreement, and on what plan, is answered platform by platform on its own page in this cluster.
Do I have to write policies, and how long do I have to keep them?
45 CFR 164.316, read on 3 September 2026, asks for reasonable and appropriate policies and procedures in written form, which the text says may be electronic, plus a written record of any action, activity or assessment the subpart requires to be documented. Three specifications attached to it are marked Required: retain that documentation for six years from its creation or from the date it was last in effect, whichever is later; make it available to the people implementing what it describes; and review and update it as operations change.
What counts as a security incident I have to respond to and write down?
The response and reporting specification at 45 CFR 164.308(a)(6)(ii), read on 3 September 2026, is marked Required and covers suspected as well as known security incidents. It asks an entity to identify and respond to them, mitigate harmful effects to the extent practicable, and document them and their outcomes. Separately, 45 CFR 164.314(a)(2)(i)(C) has the written agreement make a company report to its customer any incident of which it becomes aware, a wider set than the ones it caused.
Does the rule require a penetration test?
The word appears in none of the sections quoted on this page, read on 3 September 2026. What 45 CFR 164.308(a)(8) names instead is an evaluation standard: a periodic technical and nontechnical evaluation establishing the extent to which policies and procedures meet the subpart’s requirements. It names no method, no vendor and no frequency.
The separate question of whether a customer or an auditor is actually asking for one, and what they will accept, is decided in whether a customer or an auditor actually needs a penetration test.
The app already holds real records and none of this was done. What is the first move?
Find out where the records are before deciding anything else. The first general requirement at 45 CFR 164.306(a)(1), read on 3 September 2026, covers everything an entity creates, receives, maintains or transmits, and on a builder-generated app that list is longer than the database. Until somebody has read the code and written down every destination, the agreement question has no answer, because nobody knows whose agreement is needed, and the specification questions have nothing to check against.
The checks in this guide show you where the app is open. The sprint below closes those gaps, tests the result and writes the evidence down.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase