Patient builds own health AI with Claude Code 🛠️, EHR APIs are icebergs 🧊, OpenAI wants to bill for AI 💰

A Patient Who Doesn’t Code Built His Own Health Record AI — and Microsoft Research’s Chief Health Architect Cosigned It

Hugo Campos is a patient advocate and Kaiser Permanente member. He needed browser-based access to his health record through SMART on FHIR. Kaiser’s FHIR API has a CORS misconfiguration that blocks it.

He documented the issue in a four-page technical report. Sent it to Kaiser. Nothing changed.

So he directed Claude Code to build OpenKP [linkedin] — an MCP server that bridges his Kaiser record into Claude Desktop. MIT-licensed. Running locally on his laptop, under his own credentials. He wrote zero lines of Python. Claude Code wrote every one.

This is what patient-directed AI actually looks like. Not the patient AI an EMR deployed at you. Not the patient-facing tool a developer built for you. The AI you direct, on the data you have a right to access, building the tool you need.

Josh Mandel, Microsoft Research’s chief architect for health, reposted it with a framing that should make every EHR vendor uncomfortable: if building FHIR connectors the right way leads to dead ends, patients will write their own agents that look like end-users to the underlying system. AI agents make this increasingly easy.

The builder implication is bilateral. On one side: patients are now capable of directing AI to build clinical data tools, and the broken state of patient-facing APIs is the catalyst. On the other: clinician-builders who understand both the clinical workflow and the API architecture are uniquely positioned to build the right version of what Hugo built from frustration.

The person who understands the clinical context and the FHIR plumbing builds the tool that serves both sides.

😤 “One patient built a toy. This isn’t a trend.” Dave deBronkart’s #PatientsUseAI panel is organizing around exactly this thesis. Hugo tagged a dozen patient advocates in the post. This is a community, not an anecdote. And the tooling that makes it possible — Claude Code, Cursor, Copilot — gets better every quarter.

😤 “This is a security nightmare. Patients scraping their own EHRs is exactly what CORS protections prevent.” Josh Mandel’s point is precise: patients will find workarounds that look like end-users to the system. The choice isn’t between “controlled access” and “no access.” It’s between standards-based APIs that work and creative workarounds that don’t play by the rules. Fix the CORS config. Ship working patient APIs. The alternative is already happening.

😤 “But HIPAA—” Hugo is accessing his own data under his own credentials on his own laptop. This is a patient exercising their HIPAA right of access under 45 CFR §164.524. The legal question isn’t whether he can do this. It’s why Kaiser made it so hard that he had to.

---

The Iceberg Fallacy: Why Monetized RPA Is the Inevitable EHR Equilibrium

Brendan Keeler’s latest piece introduces a concept every clinician-builder should internalize: the iceberg fallacy — the inverse of sunk cost. Instead of overweighting past investment, it’s underweighting future maintenance obligations.

Every API is a liability the moment it ships. The maintenance tail — field additions, deprecations, version bumps, bug fixes — is the hidden cost.

The information-blocking rules require exchange of all electronic health information. The API surface area vendors must legally support is expanding faster than their engineering budgets can maintain it. Keeler’s argument: monetized RPA — third parties riding on the clinical UI, the vendor getting free regulatory compliance — is the inevitable equilibrium.

athenahealth’s API changelog is the evidence. New FHIR Subscription topics (event notifications ahead of HTI-6), Condition write endpoints, patient account creation APIs, and a Sage AI assistant for developer docs. They’re outpacing the rest of the industry on the FHIR surface area that matters to builders.

😤 “RPA is a hack. Real integrations use APIs.” Keeler’s point is that RPA-via-clinical-UI and API-via-FHIR are converging toward the same endpoint: agentic access to EHR data. The question isn’t which is more elegant. It’s which ships faster against an expanding regulatory surface area. For many vendors, RPA is the API now.

💡 80/20: Sign up for athenahealth’s developer portal and read the last 90 days of their API changelog. It’s the most transparent window into where EHR API surfaces are heading — and the gaps between what they’ve built and what your competitors are maintaining is where the opportunity lives.

---

OpenAI’s Healthcare Blueprint Has a Buried Plank Worth $5–12B

OpenAI’s “Keeping Patients First” blueprint got covered as a policy document about data portability and regulatory sandboxes. Most analysis missed the plank that actually reprices clinical-AI exit math.

The blueprint asks CMS to extend “incident-to” billing eligibility (42 CFR §410.26) and remote physiologic/therapeutic monitoring CPT-code applicability (99453/54/57/58, 98975-81) to AI-derived clinical outputs.

That’s a $5–12B annual revenue-pool unlock. It’s the only plank in the document that materially changes how clinical-AI companies get valued.

The vehicle: CMS-1808-P, the 2027 Physician Fee Schedule rulemaking docket, expected to open late summer 2026. The pre-rulemaking lobbying window is open now — roughly 90 days to organize a coherent position through AAFP, ACP, AMA RUC, and AHIMA before the docket closes.

😤 “OpenAI is just lobbying for its own products.” Obviously. But the policy mechanism — extending incident-to billing to AI outputs — would benefit any clinical-AI company, not just OpenAI. The specific CPT codes (remote monitoring 99453/54/57/58) are the ones ambient scribes, clinical CDS tools, and autonomous triage systems would bill against. If you’re building in any of those categories, this docket is your financing-plan variable.

😤 “This will never pass. CMS moves slowly.” CMS moves slowly until it doesn’t. The ACCESS Model (10-year demonstration, 150+ organizations, outcome-aligned payments) shipped in months. When the budget math works and industry pressure aligns, CMS can move. The question is whether the clinician-builder cohort has a seat at the table when the comment period opens.

---

OptumRx Goes Transparent: Flat Fees, No Drug-Price Ties

OptumRx announced a new pricing model replacing drug-price-tied economics with monthly, clearly defined per-member fees independent of manufacturers’ list prices. Every client gets transparency into fees. By end of 2027, group purchasing fully transitions to flat service fees.

The largest PBM in the country just decoupled its revenue from drug prices. Whether this is genuine transparency or structural repositioning ahead of PBM reform legislation, the technical architecture underneath your pharmacy tools needs to account for fee-based rather than spread-based economics.

💡 80/20: If you’re building anything that touches pharmacy pricing, pull up the OptumRx announcement and map it against your data model. The transition from spread-based to fee-based PBM economics changes what fields matter in your billing pipeline.

---

Anthropic Donates Petri v3.0 to Meridian Labs — Watch for the Pattern

Anthropic donated Petri, its open-source alignment evaluation toolkit, to Meridian Labs, an independent AI evaluation nonprofit. Petri v3.0 ships with a new Dish add-on (catches models that detect they’re being tested) and Bloom integration (targeted behavioral evaluations).

The UK AI Security Institute has already integrated Petri as a core component of its pre-deployment evaluation process for every Claude model since Sonnet 4.5.

This is the second instance of a strategic pattern. Build the primitive internally. Donate it to an independent nonprofit. Capture commercial upside through the integration layer. MCP → Linux Foundation was the first. Petri → Meridian Labs is the second. Watch for the third within 90 days.

For clinician-builders evaluating clinical-AI safety: track Petri integrations, don’t build from scratch. Any clinical-vertical benchmark the community builds (a “ClinicianBench”) should be positioned under an independent-steward pattern to achieve regulator-grade adoption — not a vendor-owned eval that procurement offices can dismiss.

💡 80/20: Bookmark Petri on GitHub. If you’re evaluating any clinical AI tool for safety, run the Petri deception and sycophancy evals against it before deployment. These are the tests regulators are already using. You should be too.

---

Your Agent Doesn’t Need a Better Prompt. It Needs a Judge.

Nate Jones published an implementation guide for production agent safety: a separate LLM-as-judge that evaluates each proposed action before execution. The next serious agent failure won’t look like a jailbreak — it’ll look like a correctly-executed wrong action. An email sent because the thread implied approval. A record updated because old values looked stale. Four action-risk classes, specialist judge patterns, and five starter prompts included.

---

Aidoc Raises $150M Series E for Radiology AI

Aidoc closed a $150M Series E, continuing the diagnostic AI funding wave alongside Artera’s FDA clearance and Roche’s PathAI acquisition. The radiology-AI category is consolidating around players who can show contracted health-system revenue, not just FDA clearances.

---

Microsoft’s Work Trend Index: Your Organization Is 2x More Important Than Your Skills

Microsoft’s 2026 Work Trend Index surveyed 20,000 workers. Organizational factors account for 67% of AI outcome variance — individual skills only 32%. Only 19% of workers are in the “Frontier” bucket (skilled and org-ready). AI agents in M365 grew 15x year-over-year. For clinician-builders inside health systems: the organizational permission structure matters twice as much as your personal technical skill.

---

What are you building this week? Reply and tell me — I read every one.

— Kevin