MIT asks the awkward question 🧪, the AMA writes Congress about chatbots ✉️, OpenEHR MCP 🤖
MIT Tech Review is asking whether any clinical AI in production today actually helps patients. The answer was mostly: we don’t know.
“Health-care AI is here. We don’t know if it helps patients” — published April 24 by Antonio Regalado — walks through the gap between deployment volume and outcomes evidence for ambient scribes, diagnostic AI, and triage tools, and frames the gap as the central unanswered question in clinical AI right now. It hit Hacker News this weekend (modest engagement, but the piece itself is the story). External validation for the framing this briefing has been running for months: vendor outcome claims are mostly marketing until somebody publishes a controlled comparison.
😤 Haters
“You can’t run RCTs on every clinical AI tool — the deployment landscape moves too fast.” Agreed, and that is not what the piece is asking for. It is asking for any outcomes data that is not vendor-curated. Time-to-discharge before vs. after scribe deployment. Coding accuracy at one site over six months. Documentation completeness on a defined denominator. The minimum bar is “anything not from the vendor’s own marketing deck.” Most tools cannot meet that bar today.
“This is just MIT being MIT — slow academia critiquing fast industry.” Maybe. But the piece is being read by every CMIO making a 2026-2027 procurement decision. When evidence is the new vendor moat, the vendor that publishes outcomes first eats the procurement cycle. Treat this article as a marketing brief for the AI tool you are building.
💡 80/20: Outcomes data is now the default unanswered question on every AI procurement call. Try: before your next demo of an AI tool — yours or someone else’s — write the one outcomes metric you would want a six-month report on. Send it to the vendor. The ones who already have a dashboard that answers it are a different shortlist than the ones who promise to build one.
→ Full write-up
The AMA wrote three Congressional caucuses about AI mental health chatbots. Physician societies are now in the consumer-AI policy game.
The American Medical Association sent letters to the Congressional AI Caucus, the Congressional Digital Health Caucus, and the Senate AI Caucus urging stronger safeguards for AI mental health chatbots — citing reports of chatbots encouraging suicide and self-harm in vulnerable users, plus the 2024 Congressional hearings on emotional dependency, distortion of reality, and lack of safety protocols. The letters acknowledge upside (access expansion) but argue federal guardrails are now overdue.
😤 Haters
“This is the same physician-society lobbying playbook we’ve seen for a decade — it doesn’t actually change product roadmaps.” It changes product exposure. The AMA on letterhead is the precondition for state attorneys general writing their own letters; one is the precedent, several are a movement. It also changes the diligence packet — every consumer mental-health AI raise from this point forward is going to get a question from investors about safeguard design.
“Mental health chatbots aren’t clinical tools — this is a category mistake.” That is the argument the chatbot vendors will make, and it is partly correct. It is also the argument that did not survive the Doctronic suspension in Utah. The line between “wellness companion” and “decision support” is one screenshot of a model telling a user to stop their SSRI. Build for the clinical case even if you are marketed as the wellness one.
💡 80/20: If you are building any consumer-facing AI that touches a clinical condition, the regulatory ceiling is now visible — and physician societies are putting it in writing before the regulators do. Try: write the one-page safety architecture you would hand a state attorney general. If you can’t, you don’t have one.
→ Full write-up
Midstream Health raised by selling cost reduction, not revenue capture — and got Mount Sinai and CommonSpirit to sign.
Midstream Health — a 2023-founded San Francisco startup — is running a contrarian go-to-market in healthcare AI: most vendors sell revenue uplift, Midstream sells operational and procurement cost-out. Anchor customers are Mount Sinai and CommonSpirit, with Houston Methodist also reported earlier. Co-founder Venkat Mocherla’s framing: for most health systems in 2026, margin protection on the cost side is a bigger lever than capture on the revenue side.
😤 Haters
“Cost-out AI is unsexy and cyclical — it sells today because Medicaid is uncertain and dries up when the budget cycle turns.” Probably true at the macro. But the procurement cycle that runs on cost-out signals also has a longer hold time than the revenue-capture story, because finance buyers do not churn the way clinical buyers do once a tool is integrated into their close.
“This is just the same RCM story repackaged with a margin frame.” Not quite. The RCM story is “capture the revenue you are leaving on the table.” The cost-out story is “stop paying for the supply, the rebate gap, the procurement waste you didn’t know you had.” Those are different data sources, different stakeholders, and different demos. If you are a clinician-builder mapping a category, treat them as two columns, not one.
💡 80/20: The procurement audience for cost-out AI is the CFO, not the CMIO — and the buying motion is faster because it does not require a clinical workflow change. Reframe: if your tool’s value is “the hospital saves $X per year without the clinician changing what they do,” the budget is the procurement office, the timeline is shorter, and the clinical demo is optional.
→ Full write-up
Karandeep Singh proposes a “consent time-out” for AI scribes — both directions, every visit.
Karandeep Singh, MD (Chief Health AI Officer, UC San Diego Health) shared an idea: every visit starts with a consent time-out — clinicians ask patients to consent to the scribe, and patients ask clinicians to consent to the scribe. Symmetric. The framing is fresh because it removes the assumption that consent only flows one way.
😤 Haters
“This is performative — patients don’t actually understand what they’re consenting to with an AI scribe.” That is a legitimate critique of any consent process, not specific to AI. The mutual frame is doing two things: it forces the clinician to articulate what the scribe is, and it gives the patient the question prompt that the consent form has been failing to convey. The performance, done well, is the education.
“Adding a consent step to every visit is workflow friction we cannot afford.” Friction is the other product surface that gets ignored. The 30-second time-out is also the only structured moment in which a patient learns the AI is in the room. If you are building scribe products, you are competing in a market where this becomes table stakes within a year — solve the UX of mutual consent before the regulator does.
💡 80/20: The consent UX is now a product surface for ambient AI tools, not a legal afterthought.
→ Full write-up
🛠️ From the Workbench
openEHR Assistant — a Cursor + Claude Code plugin with a companion MCP server
Sebastian Iancu published openEHR Assistant — a plugin for Cursor and Claude Code wired to a companion MCP server that pulls live CKM artifacts, implementation guides, terminology, type specifications, and worked examples. The plugin gives the IDE commands, guide-first prompts, focused agents, offline cheatsheets as fallback, and a nudge on .adl files. Sebastian’s framing: “got tired of the assistant in my editor inventing openEHR.” [note: I have not tried but find interesting]
⚠️ Verify: This is a community plugin, not a vendor product — there is no BAA, no security certification, and no compliance posture by default. The right posture is: synthetic data only, in an isolated dev environment.
😤 Haters
“openEHR is European and not relevant to US clinician-builders.” US adoption is small, true. But the pattern in this plugin — a domain practitioner shipping a Cursor/Claude Code plugin with an MCP server that reads the canonical specifications — is the pattern. Substitute “FHIR R5” or “USCDI v4” or “ICD-10-CM” for “openEHR” and the architecture is the same. The plugin is a template.
“This is just RAG over a documentation site — nothing new.” It is RAG, and it is also a fallback offline cache, an editor nudge tied to file extensions, and a focused agent with guide-first prompting. The pieces are not new individually. The composition — domain practitioner, Claude Code, MCP server, validated by a working physician on real clinical data inside the same week — is the clinicians.build archetype rendered as a build, not as a thesis.
💡 80/20: A clinical-data-standard practitioner just shipped a Claude Code plugin with an MCP server. Try: pick the standard you know best (FHIR profile, USCDI element, ICD-10 chapter) and write the README for the equivalent plugin. Even if you never ship it, the README is the product spec — and the model can do most of the implementation once the spec is real.
What are you building this week? Reply and tell me — I read every one.
— Kevin