--- title: "Connect Tebra to Claude: Manage Care Plans, Conditions, and Results" slug: connect-tebra-to-claude-manage-care-plans-conditions-and-results date: 2026-10-13 author: Riya Sethi categories: ["AI & Agents"] excerpt: "Learn how to securely connect Tebra to Claude using a managed MCP server. This guide covers FHIR R4 tool generation, clinical workflows, and access control." tldr: "Connect Tebra to Claude using Truto's managed MCP server to automate clinical workflows. Learn to query FHIR R4 records, manage care plans, and enforce read-only access without building integration infrastructure." canonical: https://truto.one/blog/connect-tebra-to-claude-manage-care-plans-conditions-and-results/ --- # Connect Tebra to Claude: Manage Care Plans, Conditions, and Results If your clinical operations team needs to connect Tebra to Claude to automate patient intake summaries, query FHIR records, review active conditions, or assemble care plans, you need a [Model Context Protocol (MCP) server](https://truto.one/what-is-mcp-and-mcp-servers-and-how-do-they-work/). This server acts as the translation layer between Claude's natural language tool calls and Tebra's complex clinical APIs. You can either construct and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on [connecting Tebra to ChatGPT](https://truto.one/connect-tebra-to-chatgpt-access-patient-records-and-clinical-data/) or explore our broader architectural overview on [connecting Tebra to AI Agents](https://truto.one/connect-tebra-to-ai-agents-sync-medical-summaries-and-clinical-fhir/). Giving a Large Language Model (LLM) read and write access to an Electronic Health Record (EHR) and practice management system like Tebra is a serious engineering undertaking. You have to handle OAuth 2.0 token lifecycles, translate massive FHIR R4 JSON schemas into flat MCP tool definitions, and deal with strict US Core data constraints. Every time Tebra deprecates an endpoint or updates a clinical data model, you have to update your server code, redeploy, and test the integration. This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Tebra, connect it natively to Claude Desktop, and execute complex clinical workflows using natural language. > Want to give your AI agents secure, authenticated access to Tebra and 100+ other SaaS APIs? Let's talk about [managed MCP architecture](https://truto.one/managed-mcp-for-claude-full-saas-api-access-without-security-headaches/). > > [Talk to us](https://truto.one/book-a-demo/) ## The Engineering Reality of the Tebra API A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools over JSON-RPC 2.0, the reality of implementing it against a highly regulated, dual-surface healthcare API is painful. 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 Tebra, you own the entire API lifecycle. Here are the specific integration challenges you will face: ### The Dual-Surface API Architecture Tebra actually exposes two distinct API surfaces: standard FHIR R4 endpoints and a proprietary Clinical REST API. The FHIR R4 endpoints are designed around the US Core / USCDI v1 specifications and rely on standard resource schemas like `CarePlan`, `Condition`, and `Patient`. The Clinical REST API, however, is heavily tied to the identity of the user who owns the API key. For example, querying `/patient/clinical/problems` automatically scopes the data to the API key owner without requiring a patient ID in the payload. An LLM has no concept of this identity context. You must build an abstraction layer that explicitly scopes tools to the correct API surface and prevents the LLM from hallucinating required parameters. ### Strict Searchset Bundles and Dependency Chains Tebra's FHIR APIs do not allow simple "list everything" queries. They require specific parameter combinations to prevent massive data dumps. For example, you cannot query the `Provenance` resource blindly. The API requires you to send a `patient` parameter or an `_id` parameter alongside `_revinclude=Provenance:target`. If the LLM sends a request without these exact combinations, Tebra rejects it. A properly built MCP server must inject these requirements into the JSON Schema definitions presented to the LLM, acting as a strict guardrail before the API call is ever made. ### Rate Limits and Header Normalization Tebra enforces strict API quotas to protect EHR stability. An LLM executing a multi-step diagnostic workflow can easily trigger an HTTP 429 Too Many Requests error. **A critical factual note on how Truto handles rate limits:** Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Tebra API returns an HTTP 429, Truto passes that error directly to the caller. What Truto *does* do is normalize the upstream rate limit information into standardized headers (`ratelimit-limit`, `ratelimit-remaining`, `ratelimit-reset`) per the IETF specification. The caller (in this case, your custom MCP client architecture) is strictly responsible for interpreting these headers and executing retry and backoff logic. Truto does not magically absorb rate limit errors. ## Creating the Tebra MCP Server Truto derives MCP tools dynamically from Tebra's OpenAPI specifications and internal documentation records. Tools are generated at runtime - they are never cached or pre-built. You can create a Tebra MCP server using either the Truto UI or the REST API. ### Method 1: Via the Truto UI For administrators and operators, creating an MCP server via the dashboard is the fastest path: 1. Log into your Truto environment and navigate to the **Integrated Accounts** page. 2. Select your connected Tebra account. 3. Click the **MCP Servers** tab. 4. Click **Create MCP Server**. 5. Select your desired configuration. You can filter the server to only allow `read` methods or restrict it to specific tool tags (e.g., `clinical`, `billing`). 6. Copy the generated MCP server URL. (e.g., `https://api.truto.one/mcp/a1b2c3d4e5f6...`) ### Method 2: Via the Truto API For platform engineers building multi-tenant AI products, MCP servers can be generated programmatically. This endpoint creates a secure token, hashes it for storage in a fast global distributed key-value store, and returns the URL. **Request:** ```bash curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \ -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "name": "Tebra Clinical Assistant MCP", "config": { "methods": ["read", "write"], "tags": ["clinical", "patient_records"] }, "expires_at": "2026-12-31T23:59:59Z" }' ``` **Response:** ```json { "id": "mcp_srv_9x8y7z6w", "name": "Tebra Clinical Assistant MCP", "config": { "methods": ["read", "write"], "tags": ["clinical", "patient_records"] }, "expires_at": "2026-12-31T23:59:59Z", "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890" } ``` The raw token in the URL is never stored in plain text. It is HMAC-hashed before being written to the database, ensuring that even a database compromise does not expose your MCP credentials. ## Connecting the Tebra MCP Server to Claude Once you have your Truto MCP server URL, you need to connect it to your Claude environment. Since Truto exposes tools via HTTP POST and JSON-RPC 2.0, you can connect it directly to the Claude Desktop app. ### Method 1: Via the Claude UI (If supported by your plan) If your Claude organization supports custom remote connectors in the UI: 1. Open Claude and navigate to **Settings -> Integrations -> Add MCP Server**. 2. Paste the Truto MCP URL (`https://api.truto.one/mcp/...`). 3. Click **Add**. 4. Claude will perform an `initialize` handshake, request the `tools/list`, and immediately populate your chat interface with Tebra capabilities. ### Method 2: Via Manual Config File (Claude Desktop) For developers using the Claude Desktop app, you must update the `claude_desktop_config.json` file. Because Claude Desktop typically expects local scripts, you use the `@modelcontextprotocol/server-sse` package to bridge Claude's standard IO transport to Truto's remote endpoint. Locate your config file: - **macOS:** `~/Library/Application Support/Claude/claude_desktop_config.json` - **Windows:** `%APPDATA%\Claude\claude_desktop_config.json` Update the configuration: ```json { "mcpServers": { "tebra-clinical": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-sse", "https://api.truto.one/mcp/YOUR_TEBRA_MCP_TOKEN" ] } } } ``` Restart Claude Desktop. The agent will read the config, fetch the remote Tebra tools, and they will appear as a recognizable "hammer" icon in your prompt bar. ## Hero Tools for Tebra Clinical Data Truto normalizes dozens of Tebra endpoints into clean, predictable MCP tools. The LLM receives a flat input namespace, and Truto automatically routes arguments to the correct query parameters or request body payload based on the internal schema. Here are six high-leverage tools for clinical workflows. ### list_all_tebra_patients Searches patient records in Tebra using the FHIR R4 Patient search standard (US Core / USCDI v1). The model must provide at least one parameter such as `_id`, `identifier`, `name`, or `birthdate`. It returns matching FHIR Patient resources from the searchset Bundle. > "Find the patient record for John Doe born on 1985-04-12. I need his FHIR logical ID for a follow-up query." ### list_all_tebra_conditions Searches for active problems, health concerns, or encounter diagnoses. This maps to the FHIR R4 Condition resource. It returns clinical status, categories, condition codes, and onset dates. The `patient` parameter is strictly required. > "List all active conditions and health concerns for patient ID 883921. Highlight any conditions with an onset date in the last six months." ### list_all_tebra_care_plans Queries care plan records in Tebra (FHIR R4 CarePlan). It requires both the `patient` ID and a `category` parameter. This is essential for reviewing ongoing treatments, intents, and specific clinical activities assigned to a patient. > "Fetch the current care plans for patient ID 883921. Filter by category if required, and summarize the active clinical intents." ### list_all_tebra_diagnostic_reports Retrieves laboratory test reports and diagnostic results (FHIR R4 DiagnosticReport). It returns the status, category, issued date, and nested observation results. Requires the `patient` ID. > "Get the diagnostic reports for patient ID 883921. Extract the results from the most recent blood panel and list the observation codes." ### list_all_tebra_medication_requests Searches medication requests and prescriptions (FHIR R4 MedicationRequest). It returns the clinical status, intent, medication codes (RxNorm), and dosage instructions. Requires the `patient` and `intent` parameters. > "Find all active medication requests for patient ID 883921 with an intent of 'order'. Detail the dosage instructions for each medication." ### list_all_tebra_clinical_summaries This tool accesses Tebra's Clinical REST API to generate a C-CDA 2.1 summary document (Common Clinical Data Set) for the API key's associated patient. It returns the content type and a base64 encoded document. > "Generate a clinical summary document for the current patient context and decode the base64 output to extract the social history and vitals." For a complete list of all supported FHIR R4 and Clinical REST operations, including locations, procedures, and immunizations, view the [Tebra integration page](https://truto.one/integrations/detail/tebra). ## Workflows in Action By providing Claude with this toolset, you enable multi-step clinical intelligence. The LLM can autonomously sequence queries, passing the outputs of one tool as the inputs to the next. Here are two real-world scenarios. ### Scenario 1: Pre-Visit Clinical Briefing A Medical Assistant asks Claude to prepare a summary for an upcoming appointment. > "Prepare a clinical briefing for Sarah Connor (born 1979-11-05). I need her active conditions, any medications she is currently prescribed, and the results of her latest diagnostic reports." **Step-by-step execution:** 1. Claude calls `list_all_tebra_patients` with `name="Sarah Connor"` and `birthdate="1979-11-05"` to extract her FHIR logical ID (e.g., `pt-4455`). 2. Claude calls `list_all_tebra_conditions` using `patient="pt-4455"` to retrieve her problem list. 3. Claude calls `list_all_tebra_medication_requests` using `patient="pt-4455"` and `intent="order"` to pull her active RxNorm codes and dosage instructions. 4. Claude calls `list_all_tebra_diagnostic_reports` using `patient="pt-4455"` to fetch the latest labs. 5. Claude compiles the data into a structured markdown briefing, highlighting key risks and recent lab anomalies. ### Scenario 2: Care Plan Review A Physician needs to verify if a patient's care plan aligns with recent lab results. > "Review the care plan for patient ID pt-8822. Check their latest diagnostic reports to see if their A1C levels have dropped, and tell me if the care plan activities reflect this change." ```mermaid sequenceDiagram participant Clinician as Clinician participant Claude as Claude Desktop participant Truto as Truto MCP Server participant Tebra as Tebra API Clinician->>Claude: "Review care plan and labs for pt-8822" Claude->>Truto: call list_all_tebra_care_plans(patient="pt-8822", category="assess-plan") Truto->>Tebra: GET /CarePlan?patient=pt-8822&category=assess-plan Tebra-->>Truto: 200 OK (CarePlan Bundle) Truto-->>Claude: JSON Tool Result Claude->>Truto: call list_all_tebra_diagnostic_reports(patient="pt-8822") Truto->>Tebra: GET /DiagnosticReport?patient=pt-8822 Tebra-->>Truto: 200 OK (Diagnostic Bundle with A1C) Truto-->>Claude: JSON Tool Result Claude->>Clinician: Summarizes A1C trends and compares against CarePlan activities ``` ## Security and Access Control Clinical data requires the highest level of security. When exposing Tebra to an LLM via Truto, you are not simply handing over a raw API key. Truto provides distinct [MCP security primitives](https://truto.one/mcp-server-security-zero-data-retention-2026-implementation-guide/) to control agent behavior: * **Method Filtering:** You can restrict a Tebra MCP server to only allow `read` operations (like `get` and `list`). This guarantees the AI agent cannot accidentally create a false condition or delete a care plan, strictly enforcing read-only access. * **Tag Filtering:** By configuring the server with specific tags (e.g., `"clinical"`), you can hide administrative tools (like billing or organization management) from the LLM entirely, reducing the tool-selection surface area and preventing hallucinated tool calls. * **Dual Authentication (`require_api_token_auth`):** By default, possessing the MCP URL grants access. By enabling the `require_api_token_auth` flag, the client must also pass a valid Truto API token in the `Authorization` header. The request is processed by a conditional middleware layer, ensuring that leaked URLs cannot be exploited. * **Ephemeral Servers (`expires_at`):** You can generate temporary MCP servers with an ISO datetime expiration. Once the time is reached, durable timers trigger a cleanup routine that completely destroys the server token in the distributed key-value store, immediately cutting off AI access. ## Strategic Wrap-Up Connecting Tebra to Claude using MCP transforms how clinical teams interact with patient data. Instead of forcing providers to click through dozens of EHR tabs to synthesize a patient history, an AI agent can execute targeted FHIR queries and return a unified briefing in seconds. Building this orchestration layer from scratch means dedicating engineering cycles to FHIR schema mapping, OAuth refreshes, and rate limit header normalization. By using Truto, you offload the infrastructure completely. You generate the MCP server, provide the URL to Claude, and focus your engineering talent on building superior clinical AI features rather than untangling integration technical debt.