EHR Integration
AI agents for Tebra
Caesar Health runs the administrative work around Tebra: the phone, the fax line, intake, scheduling, follow-up and the revenue-cycle work. Results are written back into Tebra, and Tebra stays the system of record.
Your patient record
Your administrative workAPI connection
Tebra stays your system of record.
About Tebra
Tebra (formerly Kareo and PatientPop) is a cloud EHR, practice-management, and patient-engagement platform for independent and smaller practices.
Tebra (the combination of Kareo and PatientPop) is built for independent and small practices that run without a large administrative team. That is precisely where autonomous agents make a small office operate like a much larger one — coverage across every channel, 24/7, at a fraction of the staffing cost.
Tebra API documentation: what the API actually is
If you came here to learn how the Tebra API works, this is the summary.
Tebra has two APIs, and they do different jobs. Confusing them is the most common mistake in scoping a Tebra integration.
1. The SOAP API, where writes happen
Tebra Web Services API 2.1 comes from the Kareo platform (Kareo and PatientPop became Tebra). The WSDL still lives on the Kareo host: webservice.kareo.com/services/soap/2.1/KareoServices.svc?singleWsdl.
Authentication has three parts: a CustomerKey, a username and a password, carried in the RequestHeader of every SOAP envelope. There's no OAuth and no API key. Credentials travel inside each call, so transport security and credential handling fall on the integrator. Your own system administrator generates the customer key and sets the permissions that bound what the integration can reach.
Operations:
| Operation | Entities |
|---|---|
| Get | Appointments, appointment reasons, charges, encounter details, patients, payments, practices, procedure codes, providers, service locations, transactions |
| Create | Appointment, Document, Encounter, Patient, Payments |
| Update | Appointment, appointment status, encounter status, patient, primary patient case |
| Delete | Appointment, Document |
Rate limits are published per operation, and they're tight. GetPatients, GetCharges, GetAppointments, GetPayments and UpdatePatient allow one call per second; GetAllPatients one call every five seconds. Going over returns HTTP 429. Tebra's guidance is to poll as rarely as possible and schedule bulk work after hours.
Tebra also offers ExternalId fields on many entities, such as PatientExternalId, so an integrator can stamp its own identifiers onto Tebra records. That makes reconciliation cleaner than matching on name and date of birth.
Access is controlled by you. A system administrator raises a Customer Care case to obtain the customer key, then grants the API user the right permissions.
2. The FHIR API
Tebra also publishes a FHIR R4 API against US Core, at fhir.prd.cloud.tebra.com/fhir-request, running on Smile CDR. Auth is OAuth 2.0 with SMART on FHIR. It's built for data access across the US Core resources: Patient, Condition, Encounter, Observation, MedicationRequest, DocumentReference and the rest.
Registration is reviewed by Tebra, and there's a FHIR sandbox. Patient-facing read access carries no fee; clinician-facing and bulk-export applications need registration with the practice, signed business documents and additional fees. Tebra EHR is certified to §170.315(g)(10).
What this means for a clinical note
Neither API documents an endpoint for a coded, structured clinical note. The SOAP API creates a document against the patient with CreateDocument. That puts the note in the chart as a document, not as discrete, coded data.
More on the mechanics: how the EMR integration layer works.
Does Caesar write back into Tebra, or does my staff re-key it?
It writes back. Scheduling and patient administration go into Tebra; the note goes in as a document.
| Capability | On Tebra |
|---|---|
| Inbound and outbound calls, warm transfer to staff | Caesar's own telephony |
| Call recording, transcript, summary | In Caesar |
| SMS reminders, no-show follow-up, balance reminders | Caesar's own messaging |
| Inbound and outbound fax | Caesar's own fax line |
| Tasks, review queue, audit trail | In Caesar |
| Patient search and create | Written to Tebra through the EMR Integration Layer |
| Open slots, booking, rescheduling, cancellation, confirmation | Written to Tebra through the EMR Integration Layer |
| Filing a note or fax to the patient's chart | Filed as a document in Tebra |
Where an API doesn't reach, Caesar's web agent works Tebra's own screens as a named user, from workflows recorded for your practice.
So on Tebra a deployment usually looks like this: Caesar answers the phone, finds or creates the patient, books the appointment, and handles the fax and follow-up around it. Documentation stays with the tool inside Tebra.
On athenahealth and ModMed Caesar writes structured notes, and those pages name the endpoints. The difference is the API.
Tebra ships AI Note Assist. Caesar works around the visit.
AI Note Assist is Tebra's ambient scribe, built directly into the Tebra EHR. It captures the conversation and generates the note without the clinician switching tools.
So a Tebra practice has a scribe choice already, inside the chart. Caesar's surface is the work around the visit:
- The calls that come in while everyone is in a room, and the ones after five.
- The faxed results and referrals that arrive as paper.
- The intake and insurance that should be done before the patient arrives.
- The follow-up and the recall nobody made.
Keep Tebra. Keep AI Note Assist. Caesar still has a full day's work. How Caesar compares to a scribe.
What your staff stops doing
| Today | With Caesar |
|---|---|
| Answering the phone through lunch and after hours | The phone agent answers every call, 24/7 |
| Taking messages that turn into callbacks | The agent handles the request on the call |
| Typing a new patient's details in from a voicemail | Captured on the call and written to Tebra |
| Retyping faxed results and referrals | The Document Inbox reads, extracts, matches and routes them |
| Chasing intake forms and insurance cards | Intake is collected before the visit |
| Sending reminders and follow-ups by hand | Reminders, no-show follow-up and balance reminders go out by SMS, on a per-clinic cadence with quiet hours |
| Calling down a cancellation list | Freed slots go to patients on the waitlist |
How Caesar Health connects to Tebra
Tebra is API-forward, so Caesar Health connects through its FHIR and API surface — reading patient, scheduling, and billing context and writing every result back. Tebra stays the system of record. No rip-and-replace, no migration — the agents run alongside the system your clinicians already use.
FHIR API
Modern, standards-based read/write where the EMR exposes FHIR.
HL7 v2 messaging
The interface standard most EMRs already speak for orders, results, and ADT.
Direct database
Secure direct access where APIs don’t reach the data.
Interface-level layer
For legacy or no-API systems — connects at the screen level, no vendor cooperation required.
Every Caesar Health agent, on Tebra
All 14 agents read from and write back to Tebra. Here’s what each one does inside your workflow, with the Revenue Cycle agent broken out by function.
Communication
Answers and places patient calls and books, reschedules, and cancels appointments directly in Tebra.
Reads inbound faxes, classifies each one, and files it to the right chart in Tebra.
Triages patient and provider email, drafts replies, and logs the thread against the patient in Tebra.
Runs two-way patient texting — reminders, confirmations, and rescheduling — synced to the Tebra schedule.
Answers questions on your website and books visits straight into the Tebra schedule, 24/7.
Clinical
Patient Experience
Collects intake and insurance, verifies eligibility, and writes the new patient and visit into Tebra.
Sends diagnosis- and medication-specific education based on the encounter recorded in Tebra.
Optimizes scheduling, fills cancellations from the waitlist, and keeps the Tebra calendar full.
Revenue Cycle
Codes the encounter, scrubs the claim, and posts charges to Tebra for a clean first-pass submission.
Detects when a PA is required, pulls the clinical detail from Tebra, submits it, and tracks it to approval.
Catches denials, finds the root cause, corrects the claim in Tebra, and files the appeal.
Auto-posts EDI 835 remits and patient payments against the right claims in Tebra, and flags underpayments.
Care Coordination
Reads Tebra data to find open quality-measure gaps and runs the outreach to close them.
Sends and tracks referrals end to end and closes the loop with results back in Tebra.
Runs chronic-care and remote-monitoring check-ins and keeps the care plan and readings updated in Tebra.
Built for healthcare
- HIPAA-compliant, BAA available
- SOC 2 Type II in progress
- End-to-end encryption, in transit and at rest
- Full audit log of every AI action
- Human-in-the-loop review where you want it
- Tebra remains the system of record
Tebra + Caesar Health — FAQ
Does Caesar Health replace Tebra?+
No. Tebra stays the EHR and practice-management system of record. Caesar automates the phone, fax, intake and follow-up around it. No migration, no data conversion.
What kind of API does Tebra have?+
Two. A SOAP API from Kareo, authenticated with a customer key, username and password in every envelope, which is where writes happen. And a FHIR R4 API on Smile CDR with OAuth 2.0 and SMART on FHIR, built for data access.
Does the note write back into Tebra?+
As a document. Tebra's SOAP API creates documents against the patient, so a finished note or a faxed record files to the chart. Neither Tebra API documents a coded, structured note write.
We already use AI Note Assist. Why would we add Caesar?+
AI Note Assist documents the visit. Caesar answers the phone, works fax, runs intake, books appointments and handles follow-up. Keep AI Note Assist; the two do different jobs.
Do we need Tebra's permission?+
You need a customer key, which a system administrator in your practice generates along with the permissions that scope the integration. You issue it and you can revoke it.
Is it HIPAA compliant?+
Yes. Caesar signs a BAA. PHI is encrypted in transit and at rest with customer-managed keys, access is role-based with tenant isolation per organization and location, and access to PHI is logged. SOC 2 Type II is in progress.
Related
- athenahealth: the deepest API write-back Caesar runs, and a reference for what a clinical API can expose
- Nextech: the specialty platform independent practices weigh against Tebra
- All EMR integrations · How the EMR integration layer works
- Agents: phone · Document Inbox · SMS · AI Scribe · patient intake
See Caesar Health run alongside Tebra
Book a live demo on your own Tebra workflows and watch the agents execute real administrative work end to end.
Tebra and all other product names, logos, and brands are trademarks of their respective owners, shown here to indicate compatibility. Their use does not imply endorsement or an official partnership unless explicitly stated.