Hospital-grade, by construction.
Kartha runs inside your cloud account, reaches the hospital with your EMR credentials, and never sits in the PHI path. The rest of this page is what your architects and the hospital's security team will ask next.
PHI never leaves your boundary.
The server, the SDK, the notes index and the model call all run in an account you own. Kartha configures remotely. There is no Kartha-hosted service in the request path and no runtime license server to call home to.
What this means for your security review
No PHI reaches Kartha, so there is no PHI review with your security team and no BAA by default. The review becomes a review of software you run, with your keys, in your account.
What this means for the hospital
You keep the EMR relationship and the app registration. The hospital sees your app, your keys and your audit trail. Kartha is a dependency inside it, like a database driver.
What this means for cost
Inference runs on your provider at your rates. Hosting is yours. Kartha's pricing is a flat subscription per hospital tenant, never a share of your usage.
Two layers of auth. Tenant by signature.
Who may call the server and how the server reaches the EMR are separate decisions, each enforced in the binary.
tenant taken from a verified claim
S2 forward the caller's SMART token, never stored
Layer one: who may call
A static bearer token, or the opt-in MCP-JWT: short-lived, signed by your own key, with the tenant taken from a verified claim rather than a header the caller can set.
Layer two: how the EMR is reached
S1: the server mints the EMR token from credentials in your Secrets Manager via the task role, never baked into the image. S2: your host app does its own SMART OAuth and the server forwards the caller's token per request, never storing or logging it.
Tenant resolution
The tenant comes from the verified entitlement or JWT claim. It is never derived from the EMR token, and the resolved tenant's provisioned endpoint is the only place a call can go.
Supported methods
SMART on FHIR backend services (private_key_jwt, RS384) for Epic, OpenEMR and other SMART-conformant EMRs; OAuth2 with refresh; service-account auth for GCP Healthcare API; bearer and basic for test servers.
Ten invariants. Each one gates CI.
These are not prompt instructions. Each is enforced in code and has an acceptance test in the suite that gates every build. If one fails, the build does not ship.
- Read-only by defaultWrite tools are off until a tenant explicitly enables them.
- Patient-scope floor on every searchEvery retrieval is rebound to the session patient. An agent cannot wander to another chart.
- Temporal bounds enforced at both endsTime windows are applied on the query and re-injected when the model drops them.
- Writes double-locked, drafts onlyCreates and updates land as drafts for a human to confirm. Nothing is auto-assigned.
- Tenant is a signed claim, never a headerEntitlement or MCP-JWT decides the tenant. Caller input and model output cannot.
- Licensing can never block a clinical callEntitlement checks fail open to a grace state. Denying a FHIR read over licensing is treated as a patient-safety event.
- No secrets in logs, no PHI in telemetryTokens, query values and key material are redacted. Resource ids are HMAC-pseudonymized. Response bodies never reach the log.
- Signing keys never leave KMSEntitlement verification and audit encryption use only the safe halves; the binary ships no private key.
- Skills are context, never codeSKILL.md is injected into the prompt. Nothing in a skill executes.
- No full-note dumps, idempotent tool callsNotes are retrieved by patient-scoped semantic search with coverage receipts; repeated calls are safe to retry.
Licensing that cannot block a clinical call.
The commercial platform is enforced by a signed entitlement file, offline. There is no license server and no per-call network check.
Signed, not encrypted
Kartha signs the entitlement with a private key; the binary verifies with an embedded public key. The threat is tampering, not secrecy, so the file is readable by your team.
Fail open, always
An expired or missing entitlement degrades to a grace state: premium skills flag, logs record it, your team is alerted. Clinical calls continue. Customer-authored skills always run.
Usage audit, sealed
An encrypted usage audit is collected out of band. The binary can only encrypt it; only Kartha's offline key decrypts it. It contains counts, never PHI.
Deployment targets.
One signed, multi-arch image with an SBOM. Secrets are sourced at runtime from your cloud, never from the image. Your runbook covers deploy, upgrade, and entitlement and key rotation.
ECS Fargate behind an ALB with TLS 1.2+. SSM and Secrets Manager via the task role. CDK and synthesized CloudFormation. Bedrock for inference, Aurora pgvector for notes.
GCP Healthcare API as a FHIR backend with service-account auth, Gemini Enterprise for inference, in your project.
The same image, with Azure AI Foundry for inference. Nothing on Kartha-operated infrastructure.
The MCP server and console run as Databricks Apps, the FHIR store and notes index in Lakebase Postgres, Claude through Model Serving. Governance is Databricks App permissions. Nothing crosses the workspace boundary.