Integrating with an EMR when the vendor won't help
Practical lessons on EMR integration with FHIR, HL7 v2 and vendor APIs: which door to use, what breaks, and what to test first when the vendor isn't answering.
Most EMR integration projects reach the same moment. The design is agreed, the team is ready, and the question that unblocks everything sits in a vendor's support queue with no reply. You can wait, or you can learn enough about the system to make progress on your own.
This is what I have learned from building on EMRs when help was slow or absent. None of it is specific to one vendor.
Write down exactly what you need
Before choosing a technology, list the data and the direction:
- Which records do you read? Patients, appointments, encounters, results, documents?
- Which do you write, and how often?
- How fresh must the data be: seconds, minutes, overnight?
- Who is the user: a clinician inside the EMR, a patient in an app, or a back-office job?
Reading is usually far easier than writing. Many projects get simpler once the team accepts that the EMR stays the system of record, and their app reads from it and writes back as little as possible.
Know which door you're using
There are usually several ways in, and they behave differently.
- FHIR APIs. The modern, standard route, using resources such as Patient, Appointment and Observation. In the United States, certified EHRs must offer a standardized FHIR API, so read access is widely available. Write support varies a great deal between vendors and versions, so check each resource you need rather than assuming.
- HL7 v2 interfaces. Older but everywhere. Messages such as ADT (admissions and patient updates), SIU (scheduling) and ORU (results) flow through an interface engine. They are well suited to reacting to events, but each hospital configures them a little differently.
- Vendor-specific APIs. Often the only way to reach a workflow the standards don't cover. They are powerful, but they tie you to one vendor and its release cycle.
- Embedded apps. With SMART on FHIR, your app launches inside the EMR with the patient and user context already set. For clinician-facing tools, this often matters more than any back-end integration, because nobody wants another login or another window.
Most real products use two of these: events from HL7 v2 or notifications to know when something changed, and an API to read the details.
Get a sandbox and realistic data early
Ask for a sandbox on day one, then assume the sandbox data is too clean. Build your own synthetic test patients that look like real ones: hyphenated and changed names, several addresses, a merged record, a minor with a guardian, appointments across time zones. If you can, compare your assumptions against de-identified samples of production messages.
Test the unhappy paths first
The happy path works in every demo. These are what fail in production:
- Identity. Two records for the same person, or one record that was merged last week. Decide how you match patients and what happens when you aren't sure.
- Partial data. Missing fields, free text where you expected codes, codes from a local list instead of a standard one.
- Time. Time zones, daylight saving changes and appointments stored in local time without an offset.
- Limits. Rate limits, paging, tokens that expire mid-batch, and scheduled maintenance windows.
- Duplicates and retries. Writes must be idempotent. If your request times out, you need to know whether the appointment was booked before you try again.
Write these as automated tests against the sandbox, and run them on every change.
Expect the ground to move
EMRs are upgraded on their own schedule, and integrations break quietly: a field becomes optional, a code list changes, an interface is reconfigured. Protect yourself with contract tests that check the shapes you depend on, monitoring that alerts on unusual error rates or empty responses, and clear logs that show what the EMR actually sent.
Leave time for the paperwork
The technical work is often not the longest part. Data agreements, security reviews, app marketplace reviews and go-live approvals at each site can take longer than the build. Start them early, keep a list of who signs what, and plan your timeline around the slowest one.
Where the vendor still matters
Working independently doesn't mean working against the vendor. Keep a short, precise list of questions, each with what you tried and what you saw. When the vendor does respond, you'll get answers in one call instead of five, and you'll often find you've already solved most of it.
If you're a non-profit or community health organization trying to connect to an EMR, I'm glad to talk it through. You'll find my email at the bottom of the home page.