PMS/EHR Sync

Read and write schedules, patients, and claims in the practice's PMS/EHR (Practice Management System / Electronic Health Record) via FHIR (Fast Healthcare Interoperability Resources — the standard API format for health data) or PMS REST endpoints, using an Integration row for auth.

When to use

A human needs the current status of an appointment, patient record field, or claim, and the source of truth is the PMS/EHR, not this board.
An org-approved template needs to go out to confirm or remind about an appointment.
A claim needs to be submitted or checked for status, or a schedule slot needs to be read or booked.
Any request that touches diagnosis, treatment, symptoms, or medication must be refused here and handed to a human.

Tools

http-get
http-post
http-request

Playbook

Confirm the request is purely administrative (scheduling, minimum-necessary patient lookup, or claims) before doing anything. If it mentions a symptom, a diagnosis, treatment, or medication, stop immediately and escalate to a human via send-message — do not reply clinically, even briefly.
To read a schedule or appointment slot, call http-get against the PMS/EHR's FHIR endpoint, e.g. GET https://api.pms-vendor.example.com/fhir/Schedule?date=2026-07-20. Auth is injected by the org's Integration row for this host — never ask for, echo, or hardcode credentials.
To look up a patient record, call http-get on the FHIR Patient resource, e.g. GET https://api.pms-vendor.example.com/fhir/Patient/{id}, and fetch only the minimum-necessary fields the task requires (for example, next-appointment status) — do not pull the full chart.
To create an appointment confirmation or a new schedule entry, call http-post, e.g. POST https://api.pms-vendor.example.com/fhir/Appointment with the minimum fields needed.
To update an existing appointment, patch a claim, or delete a stale schedule hold, call http-request with the appropriate method, e.g. PATCH https://api.pms-vendor.example.com/fhir/Appointment/{id}.
To submit or check a claim, call http-post (new claim) or http-get (status check) against the claims endpoint, e.g. GET https://api.pms-vendor.example.com/fhir/Claim/{id}.
Any patient-record write beyond a simple appointment confirmation, and any recall or reminder campaign activation, is human-gated — draft the action and hand it to a human for approval rather than executing it directly.
When sending a patient-facing message, use only an org-approved template; never compose free-text clinical or personal content.
When logging progress on the board, reference the record only by its opaque record ID — never write patient names, dates of birth, or condition details into update-memory or into a task title.
On a 401 or 403 response, or if no Integration row exists for the host, stop and message a human via send-message naming the service and the scopes needed. Do not retry with guessed credentials.

Failure modes

Integration row missing or expired for the PMS/EHR host, causing 401/403 on every call — escalate to a human rather than retrying blindly.
A message mentions a symptom or asks for clinical guidance — this must trigger immediate escalation, not an administrative reply.
PHI (Protected Health Information) leaking into task titles, memory notes, or logs — always substitute the opaque record ID instead of names, DOB, or condition text.
Attempting a record write, recall campaign, or claim submission that requires human sign-off without routing it for approval first.

Done when

The requested schedule, patient, or claim data has been read and reported using only minimum-necessary fields and opaque IDs.
Any write beyond a basic appointment confirmation has been routed to a human for approval, and any clinical content has been escalated instead of answered.
The Integration row's auth handled every call without credentials ever being requested, echoed, or hardcoded.