Reads by polling
OpenEMR has no webhooks, so changes are found with a watermark, a five-second overlap and duplicate detection on the boundary — the corner cases that otherwise lose a record every few thousand.
Integrations
What your EMR will actually allow
Most integration pages list logos. This one lists limits — because the limits are what decide whether a feature works at your practice, and you will find them eventually anyway.
FHIR R4 / US Core
HL7 v2 SIU
X12 837 / 835 / 270 / 271
Signed webhooks
The mechanism
How the connection works
A separate service — we call it the Bridge — speaks to your EMR through its own published API and translates whatever it finds into one shape. Nothing is written into your EMR's database, no files are modified, and no plugin is installed. Upgrading your EMR does not break us, and removing us does not break your EMR.
Writes through the API
Patients, appointments, prescriptions, medications and problems. Each verified by writing real ones into a real installation, not by reading documentation.
Refuses honestly
Something the EMR cannot do returns a specific "not supported" with the reason, never a silent no-op. The interface then shows a queue for a person instead of pretending.
In the product
The map, where your staff can see it
The EMR connection page shows what is held, when the last change arrived, and every record type as “both ways”, “read only” or “not through the EMR” — straight from what the Bridge declares for the system you connected.
Measured, not estimated
OpenEMR 8.2, counted from its own route tables
Anyone selling you OpenEMR services can confirm every line of this in ten minutes. The API surface is byte-identical in 8.3.0.
71FHIR routes, of which 6 can write
96standard routes
0billing endpoints, in either direction
0files modified in your installation
The capability map
Per resource, per operation
| Capability | Supported | What it means for you |
|---|---|---|
| Patients, appointments, encounters, documents | read | Everything syncs in |
| Documents | add | Filed documents and approved notes go into the patient’s Documents, once the connection is allowed to add them |
| Patient create and update | yes | Self-booking can register a new patient |
| Appointment create | yes | Bookings land in your diary |
| Appointment update | no | A reschedule is cancel-and-rebook; the appointment gets a new reference |
| Appointment cancel | delete only | Cancelling removes it rather than marking it cancelled, so OpenEMR's own cancellation figures will not count it |
| Prescriptions, medications, problems | write | Orders placed here reach the chart |
| Lab and imaging orders | no endpoint | Queued for a person to enter — visible, not lost |
| Vitals | write | Not through FHIR, which has no Observation write — through OpenEMR's other API, under an encounter. Reading only the FHIR surface gets this wrong |
| Lab results and imaging reports | read only | They arrive through OpenEMR's own lab interface; nothing here can write one |
| Immunisations | read only | Record them in the EMR; they appear here within minutes |
| Billing and claims | none at all | Claims are assembled from what we hold, and every claim says so |
| Bulk export | yes | You can leave, with your data |
| A patient's own record (USCDI) | read | All seventeen USCDI data classes, as US Core FHIR. Every class is reported even when it is empty — “no allergies recorded” and “we were not able to read allergies” are different answers and only one is safe to act on |
Each gap above maps to a specific upstream contribution. When one lands, a flag flips and the feature appears — no rewrite, no migration.
Standards
What we speak
FHIR R4 / US Core
The read path. OAuth2 with a signed client assertion that is valid for sixty seconds, and the resources that matter for scheduling and messaging.
HL7 v2
SIU scheduling messages over a signed endpoint, with real acknowledgements. Create, update, cancel and no-show all reach the reminder engine within the minute.
X12 835 remittances
Read properly: delimiters taken from the file's own header, positional elements, and every reason on a segment rather than only the first.
X12 270/271 eligibility
Built with the three hierarchical levels a payer requires and a segment count that matches the file, then read back into copay, deductible and whether cover is actually in force.
Signed webhooks
Outbound events for your own systems, HMAC-signed, at-least-once with an event id so your end can recognise a repeat.
CSV, SFTP and manual
For the clinic whose system has no API at all. A spreadsheet drop still gets working reminders, and a re-export does not create duplicates.
Beyond OpenEMR
A different EMR
The adaptor is the product's shape and OpenEMR is the first one written. A second system is real integration work and we will quote it rather than claim it — a connector nobody has built is the fastest way to lose a reference customer.
What makes the second one cheaper than the first
- The canonical model is already written
- The capability map already exists
- Polling and change detection are already there
- The delivery machinery is already there
What is left is the translation.
Setup
One API credential, and nothing else
No server access, no database login, no change to any installation you maintain — and removable in one action, leaving your EMR exactly as it was.