EHR and PMS integration requirements for partners

This page is for electronic health record (EHR) and practice management system (PMS) vendors who want to integrate with Peerlogic. It describes the data Peerlogic needs, the operations it performs, the sync strategies it supports, and the security and reliability expectations for a production integration. A Peerlogic integration lets your platform and Peerlogic exchange practice data securely, reliably, and on time. That data powers patient engagement, caller identification, analytics, and Aimee, Peerlogic’s AI assistant that schedules and manages appointments on a practice’s behalf. Use this page to scope an integration with Peerlogic; we’ll work with your team on the details.

How it works

What an integration includes

Secure connectivity. Authenticated APIs between Peerlogic and your system, using OAuth 2.0 or a comparable scheme, under a HIPAA business associate agreement (BAA).
Practice data. Structured data for patients, providers, locations, insurance, appointments and availability, communications, and tasks.
Data delivery. A hybrid model that combines:
- Real-time notifications (events or webhooks) so Peerlogic learns about changes right away.
- Bulk REST APIs (pageable, filterable endpoints with updated_after and cursors) for historical loads and ongoing reconciliation.
- On-demand access, where Peerlogic reads and writes directly, for example when Aimee books an appointment.
Reliable operations. Retries, idempotency, and replay; monitoring and metrics; and schema versioning with additive, backward-compatible changes.

Why Peerlogic syncs full datasets

Peerlogic needs to react in real time and to work from complete, accurate data. Events alone aren’t enough. For example, a patient.updated webhook doesn’t support patient search, safe scheduling, or analytics, which all need the full set of patient records. Syncing full datasets provides:

Historical coverage. Existing patients, providers, and appointments are available from the first day a practice is connected.
Accurate updates. Incremental syncs reconcile any changes missed during an outage or a failed delivery.
Safe scheduling. Booking an appointment needs a full view of availability and conflicts, not only recent changes.
Analytics and auditability. Trend analysis and audit trails depend on complete data.

Events tell Peerlogic that something changed. Syncing makes sure Peerlogic always knows the full current state.

Sync strategies

Peerlogic supports two strategies. We’ll agree on one with you, based on what your platform supports. Strategy A: Peerlogic-driven sync

Historical backfill. Peerlogic pages through GET /{resource}?updated_after=...&cursor=... for each resource (patients, providers, appointments, availability, insurance, locations, communications). If your platform offers a replayable event history, Peerlogic can use it to speed up the backfill.
Ongoing changes. Incremental polling every 5 to 15 minutes, with tighter windows for high-activity data such as appointments and availability. Webhooks from your platform can add a low-latency signal, with polling as a safety net.
On-demand. Peerlogic calls your API to create or update records, such as appointments, and to read the authoritative record before it acts.
Trade-offs. Peerlogic manages pacing, retries, replay, and monitoring end to end. Freshness depends on the polling interval unless you add events, and your API must return consistent reads.

Strategy B: Partner-driven sync

Historical backfill. Your platform provides an ordered event stream (for example, patient.created or appointment.upserted) with a replay cursor from the beginning or from a snapshot point.
Ongoing changes. Your platform sends webhooks on create, update, and delete, and Peerlogic fetches the full record (“notify, then fetch”). Alternatively, your platform posts small batches to Peerlogic intake endpoints every few minutes.
On-demand. The same as Strategy A: Peerlogic calls your API for authoritative reads and writes.
Trade-offs. The lowest latency without polling. Your platform owns change capture, retries, and ordering, which means running queues, idempotency, dead-letter handling, and replay.

Sync mechanics

Need	Mechanic	Strategy	Notes
Historical	Bulk REST fetch	A	Peerlogic calls pageable endpoints (for example, `GET /patients?updated_after=...&limit=500`) to retrieve many records efficiently.
Historical	Event replay	A or B	A replayable event feed with the same contract as real-time events, plus a starting cursor or `updated_after`.
Changes	Webhooks (notify, then fetch)	A or B	Either full payloads with all relevant data, or small payloads (ID and type) after which Peerlogic fetches the full record. Small payloads suit complex records.
Changes	Incremental REST fetch	A	Periodic polling with `updated_after`, typically every 5 to 15 minutes.
Changes	Event push	B	Your platform sends events to a Peerlogic intake API or webhook URL, one at a time or in small batches.
On-demand	Direct API reads and writes	A and B	Always from Peerlogic to your platform, for authoritative reads and writes during scheduling and tasks.

Key details

Resources and operations

Resource	Operations
Patients	Create, read, update, list
Appointments	Create, read, update, delete, list (update includes confirmation)
Availability slots or a scheduling endpoint	Read, list, or create
Providers	Read, list
Operatories	Read, list
Schedule blocks	Read, list
Appointment types	Read, list
Appointment statuses	Read, list
Billing, invoices, adjustments, and payments	Create, read, update

Requirements by capability

Read-only capabilities, such as analytics and caller identification, need a small set of read operations. Aimee’s scheduling needs write access as well. An operation that isn’t listed isn’t required.

Resource	Operation	Analytics	Caller identification	Aimee scheduling
Patients	Create			Yes
Patients	Read	Yes	Yes	Yes
Patients	Update			Yes
Patients	List	Yes	Yes	Yes
Appointments	Create			Yes
Appointments	Read	Yes	Yes	Yes
Appointments	Update			Yes
Appointments	Delete			Handled through update
Appointments	List	Yes	Yes	Yes
Availability slots or scheduling endpoint	Create, read, list			Yes
Providers	Read, list			Yes
Operatories	Read, list			Yes
Schedule blocks	Read, list			Yes
Appointment types	Read, list			Yes
Appointment statuses	Read, list			Yes

Veterinary platforms

For veterinary platforms, Peerlogic maps animals and their owners to Peerlogic patients. Availability, appointment types, and operatories are optional because Peerlogic can manage them itself, but we prefer to receive them from your platform when possible.

Peerlogic object	Your resource	Operations	Minimum fields	Filters
Patient	Animals (pets)	List, get by ID, create	Name, date of birth	Name, date of birth, `update_time`
Patient	Contacts (owners)	List, get by ID, create	Name, date of birth, phone number	Name, date of birth, phone number, `update_time`
Appointment	Appointments	List, get by ID, create, update	Start and end time, operatory, provider, animal, contact (optional), appointment type, status	Start time, end time, animal, contact, status, `update_time`
Provider	Resources or providers	List	Name	`update_time`
Availability (optional)	Provider availability	List, create, update, delete	Start and end time, days, appointment types, operatory	`update_time` (optional)
Appointment type (optional)	Appointment types	List, create, update, delete	Name, duration	`update_time` (optional)
Operatory (optional)	Operatories	List	Name	`update_time` (optional)

Appointment updates need at least the status, so Peerlogic can cancel an appointment and create a new one when it’s rescheduled.
The contact on an appointment is optional; Peerlogic links the appointment through the animal.
The update_time filter is optional for availability, appointment types, and operatories, because these lists are small enough to re-sync in full.

Security and compliance

Business associate agreement. Practice data includes protected health information (PHI), so Peerlogic and your organization sign a HIPAA business associate agreement (BAA) before any production data is exchanged.
Authentication. Secure, authenticated APIs using OAuth 2.0 or a comparable scheme.
Encryption in transit. TLS for all API calls and webhook deliveries.
Revocable credentials. Per-practice or per-integration credentials that can be revoked.
Least-privilege scopes. Scopes limited to the resources and operations above, so a practice that uses only read-only capabilities grants only read access.
Verifiable webhooks. Signed webhook payloads, or another way to verify that a delivery came from your platform.

Enable the Peerlogic Customer API key in Open Dental: an example of how a practice authorizes a Peerlogic integration in its own system
Contact Peerlogic Support

​How it works

​What an integration includes

​Why Peerlogic syncs full datasets

​Sync strategies

​Sync mechanics

​Key details

​Resources and operations

​Requirements by capability

​Veterinary platforms

​Security and compliance

​Related