From e4c028d0c3e05e518ead9457970f91f26ae0aa50 Mon Sep 17 00:00:00 2001 From: Maxim Moinat Date: Tue, 25 Aug 2026 19:07:05 +0200 Subject: [PATCH 1/2] fix rendering section headers in specification --- site/R/specDocRenderer.R | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/site/R/specDocRenderer.R b/site/R/specDocRenderer.R index ce445f4e..b1dda51c 100644 --- a/site/R/specDocRenderer.R +++ b/site/R/specDocRenderer.R @@ -26,7 +26,7 @@ render_spec_doc <- function(table_file, for (table_name in table_specs$cdmTableName) { # Assume that first table in section is always the same section_header <- switch( - toupper(table_name), + tolower(table_name), person = "Clinical Data Tables", location = "Health System Data Tables", payer_plan_period = "Health Economics Data Tables", @@ -39,7 +39,7 @@ render_spec_doc <- function(table_file, cat("## ", section_header, "\n\n") } - cat("### ", table_name, "{.tabset .tabset-pills}\n\n") + cat("### ", toupper(table_name), "{.tabset .tabset-pills}\n\n") table_info <- subset(table_specs, cdmTableName == table_name) cat("**Table Description**\n\n", table_info[, "tableDescription"], "\n\n") From 2ed84526e1b5196ac96d11ebf4dd139d373bbccc Mon Sep 17 00:00:00 2001 From: Maxim Moinat Date: Tue, 25 Aug 2026 19:14:24 +0200 Subject: [PATCH 2/2] render specifications --- docs/cdm30.html | 17 ++-- docs/cdm53.html | 201 +++++++++++++++++++++++++----------------- docs/cdm531.html | 19 ++-- docs/cdm54.html | 207 ++++++++++++++++++++++++++------------------ docs/cdm55.html | 221 +++++++++++++++++++++++++++-------------------- 5 files changed, 392 insertions(+), 273 deletions(-) diff --git a/docs/cdm30.html b/docs/cdm30.html index e37b92bd..1bd07cf9 100644 --- a/docs/cdm30.html +++ b/docs/cdm30.html @@ -241,6 +241,7 @@ toggleColorMode(toAlternate); setStyleSentinel(toAlternate); toggleGiscusIfUsed(toAlternate, darkModeDefault); + window.dispatchEvent(new Event('resize')); }; // Switch to dark mode if need be if (hasAlternateSentinel()) { @@ -256,7 +257,8 @@
OMOP Common Data Model @@ -553,13 +555,14 @@

CDM v3

e.clearSelection(); } const getTextToCopy = function(trigger) { - const codeEl = trigger.previousElementSibling.cloneNode(true); - for (const childEl of codeEl.children) { - if (isCodeAnnotation(childEl)) { - childEl.remove(); - } + const outerScaffold = trigger.parentElement.cloneNode(true); + const codeEl = outerScaffold.querySelector('code'); + for (const childEl of codeEl.children) { + if (isCodeAnnotation(childEl)) { + childEl.remove(); } - return codeEl.innerText; + } + return codeEl.innerText; } const clipboard = new window.ClipboardJS('.code-copy-button:not([data-in-quarto-modal])', { text: getTextToCopy diff --git a/docs/cdm53.html b/docs/cdm53.html index ebdb3c6e..8d3aa93e 100644 --- a/docs/cdm53.html +++ b/docs/cdm53.html @@ -2,7 +2,7 @@ - + @@ -241,6 +241,7 @@ toggleColorMode(toAlternate); setStyleSentinel(toAlternate); toggleGiscusIfUsed(toAlternate, darkModeDefault); + window.dispatchEvent(new Event('resize')); }; // Switch to dark mode if need be if (hasAlternateSentinel()) { @@ -256,7 +257,8 @@
OMOP Common Data Model @@ -459,42 +461,60 @@

On this page

 @@ -527,8 +547,10 @@

OMOP CDM v5.3

Below is the specification document for the OMOP Common Data Model, v5.3 (previously v5.3.1). Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). All tables should be instantiated in a CDM instance but do not need to be populated. Similarly, fields that are not required should exist in the CDM table but do not need to be populated. Should you have questions please feel free to visit the forums or the github issue page.

Special Note This documentation previously referenced v5.3.1. During the OHDSI/CommonDataModel Hack-A-Thon that occurred on August 18, 2021 the decision was made to align documentation with the minor releases. Hot fixes and minor.minor release can be found through the searching of tags.

+
+

Clinical Data Tables

-

person

+

PERSON

Table Description

This table serves as the central identity management for all Persons in the database. It contains records that uniquely identify each person or patient, and some demographic information.

User Guide

@@ -1066,7 +1088,7 @@

person

-

observation_period

+

OBSERVATION_PERIOD

Table Description

This table contains records which define spans of time during which two conditions are expected to hold: (i) Clinical Events that happened to the Person are recorded in the Event tables, and (ii) absence of records indicate such Events did not occur during this span of time.

User Guide

@@ -1247,7 +1269,7 @@

obs

-

visit_occurrence

+

VISIT_OCCURRENCE

Table Description

This table contains Events where Persons engage with the healthcare system for a duration of time. They are often also called “Encounters”. Visits are defined by a configuration of circumstances under which they occur, such as (i) whether the patient comes to a healthcare institution, the other way around, or the interaction is remote, (ii) whether and what kind of trained medical staff is delivering the service during the Visit, and (iii) whether the Visit is transient or for a longer period involving a stay in bed.

User Guide

@@ -1776,7 +1798,7 @@

visit -

visit_detail

+

VISIT_DETAIL

Table Description

The VISIT_DETAIL table is an optional table used to represents details of each record in the parent VISIT_OCCURRENCE table. A good example of this would be the movement between units in a hospital during an inpatient stay or claim lines associated with a one insurance claim. For every record in the VISIT_OCCURRENCE table there may be 0 or more records in the VISIT_DETAIL table with a 1:n relationship where n may be 0. The VISIT_DETAIL table is structurally very similar to VISIT_OCCURRENCE table and belongs to the visit domain.

@@ -2343,7 +2365,7 @@

visit_detail

-

condition_occurrence

+

CONDITION_OCCURRENCE

Table Description

This table contains records of Events of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign, or a symptom, which is either observed by a Provider or reported by the patient.

User Guide

@@ -2827,7 +2849,7 @@

c

-

drug_exposure

+

DRUG_EXPOSURE

Table Description

This table captures records about the exposure to a Drug ingested or otherwise introduced into the body. A Drug is a biochemical substance formulated in such a way that when administered to a Person it will exert a certain biochemical effect on the metabolism. Drugs include prescription and over-the-counter medicines, vaccines, and large-molecule biologic therapies. Radiological devices ingested or applied locally do not count as Drugs.

User Guide

@@ -3496,7 +3518,7 @@

drug_exp

-

procedure_occurrence

+

PROCEDURE_OCCURRENCE

Table Description

This table contains records of activities or processes ordered by, or carried out by, a healthcare provider on the patient with a diagnostic or therapeutic purpose.

User Guide

@@ -3926,7 +3948,7 @@

p

-

device_exposure

+

DEVICE_EXPOSURE

Table Description

The Device domain captures information about a person’s exposure to a foreign physical object or instrument which is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action. Devices include implantable objects (e.g. pacemakers, stents, artificial joints), medical equipment and supplies (e.g. bandages, crutches, syringes), other instruments used in medical procedures (e.g. sutures, defibrillators) and material used in clinical care (e.g. adhesives, body material, dental material, surgical material).

User Guide

@@ -4377,7 +4399,7 @@

device

-

measurement

+

MEASUREMENT

Table Description

The MEASUREMENT table contains records of Measurements, i.e. structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person’s sample. The MEASUREMENT table contains both orders and results of such Measurements as laboratory tests, vital signs, quantitative findings from pathology reports, etc. Measurements are stored as attribute value pairs, with the attribute as the Measurement Concept and the value representing the result. The value can be a Concept (stored in VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit (UNIT_CONCEPT_ID). The Procedure for obtaining the sample is housed in the PROCEDURE_OCCURRENCE table, though it is unnecessary to create a PROCEDURE_OCCURRENCE record for each measurement if one does not exist in the source data. Measurements differ from Observations in that they require a standardized test or some other activity to generate a quantitative or qualitative result. If there is no result, it is assumed that the lab test was conducted but the result was not captured.

User Guide

@@ -4971,7 +4993,7 @@

measuremen

-

observation

+

OBSERVATION

Table Description

The OBSERVATION table captures clinical facts about a Person obtained in the context of examination, questioning or a procedure. Any data that cannot be represented by any other domains, such as social and lifestyle facts, medical history, family history, etc. are recorded here.

User Guide

@@ -5509,7 +5531,7 @@

observatio

-

death

+

DEATH

Table Description

The death domain contains the clinical event for how and when a Person dies. A person can have up to one record if the source system contains evidence about the Death, such as: Condition in an administrative claim, status of enrollment into a health plan, or explicit record in EHR data.

ETL Conventions

@@ -5740,7 +5762,7 @@

death

-

note

+

NOTE

Table Description

The NOTE table captures unstructured information that was recorded by a provider about a patient in free text (in ASCII, or preferably in UTF8 format) notes on a given date. The type of note_text is CLOB or varchar(MAX) depending on RDBMS.

ETL Conventions

@@ -6167,7 +6189,7 @@

note

-

note_nlp

+

NOTE_NLP

Table Description

The NOTE_NLP table encodes all output of NLP on clinical notes. Each row represents a single extracted term from a note.

@@ -6572,7 +6594,7 @@

note_nlp

-

specimen

+

SPECIMEN

Table Description

The specimen domain contains the records identifying biological samples from a person.

ETL Conventions

@@ -7009,7 +7031,7 @@

specimen

-

fact_relationship

+

FACT_RELATIONSHIP

Table Description

The FACT_RELATIONSHIP table contains records about the relationships between facts stored as records in any table of the CDM. Relationships can be defined between facts from the same domain, or different domains. Examples of Fact Relationships include: Person relationships (parent-child), care site relationships (hierarchical organizational structure of facilities within a health system), indication relationship (between drug exposures and associated conditions), usage relationships (of devices during the course of an associated procedure), or facts derived from one another (measurements derived from an associated specimen).

ETL Conventions

@@ -7178,8 +7200,11 @@

fact

+
+
+

Health System Data Tables

-

location

+

LOCATION

Table Description

The LOCATION table represents a generic way to capture physical location or address information of Persons and Care Sites.

ETL Conventions

@@ -7427,7 +7452,7 @@

location

-

care_site

+

CARE_SITE

Table Description

The CARE_SITE table contains a list of uniquely identified institutional (physical or organizational) units where healthcare delivery is practiced (offices, wards, hospitals, clinics, etc.).

ETL Conventions

@@ -7628,7 +7653,7 @@

care_site

-

provider

+

PROVIDER

Table Description

The PROVIDER table contains a list of uniquely identified healthcare providers; duplication is not allowed. These are individuals providing hands-on healthcare to patients, such as physicians, nurses, midwives, physical therapists etc.

User Guide

@@ -8022,8 +8047,11 @@

provider

+
+
+

Health Economics Data Tables

-

payer_plan_period

+

PAYER_PLAN_PERIOD

Table Description

The PAYER_PLAN_PERIOD table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Each Person receiving healthcare is typically covered by a health benefit plan, which pays for (fully or partially), or directly provides, the care. These benefit plans are provided by payers, such as health insurances or state or government agencies. In each plan the details of the health benefits are defined for the Person or her family, and the health benefit Plan might change over time typically with increasing utilization (reaching certain cost thresholds such as deductibles), plan availability and purchasing choices of the Person. The unique combinations of Payer organizations, health benefit Plans and time periods in which they are valid for a Person are recorded in this table.

User Guide

@@ -8522,7 +8550,7 @@

paye

-

cost

+

COST

Table Description

The COST table captures records containing the cost of any medical event recorded in one of the OMOP clinical event tables such as DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, VISIT_OCCURRENCE, VISIT_DETAIL, DEVICE_OCCURRENCE, OBSERVATION or MEASUREMENT.

Each record in the cost table account for the amount of money transacted for the clinical event. So, the COST table may be used to represent both receivables (charges) and payments (paid), each transaction type represented by its COST_CONCEPT_ID. The COST_TYPE_CONCEPT_ID field will use concepts in the Standardized Vocabularies to designate the source (provenance) of the cost data. A reference to the health plan information in the PAYER_PLAN_PERIOD table is stored in the record for information used for the adjudication system to determine the persons benefit for the clinical event.

@@ -9157,8 +9185,11 @@

cost

+
+
+

Standardized Derived Elements

-

drug_era

+

DRUG_ERA

Table Description

A Drug Era is defined as a span of time when the Person is assumed to be exposed to a particular active ingredient. A Drug Era is not the same as a Drug Exposure: Exposures are individual records corresponding to the source when Drug was delivered to the Person, while successive periods of Drug Exposures are combined under certain rules to produce continuous Drug Eras. Every record in the DRUG_EXPOSURE table should be part of a drug era based on the dates of exposure.

ETL Conventions

@@ -9383,7 +9414,7 @@

drug_era

-

dose_era

+

DOSE_ERA

Table Description

A Dose Era is defined as a span of time when the Person is assumed to be exposed to a constant dose of a specific active ingredient.

ETL Conventions

@@ -9610,7 +9641,7 @@

dose_era

-

condition_era

+

CONDITION_ERA

Table Description

A Condition Era is defined as a span of time when the Person is assumed to have a given condition. Similar to Drug Eras, Condition Eras are chronological periods of Condition Occurrence and every Condition Occurrence record should be part of a Condition Era. Combining individual Condition Occurrences into a single Condition Era serves two purposes:

    @@ -9812,8 +9843,11 @@

    conditio

+
+
+

Metadata Tables

-

metadata

+

METADATA

Table Description

The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.

@@ -10031,7 +10065,7 @@

metadata

-

cdm_source

+

CDM_SOURCE

Table Description

The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.

@@ -10331,8 +10365,11 @@

cdm_source<

+
+
+

Vocabulary Tables

-

concept

+

CONCEPT

Table Description

The Standardized Vocabularies contains records, or Concepts, that uniquely identify each fundamental unit of meaning used to express clinical information in all domain tables of the CDM. Concepts are derived from vocabularies, which represent clinical information across a domain (e.g. conditions, drugs, procedures) through the use of codes and associated descriptions. Some Concepts are designated Standard Concepts, meaning these Concepts can be used as normative expressions of a clinical entity within the OMOP Common Data Model and standardized analytics. Each Standard Concept belongs to one Domain, which defines the location where the Concept would be expected to occur within the data tables of the CDM. Concepts can represent broad categories (‘Cardiovascular disease’), detailed clinical elements (‘Myocardial infarction of the anterolateral wall’), or modifying characteristics and attributes that define Concepts at various levels of detail (severity of a disease, associated morphology, etc.). Records in the Standardized Vocabularies tables are derived from national or international vocabularies such as SNOMED-CT, RxNorm, and LOINC, or custom OMOP Concepts defined to cover various aspects of observational data analysis.

User Guide

@@ -10637,7 +10674,7 @@

concept

-

vocabulary

+

VOCABULARY

Table Description

The VOCABULARY table includes a list of the Vocabularies integrated from various sources or created de novo in OMOP CDM. This reference table contains a single record for each Vocabulary and includes a descriptive name and other associated attributes for the Vocabulary.

User Guide

@@ -10810,7 +10847,7 @@

vocabulary<

-

domain

+

DOMAIN

Table Description

The DOMAIN table includes a list of OMOP-defined Domains to which the Concepts of the Standardized Vocabularies can belong. A Domain represents a clinical definition whereby we assign matching Concepts for the standardized fields in the CDM tables. For example, the Condition Domain contains Concepts that describe a patient condition, and these Concepts can only be used in the condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA tables. This reference table is populated with a single record for each Domain, including a Domain ID and a descriptive name for every Domain.

User Guide

@@ -10931,7 +10968,7 @@

domain

-

concept_class

+

CONCEPT_CLASS

Table Description

The CONCEPT_CLASS table includes semantic categories that reference the source structure of each Vocabulary. Concept Classes represent so-called horizontal (e.g. MedDRA, RxNorm) or vertical levels (e.g. SNOMED) of the vocabulary structure. Vocabularies without any Concept Classes, such as HCPCS, use the vocabulary_id as the Concept Class. This reference table is populated with a single record for each Concept Class, which includes a Concept Class ID and a fully specified Concept Class name.

User Guide

@@ -11052,7 +11089,7 @@

concept_

-

concept_relationship

+

CONCEPT_RELATIONSHIP

Table Description

The CONCEPT_RELATIONSHIP table contains records that define relationships between any two Concepts and the nature or type of the relationship. This table captures various types of relationships, including hierarchical, associative, and other semantic connections, enabling comprehensive analysis and interpretation of clinical concepts. Every kind of relationship is defined in the RELATIONSHIP table.

User Guide

@@ -11251,7 +11288,7 @@

c

-

relationship

+

RELATIONSHIP

Table Description

The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two concepts in the CONCEPT_RELATIONSHP table.

@@ -11447,7 +11484,7 @@

relations

-

concept_synonym

+

CONCEPT_SYNONYM

Table Description

The CONCEPT_SYNONYM table is used to store alternate names and descriptions for Concepts.

@@ -11564,7 +11601,7 @@

concep

-

concept_ancestor

+

CONCEPT_ANCESTOR

Table Description

The CONCEPT_ANCESTOR table is designed to simplify observational analysis by providing the complete hierarchical relationships between Concepts. Only direct parent-child relationships between Concepts are stored in the CONCEPT_RELATIONSHIP table. To determine higher level ancestry connections, all individual direct relationships would have to be navigated at analysis time. The CONCEPT_ANCESTOR table includes records for all parent-child relationships, as well as grandparent-grandchild relationships and those of any other level of lineage. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept. For example, drug ingredients and drug products are all descendants of a drug class ancestor.

This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP and RELATIONSHIP tables.

@@ -11711,7 +11748,7 @@

conce

-

source_to_concept_map

+

SOURCE_TO_CONCEPT_MAP

Table Description

The source to concept map table is a legacy data structure within the OMOP Common Data Model, recommended for use in ETL processes to maintain local source codes which are not available as Concepts in the Standardized Vocabularies, and to establish mappings for each source code into a Standard Concept as target_concept_ids that can be used to populate the Common Data Model tables. The SOURCE_TO_CONCEPT_MAP table is no longer populated with content within the Standardized Vocabularies published to the OMOP community.

@@ -11989,7 +12026,7 @@

-

drug_strength

+

DRUG_STRENGTH

Table Description

The DRUG_STRENGTH table contains structured content about the amount or concentration and associated units of a specific ingredient contained within a particular drug product. This table is supplemental information to support standardized analysis of drug utilization.

@@ -12347,7 +12384,7 @@

drug_str

-

cohort_definition

+

COHORT_DEFINITION

Table Description

The COHORT_DEFINITION table contains records defining a Cohort derived from the data through the associated description and syntax and upon instantiation (execution of the algorithm) placed into the COHORT table. Cohorts are a set of subjects that satisfy a given combination of inclusion criteria for a duration of time. The COHORT_DEFINITION table provides a standardized structure for maintaining the rules governing the inclusion of a subject into a cohort, and can store operational programming code to instantiate the cohort within the OMOP Common Data Model.

@@ -12571,7 +12608,7 @@

coho

-

attribute_definition

+

ATTRIBUTE_DEFINITION

Table Description

The ATTRIBUTE_DEFINITION table contains records to define each attribute through an associated description and syntax. Attributes are derived elements that can be selected or calculated for a subject within a cohort. The ATTRIBUTE_DEFINITION table provides a standardized structure for maintaining the rules governing the calculation of covariates for a subject in a cohort, and can store operational programming code to instantiate the attributes for a given cohort within the OMOP Common Data Model.

@@ -12737,6 +12774,7 @@

a

+
@@ -12804,13 +12842,14 @@

a e.clearSelection(); } const getTextToCopy = function(trigger) { - const codeEl = trigger.previousElementSibling.cloneNode(true); - for (const childEl of codeEl.children) { - if (isCodeAnnotation(childEl)) { - childEl.remove(); - } + const outerScaffold = trigger.parentElement.cloneNode(true); + const codeEl = outerScaffold.querySelector('code'); + for (const childEl of codeEl.children) { + if (isCodeAnnotation(childEl)) { + childEl.remove(); } - return codeEl.innerText; + } + return codeEl.innerText; } const clipboard = new window.ClipboardJS('.code-copy-button:not([data-in-quarto-modal])', { text: getTextToCopy diff --git a/docs/cdm531.html b/docs/cdm531.html index 09cc1055..453791b5 100644 --- a/docs/cdm531.html +++ b/docs/cdm531.html @@ -2,7 +2,7 @@ - + @@ -241,6 +241,7 @@ toggleColorMode(toAlternate); setStyleSentinel(toAlternate); toggleGiscusIfUsed(toAlternate, darkModeDefault); + window.dispatchEvent(new Event('resize')); }; // Switch to dark mode if need be if (hasAlternateSentinel()) { @@ -256,7 +257,8 @@
OMOP Common Data Model @@ -553,13 +555,14 @@

OMOP CDM v5.3.1

e.clearSelection(); } const getTextToCopy = function(trigger) { - const codeEl = trigger.previousElementSibling.cloneNode(true); - for (const childEl of codeEl.children) { - if (isCodeAnnotation(childEl)) { - childEl.remove(); - } + const outerScaffold = trigger.parentElement.cloneNode(true); + const codeEl = outerScaffold.querySelector('code'); + for (const childEl of codeEl.children) { + if (isCodeAnnotation(childEl)) { + childEl.remove(); } - return codeEl.innerText; + } + return codeEl.innerText; } const clipboard = new window.ClipboardJS('.code-copy-button:not([data-in-quarto-modal])', { text: getTextToCopy diff --git a/docs/cdm54.html b/docs/cdm54.html index c55c5ef1..6b774eab 100644 --- a/docs/cdm54.html +++ b/docs/cdm54.html @@ -241,6 +241,7 @@ toggleColorMode(toAlternate); setStyleSentinel(toAlternate); toggleGiscusIfUsed(toAlternate, darkModeDefault); + window.dispatchEvent(new Event('resize')); }; // Switch to dark mode if need be if (hasAlternateSentinel()) { @@ -256,7 +257,8 @@
OMOP Common Data Model @@ -459,46 +461,62 @@

On this page

 @@ -596,8 +614,11 @@

Current Suppo

* The Feature Extraction package supports all relevant new features in CDM v5.4. For example, it was decided that, from a methodological perspective, the EPISODE and EPISODE_EVENT tables should not be included to define cohort covariates because the events that make up episodes are already pulled in as potential covariates.

Looking to send us a pull request for a bug fix? Please see the readme on the main github page.

+ +
+

Clinical Data Tables

-

person

+

PERSON

Table Description

This table serves as the central identity management for all Persons in the database. It contains records that uniquely identify each person or patient, and some demographic information.

User Guide

@@ -1135,7 +1156,7 @@

person

-

observation_period

+

OBSERVATION_PERIOD

Table Description

This table contains records which define spans of time during which two conditions are expected to hold: (i) Clinical Events that happened to the Person are recorded in the Event tables, and (ii) absence of records indicate such Events did not occur during this span of time.

User Guide

@@ -1316,7 +1337,7 @@

obs

-

visit_occurrence

+

VISIT_OCCURRENCE

Table Description

This table contains Events where Persons engage with the healthcare system for a duration of time. They are often also called “Encounters”. Visits are defined by a configuration of circumstances under which they occur, such as (i) whether the patient comes to a healthcare institution, the other way around, or the interaction is remote, (ii) whether and what kind of trained medical staff is delivering the service during the Visit, and (iii) whether the Visit is transient or for a longer period involving a stay in bed.

User Guide

@@ -1845,7 +1866,7 @@

visit -

visit_detail

+

VISIT_DETAIL

Table Description

The VISIT_DETAIL table is an optional table used to represents details of each record in the parent VISIT_OCCURRENCE table. A good example of this would be the movement between units in a hospital during an inpatient stay or claim lines associated with a one insurance claim. For every record in the VISIT_OCCURRENCE table there may be 0 or more records in the VISIT_DETAIL table with a 1:n relationship where n may be 0. The VISIT_DETAIL table is structurally very similar to VISIT_OCCURRENCE table and belongs to the visit domain.

@@ -2412,7 +2433,7 @@

visit_detail

-

condition_occurrence

+

CONDITION_OCCURRENCE

Table Description

This table contains records of Events of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign, or a symptom, which is either observed by a Provider or reported by the patient.

User Guide

@@ -2896,7 +2917,7 @@

c

-

drug_exposure

+

DRUG_EXPOSURE

Table Description

This table captures records about the exposure to a Drug ingested or otherwise introduced into the body. A Drug is a biochemical substance formulated in such a way that when administered to a Person it will exert a certain biochemical effect on the metabolism. Drugs include prescription and over-the-counter medicines, vaccines, and large-molecule biologic therapies. Radiological devices ingested or applied locally do not count as Drugs.

User Guide

@@ -3564,7 +3585,7 @@

drug_exp

-

procedure_occurrence

+

PROCEDURE_OCCURRENCE

Table Description

This table contains records of activities or processes ordered by, or carried out by, a healthcare provider on the patient with a diagnostic or therapeutic purpose.

User Guide

@@ -4056,7 +4077,7 @@

p

-

device_exposure

+

DEVICE_EXPOSURE

Table Description

The Device domain captures information about a person’s exposure to a foreign physical object or instrument which is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action. Devices include implantable objects (e.g. pacemakers, stents, artificial joints), medical equipment and supplies (e.g. bandages, crutches, syringes), other instruments used in medical procedures (e.g. sutures, defibrillators) and material used in clinical care (e.g. adhesives, body material, dental material, surgical material).

User Guide

@@ -4617,7 +4638,7 @@

device

-

measurement

+

MEASUREMENT

Table Description

The MEASUREMENT table contains records of Measurements, i.e. structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person’s sample. The MEASUREMENT table contains both orders and results of such Measurements as laboratory tests, vital signs, quantitative findings from pathology reports, etc. Measurements are stored as attribute value pairs, with the attribute as the Measurement Concept and the value representing the result. The value can be a Concept (stored in VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit (UNIT_CONCEPT_ID). The Procedure for obtaining the sample is housed in the PROCEDURE_OCCURRENCE table, though it is unnecessary to create a PROCEDURE_OCCURRENCE record for each measurement if one does not exist in the source data. Measurements differ from Observations in that they require a standardized test or some other activity to generate a quantitative or qualitative result. If there is no result, it is assumed that the lab test was conducted but the result was not captured.

User Guide

@@ -5294,7 +5315,7 @@

measuremen

-

observation

+

OBSERVATION

Table Description

The OBSERVATION table captures clinical facts about a Person obtained in the context of examination, questioning or a procedure. Any data that cannot be represented by any other domains, such as social and lifestyle facts, medical history, family history, etc. are recorded here.

User Guide

@@ -5914,7 +5935,7 @@

observatio

-

death

+

DEATH

Table Description

The death domain contains the clinical event for how and when a Person dies. A person can have up to one record if the source system contains evidence about the Death, such as: Condition in an administrative claim, status of enrollment into a health plan, or explicit record in EHR data.

ETL Conventions

@@ -6145,7 +6166,7 @@

death

-

note

+

NOTE

Table Description

The NOTE table captures unstructured information that was recorded by a provider about a patient in free text (in ASCII, or preferably in UTF8 format) notes on a given date. The type of note_text is CLOB or varchar(MAX) depending on RDBMS.

ETL Conventions

@@ -6627,7 +6648,7 @@

note

-

note_nlp

+

NOTE_NLP

Table Description

The NOTE_NLP table encodes all output of NLP on clinical notes. Each row represents a single extracted term from a note.

@@ -7033,7 +7054,7 @@

note_nlp

-

specimen

+

SPECIMEN

Table Description

The specimen domain contains the records identifying biological samples from a person.

ETL Conventions

@@ -7470,7 +7491,7 @@

specimen

-

fact_relationship

+

FACT_RELATIONSHIP

Table Description

The FACT_RELATIONSHIP table contains records about the relationships between facts stored as records in any table of the CDM. Relationships can be defined between facts from the same domain, or different domains. Examples of Fact Relationships include: Person relationships (parent-child), care site relationships (hierarchical organizational structure of facilities within a health system), indication relationship (between drug exposures and associated conditions), usage relationships (of devices during the course of an associated procedure), or facts derived from one another (measurements derived from an associated specimen).

ETL Conventions

@@ -7639,8 +7660,11 @@

fact

+
+
+

Health System Data Tables

-

location

+

LOCATION

Table Description

The LOCATION table represents a generic way to capture physical location or address information of Persons and Care Sites.

User Guide

@@ -7995,7 +8019,7 @@

location

-

care_site

+

CARE_SITE

Table Description

The CARE_SITE table contains a list of uniquely identified institutional (physical or organizational) units where healthcare delivery is practiced (offices, wards, hospitals, clinics, etc.).

ETL Conventions

@@ -8196,7 +8220,7 @@

care_site

-

provider

+

PROVIDER

Table Description

The PROVIDER table contains a list of uniquely identified healthcare providers; duplication is not allowed. These are individuals providing hands-on healthcare to patients, such as physicians, nurses, midwives, physical therapists etc.

User Guide

@@ -8590,8 +8614,11 @@

provider

+
+
+

Health Economics Data Tables

-

payer_plan_period

+

PAYER_PLAN_PERIOD

Table Description

The PAYER_PLAN_PERIOD table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Each Person receiving healthcare is typically covered by a health benefit plan, which pays for (fully or partially), or directly provides, the care. These benefit plans are provided by payers, such as health insurances or state or government agencies. In each plan the details of the health benefits are defined for the Person or her family, and the health benefit Plan might change over time typically with increasing utilization (reaching certain cost thresholds such as deductibles), plan availability and purchasing choices of the Person. The unique combinations of Payer organizations, health benefit Plans and time periods in which they are valid for a Person are recorded in this table.

User Guide

@@ -9090,7 +9117,7 @@

paye

-

cost

+

COST

Table Description

The COST table captures records containing the cost of any medical event recorded in one of the OMOP clinical event tables such as DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, VISIT_OCCURRENCE, VISIT_DETAIL, DEVICE_OCCURRENCE, OBSERVATION or MEASUREMENT.

Each record in the cost table account for the amount of money transacted for the clinical event. So, the COST table may be used to represent both receivables (charges) and payments (paid), each transaction type represented by its COST_CONCEPT_ID. The COST_TYPE_CONCEPT_ID field will use concepts in the Standardized Vocabularies to designate the source (provenance) of the cost data. A reference to the health plan information in the PAYER_PLAN_PERIOD table is stored in the record for information used for the adjudication system to determine the persons benefit for the clinical event.

@@ -9725,8 +9752,11 @@

cost

+
+
+

Standardized Derived Elements

-

drug_era

+

DRUG_ERA

Table Description

A Drug Era is defined as a span of time when the Person is assumed to be exposed to a particular active ingredient. A Drug Era is not the same as a Drug Exposure: Exposures are individual records corresponding to the source when Drug was delivered to the Person, while successive periods of Drug Exposures are combined under certain rules to produce continuous Drug Eras. Every record in the DRUG_EXPOSURE table should be part of a drug era based on the dates of exposure.

ETL Conventions

@@ -9951,7 +9981,7 @@

drug_era

-

dose_era

+

DOSE_ERA

Table Description

A Dose Era is defined as a span of time when the Person is assumed to be exposed to a constant dose of a specific active ingredient.

ETL Conventions

@@ -10178,7 +10208,7 @@

dose_era

-

condition_era

+

CONDITION_ERA

Table Description

A Condition Era is defined as a span of time when the Person is assumed to have a given condition. Similar to Drug Eras, Condition Eras are chronological periods of Condition Occurrence and every Condition Occurrence record should be part of a Condition Era. Combining individual Condition Occurrences into a single Condition Era serves two purposes:

    @@ -10381,7 +10411,7 @@

    conditio

-

episode

+

EPISODE

Table Description

The EPISODE table aggregates lower-level clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) into a higher-level abstraction representing clinically and analytically relevant disease phases,outcomes and treatments. The EPISODE_EVENT table connects qualifying clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) to the appropriate EPISODE entry. For example cancers including their development over time, their treatment, and final resolution.

User Guide

@@ -10778,7 +10808,7 @@

episode

-

episode_event

+

EPISODE_EVENT

Table Description

The EPISODE_EVENT table connects qualifying clinical events (such as CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, MEASUREMENT) to the appropriate EPISODE entry. For example, linking the precise location of the metastasis (cancer modifier in MEASUREMENT) to the disease episode.

User Guide

@@ -10905,8 +10935,11 @@

episode_

+
+
+

Metadata Tables

-

metadata

+

METADATA

Table Description

The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.

@@ -11177,7 +11210,7 @@

metadata

-

cdm_source

+

CDM_SOURCE

Table Description

The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.

@@ -11505,8 +11538,11 @@

cdm_source<

+
+
+

Vocabulary Tables

-

concept

+

CONCEPT

Table Description

The Standardized Vocabularies contains records, or Concepts, that uniquely identify each fundamental unit of meaning used to express clinical information in all domain tables of the CDM. Concepts are derived from vocabularies, which represent clinical information across a domain (e.g. conditions, drugs, procedures) through the use of codes and associated descriptions. Some Concepts are designated Standard Concepts, meaning these Concepts can be used as normative expressions of a clinical entity within the OMOP Common Data Model and standardized analytics. Each Standard Concept belongs to one Domain, which defines the location where the Concept would be expected to occur within the data tables of the CDM. Concepts can represent broad categories (‘Cardiovascular disease’), detailed clinical elements (‘Myocardial infarction of the anterolateral wall’), or modifying characteristics and attributes that define Concepts at various levels of detail (severity of a disease, associated morphology, etc.). Records in the Standardized Vocabularies tables are derived from national or international vocabularies such as SNOMED-CT, RxNorm, and LOINC, or custom OMOP Concepts defined to cover various aspects of observational data analysis.

User Guide

@@ -11811,7 +11847,7 @@

concept

-

vocabulary

+

VOCABULARY

Table Description

The VOCABULARY table includes a list of the Vocabularies integrated from various sources or created de novo in OMOP CDM. This reference table contains a single record for each Vocabulary and includes a descriptive name and other associated attributes for the Vocabulary.

User Guide

@@ -11984,7 +12020,7 @@

vocabulary<

-

domain

+

DOMAIN

Table Description

The DOMAIN table includes a list of OMOP-defined Domains to which the Concepts of the Standardized Vocabularies can belong. A Domain represents a clinical definition whereby we assign matching Concepts for the standardized fields in the CDM tables. For example, the Condition Domain contains Concepts that describe a patient condition, and these Concepts can only be used in the condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA tables. This reference table is populated with a single record for each Domain, including a Domain ID and a descriptive name for every Domain.

User Guide

@@ -12105,7 +12141,7 @@

domain

-

concept_class

+

CONCEPT_CLASS

Table Description

The CONCEPT_CLASS table includes semantic categories that reference the source structure of each Vocabulary. Concept Classes represent so-called horizontal (e.g. MedDRA, RxNorm) or vertical levels (e.g. SNOMED) of the vocabulary structure. Vocabularies without any Concept Classes, such as HCPCS, use the vocabulary_id as the Concept Class. This reference table is populated with a single record for each Concept Class, which includes a Concept Class ID and a fully specified Concept Class name.

User Guide

@@ -12226,7 +12262,7 @@

concept_

-

concept_relationship

+

CONCEPT_RELATIONSHIP

Table Description

The CONCEPT_RELATIONSHIP table contains records that define relationships between any two Concepts and the nature or type of the relationship. This table captures various types of relationships, including hierarchical, associative, and other semantic connections, enabling comprehensive analysis and interpretation of clinical concepts. Every kind of relationship is defined in the RELATIONSHIP table.

User Guide

@@ -12425,7 +12461,7 @@

c

-

relationship

+

RELATIONSHIP

Table Description

The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two Concepts in the CONCEPT_RELATIONSHIP table, the respective reverse relationships, and their hierarchical characteristics. Note, that Concepts representing relationships between the clinical facts, used for filling in the FACT_RELATIONSHIP table are stored in the CONCEPT table and belong to the Relationship Domain.

User Guide

@@ -12623,7 +12659,7 @@

relations

-

concept_synonym

+

CONCEPT_SYNONYM

Table Description

The CONCEPT_SYNONYM table captures alternative terms, synonyms, and translations of Concept Name into various languages linked to specific concepts, providing users with a comprehensive view of how Concepts may be expressed or referenced.

User Guide

@@ -12742,7 +12778,7 @@

concep

-

concept_ancestor

+

CONCEPT_ANCESTOR

Table Description

The CONCEPT_ANCESTOR table is designed to simplify observational analysis by providing the complete hierarchical relationships between Concepts. Only direct parent-child relationships between Concepts are stored in the CONCEPT_RELATIONSHIP table. To determine higher-level ancestry connections, all individual direct relationships would have to be navigated at analysis time. The CONCEPT_ANCESTOR table includes records for all parent-child relationships, as well as grandparent-grandchild relationships and those of any other level of lineage for Standard or Classification concepts. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept, and the other way around. For example, drug ingredients and drug products, beneath them in the hierarchy, are all descendants of a drug class ancestor. This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP, and RELATIONSHIP tables.

User Guide

@@ -12890,7 +12926,7 @@

conce

-

source_to_concept_map

+

SOURCE_TO_CONCEPT_MAP

Table Description

The source to concept map table is recommended for use in ETL processes to maintain local source codes which are not available as Concepts in the Standardized Vocabularies, and to establish mappings for each source code into a Standard Concept as target_concept_ids that can be used to populate the Common Data Model tables. The SOURCE_TO_CONCEPT_MAP table is no longer populated with content within the Standardized Vocabularies published to the OMOP community. There are OHDSI tools to help you populate this table; Usagi and Perseus. You can read more about OMOP vocabulary mapping in The Book of OHDSI Chapter 6.3.

@@ -13168,7 +13204,7 @@

-

drug_strength

+

DRUG_STRENGTH

Table Description

The DRUG_STRENGTH table contains structured content about the amount or concentration and associated units of a specific ingredient contained within a particular drug product. This table is supplemental information to support standardized analysis of drug utilization.

@@ -13526,7 +13562,7 @@

drug_str

-

cohort

+

COHORT

Table Description

The subject of a cohort can have multiple, discrete records in the cohort table per cohort_definition_id, subject_id, and non-overlapping time periods. The definition of the cohort is contained within the COHORT_DEFINITION table. It is listed as part of the RESULTS schema because it is a table that users of the database as well as tools such as ATLAS need to be able to write to. The CDM and Vocabulary tables are all read-only so it is suggested that the COHORT and COHORT_DEFINTION tables are kept in a separate schema to alleviate confusion.

ETL Conventions

@@ -13668,7 +13704,7 @@

cohort

-

cohort_definition

+

COHORT_DEFINITION

Table Description

The COHORT_DEFINITION table contains records defining a Cohort derived from the data through the associated description and syntax and upon instantiation (execution of the algorithm) placed into the COHORT table. Cohorts are a set of subjects that satisfy a given combination of inclusion criteria for a duration of time. The COHORT_DEFINITION table provides a standardized structure for maintaining the rules governing the inclusion of a subject into a cohort, and can store operational programming code to instantiate the cohort within the OMOP Common Data Model.

@@ -13960,13 +13996,14 @@

coho e.clearSelection(); } const getTextToCopy = function(trigger) { - const codeEl = trigger.previousElementSibling.cloneNode(true); - for (const childEl of codeEl.children) { - if (isCodeAnnotation(childEl)) { - childEl.remove(); - } + const outerScaffold = trigger.parentElement.cloneNode(true); + const codeEl = outerScaffold.querySelector('code'); + for (const childEl of codeEl.children) { + if (isCodeAnnotation(childEl)) { + childEl.remove(); } - return codeEl.innerText; + } + return codeEl.innerText; } const clipboard = new window.ClipboardJS('.code-copy-button:not([data-in-quarto-modal])', { text: getTextToCopy diff --git a/docs/cdm55.html b/docs/cdm55.html index da36980f..4ae523d9 100644 --- a/docs/cdm55.html +++ b/docs/cdm55.html @@ -2,7 +2,7 @@ - + @@ -241,6 +241,7 @@ toggleColorMode(toAlternate); setStyleSentinel(toAlternate); toggleGiscusIfUsed(toAlternate, darkModeDefault); + window.dispatchEvent(new Event('resize')); }; // Switch to dark mode if need be if (hasAlternateSentinel()) { @@ -256,7 +257,8 @@
OMOP Common Data Model @@ -459,49 +461,65 @@

On this page

 @@ -598,8 +616,11 @@

Current Suppo

Looking to send us a pull request for a bug fix? Please see the readme on the main github page.

+
+
+

Clinical Data Tables

-

person

+

PERSON

Table Description

This table serves as the central identity management for all Persons in the database. It contains records that uniquely identify each person or patient, and some demographic information.

User Guide

@@ -1137,7 +1158,7 @@

person

-

observation_period

+

OBSERVATION_PERIOD

Table Description

This table contains records which define spans of time during which two conditions are expected to hold: (i) Clinical Events that happened to the Person are recorded in the Event tables, and (ii) absence of records indicate such Events did not occur during this span of time.

User Guide

@@ -1318,7 +1339,7 @@

obs

-

visit_occurrence

+

VISIT_OCCURRENCE

Table Description

This table contains Events where Persons engage with the healthcare system for a duration of time. They are often also called “Encounters”. Visits are defined by a configuration of circumstances under which they occur, such as (i) whether the patient comes to a healthcare institution, the other way around, or the interaction is remote, (ii) whether and what kind of trained medical staff is delivering the service during the Visit, and (iii) whether the Visit is transient or for a longer period involving a stay in bed.

User Guide

@@ -1847,7 +1868,7 @@

visit -

visit_detail

+

VISIT_DETAIL

Table Description

The VISIT_DETAIL table is an optional table used to represents details of each record in the parent VISIT_OCCURRENCE table. A good example of this would be the movement between units in a hospital during an inpatient stay or claim lines associated with a one insurance claim. For every record in the VISIT_OCCURRENCE table there may be 0 or more records in the VISIT_DETAIL table with a 1:n relationship where n may be 0. The VISIT_DETAIL table is structurally very similar to VISIT_OCCURRENCE table and belongs to the visit domain.

@@ -2414,7 +2435,7 @@

visit_detail

-

condition_occurrence

+

CONDITION_OCCURRENCE

Table Description

This table contains records of Events of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign, or a symptom, which is either observed by a Provider or reported by the patient.

User Guide

@@ -2898,7 +2919,7 @@

c

-

drug_exposure

+

DRUG_EXPOSURE

Table Description

This table captures records about the exposure to a Drug ingested or otherwise introduced into the body. A Drug is a biochemical substance formulated in such a way that when administered to a Person it will exert a certain biochemical effect on the metabolism. Drugs include prescription and over-the-counter medicines, vaccines, and large-molecule biologic therapies. Radiological devices ingested or applied locally do not count as Drugs.

User Guide

@@ -3566,7 +3587,7 @@

drug_exp

-

procedure_occurrence

+

PROCEDURE_OCCURRENCE

Table Description

This table contains records of activities or processes ordered by, or carried out by, a healthcare provider on the patient with a diagnostic or therapeutic purpose.

User Guide

@@ -4058,7 +4079,7 @@

p

-

device_exposure

+

DEVICE_EXPOSURE

Table Description

The Device domain captures information about a person’s exposure to a foreign physical object or instrument which is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action. Devices include implantable objects (e.g. pacemakers, stents, artificial joints), medical equipment and supplies (e.g. bandages, crutches, syringes), other instruments used in medical procedures (e.g. sutures, defibrillators) and material used in clinical care (e.g. adhesives, body material, dental material, surgical material).

User Guide

@@ -4619,7 +4640,7 @@

device

-

measurement

+

MEASUREMENT

Table Description

The MEASUREMENT table contains records of Measurements, i.e. structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person’s sample. The MEASUREMENT table contains both orders and results of such Measurements as laboratory tests, vital signs, quantitative findings from pathology reports, etc. Measurements are stored as attribute value pairs, with the attribute as the Measurement Concept and the value representing the result. The value can be a Concept (stored in VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit (UNIT_CONCEPT_ID). The Procedure for obtaining the sample is housed in the PROCEDURE_OCCURRENCE table, though it is unnecessary to create a PROCEDURE_OCCURRENCE record for each measurement if one does not exist in the source data. Measurements differ from Observations in that they require a standardized test or some other activity to generate a quantitative or qualitative result. If there is no result, it is assumed that the lab test was conducted but the result was not captured.

User Guide

@@ -5324,7 +5345,7 @@

measuremen

-

observation

+

OBSERVATION

Table Description

The OBSERVATION table captures clinical facts about a Person obtained in the context of examination, questioning or a procedure. Any data that cannot be represented by any other domains, such as social and lifestyle facts, medical history, family history, etc. are recorded here.

User Guide

@@ -6026,7 +6047,7 @@

observatio

-

death

+

DEATH

Table Description

The death domain contains the clinical event for how and when a Person dies. A person can have up to one record if the source system contains evidence about the Death, such as: Condition in an administrative claim, status of enrollment into a health plan, or explicit record in EHR data.

ETL Conventions

@@ -6257,7 +6278,7 @@

death

-

note

+

NOTE

Table Description

The NOTE table captures unstructured information that was recorded by a provider about a patient in free text (in ASCII, or preferably in UTF8 format) notes on a given date. The type of note_text is CLOB or varchar(MAX) depending on RDBMS.

ETL Conventions

@@ -6739,7 +6760,7 @@

note

-

note_nlp

+

NOTE_NLP

Table Description

The NOTE_NLP table encodes all output of NLP on clinical notes. Each row represents a single extracted term from a note.

@@ -7145,7 +7166,7 @@

note_nlp

-

specimen

+

SPECIMEN

Table Description

The specimen domain contains the records identifying biological samples from a person.

ETL Conventions

@@ -7638,7 +7659,7 @@

specimen

-

fact_relationship

+

FACT_RELATIONSHIP

Table Description

The FACT_RELATIONSHIP table contains records about the relationships between facts stored as records in any table of the CDM. Relationships can be defined between facts from the same domain, or different domains. Examples of Fact Relationships include: Person relationships (parent-child), care site relationships (hierarchical organizational structure of facilities within a health system), indication relationship (between drug exposures and associated conditions), usage relationships (of devices during the course of an associated procedure), or facts derived from one another (measurements derived from an associated specimen).

ETL Conventions

@@ -7807,8 +7828,11 @@

fact

+
+
+

Health System Data Tables

-

location

+

LOCATION

Table Description

The LOCATION table represents a generic way to capture physical location or address information of Persons and Care Sites.

User Guide

@@ -8163,7 +8187,7 @@

location

-

care_site

+

CARE_SITE

Table Description

The CARE_SITE table contains a list of uniquely identified institutional (physical or organizational) units where healthcare delivery is practiced (offices, wards, hospitals, clinics, etc.).

ETL Conventions

@@ -8364,7 +8388,7 @@

care_site

-

provider

+

PROVIDER

Table Description

The PROVIDER table contains a list of uniquely identified healthcare providers; duplication is not allowed. These are individuals providing hands-on healthcare to patients, such as physicians, nurses, midwives, physical therapists etc.

User Guide

@@ -8758,8 +8782,11 @@

provider

+
+
+

Health Economics Data Tables

-

payer_plan_period

+

PAYER_PLAN_PERIOD

Table Description

The PAYER_PLAN_PERIOD table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Each Person receiving healthcare is typically covered by a health benefit plan, which pays for (fully or partially), or directly provides, the care. These benefit plans are provided by payers, such as health insurances or state or government agencies. In each plan the details of the health benefits are defined for the Person or her family, and the health benefit Plan might change over time typically with increasing utilization (reaching certain cost thresholds such as deductibles), plan availability and purchasing choices of the Person. The unique combinations of Payer organizations, health benefit Plans and time periods in which they are valid for a Person are recorded in this table.

User Guide

@@ -9258,7 +9285,7 @@

paye

-

cost

+

COST

Table Description

The COST table captures records containing the cost of any medical event recorded in one of the OMOP clinical event tables such as DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, VISIT_OCCURRENCE, VISIT_DETAIL, DEVICE_OCCURRENCE, OBSERVATION or MEASUREMENT.

Each record in the cost table account for the amount of money transacted for the clinical event. So, the COST table may be used to represent both receivables (charges) and payments (paid), each transaction type represented by its COST_CONCEPT_ID. The COST_TYPE_CONCEPT_ID field will use concepts in the Standardized Vocabularies to designate the source (provenance) of the cost data. A reference to the health plan information in the PAYER_PLAN_PERIOD table is stored in the record for information used for the adjudication system to determine the persons benefit for the clinical event.

@@ -9893,8 +9920,11 @@

cost

+
+
+

Standardized Derived Elements

-

drug_era

+

DRUG_ERA

Table Description

A Drug Era is defined as a span of time when the Person is assumed to be exposed to a particular active ingredient. A Drug Era is not the same as a Drug Exposure: Exposures are individual records corresponding to the source when Drug was delivered to the Person, while successive periods of Drug Exposures are combined under certain rules to produce continuous Drug Eras. Every record in the DRUG_EXPOSURE table should be part of a drug era based on the dates of exposure.

ETL Conventions

@@ -10119,7 +10149,7 @@

drug_era

-

dose_era

+

DOSE_ERA

Table Description

A Dose Era is defined as a span of time when the Person is assumed to be exposed to a constant dose of a specific active ingredient.

ETL Conventions

@@ -10346,7 +10376,7 @@

dose_era

-

condition_era

+

CONDITION_ERA

Table Description

A Condition Era is defined as a span of time when the Person is assumed to have a given condition. Similar to Drug Eras, Condition Eras are chronological periods of Condition Occurrence and every Condition Occurrence record should be part of a Condition Era. Combining individual Condition Occurrences into a single Condition Era serves two purposes:

    @@ -10549,7 +10579,7 @@

    conditio

-

episode

+

EPISODE

Table Description

The EPISODE table aggregates lower-level clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) into a higher-level abstraction representing clinically and analytically relevant disease phases,outcomes and treatments. The EPISODE_EVENT table connects qualifying clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) to the appropriate EPISODE entry. For example cancers including their development over time, their treatment, and final resolution.

User Guide

@@ -10946,7 +10976,7 @@

episode

-

episode_event

+

EPISODE_EVENT

Table Description

The EPISODE_EVENT table connects qualifying clinical events (such as CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, MEASUREMENT) to the appropriate EPISODE entry. For example, linking the precise location of the metastasis (cancer modifier in MEASUREMENT) to the disease episode.

User Guide

@@ -11073,8 +11103,11 @@

episode_

+
+
+

Metadata Tables

-

metadata

+

METADATA

Table Description

The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.

@@ -11345,7 +11378,7 @@

metadata

-

cdm_source

+

CDM_SOURCE

Table Description

The CDM_SOURCE table contains details about your CDM instance. Most OHDSI tooling expects one record in this table to get the name of your cdm, release date, and vocabulary version. Multiple records are allowed in the cdm_source table, but tooling will typically only read the first record.

@@ -11699,8 +11732,11 @@

cdm_source<

+
+
+

Vocabulary Tables

-

concept

+

CONCEPT

Table Description

The Standardized Vocabularies contains records, or Concepts, that uniquely identify each fundamental unit of meaning used to express clinical information in all domain tables of the CDM. Concepts are derived from vocabularies, which represent clinical information across a domain (e.g. conditions, drugs, procedures) through the use of codes and associated descriptions. Some Concepts are designated Standard Concepts, meaning these Concepts can be used as normative expressions of a clinical entity within the OMOP Common Data Model and standardized analytics. Each Standard Concept belongs to one Domain, which defines the location where the Concept would be expected to occur within the data tables of the CDM. Concepts can represent broad categories (‘Cardiovascular disease’), detailed clinical elements (‘Myocardial infarction of the anterolateral wall’), or modifying characteristics and attributes that define Concepts at various levels of detail (severity of a disease, associated morphology, etc.). Records in the Standardized Vocabularies tables are derived from national or international vocabularies such as SNOMED-CT, RxNorm, and LOINC, or custom OMOP Concepts defined to cover various aspects of observational data analysis.

User Guide

@@ -12005,7 +12041,7 @@

concept

-

vocabulary

+

VOCABULARY

Table Description

The VOCABULARY table includes a list of the Vocabularies integrated from various sources or created de novo in OMOP CDM. This reference table contains a single record for each Vocabulary and includes a descriptive name and other associated attributes for the Vocabulary.

User Guide

@@ -12178,7 +12214,7 @@

vocabulary<

-

domain

+

DOMAIN

Table Description

The DOMAIN table includes a list of OMOP-defined Domains to which the Concepts of the Standardized Vocabularies can belong. A Domain represents a clinical definition whereby we assign matching Concepts for the standardized fields in the CDM tables. For example, the Condition Domain contains Concepts that describe a patient condition, and these Concepts can only be used in the condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA tables. This reference table is populated with a single record for each Domain, including a Domain ID and a descriptive name for every Domain.

User Guide

@@ -12299,7 +12335,7 @@

domain

-

concept_class

+

CONCEPT_CLASS

Table Description

The CONCEPT_CLASS table includes semantic categories that reference the source structure of each Vocabulary. Concept Classes represent so-called horizontal (e.g. MedDRA, RxNorm) or vertical levels (e.g. SNOMED) of the vocabulary structure. Vocabularies without any Concept Classes, such as HCPCS, use the vocabulary_id as the Concept Class. This reference table is populated with a single record for each Concept Class, which includes a Concept Class ID and a fully specified Concept Class name.

User Guide

@@ -12420,7 +12456,7 @@

concept_

-

concept_relationship

+

CONCEPT_RELATIONSHIP

Table Description

The CONCEPT_RELATIONSHIP table contains records that define relationships between any two Concepts and the nature or type of the relationship. This table captures various types of relationships, including hierarchical, associative, and other semantic connections, enabling comprehensive analysis and interpretation of clinical concepts. Every kind of relationship is defined in the RELATIONSHIP table.

User Guide

@@ -12619,7 +12655,7 @@

c

-

relationship

+

RELATIONSHIP

Table Description

The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two Concepts in the CONCEPT_RELATIONSHIP table, the respective reverse relationships, and their hierarchical characteristics. Note, that Concepts representing relationships between the clinical facts, used for filling in the FACT_RELATIONSHIP table are stored in the CONCEPT table and belong to the Relationship Domain.

User Guide

@@ -12817,7 +12853,7 @@

relations

-

concept_synonym

+

CONCEPT_SYNONYM

Table Description

The CONCEPT_SYNONYM table captures alternative terms, synonyms, and translations of Concept Name into various languages linked to specific concepts, providing users with a comprehensive view of how Concepts may be expressed or referenced.

User Guide

@@ -12936,7 +12972,7 @@

concep

-

concept_ancestor

+

CONCEPT_ANCESTOR

Table Description

The CONCEPT_ANCESTOR table is designed to simplify observational analysis by providing the complete hierarchical relationships between Concepts. Only direct parent-child relationships between Concepts are stored in the CONCEPT_RELATIONSHIP table. To determine higher-level ancestry connections, all individual direct relationships would have to be navigated at analysis time. The CONCEPT_ANCESTOR table includes records for all parent-child relationships, as well as grandparent-grandchild relationships and those of any other level of lineage for Standard or Classification concepts. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept, and the other way around. For example, drug ingredients and drug products, beneath them in the hierarchy, are all descendants of a drug class ancestor. This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP, and RELATIONSHIP tables.

User Guide

@@ -13084,7 +13120,7 @@

conce

-

source_to_concept_map

+

SOURCE_TO_CONCEPT_MAP

Table Description

The source to concept map table is recommended for use in ETL processes to maintain local source codes which are not available as Concepts in the Standardized Vocabularies, and to establish mappings for each source code into a Standard Concept as target_concept_ids that can be used to populate the Common Data Model tables. The SOURCE_TO_CONCEPT_MAP table is no longer populated with content within the Standardized Vocabularies published to the OMOP community. There are OHDSI tools to help you populate this table; Usagi and Perseus. You can read more about OMOP vocabulary mapping in The Book of OHDSI Chapter 6.3.

@@ -13362,7 +13398,7 @@

-

drug_strength

+

DRUG_STRENGTH

Table Description

The DRUG_STRENGTH table contains structured content about the amount or concentration and associated units of a specific ingredient contained within a particular drug product. This table is supplemental information to support standardized analysis of drug utilization.

@@ -13720,7 +13756,7 @@

drug_str

-

pack_content

+

PACK_CONTENT

Table Description

The PACK_CONTENT table contains structured content of drug Packs. Packs are fixed combination of Drugs (Clinical Drugs, Branded Drug, Quant Clin Drug, Quant Branded Drug, Marketed Product without box size information). For example, contraceptives contain a certain amount of progesteron drug and estrogen preparations, sufficient for a month. This table is supplemental information to support standardized analysis of drug utilization.

ETL Conventions

@@ -13868,7 +13904,7 @@

pack_cont

-

concept_metadata

+

CONCEPT_METADATA

Table Description

The concept_metadata table stores metadata for each concept from the concept table.

User Guide

@@ -13998,7 +14034,7 @@

conce

-

concept_relationship_metadata

+

CONCEPT_RELATIONSHIP_METADATA

Table Description

The concept_relationship_metadata table stores metadata for each relationship between concepts from the concept_relationship table.

User Guide

@@ -14309,7 +14345,7 @@

-

cohort

+

COHORT

Table Description

The subject of a cohort can have multiple, discrete records in the cohort table per cohort_definition_id, subject_id, and non-overlapping time periods. The definition of the cohort is contained within the COHORT_DEFINITION table. It is listed as part of the RESULTS schema because it is a table that users of the database as well as tools such as ATLAS need to be able to write to. The CDM and Vocabulary tables are all read-only so it is suggested that the COHORT and COHORT_DEFINTION tables are kept in a separate schema to alleviate confusion.

ETL Conventions

@@ -14451,7 +14487,7 @@

cohort

-

cohort_definition

+

COHORT_DEFINITION

Table Description

The COHORT_DEFINITION table contains records defining a Cohort derived from the data through the associated description and syntax and upon instantiation (execution of the algorithm) placed into the COHORT table. Cohorts are a set of subjects that satisfy a given combination of inclusion criteria for a duration of time. The COHORT_DEFINITION table provides a standardized structure for maintaining the rules governing the inclusion of a subject into a cohort, and can store operational programming code to instantiate the cohort within the OMOP Common Data Model.

@@ -14743,13 +14779,14 @@

coho e.clearSelection(); } const getTextToCopy = function(trigger) { - const codeEl = trigger.previousElementSibling.cloneNode(true); - for (const childEl of codeEl.children) { - if (isCodeAnnotation(childEl)) { - childEl.remove(); - } + const outerScaffold = trigger.parentElement.cloneNode(true); + const codeEl = outerScaffold.querySelector('code'); + for (const childEl of codeEl.children) { + if (isCodeAnnotation(childEl)) { + childEl.remove(); } - return codeEl.innerText; + } + return codeEl.innerText; } const clipboard = new window.ClipboardJS('.code-copy-button:not([data-in-quarto-modal])', { text: getTextToCopy