Beside ONEemr
ONEemr writes the OpenEMR database, so modules reach the same patients through the Bridge, whichever screen your staff use.
Essentials
25 modules for the work around the record.
Booking, reminders, notes, orders, claims, denials, integration engines. Each is a module that switches on by itself, with its own screens and permissions — and each works alongside ONEemr, beside unmodified OpenEMR, or in front of another EMR through the Bridge.
6 modules
Front desk
Booking, reminders, messages, forms and video — the work that ties up the phone.
Online bookingPatients book themselves into the EMR diary.How it works 
RemindersSMS, WhatsApp and email — and they stop when the visit does.How it works 
Two-way messagesPatient texts become conversations somebody owns.How it works 
Intake formsFilled in at home, scored before arrival.How it works 
Patient appAppointments, forms, bills and the record, on the patient’s phone.How it works 
Video visitsOne-to-one video that never passes through our servers.How it works 6 modules
Clinical
Notes, orders, documents, referrals and the patients who should be back by now.
Ambient notesRecord the consultation, read a draft, sign it.How it works 
OrdersNothing ordered quietly disappears.How it works 
Document inboxFaxes and scans matched to the right chart — by a person.How it works 
ReferralsIncoming referrals as a workflow, not a pile.How it works 
RecallWho should be back by now, and is not.How it works 
Care programmesChronic care and remote monitoring, billed on the evidence.How it works 6 modules
Billing
Claims, eligibility, payments, authorisations and the denials that come back.
Claim scrubbingProblems caught before the payer catches them.How it works 
EligibilityIs the patient covered? Asked before they are seen.How it works 
PaymentsPayment links and statements, with no card data held.How it works 
Prior authorisationChased, tracked, and caught before they expire.How it works 
DenialsRemittances read for you: what was refused and what to do.How it works 
Denial patternsWhat this payer keeps refusing, before the next claim.How it works 4 modules
Connections
Your EMR, your interface engines, your own systems, and moving records in or out.
EMR connectionA working copy of patients and appointments from any EMR.How it works 
Integration enginesHL7 engines watched — including the silence.How it works 
WebhooksSigned events to your own systems — never patient details.How it works 
Moving in and outBring records in. Take everything with you when you leave.How it works 3 modules
Practice
The clinician’s phone app, shared phrases and the reports a manager asks for.
Four ways to run it
The module does not know what is behind it
No module contains an EMR vendor’s name. What sits behind it is the Bridge’s business, which is why the same module works in all four places.
Beside OpenEMR
Your certified install stays exactly as shipped. Modules reach it over its own API, which is what keeps it certified.
Against another EMR
One adaptor per system behind the Bridge, one model in front of it. The differences between EMRs stop there.
On its own
Referrals, denials, webhooks and reports need no EMR at all; reminders can run from a spreadsheet, an SFTP drop or an HL7 feed.
Honesty about limits
We ask the EMR what it can do, and then say so
Every EMR’s API can do less than its brochure. OpenEMR, for instance, can create and cancel an appointment but not change one, accepts prescriptions but not laboratory orders, and has no billing API at all.
The Bridge declares what works, per resource and per operation, and a module asks before it offers a feature. Something the EMR cannot take is answered in plain words and queued for a person — never reported as done.
Why this matters more than it sounds
A product that pretends a write succeeded is worse than one that refuses. The refusal is annoying for a minute; the pretence is discovered weeks later, by a patient.
And each gap closes by itself. When the EMR gains a capability, a flag flips in its adaptor and the feature appears, with no module changing.
Running it
The same guarantees under every module
One database per clinic
Not a tenant column: a separate database and a separate encryption key, so a query with a missing filter cannot cross a boundary.
An audit log that refuses edits
Hash-chained and enforced by database triggers, and searchable by patient: who opened whose record, and when.
Everything has an endpoint
Signed webhooks out, signed machine endpoints in, and a module contract you can write against.
Start with one module.
Most clinics start with reminders, because it is the one with a number attached. Nothing about the EMR you run has to change.