The EHR integration checklist: 12 questions before you connect anything

Twelve questions, and almost none of them are technical. EHR integrations overrun on access, semantics, ownership and failure handling — which system may send what, what each field means, who notices at 7am when it stops, and who bills you for the privilege. The interface code is usually the cheapest part.

Every EHR integration project I have rescued went wrong before anyone wrote a line of interface code. The damage was done in the kickoff meeting, when twelve questions went unasked. Here they are, in the order they bite, each with why it matters and what a bad answer sounds like. The bad answers are recognizable, because they are almost always confident.

Scope: which messages, which fields, what volume

1. Which message types, which direction? “Integrate with the EHR” is a wish. “ADT A01/A04/A08 inbound, ORU R01 outbound” is a project. A bad answer is “bidirectional, everything” — two directions are two builds, with two sets of failure modes. If those codes are unfamiliar, the plain-English tour of HL7 message types is the prerequisite.

2. Which fields, mapped by whom? Decide who writes and approves the field mapping, and who maintains it afterward. FHIR defines data structures and meanings; profiles and implementation guides narrow them for particular uses. Your systems still need agreement on versions, terminology, supported fields and how local workflow events map to those definitions. Reading a FHIR resource down to the three fields that matter helps make that mapping concrete; validate it with representative exchanges.

3. What volume, at what peak? An interface that handles Tuesday morning’s registration rush is a different build than one that handles the monthly average. A bad answer is a monthly total divided by thirty. Ask for the busiest hour of the busiest day, and for what lands the morning after an outage.

Failure: what happens to the message that never arrives

4. What happens to a message that fails? Queue and replay, dead-letter and alert, or silently vanish — one of these is the default, and you want to choose which. A bad answer is “it retries.” How many times, over what window, and then what? “Then what” is the design.

5. Who finds out, and how fast? If the answer is “the front desk notices missing patients,” the design is not done. A bad answer names an alert with no human behind it and no response time; an alert into a shared inbox is a rumor, not a control. Deciding what people see when it breaks applies to any system — but here a silent failure costs care rather than churn.

6. What is the downtime plan on each side? EHRs go down for maintenance. Interfaces that do not queue during those windows create data-entry weekends. A bad answer covers one side only: both ends go down, on schedules nobody has compared.

Data: who is right, who is who, and how far back

7. Which system wins a conflict? When the EHR and your system disagree about a patient’s phone number, somebody has to be the source of truth, on purpose. A bad answer is “last write wins” — not a decision but the absence of one, in which a correct value is quietly replaced by a stale one.

8. How are patients matched? Name-and-birthdate matching fails at scale in ways that are genuinely dangerous. Know your identifier strategy before go-live, not after the first mismatch. A bad answer says nothing about twins, changed surnames, transposed dates, or the same person registered twice. Then the harder half: what happens to a probable match? A review queue is an answer; merging automatically is a decision somebody senior should sign.

9. What history migrates, and how far back? The go-forward feed is the easy part. The backfill is where budgets go to die. A bad answer is “all of it.” Ask which decisions the history actually supports, and let that set the window.

PHI, ownership, and the invoice nobody budgeted for

10. Where does PHI live in transit and at rest? Encryption, logging, and access control are architecture, not paperwork appended later. A bad answer treats a signed business associate agreement as a technical control. Ask where messages sit while they wait, who can read that queue, and whether the error log carries identifiers — logs are the most reliably overlooked copy of PHI.

11. Who owns the interface after go-live? Interfaces are living things. If nobody in your organization can read the engine’s logs, you are renting your own plumbing forever. A bad answer is a name with no time allocated to it. Ask who does this in the third month, on a Friday, once the builder has gone.

12. What does the vendor charge for their side? EHR vendors bill for interface access, sometimes startlingly. Get that number before you scope anything. A bad answer assumes the fee is one-time, or comes from anyone outside the vendor. Ask about the connection, the test environment, each added message type, and the annual cost.

A worked example: the clinic re-typing referrals from a fax

Referrals arrive by fax and somebody re-types each one into the EHR. The obvious project is “stop the re-typing.” Run the twelve and its shape changes.

Scope collapses into something buildable: inbound only, one message type, a few dozen a day with a Monday spike. Failure becomes the point of the build, because a referral that fails to load is a patient nobody is waiting for. Data is where the project lives: these patients frequently do not exist in the EHR yet, so question eight is the main flow. And question twelve may decide it, because a per-message fee that is trivial at a few dozen a day is not at a few hundred.

Running the list against a real process moves the risk to the first week. Mapping the journey across the systems that each hold part of it gets you honest answers on one through three.

The second-order problem: answers decay

Kickoff answers can change whenever a partner, workflow, message profile or contract changes. Review them on a schedule and at those events; there is no universal three-month shelf life. Record which versions were approved so a new field or message type does not silently change the agreement.

The fix is structural, not a matter of diligence: one document, a named owner, a review date, and changing an answer made a visible act. Same discipline as writing a scope that prevents the argument — the fight is never about the words written down, but the expectation nobody wrote.

“We cannot answer half of these yet”

Good — that is the correct state at the beginning, and worth saying plainly, because a list like this otherwise reads as a test you have already failed.

Some answers can begin as documented assumptions during discovery, but the release gates must be explicit. Scope, mapping, volume and vendor access affect the estimate. Before any live patient-data exchange, resolve failure handling, identity matching, applicable privacy and security controls, authorized data use, operational ownership and recovery; validate any required history migration too. A name and future date are not a substitute for a safe go-live decision. HHS describes the safeguards required of regulated entities; the site’s qualified owners must assess their applicable obligations. For a compact scope worksheet, use the seven-question integration scope.

What people get wrong first

Almost everybody starts by choosing a technology: the integration engine, the FHIR server, the vendor’s API documentation — because that material is concrete and feels like progress.

Use the questions to investigate the workflow before choosing a product, then verify the answers against the actual systems and contracts. Some answers depend on vendor capabilities. FHIR includes data models and exchange patterns, not merely a different transport; it still does not choose your conflict-resolution policy, operating owner or commercial terms. Reading an API like you belong in the room helps you ask the next set of questions.

How you know the checklist worked

Notice that almost none of this is about technology choice. It is about decisions, ownership, and what happens when things fail — which is to say, it is the same work as all good systems thinking, wearing scrubs.

Three signals say it did its job. The estimate stops moving, because what used to move it is written down. Go-live week is boring, because the interesting failures were designed for rather than discovered. And when something breaks in month four, the person who fixes it works for you, reading a log.

I run this exact checklist as the first pass of a healthcare integration assessment. If you are partway into one of these projects and some of these twelve made your stomach drop, bring it to the free half hour — the earlier the cheaper, in this field more than most.

Try this

Ask the EHR vendor to itemize connection, test-environment, message-type and recurring charges in writing. Record the assumptions and lead times alongside the technical, privacy and operating dependencies. Commercial access can change the scope, but it is one of several prerequisites.