The One-Database Platform Strategy
Build every application on one shared database instead of stitching systems together through acquisitions.
- Difficulty
- Expert
- Time to result
- ~ongoing to results
- Steps
- 5
- Confidence
- 85%
Epic's core strategic bet, made when founder Judy Faulner wrote the original Chronicles database in the 1970s, is that every application a hospital needs — clinical records, billing, scheduling, patient portal, research analytics — should read from and write to a single unified database rather than separate systems glued together after acquisitions. Competitors like Cerner grew by merging dozens of acquired companies, each with its own database and architecture, creating integration gaps where data gets lost or delayed. Epic instead refused all M&A and built every new module (Resolute for billing, MyChart for patients, Cosmos for research) natively on top of Chronicles. The payoff is extreme reliability and a coherent pitch to hospital buyers: implementations finish on time, on budget, and stay up, because there's only ever one system to break.
Origin
Judy Faulner had a sudden, complete insight for a single integrated patient database while sitting in her living room in the mid-1970s and immediately wrote the code that became Chronicles.
How to run it
- 1
Build one canonical data model first
Design a single core database that represents the entire domain (in Epic's case, a patient's whole care journey) before building any user-facing application on top of it.
Pro tip Pick a data model general enough that every future department or use case can be represented as new tables and screens, not a new database.
- 2
Refuse to grow by acquisition
Commit to building every new capability in-house on the same database rather than buying companies with incompatible architectures, even when a competitor or partner offers a shortcut.
Watch out A single failed partnership (Epic's Philips radiology deal) can create years of scar tissue against integrations — weigh partnerships carefully before committing engineering resources.
- 3
Layer new modules on the same foundation
When entering an adjacent use case (billing, scheduling, patient portal, research), build it as an application that queries the existing core database rather than a bolt-on system with its own data store.
- 4
Sell breadth as reliability, not just convenience
Position the unified architecture to buyers as the reason implementations won't fail: no data can get lost or delayed between systems because there's only ever one system.
Pro tip Use documented case studies of competitors' fragmented-implementation failures as the negative proof point in sales conversations.
- 5
Refuse to split the system across vendors, even under customer pressure
When a large customer wants to divide the business between your platform and a competitor's (e.g., outpatient vs. inpatient), make the case that a single vendor is required for the architecture to deliver its core value.
Watch out This requires the confidence and product maturity to back up the claim — Epic only won this argument because it already had inpatient and outpatient products built on Chronicles.
In the wild
Kaiser initially wanted to run Cerner for inpatient care and Epic for outpatient clinics, since Cerner was seen as the trusted leader in hospitals. Judy told Kaiser this was the wrong decision for patient care and billing continuity, and pushed them to pick one vendor.
→ Kaiser ultimately selected Epic for the entire system, and the 2003 deal roughly tripled Epic's revenue overnight.
Epic's chief rival Cerner grew primarily through acquisitions — merging with 24 companies and later absorbing 12 more via the Siemens Health deal — resulting in separate 'Cerner customers' and 'Siemens customers' who, years later, still weren't fully integrated onto one system.
→ Fragmented architecture is cited as a contributing factor in Cerner's later struggles, including catastrophic delays on the DoD and VA contracts, before Oracle acquired the company in 2021.
Common mistakes
Growing through unrelated acquisitions
Merging in outside companies to add capability (as Cerner and Allscripts did repeatedly) creates permanent integration debt between incompatible databases and architectures.
Letting customers split the system across vendors
Allowing a buyer to run different vendors for different care settings reintroduces exactly the data-continuity failures a unified platform is meant to prevent.
Chasing distribution through partnerships that fragment control
Epic's earlier co-development deal with Philips cost years of engineering time and folded within a year or two, teaching the company to avoid dependencies it couldn't control.
Is it for you?
Best for
Vertical software companies where reliability and data continuity across functions is the primary buying criterion.
Not ideal for
Fast-moving horizontal software markets where speed of feature delivery via acquisition matters more than deep integration.
From the transcript
“It directly talks to whether it's the clinical side for EMRs, whether it's the billing side with the resolute module that Epic has, whether it's…”
From the episode
Epic Systems (MyChart)