Connections / Webhooks
Bookings, cancellations, referrals, completed forms and payments are posted to your URL, signed and retried. Payloads carry identifiers and states, never patient details, so an integration is never an export nobody reviewed.
What it does
New patients and patient replies, appointments booked or cancelled, referrals received or moved on, intake forms completed, payments recorded, orders placed, care enrolments and out-of-range readings, and a patient waiting for a video visit.
A webhook goes to a server we do not control, so payloads carry identifiers and states only. A subscriber who needs more asks for it, having proved who they are.
Each request is signed — an HMAC of the timestamp and body — and carries an event id, because delivery is at-least-once and the receiver should recognise a repeat.
Failures retry with doubling back-off up to an hour, eight attempts in all; a subscription that fails fifteen times in a row switches itself off.
Addresses on localhost or private networks are refused, a test event shows a signed delivery before going live, and payloads are deleted after thirty days.
How it works
An HTTPS address and the events it wants.
Check the signature with the secret, shown once.
Events as they happen, retried until your end says yes.
What it needs
Every module switches on and off by itself, per clinic, with its own screens, permissions and audit trail.
Worth knowing
Payloads deliberately contain no patient details; anything more is a separate, authenticated request.
The demo runs every module against an unmodified OpenEMR, with invented patients. Nothing to install and no sales call.
