> ## Documentation Index
> Fetch the complete documentation index at: https://docs.peerlogic.com/llms.txt
> Use this file to discover all available pages before exploring further.

# EHR and PMS integration requirements for partners

> What Peerlogic needs from an EHR or practice management system integration: data resources and operations, sync strategies, reliability expectations, and security and BAA requirements.

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.

## Related

* [Enable the Peerlogic Customer API key in Open Dental](/integrations/ehr-practice-management/enable-open-dental-customer-api-key): an example of how a practice authorizes a Peerlogic integration in its own system
* [Contact Peerlogic Support](https://support.peerlogic.com/contact/)


## Related topics

- [NexHealth Synchronizer network requirements](/integrations/ehr-practice-management/nexhealth-synchronizer-network-requirements.md)
- [Enable the Peerlogic Customer API key in Open Dental](/integrations/ehr-practice-management/enable-open-dental-customer-api-key.md)
- [VoIP webhooks](/voip-platform/webhooks.md)
- [Peerlogic Voice network requirements](/peerlogic-voice/get-started/network-requirements.md)
- [Real-time audio](/voip-platform/real-time-audio.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.