The six-month assumption
Ask any patient access director who has integrated a third-party tool with Epic, and you will hear roughly the same timeline: six months from kickoff to go-live. Discovery takes three weeks. Statement of work and legal takes another five. Tech build takes ten. UAT takes three. Training takes two.
That timeline was set when integrations meant building custom HL7 interfaces. That's no longer the only path. A patient access tool integrating with Epic in 2026 can be live in four weeks. It's not a different scope; it's a different architecture. The reason it doesn't happen by default is that most patient access teams don't know to ask for it.
What FHIR changed
FHIR (Fast Healthcare Interoperability Resources) is the standard that Epic, Cerner, athenahealth, and every other major EHR has been required to support since the 21st Century Cures Act final rule went into effect.
For a patient access integration, FHIR replaces the custom interface layer with a set of standardized API endpoints. The endpoints handle scheduling, demographics, appointment status, and most of what a modern queue or check-in tool needs. They're already enabled on every Epic instance running a recent version.
This matters operationally because the longest segments of a traditional Epic integration are the ones FHIR collapses:
- The custom interface build (10 weeks → ~0 weeks)
- The interface specification negotiation (3 weeks → ~0 weeks)
- Most of UAT (3 weeks → ~1 week)
The remaining work — configuration, security review, sandbox testing, training — collapses to four weeks.
The traditional Epic integration timeline isn't a technical fact. It's a procurement habit. The six months are mostly negotiating things that no longer need to be negotiated.
Why patient access teams get the long version anyway
- Vendor incentive. A six-month integration generates more services revenue than a four-week one.
- IT scoping defaults. When a patient access team brings a new tool to IT, the default integration scope assumes custom interfaces. If patient access doesn't ask whether FHIR endpoints are available, IT doesn't volunteer the alternative.
- Comfort with the known path. Six-month integrations are predictable. The four-week version requires explaining a new architecture to people whose risk model was built for the old one.
What to ask for
If your tool is FHIR-capable, the conversation with IT should include four specific questions:
- Are FHIR endpoints enabled on this Epic instance?For any health system on a current Epic version, the answer is yes.
- What's the security review path for an OAuth-based FHIR integration vs. a traditional interface? The security review for a FHIR integration is fundamentally different.
- Can we use Epic's Showroom listing if the vendor has one? This collapses another 2–3 weeks of IT review time.
- What's the actual implementation plan if we use FHIR?This question forces the conversation.
The four-week version
- Week 1 — Kickoff. Confirm endpoint availability, security scopes, sandbox access. Identify go-live cohort and integration owner on each side.
- Weeks 2–3 — Configure. Vendor configures the integration. IT confirms security scopes. Customer confirms scheduling rules and appointment types. Sandbox testing throughout.
- Week 4 — Go-live. Production cutover for the initial cohort. Vendor on-site (or on-call) for the first three days.
It works because every step assumes standardized contracts rather than custom ones. The traditional six-month plan is mostly the cost of not having those standards. They exist now.
When the six-month version is still the right answer
- Older Epic instance. Pre-current FHIR support requires an upgrade first.
- Highly customized workflow. Some specialty workflows still don't have great FHIR coverage.
- Risk tolerance of the security team. Some systems have explicitly higher review thresholds.
The patient access team's leverage
A patient access director who knows to ask "have we considered the FHIR-based path?" routinely saves their organization four to five months of project time on a single deployment. That's not a technical contribution. It's a procurement contribution. The integration timeline doesn't have to be the constraint. It usually is because nobody is asking for the alternative.