.svg)
Your data class sets the timeline. Not the AI.
A healthcare AI MVP is one clinical or administrative workflow, built end to end, tested by the people who'd actually use it. The thing that decides your scope, timeline, and budget isn't the AI. It's which rung of the data ladder you stand on. Most first versions belong on rung one or two, where HIPAA doesn't apply to your data at all, and that single decision is worth more weeks than any technical choice you'll make.
Healthcare is the vertical where AI MVPs go to die slowly. Not because the models don't work, but because teams discover in month four that the architecture they built can't legally hold the data they need.
We've watched that happen. It's avoidable, and avoiding it is mostly a scoping decision made in week one.
This guide covers what to build, how long it takes, and what HIPAA genuinely requires, with every regulatory claim traced to the rule or guidance it comes from. It also says plainly where the popular advice is wrong, including the widespread belief that you can buy your way to compliance from a vendor.
What Is a Healthcare AI MVP?
A healthcare AI MVP is the smallest version of your product that lets a real clinician, administrator, or patient complete one workflow and tell you whether it's better than what they do now.
The definition is the same as any AI MVP. What changes is the environment around it.
That second constraint reshapes everything downstream. It sets your hosting, your vendor list, your contracts, your logging, your review process, and your timeline. It is not a phase at the end of the build. Teams that treat it as one pay for the build twice.
What Should Version One Actually Include?
One workflow. One user role. One measurable claim you're testing.
Healthcare products attract scope the way nothing else does, because every stakeholder has a legitimate requirement and all of them are real. The discipline is to pick the single decision your product improves and refuse everything that isn't in service of it.
| Layer | In version one | Deliberately out |
|---|---|---|
| Workflow | One journey, start to finish | Adjacent workflows, however obvious |
| Users | One role | Multi-role permissions, admin consoles |
| Data | Synthetic or de-identified | Live records from a production system |
| AI behaviour | One task, with its evidence shown | Autonomous action, multi-step agents |
| Integrations | None, or one read-only feed | EHR write-back, billing, scheduling |
| Review | A human confirms before anything counts | Unsupervised output |
| Claims | "This is decision support" | Diagnosis, treatment, or a clinical claim |
The right-hand column is not a list of things you'll never build. It's a list of things that each add a compliance workstream, an integration dependency, or a regulatory question. Add them when a real user has told you the core workflow is worth having.
Both of our healthcare builds were scoped this way on purpose. Find The Plan compares Medicare plans using fictional plan data and hands off to a licensed advisor rather than making a coverage decision. Warwick Eye Surgeons built an agent around a surgical practice's real intake workflow with the clinical judgment left where it belongs. Neither needed live patient records to prove its point.
How Long Does Healthcare AI MVP Development Take?
Longer than a general MVP, and the difference is almost entirely data class.
| Data you use | What that means | Typical build | What drives the extra time |
|---|---|---|---|
| Synthetic | Fabricated records that behave like real ones | 4 to 8 weeks | Building a believable data set |
| De-identified | Real data with identifiers removed under 45 CFR 164.514 | 6 to 10 weeks | The de-identification work itself |
| Limited data set | Some dates and geography retained, under a data use agreement | 8 to 14 weeks | Agreements, access controls, review |
| Full PHI | Identifiable patient information | 12 to 24+ weeks | Vendor chain, safeguards, risk analysis, policies |
The jump from row three to row four is the expensive one. It roughly doubles the calendar, and almost none of the added time produces a feature a user can see.
Does HIPAA Even Apply to Your MVP?
Start here, because a lot of teams assume the answer is yes and build accordingly when it isn't.
HIPAA reaches two kinds of organisation. Covered entities are health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically in connection with certain transactions. Business associates are the people who handle protected health information on a covered entity's behalf, which is where most software companies land.
- Are you handling PHI at all?Individually identifiable health information held or transmitted by a covered entity or business associateIf your product only ever touches synthetic or properly de-identified data, HIPAA does not apply to that data. This is the answer for most version-one products, and it is the cheapest one available.
- Who are you handling it for?A covered entity, or yourselfIf a clinic, hospital, or health plan sends you PHI so you can perform a function for them, you're a business associate. You need a BAA with them, and one with every subcontractor you pass the data to.
- Are you selling direct to consumers?A patient typing their own data into your appA direct-to-consumer wellness app is often outside HIPAA entirely. That is not the relief it sounds like: the FTC Health Breach Notification Rule, state privacy laws, and app store rules still apply.
- Are you inside certified health IT?Integrating with a certified EHR as a decision support interventionThe ASTP/ONC HTI-1 rule's predictive decision support criterion has applied since 1 January 2025 and requires 31 source attributes to be disclosed about predictive models. This one catches people by surprise.
Answer those four honestly before you pick a database. If step one gives you a clean "no PHI", most of the rest of this article becomes optional for now, and you should feel good about that.
We run this exact sequence on every healthcare enquiry, before we talk about models or budgets. It takes about ten minutes and it has changed the shape of more projects than any technical conversation we've had. Twice it ended with us telling a founder they didn't need us yet.
What HIPAA Actually Requires, and What It Doesn't
Here's the part the industry gets wrong, and it's worth being blunt about.
- There is no such thing as a HIPAA certification. HHS does not run a certification programme and no third party can grant compliance on its behalf. Any agency, platform, or auditor offering to make your product "HIPAA certified" is selling something that does not exist. What exists is evidence: a completed risk analysis, implemented safeguards, signed agreements, written policies, and training records.
- A vendor's BAA does not make your application compliant. It covers that vendor's handling of the data you send them. Your own controls, contracts, and documentation are still entirely yours.
- Self-hosting is not compliance. Running your own infrastructure removes a vendor question and hands you every safeguard obligation directly. It can be the right call. It is not a shortcut.
- SOC 2 is not HIPAA. They overlap usefully and they are not substitutes. A SOC 2 report is an auditor's opinion on controls you chose. HIPAA is a set of legal obligations you carry whether or not anyone audits you.
What the Security Rule genuinely requires is a set of administrative, physical, and technical safeguards for electronic PHI. The one that matters most, and the one most commonly skipped, is the risk analysis: an accurate and thorough assessment of the risks to the confidentiality, integrity, and availability of the ePHI you hold. Nearly everything else follows from it. Encryption, access control, audit controls, and integrity controls sit in the technical safeguards.
What's changing, and what isn't yet
HHS published a proposed rule on 6 January 2025 that would tighten the Security Rule considerably. Comments closed on 7 March 2025. Among other things it would expressly require encryption of ePHI, define and require multi-factor authentication, and add a technology asset inventory with a map of how ePHI moves through your systems. Compliance would be due 180 days after the effective date, which itself would be 60 days after a final rule publishes.
It is not in force. As of this writing there is no final rule, and the published regulatory timetable has slipped repeatedly. Build toward the proposal anyway, because asset inventories, MFA, and encryption are cheap to design in and painful to retrofit. But do not let a vendor tell you these are already legal requirements, because right now most of them are not.
The Cheapest Compliance Decision You Can Make
Don't touch PHI in version one.
We make more money on the builds that do. We still open with this recommendation on nearly every healthcare scoping call, because the alternative is watching a good product idea get buried under a compliance programme before anyone has confirmed the idea works.
- Synthetic dataNo real person's information at any pointYou fabricate records that behave like real ones. HIPAA doesn't apply. No BAA chain, no risk analysis for that data, no vendor negotiation. You can ship in weeks and still test the workflow, the interface, and the AI behaviour.
- De-identified dataReal patterns, no identifiable personUnder 45 CFR 164.514(b) there are exactly two ways to do this: expert determination, where a qualified person documents that re-identification risk is very small, or safe harbour, where you strip the eighteen listed categories of identifier. De-identified data is not PHI, so HIPAA doesn't apply to it either.
- Limited data setSome dates and geography surviveUseful when the clinical question genuinely needs timing or location. Requires a data use agreement and restricts use to research, public health, or healthcare operations.
- Full PHIIdentifiable information about real peopleBAAs up and down the chain, the full Security Rule, risk analysis, breach notification procedures, policies, and training. Necessary eventually for most clinical products. Rarely necessary to answer "does anyone want this".
Climb one rung at a time, and only when the product forces you. Every rung you delay is weeks you get back and a compliance surface you don't yet have to defend.
There's a caveat worth stating clearly. Safe harbour de-identification is stricter than people expect, the eighteen categories include a catch-all for any other unique identifying number or code, and free-text clinical notes are notoriously hard to de-identify because identifiers hide inside prose. If your data is unstructured, budget real time for this or use synthetic data instead.
Not sure which rung your product needs?
Send us the workflow and the data you think you need. We'll tell you the lowest rung that still answers your question, and what it would take to climb higher later.
Book a free healthcare scoping call ↗Which AI Vendors Will Sign a BAA?
If you do reach rung four, your model provider becomes a business associate. Not all of them will sign, and the ones that do attach conditions that change your architecture.
| Vendor | Signs a BAA | Conditions worth knowing |
|---|---|---|
| OpenAI | Yes, on request | Covers the API and ChatGPT Enterprise. Requires zero data retention on eligible endpoints. Request it directly from their team |
| Anthropic | Yes | Covers the first-party Claude API and sales-assisted Enterprise. Your organisation's primary owner must activate it |
| AWS, Azure, Google Cloud | Yes | Standard for cloud infrastructure. Shared responsibility means configuration stays your problem |
Sources: OpenAI's BAA guidance and Anthropic's BAA documentation, checked 28 August 2026. Terms change, so confirm before you design around them.
Read the exclusion lists carefully, because they are where products break. Anthropic's BAA, for example, does not cover the Batch API, the Files API, code execution, computer use, web fetch, or data flowing through third-party connectors. Those are ordinary features you might reach for without thinking. If your PHI pipeline touches an excluded surface, you have a gap that no amount of good intent closes.
The same logic applies to every other service in your stack. Your error tracker, your analytics, your logging platform, your email provider, your customer support tool. Each one that can see PHI needs a BAA, and most default configurations leak more than teams expect.
When Does Your AI Feature Become a Regulated Medical Device?
The second regulatory axis, and the one that gets skipped entirely in most agency guides.
Software that supports clinical decisions can fall under FDA device regulation. There's a statutory carve-out at section 520(o)(1)(E) of the Federal Food, Drug and Cosmetic Act, and the FDA's Clinical Decision Support Software guidance explains how the agency reads it. That guidance was revised in January 2026 and supersedes the 2022 version, so check the current document rather than the commentary written about the old one. Software is excluded from the device definition only if it meets all four criteria.
- It doesn't analyse images or device signals. Not intended to acquire, process, or analyse a medical image, a signal from an in vitro diagnostic device, or a pattern from a signal acquisition system.
- It displays or analyses medical information. Patient records, peer-reviewed studies, clinical practice guidelines, and similar material.
- It supports recommendations to a healthcare professional. About prevention, diagnosis, or treatment.
- The professional can independently review the basis for the recommendation. They must be able to reach the same conclusion without relying primarily on the software.
Two of these decide most AI products.
The third criterion says recommendations to a healthcare professional. A patient-facing tool that recommends a course of action isn't inside this carve-out at all, which surprises consumer health founders regularly. The 2026 revision didn't change that.
The fourth is the one AI fails. A model that returns a confident recommendation with no visible reasoning gives a clinician nothing to independently review. Show the retrieved evidence, cite the source, expose the inputs that drove the output. That's not a nice-to-have interface decision. It's load-bearing for staying outside device regulation, and it happens to make the product better.
The 2026 revision did loosen one thing worth knowing. The earlier guidance leaned against tools that offer a single recommendation rather than a list of options. The current version allows for a single output where that's clinically appropriate, which removes an awkward design constraint a lot of products were working around. It also stayed notably quiet on AI specifically, so don't expect it to answer your model-shaped questions directly.
This is a summary, not legal advice, and the boundary genuinely is contested. If your product is anywhere near this line, pay a regulatory specialist for an hour before you pay engineers for a month.
What Does a Healthcare AI MVP Cost?
Cost tracks the ladder more closely than it tracks the feature list.
| Rung | Indicative build budget | Why |
|---|---|---|
| Synthetic data concept | $20,000 to $45,000 | Product, workflow, AI, interface. No compliance workstream |
| De-identified data | $30,000 to $60,000 | Adds the de-identification work and its verification |
| Limited data set | $45,000 to $90,000 | Adds agreements, access control, audit logging, review |
| Full PHI | $75,000 to $150,000+ | Adds the vendor chain, safeguards, risk analysis, policies, and documentation |
These are Amplence planning ranges, consistent with the build bands in our breakdown of what an AI MVP actually costs. They exclude the ongoing run cost of models, retrieval, and hosting, which is a separate ledger.
Notice that the software in rows one and four can be nearly identical. The difference is the apparatus around it. That's why we treat the ladder as a budget tool first and a privacy one second: it's the only lever that moves a healthcare quote by a factor of three without changing a single screen your users will see.
If you're comparing proposals, ask each agency which rung they've priced. We've seen founders hold two quotes that differ by $60,000 and assume one team is padding, when the real difference is that one priced a synthetic-data concept and the other priced a product that handles live records. Both can be honest. Neither is comparable until you fix the rung.
Which Path Fits Your Product?
A founder testing a healthcare idea
Rung one. Build the workflow on synthetic data, put it in front of ten clinicians or ten patients, and find out whether the thing you imagined is the thing they need. Four to eight weeks. If nobody wants it, you've spent a fraction of what the compliant version would have cost to discover the same thing.
A clinic or practice automating admin work
Rung one or two, then a careful step up. Intake, triage, documentation, and follow-up are the highest-value targets and most of them can be proven without live records. Our AI automation work in healthcare starts here for a reason.
A funded startup with a clinical claim
Rung four eventually, but not first. Get the regulatory read early, design for the FDA criteria from day one, and build the evidence-showing interface before you need it. Budget 12 to 24 weeks and treat compliance as a parallel workstream with its own owner.
A digital health product selling to health systems
You will be a business associate, and your buyers' security reviews will be harder than the regulation. Plan for the questionnaire, not just the rule. Every safeguard you can evidence shortens a sales cycle.
Frequently Asked Questions
Can a healthcare MVP be HIPAA compliant?
An application can be built to meet the Security Rule's requirements, but "compliant" describes an organisation operating a set of controls, not a product you can buy. Readiness depends on your real data flows, vendors, contracts, policies, and training. We won't describe a build as HIPAA-ready without validating those, and you should treat anyone who does with suspicion.
Do I need a BAA for an MVP that uses synthetic data?
No. If no protected health information is involved, there's nothing for a business associate agreement to govern. That's precisely why the synthetic-data route is so much faster.
How long does healthcare AI MVP development take?
Four to eight weeks on synthetic data, six to ten on de-identified data, and twelve to twenty-four or more once real patient information is involved. The variable that moves the number is data class, not model choice or feature count.
Is de-identified data really outside HIPAA?
Yes, when it's de-identified by one of the two methods the rule permits: expert determination or safe harbour. The catch is that both are more demanding than people assume, particularly for free-text notes where identifiers hide inside sentences.
Will my AI feature need FDA clearance?
It depends on whether it meets all four criteria of the clinical decision support carve-out. The criterion most AI products fail is the fourth, which requires a clinician to be able to independently review the basis for a recommendation. Design for explainability early and get a specialist opinion before launch.
What should I ask an agency before hiring them for healthcare work?
Ask which rung of the data ladder they'd recommend and why. Ask them to name the safeguards they'd implement and which are their responsibility versus yours. Ask what they will not claim about compliance. An agency that promises HIPAA compliance as a deliverable has told you something useful about itself.
