SlicerDicer is a self-service data exploration tool built into Epic, the electronic health record (EHR) system used by a large share of hospitals and health systems in the United States. It lets clinicians, administrators, and analysts query their organization’s patient data without writing code or submitting formal data requests to an IT department. Think of it as a point-and-click way to ask questions of the EHR: how many patients with a certain diagnosis visited last quarter, what percentage of a clinic’s diabetic population has an A1c above a given threshold, or how readmission rates differ between two care pathways. The tool sits inside the Epic environment that staff already use every day, which is a big part of its appeal and a source of some of its quirks.
How SlicerDicer Actually Works
At its core, SlicerDicer is a drag-and-drop query builder. You start with a broad population, usually all patients in your health system’s Epic database, and then narrow it down by layering on filters. Those filters can include diagnoses, procedures, medications, lab results, demographics, encounter types, date ranges, and dozens of other data points that live in the EHR. The interface is hierarchical: you set a primary population filter first, then stack additional inclusion and exclusion criteria on top of it. One published study, for example, described building a SlicerDicer query that started with all patients seen in a primary care service line during a given timeframe who had a documented weight, then further filtered by clinical criteria to match a specific quality measure for abnormal BMI screening.
Once your filters are set, SlicerDicer returns aggregate counts and visualizations rather than individual patient records. You might see a bar chart showing how many patients fall into each age bracket, or a line graph tracking encounter volume month by month. The results update in near-real time, which means you can tweak a filter and immediately see how the numbers change. This makes it useful for exploratory questions where you are not entirely sure what you are looking for yet and want to iterate quickly.
Epic offers several “modes” within SlicerDicer, each oriented to a different data domain. The most commonly used ones revolve around patient populations, encounters, and procedures, but some organizations also configure modes for financial data or flowsheet measurements. Which modes are available depends on how your organization has set up and licensed the tool. Not every Epic customer gets the same SlicerDicer experience, because health systems can customize which data columns are exposed, which user roles have access, and how deeply the filters drill down.
What People Use It For
The use cases fall into a few broad buckets, but the common thread is that SlicerDicer replaces what used to be a formal data request. Instead of emailing an analytics team and waiting days or weeks for a custom report, a staff member can pull rough numbers in minutes.
Clinical quality improvement is one of the biggest drivers. A pharmacy department, for instance, might use SlicerDicer to identify how many patients on a particular medication class had a relevant lab value checked in the past year, then use that information to prioritize outreach or adjust protocols. One academic medical center described implementing SlicerDicer as an on-demand tool so frontline pharmacy staff could make data-driven recommendations and interventions without depending on centralized analytics support.1PubMed Central. Implementation of a Self-Service Data Exploration Tool Within an Academic Medical Center Department of Pharmacy
Research feasibility is another common application. Before investing months in a formal study, investigators use SlicerDicer to estimate whether enough patients meeting their criteria exist in the system to make a study viable. A team at the University of Rochester, for example, used SlicerDicer to conduct a retrospective cohort study assessing pregnancy rates among young breast cancer patients, pulling deidentified data filtered by chief complaint and date range directly from the tool.2Journal of Clinical Oncology. Use of Epic SlicerDicer to assess pregnancy rates in adolescent and young adult patients with breast cancer For preliminary screening of patient populations, it can save a research team significant time compared to requesting a formal data pull.
Operational and administrative uses round out the picture. Hospital leaders track patient volumes by service line, monitor trends in emergency department visits, compare telehealth adoption across clinics, or flag shifts in payer mix. Because SlicerDicer queries are fast and repeatable, they work well for the kind of week-over-week monitoring that operational managers need.
Who Gets Access
Access to SlicerDicer is controlled by your organization’s Epic security settings, not by Epic itself. This means the answer to “can I use SlicerDicer?” varies enormously from one health system to another. Some organizations grant access broadly to physicians, nurses, pharmacists, and quality improvement staff. Others restrict it to a smaller group of analysts and informaticists.
In most setups, you need an active Epic login and a security role that includes SlicerDicer privileges. Your IT or informatics team assigns this role, and it may come with restrictions on which data domains you can query. A physician might be able to search patient populations and encounter data, for example, but not financial or billing fields. Some organizations also limit which patients appear in your results based on your department or care setting, so a dermatology provider might only see data for patients who have been seen in dermatology-related encounters.
One thing that catches people off guard is that SlicerDicer typically works with deidentified or aggregate data by default. You see counts, percentages, and trend lines, not individual patient charts. If you need a list of specific patients to contact for a quality improvement project or a research study, you generally need a different tool or an additional step, often involving your organization’s reporting workbench or a formal data request. SlicerDicer is designed for the “how many” and “what does the trend look like” questions, not the “give me a roster” questions.
The Training Problem
SlicerDicer looks deceptively simple. The interface is visual, the filters are labeled in clinical language, and the results appear quickly. But getting reliable, meaningful answers out of it requires more than clicking around. Users need to understand which filters map to which EHR data fields, how date logic works, what “encounter-based” versus “patient-based” counting means, and how their organization’s documentation practices shape the data that appears.
Training programs have had mixed success. A project that trained pediatric physicians and staff to use SlicerDicer for EHR data extraction found that scheduling alone was a significant barrier: clinicians had limited availability during business hours because of competing clinical and administrative priorities, making it hard to set up recurring training sessions.3Healthcare. Training pediatric physicians and staff to obtain data from the electronic health record The informaticists running the program invested considerable time and effort, and even then, adoption was uneven.
This is a recurring theme in health IT: tools that are technically available to frontline staff often go underused because learning them competes with patient care for the same scarce resource, which is time. Organizations that have seen better uptake tend to embed training into existing workflows, offer short on-demand video tutorials rather than lengthy classroom sessions, and designate local “super users” who can help colleagues troubleshoot queries on the spot.
There is also a softer skills gap that formal training does not always address. Knowing how to build a query is different from knowing how to ask a good question of the data. A user who does not think carefully about inclusion and exclusion criteria, or who does not understand how a particular diagnosis code maps to actual clinical practice, can easily pull numbers that look authoritative but are misleading. The tool democratizes data access, which is valuable, but it also democratizes the ability to make analytical mistakes.
Data Accuracy and Known Discrepancies
One of the most important things to understand about SlicerDicer is that the numbers it returns are only as good as the data going into it. And EHR data, for all its volume, has well-documented quality problems. A study examining discrepancies between two aggregate data sources that both originated from the same Epic EHR found that data quality and integrity can be affected by unstandardized documentation practices, differences in whether data was patient-reported or provider-assumed, changes to collection procedures over time, improperly matched data elements, and variability in how terms and categories are defined across departments.4PubMed Central. Discrepancies in Aggregate Patient Data between Two Sources with Data Originating from the Same Electronic Health Record: A Case Study
In practical terms, this means two people running what they believe is the same SlicerDicer query can get different results if they define their filters slightly differently. The word “visit” might mean an in-person office encounter to one user and any encounter type, including phone calls and patient portal messages, to another. A diagnosis filter might capture patients with a billing code on their problem list but miss those whose condition was documented only in a clinical note. Race and ethnicity data might reflect what a patient self-reported at one registration desk and what a staff member assumed at another.
These are not bugs in SlicerDicer specifically. They are inherent features of working with EHR data, which was originally designed for clinical documentation and billing rather than population-level analytics. But because SlicerDicer makes querying so easy and fast, there is a risk that users treat the numbers it produces with more confidence than the underlying data quality warrants. A formal analytics team pulling data from a warehouse would typically validate results, check for known data quality issues, and document their methodology. A clinician running a quick SlicerDicer query during a lunch break is less likely to do any of that.
Where SlicerDicer Hits Its Ceiling
SlicerDicer is powerful for what it is, but it is not a replacement for a full analytics platform, a clinical data warehouse, or a dedicated research database. There are several categories of work where it falls short.
- Patient-level data: As mentioned, SlicerDicer returns aggregate counts and charts, not patient lists. If your workflow requires identifying specific individuals for outreach, chart review, or enrollment, you need a different tool.
- Complex joins and calculations: You cannot combine data from unrelated domains in arbitrary ways. If you need to correlate a lab trend with a medication change and a subsequent hospitalization for the same patient over time, that kind of longitudinal, multi-step analysis exceeds what SlicerDicer’s filter-and-count model can do.
- Statistical analysis: SlicerDicer shows you descriptive numbers like counts, percentages, and averages. It does not run significance tests, regression models, or survival analyses. For any real research analysis, the data needs to be exported or pulled from a warehouse into a statistical software environment.
- Cross-system data: SlicerDicer queries your organization’s Epic data. If patients received care at outside facilities, had lab work done by an external reference lab that does not feed into your Epic instance, or have relevant data in a separate research registry, those data points will not appear in your SlicerDicer results.
- Unstructured data: Clinical notes, radiology report narratives, and other free-text documentation are largely invisible to SlicerDicer. The tool works with structured, coded data fields. If a critical piece of clinical information was documented only in a progress note and never entered as a discrete data element, SlicerDicer will not find it.
For organizations with mature analytics infrastructure, SlicerDicer occupies a specific niche: it handles quick, exploratory, self-service queries that do not justify a formal data request. It is the fast sketch, not the finished painting. Problems arise when users try to stretch it beyond that role, treating a SlicerDicer output as publication-ready data or using it to make high-stakes operational decisions without validation.
SlicerDicer in Research Settings
Despite its limitations, SlicerDicer has found a growing role in clinical research, primarily in the early stages of study design. Investigators use it to estimate cohort sizes, check whether a proposed set of inclusion and exclusion criteria yields enough patients to power a study, and get a rough sense of the demographic breakdown of a potential study population. This kind of feasibility work used to require a formal request to a data analyst, which could take weeks. SlicerDicer compresses that to an afternoon.
Some teams have gone further, using SlicerDicer data directly in published studies. The breast cancer pregnancy study at the University of Rochester is one example, pulling a retrospective cohort directly from SlicerDicer’s deidentified data.2Journal of Clinical Oncology. Use of Epic SlicerDicer to assess pregnancy rates in adolescent and young adult patients with breast cancer Similarly, researchers have used it to compare quality metrics between telemedicine and in-person care cohorts, building hierarchical filters that mirrored established quality measure specifications.
This trend raises a tension in the research community. On one hand, enabling clinician-investigators to explore data independently speeds up the research pipeline and opens it to people who are not trained data scientists. On the other hand, the data quality concerns described earlier are amplified in a research context, where the stakes for accuracy are higher. A quality improvement project that is directionally correct but off by a few percentage points may still drive useful action. A published study with the same margin of error could mislead the field.
Most research institutions that allow SlicerDicer for published work require additional validation steps: cross-checking SlicerDicer counts against a formal data pull, having an informaticist review the query logic, or documenting known limitations of the data source in the methods section. These safeguards add time back into the process, partially offsetting the speed advantage, but they help maintain the credibility of the findings.
Common Misconceptions
A few misunderstandings about SlicerDicer come up repeatedly among new users. The first is the assumption that SlicerDicer shows “all” patients. It shows patients whose data is captured in structured fields within your organization’s Epic system. Patients who received care elsewhere, whose conditions were documented only in free text, or whose records have data entry errors will not appear in your results. The number you see is a floor, not a census.
The second is the belief that two users running the “same” query will always get the same number. As the data discrepancy research makes clear, subtle differences in filter definitions, date range handling, and how encounter types are categorized can produce meaningfully different results from what appears to be the same question.4PubMed Central. Discrepancies in Aggregate Patient Data between Two Sources with Data Originating from the Same Electronic Health Record: A Case Study If you are sharing SlicerDicer results with colleagues or leadership, documenting exactly how you built the query is just as important as the results themselves.
The third misconception is that SlicerDicer data is automatically compliant with research regulations. Depending on your organization’s configuration, SlicerDicer may return deidentified aggregate data that does not require Institutional Review Board (IRB) approval, or it may surface data that falls under HIPAA protections. The rules depend on the level of detail available in the output and how your institution classifies SlicerDicer use. Always check with your compliance or IRB office before using SlicerDicer data in a research context, even if the numbers look anonymous on screen.
How Organizations Are Expanding SlicerDicer’s Role
Some health systems have begun treating SlicerDicer not just as an ad hoc query tool but as part of a broader data literacy strategy. The pharmacy department implementation described earlier is one example: rather than reserving data access for a dedicated analytics team, the organization trained frontline pharmacists to pull their own data, shifting the culture toward routine, evidence-informed decision-making at the point of care.1PubMed Central. Implementation of a Self-Service Data Exploration Tool Within an Academic Medical Center Department of Pharmacy
This approach requires investment beyond just flipping on the software. Organizations that do it well build a support ecosystem around SlicerDicer: standardized query templates for common questions so users do not have to start from scratch, governance policies about how results should be interpreted and shared, regular audits of data quality in the fields most commonly queried, and accessible help from informaticists who understand both the clinical context and the technical quirks of the data. Without that scaffolding, broad access to SlicerDicer can produce a flood of unreliable numbers floating around an organization, each cited with the authority of “I pulled it from Epic.”
Epic itself continues to develop SlicerDicer with new features in its regular software updates. Recent iterations have expanded the types of data that can be queried, improved visualization options, and added capabilities for more granular time-based filtering. As health systems accumulate more years of structured data and as documentation practices slowly become more standardized, the tool’s practical utility will likely grow. But the fundamental tension between ease of access and analytical rigor is baked into its design, and managing that tension remains the responsibility of the organizations that deploy it.