[ FHIR R4 · HL7 V2 · VENDOR APIS ]
We connect your product or practice to Epic, athenahealth, eClinicalWorks, ModMed, Healthie and other EHRs, and move data between them when you switch. Every integration fails closed, never writes the same record twice, logs every read and write, and keeps PHI inside your BAA.
Scope my integration30 minutes with a co-founder. Name the EHR and the data; we'll tell you what access it takes.
FHIR R4 · HL7 v2 · vendor REST and GraphQL
3
HIPAA audits passed on platforms we shipped
Once
every write lands once, checked by a receipt number
FHIR + HL7
modern APIs and the lab interfaces still on v2
100%
code and IP owned by you
[ EHR BY EHR ]
The standard is FHIR, but how you get access, what you can write and who approves it differ by vendor. This is what each one publishes, checked on 2 October 2026.
We also scope AdvancedMD, Nextech, TherapyNotes and DrChrono. For those we confirm API access on your account during scoping instead of promising it here. Healthie details: Healthie integration.
[ WHAT WE BUILD ]
PATIENTS AND SCHEDULING
Patients, appointments, providers and locations kept in step between your product and the EHR, with one side clearly in charge of each field.
CLINICAL DATA
Read through FHIR R4 resources, mapped to your data model, refreshed on a schedule or by event, with only the scopes the feature needs.
LABS AND ORDERS
Orders out and results back for labs and imaging that still speak HL7 v2, with acknowledgements checked and failed messages kept for replay.
DOCUMENTS AND REFERRALS
Referral packets, consent forms and outside records filed to the right patient and category, with a person confirming anything the system isn't sure about.
APPS INSIDE THE EHR
Your app opens inside the clinician's EHR with the current patient already in context, no second login.
MIGRATION
Patient records, notes, documents and history moved to a new system or a custom EHR, reconciled patient by patient before switch-over.
[ HOW WE BUILD THEM ]
An integration that works on the demo and duplicates a medication list in production is worse than no integration. These rules go into every build, and we test each one before go-live.
If the EHR is down, a field doesn't map or a token expires, nothing half-written reaches the chart. The message waits in a queue, and someone gets an alert.
Every write carries a receipt number. If a retry sends the same appointment again, the EHR side sees the receipt and ignores the copy.
Who, what record, when, which system, what changed. Kept where application users can't edit it, ready for a HIPAA audit.
The integration asks for the FHIR scopes and fields the feature needs, and nothing else. PHI stays inside systems covered by your BAAs.
Failed messages are kept and replayed after a fix. Nobody retypes data from a screenshot.
[ LEAVING AN EHR ]
eClinicalWorks offers an Electronic Health Information export that lets authorized users at a practice export the health information stored in the system. That's the starting point. The work is everything after it.
STEP 1
Full export while the old contract is live, plus documents and attachments.
STEP 2
Old fields to the new model, agreed with your clinical lead, including the custom templates.
STEP 3
Both systems live, counts reconciled patient by patient: visits, problems, medications, documents.
STEP 4
Cut-over on a date your clinic picks, old system read-only for look-ups.
Moving to something built for you instead of another vendor? That's custom EHR development.
[ WHAT WE'VE SHIPPED ]
8 weeks
Two connected applications, clinical workflow and family portal, on Azure, with PHI audit trails on every AI interaction.
Open source
Clients, appointments, forms and notes read through the vendor API, with every PHI access logged locally. Read the code.
Append-only
Enforced status machine, a touchpoint log that can't be edited, and an audit event on every change.
Want Claude or ChatGPT reading from the EHR once the integration is in place? That's healthcare AI integration, and this is which Claude plans a BAA covers.
[ FAQ ]
Getting data in and out of an EHR reliably: reading patients, appointments, problems, medications and results; writing back the records your product creates; exchanging orders and results with labs over HL7; and moving data from one EHR to another. It also covers the parts nobody demos: registering with the EHR vendor, getting each practice to approve access, retries, monitoring and an audit trail of every read and write.
Yes. Epic publishes its FHIR APIs and developer resources on open.epic. Reading data through the standard APIs is the common starting point; production access to a given hospital's Epic runs through that organization, so we plan the approval steps with you from the first week.
Both, where the EHR allows it. Certified FHIR APIs are often read-only: ModMed's certified FHIR API, for example, supports read, search and bulk export, while writing into its EMA system goes through a proprietary API after a partner evaluation. We tell you on the scoping call which writes are possible on your target EHRs and what approval each needs.
The code is rarely the slow part. Vendor registration, sandbox access and each practice's approval set the pace. ModMed, for example, says its sandboxes can take up to two weeks to provision. We give you a timeline in weeks after scoping, with the vendor steps on it.
Yes. eClinicalWorks offers an Electronic Health Information export that lets authorized users at a practice export the health information stored in the system. We map that export to the new system, run both in parallel, reconcile counts patient by patient, and switch over only when your clinical lead signs off.
This page is plain integration and migration: moving data between systems correctly. Healthcare AI integration is for connecting Claude or ChatGPT to your EHR under a BAA. Many projects need both, and the integration layer comes first.
Yes, before we touch PHI. Integrations run in your cloud account or your product's infrastructure under your BAAs, and our developers work against sandboxes and synthetic data until production access is approved.
You do. The code lives in your repository, runs in your accounts, the IP is assigned to you, and it's documented so your own team or another developer can maintain it.
[ GET STARTED ]
30 minutes with a co-founder. You leave with the vendor steps, the approvals and a timeline in weeks, whether or not we build it.
Scope my integration