Epic Implementation RFP Guide: Template, Scope & Pricing Tips

Posted in EPIC

A strong Epic RFP should clearly define your organization, project goals, Epic modules, data conversion plan, vendor and internal responsibilities, vendor qualifications, and pricing model. This clarity matters because one study of 1,471 IT projects found that one in six became a major outlier, with average cost overruns of 200% and schedule overruns of nearly 70%. Epic projects rarely fail because the software is weak. They fail because governance is unclear, internal capacity is missing, timelines are unrealistic, or legacy data migration is not scoped properly. A good RFP addresses these risks before the project starts. This guide covers two areas: what to include in the RFP, and what implementation partners look for when deciding whether to bid and how to price the work.

Part 1: What to Include in the EPIC Implementation RFP

Your RFP needs to give vendors three clear pictures: 

1. Your current state
2. Your desired future state
3. The specific gaps you need them to fill

Stay vague on any of the three, and you get vague proposals back, padded with contingency pricing to cover everything you left unspecified.

Organizational Profile and Project Vision

Open with an organizational profile built on real numbers. State your number of hospitals, staffed bed count, ambulatory clinics, specialty facilities, and geographic footprint.

A single academic medical center and a five-hospital health system spread across two states are completely different projects. The staffing model a vendor proposes depends on knowing which one you are.

State your project vision plainly, because the reason you are implementing Epic changes the entire risk profile. The common drivers each carry distinct risks:

• Standardizing care across facilities that currently run different systems
• Replacing a legacy EHR such as Cerner, Meditech, or Allscripts
• M&A integration of hospitals acquired through a merger or acquisition
• Community Connect rollout to affiliated or newly acquired practices

A vendor who knows you are doing an M&A integration thinks about data reconciliation and organizational change management very differently than one preparing for a straightforward legacy replacement.

Give vendors your scale. Provide estimated end users broken down by type, physicians, nurses, and revenue cycle staff, plus your annual patient volumes.

Vendors use these figures to size the build, training, and go-live support. Leave them out and firms either guess high to protect themselves or burn time asking in the Q&A round.

Epic Modules and Scope

List the Epic modules in scope by name. Caboodle, Cadence, Resolute, Willow, Beaker, Radiant, and Cupid each carry their own certification and staffing implications, so naming them strengthens trust.

The module list drives certification requirements, team composition, and timeline. Ambiguity here ripples through the entire proposal. Every non-Epic system that needs an interface belongs on the list: PACS, your lab information system (LIS), and ERP platforms such as Workday or Oracle.

Interfaces hide a lot of effort, and vendors price for the ones they can see. The ones they cannot see become change orders later.

Data Conversion Strategy

Define your data conversion strategy, or at least your starting assumptions. Legacy data migration is the single most underscoped part of most Epic RFPs, and the gaps get expensive.

Specify how much historical data you are moving and from which legacy EHRs. There is a real difference between converting two years of discrete data and converting ten, and a difference again between bringing across structured results and migrating free-text clinical notes.

Name the source systems, give a rough sense of volume, and if you already know which data domains you care about, say so. At a minimum, the RFP should name the source systems and the approximate volume so vendors can size the effort instead of guessing.

Scope of Epic Vendor Services: Drawing the Line Between Their Work and Yours

Define exactly where the vendor leads and where your internal staff owns the work. This is the section organizations get wrong most often, and the one vendors scrutinize hardest. The common service areas you need to assign ownership for are:

• Project Management Office (PMO) leadership
• Application build, configuration, and testing
• Data conversion and interface mapping
• Organizational change management (OCM)
• Training, covering both instructional design and the credentialed trainers who teach end users
• Go-live support (at-the-elbow support) and post-live optimization

For each area, the vendor needs to know whether they are driving or supporting. “Supporting” and “leading” are wildly different cost structures. A vendor who thinks they are advising your team on the build will quote very differently than one who understands they are doing the build while your team learns alongside them.

Treat ownership as a spectrum rather than a binary. On some workstreams you may want the vendor fully in charge with your staff shadowing to build internal knowledge for the post-live world.

On others, your team leads, and the vendor supplies a certified expert to unblock them on hard problems. Spelling out that intent for each workstream removes the single biggest source of mismatched expectations between you and the firm you hire.

Vendor Qualifications and Proposed Team

Request corporate experience that matches your situation. Ask for case studies from organizations with similar bed counts running similar legacy replacements, not just a general claim of Epic experience.

A firm that has done twenty academic medical centers may have never run a multi-site community hospital rollout, and those are different muscles.

Mandate current Epic certifications for the modules each consultant will work on. This requirement sounds obvious and gets fudged constantly, with firms proposing strong resumes and then staffing the actual work with whoever is available. Make the certification requirement explicit and tie it to assigned modules.

Ask for resumes of the key personnel, specifically the Project Director and lead architects. These people determine whether your project runs well.

You want to know who they are before you sign, not discover after kickoff that the impressive team from the sales pitch has been swapped for B-team consultants.

Methodology, Timeline, and Pricing Model

Ask how the vendor will approach the rollout and why. A phased rollout and a big bang implementation carry different risks, and the vendor should defend their recommendation.

Give them your target kickoff and go-live dates, and ask how their methodology aligns with Epic’s own install processes, the structured “Good Install” approach Epic expects partners to follow.

Request a real pricing breakdown rather than a single number. The structure shapes the incentives:

• Fixed price pushes risk onto the vendor and tends to bring tighter scope control and more change orders.
• Time and materials (T&M) gives you flexibility but requires you to manage burn closely.
• Hybrid often lands sensibly, with fixed pricing on well-defined workstreams and T&M on the parts nobody can scope cleanly yet.

Ask for a tiered rate card so you can see what a project executive costs versus a senior analyst versus a trainer. Settle travel and expenses up front, including remote versus on-site expectations and any reimbursement caps, because T&E can quietly become a large line item if nobody defined it.

Part 2: What Vendors Actually Watch For

When a good implementation partner receives your RFP, they are not primarily calculating how much money they can make. They are assessing how likely your project is to go sideways.

Top firms have more demand than they can serve, so they triage. An RFP that signals a chaotic or unprepared organization gets one of two responses: a heavily padded bid to absorb the risk, or a polite no. Here is what they evaluate that the instructions never mention.

1. Leadership and Governance Alignment

• Vendors read your RFP for evidence that your executive team is aligned. If the whole thing reads as IT wrote it alone, with no fingerprints from clinical or operational leadership, that is a major red flag.
• Experienced firms know an Epic build is mostly a long series of design decisions, and design decisions require clinical champions and a steering committee willing to make calls and stick to them. Without that, the project stalls.
• Every workflow question becomes a committee debate, every debate becomes a delay, and the vendor watches the timeline and their margin evaporate.
• So they look for clinical input in the document itself, a named governance structure, and signs that someone with authority can say “this is how we will do it” and make it stick.

2. Whether Your Internal Resources Are Real

• The internal-resource claim is the assumption vendors scrutinize most. Plenty of organizations write something like “our internal IT staff will handle 50% of the build.”
• Vendors do not take that at face value, because they have seen it fail too many times. They start asking quiet questions: Do these people actually hold the certifications? Do they have the hours, or are they already committed to keeping current systems running? Will they get pulled back into legacy maintenance the moment something breaks?
• If a vendor doubts your internal capacity, they do not argue in the proposal. They build extra consulting hours into the bid so they can rescue the project when your team turns out to be overcommitted, and you pay for that doubt whether or not it was warranted.
• The fix is to be honest in the RFP about what your team can really take on and back it up with specifics on certifications and availability.
• Here is how the failure plays out. You commit your three best analysts to the Resolute build at 50% time. Two months in, a billing problem in the legacy system threatens cash flow, and those same three analysts are the only people who understand it. Guess where they go.
• Now your Epic build is short-staffed, the vendor’s consultants are waiting on decisions and dependencies that are not getting resolved, and the rescue hours the vendor quietly priced in start getting used.
• None of this is the vendor being predatory. They have watched this exact sequence unfold a dozen times and priced accordingly. Show in the RFP that you have backfilled legacy support so your build team is genuinely protected, and you take that risk premium off the table.

3. Whether Your Timeline Is Realistic

• Your target dates tell a vendor more than almost anything else. A five-hospital health system asking for a nine-month big bang that includes Beaker and Willow signals immediately that the timeline and the scope do not fit in the same box.
• Lab and pharmacy are complex builds. Testing cycles take what they take. Training a workforce takes weeks you cannot compress past a point.
• Vendors want evidence that you understand this: realistic windows for testing, realistic windows for training, and a go-live date driven by the actual work rather than working backward from a board meeting where someone promised a number.
• An unrealistic timeline does not make a vendor work faster. It makes them assume you will blame them when the date slips, and they price that risk in.

4. Data Conversion Ambiguity

• Legacy data migration is where projects go to die, and vendors know it. An RFP that waves at “migrating historical data from three legacy EHRs” without naming the data domains, the volumes, or the archiving strategy reads to a vendor as a bottomless pit of scope creep.
• How many years of data? Which clinical domains, labs, medications, problems, notes, imaging? What gets converted versus archived versus left behind? Each unanswered question is scope you will discover later, and discovery later is always more expensive.
• Serious bidders want to know you have thought about what data actually needs to come across and what can be retired. You do not need every answer in the RFP. But the more domain-level specificity you provide, the more the bid reflects real work instead of padded contingency.

5. Remote Versus On-Site Expectations

• Since COVID, the strongest Epic consultants prefer hybrid or remote arrangements, and they have the leverage to insist. An RFP that demands 100% on-site presence Monday through Thursday for the entire build phase tells vendors two things at once: they will struggle to put their A-team on your project, and your travel costs will climb.
• The best people pass on a fully on-site engagement when remote options exist, so you end up with whoever is willing to travel rather than whoever is best.
• There are real reasons to want people on-site, especially during go-live, when at-the-elbow support and in-person presence genuinely matter. But blanket on-site mandates for the whole project signal inflexibility, and they cost you both talent and money.
• Vendors read your stance on remote work as a proxy for how the engagement will feel to work on.

Partnering with Folio3 Digital Health for Epic Integration Success 

Folio3 Digital Health helps healthcare organizations plan and execute complex Epic-related projects with a practical mix of technical depth, healthcare domain knowledge, and delivery discipline. Epic integrations, interoperability, workflow optimization, and compliance-focused development, our team supports more than generic IT staffing. For hospitals, health systems, and digital health companies preparing an Epic RFP, we can help define scope clearly, reduce implementation risk, and build solutions that align with clinical, operational, and regulatory needs. 

Conclusion

A good Epic implementation RFP proves you have already done the hard thinking. It shows aligned leadership, an honest account of what your internal team can handle, a timeline that respects the real work, and a clear view of your data conversion. Vendors read those signals and respond with sharper pricing and their better people, because you have lowered the risk they are being asked to carry. A vague RFP defers the hard questions to the build phase, where they cost far more to answer. So before you send anything, get clear on where you actually are in your Epic journey. Are you replacing a legacy EHR, integrating facilities from a merger, or extending Epic through Community Connect to new practices? That answer shapes every section here, and settling it for yourself is the first real step toward an implementation that works.

Frequently Asked Questions

How long should an Epic implementation RFP be?

For most health systems, that runs 15 to 30 pages. Page count matters less than specificity. A tight 15-page RFP with real bed counts, named modules, and a defined data conversion scope beats a 40-page document full of generic language. Cut anything a vendor cannot price against.

What is the difference between a phased rollout and a big bang Epic implementation?

A big bang go-live activates all Epic modules across all facilities on a single date. A phased rollout brings them live in stages, by module, by facility, or both. Big bang avoids the cost of running Epic and a legacy system in parallel, but it concentrates all the risk on one day. Phased rollouts lower that risk and stretch the timeline and budget. Your size, internal capacity, and appetite for risk decide which fits.

About the Author