EHR integration is one of those phrases that sounds cleaner in a pitch deck than it feels in the product. A founder says "we integrate with Epic and athenahealth" and the room relaxes. Then engineering opens the actual workflow and finds patient matching rules, consent edges, custom fields, stale mappings, and a clinic that still wants a fax because one payer made their life weird in 2018.
I am not against integration. In healthcare, the record matters. The question is whether the integration is carrying the product or just decorating it. I have seen teams spend months wiring data into a workflow they had not earned yet. That is a painful way to learn that the customer mostly needed a safer handoff, not a full bidirectional sync on day one.
What job will the integration do?
Start with the actual job. "Pull patient data" is too vague. Does the product need demographics to reduce duplicate entry? Medication history to make a clinical recommendation? Appointment status to trigger outreach? A signed note to close the loop after a visit?
Each job has a different risk profile. Reading a patient name and date of birth is not the same as writing a diagnosis, updating a medication list, or creating an order. If the integration can change the clinical record, the product has crossed into a different level of review, permissioning, audit, and support.
Can the workflow work before the integration exists?
This is the uncomfortable but useful question. Early on, I like proving the workflow with the smallest honest version of data movement. Sometimes that is a CSV import. Sometimes it is a staff member pasting a referral into a structured intake screen. Sometimes it is a one-way read from a narrow source.
Manual steps are annoying, but they expose where the product is actually valuable. If a clinic will not use the workflow with a light manual bridge, the integration may hide the problem for a quarter. It will not fix it. The cleaner signal is when users tolerate the bridge because the product removes enough pain downstream.
When is buying the connector better than building it?
Buy the connector when the integration surface is common, the vendor is stable, and the product's advantage lives somewhere else. There is no prize for hand-rolling every HL7 feed or FHIR mapping if your real product is care coordination, intake routing, revenue workflow, or analytics.
Build closer to the metal when the integration behavior is part of the product's core judgment. If your system needs unusual reconciliation logic, strict latency guarantees, custom writeback rules, or a support model that depends on understanding every failed message, an off-the-shelf connector may become a black box at exactly the wrong moment.
What should be true before you write back to the EHR?
Writeback deserves a higher bar than read access. Before the product writes into the chart, I want clear ownership of the field, a visible review path, retry behavior that will not duplicate records, and logs good enough to explain the change later. Someone on the operations side should know what happens when the write fails halfway through the day.
The boring cases matter. Two patients with the same name. A merged chart. A provider who edited the record between read and write. A downstream system that accepts the message but drops one field. If those cases sound like implementation details, the integration is probably not ready to own writes.
How should a team sequence the work?
Sequence it by risk and proof. Prove the workflow first. Add the narrowest read that removes real duplicate work. Instrument the failures. Let support see the same state engineering sees. Only then expand into broader sync or writeback.
The better move is to time the integration around product proof. Let the product learn what it needs from the record and what it is responsible for putting back. That order saves money, but more importantly, it saves the team from turning a product discovery problem into an integration program.
If your team is working through this, I am always glad to compare notes.