What is Epic? Architecture and Showroom
Before you touch a single Epic API, it’s worth understanding what you’re actually integrating with. Teams often get stuck because they start building before they know what Epic even is. Once the systems and the people involved make sense, the integration patterns later in the course will fall into place.
What Epic actually is
Epic is the electronic health record or EHR that a hospital runs on. Almost everything lives here: patient charts, doctors’ orders, lab results, scheduling, billing. If you’ve ever used MyChart to check a result or message your doctor, you’ve used Epic already. That’s the patient-facing corner of a much larger system.
So “what is Epic integration” is really a question about where in that system you want to sit: reading data out, writing data back, or running your app right inside the clinician’s screen. That choice decides everything else you do downstream.
Why Epic is worth the effort
Epic is the largest EHR vendor in the US, and among big hospitals it’s the default. It runs more than 40% of hospitals, and because the largest systems lean toward it, that’s over half of all hospital beds in the country. Most of the big-name academic centers are on Epic, and it’s still growing.
Which means your biggest potential customers are probably on Epic. You can’t route around it, and the market keeps drifting Epic’s way.
The usual caveat still applies: this is mostly a US story, strongest at the big hospitals. What’s newer is that Epic is starting to win large systems in the UK and Europe too, so this may land on your radar outside the US sooner than you’d think. But if you’re selling to large hospitals, you’re selling to Epic.
Every hospital runs its own Epic
Epic sells its software to hospitals, and every hospital runs its own separate copy. They will have their own setup, data, and rules about what’s allowed in. This is a federated model.

There’s no single front door. To go live at a hospital, you work with that hospital directly: their system, their credentials, their approvals. Then the next hospital is a separate effort all over again.
The players you’ll deal with
There’s Epic, the company. They build the software, set the rules, and run the developer program you signed up for.
Then there are the hospitals. They’re Epic’s customers, and they decide whether your app gets into their system. The hospital holds the keys, not Epic. The exception is a patient-facing app, where a patient can consent to share their own data from any hospital. More on that later.
And there are the people who actually use Epic: patients, often through MyChart, and clinicians, who live inside it all day.
Epic’s architecture
Now the inside. Once you see how the pieces fit, it gets much easier to work out where you’d integrate.

Hyperdrive and Hyperspace
Start with what clinicians use. That’s Hyperdrive, the main application doctors, nurses, and staff log into to work: charting, orders, results, scheduling. It’s a client, meaning the application that sits in front of the real system and lets people use it.
Epic Hyperdrive is web-based, built on the same Chromium engine as Chrome and packaged into a desktop app with Electron, so it’s lighter to install and update than what came before. Even though it runs on web technology, it’s still installed as a desktop client, usually on Windows, not a page you reach at a URL. It’s the newer client, replacing an older one called Hyperspace, the heavy desktop version Epic ran for about two decades, usually delivered over Citrix. The switch isn’t complete, so you’ll still meet Hyperspace in plenty of hospitals.

The mobile apps: Haiku, Canto, and Rover
Clinicians aren’t always at a desk, so Epic has mobile versions. Haiku is the smartphone app for checking schedules and charts between patients. Canto is the iPad version. Rover is for nurses on the floor, built around bedside tasks like scanning a patient’s wristband and medications.
These are all the same Epic on different devices. A doctor on Haiku sees the exact same system as someone in Hyperdrive at a desk.
MyChart
The patient side is MyChart, an app and a website where patients see their own health information: test results, appointments, messages with their care team, bills, and refills. When you build a patient-facing app, MyChart is usually your way in. The patient logs in through MyChart and grants your app access to their data. We’ll go deeper on this later.
Chronicles, Clarity, and Caboodle
Underneath all of that is where the data sits, and there are two sides to it.
First, the Epic Chronicles database holds live data, everything happening in the hospital day to day. It runs on database technology from InterSystems that Epic has used for over 40 years, called Caché, or IRIS in newer systems. It isn’t a normal SQL database, which makes it very fast for hospital operations but awkward to report against directly. So Epic copies the data elsewhere for that.
That copy lives on the analytics side. Clarity is a SQL-based store that reorganizes the data for reporting, usually refreshed overnight. Caboodle is a larger data warehouse for heavier analysis.
So Chronicles is the current data; Clarity and Caboodle are copies built for analysis. We’ll come back to the analytics databases in a later lesson.
Epic runs a federated model. Which of the following best describes what that means?
Where your app fits: Showroom and Connection Hub
So where does your app go, and how does a hospital find it?
That’s the Epic Showroom, a directory of the apps and services that work with Epic, so hospitals can discover them. You’ll see older articles call this the Epic App Orchard. That name is gone. Epic shut the old marketplace down and replaced it with Showroom, so anything walking you through App Orchard is out of date.
The part you’ll care about first is the Connection Hub. A listing here shows that your app has at least one live connection to a real Epic system in production, which is why hospitals read it as a signal you’ve done this before. It costs a small yearly fee. There are tiers beyond it, but Connection Hub is the one to know starting out.
Being listed and being integrated are two different things. The listing is how hospitals find you and start to trust you. The technical work of connecting to the APIs is separate. You don’t need to be listed to connect, since the path is open either way, but plenty of hospitals want to see you there before they’ll switch your app on.
Next
That’s Epic and its architecture. In the next lesson we go through the different ways you can actually integrate with Epic, and when you’d use each.
