--- title: "Connect eClinicalWorks to ChatGPT: Manage patient medical records" slug: connect-eclinicalworks-to-chatgpt-manage-patient-medical-records date: 2026-10-10 author: Uday Gajavalli categories: ["AI & Agents"] excerpt: A complete engineering guide to generating a secure eClinicalWorks MCP server and connecting it to ChatGPT to automate FHIR R4 medical record workflows. tldr: "Learn how to bypass EHR integration complexities by generating an eClinicalWorks MCP server with Truto. Connect directly to ChatGPT to query patient data, analyze clinical notes, and manage FHIR resources using natural language." canonical: https://truto.one/blog/connect-eclinicalworks-to-chatgpt-manage-patient-medical-records/ --- # Connect eClinicalWorks to ChatGPT: Manage patient medical records If you need to connect eClinicalWorks to ChatGPT to automate pre-visit chart summaries, analyze lab results, or audit medication requests, you need a [Model Context Protocol (MCP) server](https://truto.one/what-is-mcp-model-context-protocol-the-2026-guide-for-saas-pms/). This server acts as the translation layer between ChatGPT's JSON-RPC tool calls and eClinicalWorks's complex FHIR R4 APIs. You can either build, host, and maintain this EHR infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL in seconds. If your team uses Claude, check out our guide on [connecting eClinicalWorks to Claude](https://truto.one/connect-eclinicalworks-to-claude-analyze-clinical-notes-and-labs/) or explore our broader architectural overview on [connecting eClinicalWorks to AI Agents](https://truto.one/connect-eclinicalworks-to-ai-agents-automate-ehr-data-workflows/). Giving a Large Language Model (LLM) read and write access to a production Electronic Health Record (EHR) system is a massive engineering challenge. You have to handle deeply nested FHIR data payloads, map dynamic clinical concepts to MCP tool definitions, and ensure strict [zero-data-retention access controls](https://truto.one/zero-data-retention-for-ai-agents-why-pass-through-architecture-wins/) to maintain HIPAA compliance. Every time an API schema shifts, your custom server code must be updated, tested, and redeployed. This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for eClinicalWorks, connect it natively to ChatGPT, and execute complex medical record workflows using natural language. > Stop writing boilerplate EHR integration code. Let Truto generate secure, HIPAA-ready MCP servers for your AI agents in seconds. > > [Talk to us](https://truto.one/book-a-demo/) ## The Engineering Reality of the eClinicalWorks API A custom MCP server is essentially a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, implementing it against eClinicalWorks's highly specific API is exceptionally painful for engineering teams. If you decide to [build a custom MCP server](https://truto.one/the-hands-on-guide-to-building-mcp-servers-for-ai-agents-2026/) for eClinicalWorks, you own the entire API lifecycle. Here are the specific integration challenges that break standard CRUD assumptions when working with this EHR platform: ### The FHIR R4 Schema Complexity eClinicalWorks exposes its data via the HL7 FHIR (Fast Healthcare Interoperability Resources) R4 standard. While standardized, FHIR is notoriously verbose and highly relational. A simple "medication" isn't a flat object; it requires querying a `MedicationRequest`, which contains a `medicationReference`, which then points to a separate `Medication` resource. If you try to hand-code MCP tool schemas for these payloads, you will spend weeks just writing TypeScript types to prevent the LLM from hallucinating nested clinical structures. ### Mandatory Search Constraints Unlike typical SaaS APIs where you can simply hit `GET /api/encounters` to list everything, the eClinicalWorks API enforces strict contextual boundaries. To retrieve clinical data, you almost always must provide a specific `patient` identifier. Endpoints like `list_all_e_clinical_works_conditions` or `list_all_e_clinical_works_diagnostic_reports` will outright fail without this context. Your MCP tool definitions must explicitly enforce these required query parameters so ChatGPT knows it has to retrieve the Patient ID first before asking for their vitals. ### Base64 C-CDA Binary Attachments Clinical notes and Continuity of Care Documents (C-CDAs) in eClinicalWorks are not returned as clean markdown or text. They are returned as FHIR `DocumentReference` resources containing attachments, which point to `Binary` resources. Retrieving the actual clinical narrative requires the AI agent to fetch the `DocumentReference`, extract the Binary ID, fetch the `Binary` resource, and then decode the base64 payload. Without highly curated, descriptive MCP tools, an LLM will completely fail to navigate this multi-step extraction. ## Generating the eClinicalWorks MCP Server Truto completely abstracts away the underlying FHIR schema generation and OAuth token management. Every eClinicalWorks integration connected through Truto automatically derives a set of documentation-driven MCP tools mapped to the exact resources available on the account. You can generate the MCP server endpoint for eClinicalWorks in two ways: via the Truto dashboard or programmatically via the API. ### Method 1: Via the Truto UI For internal AI agents or rapid prototyping, the UI is the fastest path. 1. Navigate to the **Integrated Accounts** page in your Truto dashboard. 2. Select your connected eClinicalWorks account. 3. Click the **MCP Servers** tab. 4. Click **Create MCP Server**. 5. Select your desired configuration (e.g., restrict to `read` methods only, or filter by specific `tags` like `clinical` or `demographics`). 6. Copy the generated MCP server URL (e.g., `https://api.truto.one/mcp/a1b2c3d4...`). Treat this URL as a sensitive credential. ### Method 2: Via the Truto API For production multi-tenant architectures, you should provision MCP servers dynamically when your users connect their eClinicalWorks accounts. Make a `POST` request to the `/integrated-account/:id/mcp` endpoint to generate a secure, scoped server URL: ```bash curl -X POST https://api.truto.one/integrated-account//mcp \ -H "Authorization: Bearer $TRUTO_API_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "name": "ChatGPT Clinical Assistant", "config": { "methods": ["read"], "tags": ["patient", "clinical", "diagnostics"] }, "expires_at": "2026-12-31T23:59:59Z" }' ``` The response returns a highly secure, hashed endpoint URL: ```json { "id": "mcp_abc123", "name": "ChatGPT Clinical Assistant", "url": "https://api.truto.one/mcp/f8e9d0c1b2a3...", "config": { "methods": ["read"], "tags": ["patient", "clinical", "diagnostics"] } } ``` ### A Critical Note on Rate Limits When routing LLM tool calls through the MCP server, you must account for eClinicalWorks's upstream API limits. **Truto does not retry, throttle, or apply backoff on rate limit errors.** When the eClinicalWorks API returns an HTTP 429 Too Many Requests, Truto passes that exact error straight back to the caller (your LLM client or agent framework). However, Truto does normalize the upstream rate limit information into standard IETF headers across all integrations: * `ratelimit-limit` * `ratelimit-remaining` * `ratelimit-reset` The caller (or the agent orchestrator) is strictly responsible for inspecting these headers, implementing backoff logic, and retrying the tool call. Do not rely on the integration layer to absorb these errors. ## Connecting the MCP Server to ChatGPT Once you have the `url` from Truto, you need to expose it to your ChatGPT instance. You can do this natively in the ChatGPT interface or via a local proxy if you are running a custom agent framework. ### Method A: Via the ChatGPT UI OpenAI now supports connecting remote MCP servers directly in the ChatGPT client for specific account tiers (Pro, Plus, Business, Enterprise, and Education) with Developer Mode enabled. 1. Open ChatGPT and navigate to **Settings -> Apps -> Advanced settings**. 2. Enable the **Developer mode** toggle. 3. Under **MCP servers / Custom connectors**, click **Add**. 4. Enter a descriptive name (e.g., "eClinicalWorks EHR (Truto)"). 5. Paste the Truto MCP URL into the **Server URL** field. 6. Save the configuration. ChatGPT will immediately ping the `/initialize` endpoint, parse the available tools, and make them available in your chat sessions. ### Method B: Via Manual Config File (SSE Proxy) If you are using a desktop client that only supports local stdio MCP servers (like Cursor or older configurations of Claude Desktop), you can bridge the remote Truto server using the official Server-Sent Events (SSE) proxy. Add the following configuration to your MCP settings JSON file: ```json { "mcpServers": { "eclinicalworks-truto": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-sse", "--url", "https://api.truto.one/mcp/f8e9d0c1b2a3..." ] } } } ``` Restart your client. The proxy will tunnel the local JSON-RPC stdio commands over HTTP to Truto's secure endpoint. ## Hero Tools for eClinicalWorks Truto dynamically generates tools based on the eClinicalWorks FHIR resources. Here are the highest-leverage tools your AI agents can use to orchestrate clinical data workflows. ### 1. Get Single Patient by ID Fetches the foundational FHIR R4 Patient resource. This is almost always the first tool ChatGPT must call, as the `id` returned here is required as a query parameter for fetching downstream clinical data. **Contextual usage:** The model uses this to extract demographic info (name, telecom, gender) and obtain the exact patient ID needed for querying encounters or labs. > "Find the patient record for ID 'pt-8472' and tell me their active contact information." ### 2. List All Conditions Searches the patient's active and historical problem list, encounter diagnoses, and health concerns. **Contextual usage:** Requires the `patient` ID parameter. The AI uses this to build a summary of the patient's chronic conditions or acute issues prior to an upcoming visit. > "Fetch all active conditions for the patient we just looked up. Filter out anything marked as resolved or inactive in the clinicalStatus." ### 3. List All Medication Requests Retrieves the FHIR R4 MedicationRequest resources, representing the patient's active prescriptions and historical medication orders. **Contextual usage:** Requires the `patient` ID parameter. ChatGPT can use this to review medication adherence or prepare refill summaries. Note that the actual medication name often requires resolving the `medicationReference` if not provided inline. > "List all medication requests for this patient. Give me a clean table showing the medication intent, status, and priority." ### 4. List All Encounters Retrieves the history of patient visits, admissions, or telehealth sessions. **Contextual usage:** Requires the `patient` ID parameter. Essential for building timelines of care. The response includes `status`, `class`, and `serviceType` to help the AI differentiate between an ER visit and a routine checkup. > "Get the encounter history for this patient over the last six months. Summarize the dates and the service types provided." ### 5. List All Diagnostic Reports Searches for lab results, imaging reports, and associated clinical notes for the patient. **Contextual usage:** Requires the `patient` ID parameter. The AI uses this to pull the metadata for critical lab results before deciding if it needs to fetch the underlying binary document. > "Check the diagnostic reports for this patient. Are there any recent lipid panels or A1C results?" ### 6. Get Single Binary by ID Fetches a base64 encoded C-CDA clinical document or raw attachment associated with a DocumentReference. **Contextual usage:** Requires the `id` of the Binary resource. ChatGPT is highly capable of taking the base64 string, decoding it in its execution environment, and parsing the raw clinical text to summarize discharge notes or specialist consults. > "Fetch the Binary resource ID 'bin-9921' attached to that last diagnostic report. Decode the base64 content and summarize the radiologist's findings." To view the full schema details, required parameters, and the complete inventory of available EHR tools, visit the [eClinicalWorks integration page](https://truto.one/integrations/detail/eclinicalworks). ## Workflows in Action Once connected, ChatGPT can autonomously chain these tools together to execute complex clinical workflows. Here are two real-world scenarios. ### Scenario 1: Pre-Visit Chart Summarization **Persona:** Triage Nurse / Medical Assistant > "I have a patient coming in this afternoon. Their ID is 'pt-445'. Please build a pre-visit summary including their active conditions, recent encounters from the last 30 days, and any pending medication requests." **Execution Steps:** 1. **`get_single_e_clinical_works_patient_by_id`**: ChatGPT fetches the demographic baseline to confirm identity. 2. **`list_all_e_clinical_works_conditions`**: It queries the active problem list, filtering for active clinical statuses. 3. **`list_all_e_clinical_works_encounters`**: It fetches recent visits, looking for context on why the patient is returning. 4. **`list_all_e_clinical_works_medication_requests`**: It pulls the current prescription list to prep the physician for medication reconciliation. **Result:** The user receives a neatly formatted, Markdown-based clinical summary derived directly from real-time EHR data, ready to be reviewed before stepping into the exam room. ```mermaid sequenceDiagram participant User as User (Nurse) participant GPT as ChatGPT participant MCP as Truto MCP Server participant Upstream as "Upstream API (eClinicalWorks)" User->>GPT: "Build a pre-visit summary for ID pt-445" GPT->>MCP: Call get_single_e_clinical_works_patient_by_id(id: "pt-445") MCP->>Upstream: GET /Patient/pt-445 Upstream-->>MCP: FHIR R4 Patient Resource MCP-->>GPT: Patient Demographics GPT->>MCP: Call list_all_e_clinical_works_conditions(patient: "pt-445") MCP->>Upstream: GET /Condition?patient=pt-445 Upstream-->>MCP: FHIR R4 Condition Bundle MCP-->>GPT: Active Conditions GPT->>MCP: Call list_all_e_clinical_works_medication_requests(patient: "pt-445") MCP->>Upstream: GET /MedicationRequest?patient=pt-445 Upstream-->>MCP: FHIR R4 MedicationRequest Bundle MCP-->>GPT: Active Prescriptions GPT-->>User: Markdown Pre-Visit Summary ``` ### Scenario 2: Post-Encounter Lab Review **Persona:** Primary Care Physician > "Look up the patient with ID 'pt-892'. Find their most recent diagnostic report. If it has an attachment, fetch the document and summarize the lab results." **Execution Steps:** 1. **`get_single_e_clinical_works_patient_by_id`**: Verifies the patient. 2. **`list_all_e_clinical_works_diagnostic_reports`**: ChatGPT searches for recent labs and identifies a report with a `presentedForm` attachment pointing to a Binary ID. 3. **`get_single_e_clinical_works_binary_by_id`**: ChatGPT requests the specific attachment. 4. **Internal Decoding**: The model receives the base64 payload, processes the text, and extracts the core findings. **Result:** The physician receives an immediate natural language breakdown of the lab results without having to click through five different nested menus in the eClinicalWorks UI. ## Security and Access Control Exposing EHR data to an LLM requires strict boundary enforcement. Truto's MCP servers are designed with security primitives that ensure ChatGPT only accesses exactly what you authorize. * **[Zero Data Retention](https://truto.one/zero-data-retention-for-ai-agents-why-pass-through-architecture-wins/):** Truto acts purely as a pass-through proxy. It routes the JSON-RPC tool calls, normalizes the FHIR payload, and returns the response to ChatGPT. Truto never caches or stores the underlying PHI. * **Method Filtering:** When creating the MCP server, you can restrict the `config.methods` to `["read"]`. This guarantees the server will never generate `create`, `update`, or `delete` tools, preventing the AI from accidentally altering clinical records. * **Tag Filtering:** You can aggressively scope the available toolset by providing `config.tags` (e.g., `["demographics"]`). Tools belonging to untagged resources (like `medication_requests` or `binary`) simply won't exist on that server URL. * **Time-To-Live (TTL):** By passing an `expires_at` ISO datetime during server creation, you can generate ephemeral access. Once the timestamp passes, the endpoint is cryptographically destroyed, instantly revoking ChatGPT's access. * **Required API Token Auth:** By enabling `require_api_token_auth: true`, possession of the MCP URL is no longer sufficient. The ChatGPT client must also pass a valid Truto API token in the `Authorization` header, providing a secondary layer of enterprise authentication. ## Final Thoughts Connecting an AI agent to an EHR like eClinicalWorks used to require months of wrangling OAuth flows, studying FHIR specifications, and building custom integration microservices. By leveraging the open [Model Context Protocol](https://truto.one/what-is-mcp-model-context-protocol-the-2026-guide-for-saas-pms/) and Truto's dynamic, documentation-driven tool generation, you can completely sidestep that infrastructure burden. You get a secure, FHIR-compliant bridge between ChatGPT and eClinicalWorks in minutes, allowing your engineering team to focus on building agentic clinical workflows rather than maintaining point-to-point API connectors.