An EMR connector earns trust structurally, not with promises. EMR MCP is read-only by construction, mirrors your Kipu® permissions instead of inventing its own, stores no patient data, and puts a signed BAA in front of every connection.
No write path to Kipu® exists in the product. The connector cannot create, change, or delete EMR data — structurally, not by policy.
Your Kipu user directory is the access list. Staff sign in with their work account; their Kipu roles set what they can ask, their location assignments set the boundaries — and removing a user in Kipu revokes their access at the next nightly sync.
Requests default to the minimum necessary. Detox census counting happens server-side, so headcount questions come back as counts, not patient records.
No patient data is ever cached or stored — it passes through, signed per request. We hold only three things: your staff directory (names, emails, roles, locations) to enforce permissions, an audit record of who ran what, and your API credentials, envelope-encrypted.
Your organization runs on its own subdomain with its own credentials and sign-in policy. Tokens issued for your org are useless anywhere else.
We sign a BAA with every customer, and recommend Claude Enterprise with a BAA signed with Anthropic on your side. Every tool call is logged — who, what, when — never patient arguments or results.
The strongest security control is the one that doesn't exist. EMR MCP contains no code path that writes to Kipu® — not a disabled one, not a permissioned one, none. Every tool reads; nothing creates, updates, or deletes. There is no configuration mistake, compromised account, or prompt-injection trick that could make the connector modify your EMR, because the capability isn't in the product.
Most integrations bolt on their own user management — one more place for permissions to drift out of date. EMR MCP doesn't. Your own Kipu user directory decides who can connect and what they can ask:
Every request defaults to the minimum necessary. Aggregate questions get aggregate answers: detox census counting happens server-side, so "how many clients are in detox?" returns a number, not a list of patients. Record-level detail is opt-in per request and available only to staff whose Kipu role permits it.
HIPAA compliance for an AI workflow isn't one agreement — it's a chain. We sign a Business Associate Agreement with every customer before anything is connected. On the Claude side, EMR answers flow into your team's conversations, so we recommend Claude Enterprise only, with a BAA signed between your organization and Anthropic. We walk you through that setup during onboarding.
Every tool call is recorded: who ran it, which tool, when. What's deliberately absent from those records is the patient data itself — never the arguments, never the results. Need the log for a review? Ask us and we'll provide an export.
The honest version, in one table.
| Data | Stored? | Why |
|---|---|---|
| Patient records, chart content, census results | Never | Answers pass through signed per request — nothing from your EMR is cached or kept. |
| Staff directory (names, emails, roles, location assignments) | Yes | It's the access list — the only way to enforce your Kipu® permissions on every request. |
| Audit records (who ran which tool, when) | Yes | Accountability. Arguments and results are deliberately excluded, so no PHI enters the log. |
| Your Kipu API credentials | Yes, envelope-encrypted (AES-256-GCM) | Required to sign requests to your instance. You can revoke them from Kipu at any time. |
Bring your compliance officer. We'd rather answer the tough questions before you connect than after.
Book a demo