I've seen the same pattern play out at a dozen healthtech companies: the team ships a working product, lands early customers, then hits a wall when it's time to integrate with Epic, Cerner, or another major EHR. What should take 6–8 weeks stretches to 6–8 months. Fundraising timelines slip. Customers churn.
After building Phare Health's data platform from zero to acquisition — processing millions of FHIR/HL7 records daily across Epic, Cerner, and payer systems — I can tell you that 90% of these delays come from the same five mistakes.
1. Treating FHIR as a Simple REST API
This is the most common and most expensive mistake. FHIR is a standard, not a product. The specification defines resource types, search parameters, and interaction patterns — but every EHR vendor implements it differently.
Epic's FHIR API behaves differently from Cerner's. Supported FHIR resources vary. Pagination works differently. Token refresh cycles differ. Search parameter support is inconsistent.
What happens: your team builds against the FHIR R4 spec, ships a clean integration on the sandbox, then discovers in production that the target EHR doesn't support half the search parameters you relied on. You're now rewriting core data access patterns under deadline pressure.
The fix: Before writing a line of code, pull the actual CapabilityStatement from each target EHR's FHIR endpoint. Map exactly which resources, search parameters, and operations they support. Build your data access layer against what's actually available, not what the spec says should be available.
Translation: the FHIR spec is a menu. Each EHR only serves half the dishes. Check the kitchen before you order.
2. Underestimating EHR Vendor Certification Timelines
Epic's App Orchard review process isn't a formality. It involves security assessments, data use agreements, and technical validation that can take 3–6 months. Cerner's (now Oracle Health's) process has its own timeline and requirements. Neither moves on your schedule.
I've watched teams plan their product launch around a date, assuming the EHR certification will be done "in a few weeks." It almost never is.
The fix: Start the vendor relationship and application process at least 6 months before your target go-live. Treat certification as a parallel workstream, not a final step. Assign someone to own the vendor relationship full-time during this period.
Translation: certification is the longest pole in the tent. Start it on day one, not after development is "done."
3. Building a Monolithic Integration Layer
The instinct is to build one service that handles all EHR communication. It pulls data, transforms it, validates it, maps terminologies, and pushes it into your application — all in one pipeline.
This works fine for your first EHR partner. Then you add a second. The second EHR returns patient demographics in a slightly different structure. Lab results use different coding systems. Suddenly you're adding conditional logic everywhere. By the third EHR, the integration layer is a maze of if-else statements that nobody wants to touch.
The fix: Architect for a pluggable adapter pattern from day one. Each EHR gets its own adapter that handles source-specific parsing. A shared normalization layer then maps terminologies, standardizes units, and unifies formats before data reaches your canonical model. Your core application never touches raw EHR data.
The core application never touches raw EHR data. When you add a new EHR partner, you write a new adapter — you don't modify existing code.
This approach scaled cleanly for us at Phare Health across Epic, Cerner, and multiple payer systems. Each adapter was independently testable. Each new EHR integration took weeks instead of months because it didn't require rewriting the core pipeline.
Translation: one adapter per EHR. Adapters handle the "how do I talk to this EHR" problem. Normalization handles the "how do I make all EHR data look the same" problem. Your app talks to a clean internal format. New EHR partner? New adapter, zero changes to existing code.
4. Ignoring Data Quality Until Production
FHIR resources from real clinical systems are messy. Patient records have missing fields, inconsistent date formats, deprecated code systems, and duplicate entries. Sandbox data is clean and well-structured. Production data is not.
The gap between sandbox and production data quality is where most integration timelines blow up. Your pipeline works perfectly in testing, then fails on the first batch of real patient data.
The fix: Implement data quality gates early. Use validation frameworks (we used SODA and Great Expectations at Phare) to define expected schemas, completeness thresholds, and consistency rules. Run these gates on every batch, not just at the end.
When a record fails validation, quarantine it and flag it — don't let it silently corrupt downstream analysis. The goal is to catch broken data before it reaches your application, not to discover it when a customer reports incorrect results.
Translation: sandbox data lies to you. Build validation into the pipeline from day one, or budget 3+ weeks of firefighting when you hit production.
5. Treating Compliance as a Checkbox
HIPAA isn't just about encrypting data at rest and in transit. It's about access controls, audit logging, de-identification for analytics, Business Associate Agreements with every party that touches PHI, and incident response procedures.
I've seen teams get 95% of the way through an integration, only to discover they need to rebuild their data pipeline to support proper audit trails — because the health system's compliance team requires complete traceability of every data access event.
The fix: Design your compliance posture before your architecture. Map exactly where PHI flows in your system. Implement audit logging from the start. Have your BAA templates ready before you begin vendor conversations.
If you're processing data for analytics or AI, build de-identification into the pipeline — not as an afterthought. Retrofitting PHI controls onto a running system is one of the most expensive engineering tasks in healthtech, both in time and in risk.
Translation: compliance isn't a final review. It's a design constraint that shapes your architecture from the first commit.
The Common Thread
Every one of these mistakes shares a root cause: assuming EHR integration is primarily a coding problem. It's not. It's an architecture, compliance, and vendor relationship problem that happens to require code.
The teams that ship integrations on time invest in upfront architecture decisions, start vendor relationships early, and build for the messiness of real clinical data from the beginning. The teams that don't end up 6 months behind, wondering where the time went.