💰 $170M to govern what's inside, 🤖 Nomad

$125M to manage AI safely. $45M to staff it with clinicians.

Two health tech raises dropped yesterday that together describe the two bets about where the value in clinical AI actually sits.

Qualified Health raised $125 million in a Series B led by NEA, with participation from an Anthropic-backed fund. The company builds the infrastructure layer for enterprise AI at health systems: a connected data foundation that pulls EHR and operational data into an AI-ready schema, builder tooling for developing applications, and a governance framework with monitoring, access controls, and risk alerts. At UTMB, they generated $15M+ in run-rate impact in six months. The pitch: health systems don’t need to figure out AI infrastructure themselves. Qualified Health does it for them.

Thesis Care raised $45 million in a Series A led by Oak HC/FT. The company — co-founded by Niren Gandra MD, previously chief commercial officer at Cedar — deploys AI agents for care management backed by a team of clinical experts in the loop. The model is explicit: AI handles the context, the coordination, and the first-pass action; clinical experts handle escalations and anything requiring genuine judgment. The pitch: the agent era in healthcare requires both AI and the clinical expertise to know when the AI is wrong.

What’s interesting is that these are not competing bets. Qualified Health builds the data and governance infrastructure for health systems deploying any AI. Thesis Care builds a specific clinical product that runs on top of that kind of infrastructure. They’re different layers of the same stack.

The clinician-builder implication across both raises: the infrastructure problem of health AI (clean data, governed deployment, auditable outputs) is now attracting serious capital. The clinical insight problem (what should the AI actually do, what workflow is actually broken, what does correct look like) is still where the domain expertise is irreplaceable. Qualified Health can’t tell a health system what to build. Thesis Care’s MD co-founder is the reason the platform knows when to escalate. In both cases, the person who understands the clinical problem is the scarcest input.

😤 Haters

“Another health AI governance platform — this is a solution in search of a problem.”

UTMB’s $15M run-rate impact in six months suggests otherwise. The implementation problem is real; health systems are not equipped to build this internally.

“Expert clinicians in the loop just means the AI is a fancy triage filter.”

Or it means the product actually works because it knows its own failure modes. Most clinical AI fails when it doesn’t know what it doesn’t know. Building human escalation in at the architectural level is the difference between a demo and a deployment.

“These raises prove health AI is overfunded.”

Two companies, $170M combined, addressing the governance infrastructure and the care management layer simultaneously — in a sector spending $600B+ annually. That’s not frothy.

💡 80/20: For clinician-builders inside health systems: the most valuable thing you can do right now is document the workflow you want to automate in terms that an AI governance platform can evaluate. What does correct output look like? Who reviews it? What’s the escalation path? If you can’t answer those three questions, you can’t sell the use case internally — regardless of what platform the health system buys. Try: write a one-page “AI spec” for one clinical tool you want to build. Not the technical spec — the governance spec. It’ll be harder than you expect.

→ Qualified Health story · Qualified Health Series B · Thesis Care Series A

---

Project NOMAD: offline AI + medical knowledge, designed for anywhere

Project NOMAD (N.O.M.A.D — Network-Optional Medical-grade AI Device, roughly) is an open-source, self-contained offline knowledge and AI system designed to run on any Debian-based system. It bundles offline Wikipedia, Project Gutenberg, medical references, repair guides, and local LLMs into a browser-accessible server — no internet required. The LLMs run locally; nothing goes to a cloud. Medical references are included offline alongside the general knowledge base.

The use case it’s built for is explicitly austere: no internet, no cloud, complete self-sufficiency. For clinicians, the obvious application is wilderness medicine, disaster medicine, resource-limited settings, and rural practice environments where connectivity is intermittent or unavailable. But there’s a broader clinical AI design question it points at: what does it look like to build clinical decision support that is genuinely offline-capable, with a data footprint that never touches external servers?

⚠️ Verify: “Medical references” is a broad claim. Before relying on any offline medical knowledge base for clinical decisions, verify what sources are included, how they’re updated, and what the version/currency lag looks like.

😤 Haters

“No serious clinical deployment should run on an offline LLM with a static knowledge base. Guidelines change; a frozen model gives dangerous answers.”

Valid concern for anything close to the clinical decision point. The verification caveat applies here: offline knowledge has a currency problem that matters most for drug dosing, guideline-based recommendations, and anything where evidence has moved since the model was last updated. The use case is resource-limited environments where an outdated answer is better than no answer — which is a real use case for some clinicians.

“This is a prepper project with a medical knowledge section, not a clinical AI tool.”

Maybe. The underlying architecture — offline LLM, local medical references, browser-accessible on a local server — is exactly what a clinician-builder would want for a privacy-first, air-gapped clinical tool prototype. The prepper framing doesn’t negate the technical pattern.

💡 80/20: The pattern here matters more than the specific project: local LLM inference + offline medical knowledge base + browser-accessible interface. That architecture is directly relevant to anyone building clinical decision support that needs to work without internet (rural clinics, austere environments, international deployments, or just privacy-first prototypes on synthetic data). Try: install Ollama locally if you haven’t already and run MedGemma or any available clinical model against a local medical reference document. That’s the prototype of what Project NOMAD is packaging more formally.

→ Full write-up · Project NOMAD on GitHub · projectnomad.us

---

🎯 Clinician-Builder Tip of the Day

Before you write the first line of code for an AI feature, answer three questions: (1) What does a wrong output look like, and how would you know? (2) Where does a human sit in the execution loop — start, middle, or end? (3) What’s the escalation path when the AI isn’t sure? If you can’t answer all three, you haven’t specced the feature — you’ve just decided to start building. These aren’t compliance theater. They’re the difference between a demo that impresses and a tool that actually gets used at 2 AM when someone’s potassium is 6.8 and the clinical situation is ambiguous. The architecture answers these questions before your code does. Make sure it’s answering them the way you’d want.

---

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

— Kevin