MimiLabs now with Pubmed, Meta's AI vendor gets breached 💥, MedPlum,
Meta Paused Its AI Data Vendor After a Supply Chain Breach. Health AI Should Pay Attention.
Meta suspended all work with Mercor, a $10B AI data startup, after a supply chain attack compromised 4 terabytes of data — including source code, user databases, and SSNs of 40,000+ contractors. The attack vector: a compromised open-source library called LiteLLM with 97 million monthly downloads. Attackers poisoned two versions on PyPI for just 40 minutes. That was enough.
😤 Haters
“This is a crypto/AI startup problem, not a healthcare problem.” LiteLLM is used by anyone routing LLM calls — including health tech companies building clinical AI. If your stack includes any open-source LLM proxy, you share this attack surface. The question isn’t whether you use Mercor. It’s whether your dependency chain includes a package with this kind of single-point-of-failure risk.
“We pin our dependencies and review updates.” Good. But the malicious versions were live for 40 minutes. Automated dependency updates, CI/CD pipelines that pull latest, pre-commit hooks that auto-upgrade — any of these could have caught the poisoned version in that window. The supply chain isn’t just your code. It’s your build process.
→ Full write-up
A VC Just Published the Healthcare AI Survival Checklist
Uma Veerappan of Flare Capital Partners published a framework identifying four factors that separate healthcare AI winners from losers: seamless workflow integration, action-oriented solutions (not dashboards), proprietary data moats, and strong go-to-market distribution. The key insight for builders: ambient AI scribes succeeded specifically because they embedded into the workflow rather than sitting alongside it. The tool that requires a new tab loses to the one that’s already there.
😤 Haters
“Proprietary data moats feel like a recipe for more data silos.” Fair concern. But the argument isn’t about hoarding data — it’s about longitudinal patient context that gets better over time. The distinction matters: a walled garden vs. a learning system with the patient’s full history.
💡 80/20: If you’re building a clinical AI tool, ask the Flare Capital test: does your tool close the loop and take action, or does it surface information and hope someone acts? Reframe: the most dangerous word in health tech is “dashboard.” Build the thing that does the thing, not the thing that shows you the thing.
→ Full write-up
🛠️ From the Workbench
MimiLabs: AI Co-Research Analyst for PubMed and Health Policy
Yubin Park, PhD shared MimiLabs, an AI-powered research tool designed for PubMed literature review, health policy analysis, and Medicare/Medicaid analytics. Think of it as a domain-specific research copilot — rather than generic search, it’s built to understand clinical evidence hierarchies and policy structures.
⚠️ Verify: Evaluate data handling practices before using with any sensitive research data. The tool interfaces with PubMed’s public API, but confirm how queries and results are stored or processed before integrating into institutional workflows.
😤 Haters
“Another AI research tool — how is this different from Elicit or Consensus?” Domain focus. MimiLabs is built specifically for health policy and Medicare/Medicaid analytics, not general academic research. Whether that specialization actually improves results over general tools requires testing with your specific research questions.
“I can just use Claude or ChatGPT with PubMed.” You can. But the value proposition of domain-specific tools is structured output — not just finding papers, but extracting the specific data points (NNT, confidence intervals, policy docket numbers) that health services researchers actually need. Having the data in one Databricks instance is where MimiLabs shines.
💡 80/20: If you do any health policy or clinical evidence research, test MimiLabs against your current workflow on one real question. Try: take the last PubMed search you did manually and run it through MimiLabs. Time both. The delta tells you whether specialization matters for your use case.
🧰 Builder’s Tip
Tool Spotlight: Medplum — Open-Source FHIR Server You Can Run Locally in 5 Minutes
If you’re building anything that touches patient data and you don’t have a FHIR sandbox yet, Medplum is the fastest way to get one. It’s open-source, FHIR R4 compliant, and comes with synthetic patient data out of the box.
npx create-medplum-app@latest my-health-app
cd my-health-app
npm run dev
Three commands and you have a local FHIR server with a React frontend, synthetic patients, and full CRUD on every FHIR resource type. Build your medication reconciliation tool, your patient summary viewer, your CDS hook prototype — all against realistic data without touching anything real. The Medplum team also maintains a Storybook with pre-built React components for common clinical UI patterns (patient timelines, medication lists, diagnostic reports). You’re not starting from scratch — you’re assembling.
What are you building this week? Reply and tell me — I read every one.
— Kevin