Once a health system has more than one source of truth, reporting on Epic data alone stops being enough. Leaders want to combine clinical data with claims, registry feeds, and third-party quality data, and they want answers fast enough to act on. That is the job Epic Caboodle was built for. It is Epic's enterprise data warehouse, and it sits one layer above Clarity in the analytics stack.
This guide explains Epic Caboodle for the teams who build analytics on it: what it is, how its dimensional model works, how it differs from Clarity, and what it actually powers. For the full module-by-module picture, our Epic integration services is the hub this guide links back to.
What Epic Caboodle is
Caboodle is Epic's enterprise data warehouse, part of the Cogito analytics suite. The name replaced the older "Cogito" branding for the warehouse itself. Where Clarity restructures Epic data into a relational reporting model, Caboodle takes it a step further and shapes the data into an analytics-ready dimensional model. A scheduled ETL, typically nightly, transforms Clarity data into Caboodle's facts and dimensions.
The capability that sets Caboodle apart is its appetite for outside data. It is designed to bring in non-Epic sources, claims, registry feeds, and third-party quality data, alongside the Epic data, so the enterprise can answer questions that span systems. Clarity is built to explain what happened inside Epic. Caboodle is built to answer enterprise questions without slowing Epic, Clarity, or itself down.
Caboodle vs Clarity
The two are partners, not rivals, but they do different jobs.
Clarity is normalized and relational, holds Epic data, and is the home of operational and regulatory reports. Caboodle is dimensional, can incorporate external data, and is built for fast enterprise analytics. In most health systems they are used together: Clarity feeds Caboodle, reporting runs against Clarity, and enterprise analytics runs against Caboodle, giving one governed source of truth. If you are still deciding which reporting layer you need, our Epic Clarity guide covers the relational side in depth.
How Caboodle's dimensional model works
If you have worked with any data warehouse, Caboodle's structure will feel familiar. It uses a dimensional, star-style model: central fact tables hold the measurable events, and dimension tables describe them.
A fact table might hold encounters or charges, the things you count and measure. Dimension tables hold the context: patient, date, provider, department, diagnosis. An analyst slices a fact by one or more dimensions, for example charges by department by month, and the model is built to make that fast. This is a deliberate contrast to Clarity's normalized tables, which are accurate but slower to query for analytics. The dimensional shape is what lets tools query Caboodle quickly across millions of rows.
What Caboodle powers
Because Caboodle combines Epic and external data in an analytics-ready shape, it underpins the enterprise-level work that matters most to leadership.
Population health work uses Caboodle for risk stratification, finding care gaps, and building chronic-disease cohorts across the whole patient panel. Financial and operational analytics draws on it for cost and utilization, service-line margin, and capacity planning. Quality and value-based care programs rely on it for quality measures, payer reporting, and outcomes tracking, where combining clinical and claims data is the whole point.
On the tooling side, Caboodle feeds Epic's own SlicerDicer for self-service exploration, external BI tools like Tableau and Power BI, and Reporting Workbench. Your BI layer queries the warehouse, not the live system.
The gotchas worth knowing
Caboodle is powerful, but a few realities shape any project:
- It depends on Clarity. Caboodle's ETL transforms Clarity data, so Clarity has to be healthy first. Problems upstream show up downstream.
- Nightly refresh. Like Clarity, Caboodle is not real-time. It answers yesterday's questions well; live data needs FHIR or HL7.
- Extending the model takes discipline. Adding custom facts and dimensions, or bringing in external data, is supported but needs careful design to stay maintainable.
- PHI governance scales with the data. Combining Epic and external data raises the stakes on access control, de-identification, and audit logging.
Getting Caboodle data into your own analytics
For healthtech teams and analytics groups, Caboodle is often the cleanest source for Epic data because it is already modeled. A common pattern is to extract Caboodle's facts and dimensions into a cloud warehouse such as Snowflake or BigQuery, layer your own modeling on top, and serve dashboards or product features from there. Because the data arrives already shaped into facts and dimensions, the modeling work downstream is lighter than starting from Clarity, though the external-data and PHI governance still need real attention.
Extending Caboodle with your own data
Out of the box, Caboodle ships with a large set of Epic-defined facts and dimensions covering encounters, charges, diagnoses, and more. The value for many systems comes from extending it with custom facts, custom dimensions, and data marts that combine Epic data with claims or device feeds. Epic supports this through documented extension points, but it rewards discipline. Custom objects built against the grain of the existing model become slow and confusing, and they break after the next upgrade.
The teams that get the most from Caboodle treat the warehouse as a product. They document each custom fact and dimension, agree on definitions so that "a visit" means the same thing in every report, and version their changes. That governance is unglamorous, and it is exactly what separates a trusted enterprise analytics layer from a pile of conflicting dashboards.
Self-service analytics with SlicerDicer
A major reason health systems invest in Caboodle is SlicerDicer, Epic's self-service exploration tool that sits on top of the warehouse. It lets non-technical users slice populations and outcomes without writing SQL, which takes routine questions off the analytics team. For a vendor or analytics group, knowing what SlicerDicer already answers helps you avoid rebuilding reports the health system can produce itself, so your integration focuses on the questions it cannot.
What a Caboodle project actually involves
A typical engagement starts from the questions leadership needs answered, works back to the facts and dimensions required, checks whether they already exist in the standard model, and only then designs custom objects or external feeds. Data governance runs through all of it: definitions, access control, and PHI handling agreed before the first table is built. The ETL schedule, the dependency on Clarity, and the refresh windows are confirmed so expectations about data freshness are correct from the start. None of this is exotic data engineering, but all of it is specific to how Epic and Cogito are built, which is where domain experience earns its keep.
How we approach Epic Caboodle work
Healthcare is the only industry we work in, and we have built EHR integrations and analytics pipelines for 30+ healthtech startups. We have moved Epic data into cloud warehouses and product databases with PHI governance designed in. We open-sourced a Headless EHR covering 28 clinical domains and more than 70 FHIR R4 resources, so the clinical data model is well understood by our team.
Our work is HIPAA-compliant by default, with SOC 2 and ISO 27001 behind it, which is what a health system's data-governance review expects. The pattern we see is that Caboodle projects succeed when the dimensional model and the external-data strategy are designed together, not bolted on later.
Caboodle, FHIR Bulk Data, and the modern stack
Caboodle is no longer the only way to get bulk Epic data. Epic's FHIR Bulk Data support lets a backend service export large data sets over a standard API, which appeals to cloud-native teams that would rather consume FHIR than connect to a warehouse. The two are not mutually exclusive. Caboodle remains the home for curated, governed, cross-source analytics with external data blended in, while FHIR Bulk Data is a clean way to move standardized clinical data into a cloud platform. We cover that path in our Epic FHIR integration guide.
For most enterprises the answer is layered. Caboodle serves the internal analytics and quality programs that depend on combining Epic and external data. FHIR, including Bulk Data, serves apps and cloud pipelines that want standardized resources. Choosing deliberately between them, rather than defaulting to whichever the last vendor knew, is what keeps the architecture coherent as new tools arrive.
One practical note: whichever path you choose, the definitions have to match. If a dashboard built on Caboodle and a model built on FHIR disagree about what counts as an admission, leadership loses trust in both. Aligning definitions across the analytics layers is unglamorous governance work that pays off every time a number is questioned in a meeting.
Where to start
Decide which enterprise questions you actually need to answer and which non-Epic data has to be combined to answer them. That scope tells you whether Caboodle is the right layer and how much model extension your project really needs.
If you want help building on Caboodle or piping its data into your own analytics, see our Epic integration services, or reach out to talk through your analytics goals.
