A clinician evaluating a new digital health tool rarely asks whether it works first. She asks who's responsible if it doesn't.
Founders get this backwards constantly. They lead with the trial data, the accuracy number, the study that took two years to run. All useful, eventually. None of it answers the question she's actually running through her head: if this tool tells me the wrong thing and I act on it, whose name is on the incident report?
This isn't a question she'll ask out loud on a first call. Most clinicians won't ever say it to your sales team directly, because saying it feels like an accusation before there's even a relationship. She'll just quietly decide the product is too early, or too risky, or "not the right fit right now," and move on. The real reason rarely makes it back to you.
The question that never makes it into the deck
Pitch decks and product pages follow a familiar structure: here's the problem, here's our solution, here's the evidence it works. That structure assumes efficacy is the gate. For a clinician, it's the second gate. Liability is the first.
This is a professional reflex, built over years of training that drills one lesson before any other: you're accountable for what you act on, regardless of what generated the recommendation. A resident learns this on day one of a rotation. An attending relearns it every time a malpractice case comes up at grand rounds. By the time she's evaluating your app, the reflex is automatic.
So when a chronic disease management platform pitches "clinically validated glucose predictions," her next question isn't about the validation study. It's this: if the prediction is wrong and a patient adjusts insulin based on it, who's named in the complaint? You, the patient, or her?
Why a strong efficacy number doesn't clear the bar
A 94% accuracy rate sounds like an answer. It leaves out the part she's actually asking about: what happens in the other 6%.
Does the app flag its own uncertainty, or hand over a confident-looking number with no caveat attached? Is there a human in the loop before a high-stakes recommendation reaches a patient, or does the output go straight through? If the tool is wrong and she never had a chance to catch it, that's a different liability position than if she signed off on every recommendation herself.
Founders read this as a technical detail. Clinicians read it as the entire risk profile of adopting the product.
What "who's responsible" breaks down into
The liability question isn't one question. It's four, and a clinician usually runs through all of them before she'll pilot anything.
Who signs off on the output. Is there a point where a licensed clinician reviews the recommendation before it reaches a patient, or does the tool act on its own? Autonomous action raises the stakes on everything downstream.
What the audit trail looks like. If something goes wrong 8 months from now, can she pull a record showing exactly what the tool recommended, when, and on what data? Without an audit trail, she has no way to show she acted reasonably on the information available at the time.
Where the failure mode is documented. Every tool fails somewhere. She wants to know the company has written down where, specifically, rather than asserting the tool doesn't fail.
What happens when she overrides it. If she disagrees with the tool's recommendation and goes with her own judgment instead, does the system make that easy and unremarkable, or does overriding it mean fighting the interface?
Most digital health content answers none of these directly. It answers a fifth question, the one nobody asked: does the product work well.
The pattern across categories
This shows up differently depending on the tool, but the underlying check is the same.
An AI-assisted diagnostic tool asks a radiologist to weigh a second opinion generated by a model. She's checking more than the model's sensitivity and specificity. She's checking whether a miss by the model, on a case she also missed, leaves her more exposed than working without it at all.
A chronic disease management platform asks a physician to act on data the platform collected outside her clinic. She's checking whether the platform's terms quietly shift responsibility onto her the moment she looks at a dashboard, even for readings she never reviewed personally.
A mental health app asks a therapist to recommend it to a patient between sessions. She's checking what happens at 2am when a user in crisis is chatting with the app instead of a person, and whether that gap is disclosed anywhere she can point to later if a family asks what she knew.
A remote monitoring device asks a cardiologist to trust readings from outside her own equipment. She's checking who gets alerted first when a reading crosses a threshold: her, an on-call service, or nobody until the next scheduled appointment.
A patient-facing app for a chronic condition asks a nurse practitioner to point patients toward it as part of their care plan. She's checking whether a wrong suggestion inside the app, one she never sees or reviews, still gets traced back to her name on the referral.
Five different products, five different clinicians, one identical audit running privately in each case, long before any of them gets a real answer from the vendor.
Why silence reads worse than an honest limitation
Founders sometimes avoid the liability question because there's no clean answer yet. The product is new. Legal hasn't finished the terms. Better, the thinking goes, to stay quiet than raise a concern nobody's asked about.
That's backwards. A clinician who can't find an answer assumes the worst one. Silence on liability reads as "untested," or worse, "known and hidden."
Compare two companies, both new, both with a real but early liability position. One says nothing on the topic anywhere in its content or product pages. The other publishes a plain, specific page: here's what our tool does autonomously, here's what always routes through a licensed clinician, here's what our audit log captures, here's how you'd retrieve it if you needed to. The second company hasn't necessarily solved liability any better than the first. It's just willing to say what it knows, in writing, before anyone asks.
Clinicians notice the difference fast, because it's the same test they run on a research paper: does this cite its limitations, or only its wins.
What belongs in the content, specifically
A liability page doesn't need a legal team's final sign-off to be useful. It needs enough specificity that a lawyer can refine it later, not invent it from scratch.
Name exactly where a human clinician is in the loop, and where the tool acts without one. State plainly what data the audit trail captures and how long it's retained. Describe, in plain language, what the product does when its own confidence is low, rather than implying it's always confident. And say what happens when a clinician disagrees with the output: is overriding it one click, or a support ticket.
Admitting where responsibility sits is a specific, narrow claim. It says who reviews an output, not whether the output is any good. That's the claim she's actually trying to verify, and most digital health content never makes it.
Where this needs to live
None of this works if it's buried in a PDF a rep emails over after the first call. By then, she's already run her private audit and reached a conclusion, most likely without you.
This has to live where her research already happens: a dedicated, linkable page on the site, referenced from the product pages themselves, indexed and findable by anyone searching your company name alongside "liability" or "malpractice" at 11pm after a clinic shift. Publish it the way you'd publish a pricing page: assume someone is reading it alone, with no one from your team in the room to answer follow-up questions, and write it to hold up under that condition.
The same page does double duty with a clinical advisor or KOL you're hoping will put their name behind the product publicly. A specialist with a license to protect will ask the liability question before agreeing to any endorsement, whether or not your team thinks to raise it. Having a clear answer already published makes that conversation shorter, and makes the advisor relationship easier to secure in the first place.
What this costs when it's missing
A digital health company that skips this doesn't lose deals with a clear rejection. It loses them quietly: a pilot that never gets a second site, a champion who goes cold after one internal legal review, a security and compliance sign-off that stalls for reasons nobody explains back to sales.
The cost compounds at fundraising too. An investor's diligence associate reading the same content runs a lighter version of the same check: does this founder understand where the legal exposure sits in their own product, or has that question simply never come up. A founder who can answer it cleanly, in writing, on the website, before anyone asks in a data room, signals the operational maturity a clinical diligence call is designed to surface. A founder who can't tends to get a longer diligence process, not a shorter one.
Answer it before she asks
The liability question isn't rude, and it isn't a sign a clinician doesn't believe in your product. It's the professional habit that keeps her license intact, running on every new tool she considers, whether she says it out loud or not.
Content built for efficacy answers a question she'll get to eventually. Content built for responsibility answers the one she's asking first, quietly, before your sales team is even in the room.