Kartha Health now runs natively on Databricks — end to end.

01The constraint was never the model. It’s blast radius.

For healthcare teams building with AI, every hop your PHI takes outside your own environment becomes a BAA conversation, a data-residency question, and a risk you own forever. So we put the entire Kartha stack inside the Databricks workspace — the same platform, now alongside AWS, GCP and Azure.

02How Kartha runs in your workspace

03What’s inside

• FHIR on LakebaseA FHIR R4 store in Lakebase Postgres — read, search, create, and version-aware update. Clinical notes are chunked and embedded, so semantic search across a patient’s notes is a single tool call — patient-scoped by construction, not by prompt.
• The MCP server is a Databricks AppStreamable HTTP on /mcp. Any Databricks agent can discover and call it — AI Playground, an Agent Bricks Supervisor subagent, or a custom agent. Governance is Databricks App permissions: you grant access to clinical data the way you grant everything else.
• The Clinical Agent Console is an App too50 clinical skills and 10 agents against Lakebase, with the full generation trace on every answer — each tool call, each guardrail adjustment, tokens and cost per turn.
• Claude runs in-workspaceThrough Databricks Model Serving. The agent loop stays ours; the model call never leaves your account.
• The guardrails are the productEvery retrieval is rebound to the session patient. Read-only by default. Temporal bounds re-injected when the model drops them. An agent cannot wander to another chart — enforced in code, not asked for in a system prompt.
• One skill format, every cloudThe same skills and agents run on Databricks alongside AWS, GCP and Azure. Nothing to rewrite when your platform changes.

04Seen in the workspace

Synthetic demo data throughout — no PHI.