Epic EHR — Module & Technical Reference

Reference date: November 2026 · Lifecycle key: “Active” means currently in use as documented in the source reference; it does not imply installation at every customer. Cerner comparisons are functional, not necessarily one-to-one product replacements.

Hospital — Admissions, Registration & Scheduling

Epic Item	Classification	Function	Status	Cerner / Oracle Health Equivalent
Prelude	Module	Patient registration, demographics, coverage	Active	Registration Management
Grand Central	Module	Hospital admission, discharge, transfer, bed management	Active	Registration/ADT, CareAware Patient Flow
Cadence	Module	Hospital appointment and resource scheduling	Active	Enterprise Scheduling
Welcome	Application / module	Check-in / arrival	Active	Patient check-in tools

Hospital — Clinical Workflow

Epic Item	Classification	Function	Status	Cerner / Oracle Health Equivalent
EpicCare Inpatient	Module	Hospital physician orders, treatment, care	Active	PowerChart, PowerOrders
ClinDoc	Module	Inpatient nursing flowsheets, care plans, assessments	Active	iView, PowerChart
ASAP	Module	Emergency department	Active	FirstNet
OpTime	Module	Operating room scheduling and surgery	Active	SurgiNet
Anesthesia	Module	Anesthesia documentation	Active	SurgiNet Anesthesia
Willow	Module	Inpatient medication/pharmacy workflows	Active	PharmNet
Beacon	Module	Oncology treatment plans	Active	PowerChart Oncology
Stork	Module	Inpatient obstetrics and labor & delivery	Active	PowerChart Maternity
Phoenix	Module	Transplant clinical workflows	Active	PowerChart specialty build

Hospital — Radiology, Laboratory & Diagnostics

Epic Item	Classification	Function	Status	Cerner / Oracle Health Equivalent
Radiant	Module	Radiology scheduling, orders, results	Active	RadNet
Beaker CP	Module	Clinical laboratory / pathology	Active	PathNet
Beaker AP	Module	Anatomic pathology	Active	PathNet AP
Beaker Blood Bank	Module / capability	Transfusion / blood-bank management	Active	PathNet Blood Bank
Cupid	Module	Cardiology diagnostics and procedures	Active	CVNet / cardiology tools
Lumens	Module	Endoscopy documentation	Active	SurgiNet / endoscopy tools

Hospital — Notes, Documents & Medical Records

Epic Item	Classification	Function	Status	Cerner / Oracle Health Equivalent
EpicCare Inpatient	Module	Physician progress and discharge notes	Active	PowerNote, Dynamic Documentation
ClinDoc	Module	Nursing notes, assessments and flowsheets	Active	iView
HIM (functional area)	Functional area — not a module	Record completion, deficiencies, release	Active	ProFile / HIM functions
Care Everywhere (capability)	Interoperability capability — not a module	Outside clinical records	Active	CommonWell / Carequality exchange

Ambulatory — Clinics & Outpatient Care

Epic Item	Classification	Function	Status	Cerner / Oracle Health Equivalent
Cadence	Module	Office visits, clinician calendars, referrals	Active	Enterprise Scheduling
Prelude	Module	Clinic registration, demographics, insurance	Active	Registration Management
Welcome	Application / module	Clinic check-in	Active	Patient check-in tools
EpicCare Ambulatory	Module	Outpatient visits, rooming, provider notes, orders	Active	PowerChart Office / Ambulatory
Willow	Module	Pharmacy/prescribing integration	Active	PharmNet / prescribing
Beacon	Module	Ambulatory oncology/infusion care	Active	PowerChart Oncology
Bones	Specialty module	Orthopedics specialty workflow	Active	PowerChart orthopedic specialty build
Kaleidoscope	Specialty module	Ophthalmology specialty workflow	Active	PowerChart ophthalmology specialty build
Wisdom	Specialty module	Dental clinics	Active	Dental system / integration
Healthy Planet	Application / module	Population health, registries, care management	Active	HealtheIntent / Oracle Health Data Intelligence
Dorothy	Module	Home health	Active	No close one-to-one Millennium module
Comfort	Module	Hospice	Active	Hospice workflows / specialist solutions
Radiant	Module	Outpatient imaging	Active	RadNet
Beaker CP / AP	Modules	Outpatient specimen processing and diagnostic results	Active	PathNet
Cupid	Module	Outpatient cardiology	Active	CVNet / cardiology solutions
Lumens	Module	Outpatient endoscopy	Active	SurgiNet / endoscopy solutions

Coding, Billing & Revenue Cycle

Epic Item	Classification	Function	Status	Cerner / Oracle Health Equivalent
HIM Coding (workflow)	Workflow — not standalone module	Diagnosis/procedure coding	Active	Oracle Health HIM / coding workflows
Resolute Hospital Billing (HB)	Module	Facility billing and hospital claims	Active	Cerner/Oracle Health Patient Accounting
Resolute Professional Billing (PB)	Module	Clinician / outpatient professional claims	Active	Oracle Health professional billing
Tapestry	Module	Health plan administration	Active	Oracle Health payer tools; no direct match
Charge Router (component)	Component — not standalone module	Charge validation and routing	Active	Charge Services

Claims, Remittances and Medicare EDI

X12 numbers designate transaction formats, NOT Epic software modules. Resolute HB and PB generate and post claim/payment activity, commonly using interface or clearinghouse workflows.

EDI / form	Type	Function	Direction / comparison
837P	X12 EDI transaction — not module	Professional / physician claim	Provider → payer; CMS-1500 paper counterpart
837I	X12 EDI transaction — not module	Institutional / hospital claim	Provider → payer; CMS-1450 / UB-04 paper counterpart
837D	X12 EDI transaction — not module	Dental claim	Provider → payer
835	X12 EDI transaction — not module	Electronic remittance advice (ERA), adjustments and payment details	Payer → provider
270 / 271	X12 EDI transaction pair — not modules	Insurance eligibility inquiry / response	Provider ↔ payer
276 / 277	X12 EDI transaction pair — not modules	Claims status inquiry / response	Provider ↔ payer
277CA	X12 EDI acknowledgment — not module	Claim-level acceptance / rejection report	Payer / intermediary → provider
999	X12 EDI acknowledgment — not module	Syntax / implementation acknowledgment	EDI receiver → sender
278	X12 EDI transaction — not module	Health care services review / authorization	Provider ↔ payer
CMS-1500	Medicare / industry paper claim form — not module	Professional or supplier claim	Electronic equivalent: 837P
CMS-1450 / UB-04	Medicare / industry paper claim form — not module	Hospital / institutional claim	Electronic equivalent: 837I
Medicare 835 ERA	Medicare electronic remittance — not module	MAC-issued electronic remittance with line-level payments, denials and adjustments	Payer → provider

Patient Portals & Clinician / External Access

Epic Item	Classification	Function	Status	Cerner / Oracle Health Equivalent
MyChart	Application / module	Patient portal, visits, messaging, results	Active	HealtheLife / Oracle Health Patient Portal
MyChart Bedside	MyChart feature / application	Inpatient patient engagement	Active	Bedside engagement tools
MyChart Care Companion	MyChart feature / application	Patient home monitoring and care plans	Active	Patient engagement and remote monitoring
EpicCare Link	Application	Referring / outside clinician access	Active	Provider Portal / PowerChart Outreach
Haiku	Mobile application	Clinician smartphone application	Active	PowerChart Touch / mobile tools
Canto	Mobile application	Clinician tablet application	Active	PowerChart Touch
Rover	Mobile application	Mobile bedside nursing workflow	Active	CareMobile / CareAware

Epic Workspace and Messaging

Epic applications share a common workspace. In Basket and Secure Chat are functions inside Epic, not separate EHR modules.

Epic item	Classification	Function	Cerner / Oracle Health comparison
Hyperdrive	Desktop UI / workspace platform — not clinical module	Main Epic desktop client where users open clinical, operational and financial activities	PowerChart / Millennium user interface (functional analogy)
Hyperspace	Legacy desktop client — not module	Earlier Epic client, replaced or being replaced by Hyperdrive at many sites	Legacy PowerChart desktop client
In Basket	Built-in messaging and task workflow — not standalone module	Patient messages, staff communications, results and routed tasks, often assigned to team pools	Message Center / clinical inbox
Secure Chat	Built-in real-time staff messaging — not standalone module	One-to-one and group clinician communication	CareAware communication tools / secure messaging
MyChart Messages	Patient portal feature — not standalone module	Patient-originated messages appear in configured In Basket queues / team pools	Oracle Health patient portal messaging

Message Routing Examples

Specific routes depend on local In Basket pools, care-team configuration, and security settings.

Scenario	Patient / sender location	Epic destination
Doctor → nurse, immediate message	Secure Chat	Nurse Secure Chat conversation
Doctor → nurse, task or follow-up	In Basket	Individual nurse or shared team In Basket pool
Patient → doctor	MyChart → Messages	Epic In Basket (sometimes triage pool before physician)
Doctor → patient	Epic In Basket / MyChart message composition	Patient MyChart Messages

Reporting, Analytics & Interoperability

Epic Item	Classification	Function	Status	Cerner / Oracle Health Equivalent
Cogito (framework)	Analytics framework — not single module	Enterprise reporting and analytics	Active	PowerInsight / Oracle Health Data Intelligence
Reporting Workbench (tool)	Reporting tool — not standalone module	Operational reporting	Active	Discern Reporting
Radar (tool)	Dashboard tool — not standalone module	Dashboards	Active	PowerInsight dashboards
SlicerDicer (tool)	Analytics tool — not standalone module	Interactive data analysis	Active	Oracle Health analytics
Clarity (database)	Database — not module	Relational reporting store	Active	Millennium reporting repository
Caboodle (warehouse)	Data warehouse — not module	Enterprise analytics warehouse	Active	HealtheEDW / Oracle Health Data Intelligence
Bridges (integration component)	Integration component — not module	HL7/other interfaces	Active	Open Engine / FSI
Interconnect (API component)	API component — not module	REST, FHIR, web services	Active	Millennium / Oracle Health APIs
Care Everywhere (capability)	Interoperability capability — not a module	Cross-organizational records	Active	CommonWell / Carequality connectivity

Technical Architecture & Hosting

Hosting models

Hosting model	Where servers operate	Who operates them
Self-hosted	Hospital's own data center	Hospital IT
Epic Hosting	Epic-managed infrastructure	Epic
Third-party / cloud	Contracted hosting/cloud provider	Organization and provider
Community Connect	Another health system's Epic instance	Sponsoring health system

Epic does not mandate Epic-hosted infrastructure. Epic Hosting is an available managed hosting option.

Core technologies

Technology	Purpose	Cerner / Oracle Health analogy
Chronicles / InterSystems	Operational patient database	Millennium operational database
Hyperdrive	Newer Epic user interface	PowerChart clinician client
Hyperspace	Older Epic desktop client, being replaced by Hyperdrive	Legacy PowerChart client
Bridges	Traditional interface connectivity	Open Engine / FSI
Interconnect	APIs/web services	Oracle Health FHIR / Millennium APIs
Clarity	Relational reporting	Millennium reporting data
Caboodle	Analytics warehouse	HealtheEDW

Interfaces, Integration & Data Exchange

Architecture: Epic Bridges is Epic's core HL7v2 messaging infrastructure. Interconnect exposes web services and APIs. A third-party interface engine may sit between Epic and other systems for transformation, routing, observability, or protocol mediation. Not every connection uses every layer. Epic HL7 interface catalog · Epic FHIR catalog

9.1 Integration building blocks — module or not?

Item	Classification	What it does	Oracle Health / Cerner analogy
Bridges	Integration framework / infrastructure (not clinical module)	Configures and runs many HL7 v2 inbound/outbound interfaces; handles message processing and acknowledgments.	Millennium FSI / Open Engine
Interconnect	API/web-services layer (not clinical module)	Supports Epic web-service integration, including FHIR-based access.	Millennium API / FHIR services
open.epic / App Orchard	Developer ecosystem (not clinical module)	Public interface specifications, app/API registration and technical documentation.	Oracle Health developer ecosystem
Care Everywhere	Interoperability feature / capability	Cross-organization clinical record exchange.	CommonWell/Carequality and Oracle Health information exchange
External integration engine	Third-party middleware (not Epic module)	Optional message mapping, queues, monitoring, and connections to non-Epic systems.	Rhapsody, Mirth/NextGen Connect, Corepoint, Cloverleaf, etc.
Interface workqueues / error-monitoring tools	Operational features (not standalone clinical modules)	Review failed records, message exceptions, and reconciliation.	Millennium interface monitoring / integration engine queues

9.2 How messages actually flow

External source/targetLab · PACS · HIE · Pharmacy · Payer · Device

⇄

Optional enterprise integration engineTransform · route · queue · monitor

⇄

Epic Bridges or InterconnectHL7 v2 / FHIR / services

⇄

Epic workflows and recordsPrelude · EpicCare · Beaker · Radiant · Resolute

Placement: The middleware may run in a hospital data center, cloud environment, Epic-managed hosting arrangement, or external vendor environment. The exact network path, VPN/private links, interfaces, firewall rules, and tenancy are implementation-specific. (assumed) A typical hospital will keep a central interface team responsible for message lifecycle even when infrastructure is hosted elsewhere.

9.3 Interface catalog — clinical and operational

Interface / message	Common standard	Direction relative to Epic	Typical source → destination / use
ADT: A01 / A02 / A03 / A04 / A08 and others	HL7 v2 ADT	In or out	Prelude/Grand Central ↔ outside registration, census, billing, bed, and ancillary systems; admit, transfer, discharge, updates.
Orders	HL7 v2 ORM; OML where applicable	Commonly out	EpicCare/Beaker → external lab, radiology, cardiology, reference laboratory.
Results / observations	HL7 v2 ORU	Commonly in	Lab/RIS/device → Epic results and clinician chart; match to patient and order.
Clinical documents and transcriptions	HL7 v2 MDM; CDA/C-CDA where applicable	In or out	Transcription, documentation repository, referring providers → chart/HIM; or notes pushed out.
Appointments and scheduling	HL7 v2 SIU	In or out	Cadence ↔ scheduling/notification, transport, ancillary systems.
Patient identity matching	HL7 v2 / FHIR / EMPI services	In or out	Cross-system MRN, encounter, demographics, and enterprise identity reconciliation.
Medication information	HL7 v2 RDE/RAS/RXA as applicable	In or out	Epic medication orders/administration ↔ dispensing, automation, external medication systems.
E-prescribing	NCPDP SCRIPT	In or out	Prescriber ↔ pharmacy, network, prescription messages and renewals.
Clinical observation devices	HL7 v2 / vendor device gateways	Commonly in	Bedside monitors, infusion pumps, vitals aggregators → Epic documentation.
Images and imaging metadata	DICOM; HL7 v2; FHIR ImagingStudy metadata	Both	Modality/PACS/VNA ↔ Epic/Radiant; image pixels are commonly retained in PACS/VNA while reports and links surface in Epic.
Care Everywhere / HIE exchange	FHIR, CDA/C-CDA, exchange networks	Both	Other health organizations ↔ Epic clinical records.
External clinical app	FHIR R4 + SMART on FHIR / OAuth 2.0	API read/write as supported	Approved app ↔ Epic clinical and demographic resources; endpoint support varies.

9.4 Revenue-cycle X12 EDI — claims, remittances, Medicare

Transaction	Purpose	Typical direction (provider perspective)	Epic / operational destination
837P	Professional/physician electronic claim; CMS-1500 electronic equivalent	Provider → payer/clearinghouse	Resolute Professional Billing; claims engine/clearinghouse
837I	Institutional/hospital electronic claim; UB-04/CMS-1450 electronic equivalent	Provider → payer/clearinghouse	Resolute Hospital Billing; claims engine/clearinghouse
837D	Dental claim	Provider → payer/clearinghouse	Dental billing workflows, if configured
835	Electronic remittance advice (ERA): paid, denied, adjusted; payment posting data	Payer/clearinghouse → provider	Resolute remit processing and posting
270 / 271	Insurance eligibility inquiry / response	Provider ↔ payer	Registration / coverage verification
276 / 277	Claim status inquiry / response	Provider ↔ payer	Billing follow-up and claim status
277CA	Claim acknowledgment / acceptance or rejection	Payer/clearinghouse → provider	Claims status/error workqueues
999	Implementation-level EDI acknowledgment	Receiver → sender	EDI/interface processing monitoring
278	Prior authorization / utilization review transaction	Both	Authorization workflows
834	Benefit enrollment / maintenance, especially payer operations	Employer/sponsor → payer	Tapestry or health plan systems, when applicable
820	Payment order / remittance for premium payments (payer context)	Depends on payer role	Tapestry premium billing, where used

Medicare: Medicare Fee-for-Service institutional and professional claims ordinarily use 837I and 837P through Medicare Administrative Contractors (MACs), subject to Medicare billing rules, enrollment, edits and companion guides. CMS-1500 (professional) and CMS-1450/UB-04 (institutional) are the corresponding paper claim formats. An 835 is a remittance transaction, not the claim itself. See Epic X12 interface inventory and CMS EDI information.

9.5 Example end-to-end workflows

Scenario	Sequence	Key control point
External lab test	Epic order → outgoing HL7 order → lab LIS → incoming HL7 results → Epic chart/In Basket routing	Patient/order identifiers, ACK, result reconciliation
Hospital registration	Prelude/Grand Central → ADT → downstream department systems → ACKs and census reconciliation	MRN/visit consistency, duplicate and missing messages
Radiology imaging	Epic order → Radiant/RIS ↔ modality/PACS → report/result → Epic	Order/accession matching; DICOM objects and final report may travel separately
Professional claim	EpicCare Ambulatory visit → coding/charge capture → Resolute PB → 837P → clearinghouse/MAC/payer → 999/277CA → 835 → payment/denial posting	Claims acceptance, rejects, remit balancing and denial follow-up
Hospital claim	Inpatient encounter → charges/coding → Resolute HB → 837I → payer/MAC → status and 835 → posting	DRG/coding, charge reconciliation, claim edits
External patient-facing application	App authorization → SMART/OAuth → Epic FHIR endpoints → permitted patient/clinical data	Scopes, consent/authorization, access logging
Patient message	Patient MyChart message → Epic In Basket → physician or staff pool; staff may initiate Secure Chat	Pool rules, assignment, follow-up; Secure Chat ≠ patient MyChart inbox

9.6 Interface deployment and validation checklist

Stage	Activities / deliverables	Accountable team (typical)
Inventory and ownership	Define producer/consumer, system of record, message direction, business owner, SLA	Integration lead + application owner
Specifications	Version, trigger events, segment fields, code sets, mappings, sample payloads	Epic interface analyst + vendor analyst
Connectivity	Endpoint, network routes, TLS, MLLP/SFTP/HTTPS as applicable, credentials, allowlists	Network/security + interface engine team
Message handling	ACK/NACK, retries, de-duplication, ordering, queue limits, dead-letter/error handling	Interface engineers
Testing	Unit, end-to-end, negative/error cases, high volume, downtime/recovery, integrated testing	Hospital QA + Epic + third party
Cutover	Endpoint swap, feed activation, backfill and duplicate controls, command-center support	Cutover lead + interface teams
Production operations	24×7 monitoring where critical, queue thresholds, on-call routing, reconciliation, change control	Hospital integration ops / managed provider

9.7 Who supports an interface?

Layer	Usually responsible	What gets escalated
Epic workflow configuration	Hospital Epic application analysts	Orders, routing, encounter/charge build
Epic Bridges / Interconnect	Hospital Epic interface analysts, supported by Epic TS	Interfaces, build, application-level logs/behavior
Third-party interface engine	Hospital integration team or outsourced vendor	Mappings, transforms, queues, endpoint connections
External application	Lab, PACS, payer, pharmacy or vendor IT	Source payload, target processing, downstream data quality
Network / hosting	Hospital IT, Epic Hosting, or contracted cloud/provider per model	DNS, certificates, firewall, service outages, network paths
Revenue-cycle reconciliation	Billing operations, clearinghouse, EDI team	837 rejections, 835 unposted remits, 277CA status, payment balancing

9.8 Integration references

Epic official HL7 v2 integration catalog · Epic official FHIR integration catalog · Epic official X12 catalog · CMS: electronic billing and EDI. Exact interface support depends on licensed application, version, configuration and the connected endpoint.

Ambulatory workflow

Cadence scheduling → Prelude / Welcome registration → EpicCare Ambulatory visit, notes and orders → diagnostics / pharmacy → Resolute Professional Billing → MyChart

Epic Implementation Methodology, Engagement & Support

Epic follows a Foundation-based implementation approach with standardized content, workflow validation, configuration, testing, readiness and optimization. The exact proprietary internal methodology and templates are not publicly available; this is an evidence-based summary of published Epic implementations.

Big bang is not unique to Epic, and phased implementation is not unique to Cerner. A published Intermountain Cerner Millennium study describes phased regional deployment with big-bang activation inside each region. The defensible conclusion is that Epic leadership publicly promotes simultaneous enterprise activation more strongly—not that either vendor only supports one rollout pattern. Intermountain Cerner implementation study. Epic's own implementation executive said large health systems can launch a first phase within roughly 16–18 months, with later launches about six months apart. April 2024 report.

10.0.3 Important distinction: Epic versus Oracle Health/Cerner

Pressure point	Practical consequence	What the evidence supports
Foundation-first build	Departments are pushed toward common, prebuilt workflows rather than independent, local configuration.	Epic describes its Foundation System as a default design based on customer practices; the degree of local variation is a governance decision.
Shared enterprise activation	Scheduling, medication management, nursing, orders, labs, interfaces, coding and revenue cycle must work across departments at once.	Observed in big-bang implementations; not required for every Epic customer.
Fixed readiness milestones	Late changes can disrupt integrated testing, training materials, conversion rehearsals and cutover planning.	Implementation-management inference; the exact project controls vary by contract and organization.
Centralized change authority	Local department preferences may be rejected to protect a system-wide common build.	Common enterprise-governance effect, not proof that Epic forbids every customization.
Limited staggered learning	A large activation leaves less opportunity to use one department's live experience before another department converts.	Contrast described in staged-implementation case studies.
Go-live issue concentration	Support queues, command center, clinical informatics, and interface analysts all face problems simultaneously.	Explicitly described by Vanderbilt's implementation leadership.

10.0.2 Why the approach can feel draconian

Health system	Activation model	Specific evidence
Intermountain Health	Big bang	33 hospitals across six states transitioned together in September 2025. Source
Vanderbilt University Medical Center	Big bang	More than 18,000 physicians, nurses and staff switched on one day. Its informatics leader said issues from simple to complex occurred simultaneously; initial go-live support lasted about five weeks. Vanderbilt retrospective
Northwell Health	Regional waves	First major go-live November 1, 2025; leadership called a big-bang rollout across 28 hospitals and hundreds of ambulatory sites disruptive. Feb. 2026 report
UPMC	Phased waves	UPMC selected a phased transition to reduce risk to patient care, integration, data conversion, and readiness while consolidating nine EHRs. Source
WMCHealth (planned, March 2026)	Big bang	Public RFP questions and answers specify a single enterprise instance, all facilities in scope, and a big-bang go-live. RFP Q&A

10.0.1 Actual Epic implementation examples

Dimension	Big-bang / enterprise activation	Phased / wave activation
Scope	Multiple sites and tightly coupled clinical, ancillary, and revenue-cycle functions start on the same date.	Sites, regions, service lines, or functions transition on different dates.
Benefit	Unified chart, workflows, registration, orders, and billing from day one; avoids running two operational models for an extended period.	Smaller immediate blast radius; later waves can incorporate lessons learned.
Risk	Simultaneous clinical, operational, integration, training, and revenue-cycle issues; very large command-center demand.	Dual-system reconciliations, cross-system handoffs, temporary interfaces, and prolonged cutover staffing.
Staffing	Intense concurrent build, validation, training, at-the-elbow support and command-center coverage.	Support resources distributed by wave, but teams may support recently activated sites while building the next wave.
Decision pressure	Early, cross-department agreement on standardized workflows and a common cutover date.	Repeated readiness decisions and transitional operating procedures.

Verified finding (November 2026): Epic frequently favors a big-bang activation, with multiple hospitals, ambulatory clinics, and integrated applications switching together on one date. At Epic's 2025 Users Group Meeting, CEO Judy Faulkner explicitly described why she believes big-bang installs are often better: phased activation generates temporary workflows and repeated transitions. This is a preference, not a mandatory rule: large Epic clients also deploy in waves. Becker's, Oct. 2, 2025.

10.0 Enterprise-wide go-live versus phased activation: why Epic feels more rigid

10.6 Sources and evidence strength

10.7 Standard implementation stages and ownership

Criticism	Evidence / context
“Epic dictates the workflow”	A hospital's own published guiding principles prioritize “Foundation, Foundation, Foundation” and adherence to standardized workflows.
“They won't customize before go-live”	A 2013 consultant critique described a model plan that limits extensive customization until after activation. This is a criticism, not a universal Epic policy.
“The hospital needs far more people than expected”	The same critique alleged staffing plans could underestimate needs by 20–30%; this is a historical consultant claim, not a verified current benchmark.
“They are extremely controlled, but it works”	Modern project schedules show tightly coordinated build, testing, readiness and cutover checkpoints; the trade-off is less flexibility during deployment.

10.5 What the criticism actually says

Deployment scale	Published benchmark	Interpretation
Smaller health systems	9–12 months, commonly	Epic implementation executive statement (2024)
Larger health systems	First go-live 16–18 months, subsequent waves ~6 months apart	Epic implementation executive statement (2024)
Community Connect clinics	Can use shorter affiliate rollout schedules	Depends on host standardization, interfaces and conversion

10.4 Timing and model

Checkpoint	Operational meaning	Evidence
Build waves 1–4	Incremental configuration according to a master schedule	UMC / TTUHSC implementation timeline
Readiness waves 1–4	Progressive clinical, operational and system validation	UMC / TTUHSC implementation timeline
Integrated testing	End-to-end workflows across applications and interfaces	UMC / TTUHSC implementation timeline
Parallel revenue-cycle testing	Check charges, claims and financial results before conversion	UMC / TTUHSC implementation timeline
TDR	Test workstations, devices, printing, scanning, access	CTG and published project schedule
GLRA	Escalate unresolved readiness risks at scheduled milestones	CTG and published project schedule

UMC / Texas Tech's published implementation schedule identifies four configuration waves, four readiness waves, three rounds of integrated testing, two rounds of parallel revenue-cycle testing, Technical Dress Rehearsal, and readiness assessments at 120, 90, 60 and 30 days before go-live. These are specific documented project practices; not every Epic contract must use identical counts.

10.3 Actual implementation sequencing: documented example

Workstream	Typical deliverables / activities	Responsible teams
Governance & scope	Executive sponsors; steering committee; issue escalation; scope decisions; master schedule; project controls	Hospital leadership, PMO, Epic implementation team
Foundation & design	Foundation walkthroughs; workflow validation; gap and exception decisions; future-state process maps	Operational workgroups, physician/nursing champions, app analysts, Epic
Build waves	Application configuration; security roles; order sets; documentation templates; charge capture; build trackers	Certified app analysts, operational SMEs, Epic TS
Technical	Hosting/infrastructure; workstation inventory; printers/scanners; interfaces; devices; identity/access; downtime	ECSA, infrastructure, interface, security and vendor teams
Data conversion	Patient matching; appointments; allergies, medications, histories; mapping; mock loads; reconciliation	Conversion and clinical validation teams
Testing	Unit/functional tests; integrated testing; Day-in-the-Life; revenue cycle parallel tests; defect triage	App teams, operational SMEs, billing, QA
Readiness	Technical Dress Rehearsal (TDR); device validation; training records; GLRA checkpoints	Project leadership, IT, training, operations
Activation	Cutover checklist; appointment conversion; command center; at-the-elbow support; issue prioritization	Joint Epic/hospital/contractor go-live organization
Stabilization	Hypercare; support handoff; defect backlog; optimization governance; upgrade planning	Hospital application support, Epic TS, operations

10.2 Epic-specific project workstreams and deliverables

Critical distinction: Foundation is not “zero customization.” Peer-reviewed interviews with EHR implementation leaders describe extensive parameter-level configuration as necessary, while over-customization increases maintenance difficulty. Epic's rigid reputation reflects an implementation operating model, not an absolute ban on customization.

Control	What occurs in practice	Why it feels restrictive	Trade-off / benefit
Foundation System default	Begin with Epic's configured standard workflows rather than blank-sheet design.	Local practices must justify deviations; departments cannot simply recreate their old EHR.	Limits unnecessary build complexity and accelerates deployment.
Workflow standardization	Operational committees select common workflows, often across many hospitals.	Clinicians or sites lose some local autonomy.	Consistent care processes, training and analytics.
Decision deadlines	Workgroups must make and record decisions to keep successive build waves moving.	Late objections and requests can be deferred to optimization.	Protects interdependent testing and go-live schedule.
Cross-functional governance	Clinical, revenue cycle, IT and operational representatives must approve design.	A single department may not control a shared build decision.	Prevents downstream conflicts and fragmented configuration.
Required training and role validation	Analysts, super users and end users receive role-specific preparation.	Time away from patient care and mandatory training obligations.	Reduces operational disruption at activation.
Readiness gates	Technical dress rehearsals, integrated testing and 120/90/60/30-day readiness reviews assess preparedness.	Open issues are visible to executives and can force corrective action.	Surfaces patient safety and financial risks before cutover.
Centralized cutover	Command center, issue triage, go-live schedule and stabilization are coordinated.	Limited freedom to change workflows during activation.	Maintains a controlled transition.
Customization constraints	Organizations may tailor Epic extensively but must manage build, test and upgrade implications.	Desired changes are often challenged or pushed to post-live optimization.	Contains cost and long-term maintenance burden.

Epic implementation is Foundation-first, governed, highly scheduled, and adoption-intensive. The characterization “draconian” is an industry criticism, not Epic's formal methodology name. The documented mechanisms behind that impression are:

10.1 Why Epic implementations are perceived as rigid

Stage	Epic implementation practice	Primary ownership
1. Initiation	Governance, charter, scope, executive sponsorship, project plan	Hospital leadership + Epic implementation leads
2. Foundation & discovery	Review Foundation System / standard workflows; identify local variation and decisions	Operational workgroups + Epic
3. Design & build	Workflow validation, configuration, security, application build waves	Hospital certified application analysts + Epic TS/IS
4. Data & interfaces	Legacy conversion, HL7/FHIR integrations, external systems, device setup	Hospital technical teams + vendors + Epic
5. Testing	Application testing, integrated workflows, billing/claims, conversion validation	Application analysts + clinical/business owners
6. Readiness	Training, Day-in-the-Life, technical dress rehearsal (TDR), go-live readiness assessments (GLRA)	Hospital training/operations/IT + Epic
7. Go-live	Cutover, on-site support, command center, triage, defect prioritization	Hospital + Epic + external partners
8. Stabilize & optimize	Resolve defects, measure adoption, hand over into operational support	Hospital support organization + Epic

Terminology: Foundation System, workflow validation, build waves, integrated testing, Day in the Life, TDR, GLRA, command center, optimization. Methodology classification: organizational implementation approach, not an Epic software module.

Evidence: Stanford implementation phases · UMC/TTUHSC implementation timeline · Epic vendor services.

Support Organization & Operating Model

Support is shared across customer operations, customer IT, Epic employees and optional consulting or technology partners. Hospital support is not exclusively staffed by Epic.

Layer / Team	Staffing model	Role / escalation
L0. Super users / education	Hospital operations	Answer workflow questions, coaching, adoption
L1. Service desk	Hospital in-house or outsourced	Ticket intake, access, basic troubleshooting and routing
L2. Certified Epic application analysts	Hospital staff or contractors	Application build, In Basket routing, clinical workflow, billing, Cadence/Prelude and other module support
L2. Interface & integration	Hospital integration team, vendors or managed services	HL7/FHIR interfaces, interface engine, APIs, connected applications; coordinate with Epic Bridges/Interconnect
L2. Infrastructure & ECSA	Hospital IT, Epic Hosting or other host	Client infrastructure, servers, environment operations, networking and device issues
L3. Epic Technical Services (TS)	Epic employees	Epic-specific technical/product issues escalated by customer analysts
Implementation Services (IS)	Epic employees	Project and workflow implementation support during rollout
Project/PMO & clinical governance	Hospital + Epic + contractors	Priorities, change control, operational decisions, release readiness
Boost / staff augmentation	Epic Boost or outside consultants	Additional Epic-focused PM or technical capacity when contracted
Third-party vendor support	External vendor	Vendor-owned application, interface endpoint or device problems
Community Connect host	Large hosting health system	Application support, upgrades and service desk for subscribed clinics; model varies by sponsor

Typical escalation

User → hospital help desk → module/application analyst → Epic TS (if an Epic product issue). External-interface defects also route to the hospital integration team and the third-party vendor. Infrastructure incidents route to the responsible hosting team.

Integrated into other support systems?

Yes. A hospital may use its enterprise ITSM / ticketing platform, change-management and monitoring systems, and its own integration engine. Epic product escalation and vendor collaboration remain distinct from the hospital’s internal service-desk workflow. No universal ITSM vendor or mandatory ticketing platform is implied.

Support-by-hosting-model

Model	Clinical/application support	Infrastructure support
Hospital self-hosted	Hospital analysts + Epic escalation	Hospital infrastructure teams
Epic Hosting	Hospital analysts + Epic escalation	Epic hosting operations; local devices remain hospital responsibility
Community Connect	Sponsoring health system support (contract-dependent)	Hosting health system; local networks/devices generally remain practice responsibility

Evidence: Epic official support roles · Epic Boost · NYP Community Connect handoff · AdventHealth Community Connect support and upgrades.