Philosophy
What I've learned building AI in healthcare
Ten principles from 14 years working on clinical products and AI systems in regulated environments. Each one is something I require from the teams I lead — not just something I think about.
Ten principles
- 01
Evaluate workflows before models.
A model that performs in evaluation still has to fit the workflow. Most AI products fail at the integration point, not the inference point.
Transcarent care navigation → - 02
Human override is a product feature.
The ability to override, escalate, or send back for review is not a fallback — it's a core capability that determines whether the system deploys.
Authorization states → - 03
Provenance beats confidence scores.
Knowing where a recommendation came from — and what evidence backed it — matters more than a confidence number nobody can act on.
Refract → - 04
Shipping safely beats shipping first.
In healthcare, a premature launch creates downstream costs that dwarf the speed advantage. The unhappy path gets the same engineering as the happy path.
Epic escalation process → - 05
Enterprise trust is earned operationally.
Hospital IT, legal, and compliance teams don't trust models — they trust the operational system surrounding the model. Compliance documentation is a product decision.
Doximity Dialer → - 06
AI products fail more often in integration than inference.
The hard work is fitting into EHR systems, clinical workflows, and regulatory frameworks — not achieving better model accuracy.
Case studies → - 07
The decision the AI feeds into matters more than the AI's output.
When a system harms someone, the question is never 'was the algorithm wrong?' It's 'who owned the decision the algorithm fed into?'
The Crumple Zone → - 08
Governance is a product capability, not a compliance exercise.
Evaluation, monitoring, escalation, and correction should be built into the product — not bolted on after a compliance review.
Ethotechnics → - 09
Correction propagation is the real test of a deployed system.
When the evidence changes, the correction has to reach everything the error touched. If it doesn't, the system was never really deployed — it was just running.
Reconsideration loop → - 10
The unhappy path deserves the same engineering as the happy path.
Defaults before the edge case arrives. Every trigger has a default action, an owner, and a required record — defined before production, not after an incident.
Escalation matrix →
How I work
The artifacts below are what I actually use to run product teams — not templates, but the frameworks and checklists that have survived real use.
Product evaluation framework
How I evaluate whether an AI product is ready to deploy in a clinical setting — workflow fit, compliance posture, clinician adoption, and correction capacity assessed before launch, not after.
View framework → TemplateDecision memo template
One-page structure for documenting product decisions under uncertainty: context, options, tradeoffs, decision, and review conditions. Used so teams can trace why a call was made, not just what was built.
Request template → ChecklistLaunch readiness checklist
Derived from the authorization states and escalation matrix — the conditions that must be true before a system may influence decisions, and the monitoring that must continue after launch.
View checklist → FrameworkPrioritization framework
How to sequence AI features by deployment risk vs. adoption value — shipping the capabilities that build operational trust first, not the ones that look most impressive in a demo.
Request framework →If your organization is building healthcare AI products that must perform in real-world environments — where adoption, governance, evaluation, and measurable impact matter as much as technical innovation — I'd welcome the opportunity to help lead that effort.