How can researchers get Epic data without waiting months for an extract?

An investigator asks how many patients with a diagnosis also had a lab result above a threshold. The question is reasonable, the answer sits in Clarity, and the request still joins a queue behind finance and operations reports. When the extract finally arrives as a spreadsheet, the protocol has moved on and the next variation starts the wait again.

The fix is less about faster analysts and more about separating the steps: exploring a population, approving its use, and delivering the records.

Why do cohort extracts take months?

Clarity is a large, normalized reporting database. A single clinical question can span encounters, diagnoses, orders, results and flowsheet rows, and the local build decides which tables hold the answer. The people who know that build are usually the same small team that serves operational reporting.

Each extract also carries approvals: the IRB protocol, the honest broker or data request review, and the minimum necessary fields. When those steps are handled per request, by email, every revision repeats them. Spreadsheets sent back to the investigator then leave the governed environment, which makes the next review harder.

Which tools give researchers self-service access?

Cohort discovery tools answer the first question, how many patients match, usually without exposing identifiable records.

• i2b2 provides a query tool over a de-identified star schema, widely used through CTSA hubs.
• Leaf, built at the University of Washington, queries an existing clinical data warehouse directly through a browser interface.
• OHDSI ATLAS defines cohorts against the OMOP common data model and supports characterization studies across sites.
• TriNetX offers counts and analysis across a federated network of institutions.
• SlicerDicer lets Epic users explore populations within the models their institution has built.

REDCap's Clinical Data Interoperability Services (CDIS) can pull EHR data into a REDCap project through FHIR, which helps when a study needs a defined set of fields per participant. None of these replaces a governed copy of Clarity when a study needs history, free-text notes or custom calculations at scale.

What does a governed research copy of Clarity look like?

A research copy lands Clarity tables on a schedule (Clarity itself refreshes nightly from Chronicles), keeps each load's schema so Epic upgrades are visible, and applies shared definitions once: encounter status filters, diagnosis groupings, the date that sets a reporting period. Researchers then query reviewed views rather than raw tables.

Many centers also map the copy to OMOP so that ATLAS and multi-site studies can reuse cohort definitions. The mapping is a project of its own; plan which source fields carry the meaning before loading.

How do Clarity and REDCap data meet?

Study data usually lives in REDCap: consent status, study arm, case report forms. Clinical history lives in Clarity. Joining them needs a reliable identifier (a medical record number stored in the REDCap project, or a linkage table kept by the honest broker) and a rule for which clinical events count for each participant, often relative to enrollment date.

Keep the join in the governed environment. Exporting both sides to a laptop to merge them recreates the problem the research copy was meant to solve.

Which access controls will an IRB look for?

The institution and its IRB decide what a study may see. The platform's job is to make that decision enforceable and reviewable.

• Access granted per study and per person, removed when the protocol ends.
• Identifiable columns (names, MRNs, dates of birth) hidden unless the protocol allows them; limited data sets and de-identified views as separate objects.
• Every query and export logged with who ran it and when.
• Data kept inside the institution's own cloud tenant, under its existing network and identity policies.

Where does Databasin fit?

Databasin was built at Washington University School of Medicine's Institute for Informatics, Data Science and Biostatistics because research pipelines from Epic kept failing. It extracts Clarity (and Caboodle where an institution has it), connects REDCap and other research sources, and lands them in a lakehouse inside your own Azure tenant.

Access rules apply at the catalog, table and column level and are checked before data is read; restricted cohorts are delivered as their own tables because row-level filters are not part of the rules today. Researchers work in Python notebooks (PySpark), in SQL, or by asking questions in plain English and checking the SQL behind each answer. Our team implements the connections, the shared definitions and the first study views with your research informatics group.

Example: from feasibility count to approved extract

An illustrative sequence for a single study:

Checks before opening self-service access

1. Name the cohort toolDecide whether investigators start in i2b2, Leaf, ATLAS, TriNetX or SlicerDicer, and what each may show.
2. Agree the shared definitionsWrite down encounter, diagnosis and date rules once, in the research copy, before studies reuse them.
3. Map identitiesConfirm how REDCap participants link to Clarity patients and who maintains that link.
4. Test the controlsRun a study role against the copy and confirm hidden columns stay hidden and every query is logged.

Sources