“FHIR-enabled” on a brochure tells you almost nothing about how hard your integration will be. Two practices on the same EHR can have completely different experiences depending on their edition, their contract, and which data they actually need to move.
Here is what usually determines whether an integration project is a few weeks or a few quarters.
What you actually have access to
Between a marketing claim and a working interface there are several gates:
- Your EHR vendor and edition. API surface varies by product tier. The version sold to a hospital system is not always the version a ten-provider clinic is on.
- Whether API access costs extra. Some vendors meter it, gate it behind a partner program, or charge per interface.
- Whether your specific data is exposed. A partial FHIR API might cover demographics and problems but not the custom fields your workflow depends on. In practice you often end up with HL7 v2 feeds, a subset of FHIR resources, or a scheduled flat-file export — sometimes all three for different data.
Reading is easier than writing
Pulling data out is usually feasible. Writing back into the chart — creating an order, filing a note, updating a problem — is gated more tightly, is slower to approve, and in some configurations is not available without direct vendor involvement.
If a project depends on write-back, confirm it is possible on your specific setup before committing to a timeline. It is the single assumption most likely to be wrong.
The vendor is in the loop, and their queue is not yours
Sandbox provisioning, production credentials, interface configuration, security review — several of these steps run on the EHR vendor's schedule. A realistic plan budgets weeks of calendar time for things that are not your team's work to do, and starts them early.
Questions to ask before you commit
- Which interfaces are available on our edition — FHIR, HL7 v2, bulk export, vendor API?
- Which of the specific resources and fields we need are actually exposed?
- Is there a sandbox we can get today, and what does production access require?
- Is there a cost for API access, per interface or per call?
- Is write-back supported for our use case, or is it read-only in practice?
- Who owns the vendor relationship, and what is their current turnaround?
Scope it as procurement, not just engineering
The engineering for a well-defined interface is rarely the hard part. The hard part is discovering, mid-project, that the data you assumed was available isn't, or that access takes a contract amendment. Answer those questions during evaluation and the build becomes predictable.