# 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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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}.
6. 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}.
7. 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.
8. When sending a patient-facing message, use only an org-approved template; never compose free-text clinical or personal content.
9. 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.
10. 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.