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. See OHDSI tools in Data2Evidence for the tools Data2Evidence integrates.

Concept​

A single coded idea in a person's 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 persons 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. An incidence rate analysis, for instance, calculates how often the outcome occurs in the target cohort during a time at risk.

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 in the ATLAS data source reports of the Researcher Portal. 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 persons) derived from public Medicare claims data. It contains no real person 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​

ATLAS​

The OHDSI web application for vocabulary search, concept sets, cohort definitions and analyses on OMOP CDM data. The Data2Evidence Researcher Portal integrates ATLAS 3. Its user manual opens from the User manual icon in the Researcher Portal.

Researcher Portal​

The interface researchers use to find data sources, build concept sets, explore data, create cohorts, and run analyses and notebooks. Integrates ATLAS 3 alongside Data2Evidence features. See the User Guide.

Data Exploration​

The interactive way to explore the persons of a data source with filter cards, charts and the Person List. What it offers is set by the Data Exploration configuration. See Data Exploration and Data model configuration.

Admin Portal​

The interface administrators use: manage users and roles, register datasets, configure database credentials, and run and monitor jobs. Reached by selecting your user name in the top right and then Switch to Admin portal. 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 Data2Evidence 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 person-level 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 the person-level data 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 notebook for running Python or R against a cohort or data source, opened from Studies in the Researcher Portal. Intended for lightweight exploration rather than heavy processing. See Studies and 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 concept sets, explore data, create cohorts, and run analyses on the data sources 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.