How to Use SlicerDicer in Epic

This guide walks you through how to use SlicerDicer in Epic to build a patient cohort that is clear, reproducible, and easy to explain to colleagues. Using generic mock screens as a reference, you will learn how to set your unit of analysis, apply inclusion criteria, group and measure your results, and save your work so it can be trusted and shared with confidence.

Prerequisites

Before you begin, you should understand what SlicerDicer is designed for and what it is not:

• Use SlicerDicer for exploratory questions, such as testing a hunch, inspecting trends within a population, or comparing subgroups.
• Do not use SlicerDicer for formal regulatory reporting, automated production reporting, or causal inference (unless you perform a separate validation).

SlicerDicer is best suited for quick, visual exploration rather than formal, validated reporting.

Understanding the analytical loop

As you build your analysis in SlicerDicer, keep in mind five independent decisions that shape your results:

• Population: Who or what is included?
• Slices: How should the same population be grouped?
• Measures: What quantity should the visual encode?
• Dates: Which event date and time window apply?
• Visual: Which display makes the comparison legible?

Each of these components adjusts your report independently, so understanding how they interact is key to building a cohort you can explain.

1

Choose the correct data model

Before selecting any filters, decide which data model matches the question you are asking:

• Patients Data Model: Use when you want cohort counts, where one result equals one patient. For example, a patient with five ED visits still contributes one patient result.
• Encounters Data Model: Use when you need visit counts, where one result equals one encounter. The same patient may contribute several encounter results.

If you choose the wrong unit, every later click can be technically correct while the final answer is still wrong.

4

Apply the analysis date window

Before adding any time-sensitive criteria, set your analysis date window explicitly:

1. Click Last 12 months.
2. Click Apply.

This step prevents your report from relying on default date settings that could lead to inaccurate results. Confirm which event date is active, since some models expose more than one.

5

Add an inclusion criterion to narrow your population

To filter your patient records by clinical condition:

1. Click Population, then select Diagnosis.
2. In the criteria search, type and select your local type 2 diabetes grouper.
3. Click Include, then click Accept.

Record the grouper name or identifier if this will support research or quality improvement work.

6

Apply the clinical condition to your population

After selecting your grouper, confirm the filter:

1. Click Include.
2. Click Accept to apply this clinical condition to your population.

This ensures only patients with type 2 diabetes are included in your cohort.

8

Add evidence of recent care

To ensure your cohort reflects patients seen recently:

1. Select an Encounter criterion.
2. Set the criterion to Encounter in date range.
3. Click Use session range to apply your active session date window (for example, Last 12 months).
4. Confirm that Link to diagnosis? is set to No – separate events, unless your analysis requires otherwise.
5. Click Accept to apply the encounter filter.

10

Configure your measures

To see proportional results rather than raw counts:

1. Click the Measures + button.
2. Select Percentage to see the share of the population in each age group.
3. Click Apply to update the visualization.

13

Save your session with a clear, descriptive name

To preserve your cohort's logic for later use:

1. Click Save As in the toolbar.
2. Enter a session name that reflects the meaning and logic of your cohort, for example, T2D adults – age distribution – 12 months.
3. Click Create Session to save your work.

This allows you to reload or share the exact logic later, treating your results as a refreshable, dynamic set rather than a static snapshot.

Understanding saved results as dynamic

A saved session preserves the build definition, not a fixed result — counts may refresh as data updates. Sharing is permission-controlled, so only authorized users can access shared sessions.

Performing final checks before sharing or trusting results

Before you trust or share your numbers, run through these six quick checks:

• Verify the unit of analysis.
• Confirm your date window.
• Check the logic of your inclusion/exclusion criteria.
• Account for missing data.
• Ensure your measures and visualizations match your question.
• Review for any other context-specific considerations.

Reviewing the measure type and performing a face validity check

After configuring your measures, review the selected measure type to confirm it aligns with your analysis goals. Perform a quick face validity check by confirming that the results make sense given your knowledge of the population and question. If results appear unexpected, revisit your filters, slices, and measure definitions for possible errors.

Ensuring proper governance and validation for research use

If you are using SlicerDicer for research purposes, confirm the appropriate governance and approvals are in place:

• Confirm IRB (Institutional Review Board) or preparatory-to-research and privacy requirements.
• Validate phenotype logic and code/groupers locally.
• Document the data model, date ranges, filters, and measure definitions used.
• Use only approved detail/export workflows, as access is permission-dependent.

Refer to your institution's policies for additional requirements.

Protecting patient privacy in shared materials

Never include screenshots or exports containing patient identifiers in your shared screenshots, reports, or training materials. Always de-identify data before sharing or presenting.

The repeatable SlicerDicer recipe

Use this structured approach for every SlicerDicer analysis:

1. Frame: Write the unit, population, window, and outcome before opening Epic.
2. Model: Choose the data model that returns the correct unit.
3. Filter: Build inclusion and exclusion criteria, then inspect the definitions.
4. Slice: Group the same population to expose meaningful variation.
5. Measure: Choose the statistic that answers your question.
6. Validate: Check dates, logic, missingness, and face validity.
7. Save: Use a descriptive session name and document the build.

This recipe ensures your work is robust, reproducible, and easy to review.

Summary

By following these steps, you now know how to use SlicerDicer in Epic to build a clearly defined, explainable cohort — from selecting the right data model and applying inclusion criteria, to configuring measures, validating your results, and saving your session for future use. With your question framed, model selected, filters and slices applied, measure chosen, output validated, and work saved, you are ready to begin exploring your data in Epic SlicerDicer. Always prioritize data privacy and institutional governance throughout your workflow.