Understanding Epic Caboodle

What is Epic Caboodle?

Epic Caboodle is Epic's enterprise data warehouse: a star-schema database refreshed nightly from Clarity and, where a health system adds them, other source systems. It organizes data into facts and dimensions so analysts and self-service tools such as SlicerDicer can count and compare patients, visits and outcomes without complex joins across Clarity's relational tables.

Caboodle belongs to the health system, not to Epic or to any vendor. The customer decides what it holds beyond Epic's standard content, who can query it, and what leaves it.

How does data reach Caboodle?

Data reaches Caboodle in two hops. Chronicles, the operational database clinicians work in, feeds Clarity through a nightly ETL, and Clarity data is then refined into Caboodle.

UC Davis Health describes Caboodle as a star-schema data warehouse that Epic provides, built by refining Clarity data, and as a nightly extract of operational information from Clarity and other systems. Vanderbilt University Medical Center describes its Caboodle as updated nightly, fully identifiable, holding most but not all of the data in Clarity, and including links to data from outside its Epic system.

Three consequences follow for anyone planning to use it. First, Caboodle is at least a day behind the live record, so it suits trends and reporting, not real-time decisions. Second, a field that exists in Clarity may not have reached Caboodle, so confirm coverage before designing a report. Third, it can hold data that Clarity does not, such as records from a legacy system or a registry the health system has chosen to load.

Load failures matter too. If a nightly Clarity load runs late, Caboodle's refresh waits behind it, and a morning dashboard can show the day before yesterday without saying so. Ask the health system how it signals a late or partial load.

What does a star schema change for analysts?

A star schema puts the events being measured in central fact tables and the descriptions of those events in surrounding dimension tables. Analysts join one fact table to a few dimensions instead of tracing a long chain of relational tables.

• Facts: Rows for events such as an encounter, an admission, a result or a billing transaction, with the measures that go with them, such as length of stay or charge amount.
• Dimensions: Rows that describe who, where, when and what: the patient, the department, the provider, the date and the diagnosis.
• Shared dimensions: The same patient or date dimension serves many fact tables, so counts from different areas line up.
• Many-to-many links: Events with several values, such as an encounter with many diagnoses, need a linking table between fact and dimension, which is where double counting creeps in.

The trade is simplicity for detail. A star schema answers questions like "how many diabetic patients had an A1c in the last year, by clinic" quickly. It is weaker for questions that need every status change on an order, which Clarity's detailed tables keep.

Definitions are the other gain. When the health system defines an active patient or a completed visit once in the warehouse, every report that uses it agrees. A vendor should ask which of its needed measures already have agreed definitions, and reuse them rather than inventing its own.

Where Caboodle sits in Cogito

Cogito is Epic's name for its analytics tools, and Caboodle is one of the data stores beneath them. UC Davis Health lists Chronicles, Clarity and Caboodle as Cogito's data warehouses and SlicerDicer among its tools.

For a health system, this means Caboodle often feeds the self-service tools that clinicians and managers use directly, as well as the dashboards and reports that analysts build. UC Davis Health describes Caboodle data as optimized for retrieval and used mainly for operational analytics and self-service queries.

For a vendor, it means the health system's analytics team already knows Caboodle well. Its analysts are the people who will build, validate and schedule any extract, so involve them from the first conversation. They also know which reports leaders already trust, which is the fastest check on whether a vendor's numbers are right.

Caboodle or Clarity: a decision list for vendors

Ask for Caboodle data when the use case needs counts, trends or cohorts that line up with the health system's own reports. Ask for Clarity data when it needs detail Caboodle does not carry. This list helps decide.

• Population measures: Prefer Caboodle. Shared definitions keep the vendor's numbers in line with the customer's dashboards.
• Detailed event history: Prefer Clarity. Order status changes, audit-style timelines and rarely used fields are more likely there.
• Outside data in scope: Prefer Caboodle where the health system has loaded the outside source and linked it to patients.
• Near real-time needs: Prefer neither. Both are nightly, so use interfaces or FHIR APIs for current data.
• Large research cohorts: Either, depending on the fields. Check whether the health system already publishes a research data mart built from one of them.
• Patient-level data for an app: Prefer FHIR APIs or Bulk Data for standardized resources, and use warehouse extracts only for what those do not cover.

How does a vendor get Caboodle data?

A vendor gets Caboodle data through an extract that the health system's analysts build and run. Direct query access for outside parties is the health system's call, and an agreed extract is the simpler path to review.

• 1. Use case: Write down the question the data must answer and the decisions it supports.
• 2. Data specification: List the fields, definitions, date range, refresh frequency and file format, and mark which fields are truly needed.
• 3. Privacy review: The health system checks the request against its policies and the contract, and decides on identified, limited or de-identified data.
• 4. Build: The customer's analysts write the query or view in Caboodle and test it against their own reports.
• 5. Delivery: Files move by an agreed secure transfer, encrypted, to a location the vendor controls under its agreement with the health system.
• 6. Validation: The vendor checks row counts, totals and a sample of records against figures the analysts provide.
• 7. Schedule: The extract runs on a schedule after the nightly loads finish, with an alert when it is late or empty.

The privacy step has a clear rule behind it. Under the HIPAA Privacy Rule's minimum necessary standard, 45 CFR 164.502(b) and 164.514(d), a covered entity limits the protected health information it discloses to the minimum needed for the purpose, outside exceptions such as disclosures for treatment. A tight data specification makes that review faster.

What should the receiving pipeline handle?

The receiving pipeline should treat each delivery as a snapshot that may correct earlier ones. Warehouse data changes after the fact: a diagnosis is coded days after a visit, a charge is reversed, or a duplicate patient record is merged.

• Landing zone: Store each file as received, unchanged, with its delivery date, so any later question can be traced to the original.
• Stable keys: Agree on the identifiers that tie rows across deliveries, such as an encounter key, and never key on names or dates alone.
• Full or incremental: Full refreshes are simpler to reason about; incremental loads are smaller but need a reliable change date and a way to send deletions.
• Look-back window: Re-send a rolling window of recent weeks with each incremental load, so late coding and corrections replace the earlier versions.
• Merged patients: Handle notices that two records are now one, or counts by patient drift upward over time.
• Schema changes: Version the specification. A new column or a changed definition is a new version, tested before it reaches production reports.

Keep identified and de-identified data in separate stores if the extract carries both. The access rules, retention periods and audit needs differ, and mixing them in one schema makes every later review harder.

Where Caboodle extracts go wrong

• Assumed coverage: The specification lists a field that exists in Clarity but not in the customer's Caboodle.
• Double counting: A join through a many-to-many link counts an encounter once per diagnosis.
• Different definitions: The vendor computes its own version of a measure that the health system already defines, and the numbers disagree.
• Silent late loads: The extract runs before the nightly refresh finishes and sends yesterday's data again.
• Over-wide extracts: Identifiers and free text are included because they were easy to add, not because they were needed.
• Customer differences: A query built for one health system is reused at another whose warehouse has been extended differently.

Agreeing definitions in the specification and validating each delivery against the customer's own figures catches these problems before anyone acts on the numbers.

How Agnotic can help

Warehouse data from an Epic customer is only useful when both sides agree on what each field means and when it arrives. Agnotic Technologies builds that for the client: data specifications written with the customer's analysts, secure delivery and loading pipelines, validation against the customer's own figures, and alerts for late or partial extracts.

Where a use case needs current or standardized data, Agnotic pairs warehouse extracts with Epic's FHIR APIs, Bulk Data or HL7 v2 feeds, so each kind of data comes from the source that fits it.

Sources

• UC Davis Health: Clinical data sources, Clarity and Caboodle
• UC Davis Health: Epic Cogito
• Vanderbilt University Medical Center: Epic data resources
• 45 CFR 164.514: Minimum necessary and de-identification