At the same time, healthcare AI assurance is becoming more formal on the buyer side.

On July 29, Hackensack Meridian Health became the first health system to earn the Joint Commission’s Responsible Use of AI in Healthcare certification. The certification evaluates the health system’s governance, privacy safeguards, risk and bias processes, performance monitoring, transparency, and staff training. It does not certify individual AI products.

Read those developments together and the direction becomes clearer.

A common federal disclosure framework may be shrinking just as health systems begin building more formal processes for evaluating and governing AI. The questions about validation, intended use, limitations, bias, monitoring, and accountability are not disappearing.

They are moving into procurement, contracts, accreditation, and customer-specific governance reviews.

For a large certified health IT developer, that may reduce regulatory work.

For a smaller healthcare AI vendor, it may replace one standard with a different questionnaire from every buyer.

The rule probably does not apply to you directly

The certification criteria sit with certified health IT developers.

That means companies such as Epic and Oracle Health. It probably does not mean the MedTech, diagnostics, SaMD, or analytics company delivering a product through someone else’s certified platform.

But vendors outside the certification program still feel its effects.

The criteria influence what a certified platform collects from an application developer, what appears in an integration agreement, and what a health system expects to review during procurement. A requirement that begins with the certified platform can reach a smaller vendor as a contractual flow-down or an app-review checklist.

Deleting the criterion does not necessarily delete the clause.

The cheapest useful response to the rule may therefore be a contract read, not a regulatory assessment.

Open your integration agreements and search for 170.315(b)(11), the decision-support interventions criterion. If an agreement incorporates the regulation by reference, the obligation may change when the regulation does. If it restates the required fields in the contract, the obligation may continue until the contract changes.

No major platform removes a shipped data field or rewrites an integration process the day a federal paragraph disappears. Some requirements will survive for at least a release cycle. Others may remain because buyers still find the information useful.

That is the larger story.

Some of the 34 removals matter more than others

The headline count overstates the substantive change.

Some of the criteria proposed for removal are expired, duplicative, or weak. An accessibility criterion accepted a response that no accessibility-centered standard had been applied. Two privacy and security criteria operated as attestations rather than functional tests.

But several requirements produced real evidence.

The safety-enhanced design criterion required a user-centered design process across nine health IT capabilities, with at least 10 test participants for each capability tested. The results included task success and failure rates, performance time, and user satisfaction information, and were made public through the certified product list.

The decision-support criterion created a standardized set of source attributes for predictive interventions. Those attributes covered areas such as intended use, developer identity, funding, validation, limitations, performance, bias management, and ongoing maintenance.

It also required developers supplying predictive interventions to describe their risk-management practices and make the summary publicly available without imposing additional steps on the reader.

Under the proposal, the source-attribute and risk-management publication requirements would be removed. The federal rule does not replace them with another common disclosure mechanism.

The need for the information remains. The common method of supplying it does not.

The provider still has to ask

A health system evaluating an AI product still needs to know:

What population was used to validate it?

What intended use does the evidence actually support?

Where does performance degrade?

How was bias assessed?

What monitoring occurs after deployment?

Who is responsible when the model, data, workflow, or intended use changes?

Removing a certification field does not make any of those questions less important.

The Joint Commission and CHAI guidance behind the new certification directs health systems to ask developers how their tools were tested and validated for the intended use, whether they will tune or validate against a sample representative of the deployment context, and how relevant biases were evaluated. It also places responsibility on the health system to establish governance, contracting, and ongoing monitoring processes.

The provider owns the deployment decision and its governance.

The vendor supplies much of the evidence needed to support it.

So information that once appeared in a defined certification field may become a document exchanged during procurement, an answer prepared for an AI committee, or a bespoke section of a customer questionnaire.

The work does not cleanly transfer from the platform to the vendor. It becomes negotiable, inconsistent, and private.

One important boundary: audit controls, authentication, and access control do not become solely the provider’s responsibility if the related certification criteria disappear. A hosting vendor that is a HIPAA business associate already carries the applicable Security Rule duties directly. Those obligations were never sitting only with the customer.

One schema out, several substitutes in

The replacement landscape is already taking shape.

The CHAI Applied Model Card offers a standardized transparency format covering intended use, performance, risks, limitations, and responsible AI practices. It was explicitly designed to support transparency for predictive decision-support interventions and is now available through a public registry.

The Joint Commission certification applies to organizations using AI. It creates provider-side expectations around governance, risk, monitoring, privacy, and training, which will affect the information health systems request from vendors.

URAC’s Health Care AI Accreditation has two paths: one for organizations using AI and another for developers and vendors. That makes it a direct assurance option for companies building healthcare AI, not only for their customers.

HITRUST offers an AI Security Assessment and Certification focused specifically on the security controls of deployed AI systems. That can provide useful assurance about security, but it does not establish the product’s clinical validity, intended use, or effectiveness.

California now requires developers of certain generative AI systems made available to Californians to publish documentation about the data used to train them, including a high-level summary of the datasets. The requirement took effect January 1, 2026, and applies only where the statutory scope is met.

Colorado’s replacement Automated Decision-Making Technology Act will require developers of covered systems used in consequential decisions to provide deployers with technical documentation describing intended uses, categories of training data, known limitations, and instructions for appropriate use and human review beginning January 1, 2027.

A vendor may also carry contractual documentation inherited from an EHR or platform partner, plus a different questionnaire from every customer building its own governance process.

These are not interchangeable versions of the same standard.

They apply to different entities. They examine different dimensions of the product or organization. They operate on different timelines. Some are legal requirements. Some are voluntary. Some focus on security. Others focus on organizational governance, model transparency, or deployment monitoring.

That is why removing one common schema can produce more work rather than less.

A schema is a leveling device

A common disclosure format does more than create compliance work.

It gives a buyer a way to evaluate a company it does not already know on the same surface as a company it does.

The evidence may still be incomplete. A model card does not prove that a product is safe, effective, or appropriate for a specific deployment. A health system may still need local validation, security testing, workflow review, and monitoring.

But the schema creates a common starting point.

Remove it and evaluation becomes more dependent on the buyer’s own process, the vendor’s ability to support repeated diligence, and the trust the company already carries into the room.

That favors incumbents.

A well-known vendor can survive an incomplete answer because the committee has prior experience, references, and an existing commercial relationship. A smaller company is more likely to be evaluated through the completeness and credibility of the evidence it can produce.

Standardization does not eliminate that disadvantage. It reduces it.

The buyer response to HTI-5 is telling. The American Hospital Association asked ASTP/ONC to retain the current privacy and security criteria and the decision-support interventions criterion. Hospitals use the certification framework as part of the foundation on which they evaluate and operate health IT.

The people producing the disclosures may experience them as burden.

The people relying on them may experience them as assurance.

Both can be right.

ASTP may still be right

Several of the proposed removals are defensible.

An accessibility criterion that accepts “none” does not establish accessibility. An attestation that allows a developer to report that a security capability is not supported does not test the capability. A static disclosure does not prove that an organization tested the product on its own population or will monitor it after deployment.

Certification may simply be the wrong mechanism for some of these questions.

A better procurement process would ask sharper questions than a fixed list of source attributes and test the answers in the intended deployment context.

The strongest version of ASTP’s argument is not that the questions no longer matter.

It is that certification is no longer the best place to ask them.

That argument wins if buyers converge on something better.

It loses if every health system, accreditor, platform partner, and state creates a different partial replacement.

The test is not how many criteria disappear from the Code of Federal Regulations. It is whether one credible substitute becomes common enough to reduce repeated work while improving the quality of the evidence.

The Joint Commission program now has its first certified health system. What matters next is whether it becomes a shared operating standard or one more framework in an expanding stack.

What vendors should do now

Start with one question for the head of quality:

If our largest customer asked today how this product was validated, on which population, with what known limitations, and under what ongoing monitoring plan, what file would we send?

If the answer is a collection of slides assembled for the last board meeting, the problem already exists.

Then take three steps.

Read the integration agreement. Determine whether your evidence obligations incorporate the certification rule by reference or restate them as contractual duties.

Map each artifact to its future requester. Identify what you currently produce because a certification criterion asks for it, who will request it if the criterion disappears, and which documents have no obvious successor.

Choose one durable evidence package. The CHAI Applied Model Card is a practical starting point because it preserves much of the structure vendors have already built. Maintain one source of truth and map customer requests back to it rather than rebuilding the evidence for every deal.

Providers should make the reciprocal move.

Accept a common evidence package where possible. Add custom questions only for the risks, population, workflow, and deployment conditions that are genuinely specific to the organization.

Otherwise both sides will spend more time translating formats and less time determining whether the product works for the intended use.

The final HTI-5 rule may remove a federal disclosure requirement.

It will not remove the buyer’s need to understand what it is purchasing.

The decision for vendors is not whether to keep producing evidence.

It is whether to let every customer invent the format.

When assurance requirements are shifting across regulation, contracts, and customer governance, the challenge is not simply producing more documentation. It is knowing which evidence will change the buying decision and building it before each customer invents a different test.

Work with Vahana Labs

Vahana Labs offers two focused diagnostics for healthcare leaders at a point of operational or commercial friction. The Operating Leverage Diagnostic identifies where growth, acquisition, or technology investment should be producing greater margin, capacity, cash, or control, and why it is not. The Commercialization Leverage Diagnostic helps healthcare technology companies determine what must change across evidence, claims, buying, implementation, and adoption to turn product traction into repeatable enterprise business.

Arvita Tripati is the founder and CEO of Vahana Labs, where she advises healthcare executives and investors on commercialization, operating leverage, and AI operating models. Over nearly two decades, she has helped build and scale more than 30 regulated healthcare products spanning diagnostics, wearables, clinical-trial technology, and AI-enabled products. She writes Operating in HealthTech about what healthcare leaders must make repeatable before products and platforms can scale.

Free accounts and all their data get deleted on August 15. Paid accounts get 60 days, a prorated refund, and an export window that closes September 14. Every workflow, every table, every connected integration, gone by mid-September unless you pull it out first.

Relay.app is a general workflow automation tool in the same family as Zapier and Make, founded in 2021, backed by Andreessen Horowitz and Khosla. It is not sold into healthcare. That is not a reason to skip this. It is the mechanism. Tools that do not look like clinical systems are exactly the ones that end up load-bearing inside healthcare operations without anyone reviewing them, which is the first half of what I want to argue. The second half is that the version of this problem arriving next is materially worse than the one in the email.

First, the part that isn’t new

Let me concede the obvious before arguing the rest, because otherwise you will.

Most of this is not an AI story. A vendor shuts down, sends the email, customers scramble to export before the window closes. That has been true of SaaS for fifteen years, and “do your vendor diligence” is the oldest lesson in procurement. Relay.app in particular is a thin AI case. It raised about $8.1 million, took its last round in 2023, and could not raise again in a category the automation incumbents and the foundation labs are both entering at once. Textbook shakeout.

The concession goes further. Even the biggest healthcare AI collapse we have was not, at root, an AI failure. Olive AI hit a $4 billion valuation with more than $850 million raised and revenue cycle automation running at more than 900 hospitals across 40 states. It shut down at the end of October 2023. The reasons were old ones. It told customers it would cut administrative spending fivefold and did not come close, and an Axios investigation found it was working from rough estimates, tracking savings only when a client asked, and overstating what it could do. Its own CEO named fast growth and lack of focus as what strained the company. Overpromised ROI, unfocused expansion, a funding winter. You could have written that post-mortem about a SaaS company in 2013.

Holding tokens and acting across systems is not new either. Zapier has held OAuth credentials and fired actions into other people’s software since 2012. If your objection is that none of this is specific to AI, you are right about the email in your inbox this week.

What actually changes

Two things, and neither is the shutdown.

Relay is the last easy version of this. Relay.app’s exports include workflows as JSON. That matters more than it sounds. Its logic is deterministic: if this, then that, written down, legible, portable. When a rules engine dies you can read exactly what it did, hand the file to a successor tool, and reconstruct any past decision by replaying the rule that produced it. Painful migration, solvable problem.

Now run the same shutdown against what is replacing this category. What follows is a forecast rather than a post-mortem, since the agentic tools now entering healthcare operations have not been through a wind-down yet. That is the point. The time to ask these questions is before the first one sends this email, not after. An agent does not execute a rule you can export. It decides at runtime, and the decision is a function of a model, a prompt, and whatever context it had accumulated in that moment. Relay’s own export includes AI prompts, which is the legible fraction, and a prompt is not a decision record. It tells you what you asked for, not what the thing concluded on March 12 for that specific patient record.

To be fair to the engineering: the reasoning is usually recorded somewhere. Agentic systems emit traces, tool calls get logged, and any serious vendor runs observability on all of it because they need it to debug their own product. The record generally exists.

The problem is who holds it and for how long. That trace sits on the vendor’s infrastructure, under a retention window the vendor set, almost never appearing in the customer export, and often tied to a model version that gets deprecated on the vendor’s schedule rather than yours. A trace also shows the sequence of actions taken, not a rule you can hand a successor and run. So when an agentic vendor sends this email, you are not losing reasoning that never existed. You are losing access to reasoning you never controlled, on infrastructure that is being turned off, along with the accumulated corrections and tuning that made the thing good at your work in the first place.

In healthcare that stops being an ops problem. If a regulator, an auditor, or opposing counsel asks why a claim was routed a certain way or why a patient was flagged, “the vendor shut down and took the logs with it” is not an answer that survives contact. The obligation to explain outlives the vendor. That is fixable, and it is fixable with contract language rather than engineering, which is why it is so galling that almost nobody asks for it.

The replacement is not a swap. It is a revalidation. Trade one CRM for another and you re-point a pipe into a familiar shape. Trade one AI tool for another and the replacement behaves differently on the same inputs, so migrating means confirming the new outputs are right before you trust them. For a regulated or GxP-scoped system, that is formal revalidation with documentation and sign-off, landing on a timeline set by someone else’s shutdown calendar. For everything else it is still output verification nobody put in the migration budget. Either way the clock belongs to the vendor and the work belongs to you.

Why it doesn’t get caught

Often the evaluation did not fail. It never ran, or it ran on the wrong version of the tool.

A product like Relay.app enters framed as administrative glue: notifications, scheduling, reminders, moving records between two systems. Because it looks like ops tooling and not a clinical system, it comes in on a pilot budget or a department card and skips the vendor review a core system would get. The trap is that “administrative” and “PHI-free” are not the same thing. A scheduling tool pulls patient identifiers. An intake router carries clinical detail. An appointment reminder knows who is seeing which specialist. The tool gets waved through on what it looks like, not on what it touches.

And when something did get reviewed on the way in, the review was scoped to its day-one job. Then usage grew, one workflow at a time, and nobody re-ran the review when the scope did. A tool cleared for internal notifications a year ago may be acting across half your stack now, and the assessment on file still describes the old version. Most health systems cannot produce a current list of which AI tools touch protected data, because those tools arrived one corporate card and one quiet expansion at a time.

This is trust debt. Not the vendor failing to earn trust, but an operation depending on something it never named, on terms it never priced, in a way nobody wrote down. It accrues quietly and comes due all at once, usually on a schedule set by someone else. The shutdown email is just the invoice.

If you’re buying

Run this at procurement, and run it on the vendor that looks too established to fail, because that is the one you are least likely to have a fallback for. None of it asks you to predict which vendor dies. It asks you to know what breaks if one does.

The decision record. Start here, because it is the question no standard vendor questionnaire asks. If this tool decides rather than executes, four things need answers in writing: what gets logged about how an output was produced, how long it is retained, whether you can pull those records yourself on demand, and what happens to them at termination. If the honest answer is that traces live on the vendor’s servers for thirty days and never appear in your export, you now know what you cannot explain later, and you can negotiate it before signing instead of discovering it during an audit.

Portability. Can you export config, data, and run history in a format someone else reads, on demand, without a support ticket or a services engagement?

Money. Do not expect the truth from the sales call. The signal is outside it: headcount trend, quiet layoffs, the date and size of the last raise, whether incumbents they cannot outspend are entering the category.

Contract language. Notice period before wind-down, data-return and deletion timeline, and the change-of-control clause. That last one matters more than the shutdown scenario, because assignment is the more likely ending. When Olive collapsed it did not evaporate. Its clearinghouse and patient access businesses went to Waystar, prior authorization to Humata Health, and its payer utilization management tool had gone to Availity earlier that year. Customers who had diligenced Olive woke up as customers of companies they never evaluated, on contracts negotiated with one that no longer existed. Require notice before assignment and an exit if the new owner does not meet the same bar. For anything touching a patient or a payment, add escrow.

Scope. What can this tool reach, and what does it do without a human in the loop? If you have a current integration inventory and data flow diagram, this is a ten-minute exercise. If you do not, that gap is the more urgent finding. Either way, know which integrations go dark when stored tokens are deleted, and make sure the BAA says how protected data is returned and destroyed after termination, on a timeline that does not collide with your own retention rules.

Blast radius. How many workflows route through this one vendor, and does any of them have a manual fallback or a second source?

If you’re building

Every one of those questions is coming for you. It arrives as a line in a security questionnaire, or as the moment on a procurement call when someone asks what happens to their data if you go under and the room goes quiet. That question is not a formality before the real evaluation. The answer decides whether security signs off, and security not signing off is how pilots die without anyone telling you why.

On runway. When a CISO asks a fifteen-person company how long it can last, do not dodge and do not oversell:

“We have about [X] months of runway and we are raising our Series A in [quarter]. Because we are early, we put the protection in the contract instead of asking you to take our word for it: full data export on request within [N] business days, [N] days written notice before any wind-down, and return-and-deletion terms written into the BAA. Our size is the reason to hold us to those, not a reason to wait on the pilot.”

That converts your stage from a risk they price into commitments they can hold you to.

On the decision record. If your product decides rather than executes, this is the question that will separate you, and you are probably most of the way there already. You almost certainly log traces, because you need them to debug. The gap is not instrumentation. It is that those traces are yours, kept as long as suits you, invisible to the customer, and gone when your infrastructure is. Closing that gap is a commitment, not a build: name a retention period, give the customer a way to pull their own records, and include them in the export and in the return-and-deletion terms. Most vendors have not thought about this, which is why answering it well is worth more right now than another accuracy benchmark. It is what lets your customer explain a decision to a regulator eighteen months from now, whether or not you still exist.

On context portability. You will be asked whether they can take everything with them, and the honest answer is that records export cleanly and accumulated tuning does not. Say so first, before they find it. Then say what you do about it: export configuration, rules, and prompt logic in human-readable form so a successor can be rebuilt from it. Naming this yourself reads as candor. Letting counsel find it reads as lock-in, and lock-in in front of a health system’s legal team is a reason to wait.

On scope. Publish what your tool can reach and what it does without human approval, and keep it current. Then offer the clause almost nobody offers: written notice when the scope of what your tool touches materially expands, so their review can be re-run against what it actually does now. That is the direct antidote to the stale-assessment problem, and it may be the most persuasive thing in your security packet, because it tells the reviewer you understand the failure mode they live with.

On the floor. You do not need a full export product to make these commitments. Self-serve exports are the ceiling; the floor is contract language your lawyer writes, not a feature your engineers build. Five clauses cover most of it: an export-on-request SLA delivering full data and configuration in an open format within a set number of business days; data return and deletion tied to termination; a defined notice period before wind-down; change-of-control notice before assignment; and scope-change notification. None of that is a build. All of it reads as confidence offered while you are alive, and as a confession offered when you are not.

What to do this week

The shutdown email is the old part of this story. What is changing is the dependency it interrupts. A rules engine dying costs you a migration. An agent dying costs you the migration plus the ability to explain what it did, and healthcare is one of the few markets where that second cost has a legal deadline attached.

Buyers: name the one AI tool whose shutdown or acquisition would hurt you most, and find out today whether you could export it, run your fallback, and verify a replacement without the vendor’s help. Founders: write the answer to “what happens to our customers if we disappear or get bought” this week, and put the five clauses in your next contract.

Sources: Relay.app shutdown announcement (relay.app); PitchBook and Tracxn on Relay.app funding and stage; Healthcare Dive and Fierce Healthcare on Olive AI’s 2023 wind-down and asset sales; Axios (April 2022) and eMarketer on Olive’s savings claims.

Three tools. One problem: your product is ready but the deal isn’t closing.

• Pressure Test — Find out where your pitch breaks, before the room does. Free to start.

• Healthcare Market-Fit Lab — Diagnose whether the market you chose can actually buy what you built.

• Sold. Build Your Pilot Conversion Playbook — Build the positioning, documents, and pilot structure that get contracts signed.

All three are built on the same premise: stalled deals are structural problems. The pitch is usually the last thing that needs fixing.

Arvita Tripati is the Founder and CEO of Vahana Labs, a B2B strategy consulting firm helping healthtech and AI startups transition from pilot to enterprise contract. She has launched 30+ regulated AI-enabled products and worked with firms like the VA, Moderna, Gilead, NHS, and Bristol-Myers Squibb.

That tension runs underneath a whole family of Medicare codes, and it points to something most people building on them have not sat with. As the technology improves, a code that pays for documented labor becomes a weaker business to own, not a stronger one. It is worth understanding why before you build anything else on one.

The code made it billable, not deliverable

Start with the largest example. In 2015, Medicare began paying separately for chronic care management. The base code, 99490, pays a practice for at least 20 minutes per calendar month of clinical staff time spent coordinating care for a patient with two or more chronic conditions. Roughly $60 per patient per month. About 70% of Medicare beneficiaries qualify. On paper, it is one of the largest addressable populations in outpatient medicine.

Adoption never came close. By 2019, roughly 4% of eligible beneficiaries were receiving chronic care management, up from a little over 1% in the first year. Most practices that tried it billed it for only a fraction of their eligible patients, and often not every month.

The reason was not that practices could not get paid. The code existed and the claim went through. The reason was that the payment did not cover the cost of actually doing the work: the consent, the comprehensive care plan, the monthly outreach, the precise time-tracking required to defend every claim. The allowable reimbursement was too low relative to the burden of building and running the service.

The code made the activity billable. It did not make it deliverable. That gap is where a lot of healthcare companies quietly get stuck.

Getting paid is not the same as getting adopted

A reimbursement pathway answers one narrow question: can someone submit a claim for this activity?

It does not tell you whether the people expected to do the work will make time for it, whether the payment covers the operational burden, whether the organization will redesign its workflow around it, whether the activity produces something the buyer actually values, or whether the organization doing the work is the same one that captures the benefit.

Chronic care management answers yes to the claim question and not really to almost all the others. A code that recognizes a service is not the same as a service that fits into clinical operations.

And chronic care management is not alone. It is the largest of a family built the same way: transitional care management, principal care management, behavioral health integration, and the remote monitoring codes in this year’s rule all pay a practice for documented time or activity rather than for a result. The pattern is the structure, not the particular code.

What happens when the labor is the thing being automated

The work these codes pay for is increasingly being pulled out of the exam room. Care management now runs through centralized teams, remote nurses, and, more and more, software that handles outreach, triage, documentation, and follow-up. The direction is obvious to anyone building in the space: the 20 minutes of clinical staff time a code like 99490 pays for is exactly the kind of work automation is getting good at.

Which creates a strange problem. When the documented minutes a code pays for can be produced by software at close to zero marginal cost, a business built on billing per documented minute starts to erode from underneath. Better automation makes a pay-for-labor code less defensible, not more. The improvement you were counting on is the thing that undermines the model.

And automation is not the only pressure on these codes. Fee-for-service rates are on a downward path, and the same 2027 rule is a small example of it: as a temporary 2026 increase expires, the base rate most clinicians are paid goes down next year. So in one document, CMS expands the ways you can bill for care-management time and lowers what that time is worth. Squeezed on price from one side and on cost from the other, the code gets worse to build on every year.

The problem with paying for time

Chronic care management pays for 20 minutes. It does not pay for whether the patient’s diabetes stayed controlled, whether a medication conflict got caught before it put someone in the hospital, or whether a deterioration got flagged early enough to matter. Those are the outcomes. The minutes are the input.

When reimbursement pays for documented time, the system rewards the documented performance of the activity, not the completion of the underlying job. Push people toward that model and you train them to watch the clock and play the coding games that follow, none of which touches whether the disease was actually managed. You can hit 20 clean minutes every month and change nothing about the patient’s trajectory, and the claim is still valid. The 2027 proposal, by tightening who may deliver remote monitoring rather than what it has to achieve, keeps the whole apparatus pointed at the input.

Follow the value, not the code

When CMS’s own evaluation contractor studied chronic care management’s early years, it found real savings: per-beneficiary-per-month spending fell by about $74 after 18 months, concentrated in inpatient and post-acute care. Over the same period, Medicare’s payments to physicians went up.

The savings and the billing landed on different line items. The practice collected about $60 a month for the documented time. The reduced hospital and post-acute spending accrued to whoever was carrying the total cost of care. In fee-for-service, that is Medicare. In a value-based arrangement, it is the ACO, the health plan, the management services organization, or the risk-bearing group.

That is the recurring healthcare commercialization problem in one data point. The user, the person doing the work, the organization submitting the claim, the budget holder, and the entity that captures the value are often different parties. Reimbursement pulls you toward the one that can bill. A more durable business usually comes from selling to the one that actually benefits when it works.

What the automation lets you do

When software can produce the documented work, the obvious play is to keep the code and pocket the difference: automate the 20 minutes, still bill the $60, run the margin. It works until it does not. You are now running an arbitrage on a reimbursement rate, and everything above is squeezing it. CMS keeps tightening who is allowed to deliver the service, which is what this year’s remote monitoring proposal does. And “20 minutes of clinical staff time” is a strange thing to bill when no clinical staff spent 20 minutes. The better the automation, the more the model leans on a fiction the payer is actively rewriting.

The thing worth building is the one the old labor model could not support. When a nurse spent 20 minutes each on a few dozen patients, you could promise the activity, not a result. You had no way to reach the whole panel. When software can touch every eligible patient every month, that changes. For the first time you can be accountable for the outcome the activity was always a proxy for: the deterioration caught early, the medication conflict flagged before the admission, the care gap closed across the entire panel rather than the handful a human team could get to. Automation does not just make the minutes cheaper. It makes it possible to sell the result instead of the minutes, because you can finally produce the result at a scale a buyer will pay for.

That is a different company than the one that bills 99490. The customer moves from the practice that can bill to the organization that carries the risk. The evidence moves from a time log to a measured outcome. The price moves from a per-claim fee to something tied to the result. Technology, workflow, customer, and revenue model change together, or the automation just makes you better at billing a code that is quietly getting cut. That is far harder than adding a copilot. It is also the only version of this that gets more valuable as the models improve.

Skipping the code changes the proof, it does not remove it

None of this makes reimbursement irrelevant. It is often still the cleanest path to a sustainable business, because it creates budget, lowers buyer uncertainty, and gives you a familiar way to get paid. Selling against cost reduction and outcomes is harder.

Chronic care management shows exactly how much harder. The savings are real, but they are uneven and contested, and adoption stalled at a few percent of the eligible population. If you sell a care-management service on “we will lower your total cost of care,” you inherit all of that. You have to prove the intervention produces a result, that the result creates measurable economic value, that the buyer can attribute enough of it to you, that the savings land inside a useful window, and that the buyer has the budget and the contract to pay you through.

A healthcare strategy consultant I know has watched this from the inside: companies that could show a real cost reduction, sometimes as much as half, that still could not move a payer contract forward. The evidence was not the problem. The savings took three to five years to land, and the commercial payers across the table were deciding on a one-to-three-year horizon. The result was good enough to be true and too slow to be bought.

And even a real number is not enough on its own. The organization that captures the value is a harder sale than the practice that could bill: it scrutinizes attribution the way its own actuaries do, and often wants shared risk rather than a software fee. The $74 above is a program-level average, not your result to promise. It shows the category can produce savings; it does not prove your product will. Carry an unowned number into that room and you will spend the meeting defending someone else’s study.

That is a heavier burden than “we performed 20 documented minutes.” It is also a more defensible business, because a buyer who pays for a result you can prove does not churn the first time budgets tighten.

Skipping reimbursement does not remove the evidence burden. It changes it. Instead of proving that an activity happened, you have to prove that it mattered.

Before you build anything else on the code

If you are building on a care-management code, these are the questions worth answering first:

• Is the code paying for the outcome, or for the labor historically required to produce it?

• Does the reimbursed workflow create adoption friction the payment does not cover? If most eligible patients never get the service, that is your answer.

• Who experiences the clinical benefit, and who captures the economic benefit? Are they the same organization?

• Does that organization have the authority and the budget to be your buyer?

• If software can produce the documented work, does your billing model get more attractive or less defensible?

• Are you using automation to perform the old activity more cheaply, or to take responsibility for a result the old activity was only ever a proxy for?

If those answers point away from the code, the move is not to reposition the whole company on Monday. It is to run the test cheaply. Pick one outcome the code is a proxy for and instrument whether your automation actually moves it on a defined panel of patients. Take that measured result to the one buyer who carries the risk for it. Prove the result on a small panel and you have the start of a business you can sell on the outcome. Fail, and you have a cheaper way to bill a shrinking code. Better to learn that on one panel than after you have built the company around it.

A code confirms the market recognizes a need. It cannot tell you what business to build. And when the technology changes what the work actually is, a code will quietly keep you selling the old version of it.

Three tools. One problem: your product is ready but the deal isn’t closing.

• Pressure Test — Find out where your pitch breaks, before the room does. Free to start.

• Healthcare Market-Fit Lab — Diagnose whether the market you chose can actually buy what you built.

• Sold. Build Your Pilot Conversion Playbook — Build the positioning, documents, and pilot structure that get contracts signed.

All three are built on the same premise: stalled deals are structural problems. The pitch is usually the last thing that needs fixing.

Arvita Tripati is the Founder and CEO of Vahana Labs, a B2B strategy consulting firm helping healthtech and AI startups transition from pilot to enterprise contract. She has launched 30+ regulated AI-enabled products and worked with firms like the VA, Moderna, Gilead, NHS, and Bristol-Myers Squibb.

Nikhil Krishnan made an argument that the consumer health stack is commoditizing. Labs, records, telehealth, even AI primary care are swappable, and most of them burn cash on their own. His read is that wearables are the layer that holds up. They measure you objectively instead of asking you to rate your anxiety from one to ten. They tell you something is off before you go looking. And they earn on hardware margin and recurring software at the same time, right when software-only moats are eroding.

He is right about all of it. I want to push on the one word doing the heavy lifting, because if you are building one of these companies, “defensible” is hiding the decision that determines whether you make it.

The sensor is the most commoditized part of the entire stack.

The sensor is table stakes now

Dexcom and Abbott make the large majority of CGM hardware. Stelo, the first over-the-counter glucose biosensor, is resold under a dozen metabolic-health brands. Signos and Nutrisense run on it. The wrist is converging too, with Oura, Whoop, Apple, and Samsung chasing the same optical and electrical sensing. If your defensibility is the component, you are defending the one thing two device giants and several trillion-dollar platforms already make better and cheaper than you can.

Then the regulator widened the door. On January 6, the FDA rewrote its general wellness guidance. Non-invasive sensing of heart rate, glucose, blood pressure, and heart rate variability can now sit in the wellness lane with no clearance, as long as you avoid claims about diagnosis, disease, or clinical management. At Wilson Sonsini’s medical device conference this month, the pathway-and-enforcement-discretion question was on the main stage. The agency framed the change as removing friction for innovators. From a founder’s chair, it removed a wall.

That gift makes the layer more commoditized, not less. The clearance burden used to be the moat nobody talked about. It kept the look-alikes out. Now anyone can buy the sensor and ship the reading without a review. The barrier you were quietly standing behind just came down for you and for everyone chasing you.

A reading is not an action

If the sensor is table stakes and the raw reading is now license-free, what is left to defend? The interpretation that someone will act on.

There are exactly three buyers of an action: the person wearing the device, a clinician, and a payer. Each has a different bar, and only the second and third pay in a way that compounds.

The consumer pays for novelty, and for most products the loop goes stale and the band comes off. A rare few engineer retention well enough to make consumer subscription a real business. Most do not, which is why Signos just raised $20 million, per MedCity News, to push CGM past diabetes into weight loss on the back of GLP-1 demand. Read that as the consumer wedge searching for a stickier reason to exist. Glucose curves are interesting for a month.

The clinician does not distrust your data. A published survey of physicians on smartwatch cardiovascular data found they agree it is useful, then named the actual blockers: no billing code, and no time in the visit. The handle people reach for is the remote monitoring code family, RPM for device-supplied physiologic data and RTM for therapeutic data, built for exactly this. Here is the catch, and it is the whole argument in miniature. Those codes generally require the data to come from a device that meets the FDA definition of a medical device. The reimbursement handle sits on the far side of the same line you were tempted to stay behind. You cannot bill your way out of the wellness lane while you are standing in it. A code is the difference between a reading that dies in the inbox and a reading a clinician is paid to look at, and reaching it means crossing the line on purpose.

The payer pays for outcomes or cost offset, backed by evidence. The door here is opening, not open. Whoop’s $575 million Series G in March, at a $10.1 billion valuation, brought Abbott in as a strategic investor and Mayo Clinic as a clinical partner, per MedTech Dive. That is the consumer-subscription company with the retention everyone else envies, using its raise to buy a path toward the clinical and reimbursed side. Broad commercial coverage for consumer wearables is still thin and inconsistent, so read moves like this as early signals, not proof the door is open.

Two things a medical director will tell you on the first call. A billing code is necessary and not sufficient, because carriers can decline it, pay it poorly, or wrap it in prior authorization, and coverage is a separate fight from coding. And a payer does not reimburse an accurate reading. It reimburses a reading that, acted on, changes an outcome or lowers a cost, with evidence good enough to weigh against the current standard of care.

The trap hiding in the wellness lane

This is where the SaMD and wearable founder gets cornered, and it is a product decision long before it is a regulatory one.

The claims that keep you in the wellness lane are the same claims that make your data clinically unactionable.

To stay license-free, you say the words: for general wellness, not intended to diagnose or treat. That sentence buys you speed. It is also the reason a cardiologist cannot use your output to change a medication, and the reason a payer will not reimburse it. You bought velocity by promising your data does not matter clinically, and then your Series B story needs it to matter clinically.

Think of it as wiring versus paint. The wellness positioning is paint. You can repaint. The things that make data actionable are wiring, and you cannot rerun the wiring cheaply after you have shipped to a million wrists.

Two things are paint, the parts you can change later:

• Wellness-only positioning and claims. You can reposition, but every claim constrains who can act on the data while it stands.

• Consumer app, dashboard, and UX. Iterable and visible, and not what a clinician or payer relies on.

Everything that decides whether your data can cross into care is wiring, the parts you cannot rerun cheaply once you have scaled:

• Analytical validity, the reading being accurate in a population that looks like your users. The floor for any clinical use, and slow to reconstruct after a consumer launch.

• Clinical utility, proof that acting on the reading changes an outcome or lowers a cost. The expensive one, because it is the evidence a payer actually reimburses, and a different study from accuracy.

• A named owner for clinical liability. Decides whether a clinician can act on your output at all.

• Consent and data governance written for clinical use. Consumer consent does not cover clinical use, so a later pivot inherits a gap on data you already hold.

• A reimbursement pathway, including RPM or RTM design. No code means no durable payer, and this shapes the product, not just the billing screen.

Wiring does not mean maximum spend. The cheap version is a regulatory and reimbursement strategy memo plus early payer input, low five figures in most markets, that keeps the clinical door open: the claims you avoid now, the consent language you adopt now, the single validation endpoint you design toward. The expensive version is a full clinical-utility study and a cleared indication. You do not need the expensive version today. You need to not foreclose it. The mistake that costs the most is skipping the cheap work, because that is what quietly locks the door.

If you already shipped

Half the people reading this already launched as wellness. You are not stuck. You are paying more to fix it later than you would have paid to build it now, which is a worse position, not a fatal one.

The moves that still work: amend your claims going forward, re-consent users for clinical use rather than assuming the consumer consent covers it, and run validation retrospectively on the data you already hold. The data you gathered as wellness can often seed the evidence you need for clinical use, but only if your consent and governance permit that use. That clause is the one most teams discover too late, usually in diligence, usually when a buyer’s counsel asks the question no one on the team can answer.

Data company or decision company

The split is simpler than the category makes it look.

A data company sells readings and dashboards. It competes with everyone who can buy the same sensor, which is now everyone. A decision company sells an action a clinician or payer will stand behind. It competes with almost no one, because almost no one builds the boring parts.

I watched this from the inside at AliveCor. We built the first FDA-cleared medical device accessory for the Apple Watch. The single-lead ECG was the thing everyone pointed at. Then Apple put an ECG in the watch itself. The sensor was never the moat. The cleared indication and the accuracy a clinician would rely on held longer, and even those were table stakes, not the finish line. Getting a physician to act on the read, and getting anyone to pay for it, was a separate climb from proving the read was accurate. That is the distance between analytical validity and clinical utility, lived rather than diagrammed. If your defensibility is the part the platform owner can absorb into their next release, you do not have a moat. You have a head start, and a clock.

What to do before your next roadmap meeting

Three questions, and you can run them this week.

First, for each headline metric on your device, name the buyer of the action. Not who sees the number, who acts on it and pays. Run it on a real one. A consumer CGM that says “see how meals affect you” has a buyer of the action who is the user, and the user churns. A CGM whose reading a clinician uses to titrate a GLP-1 dose has a buyer who is the clinician, if there is a code and a liability owner. Same sensor, different company. If your honest answer is “the user feels informed,” you are a data company. That can be a real business. Just decide on purpose, not by drift.

Second, list every claim you are making to stay in the wellness lane, and for each one write down what it forecloses. If a claim blocks the clinical or payer use you are counting on eighteen months out, it is not a marketing line. It is a strategic constraint you are accepting now to move faster today.

Third, sort your trust investments into wiring and paint using the list above, then check whether your build sequence funds the wiring before the scale or after. After is the default, and after is the trap.

The front door, and what it costs

Push it out one more order, because this is where the category is heading and where this series goes next.

The company that owns the interpretation, the routing, and the reimbursement does not just have a moat. It becomes the front door to care, the role the primary care physician used to hold. A recent analysis in JMIR makes exactly this argument, and points out that we have not applied to wearable platforms the antitrust and trust scrutiny we apply to physicians who control referrals. That is the prize and the exposure in one sentence.

For now the operator takeaway is smaller and more useful. Nikhil is right that wearables are the last layer standing. But the defense is not the thing on the wrist. It is whether anyone with a budget will act on what the thing on the wrist says. That has never been a hardware problem. It is a trust problem, and trust is the one part of this stack you cannot buy off the shelf and resell.

Three tools. One problem: your product is ready but the deal isn’t closing.

• Pressure Test — Find out where your pitch breaks, before the room does. Free to start.

• Healthcare Market-Fit Lab — Diagnose whether the market you chose can actually buy what you built.

• Sold. Build Your Pilot Conversion Playbook — Build the positioning, documents, and pilot structure that get contracts signed.

All three are built on the same premise: stalled deals are structural problems. The pitch is usually the last thing that needs fixing.

Arvita Tripati is the Founder and CEO of Vahana Labs, a B2B strategy consulting firm helping healthtech and AI startups transition from pilot to enterprise contract. She has launched 30+ regulated AI-enabled products and worked with firms like the VA, Moderna, Gilead, NHS, and Bristol-Myers Squibb.

Most digital health founders will ignore it.

They shouldn’t.

The guidance is technically about orthopedic guides used to help surgeons place implants according to a pre-surgical plan. Narrow category. Specific use case.

But the underlying lesson is much bigger.

When a product turns patient-specific data into clinical action, the output is not the whole product.

The process that produces the output is the product.

That is where many digital health companies get into trouble. They think they have built a personalized product. What they may actually have is uncontrolled clinical variation with a good interface.

And that distinction tends to surface at the worst possible moment: after a promising pilot, when the company expects the buyer to move toward contracting.

The guidance is about orthopedic guides. The lesson is about trust.

Patient-matched orthopedic guides are different for every patient. Because each patient is different, FDA cannot evaluate them as if every unit coming off the line is identical.

So FDA focuses less on the individual guide and more on the controlled chain that creates it: the inputs, the software, the human review, the manufacturing process, the clinical workflow, labeling, and the fallback path.

That is the part digital health founders should pay attention to.

FDA is not just asking: “Does this guide look right?”

It is asking: “Can this company repeatedly produce the right guide from messy patient-specific inputs, through a controlled process, into safe clinical use?”

That pattern applies far beyond orthopedics.

If your product takes patient data and turns it into a recommendation, risk score, alert, care pathway, diagnostic interpretation, triage decision, AI summary, treatment suggestion, or personalized intervention, you are dealing with the same underlying problem.

You are not just shipping an output. You are operating a clinical production system.

And that system needs boundaries.

This matters because founders rarely lose enterprise deals only because the model is bad. They lose momentum because the buyer cannot tell whether the product will behave safely and consistently outside the pilot.

The pilot trap

A lot of digital health products look strong in a pilot.

The implementation team is hands-on. The clinical champion is engaged. The data issues are quietly cleaned up. The nurses learn which alerts to ignore. The founder is close to the workflow. The product team watches every edge case.

Then the company tries to scale.

The next site maps EHR fields differently. The patient population is more complex. The care team has less time. The champion is not as involved. The workflow has different escalation rules.

The “same” product starts producing different operational behavior.

The algorithm may not have failed. The uncontrolled system around the algorithm failed.

Consider a remote monitoring company that proves a readmission-risk workflow with one health system. In the pilot, everything works. The data is cleaned manually. The clinical champion reviews questionable alerts. The implementation lead fixes mapping issues before they become visible. The care team learns which outputs to ignore. The founder joins the weekly ops meeting and helps troubleshoot.

The health system sees enough signal to keep going.

Then the company expands to three more sites.

Different fields. Different escalation rules. Different staffing ratios. Different patient adherence patterns. Different comfort levels with automation.

The expansion does not fail dramatically. It gets slower.

The weekly meetings multiply. The buyer asks for more evidence. Legal wants clearer accountability. Clinical governance asks who owns false positives. The champion starts saying, “We still believe in this, but we need to work through a few things.”

That is how a successful pilot becomes a stalled deal.

The company may think it has an implementation issue. The buyer sees something more concerning: a product whose performance depends too much on informal workarounds, local knowledge, and founder proximity.

That is not just a scaling problem. It is a trust problem.

Personalization is controlled variation

Digital health founders love the language of personalization.

Personalized care. Personalized nudges. Personalized patient journeys. Personalized recommendations. Personalized AI.

But personalization creates variability. And variability creates risk.

The orthopedic guide guidance is useful because FDA does not treat variability as inherently bad. The whole point of the product is that it varies by patient. But the variation has to happen inside a controlled envelope.

The manufacturer needs to define what can vary, what cannot vary, what inputs are acceptable, what quality checks are required, who reviews the plan, and how the final output is verified.

That is the digital health lesson.

Personalization without boundaries is not precision medicine. It is variation with marketing copy.

The question is not just whether your product can personalize. The question is whether it knows when personalization should stop.

A product that adapts to a patient, clinician, workflow, or site needs to know what is allowed to vary and what is not. It needs to know when the input data is good enough to support the action being recommended. It needs to know when the patient, workflow, or clinical context falls outside what the product can responsibly handle.

That is not a regulatory nicety. That is the difference between a product that scales and a product that depends on heroic implementation.

Input quality is product quality

One of the most practical lessons in the guidance is the emphasis on image quality.

For orthopedic guides, patient imaging is the foundation. If the image is poor, the segmentation may be wrong. If the segmentation is wrong, the anatomical model may be wrong. If the model is wrong, the guide may not fit. If the guide does not fit, the implant may be misaligned.

That chain matters.

Digital health has the same problem, just with different inputs.

Your input may be an EHR field, a CGM trend, a blurry wound photo, a patient-reported symptom, a medication list copied forward three visits ago, a wearable signal, or a home blood pressure reading.

Each input has failure modes.

The founder question is not: “Can we ingest this data?”

The better question is: “When is this data good enough to support the action we are asking someone to take?”

If your product cannot distinguish between acceptable and unacceptable input quality, your downstream claims are fragile. And your buyer will eventually notice.

“Human in the loop” is not a safety strategy

This may be the most important section for AI founders.

The orthopedic guidance spends real time on healthcare professional concurrence. FDA wants clarity around when the clinician is involved, what they review, what they can modify, how plan changes are handled, and how final concurrence is documented.

That matters because a clinician’s involvement is not assumed to be meaningful simply because a clinician exists somewhere in the workflow.

Founders often say: “The clinician is always in the loop.”

That sentence does far less work than people think.

A clinician at the end of a bad workflow is not a control. A clinician asked to review too much, too fast, with too little context is not a safety strategy. A clinician who cannot see why the system produced a recommendation is not providing meaningful oversight. A clinician who is nominally responsible but practically unable to catch errors is not “in the loop” in any useful sense.

That is not safety architecture. That is liability laundering.

If the human is part of your risk control strategy, the product has to be designed around the human’s actual job. Not the job you wish they had. Not the job your pitch deck implies they have. The job they can realistically perform inside the buyer’s workflow.

Human-in-the-loop only works when the human’s role is explicit, feasible, supported, and tested.

Buyers buy governable systems

The software may run consistently. The system may not.

A product can perform well in one environment and degrade in another because the process around it is not reproducible. The issue may not be the model. It may be the data mapping. Or the implementation workflow. Or the escalation rules. Or the training. Or the clinician review process. Or the thresholds someone changed locally because “that’s how we do it here.”

This is where buyers start to wonder whether they are buying a product or signing up to co-develop an operating model.

Mature buyers do not expect your product to be perfect. But they do expect you to know how it fails, how users will detect failure, and what should happen next.

That is why fallback paths matter. Not as edge cases. As part of the product.

What happens when the AI summary is incomplete? What happens when the data is too noisy? What happens when the patient falls outside the validated population? What happens when the integration breaks? What happens when the clinician disagrees? What happens when the product should not be used?

A weak answer is: “That should not happen.”

A stronger answer is: “Here are the known failure modes. Here is how the system detects them. Here is how the user is notified. Here is what the user should do next.”

That is the difference between a promising tool and an enterprise-ready system.

The same is true for claims.

“Helps prioritize outreach” is not the same as “reduces hospitalizations.” “Generates a summary” is not the same as “improves diagnosis.” “Supports patient engagement” is not the same as “treats depression.”

The bigger the claim, the bigger the evidence burden. Founders do not need to avoid ambitious claims forever. They need to sequence them. Start with what you can support. Build evidence. Expand carefully. Do not let marketing outrun validation.

Because when marketing outruns evidence, the problem is not just regulatory risk. It is buyer distrust.

Health systems have seen too many products that promise outcomes and deliver dashboards.

The real issue is not FDA. It is trust.

It would be easy to read this guidance as a regulatory lesson. It is.

But for founders, the bigger lesson is commercial.

The same ambiguity that makes regulators uncomfortable is often what makes clinical governance committees, procurement teams, legal teams, and medical leaders slow down.

Trust infrastructure is the evidence and control layer that lets a buyer believe your product will keep working when your team is no longer in the room.

That is where many startups get stuck.

The pilot worked. The champion loved it. The deck looked strong. The founder thought the next step was contracting.

Then the buyer started asking harder questions.

What data does this rely on? How do you know the data is good enough? Who reviews the output? Can clinicians override it? What happens if the integration breaks? What evidence supports this claim? Can we defend adoption if something goes wrong?

Those questions are not bureaucratic noise. They are the buyer trying to understand whether your product can be governed.

If you cannot answer them, you do not have a sales problem. You have a trust infrastructure problem.

The takeaway

The future of digital health will not be won by the companies with the most impressive demos.

It will be won by the companies that can show their products behave safely and consistently when the founder, the champion, and the implementation team are no longer in the room.

That is the bigger lesson hiding inside FDA’s orthopedic guide guidance.

When a medical product turns patient-specific inputs into clinical action, the process is the product.

The companies that learn this early may look slower during the demo phase. They will be faster when the buyer starts asking hard questions.

The ones that ignore it will eventually discover, usually at the worst possible time, that the pilot proved the feature.

Not the product.

Three tools. One problem: your product is ready but the deal isn’t closing.

• Pressure Test — Find out where your pitch breaks, before the room does. Free to start.

• Healthcare Market-Fit Lab — Diagnose whether the market you chose can actually buy what you built. Two full-day sessions, June 6 and 13. Six seats.

• Sold. Build Your Pilot Conversion Playbook — Build the positioning, documents, and pilot structure that get contracts signed. Three weeks, starts June 1. Six seats.

All three are built on the same premise: stalled deals are structural problems. The pitch is usually the last thing that needs fixing.

Arvita Tripati is the Founder and CEO of Vahana Labs, a B2B strategy consulting firm helping healthtech and AI startups transition from pilot to enterprise contract. She has launched 30+ regulated AI-enabled products and worked with firms like the VA, Moderna, Gilead, NHS, and Bristol-Myers Squibb.

Three tools. One problem: your product is ready but the deal isn’t closing.

• Pressure Test — Find out where your pitch breaks, before the room does. Free to start.

• Healthcare Market-Fit Lab — Diagnose whether the market you chose can actually buy what you built. Two full-day sessions, June 6 and 13. Six seats.

• Sold. Build Your Pilot Conversion Playbook — Build the positioning, documents, and pilot structure that get contracts signed. Three weeks, starts June 1. Six seats.

All three are built on the same premise: stalled deals are structural problems. The pitch is usually the last thing that needs fixing.

Now, on to this week’s post.

Across 50+ companies and multiple evaluation programs this spring, I kept seeing the same disconnect. The strongest technology in the room almost never correlated with the strongest commercial readiness. Sometimes they were inversely correlated.

Not because smart people can’t do business. But because they spent their energy on what they’re best at and assumed the rest would follow.

Here are the four commercial gaps I saw most consistently.

Gap 1: The Payment Silence

I asked some version of “how does your customer get paid for using this” to nearly every company I evaluated. The hit rate on clear, specific answers was low.

One company had strong IP, clinical partnerships, and regulatory traction. When I asked about billing codes, the founder said they’d “follow the pathway of companies that recently commercialized in adjacent spaces.” That’s a placeholder for a reimbursement strategy, not a reimbursement strategy.

Another company had regulatory feedback and clinical differentiation. When asked about payment, the founder said they wanted to “partner with a large company” to handle “the downstream economics.” That’s an exit plan, not a revenue plan.

The companies that impressed evaluators had a different level of specificity. A strong answer to the reimbursement question sounds something like: “Our instrument is placed for free. The consumable costs us under a dollar to manufacture. The market pays $300 to $500 per test. Our gross margins are above 85%. We save the customer roughly $3,000 to $4,000 per case by reducing repeat testing and invasive procedures. Our initial channel is centralized because the adoption barrier is lower, and we transition to distributed instruments once we have five validated sites.”

That’s the bar. They could explain their pricing model, their cost structure, the average savings per customer, the math behind that savings figure, and why their initial go-to-market channel was different from their scaled channel.

The gap between that level of commercial thinking and “we’ll figure it out” is the gap between a company and a science project.

For founders building SaMD or devices: there’s a regulatory dimension here that’s easy to miss. Your regulatory submission determines your clinical claims. Your claims determine which billing codes you qualify for. Your codes determine how much you get paid. If your regulatory strategy and your reimbursement strategy aren’t connected, you can clear the FDA and still have no viable path to revenue.

Fundraising impact: Investors ask about reimbursement within the first 30 minutes of diligence. If you can’t answer, they won’t tell you it’s a problem. They’ll pass with feedback like “interesting technology, concerns about commercial readiness.” That’s polite code for “they can’t explain how money flows.”

The test: Can you answer these without looking at slides? (1) What existing billing code covers your product today? (2) What’s the dollar gap between that code’s reimbursement and your price? (3) Who at the health system approves that gap?

Gap 2: No Commercial Function

Multiple companies sent their technical co-founder or scientist-inventor to present at what was fundamentally a commercial evaluation. Every time, it cost them.

On the surface, this looks like a presentation problem. The scientist talks about mechanism of action when the room wants to hear about buyer impact. One founder spent the majority of his pitch time on vision and technical architecture. When a question about competitive positioning came up, the answer was more technical detail.

But the presentation is the symptom. The underlying problem is that the company hasn’t built a commercial function. There’s no one on the team whose job it is to translate the technology into buyer language. The founder is doing double duty as both technical expert and commercial voice, and one of those roles is always underprepared.

This shows up in a specific way for regulated products. The regulatory submission describes what the product does in regulatory language. The sales conversation needs to describe what the product does in buyer language. If nobody on the team has translated from one to the other, you end up in meetings where the founder presents regulatory claims and hopes the buyer will connect them to their own priorities. They won’t. That’s your job, and if nobody owns it, it doesn’t get done.

Fundraising impact: If your investor meetings consistently result in “interesting technology, need to see more commercial traction,” the problem might not be traction. It might be that a technical founder is presenting commercial plans without conviction, and investors are reading the gap between the words and the confidence behind them.

The test: Record your last pitch or customer meeting. Count the minutes on technology versus buyer impact, pricing, and competitive positioning. If technology is more than 40% and the audience is commercial, you don’t have a presentation problem. You have a team problem.

Gap 3: Focus Decisions That Haven’t Been Made

This shows up in two related ways.

On the market side: I saw multiple companies with active work across three or more entirely different application areas. Others listed numerous clinical indications they could serve. In every case, the evaluator response was the same concern: the company hasn’t committed to a beachhead.

The companies that impressed evaluators had one product, one application, and one value proposition they could articulate in a sentence. Evaluation took minutes.

Breadth of application is often technically true for platform technologies. But breadth is not a pitch. When a founder lists five potential markets, evaluators hear: “We’ve tried all five and none of them said yes with enough enthusiasm for us to commit.” That reading may not be fair. It’s the reading that gets made.

For regulated products, focus decisions carry additional weight. Choosing one market means choosing one set of indications, one regulatory submission, and one set of clinical claims. Trying to serve multiple markets often means either a broad submission with diluted claims that don’t resonate in any single market, or multiple submissions that drain resources across parallel timelines. The regulatory strategy and the market strategy have to point at the same target.

On the pitch side: The companies that scored highest spent less than 30 seconds on their long-term vision. The ones that scored lowest spent three to five minutes. After 30 seconds of vision, every additional second is a second not spent on traction, data, and evidence. And evaluators make their decisions on evidence, not aspiration.

Fundraising impact: Investors read “platform with multiple applications” as “the founder is hedging because no single market has validated.” Counterintuitively, a smaller addressable market with clear traction is more investable than a massive TAM with no evidence of pull.

Two tests for this one:

Market focus: If you had to keep only one of the markets on your slide, which one survives? If you can’t choose in ten seconds, you haven’t done enough customer discovery to know where the pull is.

Pitch focus: Time your next presentation. How many seconds before you say something a skeptic could verify? If it’s more than 60 seconds, you’re leading with aspiration instead of evidence.

Gap 4: Services Disguised as Product Revenue

Several companies presented as product or platform businesses but derived most of their revenue from custom service contracts or bespoke project work.

One company pitched a SaaS platform but acknowledged the vast majority of revenue came from services. Another had a product-based business model on paper but made most of its money running analyses for clients. A third described a “platform” but was doing custom work for each customer, project by project.

The logic makes sense. Product revenue takes time. Services revenue is available now. Customers will pay for your team’s expertise before they’ll commit to a subscription. And the services work generates case studies and domain knowledge that feed back into the product.

The problem is that services don’t scale like products do. Every services dollar requires roughly proportional human effort. You’re not building a flywheel. You’re building a consultancy.

One company handled this transition honestly. They were explicit about their current mix and laid out a specific plan: “We’re 80% services, 20% product today. By end of next year, we want to be 40/60. Here are the three product milestones that have to ship before we shift each 10% of revenue from services to product. And here’s what we learned from services clients that changed the product design.” That structure, current state, target state, milestones gating the transition, and learning feeding back into the product, was more credible than pretending services revenue was product revenue.

Fundraising impact: In healthtech transactions, services businesses have consistently traded at significantly lower multiples than product businesses. The gap is large enough to change your fundraising math. If most of your revenue is services and you’re pitching at product multiples, investors will catch the discrepancy during diligence. Better to be honest about the mix and show a credible transition plan.

The test: What percentage of your revenue requires a human from your team to deliver it? If it’s above 50%, you have a services business today. That’s not a death sentence, but it changes your growth trajectory, your hiring plan, and your valuation. The question isn’t whether to acknowledge this. The question is whether you have a plan to change the ratio, and whether that plan has milestones attached to it.

What Ties These Together

These four gaps are the predictable result of building a company from the technology outward rather than from the customer inward. The founders I evaluated are smart. Their technology works. But “technology works” is the starting line, not the finish line.

And every month those gaps stay open, the competitive landscape shifts. Someone else figures out the reimbursement. Someone else builds the commercial team. Someone else makes the focus decision you haven’t made yet. The technology doesn’t expire, but the window to define the category does.

Check yourself against all four. If you’re clean, you’re in better shape than most of what I saw this spring. If any of them landed, now you know where to look.

Three tools. One problem: your product is ready but the deal isn’t closing.

• Pressure Test — Find out where your pitch breaks, before the room does. Free to start.

• Healthcare Market-Fit Lab — Diagnose whether the market you chose can actually buy what you built. Two full-day sessions, June 6 and 13. Six seats.

• Sold. Build Your Pilot Conversion Playbook — Build the positioning, documents, and pilot structure that get contracts signed. Three weeks, starts June 1. Six seats.

All three are built on the same premise: stalled deals are structural problems. The pitch is usually the last thing that needs fixing.

Arvita Tripati is the Founder and CEO of Vahana Labs, a B2B strategy consulting firm helping healthtech and AI startups transition from pilot to enterprise contract. She has launched 30+ regulated AI-enabled products and worked with firms like the VA, Moderna, Gilead, NHS, and Bristol-Myers Squibb.

The guidance is called “Incorporating Voluntary Patient Preference Information over the Total Product Life Cycle.” It replaces a 2016 version that was narrowly scoped to PMA and HDE applications. The new version does something the old one didn’t: it extends patient preference data across the entire regulatory lifecycle, including 510(k)s, Breakthrough Device designations, IDEs, and enforcement decisions.

That last category is the one worth pausing on. But I’ll get there.

Two rooms, same pressure

While FDA was finalizing this guidance, something else was happening in the market.

GLP-1s are being prescribed and distributed through telehealth platforms, not clinics. Peptide therapies for recovery and performance are moving from niche to mainstream. Wellness brands, gyms, and chiropractors are white-labeling telemedicine infrastructure to offer medical-grade services under their own brand. Companies like Axentra Health are building the backend that lets a fitness brand run an injectable telehealth storefront without becoming a clinic.

Patients aren’t waiting for a formal survey to express their preferences. They’re expressing them with their wallets, their app downloads, and their subscription renewals.

That’s the demand side.

On the supply side, FDA-regulated device companies have historically treated patient preference as something that lives outside the regulatory conversation. You collect clinical endpoints. You run your pivotal trial. You submit your data. Patient experience might show up in a patient-reported outcome (PRO) instrument, but PROs measure how patients feel during treatment. They don’t measure what patients actually want when they’re weighing options.

Patient preference information (PPI) is different. FDA defines it as qualitative or quantitative assessments of how patients weigh tradeoffs between benefits and risks across different treatment options. Not how they felt after using your device. What they’d choose, and why, before they’ve used it. The two require separate instruments, answer separate questions, and carry separate regulatory weight.

The new guidance is FDA acknowledging that the gap between how patients make healthcare decisions and how the regulatory system evaluates devices was becoming hard to defend.

What actually changed

The 2016 guidance applied to three submission types: PMAs, HDEs, and de novo requests. If you were going through 510(k), PPI wasn’t part of your conversation with FDA.

The 2026 guidance applies across the full product lifecycle:

• IDEs

• Breakthrough Device designation requests

• PMAs, HDEs, and de novos (carried over)

• 510(k)s

• Administrative, enforcement, and other FDA actions

The 510(k) expansion matters for most early-stage device companies, because that’s the pathway a significant portion of SaMD and digital health products use. PPI is no longer reserved for the highest-risk regulatory conversations.

The enforcement expansion is the part that hasn’t gotten enough attention. If FDA can consider patient preference data in enforcement and compliance decisions, that has implications for post-market situations where a device faces regulatory questions but patients are clearly deriving benefit. It could affect how FDA weighs enforcement discretion, how it evaluates warning letter responses, or how it thinks about device availability during a compliance dispute. There’s no public precedent for PPI being used this way yet. This is new territory. But the fact that FDA wrote it into the guidance signals where they see this going.

Consider what happened with Whoop. In July 2025, FDA sent a warning letter over Whoop’s blood pressure feature, calling it an unapproved medical device. Whoop’s CEO publicly refused to pull it. They kept marketing throughout 2025. Then in January 2026, FDA updated its General Wellness guidance in a way that carved out space for exactly the kind of blood pressure data Whoop was providing, as long as companies don’t claim “medical-grade” accuracy.

Consumer demand won that fight. But it won through public defiance, CEO interviews on Bloomberg, and lobbying. That’s not a repeatable playbook for a Series A SaMD company. The new PPI guidance creates a formal channel for the same pressure. If you had structured evidence showing patients strongly prefer access to specific health insights and consider the tradeoffs acceptable, that’s data FDA can weigh when deciding how to enforce. It’s not a guarantee. But it’s a conversation you can now enter with evidence instead of press appearances.

The alfapump case: what PPI looks like when it works

This isn’t theoretical. Sequana Medical’s alfapump got PMA approval in December 2024 for treating recurrent or refractory liver ascites. The standard treatment is paracentesis: a large needle drains fluid from the abdomen. It’s invasive, burdensome, and patients need it repeatedly.

Sequana ran a discrete-choice experiment with RTI Health Solutions. They surveyed 125 US patients with a comparable profile to their pivotal study population, asking them to weigh the risks they’d accept against the benefits of an implantable alternative. The study design was pre-discussed with FDA.

The results showed patients were willing to tolerate risks beyond what was observed in the clinical data to reduce their need for paracentesis. That preference data, combined with clinical evidence from the POSEIDON pivotal study, supported the approval.

Two things to note about this example. First, Sequana engaged FDA early on the study design. They didn’t run a preference study and hope FDA would accept it. They got FDA’s input on methodology through the pre-submission process before fielding the survey. Second, the PPI worked because it sat alongside strong clinical evidence. The pivotal trial data showed the device worked. The PPI data showed patients considered the benefit-risk tradeoff acceptable.

That’s the pattern FDA wants to see. But it has limits. The guidance also includes a hypothetical where PPI shows patients would accept higher risk, but FDA declines to approve because the risk could be addressed through design improvements. Patient preference data is one input in the totality of evidence. It supports clinical data. It doesn’t substitute for it.

Where this matters most: subjective endpoints and the AI device problem

The 2026 guidance adds a new device characteristic to the list of strong PPI candidates: “devices where key endpoint experiences are subjective.”

That sentence matters more than it looks like for anyone building AI-enabled clinical tools.

Think about a device that monitors a chronic condition where the primary benefit includes reduced symptom burden or fewer unplanned clinical visits. The endpoint is partly about how patients experience the monitoring. A SaMD targeting pain management, medication adherence, or functional status between appointments is measuring patient-experienced outcomes. Digital therapeutics aimed at behavioral or mental health outcomes are almost entirely patient-reported.

For these products, PPI isn’t a nice-to-have. It may be the strongest evidence you can bring to the benefit-risk conversation, because the benefit itself is defined by what patients value.

These are different regulatory universes from GLP-1 telehealth storefronts, obviously. But the patient expectation carries over. People who are accustomed to choosing their care based on convenience, brand experience, and personal values don’t suddenly stop having preferences when they encounter a regulated device. The question for device companies is whether you’re capturing those preferences in a form that FDA can actually weigh.

The preference gap

Consumer health companies have detailed data on what patients prefer because they see purchasing behavior in real time. Subscription renewals, feature usage, NPS scores, churn patterns. They know which attributes drive adoption.

FDA-regulated device companies often don’t have that data in a form the agency can use. They may have it buried in customer interviews, in sales call notes, in support tickets. But structured, rigorous preference data that meets FDA’s 12 quality criteria? Most early-stage companies haven’t invested there.

The 2026 guidance outlines what “rigorous” means. Some of the requirements are obvious: the study should be patient-centered, the sample should be representative, the analysis should hold up to scrutiny. Others are traps for companies that try to run a quick survey and call it PPI.

A few that trip people up:

Cost can’t be an attribute. If your preference study asks patients to weigh device features against price, FDA may discount the results. Attributes need to be clinically relevant and not confounded by financial considerations.

Heterogeneity matters. FDA wants to see that you’ve captured the range of patient preferences, not just the average. A study showing that “most patients prefer X” is less useful than one showing that a definable subgroup with specific clinical characteristics strongly prefers X. That subgroup data can support a narrower but successful approval.

Cognitive bias is a disqualifier. If your survey frames risks as gains vs. losses and that framing influenced responses, the study has a validity problem. FDA cites a classic example: more patients chose surgery when told it had a 90% survival rate than when told it had a 10% mortality rate. Same data, different frame, different result. Your study design has to account for this.

PPI as competitive moat

Most founders will read this guidance as a regulatory update. It’s also a product strategy document.

If you design a PPI study that meets FDA’s quality criteria, you don’t just get a regulatory asset. You get product intelligence. You know which attributes your target patients value most, how they weigh tradeoffs, and where the preference distribution breaks across subgroups.

That data feeds your product roadmap, your positioning strategy, and your enterprise sales narrative. You can tell a health system exactly which patient segments will adopt and why.

The companies that build this data early, while competitors treat PPI as a PMA-only exercise or skip it entirely, will have a compounding advantage. They’ll have structured evidence of patient demand that works in a submission, in a sales deck, and in a board presentation.

What to do about this

If you’re a SaMD or digital health CEO reading this guidance, a few concrete moves:

Check whether your device is “preference-sensitive.” FDA flags three conditions: multiple treatment options exist without a clearly superior choice, evidence supporting one option is uncertain or variable, and patients’ views on benefits and risks vary or differ from clinicians’ views. Most AI-enabled health products meet at least two of these.

Talk to FDA early about study design. The guidance recommends getting FDA’s input via Q-Sub on research questions, patient sample, proposed attributes, and survey instruments before you finalize anything. This is iterative, not a single checkpoint. FDA wants to be involved in the design phase, not surprised by results.

Budget for it honestly, and start early. A rigorous stated-preference study isn’t a SurveyMonkey exercise. The alfapump study enrolled 125 patients and was run by RTI Health Solutions, a CRO with deep experience in discrete-choice methodology. The study was designed alongside the clinical program, not bolted on after the pivotal trial. A well-scoped PPI study with 150-300 respondents, proper instrument design, cognitive pre-testing, and statistical analysis typically runs in the low-to-mid six figures and takes 6-9 months from design to final report. That’s real money for a Series A company. But if you’re already spending $2M+ on a pivotal trial, the incremental investment in preference data that could differentiate your submission (and double as market intelligence) is worth sizing.

Keep an eye on ICH E22. There’s a parallel draft guidance from ICH on patient preference studies for drugs, with comments due April 7, 2026. If you’re building a combination product or working at the device-drug boundary, both guidances are relevant.

Where this is heading

The consumerization of healthcare and the formalization of patient preference in regulation aren’t the same thing. They operate in different regulatory contexts with different risk profiles. But they share a root cause: patients have more agency over their care decisions than the system was originally designed for, and the system is adapting.

The unregulated side of healthcare (telehealth platforms, DTC brands, white-label wellness infrastructure) responded to this first. They built around patient choice as a core design principle.

The regulated side is now being given a formal mechanism to account for patient choice in its decision-making. Voluntarily, for now. But the direction is clear.

The device companies that recognize PPI as a strategic asset, not a regulatory footnote, will be better positioned for submissions, for sales conversations, and for the version of healthcare delivery that’s already taking shape around them.

This is strategic analysis, not legal or regulatory advice. Talk to your regulatory counsel before making submission or study design decisions.

Sidebar is a peer community for senior leaders. The room was intentionally small. These weren’t conference attendees half-listening between sessions. They opted in, showed up, and answered honestly. Which is what made the results interesting.

The aggregate scores were high. Nobody scored themselves below Integrated on Architecture. Most said they optimize for Adoption Velocity. 80% rated their Perception as Differentiating.

Then we asked the open-ended questions. And the answers didn’t match.

Discovery: what people said vs. what people described

Half rated their Discovery as Strategic or Proactive, meaning they anticipate trust requirements before they build and research them during discovery.

Then we asked: “In 1-2 words, how did you last discover a trust requirement you were missing?”

The answers: lost customer. Deal stall. Sales. Compliance audit. Internal audit. User feedback from early adopters.

These are all reactive discovery mechanisms. Every single one describes learning about a trust gap after it already cost something. A lost customer is not proactive discovery. A deal stall is not strategic. These are fire alarms, not smoke detectors. From people who had just scored themselves at the top of the scale.

The people in the room had the right vocabulary. They knew what good discovery looks like. But when asked to describe the last time it actually happened, they described something different.

This matters if you’re trying to convert a pilot into a contract. You think you’ve mapped the buyer’s trust requirements during the pilot. But you mapped them from your champion’s perspective, not from procurement’s, not from IT security’s, not from the CISO’s. The first time you hear about the gap is when the deal stalls. And by then you’re retrofitting in the middle of a sales cycle.

The buyer vs. user question that changed the room

Partway through the session, our moderator Kim Martin asked something that reframed the rest of the conversation. She pointed out that in B2B, the buyer and the user are often different people. So when you score yourself on trust maturity, whose trust are you scoring?

It’s a question that sounds obvious and almost never gets asked explicitly.

Your clinical champion trusts the product because they’ve used it and seen the results. They’ll go to bat for you internally. But the person filling out the vendor assessment form has never logged in. They’re evaluating your documentation, your certifications, your audit trail, your data architecture. They’re forming a trust judgment based on completely different inputs.

Most teams, when they self-assess on trust, are scoring from the champion’s perspective. The champion says good things about us. Our NPS is high. Users like the product. That’s real, but it’s one half of the trust equation. The other half is the evaluator who needs to verify your trust posture without your help, and who may never use the product at all.

Kim’s question explained something about the scoring gap we were seeing. People scoring Differentiating on Perception were probably right that their users trust them. The miss was that users aren’t the only ones grading.

Architecture: high scores, scattered infrastructure

Everyone who answered the Architecture question said Integrated or Platform. Nobody said Workaround or Bolted-On.

Then we asked: “Where does your trust infrastructure live right now?”

The answers: spread out. Feature. Sales, CS, and platform. Platform and roadmap.

“Spread out” is not Integrated. “Feature” is not Platform. “Sales, CS, and platform” means three different teams touching trust in three different ways with no shared system.

This is a familiar pattern from diligence work. The company has trust capabilities. They exist. But they’re scattered across teams, tools, and release cycles. When a buyer asks for an audit trail, someone can produce one, but it takes three people, two Slack threads, and a spreadsheet export. That’s Bolted-On with extra steps.

I worked with a B2B SaaS company where the data architecture had been built for speed to market, not scalability. Functional for early adopters. But it lacked the governance, auditability, and extensibility that larger enterprise buyers require. When we got into sales cycles with top-five pharma, the deals stalled because IT and procurement kept flagging technical gaps. The fix was a half-million dollar re-architecture. That’s the cost of trust debt when it compounds in the architecture layer. And it’s the kind of cost that doesn’t show up on a self-assessment where everyone clicks “Integrated.”

This also shows up in smaller ways during pilots. The pilot is going well with your clinical champion but procurement sends a 200-question security questionnaire. Your team scrambles. The answers come from four different people. Some contradict each other because they’re describing different parts of the system. The questionnaire takes three weeks instead of three days. The deal loses momentum.

Velocity: saying adoption, cutting usability

Most who answered the Velocity question said Adoption Velocity, meaning they optimize for time-to-trust.

Then we asked: “What gets cut when the sprint is full?”

The answers: fluff. Non-user value. Usability design. Me-too features. Low-priority features.

Usability design gets cut when the sprint is full. By a team that says it optimizes for adoption velocity.

If you’re optimizing for how fast someone goes from trying to relying, usability is load-bearing. It determines whether the user even gets to the point where they can evaluate trust. Cutting it means you’re actually optimizing for feature count and calling it adoption.

This pattern predicts a specific failure mode in pilots. The product works. The features are there. But the workflow is clunky, the user can’t find the value, and week-two usage drops. The champion defends the product internally but can’t explain why adoption is low. The pilot stalls. Nobody connects it to the usability work that got cut in sprint 4.

Perception: Differentiating on paper, relationship-dependent in practice

80% who answered the Perception question said Differentiating.

Then we asked: “What proof of trustworthiness can someone find about your product without asking you?”

The answers: case studies. Low incidents historically. Warm referrals. How you’re managing data. Validation metrics. Customer refs.

Most of these require your involvement. Warm referrals require someone to call your existing customer. Customer refs require you to provide the reference. These are gated. They depend on you being in the loop.

Differentiating perception means a buyer can verify your trust posture independently. Public documentation. Searchable certifications. A trust center on your website. G2 reviews that mention security specifically. Things that exist whether or not you’re in the room.

Kimberly shared a story that landed this point. She worked with a company that had the explainability behind their a specific score buried three clicks deep in the product. The feature existed. The architecture supported it. But users couldn’t find the reasoning behind a score without digging. Her team hadn’t noticed because they knew where to look.

I saw a version of this with an AI-powered monitoring device I worked on. Independent physicians loved the product. They controlled the patient interaction, managed the data flow, and had enough clinical context to verify the output. Trust was high. But when we brought the same product, same FDA clearance, to academic clinicians, the reception was the opposite. They were worried about patients flooding their practices with data they hadn’t asked for, creating liability exposure they couldn’t quantify. Same product. Same evidence package. Completely different trust perception, split by practice type. Each evaluator was grading trustworthiness from a different set of concerns, and our perception score depended entirely on which one you asked.

That’s the problem with scoring Differentiating on a self-assessment. You’re probably right about some of your evaluators. You’re probably wrong about others.

Operating Altitude: who decides when nobody’s watching

By this point in the session, participation had dropped by half. Of those still answering, most said Systematic or Process-Driven.

Then we asked who makes trust decisions when leadership is out. The answers: Product. Engineers. Depends on sales, CS, product.

“Depends” is not Systematic. If the answer changes based on which team encounters the question first, you don’t have a system. You have whoever picks up the phone.

The drop-off itself is data. People engaged with questions that felt comfortable and pulled back when it got specific. “How do you learn about trust requirements?” is easy to discuss. “Who decides when you’re not there?” requires admitting you might not know.

The frontier model question

Near the end of the session, a participant raised something that’s been coming up in every enterprise deal I hear about: frontier model trust erosion. Companies that were comfortable sending data to predictive ML models are rewriting contracts over LLM integration.

Kimberly confirmed she’s seen it, particularly with Fortune 500 buyers. The infrastructure didn’t change. The perceived risk surface did. If your product uses frontier models and your trust documentation still describes your system as though it runs on internal models, that gap is about to show up in your next enterprise security review.

What to do with this

Run this diagnostic with your team. Have each person score independently, then compare. The disagreements are where your trust debt lives. Your head of sales and your head of product will almost certainly score Perception differently. That difference tells you something about how your trust posture looks from the inside vs. how buyers experience it.

Then ask Kim Martin’s question: whose trust are you scoring? The user’s or the evaluator’s? If you’re only scoring one, you’re missing half the picture.

And ask the follow-up questions out loud. Not “how do you rate our discovery?” but “when was the last time we found out about a trust requirement we’d missed, and how did we find out?” The story will tell you whether your score is earned or aspirational.

Thanks to Sidebar for hosting this session and to Kim Martin for the question that connected everything. Kimberly Bloomston and I are co-authoring a book on trust debt, coming out this fall, that goes deeper on all five dimensions with templates for running this diagnostic internally and playbooks for addressing each gap. More soon.

That’s not speculation. The data is already in:

• 64% of healthcare organizations are experimenting with or deploying agentic AI today, but only 3% have agents in live production workflows. The gap between those numbers is closing fast.

• Only 30% maintain an enterprise-wide AI inventory.

• Over half have no documented method for detecting when vendors embed AI into existing products. That’s the number that should concern you most.

• 85% plan to increase agentic AI investment over the next two to three years.

• Every payer respondent in Gartner’s 2026 survey has either implemented or plans to deploy agentic AI by 2028.

The gap between deployment velocity and governance readiness is the defining risk of the next four quarters. Not the technology. Not the regulation. The gap.

This piece lays out what needs to be built, in what order, and by when, to close that gap before the first wave of agent-related incidents forces organizations to close it under pressure.

Share

Why This Moment Is the Window

Healthcare organizations are in the middle of one of the largest data infrastructure investments the industry has seen. Healthcare IT spending is at an all-time high and growing in the mid-teens annually. Health systems are migrating EHRs to cloud platforms, consolidating fragmented data stores, standing up FHIR-based interoperability layers, and building the data foundations required for AI workloads. TEFCA exchange volume went from roughly 10 million records in January 2025 to nearly 500 million by February 2026. Cloud-based EHR deployments dominated new implementations in 2025. Major systems like Intermountain are in the middle of enterprise-wide EHR consolidations. The data environment is being rebuilt right now, across the industry, in this budget cycle.

The question is whether anyone thought to scope it for agents too.

Agents don’t just read data. They act on it. They retrieve records, modify system state, submit documents, route tasks, and in some configurations decide what to do next without human approval at each step. That means the data infrastructure they operate on needs minimum-necessary access scoping, role-based permissions that can be assigned to agents (not just human users), action-level audit trails, and retention policies that account for agent memory and persistent context.

If the data infrastructure being built today doesn’t account for those requirements, the industry will be retrofitting again before the current investment has paid off. Organizations that scope their current cleanup for agentic access patterns will have a foundation that supports both gen AI and autonomous agents. Organizations that optimize only for the current use case will face a second remediation cycle within 18 months.

The Pattern We’ve Seen Twice Before

Healthcare has been through this before. Cloud was first: teams adopted it because it was faster, assumed the provider had “taken care of security,” and then spent a decade building shared responsibility models and audit frameworks after incidents proved otherwise. Device quality systems were second: companies scaled on heroics until regulatory enforcement taught them that repeatable systems beat talented individuals at scale.

Both followed the same cycle: productivity gain, mistaken belief that convenience changed accountability, incidents, new control abstractions, and finally governance as an operating requirement.

Agentic AI is the third iteration. Cloud mostly changed where computation happened. Quality systems mostly changed how organizations proved control. Agent platforms change who gets to act. Agentic AI is what happens when the cloud-era control problem and the cGMP-era evidence problem collide inside a system that can take action on your behalf.

The prediction: organizations that build governance infrastructure in the next 12-18 months will be ready when the first wave of agent-related incidents hits. The organizations that wait will be building under pressure, with higher cost and less room for error.

What the Failure Modes Look Like: OpenClaw

OpenClaw is an open-source autonomous AI agent that went viral in late January 2026, accumulating 247,000 GitHub stars in six weeks. It was designed as a personal assistant with a single trusted operator, never for enterprise environments, but its architecture exposed the failure modes that healthcare will face if agents are deployed without governance.

Persistent memory turned exploits into time bombs. Palo Alto Networks identified that persistent memory allows malicious payloads to be fragmented, stored as benign-looking fragments, and assembled into executable instructions when the agent’s context aligns. For healthcare: an agent that ingests PHI into persistent memory creates both a HIPAA liability and a security exposure that grows over time.

The supply chain was compromised at scale. Snyk’s audit of 3,984 skills from OpenClaw’s registries found that 36% contained detectable prompt injection; 91% of confirmed malicious payloads combined prompt injection with traditional malware. For healthcare: any agentic system that accepts third-party plugins or integrations needs vetting with the rigor of a medical device supply chain, not an app store.

Structural exposure was baked in. Microsoft’s security team stated that OpenClaw should be treated as untrusted code execution with persistent credentials. Researchers demonstrated that valid credentials could be exfiltrated and used to take actions that appeared fully authorized, because the tokens were real even when the person behind them wasn’t. For healthcare: the enterprise agent platforms being sold at HIMSS26 this week need to demonstrate they’ve solved these structural problems, not just wrapped them in a compliance addendum. And credential-based security alone won’t catch a compromised agent acting with valid tokens.

People assume the intelligence layer is the hard part. The actual problems are permissions, execution paths, trust boundaries, and runtime governance.

What the Regulatory Landscape Requires

Two regulatory developments in January 2026 matter for the 18-month timeline. On the medicines side, FDA and EMA jointly published ten Guiding Principles of Good AI Practice in Drug Development covering the full lifecycle. On the device side, FDA’s PCCP framework for AI-enabled device software provides the most useful governance template, with planned modifications, validation methods, and impact assessment specified in advance. The CDS guidance draws the dividing line: the more an agent influences clinical action, the more governance needs to resemble device discipline.

The routing logic for which framework applies: if your agent operates in a clinical trial, pharmacovigilance, or manufacturing context, the drug-development principles apply. If it operates as software that influences clinical decisions for individual patients, the device framework applies. If it does neither, you’re in ordinary enterprise governance territory, which still requires the five structures below.

Both frameworks converge on the same practical requirements: classify use cases by risk, document context of use, monitor continuously, and control changes before they go live.

The Build Sequence: What to Do and When

The governance architecture has five components. They have a sequence, and the sequence matters because each layer depends on the one before it. These timelines assume executive sponsorship and dedicated resourcing. Without both, add two quarters to each phase.

What does it cost to show up without this infrastructure? Two examples from my own career.

Early in my career, I was at a startup company building software for a highly regulated pharmaceutical workflow. We had a warm introduction to a top-five pharma company. Our readiness was oversold. They started asking security questions we couldn’t answer: certifications, audit history, data sovereignty, business continuity. We had gaps. They told us they’d reopen competitive bidding in five years. We weren’t rejected. We were shelved. The people who evaluated us remembered. The company went under before that procurement cycle reopened. That’s what happens without trust-boundary architecture: phase two in the sequence below.

At another company, a clinical technology vendor I worked with thought they were ready for a hospital deployment. The hospital ran their own vulnerability scan, found issues the vendor hadn’t anticipated, and blocked deployment. Ten months of delay. Ten months of burn. That’s what happens without verification and change control: phase three below.

Both were traditional software deployments. Autonomous agents have broader system access, process more sensitive data, and take actions without human approval at each step. The blast radius is larger.

Phase 1: Q2-Q3 2026 -- The Foundation

Build the agent inventory. You can’t govern what you can’t see. Start by cataloging every AI system in your environment, including capabilities vendors have embedded into existing products without a separate procurement event. This is the part most organizations are skipping, and it’s the part that matters most given that over half of healthcare organizations have no method for detecting vendor-embedded AI. The inventory isn’t just a list of agents you chose to deploy. It’s a list of every agentic capability operating in your environment, whether you procured it or it arrived in a software update. Extend to any agentic pilots, experiments, or shadow deployments.

The thing that will try to stop you: nobody owns this across the organization. The data is scattered across vendor contracts, IT tickets, departmental pilots, and product release notes nobody read. Assign a single owner with authority to request information from every department and every vendor.

Build the classification system. Every agent needs a risk tier: informational, workflow-support, decision-support, or autonomous execution. This applies to agents you deployed and to agentic capabilities your vendors added. An agent assembling prior-auth documentation for human review lives in a different tier than one submitting packages to payors. But what about the agentic feature your RCM vendor shipped in a quarterly update that now autonomously routes denial appeals? That needs a tier too, and someone needs to know it exists before it can be classified.

The thing that will try to stop you: disagreement between clinical, IT, and compliance on what counts as “decision-support” vs. “informational.” Resolve it with a decision matrix, not a meeting series. Define the criteria once, apply them consistently, and adjudicate edge cases quarterly.

Scope the data infrastructure for agentic access. If your organization is in a data modernization, this is the moment to extend scope. Build in minimum-necessary access scoping, role-based data permissions assignable to agents (not just human users), action-level audit trails, and retention policies that account for agent memory. Concretely: add an agent-identity type to your RBAC schema so agents can be granted and revoked permissions the same way human users are. Add action-level audit events to your logging specification so you can trace what an agent did, to what data, at what time, and under whose authorization.

The thing that will try to stop you: the data modernization project was scoped and budgeted before anyone asked about agentic access patterns, and reopening scope requires re-approval. Make the case now, while the project is in flight, because the cost of adding scope mid-project is a fraction of the cost of a second remediation cycle.

Phase 2: Q4 2026 -- The Trust Architecture

Implement hard trust boundaries. Policy language is not a trust boundary. A trust boundary is a technical enforcement point with separate credentials, separate access controls, and separate blast radius. For agents: role-based agents rather than one super-agent, environment segmentation between PHI and non-regulated workflows, workspace scoping, and separate gateways per trust domain.

athenahealth’s MCP server at HIMSS26 is an early example: the agent can only see what the protocol layer exposes, and the patient controls enablement. Imprivata’s Agentic Identity Management governs agent identities with the same rigor as human identities. Singulr AI’s Agent Pulse provides runtime governance. No single product covers all three layers (protocol-level data scoping, identity management for agents, runtime governance), which means organizations have to integrate across products. Start by mapping which layer each of your current and planned vendors covers, and identify the gaps.

Solve the identity impersonation problem. Consider the scenario: an agent with valid credentials has been compromised through prompt injection. It submits prior auth requests, modifies patient records, and routes clinical tasks for hours before anyone notices, because every action passes the credential check. The tokens are real. The person behind them isn’t.

Traditional authentication verifies who logged in. It doesn’t verify who is acting right now. Agents don’t log out. They run continuously, hold persistent credentials, and act across sessions. The governance model needs to move from credential-based verification to continuous person-based verification: not “who logged in?” but “is this action still authorized by the person it claims to represent?”

At minimum, build re-authorization triggers for high-risk actions. When an agent’s behavior deviates from its documented scope, when it accesses data outside its normal pattern, or when it takes an action like modifying a patient record or submitting a regulatory filing, the agent should pause and require explicit human re-authorization, verified through a factor beyond the agent’s own credentials. This is an emerging capability, not a solved problem, but it belongs on the trust-architecture roadmap because credential-based controls are structurally insufficient for always-on autonomous systems.

Extend data governance to cover agent memory and PHI. If an agent ingests PHI into persistent memory, that memory becomes a data store subject to HIPAA requirements. Establish policies: what data agents can retain in context, for how long, under what conditions, and who authorizes it. Review your BAAs with agent vendors to confirm that persistent memory is explicitly covered as a data store; most current BAA language was written for traditional SaaS and may not address it. Several states now have AI-specific disclosure requirements when AI influences coverage or care decisions. If an agent processes prior auth, some states may require patient notification.

The thing that will try to stop you: legal and compliance haven’t been asked to draft agent-specific data policies yet, and the question of whether agent memory constitutes a “designated record set” under HIPAA doesn’t have settled case law. Don’t wait for the case law. Draft the policy based on the most conservative reasonable interpretation, and revise as guidance matures.

Phase 3: Q1-Q2 2027 -- Lifecycle Governance

Stand up verification, monitoring, and change control. Agents need pre-deployment validation, fit-for-use metrics, drift detection, incident thresholds, controlled updates, and the authority to shut things down fast. They also need rollback procedures and degraded-mode operations plans. If an agent is processing claims and you shut it down, thousands of claims can be stuck mid-process. The shutdown plan needs to account for that: what happens to in-flight work, who gets notified, what manual process takes over, and how quickly. The PCCP framework provides the template: what changes are planned, how will they be validated, how will they be implemented, and how will impact be assessed?

The thing that will try to stop you: no existing monitoring tooling is designed for agentic behavior drift. Most organizations will adapt application performance monitoring tools that weren’t built for this purpose. Accept that the first version will be imperfect and instrument for the basics: action logging, output sampling, escalation triggers.

Establish the standing multidisciplinary review body. An AI governance council that approves use-case tiers, reviews incidents, owns escalation paths, can shut down agents quickly, and maintains the inventory. This body needs product, security, privacy, compliance, regulatory, data, and clinical representation. By mid-2027, it should be operational, not aspirational.

The thing that will try to stop you: getting eight disciplines in one room regularly enough to make decisions. Don’t wait for the full body. Start with a core team of three (security, compliance, one clinical lead) that meets biweekly, with authority to make provisional decisions. Expand the membership as the agent inventory grows and the governance load justifies it.

Why the sequence won’t be clean

A compliance team will be carefully building the inventory while someone in revenue cycle management has already deployed an autonomous appeals agent without telling the governance committee it exists. That’s the pattern the Censinet data describes: 64% deploying, 30% with inventory.

This is the shadow-adoption pattern from cloud all over again. Cloud spread team by team because it was faster than waiting for central IT. Agents spread person by person for the same reason. The governance challenge isn’t just building the right infrastructure. It’s preventing people from skipping it.

What This Means for Three Audiences Over the Next 18 Months

For healthtech startups selling agentic products

Within 12 months, health system procurement teams will add agent-specific questions to their vendor risk assessments. Here’s what’s coming, grouped by what they’re evaluating:

Your agent’s own governance:

• How does your agent scope data access? What’s the minimum data it needs, and how is that enforced?

• What happens when the underlying model updates? How are changes validated before they reach production?

• Who can shut the agent down, and how fast? What happens to in-flight workflows when it stops?

• How is agent memory governed? What patient data can it retain, for how long, and who authorized it?

• What third-party plugins, skills, or integrations does the agent use, and how are they vetted?

Your vendor and subprocessor practices:

• What subprocessors touch the data? How is the customer notified when you add agentic capabilities to an existing product?

• Does your BAA explicitly cover data retained in agent memory as a data store?

Identity and impersonation:

• How does your system verify that an agent is still acting under authorized human control, not operating on compromised credentials or poisoned context?

The vendors who can answer these questions with architecture, not documentation, will close. The rest will stall in procurement.

I’ve seen the difference this makes. At one company early in my career, the founding team hired a regulatory and compliance professional as their first non-technical hire. Not a second engineer. Not a salesperson. That hire slowed feature velocity. It also meant they could answer enterprise buyers’ security, validation, and audit questions that competitors were still figuring out. They closed deals faster because governance wasn’t a retrofit.

For health systems

Four actions for the coming quarter:

• Build the inventory. Catalog every AI and agentic capability in your environment, including what vendors embedded in product updates without a separate procurement event. Assign a single owner.

• Add agent-identity types to your RBAC schema so agents can be granted and revoked permissions independently of the human users who deployed them. If your data modernization is in flight, bring this to the next steering committee meeting before the scope window closes.

• Add action-level audit events to your logging spec so you can trace agent actions to specific data, timestamps, and authorizations.

• Map every agent in production to its rollback procedure. If an agent goes down, what manual process takes over? Who gets notified? How long does the workaround take? If you can’t answer those questions for a given agent, that agent shouldn’t be in production yet.

For the identity question your CISO should be asking: credential-based authentication is not sufficient for always-on autonomous systems. An agent with valid tokens that has been compromised through prompt injection or memory poisoning will pass every credential check while taking unauthorized actions. Ask your agent vendors how their system detects when an agent is acting outside its authorized scope. Build re-authorization triggers for high-risk actions: patient record modifications, regulatory submissions, PHI access outside normal patterns. If the vendor can’t explain how impersonation is detected in real time, that’s a gap in the trust architecture.

Health systems that went through cloud governance maturation have an advantage. The mental model transfers: shared responsibility, identity-based access, continuous posture management, configuration as code. The organizations that skipped that work during cloud adoption will find the agent governance problem harder, because they’re building two layers of infrastructure at once.

For PE/VC firms

Agent governance maturity is becoming a diligence criterion for healthtech investments, the same way cloud security maturity became a diligence criterion for SaaS investments in the 2010s. The questions for the next 18 months:

• Does the company have an agent inventory?

• Is there a documented classification system for AI use cases?

• Are trust boundaries technical or just policy?

• Who can shut an agent down, and how fast?

• How are model updates, new skills, and scope changes controlled?

• How is the data infrastructure scoped: for gen AI only, or for agentic access patterns?

The cost of getting this wrong is quantifiable. In my experience, governance gaps add 3-6 months to enterprise sales cycles. One company I evaluated lost two enterprise contracts worth a combined $1.4M in the same quarter because they couldn’t pass the health system’s security review. That represented roughly 25% of their projected annual revenue. Post-close, remediating governance infrastructure, building the inventory, implementing trust boundaries, standing up change control, typically takes 6-12 months and pulls engineering resources from product work. Factor that into the valuation, not just the integration plan.

Companies that treat governance as a bolt-on are accumulating trust debt. Within 18 months, expect agent governance maturity to be a standard part of healthtech technical diligence.

The Recurring Lesson

Cloud taught us that moving the workload changes the boundary. Quality systems taught us that scaling risk requires systems, not heroics. Agent platforms are teaching the third version of the same lesson: delegating action changes accountability.

The most interesting outcome of the agentic AI wave in healthcare is not “a bot that practices medicine.” It is a network of tightly scoped agents that make regulated organizations faster without making accountability fuzzy. The governance structure has to preserve three things at once: clear context of use, clear human accountability, and clear technical boundaries.

The window to build that structure is open now. The budgets are allocated, the data environments are under renovation, and the regulatory vocabulary exists. Within 18 months, the organizations that used this window will be the ones that can deploy agents with confidence. The rest will be building governance after the incident that made it unavoidable.

The first step is the inventory. Start there. This quarter.

Arvita Tripati is the Founder and Managing Director of Vahana Labs, a B2B strategy consulting firm helping healthtech and AI startups transition from pilot to enterprise contract. She has launched 30+ regulated AI-enabled products and worked with firms like the VA, Moderna, Gilead, NHS, and Bristol-Myers Squibb.

This is the pattern nobody talks about at pitch meetings: The trust erosion in consumer healthtech isn’t primarily a marketing problem. It’s a regulatory design constraint that gets baked into your product from day one. And if you don’t recognize it, you’ll either cripple your product with overly conservative positioning, or you’ll build something that looks great until regulatory scrutiny arrives.

The stakes are real. A third of consumers now find digital health tools unhelpful, full stop. But here’s the counter-signal: consumers using AI-powered health tools report significantly higher satisfaction than non-users. That 46% increase in appointment scheduling when relevant health content is present? That’s not a content marketing win. That’s the signal that clear, honest positioning drives actual behavior change more than feature engineering does.

The companies winning this game aren’t hiding their limitations. They’re building their positioning around them.

The Boundary Problem: Why Vague Positioning Kills Trust

Pull up Abba AI’s terms of service. It will tell you exactly what it’s not: not a therapist, not a medical device, not designed to diagnose or treat anything. This clarity isn’t cautious. It’s aggressive. Victor Carrion’s team at Abba recognized something most consumer healthtech founders miss: consumers don’t get confused by boundaries. They get confused by ambiguity.

Compare this to the mental health AI space, where a researcher like Burns can report a 96% reliability rate on clinical scales and 60-70% symptom improvement in 70 minutes, yet consumers don’t believe the results. Why? Because the marketing, the positioning, the entire framing sends mixed signals. The product claims rigor. The language hedges. The consumer is left guessing whether this is a proven intervention or a wellness toy.

The regulatory framework is partly to blame. FDA regulations, FTC guidelines around health claims, the murky wellness-versus-medical-device line. These constraints exist. But here’s what separates the winners: they don’t treat regulatory constraints as obstacles to hide. They treat them as features of the product story.

Carrion put it perfectly: “Abundantly factual in all communications.” Not abundantly modest. Not abundantly cautious. Abundantly factual. Say what you know. Say what you don’t. Stop hedging.

The Missing Product Design Decision: Classification Strategy

Most consumer healthtech founders make the regulatory classification decision after the product exists. That’s backwards.

Chris Palmer from Novos laid out the classic framework: Path 1 is pharma (10-100+ million dollars, clinical trials, FDA approval). Path 2 is supplement or DSHEA (limited claims, lower regulatory burden). Most consumer healthtech teams assume they’re choosing Path 1 or Path 2. In reality, most of you are stuck in a gap.

That gap is where trust dies. You have evidence. It’s not pharma-grade. You have claims. They’re not supplement-class. So you end up marketing something that feels medicinal without being regulated like medicine. That’s the exact zone where consumers distrust AI healthcare most.

Carolina from OneSkin lives this every day. Her team has done rigorous studies showing that their product reduces DNA damage and inflammation. Those are real outcomes. But the company is classified as a cosmetic manufacturer. Cosmetics can’t make structure-function claims. So OneSkin has the evidence, but can’t market any of it. The result? Regulatory classification constrains the product narrative to the point where actual efficacy becomes invisible.

This is the design decision you need to make before you build feature list number two: What category are you claiming to operate in, and what does that mean for your evidence requirements?

If you’re claiming mental health benefits, you’re inviting FDA scrutiny whether you want it or not. If you’re claiming disease prevention, same story. If you’re claiming “wellness support,” you get more freedom, but you also get different regulatory constraints around claims. If you’re claiming “information,” you’re in a totally different lane.

The companies winning right now aren’t the ones with the most evidence. They’re the ones who picked a regulatory category that matches their evidence and built their entire go-to-market around the boundaries of that category.

The Evidence Gap: What Do You Do When the Data Isn’t There?

Joanna from Midi Health asked the question that most founders avoid: “Evidence-informed versus evidence-based. What’s the difference when the evidence literally doesn’t exist?”

Women weren’t included in clinical trials until 1992. Hormonal health, reproductive health, menopause interventions. These are areas where the “gold standard” clinical evidence is built on male or non-representative populations. Midi Health built products designed to help women. But the regulatory standard assumes you’re comparing against research that excluded women.

This isn’t a niche problem. Most consumer healthtech is addressing outcomes where the evidence base is either missing or biased. Triage algorithms are trained on unrepresentative datasets. Patient engagement tools are trying to shift behavior in ways that haven’t been fully studied. Wearables are claiming to predict things we don’t have randomized controlled trials for.

Your choice isn’t “get perfect evidence before launching” (you’ll never launch) or “ignore evidence requirements” (you’ll hit regulatory walls). Your choice is: How do you position evidence-informed decisions honestly?

Midi’s approach: Be explicit about what you know and what you don’t. Don’t pretend that the gap doesn’t exist. Use that gap as part of your positioning story. “Women weren’t in these trials. We’re building based on mechanistic understanding and early-stage evidence. Here’s what that means for what we can and can’t claim.”

This is the inverse of Carrion’s approach, but it’s the same move: boundary clarity becomes trust-building.

The FTC has relatively clear guidelines on this: health claims can be “well-substantiated” without being pharmaceutical-level evidence. You can make a claim supported by competent and reliable scientific evidence. That evidence doesn’t have to be a Phase III RCT. But you have to be clear about what you have and what you’re claiming. The problem most founders have isn’t that their evidence is weak. It’s that they’re not being specific about what their evidence actually supports.

Positioning the AI: Why Transparency Is a Competitive Advantage

Here’s what the McKinsey data tells you that most people miss: Consumers using AI healthcare tools report higher satisfaction than those not using them. The trust erosion isn’t about AI existing. It’s about AI being deployed in ways that feel opaque.

If you’re building an AI-powered scheduling tool, say so. Make the algorithm visible to users. If you’re using AI for triage, explain the logic. If you’re using AI for content recommendations, tell people it’s AI. The companies losing trust are the ones deploying AI while downplaying it, trying to make it feel human or hiding it entirely.

That 46% increase in appointment scheduling? It came from health content that was clearly positioned as educational, not prescriptive. Content that helped people understand what kind of care they needed, not content that told them what they should do. The AI that won consumer trust was transparent about its role.

This matters for wearables. It matters for digital front doors. It matters for patient engagement platforms. Every time you deploy an algorithmic decision, a choice about what to show, a prediction about what someone needs. You’re making a regulatory decision about whether that’s a medical device claim or a wellness feature. And you’re making a trust decision about whether to be transparent about it.

The winning move: Be explicit about what you’re doing with AI, what evidence supports it, and what the boundaries are. Don’t hide the algorithm. Don’t pretend it’s perfect. Don’t claim it’s replacing clinical judgment if it’s not. The companies winning consumer trust aren’t being less ambitious. They’re being more honest.

The Regulatory Classification Checklist: Build This First

Before you finalize your positioning, you need to make these decisions. Don’t make them in isolation from your product or marketing teams. Make them together, because they’re the same decision.

1. What specific outcome are you claiming? Not “better health.” Not “improved wellness.” What actual, measurable outcome? (Reduced appointment wait time. Faster triage decisions. Symptom reduction. Information access. All of these have different regulatory implications.)

2. What regulatory category does that outcome put you in? (Wellness support vs. disease prevention vs. disease treatment vs. information provision. This matters enormously for FTC oversight and what claims you can legally make.)

3. What evidence do you actually have for that outcome? (Not what evidence you wish you had. What you have right now. Be specific about study design, sample size, and whether it’s published.)

4. What is your honest assessment of the gaps in that evidence? (Where does the evidence come from? Are the populations representative? How confident are you in the mechanism?)

5. How will you communicate boundaries to users? (Carrion’s “not a therapist” is explicit. Midi’s “evidence-informed” approach is explicit. What’s yours? And where will you put this information: terms of service, in-app, marketing copy?)

6. What claims can you legally make given your category and evidence? (Not what you want to claim. What FTC and FDA frameworks actually allow you to claim given your classification and substantiation.)

The companies losing consumer trust skipped steps 2-6. They built a product, got some positive feedback, and started marketing based on what they wished was true. The companies winning trust made these decisions before they finished the feature roadmap.

What This Means for Your Go-to-Market

Regulatory strategy and consumer trust strategy are the same strategy. They’re not separate. The moment you decide your product is “wellness support,” you’ve decided your marketing can’t use disease language. The moment you decide you’re offering “information,” you’ve decided your evidence bar is different than if you’re offering “treatment support.”

Most healthtech founders see this as constraint. The winning move is to see it as differentiation.

Your competitors are either going too bold (claiming more than they can substantiate, inviting regulatory scrutiny and consumer distrust), or too timid (positioning so narrowly they become invisible). You can own the middle: ambitious scope, honest boundaries, transparent evidence.

For scheduling tools: Position yourself as reducing scheduling friction and removing barriers to care. You’re not claiming to improve health outcomes unless you have evidence. You are claiming to reduce barriers to care.

For patient engagement platforms: Position yourself as improving adherence and engagement. Say what engagement behavior your evidence supports, and be honest about the mechanism. (”Patients who engage with our daily check-ins report 30% higher appointment attendance” is a very different claim than “Our engagement tool improves health outcomes.”)

For digital front doors: You’re creating a data-informed triage system, not diagnosing. You’re routing people to the right kind of care, not saying what kind of care they need. This is a positioning move and a regulatory move at the same time.

For triage apps: This one is sensitive. Most triage apps are operating in a zone where FDA is paying attention. Know your regulatory status. If you’re a medical device, you’re a medical device. Own it or pivot. If you’re an information tool, communicate that explicitly.

For wearables and biomarker monitoring: Transparency about what you’re actually measuring, what your algorithm does with the measurement, and what the limitations are. “Our algorithm predicts sleep quality based on movement and heart rate. This is not a diagnosis. Here’s what your doctor should know about our limitations.”

For health content apps: This is usually the clearest regulatory zone. You’re providing information, not medical advice. Make that distinction visible. But don’t shy away from it. Information that helps people make better decisions about their care is valuable. Say so.

The Next Three Moves

This week: Audit your current positioning against the regulatory framework. Not “Is this legally safe?” but “Is this honest about what we claim?” Pull your marketing copy, your terms of service, your in-app language. Do they tell a consistent story about what you are and what you’re not?

Next month: Make the classification decision explicitly. Have your legal counsel, your product lead, and your head of marketing in a room. Decide: Are you wellness? Information? Prevention support? Treatment support? Write it down. Make it the anchor for every future marketing decision.

Next quarter: Rebuild your evidence communication. Whatever evidence you have, make it visible. Whatever gaps exist, be honest. The companies winning trust aren’t the ones with the best science. They’re the ones being the most honest about what science they have and what it actually supports.

Consumer healthtech is at an inflection point. Trust in AI healthcare is eroding, but it’s not because AI is bad. It’s because the messaging is incoherent. Regulatory strategy and consumer positioning have become the same thing. The founders who recognize this early will own the next generation of consumer health.

Clarity is the competitive advantage. Use it.

If you sell digital health tools for blood pressure, diabetes, chronic pain, or depression/anxiety, many of these organizations are evaluating how to build their technology stack over the next four months. Not all 350+ will make it through. Some will drop when they see the reporting requirements. But the ones that commit will be actively sourcing vendors for specific infrastructure gaps. Here’s why this matters, and what they’re actually looking for.

The ACCESS model pays participating organizations $180-$420 per beneficiary per year across four chronic care tracks. But 50% of that payment is withheld until they prove outcomes: blood pressure under 140/90, HbA1c at target, PHQ-9 and GAD-7 scores improving, weight trending down. Hit the clinical targets for at least 50% of your patients, you get paid in full. Miss them, you don’t.

That changes the buying conversation completely.

Before ACCESS, selling tech-enabled chronic care to a Medicare provider meant competing for innovation budget or layering onto existing CCM/RPM billing codes. The ROI case was always indirect: “our tool will help you bill more efficiently” or “our platform reduces readmissions.”

ACCESS makes the ROI case direct. The provider’s revenue literally depends on whether patients hit clinical targets. The outcome is measured at the patient level, so participants will want evidence that your product contributes to the target, not just that it “supports” chronic care generally. Bring data.

What ACCESS participants actually need from vendors right now. Based on the model’s reporting requirements, outcome measurement windows, and connected device dependencies, participants are trying to fill five infrastructure gaps:

1. Connected device procurement and distribution at scale, including the logistics to get BP cuffs, glucose monitors, and scales into patients’ homes (especially rural and underserved populations, where ACCESS provides a $15/beneficiary add-on specifically for device distribution).

2. FHIR-compliant outcome reporting systems that can feed clinical data into the ACCESS reporting API within the required validity windows (15 days for BP, quarterly for PROMs).

3. Patient enrollment and engagement platforms that drive adherence. ACCESS pays for outcomes, not enrollment. A patient who receives a device but never uses it is a cost, not revenue.

4. PROM collection tools for the behavioral health and MSK tracks: PHQ-9, GAD-7, and PROMIS pain scores, with automated validity-window tracking so nothing falls through the cracks.

5. Clinical workflow integration so care teams aren’t doing double documentation. If using your tool creates more work for nurses, it won’t survive the pilot.

Vendors who show up with a pitch that maps to these five needs will get meetings. Vendors who show up with “we do RPM” will not.

A note on horizontal tools. If your product isn’t condition-specific (clinical documentation AI, scheduling, care coordination), you’re not automatically excluded. ACCESS participants still need workflow infrastructure around the clinical programs. But you’ll need to position around a specific track’s requirements rather than selling generically. “We improve documentation efficiency” won’t land. “We automate PROM collection and validity-window tracking for the BH track” will.

Those are the five gaps. Now here’s what’s happening in the broader RPM market that will determine which vendors actually fill them.

There’s another change compounding this. As of January 1, CMS dropped the RPM monitoring threshold from 16 days per month to 2 days (new CPT 99445). Under the old rule, a patient who transmitted data 15 days out of 30 generated zero RPM revenue. Now that same patient is billable. The treatment management threshold dropped from 20 minutes to 10 minutes (CPT 99470) as well.

For ACCESS participants, this is fuel. They need connected device data to prove the outcomes that protect their withheld payment. The 2-day minimum means even their least-engaged patients can generate billable monitoring data. A tool that gets a patient to transmit 3 days per month used to be worthless for billing. Now it’s reimbursable AND it feeds the outcome reporting ACCESS requires.

For device manufacturers, the addressable market just expanded to include every patient who would have fallen below the old 16-day cutoff. In one study, 16% of monitored patients recorded only 2-15 days of data per month. That was dead revenue. It isn’t anymore.

But there’s a catch buried in the payment structure that most people will miss.

ACCESS includes a “substitute spend adjustment.” If more than 10% of a participant’s beneficiaries receive chronic care tech services (RPM, CCM, RTM, or DMHT codes) from a different provider, the ACCESS participant’s withheld payment gets reduced. The model financially penalizes fragmentation. And here’s where the 2-day RPM change makes this worse: because more providers can now bill RPM for shorter monitoring periods, there’s more RPM billing happening across the system. The odds that an ACCESS participant’s beneficiary is receiving RPM from someone else just went up.

What this means depends on which type of company you are:

If you bill Medicare directly for RPM, CCM, RTM, or DMHT services, and your client also participates in ACCESS, your services might be the “substitute spend” that triggers their penalty. You become a cost to them, not a partner. You need to restructure that relationship before July 5, either by contracting directly with the ACCESS participant so your services flow through their program, or by having a clear conversation about how your billing will coexist with their model.

If you’re a device manufacturer without FDA clearance, the TEMPO pilot offers enforcement discretion for up to 40 uncleared devices (10 per ACCESS track) while you collect real-world data toward eventual FDA submission. Statements of interest opened January 2, with follow-ups starting around March 2. It’s competitive, not guaranteed, but it’s the first time FDA and CMS have built a parallel regulatory/reimbursement on-ramp like this.

If you’re a software vendor that doesn’t bill Medicare and isn’t a device, this is actually the cleanest position. You sell directly to the ACCESS participant as a B2B vendor. No substitute spend trigger. No FDA pathway needed. The ACCESS participant gets $180-$420/beneficiary/year and decides how to spend it on technology, staff, and care delivery. Your product is a vendor expense they choose to absorb because it helps them hit the outcome targets that protect their withheld payment.

The risk in this third scenario: you’re competing for a share of a fixed per-beneficiary payment, not adding a new billing code on top. The ACCESS participant is doing math on whether your tool’s cost per beneficiary pays for itself in outcome improvement. That math only works if you have data showing your product moves the clinical needle. “We support chronic care management” isn’t enough. “Our platform improved BP control rates by X% in a comparable population” is.

Now zoom out, because the competitive landscape around all of this is shifting in ways that will surprise people.

The CPT-code-dependent RPM business model is under pressure from three directions at once.

Margin compression. Average Medicare RPM reimbursement has decreased 7-28% since the codes were introduced in 2019, even as CMS expands access. The 2-day monitoring threshold adds more billable patients, but at the same per-event reimbursement. More volume, thinner margins per patient. That math rewards scale and punishes small vendors who can’t spread fixed costs across a large patient base.

Platform risk. Large players would rather own the RPM workflow than reimburse it. UHC has developed its own RPM application. Humana has aligned its strategy with Epic and MyChart. Aetna is building through a partner network. Epic is embedding native RPM capabilities directly into the EHR. This is a different threat than coverage denial. It’s the buyer deciding to build rather than buy. UHC’s attempt to drop RPM coverage last fall (delayed after backlash, legally contested, and so far an outlier with no other major payer following) fits this pattern: they’re not saying RPM doesn’t work. They’re saying they’d rather control the workflow than pay third parties to deliver it.

Market saturation. The RPM vendor market is already heavily fragmented, with hundreds of companies competing on similar billing codes. ACCESS is about to intensify this, because every one of those vendors will pivot to selling B2B to ACCESS participants.

But here’s where the conventional wisdom is wrong: the flood won’t hit everyone equally.

Think of RPM software as three layers, not one. Each has a different defensibility profile.

The presentation layer is what’s commoditizing fastest. Patient-facing apps, monitoring dashboards, basic analytics, and engagement UX can be built by any competent team in weeks with AI coding tools. The barrier to building that layer just collapsed. When every competitor can spin up a comparable front-end, your dashboard isn’t a moat.

The clinical workflow layer sits in the middle, and it’s more defensible than most people realize. Clinical protocols, escalation logic, alert prioritization, care pathway automation — this is the intelligence that determines whether device data actually changes a patient’s outcome. ACCESS pays for outcomes, not data collection. The vendor whose software decides when to escalate a rising BP trend to a clinician, which patients need intervention this week, and how to route that alert into the care team’s existing workflow is solving the problem ACCESS participants actually have. That’s not something you replicate by building a dashboard.

The interoperability infrastructure layer is the deepest moat. FHIR-compliant data pipelines, HL7 message handling, clinical-grade audit trails, HIPAA-grade security architecture, and outcome reporting systems that feed ACCESS’s specific validity windows. That’s real engineering work that AI tools can accelerate but not automate end-to-end.

Software vendors whose value is in the presentation layer are exposed. Vendors who own the clinical workflow intelligence or the interoperability infrastructure are not. The strongest are the ones who combine both.

Hardware is moving in the opposite direction from software entirely. You can’t prompt-engineer a connected blood pressure cuff. You can’t AI-generate a CGM sensor. Manufacturing, supply chain, wireless certifications, clinical-grade accuracy validation, FDA clearance, and physical distribution logistics to patients are all barriers that AI tools don’t touch.

But hardware isn’t generically defensible either. Commodity-level BP cuffs that can already transmit readings are table stakes. The real hardware moat is where clinical-grade accuracy, FDA clearance, and FHIR-native data output converge. The question isn’t “can this device take a blood pressure reading?” It’s “can this device produce data in the exact format the ACCESS participant needs for outcome reporting, within the validity windows, without manual extraction or reformatting?” That’s hardware plus firmware plus data pipeline, not just hardware.

ACCESS makes this convergence more important, not less. The entire payment model depends on a data supply chain that starts with a physical device in a patient’s home. Without that device, the ACCESS participant can’t prove the outcomes that determine whether they get paid. The $15 per beneficiary rural add-on for connected device distribution reinforces this. ACCESS participants need devices in patients’ hands, especially in underserved areas. That’s a logistics operation, not a software feature.

So the real competitive picture shaping up around ACCESS: device companies with cleared hardware, FHIR-native data output, and distribution logistics have increasing pricing power because the ACCESS participant cannot get paid without their devices. Software vendors whose value is in the presentation layer face a margin squeeze as the category floods. Software vendors who own the clinical workflow intelligence or the interoperability infrastructure have a different kind of moat. And the vendors who combine devices, clinical intelligence, and data infrastructure are the ones ACCESS participants will consolidate around to avoid the substitute spend penalty.

Most companies can’t build all of this organically. A device company doesn’t have FHIR infrastructure. A software company doesn’t have manufacturing and distribution. The convergence will happen through partnerships and acquisitions, not internal build. If you’re a device company without a data infrastructure partner, or a software company without a hardware relationship, the question for 2026 isn’t “should I build this?” It’s “who do I partner with or acquire?”

Three things to do this week:

1. Find out if your prospects or current clients are applying to ACCESS. These organizations are self-identifying as buyers of tech-enabled chronic care infrastructure. CMS will maintain a public directory of participants and outcomes once the model launches. In the meantime, ask your prospects directly, or check the CMMI ACCESS page for updates on accepted organizations.

2. Figure out which scenario you’re in. Billing Medicare directly? Restructure before July 5. Device without clearance? Look at TEMPO now (the window is weeks, not months). Software vendor? Assess which layer you own: presentation (vulnerable), clinical workflow intelligence (defensible), or interoperability infrastructure (deep moat). If you’re in the presentation layer, start building the outcome attribution story or find a partnership that moves you deeper. If you’re a device or software company missing the other half, identify your M&A or partnership target now.

3. Map your product to the five infrastructure needs and the outcome targets. ACCESS doesn’t pay for utilization. It pays for BP under 140/90, HbA1c improvement, PHQ-9 score reduction. If you can’t draw a line from your product to one of these clinical targets through one of those five infrastructure gaps, you’re not in the conversation.

The organizations that get accepted will be building their technology stack between now and July. That’s your window.

But if you read the actual requirements, this RFI is something else entirely. It’s the most detailed public document I’ve seen from a federal buyer spelling out exactly what “enterprise-ready” means for health AI. And most of the companies building in this space right now would not qualify.

That’s worth paying attention to. Not because you’re going to respond to this RFI, but because every regulated buyer in healthcare is moving in this direction. CMS just said the quiet part out loud.

The Production-Only Gate

Page 3 of the RFI sets the tone immediately. CMS requires that solutions be “currently active and live in production environments, not aspirational, pilot-only, or in development.”

They go further. They want measurable outcomes from real beneficiaries. Documented uptime. Performance benchmarks. This isn’t a “show us your roadmap” conversation. This is a “show us your receipts” conversation.

For the plan recommendation category, the volume threshold is 1 million Medicare enrollments annually processed through AI-powered systems. For call center AI, it’s 250,000 calls or equivalent minutes per year. Across multiple carriers and plan types.

These numbers are designed to filter out companies that have a working demo, a few friendly pilot customers, and a pitch deck full of projections. CMS has seen enough pilots. They want proof that the thing works at scale, under real conditions, with real people making real healthcare decisions.

The Independence Requirement Nobody’s Talking About

Buried in the organizational requirements is a provision that eliminates a massive portion of the market.

CMS prohibits responses from companies affiliated with or owned by insurance carriers, brokerages, Field Marketing Organizations, or “any entity with a financial incentive to steer beneficiaries toward specific plans or carriers.”

Let’s be specific about who that touches. There are three business model structures that run straight into this wall:

Carrier-owned comparison platforms. Several of the largest Medicare plan comparison and enrollment platforms are subsidiaries of insurance holding companies or have been acquired by carriers. If the parent company sells Medicare Advantage plans, the subsidiary can’t claim neutrality in recommending them. CMS is drawing a bright line here.

Commission-dependent distribution technology. A large category of health tech companies in the Medicare space monetize through downstream insurance commissions. They may look like technology companies, but their revenue depends on which plan a beneficiary selects. Under these requirements, that financial structure is disqualifying regardless of how good the technology is.

Foundation model API wrappers. CMS also requires that respondents own their AI technology outright and control their training, deployment, and governance “without dependencies on third-party AI platforms that could compromise CMS data security or beneficiary privacy.” If your core AI capability is a thin application layer on top of a foundation model provider’s API, if you’re essentially doing prompt engineering and UX on top of someone else’s model, CMS is asking whether you actually control the thing. They want to know who owns the algorithms, the models, the IP, and the data. If the answer is “we license it,” that’s a problem.

For PE and VC firms evaluating health AI companies, this section of the RFI is a diligence checklist in disguise. The combination of plan neutrality and technology ownership is being established as a baseline requirement at the federal level, not a differentiator. Companies structured around commission-based distribution or dependent on third-party AI infrastructure may find themselves locked out of the largest single payer in the country. That has direct implications for which companies become more valuable and which become harder to fund.

Trust Infrastructure Is the Actual Product

The longest sections of this RFI aren’t about the AI itself. They’re about everything around the AI.

CMS devotes full sections to explainability (every recommendation needs a clear, user-facing explanation), bias and fairness (documented testing, fairness metrics, monitoring, remediation, training data transparency), privacy architecture (HIPAA, FedRAMP, privacy-preserving ML, encryption, incident response), accessibility (Section 508, WCAG 2.1 AA, multilingual support, plain-language outputs, adaptive interfaces for varying literacy and cognitive levels), and governance (audit trails, consent mechanisms, model drift monitoring, continuous validation, controls against misleading responses).

In my upcoming book Built to Survive, the core argument is that the companies that win in regulated AI aren’t the ones with the best model. They’re the ones that build the trust infrastructure around the model: the governance, the compliance scaffolding, the explainability, the auditability. The stuff that doesn’t show up in a demo but absolutely shows up in a procurement evaluation.

This RFI reads like a checklist of that argument. CMS isn’t just buying AI capability. They’re buying the ability to deploy AI responsibly, at federal scale, with 70 million people who depend on getting the right answer.

This Isn’t Just CMS

If this were only about one federal RFI, it would still be worth reading. But CMS isn’t operating in isolation. The same requirements showing up in this document are already appearing across the healthcare procurement landscape.

In September 2025, the Joint Commission partnered with the Coalition for Health AI (CHAI) to release national guidance on responsible AI use in healthcare. Their framework covers the same territory CMS is asking about: formal governance structures, bias and risk assessment, local validation before deployment, continuous monitoring, data security, and voluntary safety event reporting. The Joint Commission plans to release detailed governance playbooks and then launch a voluntary AI certification program in 2026, available to its 22,000+ accredited healthcare organizations nationwide.

That certification is going to change vendor evaluations. The Joint Commission’s procurement guidance already tells hospitals to request information from AI vendors on how tools were tested and validated, whether vendors will validate on samples representative of the deployment context, and how biases were evaluated and mitigated. When the certification goes live, hospitals will have a structured framework for asking these questions and a reason to reject vendors who can’t answer them.

Meanwhile, state-level requirements are compounding. Colorado’s AI Act kicks in June 30, 2026, requiring disclosure whenever AI is used in high-risk decisions, annual impact assessments, anti-bias controls, and three years of record-keeping. Utah already enforces AI disclosure in healthcare, with $2,500 per-violation penalties. Texas requires plain-language disclosure in AI-influenced high-risk scenarios, with enforcement starting in 2026. CMS itself launched the WISeR Model in 2025, using AI to review prior authorization decisions, and now expects hospitals to demonstrate auditable data lineage, model explainability, and prompt-level validation for their own AI systems.

A 2025 study found that only 44% of U.S. hospitals currently evaluate AI tools for bias, despite 65% using predictive models. That gap is about to close, and it’s going to close through procurement requirements, accreditation standards, and state enforcement, not because vendors voluntarily decided to get rigorous.

The CMS RFI is the federal version of a conversation that’s already happening at health systems, state regulators, and accrediting bodies across the country. If you’re building health AI and your go-to-market includes any regulated enterprise buyer, this is the direction the requirements are moving. Not eventually. Now.

Subscribe now

A Note for Seed-Stage Founders

If you’re reading this with 15 employees and two pilots and thinking none of this applies to you yet: I get it. You’re not responding to a CMS RFI. You’re trying to convert one pilot into a paid contract.

But here’s why this matters to you right now: the health system you’re selling into is reading the same Joint Commission guidance. Their procurement team is starting to ask vendors for bias testing documentation, validation evidence, and explainability frameworks. Maybe not in your current pilot conversation, but in the next one. Or in the expansion conversation after the pilot succeeds.

You don’t need FedRAMP authorization at your stage. You don’t need to process a million enrollments. But you do need to start building the minimum version of trust infrastructure that lets you answer these questions when they come:

Start with explainability documentation. Write down, in plain language, how your model makes recommendations and what data it uses. This doesn’t require a research paper. It requires a two-page document that a non-technical procurement reviewer can read and understand. If you can’t explain how your AI works in writing, you can’t sell it to an enterprise buyer.

Run a basic bias assessment. Look at your model’s performance across the demographic groups represented in your pilot data. Document what you found, including where the data is thin. The point isn’t to prove your model is perfect. The point is to show you looked, you know where the gaps are, and you have a plan. A 2025 Censinet analysis found that hospitals are increasingly scoring vendors on bias mitigation during evaluations. Having a documented assessment, even an early one, puts you ahead of the majority of startups who have nothing.

Get your data governance story straight. Know exactly what data you’re using, where it comes from, what rights you have to it, how it’s stored, and who can access it. Map your data flows. This is foundational work that doesn’t cost much to do early but becomes very expensive to retrofit when a buyer asks for it during diligence.

Build consent and audit mechanisms into the product now. Adding audit trails and user consent flows later means rearchitecting. Adding them now means making a few design decisions while you’re still building. Every health system buyer is going to ask how you log AI-generated recommendations and whether beneficiaries consented to personalized guidance. Build the plumbing before the inspection.

None of this requires a big team or a big budget. It requires deciding that trust infrastructure is part of the product, not something you’ll figure out after you get traction. The founders who make that decision at the seed stage are the ones who don’t get stuck when a health system’s procurement team sends over a 40-question AI governance questionnaire and expects answers in two weeks.

What the Procurement Approach Signals

The back half of the RFI outlines an anticipated procurement approach worth studying. CMS is considering a challenge-based acquisition with proof-of-concept evaluations, multiple initial awards, head-to-head comparisons, down-selection, and phased rollout starting with pilot states.

They even publish illustrative evaluation metrics: plan recommendation accuracy of 85% or higher against expert recommendations, conversational AI satisfaction of 80% or higher, response times under 2 seconds for recommendations and under 3 seconds for chatbot, WCAG 2.1 AA conformance verified by third parties, SUS usability scores of 70 or higher, and no statistically significant disparate impact on protected classes.

These are concrete, testable numbers. If you’re building in this space and you aren’t already measuring your product against benchmarks like these, you’re not preparing for enterprise procurement. You’re hoping for it.

The challenge-based approach also tells us something about CMS’s confidence level. They’re not ready to pick a winner. They want to see who can actually perform under controlled conditions before committing. That’s a procurement team that has been burned by vendors who demo well and deliver poorly.

Where This Leaves You

Here’s a stage-specific read on what to do with this information:

If you’re pre-revenue or in early pilots: Your job isn’t to meet CMS thresholds. It’s to start building the documentation and governance habits that will let you meet them later without a painful retrofit. Explainability docs, a bias assessment, data governance mapping, and audit-ready logging. These are weeks of work, not months. Do them now.

If you’re post-pilot with paying customers: You should be benchmarking your product against the proof-of-concept metrics CMS published: recommendation accuracy, response time, usability scores, fairness testing. You should also be mapping your technology ownership and independence. If your core AI runs on a third-party platform you don’t control, start thinking about what your migration path looks like before a buyer asks.

If you’re at growth stage selling to enterprise buyers: This RFI is a preview of your next three years of procurement conversations. Use it as a gap analysis. Walk through every section CMS covers (explainability, bias, privacy, accessibility, governance, integration, scalability) and grade yourself honestly. Where you have gaps, build a roadmap with timelines. Where you’re strong, start documenting it in a format procurement teams can consume.

If you’re a PE/VC firm evaluating health AI: Add the independence and IP ownership questions from this RFI to your diligence framework. Ask portfolio companies whether their business model would survive CMS’s conflict-of-interest requirements. Ask whether they own their AI or rent it. The answers will tell you a lot about which companies are built for regulated enterprise sales and which are built for a market that’s disappearing.

The CMS RFI (Notice ID: 269999) is open for responses through March 31, 2026. The full document is available through federal procurement channels.

The Joint Commission and CHAI’s Guidance on Responsible Use of AI in Healthcare is publicly available at jointcommission.org.

Arvita Tripati is the founder of Vahana Labs, where she helps health AI companies navigate the gap between pilot success and enterprise-scale deployment. She is the co-author of the upcoming Built to Survive: Building Trusted AI Products and Organizations.

Most companies can prove they have a human in the loop. They can count it, document it, point to it when a regulator or buyer asks. What they can’t prove is whether that human is actually catching problems, whether they have the information, time, expertise, authority, and incentive to function as real oversight.

That’s effectiveness. Harder to measure. Harder to audit. But it’s what determines whether oversight is real or theater.

The Research on What Efficiency Misses

Automation bias is real. Decades of research shows humans tend to accept automated recommendations even when they’re wrong. The bias is stronger when humans are less confident in their own judgment and when systems are perceived as reliable. The more you trust the AI, the less you check it.

Workload makes real review impossible. Studies report radiologists must interpret one image every 3-4 seconds during an 8-hour shift to meet demand. They make 30% more errors toward the end of a long shift, examining less of each image as fatigue sets in. The human is in the loop. The review is happening. It’s just not thorough.

Alert fatigue trains humans to ignore. Clinical decision support systems generate so many alerts that physicians learn to click through them. One study found only 7.3% of drug-drug interaction alerts were clinically appropriate. Physicians adapted rationally: they stopped paying attention.

That last point matters. Poorly designed systems trained humans to override, and that habit persists even when the systems improve. You can fix the AI. The human muscle memory is harder to fix.

The human is present. The human is clicking. By efficiency metrics, oversight is happening. By effectiveness metrics, is the human actually catching errors? The story is different.

Five Questions That Test Effectiveness

I’ve sat through enough FDA reviews to know what separates real oversight from theater. The reviewer always asks the same questions:

1. Does the human have information to actually evaluate the output?

If they see a recommendation without the reasoning, the confidence score, or the underlying data, they can’t evaluate. They can only approve on gut feel.

2. Do they have time?

If proper review takes 3 minutes and they’re seeing 200 outputs per day, the math doesn’t work. You’ve built a system that requires 10 hours of review into an 8-hour day.

3. Do they have expertise to catch errors?

The human in the loop needs to be the right human. A customer service rep reviewing AI-generated legal language isn’t oversight. A junior associate reviewing AI-drafted contract clauses might not be either.

4. Do they have real authority to override?

If overriding triggers extra documentation, flags for supervisory review, or takes 5x longer than accepting, that’s not authority. That’s friction designed to suppress disagreement.

5. Do they have any incentive other than to approve?

If the human’s metrics are based on throughput, if their bonus depends on volume, if their performance review mentions efficiency but not accuracy, you’ve built a system that rewards rubber-stamping.

In a system optimized for efficiency, conscientiousness becomes a performance problem.

Utah Started Measuring Effectiveness

Three weeks ago, Utah became the first state to let AI prescribe medication without a physician’s involvement.

Through Doctronic, patients with chronic conditions can renew prescriptions online. No doctor reviews the decision. The AI evaluates the request, sends the prescription to the pharmacy. Four dollars, a few minutes, done.

My first reaction wasn’t “this is dangerous.” It was: “they’re asking the right questions.”

Utah looked at prescription refills and asked: is the physician actually adding value, or just adding cost and delay? Is the doctor exercising clinical judgment, or clicking through a queue? If the human oversight isn’t functioning as oversight, why require it?

Their answer was specific to a narrow use case. Only refills, not new prescriptions. Only 190 pre-approved medications. No controlled substances. Human doctors review the first 250 prescriptions per drug class before the AI goes autonomous. Malpractice insurance holds the AI to physician standards.

They didn’t eliminate oversight. They redesigned it based on where oversight actually adds value.

The Gap Nobody’s Talking About

At a recent dinner with people building AI across legal, enterprise software, and consumer products, I heard variations of the same efficiency problem.

One founder described taking 500 hours of legal document review down to 30 minutes. A human reviews the AI’s output. But that human used to spend 500 hours building context and judgment. Now they’re reviewing a summary they didn’t create, for a case they don’t deeply understand. Are they catching errors, or blessing outputs?

A CEO building AI to replace work humans used to do raised a pipeline problem: routine tasks are where people build judgment to handle hard ones. If juniors never do the repetitive work, they never develop pattern recognition for when something’s off. Faster output today, hollowed-out pipeline tomorrow.

But here’s what I kept thinking about: rural electrification. We’ve been at it for 80 years and it’s still not done.

The conversation assumed AI deployment is a question of “when,” not “where” or “for whom.” But the communities I work with, rural health systems, under-resourced clinics, the places that get new technology last, aren’t going to see these AI tools for years. And when they do, they’ll have even fewer resources to audit whether oversight is working.

The effectiveness problem isn’t just about whether your human is rubber-stamping. It’s about what happens when AI tools reach the places with the least capacity to check them. The gap between “AI is going to eat the world” and actual deployment to those communities is larger than the hype suggests. And the places with the weakest oversight infrastructure will be the ones where effectiveness failures hit hardest.

That’s not an argument against AI. It’s an argument for taking effectiveness seriously before the tools scale past the organizations that can afford to ask questions.

What I Think Happens Next

The “human in the loop” slogan has about 18 months left. Not because humans will be removed from loops everywhere. But because efficiency answers will stop being sufficient.

Regulators, buyers, and boards will start asking effectiveness questions. They’ll want acceptance rates, override frequency, time-to-decision metrics. Evidence that the human is functioning as oversight, not just present as compliance theater.

Utah is the first mover. The EU AI Act already requires human oversight that’s “effective,” not just present. Enterprise buyers are starting to ask about audit trails. The sophistication of the questions is increasing.

Companies that can answer effectiveness questions will close deals faster. Companies still offering efficiency answers (”don’t worry, there’s a human”) will start losing to competitors who can show their work.

Where to Start

If you don’t have a team dedicated to this, you’re not alone. Most companies don’t.

Start with one deployment. Pick the AI with the highest stakes or the highest volume, wherever a failure would hurt most. Then ask the five questions. Not theoretically. Actually measure:

• Acceptance rate. If it’s above 95%, that’s not a sign your AI is good. It’s a sign your human may have stopped reviewing.

• Time to decision. How long does the average review take? Is it enough time to actually evaluate, or just enough time to click?

• Override friction. Walk through the override path yourself. Count the clicks, the forms, the delays. If it’s significantly harder than accepting, your override path is decorative.

Skip the dashboard. Skip the new hire. Someone spending half a day with one system and reporting back is enough to start.

If the answers are bad, you’ve learned something important. If the answers are fine, you’ve got evidence you didn’t have before. Either way, you’re ahead of companies still counting humans without checking if they’re working.

The Harder Question

Do you have a threshold for removing the human from the loop?

If the AI is good enough, if the human is just adding cost without adding safety, at what point do you take them out? Utah defined theirs: 250 successful prescriptions per drug class, then the AI goes autonomous.

Most companies don’t have one. They’ll either keep humans in loops forever, expensive and possibly pointless, or remove them based on intuition when the pressure gets high enough.

Efficiency thinking says: keep the human, check the box, move on.

Effectiveness thinking says: figure out where the human actually adds value, measure it, and design your oversight around that.

The companies that figure out the difference will be the ones still standing when the stress test comes.

I’ve spent 20 years in healthcare AI, where regulators force you to answer effectiveness questions whether you want to or not. If you’re thinking through strategy & governance for your own deployments, I’m at arvita (at) vahanalabs.com.

References

• Springer AI & Society. “Exploring automation bias in human-AI collaboration.” 2025.

• Hosny A, et al. “Artificial intelligence in radiology.” Nature Reviews Clinical Oncology, 2018.

• Park H, et al. “Appropriateness of Alerts and Physicians’ Responses.” JMIR Medical Informatics, 2022.

For wearable AI devices, the answer usually comes down to whether founders understand what they’re actually building. Not the vision. Not the pitch. The product that will survive contact with clinical validation, FDA review, and commercial reality.

One of the hardest things about building a regulated device is knowing what the bar actually is. Guidance is written to cover thousands of device types. It tells you what to think about, not what to do.

The strategy I’ve used: pattern match. Working on a novel implantable neurostimulator with no specific guidance? Study the pacemaker pathway. It’ll get you most of the way there. Building a wearable in a category without established precedent? Look at adjacent markets. How did Dexcom build a consumer business around continuous data when the clinical standard was intermittent finger sticks? How did AliveCor carve out a category for mobile ECG when the incumbent was a hospital device? The specific tissue area matters less than the strategic problem: how did someone else convince FDA, payers, and clinicians to accept a new form factor for an established measurement?

The new cuffless blood pressure guidance just became that template for wearable AI. Not because you’re building a blood pressure device, but because FDA just showed how they’ll evaluate any wearable that uses AI to claim clinical-grade accuracy.

Here’s what it tells you about whether your bet is worth making.

Does Your Technology Work Where It Matters?

Most wearable algorithms nail accuracy at a single point. Calibrate, measure, compare to reference, hit your spec. That’s the easy test.

The hard question: can you detect the changes that actually matter clinically?

For blood pressure, that means catching the thresholds that alter clinical decisions: normal to Stage 1 hypertension (crossing 130 mmHg), Stage 1 to Stage 2 (crossing 140 mmHg), the jump toward hypertensive crisis (180 mmHg). For glucose, it’s detecting excursions into hypoglycemic or hyperglycemic ranges. For any vital sign, the question is the same: can you catch the shift that would change what a clinician does next?

Most algorithms can’t. They learn correlations around a calibration point and degrade outside that range.

The new FDA guidance makes this explicit: 30% of validation measurements must show large increases from calibration, 30% must show large decreases, same accuracy spec in both directions. But the regulatory requirement isn’t the point. The point is that a device calibrated at 120 mmHg that loses accuracy as readings approach 140 mmHg is a device that works when it doesn’t matter and fails when it does.

That’s not a regulatory problem. It’s a technology problem. And it’s a differentiation problem. If your algorithm only works in static conditions, you don’t have a better product than what exists. You have a different form factor for a narrower use case.

That might still be a business. Confirming a diagnosis already made, establishing baselines, monitoring stable patients. But it’s a smaller market, a narrower indication, a different competitive position. The question is whether that’s a business worth building.

Before you spend another dollar on clinical validation: Stress-test your algorithm across the thresholds that matter for your indication. Not “does accuracy degrade?” but “can I still detect the clinical transitions that would change patient management?” If the answer is no, you have three options:

1. Fix the algorithm (hard, possibly impossible with your current approach)

2. Narrow your indication to conditions where transitions don’t matter (limits clinical value and differentiation)

3. Walk away and redeploy the capital elsewhere

This filter tells you whether your core technology works before you burn $2M proving it doesn’t.

Is “Continuous” Worth the Cost?

Calling your device “continuous monitoring” sounds better for marketing. It might also double your validation cost and add six months to your timeline. Intermittent measurements validate against a nurse with a blood pressure cuff. Continuous measurements validate against an arterial line. Invasive, hospital-based, expensive. The cost difference is 3-5x. The timeline difference is 6-12 months.

But the validation cost isn’t even the main question. The main question is whether “continuous” actually changes your business:

Clinical value: Does continuous change patient outcomes for your indication, or is it a feature that sounds good but doesn’t move the needle? For some conditions (arrhythmia detection, glucose management), continuous matters. For others, intermittent spot-checks may deliver 90% of the clinical value.

Reimbursement: Continuous monitoring codes exist for some categories but not others. If there’s no reimbursement pathway for continuous, you’re building a feature payers won’t pay for.

Competitive differentiation: If everyone else is intermittent, continuous might be your wedge. If the market is moving to continuous anyway, being intermittent might leave you behind. Know what you’re actually competing on.

User behavior: Will patients actually use continuous monitoring, or will they check once a day regardless? If real-world usage patterns are intermittent, validating as continuous is paying for something you won’t use.

Some companies intentionally position as “intermittent spot checks” even when their technology could run continuously, because the study is cheaper and faster. That’s not a compromise. That’s capital efficiency.

Does Your Positioning Match Your Product?

Founders hope that clever positioning will simplify the path. Call it wellness, not clinical. Call it decision support, not diagnosis. Call it screening, not detection.

It rarely works. Regulators classify based on function and risk, not marketing language. If your device outputs values that look clinical (118/76 mmHg, 95% SpO2, 110 mg/dL), you’re a medical device regardless of your disclaimers. If your software analyzes signals to generate clinical recommendations, it’s a device, no matter what you call it.

The test: Would a reasonable user make health decisions based on your output that they’d otherwise make with a clinical device? If yes, you’re regulated.

Stop building strategy around the classification you want. Build it around the classification your device’s function will trigger. If that breaks your timeline or capital model, better to know now.

Does Your Capital Plan Reflect Reality?

Two assumptions blow up most fundraising models: how long enrollment takes and how long FDA review takes.

Enrollment.

Your clinical study needs to prove your device works across the population you’re claiming. If your sites can’t recruit that population, your timeline stretches.

The specific subpopulations that matter depend on your device. For optical sensors, skin pigmentation is the obvious one. The BP guidance requires 25% enrollment in each Monk skin tone tier. But depending on your technology, the list might include BMI, tissue thickness, perfusion, or motion artifacts. For your indication, you need the clinical populations where you’re claiming to work: age ranges, comorbidities, disease severity.

Most single-site US academic medical centers can’t hit aggressive diversity or comorbidity targets. If your sites can’t recruit the population you need, you’re looking at multi-site studies or international expansion:

• Single-site US study, accessible population: 6-9 months

• Multi-site US study with specific subpopulation requirements: 12-18 months

• International sites added: 18-24 months, plus regulatory and logistical complexity

Review timeline.

Promising investors a specific clearance date is promising something you don’t control. This has always been true for regulated devices. AI/ML adds uncertainty. The current FDA environment compounds it.

FDA review timelines depend on reviewer workload, the questions your submission raises, and whether your device fits neatly into established categories. For AI/ML devices, FDA is still figuring out evaluation frameworks. Your submission might be a test case. That means additional information requests you can’t anticipate, review cycles that extend beyond published targets, possibly a request to reclassify from 510(k) to De Novo mid-review.

Personnel changes, hiring freezes, and organizational uncertainty at FDA create additional variability. The reviewer who understood your device category may not be there when your submission arrives.

I’ve seen AI/ML submissions add 6-12 months beyond what the founder modeled. Not because anyone made mistakes, but because the environment is genuinely unpredictable.

The capital math.

Take your current burn rate. Add a realistic clinical study cost (not the optimistic version). Add 6 months of buffer for review uncertainty. Do you have 18+ months of runway from that starting point?

If no, you need to raise more, spend less, or narrow scope before you start the clinical program. Telling investors “Q3 2026” when you should have said “sometime in 2026” is how you end up in painful conversations later. Precision you can’t deliver becomes credibility you can’t recover.

Are You Building a Business or Chasing a Clearance?

A pre-submission meeting with FDA costs roughly $10K in fees and takes 2-3 months. It tells you whether FDA agrees with your regulatory pathway, whether your predicate is acceptable, whether your clinical study design will generate evidence they’ll accept.

I’ve watched companies design $2M clinical studies for a 510(k) pathway, submit, and learn FDA considers them De Novo. Eighteen months lost. Another fundraise required.

But here’s the thing: even companies that get clearance efficiently sometimes fail to build a business. Clearance is the starting line, not the finish.

I’ve also watched companies get clearance and then discover there’s no reimbursement code for their device. Or that health systems won’t adopt without integration into their EHR, which takes another 18 months. Or that the clinical workflow they assumed doesn’t exist, so clinicians don’t know what to do with the data. Clearance without a path to revenue is just an expensive credential.

What your next investors will ask:

1. Pathway clarity: Is this 510(k) or De Novo? Do you have FDA feedback confirming, or are you guessing?

2. Clinical study design: Does your protocol meet current validation expectations, or will you need to redo it?

3. AI/ML documentation: Can you show training data provenance? Subpopulation performance? How you’ll handle drift?

4. Diversity data: Will your validation hold up to scrutiny on demographic performance?

5. Change test performance: Does your algorithm track physiologic shifts, or only static conditions?

6. Commercial path: What unlocks revenue after clearance? Reimbursement, partnerships, clinical adoption?

A diligence team stress-tests your regulatory package as much as your technology. Gaps become valuation haircuts. Or term sheet passes.

And remember: a strong regulatory package doesn’t just get you through FDA. It positions you for partnership conversations, reimbursement negotiations, and the commercial phase where the real scaling happens.

Who’s Positioned to Win

These constraints apply to everyone, but they don’t affect everyone equally.

Well-positioned:

• Teams who chose intermittent positioning because it fits the clinical use case. They face a 3-5x cheaper validation path.

• Companies whose training data already includes diverse populations. They don’t need to retrofit enrollment strategy.

• Devices where the reference standard is accessible (a cuff, a finger stick) rather than invasive (arterial line, lab draw).

Exposed:

• First-time founders who assumed 510(k) would be straightforward for “just software”

• Teams planning single-site US studies who haven’t mapped their enrollment demographics against the subpopulations their device needs

• Anyone whose algorithm was tuned on data from one demographic and hasn’t tested cross-population performance

For investors, three signals that matter before clinical data exists:

Training data provenance: Where did the data come from? How diverse is it? If training data is homogeneous, assume the validation study will surface problems.

Regulatory fluency at the founder level: Does the CEO understand the difference between 510(k) and De Novo? Founders who delegate regulatory entirely to consultants often get surprised.

Clinical endpoint clarity: Can the team articulate what clinical transitions their device needs to detect, and why those matter? Teams that start from clinical utility and work backward are more likely to build something that passes validation AND has a market.

If you’re in the exposed column, that’s not a signal to quit. It’s a signal to recalibrate before the gap becomes a crisis.

The Viability Test

Some founders reading this should conclude their device isn’t viable under current constraints. Here’s how to know if that’s you:

Technology:

• Identify the clinical thresholds that matter for your indication, the transitions that would change patient management. Test your algorithm’s accuracy specifically at and around those thresholds.

• If accuracy degrades as you approach clinically meaningful transitions, you have a device that works when it doesn’t matter. Strategy can’t fix that.

Product clarity:

• Do you know whether you’re building continuous or intermittent, and have you made that choice based on clinical value and business model, not just what sounds better?

• Does your positioning match what your device actually does, or are you hoping for a classification you won’t get?

• Are your product requirements aligned with the clinical claims you’ll be able to make, or are you building features that won’t be in your cleared indication?

Capital:

• Can your sites recruit the populations you need, or do you need to add sites and extend timelines?

• Do you have 18+ months of runway from study start, including buffer for review uncertainty?

Market:

• Is there a reimbursement pathway for your device, or will you be selling into a payment vacuum?

• Do you know the clinical workflow you’re fitting into, or are you assuming clinicians will figure out what to do with your data?

• Does clearance unlock real revenue, or just permission to sell something nobody’s buying?

If you hit red flags on two or more of these categories, the guidance isn’t telling you to try harder. It’s telling you to reconsider the bet, or reconfigure it with different resources, scope, or timing.

Monday Morning

• [ ] Run your own change test. Identify the clinical thresholds that matter for your indication and test accuracy there. If your algorithm falls apart approaching those transitions, address that before spending anything else.

• [ ] Map your enrollment sites against subpopulation requirements. Can you actually recruit the populations your device needs to validate against?

• [ ] Decide: pre-submission meeting or not? If any pathway ambiguity exists, the answer is yes.

• [ ] Stress-test your timeline assumptions with someone who’s been through a recent submission. Not a consultant who’ll tell you what you want to hear.

• [ ] Revisit your fundraising model with realistic regulatory timelines. If it breaks your runway math, better to know now.

Building a wearable AI device and want to pressure-test whether it’s built to scale? Reach out to me arvita (at) vahanalabs.ai or book a call at www.vahanalabs.ai

The short version: non-invasive wearables estimating blood pressure, glucose trends, SpO2, and HRV can now operate as wellness products outside FDA oversight, provided they stay within specific guardrails.

I’ve spent nearly two decades helping healthtech companies navigate from pilot to enterprise scale. This piece is the playbook I’d give a founder walking into my office tomorrow asking “what do I do with this?”

The Market You’re Playing In

Before strategy, context. The wellness wearables market is large and growing:

The wellness wearables market is roughly $20-25 billion domestically today, growing to $80-90 billion by 2035. Oura just raised $900 million at an $11 billion valuation. Whoop is at $3.6 billion. The market can support very large outcomes.

The guidance just opened a significant portion of it to products that previously faced regulatory ambiguity.

The 90-Day Checklist

If you’re a seed or Series A wellness company, here’s what to do in the next quarter:

Week 1-2: Claim Audit

Get regulatory to review every claim in your product, marketing, and sales materials. Map each claim to one of two buckets:

• Wellness claims (guidance compliant): “may help living well with,” “as part of a healthy lifestyle,” tracks/monitors/encourages

• Medical claims (guidance non-compliant): diagnoses, treats, manages, screens, monitors for clinical purposes

If anything lands in the second bucket, fix it now. This is table stakes.

Week 3-4: Validation Documentation

The guidance requires “validated values” but doesn’t define validation standards. Build your defensibility file:

• Document your validation methodology (internal testing, third-party lab, peer-reviewed literature)

• Quantify accuracy and limitations in writing

• Create a summary suitable for enterprise buyer diligence

A clinical trial isn’t required. What matters is being able to answer “how do you know this works?” with specifics.

Week 5-8: Buyer Segment Mapping

Not all buyers require the same evidence. Map your target segments, evidence required, and timeline to sale. Consumer DTC needs product experience and brand. Wellness brokers need engagement metrics. Enterprise employers need published validation. Health systems usually want clearance.

Decide which segments you’re pursuing in the next 12 months. Build evidence for those segments, not for some abstract “credibility” standard.

Week 9-12: Clinical Advisory Infrastructure

Get at least one clinical advisor who can:

• Review claims for clinical defensibility

• Represent you in conversations with sophisticated buyers

• Connect you to relevant professional networks

This doesn’t require a famous CMO. It requires someone credible who will actually engage. One good advisor beats a logo-farm advisory board.

The Three Viable Strategies

Based on how regulated digital health markets have stratified historically, and the capital and capability requirements for each segment, there are three coherent paths through this market. Pick one.

Strategy 1: Consumer Scale

The bet: Build a consumer subscription business that doesn’t depend on enterprise sales or clinical validation.

Who this is for: Teams with strong consumer product and growth skills. Founders who’ve built DTC brands. Companies targeting performance, optimization, and quantified-self markets.

Requirements:

• Compelling product experience

• Engagement and retention metrics

• Brand and community

• Basic analytical validation (enough to defend against “this doesn’t work” claims)

Not required:

• Clinical trials

• Enterprise sales team

• Medical society relationships

• FDA clearance pathway

The exit: Consumer health acquirers (Apple, Google, Garmin, Samsung), standalone scale, or acqui-hire.

Who did this well: Oura and Whoop built cult communities around specific use cases (sleep, athletic recovery) before expanding.

Who struggled: Amazon Halo had novel technology but no community or clear differentiation. Fitbit got squeezed between Apple and cheaper alternatives.

Strategy 2: Enterprise Wellness

The bet: Sell to employers and benefits buyers who want wellness solutions with credibility but don’t require FDA clearance.

Who this is for: Teams with B2B sales experience. Founders who understand benefits procurement. Companies with products that show engagement and behavior change.

Requirements:

• Validation documentation (your defensibility file)

• Engagement and behavior change data from early deployments

• At least one clinical advisor

• Case studies from pilot customers

• Sales team that understands benefits buyers

Not required:

• Peer-reviewed publications (helpful but not required)

• FDA clearance

• Deep medical society relationships

The exit: Benefits platform acquirers, healthcare services companies, PE rollup.

Timeline to first enterprise deal: 6-12 months if you have pilot data. 12-18 months if starting from scratch.

Who did this well:

Oura’s enterprise pivot is instructive. They started pure consumer, then expanded to employer wellness and military contracts. The US military is now their largest B2B customer, with tens of thousands of service members using rings for fatigue tracking. They didn’t start with enterprise readiness; they built it after proving consumer traction.

Virgin Pulse (now Personify Health after merging with HealthComp) is the clearest enterprise wellness success story. Founded in 2004, they built an engagement platform aggregating multiple wellness modalities (activity tracking, health coaching, rewards) and sold outcomes data to employers. They raised ~$90M total before being acquired by Providence in 2022 for a reported $3B. Timeline: 18 years from founding to major exit.

Livongo took a disease-specific approach (diabetes management), raised $235M, and went public in 2019 at a $2.5B valuation. Teladoc acquired them in 2020 for $18.5B at the peak of telehealth enthusiasm. Timeline: 6 years from founding to IPO, 7 years to acquisition. They proved that focused clinical outcomes could command enterprise premiums.

Castlight Health is the cautionary tale. They went public in 2014 at a $3B valuation on the promise of healthcare navigation and transparency. The stock dropped 90%+ over the following years as growth stalled. They were eventually acquired by Vera Whole Health in 2022 for ~$370M. The lesson: enterprise wellness valuations can evaporate if growth doesn’t materialize.

What goes wrong:

Enterprise wellness sales cycles are long (6-12 months minimum), require multiple stakeholders (HR, benefits, sometimes clinical), and often stall at pilot. The biggest failure mode is running out of runway during the pilot-to-contract conversion. Budget 18-24 months of runway before expecting meaningful enterprise revenue.

Typical timeline to scale:

• Year 1: 2-5 pilot customers, minimal revenue

• Year 2: 5-15 customers, $500K-1.5M ARR

• Year 3: 15-40 customers, $2-5M ARR

• Year 4: Path to $10M ARR if product-market fit is real

Strategy 3: Clinical Onramp

The bet: Use the wellness product as infrastructure for an eventual FDA-cleared medical device.

Who this is for: Teams with clinical and regulatory expertise. Founders who want to build a platform company. Products where the clinical version would command premium pricing or reimbursement.

Requirements:

• Everything from Strategy 2, plus:

• Regulatory affairs capability (hire or advisor)

• Clinical advisory board with domain expertise

• Data architecture designed for eventual regulatory submission

• Published validation studies (working toward peer review)

• Medical society visibility (conference presentations, research collaborations)

The exit: Medical device acquirers, pharma partnerships, standalone with diversified revenue (consumer + clinical).

Why this works: Your wellness user base becomes your clinical trial recruitment pipeline. Your real-world data informs your regulatory submission. Your consumer revenue funds your clinical development. You’re de-risking the regulated path with market-funded R&D.

Timeline: 18-36 months to clearance submission, depending on device classification and predicate pathway.

Who did this well:

Levels raised $12M seed from a16z in 2020, $38M Series A in 2023, and has been methodically building toward this model. They started with CGM-based metabolic insights for wellness users, built a massive dataset (700M+ glucose data points, 60,000+ customers), and are now positioned to pursue clinical applications. Total funding: ~$80M. Revenue exceeded $21M in 2023 with 143% CAGR. They’re explicitly not pursuing FDA clearance for their wellness product but building the data infrastructure that could support a clinical play later.

Dexcom’s partnership with Oura shows how this plays from the acquirer side. Dexcom invested $75M in Oura in late 2024 to integrate glucose monitoring data into the Oura ecosystem. They see Oura’s wellness user base as a distribution channel and data generation engine for their clinical CGM products.

What goes wrong:

The dual-track strategy requires discipline. Companies that try to serve wellness and clinical markets simultaneously with the same product often satisfy neither. The wellness users want simplicity; the clinical buyers want validation. The regulatory pathway demands rigor that can slow consumer iteration. Pick which track is primary and sequence the other.

The TEMPO Wild Card

Four days before the General Wellness guidance dropped, FDA started accepting applications for something potentially more important: the TEMPO pilot.

What it is: Technology-Enabled Meaningful Patient Outcomes (TEMPO) is a voluntary pilot where FDA will exercise enforcement discretion for up to 40 uncleared digital health devices, allowing them to be used in real-world clinical settings while collecting performance data. It runs alongside CMS’s ACCESS model, which provides Medicare reimbursement for technology-enabled chronic disease care.

The math: FDA will select approximately 10 devices in each of four categories:

• Early cardio-kidney-metabolic (prediabetes, prehypertension)

• Cardio-kidney-metabolic (diabetes, heart failure, CKD, hypertension, obesity)

• Musculoskeletal (chronic low back pain, knee osteoarthritis)

• Behavioral health (depression, anxiety)

Why this matters: If you get into TEMPO, you can deploy an uncleared device to Medicare patients under clinical supervision while generating the real-world evidence you’d need for eventual clearance. CMS pays providers for using your device. You get clinical data. You get revenue. You get regulatory pathway de-risking. All simultaneously.

The timeline is brutal: Statements of interest opened January 2, 2026 (four days ago). The ACCESS model interest forms are due April 1, 2026. The program is expected to begin July 2026.

What this means for your strategy:

If you’re pursuing Clinical Onramp: TEMPO is potentially the best thing that’s happened to your company. Instead of burning runway on validation studies before clearance, you could be generating revenue and evidence simultaneously. The catch: you need to move immediately. The application window is open now.

If you’re pursuing Consumer Scale or Enterprise Wellness: TEMPO probably isn’t for you. The devices must be intended for clinical use under physician supervision, which doesn’t fit pure wellness positioning. But watch the companies that get selected. They’ll be your competitors in 18-24 months with real-world evidence you don’t have.

If you’re a wellness company considering a clinical pivot: TEMPO changes the math on when to pivot. Previously, you’d build wellness traction first, then pursue clearance. Now, if your product fits a TEMPO category, you might pursue TEMPO selection first, use that to generate clinical evidence and revenue, then layer wellness positioning on top.

The competitive implications:

40 companies will get a head start on clinical evidence generation with FDA blessing and CMS payment. Everyone else in those disease categories will be playing catch-up. If you’re building anything related to diabetes, hypertension, heart failure, CKD, obesity, chronic pain, or behavioral health, you should be evaluating whether TEMPO is the right path.

What to do this week:

1. Read the Federal Register notice (FDA-2025-N-6461)

2. Assess whether your product fits one of the four clinical categories

3. If yes, talk to regulatory counsel immediately about submitting a statement of interest

4. If you’re not ready for TEMPO, understand that 40 competitors may be

The General Wellness guidance and TEMPO together represent a fundamental restructuring of the digital health regulatory environment. The wellness guidance lowers the floor. TEMPO creates a fast lane for the ceiling. Companies that understand both have options that didn’t exist a month ago.

Evidence Timing Question

The guidance makes one strategic decision more explicit: when to invest in validation.

Your investors will have a point of view on this. Consumer Scale is faster to signal - users, engagement, retention all show up in months, not years. From a portfolio perspective, they’d rather you find out quickly whether anyone wants your product than spend 18 months and $500K building clinical credibility for something that doesn’t have pull.

They’re not wrong. If you’re still searching for product-market fit, evidence investment is probably premature. The guidance gives you room to iterate without regulatory risk. Use it.

But if you already have PMF signals - users love it, retention is strong, word of mouth is working - then evidence becomes a defensibility investment. You have something worth protecting. Validation data, clinical advisors, and published studies are what separate you from the 30 competitors who will enter the market now that the regulatory ambiguity is gone.

The problem is that most founders think they have PMF before they actually do. And most investors assume you don’t, regardless of where you actually are.

Have the conversation directly: “Given where we are on product-market fit, when is the right time to invest in validation?” Don’t let the decision happen by default because the guidance made it easy to skip.

What Happens When Everyone Else Reads This Guidance

The guidance doesn’t just help your company. It helps everyone.

What happens next:

Short-term (0-12 months): Expect 20-50 new wellness wearable companies to announce products that would have been regulatory gray zones before. Many will be undifferentiated. Marketing noise increases. Consumer confusion increases. Enterprise buyers become more skeptical, not less, because they can’t distinguish quality.

Medium-term (1-3 years): Market shakes out. Companies with actual validation data and clinical credibility pull ahead. Companies relying solely on “FDA doesn’t regulate us” positioning struggle to differentiate. Category leaders emerge in specific verticals (metabolic, cardiovascular, sleep, stress).

Long-term (3-5 years): Consolidation. The 3-5 credible players in each vertical get acquired or reach scale. The rest either pivot, get acqui-hired, or shut down. Medical societies publish position statements that narrow what claims are supportable. The regulatory environment tightens as FDA observes market behavior.

Defensibility in a crowded market:

Since the regulatory moat just got lowered for everyone, other moats matter more:

• Data moat: Longitudinal data from engaged users is hard to replicate. Oura has 700M+ data points. Levels has 700M+ glucose readings. New entrants start at zero.

• Brand moat: Consumer trust takes years to build. Whoop’s athlete community, Oura’s sleep authority, Levels’ metabolic health positioning were built through consistent execution, not marketing spend.

• Clinical credibility moat: Published validation, clinical advisory relationships, medical society visibility. This is where the guidance actually increases defensibility for those who invest.

• Integration moat: Partnerships with platforms (Apple Health, Google Fit), clinical systems (Epic, Cerner), and other devices (Dexcom-Oura partnership) create switching costs.

The companies that invested in these moats before the guidance are now better positioned. The companies that were waiting for regulatory clarity to start building have more competition and less differentiation.

How to Prepare for VC Questions

If you’re getting evaluated by a VC post-guidance, here’s what separates the thoughtful from the naive:

Question 1: “Walk me through your claim strategy.”

Good answer: “We’ve mapped every claim to the guidance language. Here’s our wellness claim framework, here’s what we can’t say, here’s how we train the team on boundaries.”

Bad answer: “Our lawyers said we’re fine.” They haven’t thought about it.

Question 2: “What’s your validation story?”

Good answer: “We did internal validation showing X accuracy against Y reference. We have third-party testing scheduled for Q2. Here’s the documentation we share with enterprise buyers.”

Bad answer: “The underlying sensor is validated by our component supplier.” They’re borrowing credibility they don’t own.

Question 3: “Which buyers require what evidence?”

Good answer: “Consumer doesn’t need much. Wellness brokers want engagement data, and we have it. Enterprise employers want published validation, and we’re working toward it. Health systems want clearance, and that’s our 24-month roadmap.”

Bad answer: “We’re focused on consumer right now, we’ll figure out enterprise later.” They don’t have a path to the higher-margin segments.

Question 4: “What’s your clinical advisory situation?”

Good answer: Names a specific advisor, explains their domain relevance, describes actual engagement (not just logo rights).

Bad answer: Lists five impressive names with no explanation of what they actually do. Advisory board theater.

Question 5: “How do you think about medical societies?”

Good answer: “The AHA/ADA/etc. guidelines define what claims we can make. We monitor them. Our advisor has relationships there. We’re presenting at [conference] next year.”

Bad answer: Blank stare. They don’t know this is a thing.

Risk Mitigation By Stage

Not all risks are addressable at every stage. Here’s what you can control:

Seed Stage (Mitigatable)

• Claim compliance: Fix it now, it’s cheap

• Basic validation documentation: Build the habit early

• Clinical advisor: One good one is affordable

Seed Stage (Accept as Market Risk)

• Medical society guideline shifts: You can’t influence this yet

• Category trust erosion: Sector-wide, not company-specific

• Regulatory devolution complexity: Build awareness, not infrastructure

Series A (Mitigatable)

• Validation depth: Invest in studies that satisfy target buyer segments

• Liability infrastructure: Terms of service, adverse event tracking, documentation

• FTC exposure: Substantiation files for all claims

Series A (Accept as Market Risk)

• Incumbent advantages: They have relationships you can’t replicate quickly

• Buyer fragmentation: Navigate it, don’t try to solve it

Series B+ (Mitigatable)

• Medical society relationships: Now you have resources to invest

• Published evidence: Peer-reviewed validation becomes achievable

• Regulatory optionality: Clearance pathway if clinical segment is attractive

The Medical Society Playbook

The guidance says disease-related wellness claims must be grounded in “peer-reviewed scientific publications or official statements made by healthcare professional organizations.” That makes AHA, ADA, AMA, and specialty colleges de facto regulators of what claims you can make.

Companies with relationships there have structural advantages. Here’s how to build them, staged appropriately:

Seed stage: Don’t prioritize this. Your job is product-market fit. A $2M seed should go toward product, users, and basic validation. Medical society relationships are a distraction at this stage. The exception: if your clinical advisor already has society relationships, use them passively. Don’t spend cash on it.

Series A: Start visibility

• Submit abstracts to present research at society conferences (AHA Scientific Sessions, ADA Scientific Sessions, ACC Annual Meeting)

• Conference registration and travel for your clinical advisor: $3-5K per conference

• Poster presentations are achievable for early-stage companies; oral presentations require stronger data

• Goal: Get your company name and data in front of the research community

Series B: Build credibility

• Fund a small investigator-initiated study at an academic medical center with society-connected PIs

• Typical pilot study: $50-100K for a 50-100 person validation study

• Target institutions where faculty serve on society guideline committees

• Publish results in society-affiliated journals (Circulation, Diabetes Care, JAMA Cardiology)

• Goal: Generate peer-reviewed evidence that can be cited in guidelines

Series C+: Develop relationships

• Sponsor educational sessions at society conferences (non-promotional, CME-eligible)

• Join society corporate councils or industry liaison programs where available

• Support research initiatives that match society priorities

• Hire or retain advisors who serve on guideline committees

• Goal: Be in the room when guidelines are discussed

This is a long game. The founders who start visibility work at Series A will have credibility by Series C and relationships by the time they’re competing for enterprise deals against incumbents. But don’t let this distract from the core job at each stage.

The Structural Reality (Why This Matters)

For those who want the “why” behind the playbook:

Regulatory devolution is real. The FDA guidance pushes evaluation downstream to buyers. This isn’t deregulation. It’s fragmentation. We saw the same pattern with AI governance rollback in 2025: federal standards disappear, state requirements and buyer-specific demands multiply. The companies that built compliance infrastructure before the rollback were advantaged. Same pattern applies here.

Medical societies now matter for regulatory positioning. The guidance says disease-related claims must be grounded in professional society guidelines. That makes AHA, ADA, AMA, and specialty colleges de facto regulators of what claims you can make. Companies with relationships there have structural advantages: early warning on guideline changes, ability to surface favorable evidence, credibility signals buyers recognize. This is a long game. You can’t build these relationships in a quarter. But founders who start now will have moats in 3-5 years.

The market will stratify. Credibility leaders will own enterprise and clinical segments. Consumer scale players will build real subscription businesses. Fast followers will compete on price in a commoditizing market. All three are viable. The mistake is trying to be all three simultaneously with seed-stage resources.

The One Bet I’d Make

If I had to deploy $10M into this thesis today, I’d look for:

A company pursuing the Clinical Onramp strategy with:

• Founder team that combines consumer product skills with regulatory experience

• Product in a category where wellness data has clear clinical utility (metabolic health, cardiovascular, sleep)

• Early consumer traction proving engagement (10,000+ users, 60%+ monthly active)

• Validation roadmap designed for eventual 510(k) or De Novo

• At least one clinical advisor with relevant society relationships

• Data architecture that supports both consumer features and regulatory submission

The bet: wellness traction de-risks the clinical path while consumer revenue funds it. If clearance succeeds, you own both markets. If it doesn’t, you still have a consumer wellness business.

That’s asymmetric.

The Bottom Line

The guidance is good for founders. It removes ambiguity, lets you sequence spending against traction, and opens markets that weren’t clearly accessible before.

But it’s not a free pass. The regulatory floor is clear. The commercial ceiling depends on what you build.

The founders who win will:

• Pick a strategy and execute it (not hedge across all three)

• Build evidence matched to their target buyer segments

• Start clinical advisory relationships early, even if lightweight

• Document everything (validation, claims rationale, adverse events)

• Understand that regulatory permission is not commercial permission

The window is open. Now you know how to climb through it.

If you’re working through this for your company, or you’re an investor diligencing a wellness deal, I do this work: regulatory assessment, commercial strategy, enterprise readiness. Reach out at arvita (at) vahanalabs.ai.

Arvita is the Founder of Vahana Labs, helping healthtech and AI startups navigate from pilot to enterprise scale. She advises Alchemist Accelerator and The Batchery, and previously held VP-level roles at in Product, Regulatory, and Privacy, launching 30+ regulated AI-enabled products.

VCs are publishing “7 ways to win in AI” decks. Analysts are drawing category maps. Founders are trying to reverse-engineer their product strategy to fit one of them.

But here’s the problem: almost all of these frameworks are useless if you’re actually building product.

They’re written for capital allocators, not operators. They’re good for board slides, but not for deciding what to prioritize on Monday morning.

If you're a CPO, founder, or head of product, you need something else entirely: a clear-eyed way to decide where to go deep, where to say no, and how to build something that survives commoditization.

That’s what I’ve been thinking about lately.

Why the Classic Frameworks Break Down

Most AI strategy write-ups offer some version of this list:

1. Foundational infrastructure (OpenAI, NVIDIA)

2. Vertical AI apps (Abridge, Harvey)

3. Full-stack AI-native companies

4. Incumbent workflow automation

5. M&A for automation

6. M&A for distribution

7. Complements to AI (data, talent, compute, energy, etc.)

It’s a neat taxonomy, if your job is to allocate across categories.

But if you’re building, launching, and scaling product, these categories don't help. They hide the real questions:

• Where can we actually build a moat?

• What’s defensible vs. just convenient?

• What value do we keep if the model gets 20% better tomorrow?

What I Believe as a Product Strategist

Most AI companies will not be defensible. The winners will be the ones who acknowledge that and build accordingly.

Here’s the core thesis I’m operating from:

• The best models will become commodities.
  Everyone will have access to 90% of the capabilities.

• Workflow integration isn’t inherently defensible.
  It’s sticky only if it also creates friction, trust, or switching cost.

• Most “data flywheels” are fake.
  Usage data ≠ proprietary advantage.

• Interface ownership is rare.
  Most companies will win by integrating into someone else’s interface not by creating a new one.

3 Strategic Product Models That Still Matter

Instead of 7 categories, I think in terms of 3 overlapping strategies. But here's the key difference: none of them are inherently defensible. You have to design them that way.

1. Deep Workflow Integration (with a Moat)

This is where most vertical apps are playing: apply AI to a specific high-value workflow.

But most of these aren’t sticky. If you're just automating tasks, anyone with a better model or prompt tomorrow can replace you.

What makes a vertical AI app defensible is:

• Regulatory or compliance complexity (e.g., FDA, HIPAA, FINRA)

• Multi-stakeholder lock-in (e.g., hospitals, payers, patients)

• Embeddedness in operational workflows (not just UI surface area)

• First-party data that others can’t get

What it’s not:

• A slick copilot

• A ChatGPT wrapper with templates

• A dashboard that summarizes Slack threads

Workflow depth is only an advantage if the cost to rip you out is greater than the value of a better model.

Example: Flatiron Health Flatiron built software to integrate deeply into oncology practices, serving oncologists, billing staff, and pharma sponsors. It didn’t just automate documentation — it became the source of truth for clinical and operational workflows. Their regulatory-grade data model, paired with EMR integration, created a moat far stronger than any model output could.

Workflow Defensibility Checklist
Ask:

• Does this workflow involve regulated data or audit trails?

• Do users modify their behavior to accommodate the product?

• Would 3+ stakeholders need to change behavior to switch tools?

• Do users rely on the output to make high-consequence decisions?

If not, it’s probably convenience, not defensibility.

2. AI-Operationalized Full Stack

Instead of selling tools, you become the provider. You don’t automate underwriters, you become the AI-native insurer.

This works best when:

• The industry has high labor costs, slow cycles, or manual bottlenecks

• You can show radically better time-to-value or cost-to-serve

• You design ops around what AI can do, not what humans used to do

But even here, the AI isn’t the moat. The moat is:

• Regulatory permission to operate

• Trusted brand for sensitive decisions

• Distribution channels you own (vs. rent)

• Economic structure that scales with volume

You're not winning because you're “AI-native.” You’re winning because you redesigned the business to take full advantage of AI’s operating leverage.

Forget the venture fantasy: most full-stack winners will be boring businesses with lower cost structures and faster iteration cycles.

Example: Recursion Pharmaceuticals Recursion is reimagining drug discovery by operating as a full-stack biotech company. They generate proprietary biological datasets and train machine learning models on that data, all under one roof. Rather than selling AI tools to pharma, they became the pharma company, reducing time and cost to discover novel therapeutics.

3. Strategic Integration, Not Interface Ownership

There’s a seductive fantasy that some startup will become the “OS of work” with an AI copilot UI. But most users don’t want a new OS. They want their existing tools to work better.

Instead of owning the interface, win by:

• Being the best plugin, not the best app

• Making someone else’s interface indispensable because of you

• Embedding in systems of record, not fighting them

Interface control is a nice-to-have. Frictionless value delivery is not.

Example: Doximity Doximity integrates into the daily workflows of physicians with tools for secure messaging, e-fax, telehealth, and scheduling. It doesn’t compete with the EHR, rather it works alongside it, making key tasks faster and simpler. Because it's embedded into how providers already work, it's sticky without demanding workflow change.

Rethinking Defensibility: What Product Teams Can Actually Build

Most AI features are easy to clone. So rather than betting on novelty, product teams should focus on:

How to Measure Trust as a Feature

• % of users who override or correct outputs

• NPS / CSAT on “confidence in results”

• Average time-to-trust: # of sessions before users adopt automation

• Escalation ratio: manual rework vs. automatic approval

Product-Market Fit for AI Feels Like…

• Users stop double-checking results

• Teams ask to expand usage to new workflows

• Support tickets shift from “why is this wrong?” to “can it do more?”

• Usage without prompts or nudges increases over time

Roadmapping in a Commoditized World

• Plan for model obsolescence every 6 months

• Tie features to workflows, not model novelty

• Build scaffolding to swap models without UX breaks

• Ship moat before polish: embeddedness > delight

Timing Is (Almost) Everything

Your product strategy isn’t just about what to build, it’s also about when. Most AI companies will fail because they build either:

• Too early (market not ready, users not educated)

• Too late (incumbents have copied the playbook)

Here’s a quick framework:

No Moat? Build Like It.

Most companies in this wave will not have durable moats. That’s not failure, it’s the starting condition.

Design for:

• Default usage

• Workflow entrenchment

• Distribution you don’t have to buy

• Switching costs that aren’t model-dependent

You’re not here to protect a clever feature. You’re here to become part of the system before someone else does.

“We need to value our scientists’ time. The agency-wide deployment of these [AI] capabilities holds tremendous promise in accelerating the review time for new therapies.”
— FDA Commissioner Martin A. Makary

The headline was modest enough: completion of an AI-assisted scientific review pilot and a timeline to scale across all FDA centers by June 30. The regulator is modernizing faster than most vendors. Are you ready to explain your PDFs to a machine?

But buried in the release was a shift in tone that suggests a new phase of operational urgency:

“This is not theoretical. This is not a panel discussion. This is happening, now.”

For those of us who’ve been building regulated products, navigating multi-month review cycles, reviewer variability, and fragmented evidence pipelines, this is something new.

Not a framework. Not a whitepaper. An early-stage system. Piloted within the FDA. With a stated intent to expand.

What This Changes

The implications are wide-reaching, but I want to focus on three audiences: product leaders, regulatory leaders, and those of us building the tools they rely on: eClinical platforms, eQMS systems, regulatory intelligence tools, and evidence-generation infrastructure.

This isn’t the FDA dabbling in innovation. Between the FHIR Request for Comment and the generative AI rollout, the agency is laying down a roadmap for the next decade of evidence processing: structured in, machine-augmented review out. That shift should influence how we build everything: from source systems to submission platforms to the documentation we hand over.

For Product Leaders: Your Submission Pipeline Just Became a Product

If the FDA is using generative AI to reduce review timelines from months to weeks, your team’s ability to generate submission-ready data now sits in the critical path of speed-to-market. A few implications:

Documentation has always mattered, but now it’s infrastructure. In a machine-reviewed world, outputs must be structured, traceable, and durable enough to survive automated parsing and cross-system scrutiny. What used to live in slides or scattered comments now needs to be systematized.

Submission strategy and product strategy are converging. Your regulatory partner can no longer be brought in at the beginning and then again at the 11th hour. The way a feature is logged, the metadata captured, the internal flags surfaced, these are now product decisions with regulatory impact.

"Explainability" isn't just for models. Can your product outputs be audited? Can the feature logic be traced through a version-controlled configuration layer? If not, you may not be ready for a world where the reviewer reads faster than you can revise.

Example: In a future AI-assisted review, a Summary of Safety and Effectiveness Data (SSED) might be parsed not for completeness alone, but for internal consistency across labeling claims, clinical outcomes, and prior submissions - surfacing mismatches in minutes or hours that a human reviewer might not catch until late in the process.

For Regulatory Leaders: Your Role Is About to Change

This is the beginning of a new era, one where the regulator has an AI stack and expects you to have one, too.

Review timelines may shorten, but expectations won’t. Faster processing doesn’t mean lower standards, it means less tolerance for disorganized submissions, weak narratives, or vague justifications. Your role will move upstream, shaping structure, taxonomy, and messaging before the first page is turned.

You’ll need to run internal reviews at agency speed. If FDA reviewers can complete work in days that once took weeks, sponsors will need to show they’re keeping pace, both in tooling and in readiness.

AI policy is now operational. You’re not responding to guidances anymore. You’re responding to infrastructure. Understanding how the agency’s tooling ingests, synthesizes, and flags data is now part of the job.

But a note of caution: AI systems aren’t infallible. FDA reviewers may still face false positives, bias amplification, or edge-case data that require deep human judgment. The transition will be uneven across centers and product types. Sponsors should expect variability in how quickly and effectively AI is adopted across divisions.

For Vendors: Your Platform Is Now Part of the Regulatory Stack

If you’re building eClinical, eQMS, submission automation, or evidence infrastructure tools, the FDA’s pilot signals a shift in what your customers may soon expect—and what the agency could begin requiring over time.

If your product helps generate, structure, analyze, or manage evidence, whether for trials, safety, labeling, quality, or submissions, your role just changed.

This includes:

• Real-world data & synthetic control platforms

• PV automation and signal detection tools

• Labeling and CCDS systems

• Document automation for regulatory teams and MSLs

• Model explainability, algorithm lifecycle, and SaMD documentation

• Structured content authoring tools for SPL and global submissions

In short: if you help operationalize or submit evidence, you're now upstream of an AI-augmented reviewer and your software must support that shift.

Strategic Expectations Have Shifted

Across categories, stakeholders will now expect:

Structured outputs by default. Unstructured exports and flat PDFs won’t hold up to AI-driven review. Your platform needs to output data in ways that are traceable, parsable, and versioned.

Simulation and feedback loops. Customers will increasingly expect tools to simulate review workflows, surface likely deficiencies, and “score” submissions before they hit the agency.

Interoperability with regulatory systems. The FDA is building a secure, unified genAI stack across centers. You don’t need inside access, but you do need alignment on structure, semantics, and explainability.

Support for high-trust narratives. Whether your tool generates clinical summaries, model reports, or labeling documentation, those narratives must be robust under both human and algorithmic scrutiny.

AI governance readiness. If your tool includes genAI or supports model submission, customers will demand controls, logs, and auditable decision flows. “Compliant enough” won’t be enough.

Counterintuitive Takeaways

This isn’t just about speed and automation, it’s also about subtle power shifts and design demands. A few points that might catch teams off guard:

Speed compresses margin for error. Faster reviews don’t always mean faster approvals, just less time to get your house in order.

Persuasion may weaken. AI-assisted reviewers won’t give you the benefit of the doubt. Ambiguities get flagged, not overlooked.

Standardization could obscure edge cases. FDA’s uniform tooling may streamline common pathways, but novel or blended products may struggle to fit without over-explaining.

You’re designing for machines now, too. Submissions aren’t just for human reviewers, they’re now interactive content for machine interpreters.

Guidance won’t lead this shift, operations will. The rollout precedes the paperwork. Policy updates will trail behind lived expectations.

What to Do Next, Whether You’re Building or Buying

No matter your role in the ecosystem (sponsor, vendor, service provider, or regulator-adjacent) this is a moment to reset how you think about evidence readiness.

1. Inventory your evidence systems. What documents, data assets, or artifacts are being generated today that will need to be structured or referenced downstream? Map these touchpoints now.

2. Run an AI-review dry run. Take a recent submission component like a protocol synopsis or risk management plan and test it using a language model. Does it raise consistency issues? What metadata is missing?

3. Establish a product-regulatory handshake. If you're in product, sit with regulatory leaders and ask how outputs from your system translate into evidence. If you're in regulatory, push upstream.

4. Audit for auditability. What’s your current level of traceability across submissions? Can your systems explain how a given line in a submission was derived?

5. Monitor implementation, not just announcements. Pay attention to how the AI rollout is playing out center-by-center. Some groups will lead, others will lag. Expect inconsistencies and build flexibility into your strategy.

6. Update your roadmap. Whether building internally or evaluating vendors, prioritize capabilities that support: structured data, explainability, review simulation, system interoperability, and audit traceability.

Final Thought

A few years ago, the most provocative thing you could say in a product meeting was:
“What if we made the FDA reviewer experience as seamless as the user experience?”

Today, the FDA is doing exactly that from the inside out.

This isn’t about leaving sponsors behind. It’s an invitation to step into a new model, where clarity, consistency, and shared tools let both sides move faster together.

So the question isn’t whether you can match their pace.
It’s whether your product, process, or platform is ready to become a trusted contributor to a faster, smarter, more transparent regulatory system.

At a glance, it looks technical: “Exploration of HL7 FHIR for Use in Study Data Created from Real-World Data Sources.” But if you’re building health AI, EHR integrations, decentralized trials, or real-world evidence platforms, this is something bigger.

It’s a signal.

It shows that regulators are starting to align on what tomorrow’s evidence pipeline might look like, not as static PDFs and custom extracts, but as structured, machine-readable, and interoperable data directly from the systems that already power care delivery.

Why This Matters: It's Not Just an IT Standard

HL7 FHIR (Fast Healthcare Interoperability Resources) is already entrenched in healthcare delivery. But this docket opens the door to formal acceptance of FHIR-based clinical research submissions, particularly when study data is drawn from real-world sources like EHRs, registries, and digital health tools.

If successful, this could lead to:

• Streamlined regulatory submissions for trials leveraging real-world data

• Greater harmonization between clinical care and research infrastructure

• A shift in who can produce regulatory-grade evidence (and how fast they can do it)

This isn't just about format compliance. It's about changing the cost structure and timelines of drug and device development.

What the FDA Is Asking For

The FDA’s docket poses questions about:

• The feasibility and challenges of submitting clinical data derived from RWD sources using FHIR

• Whether current standards (like USCDI v3) are sufficient for research purposes

• How nationwide data exchange frameworks (like TEFCA) could support research

• How this aligns with HHS and ONC health IT interoperability policies

The agency isn’t mandating anything, yet. But it’s clearly signaling an interest in shifting from ad hoc, static submissions to dynamic, standards-based data exchange.

This is the policy setup that could enable:

• Lower-friction regulatory-grade evidence from academic centers or integrated delivery networks

• Real-time safety reporting and adaptive trials fed by live EHR connections

• Smaller companies to “punch above their weight” by automating trial data submission workflows

Why This Window Is Rare And Why That Matters

To be clear: FDA opens dockets regularly. Most get polite engagement from trade groups and a few academics, but rarely shift infrastructure. So what makes this one different?

It’s not just that the agency is asking about HL7 FHIR. It’s that they’re inviting public input on whether tomorrow’s regulatory-grade evidence can be built on top of the same standards already powering clinical care.

That’s rare.

Most regulatory innovation happens after data is collected: new frameworks for evaluating endpoints, or new guidance on how to interpret digital biomarkers. This docket goes upstream. It’s about how we structure, transport, and submit evidence in the first place.

And it’s happening at a moment when:

• FHIR is already mandated in clinical systems via the 21st Century Cures Act

• TEFCA is live, creating a potential backbone for multi-site research data exchange

• RWE has momentum, but its data quality still raises skepticism

So yes, this is an early policy signal. But it’s also an invitation:
Can we lower the cost of generating trustworthy evidence? Can we make it easier for more organizations, not just big CROs, to participate in regulated research?

If the answer is yes, then this moment could end up being an inflection point.

Who Should Pay Attention

1. Real-World Evidence (RWE) Platform Companies

If you’re supporting postmarket surveillance, registry enrichment, or safety signal detection (especially with EHR or claims-based data) you need to be ready for FHIR as a submission requirement, not just an ingestion format.

2. EHR-Integrated Clinical Trial Platforms

Companies like Medidata, Veeva, uMotif, and OneSource-aligned collaborators should see this as a potential accelerant the pipeline from EHR to FDA could become dramatically more direct.

3. Biopharma and Medtech Regulatory Teams

Filing with data collected via FHIR will require alignment with evolving FDA expectations for data structure, completeness, and traceability. Regulatory ops leaders should start planning for how to validate, version, and explain data coming from heterogeneous RWD streams.

4. Standards Bodies, Open Source Contributors, and Health IT Vendors

FHIR implementers, SDOs, and health IT vendors now have an opening to build the connective tissue between clinical care data and regulatory submissions, a long-missing piece of the puzzle.

What Builders Can Do Now

1. Track the Docket
   FDA-2025-N-0287 is open for comments. If you’ve got experience collecting clinical-grade data from RWD sources using FHIR, submit feedback. Shape the requirements before they’re locked in.

2. Audit Your FHIR Pipeline
   How many of your endpoints support the right resources (e.g., Observation, MedicationAdministration, Provenance)? Are your data models harmonized to USCDI v3 or higher? Do you log source system provenance? These are likely to become review expectations.

3. Map Clinical Concepts to Regulatory Contexts
   For teams collecting data on adverse events, treatment response, or medication adherence via digital platforms: align your data elements with regulatory-grade vocabularies (e.g., MedDRA, SNOMED CT, LOINC). Don't assume a payer-facing data structure will suffice for FDA. Create provenance and versioning logic now.

4. Monitor TEFCA's Role in Research
   If “Research” becomes a formally recognized exchange purpose under TEFCA, that could lower access barriers for multisite real-world studies. This has implications for how research networks share data and how sponsors think about recruitment, monitoring, and compliance.

Policy Is Product, Again

This docket follows a clear pattern: like the AdvaMed AI Policy Roadmap, it’s a sign that regulators are creating space for modernization, but expecting industry to show up early.

The upside is huge: lower costs, faster insights, and more inclusive evidence development.

But the risk is clear too: if only well-resourced players can afford to adapt, we re-entrench the same inequities we claim we want to solve.

So whether you’re an early-stage RWE tool, a regulatory ops leader, or a digital health builder helping sponsors collect decentralized trial data, now is the moment to engage.

Let’s Be Clear: This Is a Long Play, But One Worth Watching Now

We need to be honest about timing. Even if the FDA moves forward on incorporating FHIR into its regulatory submission infrastructure, meaningful impact on day-to-day product work is likely 12–36 months out, depending on your position in the ecosystem.

This isn’t a Q3 pivot. It’s a chance to get ahead of structural change, or at least avoid being surprised by it.

That said, implementation won’t be easy. The technical lift to align real-world data with regulatory vocabularies and traceability standards is substantial. Many EHR systems still struggle to provide consistent FHIR output. And few AI or RWE platforms today track provenance at the granularity regulators will require.

But for companies whose business model depends on trustworthy, reusable evidence, this is worth building toward.

Product Team Decision Guide: Should You Prioritize This?

Here’s a practical guide for product and strategy leaders deciding how to respond:

Engage Now If:

• Your platform supports clinical trials, RWE, or post-market surveillance for FDA-regulated products

• You already collect or structure clinical-grade data using FHIR

• Your buyers are regulatory, HEOR, or medical affairs teams seeking submission-ready formats

• You’re designing infrastructure for decentralized or multi-site studies

Action: Submit feedback to the docket. Begin auditing your FHIR endpoints. Align internal data dictionaries with SNOMED CT, MedDRA, and USCDI v3.

Monitor Closely If:

• You ingest RWD (EHR, claims, etc.) but don’t yet produce submission-grade outputs

• Your customers are clinical researchers or health systems, not sponsors

• You’re pre-PMF or focused on provider workflow integration, not regulatory alignment

Action: Track the docket outcome and future guidances. Consider integrating provenance tracking and FHIR alignment into your mid-term roadmap.

Wait If:

• You are building non-clinical tools (e.g., scheduling, billing, patient education)

• Your company does not handle structured clinical data or make regulatory claims

• Your data is not intended to support submissions or clinical decision-making

Action: Focus on core product value. Revisit if you expand into research or regulated clinical pathways.

Final Thought

This isn’t the FDA dictating a new requirement.

It’s the agency saying, “We’re willing to modernize. Show us what’s possible.”

That’s rare. And for the teams thinking long-term - those building not just AI models or apps, but infrastructure for evidence itself - this is your early signal.

Don’t overcorrect. But don’t sleep on it either.

Because if your product plays any role in collecting, structuring, or translating clinical insight into regulated impact, the future won’t just reward the technically correct.

It will reward the interoperable, trusted, and submission-ready.

The docket is open. So is the architecture of tomorrow’s evidence pipeline.

This primer offers an entry point for teams approaching their first regulatory submissions or seeking sustainable reimbursement paths, when policy engagement shifts from optional to existential.

The recent AI Policy Roadmap from AdvaMed lays out how U.S. regulators are thinking about AI-enabled medical devices, from reimbursement for algorithm-based services to continuous learning model updates. While it's written in the careful tone of policy professionals, it offers product leaders something more: a mirror.

It shows us what will be possible. And what could be prevented - not by malice, but by inertia, omission, or misalignment.

This isn't a call to play politics. It's a call to engage early and thoughtfully, because policy done right doesn't just create markets. It expands access. It drives safer, earlier, more equitable care. While specialized regulatory expertise remains essential as you scale, these foundational concepts will help you build with the system, not just within it.

1. The Bar Is Being Set, So Let’s Set It With Intention

When CMS creates a pathway for reimbursing AI-based healthcare services, it has to define what qualifies. Do we require demographic bias audits? Ongoing performance monitoring? FDA-approved change control plans?

These aren’t just technical checklists. They shape who gets to serve patients and how safely. Thoughtful policy engagement means ensuring those standards reflect clinical validity, patient safety, and inclusivity, not just what incumbent vendors already do well.

When we advocate for a high bar, we’re not gatekeeping, we’re safeguarding.

2. A Real-World Example: From Lobbying to Lifesaving

Consider the case of digital breast tomosynthesis (DBT), an advanced imaging technology for breast cancer screening. Initially, Medicare didn’t reimburse for DBT, despite growing clinical evidence of its effectiveness. It took coordinated policy engagement by radiology societies, patient advocates, and technology vendors to change that.

Once reimbursement was established, access expanded rapidly, particularly for underserved populations. One 2020 study showed DBT significantly reduced recall rates and increased cancer detection in community settings.

Policy alignment didn’t just benefit the vendors. It helped detect cancer earlier and more accurately, for more people.

3. CPT Codes Are Cultural Codes

When a procedure gets a CPT code, it becomes real. Not just to billing systems, but to clinicians, administrators, and procurement teams. That’s why advocating for procedural codes for AI-generated clinical outputs is about more than revenue. It’s about recognition.

But we have to be careful. If those codes only reflect the workflows of academic hospitals or high-resource centers, we risk excluding care models that reach rural, lower-income, or non-English-speaking populations.

Inclusive policy doesn’t just mean fair access to innovation. It means ensuring that the definition of innovation isn’t exclusively written by and for the privileged few.

4. The Tension: Speed vs. Inclusivity

Policy takes time. Working through standards bodies, public comment periods, and stakeholder engagement is slow. Startups, meanwhile, live on quarterly runway and fast iteration.

This tension is real. But it’s not unresolvable.

Here’s one model: dual-track execution. While your GTM team pursues immediate commercial paths (e.g., pilot contracts, academic partnerships), your product and policy leads engage in shaping the long game, helping define what “safe,” “effective,” and “reimbursable” will mean in three years.

It's about meeting the present while shaping the future, not waiting for one to finish before starting the other.

5. A Better Kind of Moat

We often think of moats as being about exclusion. But in healthcare, the best moats are the ones built from shared values, the kind that say: our technology is trustworthy, our practices are evidence-based, our models perform across populations, and our commitment to safety is structural, not situational.

That kind of moat isn’t won in a sprint. It’s earned in how you show up to the table - early, consistently, and with both strategic and ethical clarity.

6. Operationalizing Policy Engagement: A Tactical Guide

Good intentions don’t get you reimbursed. Strategic hustle does.

Here’s how small teams can take real steps toward payer alignment, even without a policy department or a 6-figure budget.

6.1 Just start

• Find the 2–3 most relevant reimbursement signals for your product:
  MAC draft LCDs, CMS rules, CPT code proposals, private payer policy updates.

• Set up tracking alerts on CMS.gov, CPT Editorial Panel, and your regional MAC websites.

• Prep templates now for submitting comments, don’t wait until you're scrambling.

• Prioritize documents where you have the highest likelihood of influencing outcomes

  • Regulators reference your clinical domain in draft guidances.

  • You’re already cited in tech assessments or white papers.

  • KOLs you work with are on FDA/CMS committees.

  • Early payer pilots are showing traction in your category.

  • Your real-world evidence is being referenced publicly.

You don’t need a policy team. You need a calendar, a doc template, and 90 minutes a month to stay on top of it.

6.2 Build Light Engagement Infrastructure

• Run quarterly reimbursement workshops across Product, Clinical, and Legal.

• Output: one-pager mapping payer requirements to product features, evidence, and milestones.

• Track 3 things:

  • Relevant codes and payment pathways

  • Clinical evidence gaps (what payers will ask for)

  • Economic model components you still need to build

6.3 Measure the Right Kind of ROI

Before revenue, look for leading indicators:

• Have any payers engaged with you (even for a pilot)?

• Have you been cited in a draft coverage memo?

• Do your outcomes line up with payer language (e.g., avoided procedures, reduced readmissions)?

Then quantify:

• Cost of delay from reimbursement uncertainty

• Time saved from early alignment with payer expectations

• Product decisions made because of reimbursement feedback

Final Thought

The rules of healthcare are being rewritten for the AI era. The question is not whether we like that. The question is whether we’ll participate in that process with humility and purpose, or let it be written without us.

Because the ultimate goal isn’t just market access. It’s better care, delivered more safely, to more people, sooner.

If we can help shape the policies that enable that future thoughtfully, transparently, and inclusively then we’re not just building moats.

We’re building systems that deserve to last.

In traditional product development, we express what we want through detailed specifications, mockups, and engineering tasks. But with AI capabilities, something interesting happens: the prompt itself becomes our primary specification document.

This represents a significant change in how we create products:

--Rather than controlling behavior through explicit code paths, we're guiding AI systems through natural language

--The precision and quality of this language directly shapes the user experience

--The prompt functions as a behavioral contract between your intentions and the system's output

Like any good product specification, effective prompts share common characteristics - they must be clear, reusable, thoroughly tested, properly versioned, and have clear ownership within the team.

Product quality now directly correlates with prompt quality. This isn't theoretical - it impacts real user experiences.

Here's a simple but powerful approach for evaluating prompt effectiveness I've seen work well.

Prompt Health Assessment Framework: The 5 Cs

1. Clarity

• Precision in language: Are instructions expressed without ambiguity or conflicting directives?

• Hierarchical structure: Is there clear prioritization of instructions when multiple requirements exist?

• Defined purpose: Does the prompt explicitly state what problem it's trying to solve?

• Measurable outcomes: Are success criteria for the output clearly defined?

2. Constraints

• Boundary conditions: Are limits on scope, content, and topics explicitly stated?

• Output parameters: Are format, length, tone, and style requirements properly specified?

• Safety guardrails: Are there explicit instructions to prevent harmful, biased, or inappropriate content?

• Resource efficiency: Are there controls to manage token usage and computational costs?

3. Context

• Relevant background: Is necessary domain knowledge provided to ground the response?

• User information: Is appropriate user context included to personalize responses?

• Examples: Are high-quality examples provided for complex or nuanced requirements?

• Situational awareness: Does the prompt establish the right environment for the task (e.g., expert role, specific scenario)?

4. Coverage

• Persona validation: Has the prompt been tested across different user segments?

• Input diversity: Has it been validated with various phrasings and question types?

• Edge cases: Have potential failure modes been identified and addressed?

• Cross-validation: Has performance been compared to similar prompts or other approaches?

5. Consistency

• Temporal stability: Does the prompt maintain quality across model versions?

• Reproducibility: Are results consistent when the same input is provided multiple times?

• Cross-instance reliability: Does it perform consistently across different environments or API instances?

• Documentation: Is there clear versioning and change management for prompt iterations?

This isn't just an academic exercise. Teams that neglect prompt quality face real consequences, including:

--Inaccurate or fabricated responses when constraints aren't well-defined

--Unpredictable outputs when context isn't properly maintained

--Unexpected cost increases from unnecessarily verbose responses

What's becoming increasingly clear is that prompts represent a new form of product design. They influence user experience, shape interactions, and introduce potential risks that must be managed.

The most successful product teams are now treating prompts with the same rigor they apply to other critical components - documenting them properly, testing them thoroughly, and establishing clear ownership.

I'm curious about your experiences:

--What additional dimensions would you include in a prompt quality framework?

--Has your organization begun implementing processes for managing prompts systematically?