Today we published @oktopeak/intakeq-mcp on npm. It is a Model Context Protocol server that lets Claude work directly with a clinic's IntakeQ / PracticeQ account: look up a client, review appointments, read intake forms and notes, check invoices. It is open source under the MIT license, and every read or write of patient data is written to a local audit log.
We build software for regulated industries, so we wrote the README the way we wish more vendors would. It has a section near the top titled "Before you connect this to real patient data," and that section makes a claim most marketing pages avoid. We want to spend this post on that claim, because it is the part that actually matters for a clinic deciding whether to use Claude at all.
The claim we refuse to make
Read enough AI healthcare pages and you will see a version of this line: "Your data never leaves your practice." It is reassuring, and with a hosted model it is not true.
When Claude summarizes an intake form through our connector, that intake form is sent to the model provider so the model can process it. That is what inference is. The connector does not run the model on your laptop. It brokers an authenticated call to IntakeQ, hands the returned content to the model, and logs that the access happened. The content reaches the model. There is no version of a useful hosted-model workflow where it does not.
"Nothing leaves the clinic" is only honest when the model runs entirely on hardware you control, on-premises or a local open-weights model. For a hosted frontier model like Claude, the accurate statement is different, and better, once you understand the distinction below.
Why we care about this so much. A clinic that believes "nothing leaves" will skip the one control that actually protects them: a contract with the AI provider governing what the model is allowed to do with the content it processes. The comforting lie removes the reason to get the paperwork right.
Access vs retention
Most people evaluating an AI tool ask about retention. Does it keep my data? Does it train on it? Those are the right questions, but they are the second and third questions. The first one is access.
Retention is what happens to content after a request completes: whether it lands in logs, training sets, or vendor storage.
Access is whether the model saw the content at all, even for the fraction of a second it takes to generate a response.
For protected health information, access is the exposure. If the model processed a patient's note, that processing is the event a compliance review cares about. A no-retention guarantee is real and worth having, but it governs what happens to the content afterward. It does not undo the fact that the model read it.
This is the gap most evaluations miss, and it is why an audit log alone is not a compliance answer. An audit log records that access happened, who triggered it, and when. It does not record that the access was permissible. Those are different facts. Logging is necessary. It is not consent.
Put plainly: if the model was allowed to process the content under a contract that forbids retention and training, you are in good shape. If it processed the content and there is no such contract, a spotless audit log is a detailed record of a problem, not the absence of one.
The clean answer for PHI
Once you frame it as access, the requirements fall out cleanly. To use a hosted model with patient data safely, you want all three of these, and none of them is "data locality":
A Business Associate Agreement with the model provider. Under HIPAA, any vendor that processes PHI on your behalf needs a BAA. The AI provider processes PHI the moment the model reads a note. So the AI provider needs a signed BAA, not just your hosting company and your EHR.
Training disabled. The content you send must not become part of any model's training data. This is a specific contractual setting on enterprise AI tiers, not a default.
Zero Data Retention. The provider does not store the request or response after it serves the answer. On Anthropic's enterprise tier this is available as an explicit setting under a BAA.
Notice what is not on this list. "We keep your data in your region" is a data-locality property. It is fine, but it is a statement about geography, not about whether the model processed privileged content. A tool can be perfectly region-locked and still have no BAA and full training on your inputs. Locality is the property that sounds like privacy without being it.
This diagnostic is vendor-agnostic. Whether you are looking at Claude, another frontier model, or a self-hosted open-weights setup, ask the three questions in order: Is there a BAA covering the model provider? Is training off? Is retention zero? The right architecture is whichever one lets you answer yes to all three for the content you actually send.
Why IntakeQ, specifically
We build connectors across regulated industries, and healthcare has a wall in front of it that legal tech does not. In legal, practice-management platforms like Clio, MyCase, and Filevine hand you a self-serve API key and you are building in an afternoon. In healthcare, most platforms gate API access behind an NDA, a paid developer license, a signed partner agreement, and a demo approval before you can read a single field. AdvancedMD, NextGen, and athenahealth all sit behind some version of that gate.
IntakeQ / PracticeQ does not. A clinic generates an API key from its own settings, and, the part that matters most, IntakeQ includes a self-serve Business Associate Agreement on every plan. You sign it in your account. You do not negotiate it.
That self-serve BAA on the EHR side is why a clinic-operated connector is even possible. It clears the healthcare access gate that blocks most platforms. It is the reason we chose IntakeQ as the first healthcare connector we would ship rather than a legal one.
So a real deployment needs two BAAs. One with IntakeQ, which is self-serve and included. One with your AI provider, on an enterprise tier, with training disabled and Zero Data Retention. With both in place, the model can process a patient's intake form under contract, without retaining it and without learning from it. That is the honest version of "safe."
What the connector actually does
The design follows from treating access as the exposure. A few decisions worth calling out:
Audit logging on every PHI read and write. HIPAA's audit controls (45 CFR 164.312(b)) require a record of access to protected health information. Every tool call the connector makes is appended to a local log at ~/.intakeq-mcp/audit.log: which tool ran, when, and whether it succeeded. The log lives on your machine, and it records the access trail, not the patient content itself.
Encrypted key storage. Your IntakeQ API key is encrypted at rest with AES-256-GCM and the encryption key lives in your operating system keychain, not in a plaintext file on disk.
Minimum-necessary by design. The tools are scoped to a client or an appointment rather than "dump the whole panel." You ask for one client's record, or one date range of appointments. There is no bulk export of every patient, because minimum-necessary is a HIPAA principle, not a nice-to-have.
Files stay as references. When a client has a document attached, the connector returns a reference you open in IntakeQ. It does not download and cache the binary. The fewer copies of PHI in motion, the smaller the exposure.
None of this makes the model stop processing the content. It makes the access deliberate, scoped, and logged, and it keeps the connector itself from becoming another place patient data is stored.
How to evaluate any AI + PHI setup
You can apply the same test to any AI tool a vendor pitches to your practice, ours included. Five questions, in order:
- Does the model process our patient content? If the tool is useful and the model is hosted, the answer is yes. Be suspicious of anyone who says no.
- Is there a BAA with the party that runs the model? Not just the app vendor. The entity performing inference.
- Is training on our inputs disabled, in writing?
- Is retention zero, in writing?
- Is every access to PHI logged where we can review it?
Answer those and you know exactly what you are exposed to. A tool that passes is not the one with the best privacy tagline. It is the one that lets you answer yes to questions two through four for the content you actually send.
Get it
The connector is free and open source:
- npm:
npm install -g @oktopeak/intakeq-mcp - Source and README (including the full "before you connect this to real patient data" section): github.com/oktopeak/IntakeQ
It is the same architecture we ship for legal practice management: our Clio, MyCase, and Filevine connectors use the same encrypted key storage, audit logging, and rate limiting.
Frequently Asked Questions
Does the connector keep patient data inside my clinic?
No, and any tool that claims it does with a hosted model is misleading you. The connector stores no patient content and logs every access locally. But when Claude reads an intake form or a note through it, that content is sent to the model provider for inference. The connector brokers authenticated API calls and records the access trail. It does not change where inference happens.
What is the difference between access and retention for PHI?
Retention is what happens to data after a request: logs, training sets, vendor storage. Access is whether the model saw the content at all, even briefly. For protected health information, access is the exposure. If the model processed a patient note, that is the event that matters. A no-retention guarantee constrains what happens later, but it does not undo that the model read the content.
What makes a Claude setup safe for patient data?
Two things beyond the connector: a signed Business Associate Agreement with your AI provider, and Zero Data Retention with training disabled on an enterprise tier. That combination means the model can process the content under contract without retaining it or learning from it. Data locality (keeping data in your region) is a weaker property and is not the same as never being processed by the model.
Why IntakeQ instead of another EHR?
IntakeQ / PracticeQ is one of the few healthcare platforms with a self-serve API key and a self-serve Business Associate Agreement included on every plan. Most competitors gate API access behind NDAs, paid developer licenses, and demo approval. That self-serve BAA is what makes a clinic-operated connector realistic without a partner gatekeeper.
Is the connector free?
Yes. It is published on npm as @oktopeak/intakeq-mcp under the MIT license. You can install it, read the source, and run it against your own IntakeQ account. We also offer a paid guided setup for clinics that want it deployed and configured for them.
