KarthaHealth
3,500+LangCare installs, our open-source MCP FHIR server

Clinicians write the skill. Kartha ships the agent.

Not one agent that does one thing. The Kartha Clinical Context Platform ships them all: the LangCare MCP FHIR server, the Agent SDK, ten agent accelerators and fifty clinical skills, so your skill becomes a running agent in an afternoon, guardrailed and receipted, with secure, tenant-isolated access to the hospital EMR in your cloud.

Your agents Clinical decision supportMedication managementCoding & CDICare coordinationLab diagnosticsPopulation health
KarthaHealth
Clinical Context Platform
Their EMRs EpicOracle Health / CernerathenahealthOpenEMRGoogle Cloud HealthcareMEDITECHAny FHIR R4 server
6–12

person-months of plumbing before a clinical-AI team ships its first differentiated feature. Same list, every team, every time.

The FHIR client is the easy five percent.

Connecting an agent to a FHIR API takes an afternoon. What takes months is everything a health system requires before that agent touches a chart. None of it is your product. All of it ships with Kartha.

  • Epic, Cerner and athena app registration and OAuthSMART backend services, private_key_jwt, token refresh, per-vendor quirks
    Handled
  • Multi-tenant isolation per hospitalOne deployment, many hospitals, provably separate
    Handled
  • Security review and audit trailTwo-layer auth, scrubbed logs, pseudonymized ids, signed images
    Handled
  • Clinical-context retrievalA chart is 200K tokens; your context window is not
    Handled
  • Guardrails enforced in codePatient scope, read-only, temporal bounds, draft-only writes
    Handled
  • Clinical skills and workflowsSepsis screening, med reconciliation, discharge planning, care gaps and 46 more
    Handled

One platform, four layers you no longer have to own.

A guardrailed MCP FHIR server, an agent SDK, a clinical skill catalog, and batch workflows. Your product sits on top. Your EMR keys stay underneath.

MCP FHIR server

Guardrailed access to any EMR, in 100% Go.

Four generic tools over any FHIR R4 resource. The tenant is chosen by a signed entitlement, never by the caller or the model, and every call reaches only the provisioned endpoint. Stateless, no database, no PHI at rest.

// one call, any resource type, summarized on the way back
fhir_search({
  resourceType: "Observation",
  queryParams: "patient=p-4471&code=2160-0&_sort=-date",
  outputFormat: "text"   // full | text | compact-fhir
})
About the server
Agent SDK

Agents in YAML. Skills in Markdown.

A TypeScript runtime with a guardrail executor, sessions and streaming, prompt caching and full turn tracing. Apache-2.0.

# agent.yaml
name: discharge-planner
skills: [discharge-planning, med-reconciliation]
guardrails:
  patient_scope: required
  writes: draft-only
  temporal_bounds: enforced
model: bedrock/anthropic.claude-sonnet
About the SDK
Clinical skills

Fifty workflows, reviewed by clinicians.

Injected as context, never executed as code. Author your own in an afternoon.

Sepsis screeningMed reconciliationDischarge planningCare gapsOpioid riskGrowth chartsOncology timeline
Browse the catalog
Clinical AI workflows

Run one skill across a whole cohort.

One queue message per patient, a rate-limited worker, per-run results in S3 and an honest job report. Deploys with five resources.

YAML→SQS→Lambda→S3 report
About workflows
Receipts

Every answer shows its work.

Each tool call, each guardrail that fired, tokens and cost per turn. Clinicians do not have to trust the agent was constrained. They can see it.

tool calls17 traced
guardrailspatient-scope · read-only · temporal
chart tokens−74% via summarizer
synthetic patient, no PHIcost shown per turn
About the console
New: Jev

Not every clinical agent needs an LLM.

Jev answers hundreds of small structured questions per chart with calibrated probabilities. Deterministic rules turn them into findings. Millisecond speed, pennies per chart, every call auditable.

Meet Jev
40/40

inpatient stays reviewed

$0.17

total cost for the run

195 ms

p50 per request

Three ways to run it. One skill format.

Interactive

A clinician asks, the agent retrieves.

One session per patient, LLM-driven retrieval, the full trace on screen. Ship it inside the Kartha console or your own UI.

Headless

Your product calls an API.

POST /v1/sessions with REST and SSE. No UI attached. The guardrails and receipts come along anyway.

Cohort

A whole panel, overnight.

Code-driven chart abstraction with zero tool calls per patient, fanned across a cohort as durable, throttled jobs.

Your cloud. Your keys. Our harness.

Kartha deploys into your AWS, GCP, Azure or Databricks account and reaches the hospital with your own EMR credentials. Kartha configures remotely and never sits in the PHI path. Security review gets short.

Said to a hospital security team, in one line: the whole platform runs inside our account with our EMR keys. No PHI leaves. No runtime license server.

  1. Read-only by default
  2. Patient-scope floor on every search
  3. Temporal bounds enforced at both ends
  4. Writes double-locked, drafts only
  5. Tenant is a signed claim, never a header
  6. Licensing can never block a clinical call
  7. No secrets in logs, no PHI in telemetry
  8. Signing keys never leave KMS
  9. Skills are context, never code
  10. No full-note dumps, idempotent tool calls

Ten invariants. Each one has an acceptance test, and the suite gates CI. If an invariant fails, the build does not ship.

AWS

ECS Fargate behind an ALB. Keys from Secrets Manager via the task role. Inference on Bedrock.

Google Cloud

Healthcare API as a backend, Gemini Enterprise for inference, your project, your rates.

Azure

Same image, Azure AI Foundry for inference. Nothing on Kartha-operated infrastructure.

Databricks

The entire stack as Databricks Apps on Lakebase, with the model served in-workspace.

Read the security model

Built on an open-source core.

LangCare was the first MCP server for FHIR, written a few weeks after the protocol was published. It is MIT-licensed and a few thousand teams have installed it. Kartha is the production layer on top: tenancy, guardrails, skills, workflows and support.

terminalMIT
$ npx @langcare/langcare-mcp-fhir -config config.yaml

# config.yaml
fhir_server:
  provider: epic          # epic | cerner | gcp | openemr | generic
  base_url: https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4
transport:
  http: { enabled: true, port: 8080 }
logging:
  scrub_phi: true

We are onboarding a handful of design partners.

Funded clinical-AI teams and clinician-founders with a real workload and a real EMR to connect to. You bring the workload. We get your first hospital tenant live in your cloud, and your feedback shapes the roadmap.

Or write directly: hari@kartha.health

  1. Scope

    One workload, one EMR, one hospital tenant. We agree on what done looks like.

  2. Deploy

    Kartha lands in your AWS, GCP, Azure or Databricks account with your keys. We configure remotely.

  3. Ship

    Your agent runs against the live tenant with guardrails and receipts. Then we add tenants.