OpenEMR integration for phone calls and appointment booking

OpenEMR runs thousands of US clinics, yet very few phone or AI receptionist products write to it. The usual advice is "forward calls to a service that emails you the message", which means the front desk retypes every booking. This guide explains how appointment automation actually works against OpenEMR, so you can evaluate any vendor, including us, on the details.

What OpenEMR exposes

Since version 6.0, OpenEMR ships two interfaces that matter here:

• FHIR R4 API for Patient, Appointment, Practitioner, Location and related resources. This is the standards path and the one most integrators should use for reads and patient creation.
• Standard REST API for calendar events, patient notes (pnotes), messages and a few things FHIR does not cover well, such as appointment categories and facility hours.

Both are secured with OAuth2. OpenEMR 6.1 or later is the practical minimum; 7.x is recommended because the appointment and message endpoints are more complete and the API client screen is easier to use.

Step 1: register an API client

In Administration → System → API Clients, register the integration as a confidential client with the scopes it needs: patient/Patient.read, patient/Patient.write (if new patients may be created), patient/Appointment.read and .write, user/Practitioner.read, user/Location.read and the standard-API scopes for calendar and pnotes. Approve the client, then create a dedicated OpenEMR user (for example "Clinic Answering Service Assistant") so that every write is attributed to the integration in OpenEMR's own audit log. Never share a staff member's login.

Step 2: map facilities, providers and categories

OpenEMR calendar events carry a category (Office Visit, New Patient, Established Patient, Telehealth and whatever you have added), a provider, a facility and a duration. The integration should list these and let you decide which categories the phone assistant may book and the default length for each. A good rule: start with two or three categories, add more after the first week.

Step 3: reading availability

Availability is not a single endpoint. It is the provider's "In Office" and "Out Of Office" calendar events, the facility hours and the existing appointments, combined. The integration should compute open slots from those three sources, respect buffer rules you set (for example no new patients in the last slot of the day) and offer the caller two concrete options rather than reading a list.

Step 4: matching the caller to a patient

Phone number first, then name and date of birth confirmed on the call. If two records match, ask one more identifier rather than guessing. If none match, either create the patient (if you allow it) or create a provisional record flagged for front-desk review. Duplicate patients are the single most common complaint about phone integrations, so this logic deserves scrutiny in any demo.

Step 5: what to write, and what never to write

Write:

• The appointment, with category, provider, facility, start time and duration.
• Demographics and insurance for a new patient.
• A patient note containing the three-line call summary and a link to the recording.
• The eligibility result (if the integration verifies coverage) against the appointment.
• Refill, results and symptom questions as messages to the right inbox.

Never write to the clinical chart, encounters, orders or prescriptions from a phone call. A refill request is a message for a nurse, not a prescription.

Step 6: test before you forward

Call the demo line from your own phone, book a visit and watch it appear in the OpenEMR calendar. Open the patient and check the note. Cancel from the phone and confirm the slot reopens. Only then forward after-hours calls, and only after a week of clean results forward everything.

Self-hosted installs

If OpenEMR sits behind a firewall, insist on an outbound-only connection (the integration opens a TLS tunnel from inside your network) rather than opening an inbound port. Rotate the client secret on request and review the API client list quarterly.

How Clinic Answering Service does it

Clinic Answering Service is being built next to OpenEMR by the team that hosts it for US clinics. As of October 2026 its OpenEMR adapter runs in sandbox (demo) mode with test references, and a production pilot is planned with Radiatus-hosted OpenEMR clients. The design uses the FHIR and standard APIs exactly as above, with a dedicated service user, category mapping, two-identifier matching, notes and messages rather than clinical writes, and an outbound tunnel for self-hosted installs. Existing Radiatus OpenEMR clients will get no setup fee. See the OpenEMR integration page for the current status and planned setup steps.

Common OpenEMR integration problems and how to fix them

• Slots offered that the provider cannot see. Usually a missing "In Office" event or a facility mismatch. Check that each provider's in-office blocks are on the facility the integration reads.
• Duplicate patients. Caused by matching on name alone. Require phone plus date of birth, and review provisional records weekly for the first month.
• Appointments with the wrong length. Category durations in OpenEMR and in the integration disagree. Set the duration on the mapping, not on each booking.
• 401 errors after an upgrade. OpenEMR upgrades can reset API client approval or scopes. Re-approve the client and re-check scopes after every upgrade.
• Notes landing on the wrong patient. Almost always a shared family phone number. Confirm date of birth on every call, even when the number matches.

What it costs

OpenEMR itself is free, open-source software; your costs are hosting and support. On Clinic Answering Service, OpenEMR write-back will be part of the Practice plan at $349 a month and the Group plan at $699 once released, with a $0 setup fee for existing Radiatus EMR clients; see clinic answering service pricing. Primary care practices on OpenEMR can also read how the AI receptionist for medical practices handles refills, results calls and same-day sick visits.

Questions people ask

Which OpenEMR version do I need?

6.1 or later works; 7.x is recommended because the FHIR Appointment resource and the message endpoints are more complete and API clients are easier to manage.

Can the integration create new patients?

Yes, if you grant the Patient.write scope. Many practices prefer provisional records flagged for front-desk review during the first month, then switch to automatic creation.

Does writing appointments by API bypass OpenEMR permissions?

No. The API client acts as the OpenEMR user you assign to it, with that user's ACL. Give it the narrowest role that can book appointments and write notes.