Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MyChart Care Record Connector show my most recent lab results"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A remote MCP connector that reads a patient's own health records from an Epic MyChart portal over the official patient-facing FHIR API, so an AI assistant the patient authorizes can help them keep those records organized.
Built for personal family use by an independent developer. Not affiliated with, or endorsed by, Epic Systems Corporation or any health system.
Signs in to MyChart with a SMART on FHIR standalone patient launch (PKCE, confidential client), and keeps a refresh token so it can sync without a browser round-trip every time.
Reads labs, diagnostic reports, clinical documents, attachments (Binary), appointments and
patient demographics.
Exposes those as MCP tools over an OAuth 2.1 endpoint that Claude can connect to as a Custom Connector.
It is read-only. It holds no scopes that can write to, change, or delete anything in a medical record.
Related MCP server: FHIR MCP Server
A few decisions that are not obvious and are easy to get wrong:
Confidential client, not public. Epic only offers "Requires Persistent Access" (refresh tokens) to confidential clients. A public client with PKCE cannot get a refresh token at all, which means no unattended sync. The client secret lives in Secret Manager.
Rolling refresh tokens. Each refresh returns a new refresh token and retires the old one.
Persisting the new one is mandatory or the link breaks on the next call. See
src/epic-session.ts.
Endpoints are discovered, not hardcoded. .well-known/smart-configuration is read from the
FHIR base at runtime, so moving between the sandbox and a real organization is a config change.
A dead credential is not a server error. When a refresh token is rejected, the link is marked invalid and tools return an actionable "re-link" message rather than a generic failure. Reporting a credential problem as a server fault makes clients retry forever instead of prompting the user.
The Epic refresh token is encrypted at rest with Cloud KMS (src/crypto.ts). It is never
written in plaintext and never logged.
Path | Purpose |
| Epic SMART client: discovery, PKCE, token exchange, FHIR + Binary reads |
| Turns a stored refresh token into a usable access token |
| KMS envelope encryption for the stored refresh token |
| Firestore persistence, including the per-user MyChart link |
| The OAuth 2.1 server this connector runs for Claude |
| Federated login used to establish who is calling |
| Terms and Conditions (published via GitHub Pages) |
| Where this stands and how to resume |
Two separate OAuth flows meet in this codebase, which is the main thing to hold in your head:
Claude --OAuth--> this connector (auth-provider.ts)
this connector --OAuth--> Epic / MyChart (epic.ts)See .env.example. Nothing secret is committed; secrets come from Secret Manager at deploy time.
Paused 2026-09-10. Deployed to Cloud Run and working; the Epic sandbox sign-in that proves the token exchange, refresh tokens, encryption and FHIR reads has not been run yet. Not pointed at a production health system: the target organisation has not distributed the client id.
See STATUS.md for exactly where things stand, the single next action, what blocks real data, and the traps that already cost time.
Provided as-is, with no warranty. See the Terms and Conditions linked above.
This server cannot be deployed
Your MedNode health vault in your AI assistant — records, summaries, labs, appointments.
Read wearables and lab health data — sleep, activity, workouts, timeseries, lab tests and orders.
Guardrailed FHIR access for AI agents: PHI redaction, audit trail, step-up auth, tenant isolation
AI-powered medical document management for cancer patients. Google Drive, Gmail, Calendar via MCP.
