Skip to main content

Glossary

Data2Evidence builds on the OHDSI ecosystem, so the documentation uses vocabulary from three overlapping worlds: the OMOP data standard, the OHDSI tools built on top of it, and Data2Evidence's own concepts. This page defines the terms as they are used in these pages. Where a term has a broader meaning elsewhere in the OHDSI community, the definition here describes what it means in Data2Evidence specifically.

Data model and vocabulary​

OMOP CDM​

The Observational Medical Outcomes Partnership Common Data Model: a standard table layout for observational health data. Converting a hospital's or registry's data into the OMOP CDM means the same analysis can run unchanged against any other OMOP dataset. Data2Evidence supports CDM versions 5.3 and 5.4. The version a dataset uses is shown on its dataset card.

OHDSI​

Observational Health Data Sciences and Informatics: the open science community that maintains the OMOP CDM and the surrounding tool ecosystem (ATLAS, Achilles, the Data Quality Dashboard and others). Data2Evidence is an OHDSI project.

Concept​

A single coded idea in a patient record: a condition, a drug, a procedure, a measurement, a visit. Every concept has a numeric concept_id. Concepts are the atoms that cohort definitions are built from.

Standard concept​

The canonical concept that Data2Evidence uses for analysis. Source data often codes the same idea in different ways (an ICD-10 code here, a local code there); each of those source concepts maps to one standard concept, so that an analysis written once matches records regardless of how they were coded originally.

Concept set​

A named, reusable collection of concepts that together express one clinical idea — for example "type 2 diabetes" as the set of all concepts meaning that diagnosis. Concept sets are the building blocks of cohort definitions. See Concepts.

Vocabulary​

The reference tables that define every concept, its relationships and its mappings. Data2Evidence loads these from Athena into a dedicated schema (conventionally cdmvocab). See Load Athena vocabularies.

Athena​

The OHDSI website that packages the standardised vocabularies for download. Downloading a vocabulary bundle from Athena is a prerequisite for concept search working in Data2Evidence.

An optional vocabulary table that powers the "related concepts" suggestions shown while building a concept set. See Load concept_recommended table.

Research concepts​

Cohort​

A set of patients who meet defined inclusion and exclusion criteria over some period of time — also called a phenotype. Cohorts are the unit most analyses operate on: you define one, then characterize it or compare it against another. See Cohorts.

Target cohort and outcome cohort​

Many analyses take two cohorts: the target is the population you are studying, and the outcome is the event you are looking for within it. A Kaplan-Meier survival analysis, for instance, measures how long members of the target cohort go before the outcome occurs.

Table 1​

The baseline characteristics table conventionally printed first in a clinical paper, summarising the study population's demographics and covariates. See Table 1.

Kaplan-Meier​

A method for estimating survival probability over time that correctly handles censored cases — patients whose outcome had not occurred by the end of the study, or who were lost to follow-up. Available as a pre-configured analysis. See Analysis.

Data characterization​

An automated descriptive summary of what is actually in a dataset: record counts per table, distributions by age and sex, most frequent conditions and drugs, and so on. Run as a job by an administrator; the results appear as dashboards for researchers. See Data Characterization job.

Data Quality Dashboard (DQD)​

An OHDSI tool that runs roughly 4,000 automated checks against a dataset and grades the results against thresholds, organized by the Kahn framework's categories of plausibility, conformance and completeness. See Data Quality job.

SynPUF-1k​

A small synthetic dataset (about 1,000 patients) derived from public Medicare claims data. It contains no real patient information, which makes it the usual choice for testing an installation. See Load SynPUF-1k.

Broadsea​

An OHDSI project that packages the reference tools as Docker containers. Its atlasdb demo database is one of the ways to get a working dataset into Data2Evidence quickly. See Broadsea-atlasdb.

Data2Evidence platform​

Researcher Portal​

The interface researchers use: browse datasets, build concept sets and cohorts, run notebooks and analyses. See the User Guide.

Admin Portal​

The interface administrators use: manage users and roles, register datasets, configure database credentials, and run and monitor jobs. Reached from Account in the top right. See the Admin Guide.

d2e CLI​

The d2e command line executable that installs and operates a deployment — d2e init generates secrets, d2e pull and d2e start bring the services up, d2e clean removes everything. See D2E CLI.

Dataset​

A registered data source that researchers can browse and analyse. A dataset points at a database schema, carries its own metadata and access permissions, and is either public or restricted to users who have been granted access.

Source dataset and cache dataset​

A source dataset points at the patient data itself. A cache dataset is a derived copy that Data2Evidence maintains to make concept search and dashboards responsive without repeatedly querying the source. Some management modes use both; after an upgrade the cache may need rebuilding with Update cache.

Schema​

The Postgres schema holding a dataset's tables. Deployments conventionally use cdmdefault for the CDM tables, cdmvocab for the vocabulary, and cdmdefaultresults for the cohort and results tables — the last must be separate from the CDM schema.

alpdev_pg​

The default name of the Postgres database that holds patient schemas in a standard installation. See Postgres initialization.

Dataflow​

A pipeline that performs work against a dataset — loading data, running data quality checks, generating characterization results. Dataflows are executed by Prefect and surfaced in the Admin Portal as Jobs.

Job​

One execution of a dataflow, with a status and logs. The Jobs page in the Admin Portal is where you watch a run and diagnose a failure.

Plugin​

A packaged analysis or dataflow that can be added to a deployment, letting administrators extend the platform with analyses beyond the built-in ones.

Notebook​

An in-browser Starboard notebook for running Python against a cohort or dataset. Intended for lightweight exploration rather than heavy processing. See Notebooks.

Data Load template​

A ready-made dataflow in the ETL portal that ingests a zip of CSV files into a dataset: upload, transform, optionally truncate the target tables, then load. See Load data via templates.

Roles​

Roles are cumulative — a user holding several roles has the combined permissions of all of them. See User management.

Viewer​

Can see datasets and request access to restricted ones. The default role, and enough for most researchers to get started.

Researcher​

Can build cohorts and run analyses on datasets they have access to.

Dashboard Viewer​

Can open the data quality and data characterization dashboards.

Administrator​

Full administrative access: users, datasets, configuration and jobs.

User Admin​

Can manage user accounts and role assignments, without full system administration rights.

Job Runner​

Can execute jobs and background tasks.

Inactive​

A disabled account. The user cannot sign in or perform any operation.

Infrastructure​

FQDN​

Fully Qualified Domain Name — the public hostname a remote deployment is reached on. Local workstation installs use localhost instead and can leave the FQDN unset. See Environment types.

Caddy​

The web server that terminates TLS and routes requests to the internal services. It is what issues the self-signed certificate you accept on a local install.

Prefect​

The workflow engine that schedules and executes dataflows. Job run logs in the Admin Portal come from Prefect.

Logto​

The identity provider that handles sign-in, sessions and the initial admin account.

DuckDB​

An embedded analytical database. Data2Evidence uses DuckDB files for cache datasets and for validating CDW configuration.

FHIR​

Fast Healthcare Interoperability Resources — a standard for exchanging health data via a REST API. Data2Evidence can expose a FHIR server as an alternative to OMOP-shaped datasets. See FHIR server.