MDW - Discover Metadata Catalogue

MDW Discover  > Cheshire and Merseyside ICB Local Primary Care Data (OMOP) @ 1248

MDW Discover

Browse All

London SDE

West Midlands SDE

Kent, Medway & Sussex SDE

MDW - Discover

This OMOP CDM is built from a flow of primary care data from Cheshire and Merseyside GPs who have signed the ICB Data Sharing Agreement for Population Health. Patients who have signalled that they wish to opt out of their records being shared for secondary uses (i.e. uses beyond Direct Patient Care) are removed as per national data opt-out policy.  The source data is refreshed weekly (Sunday evenings) and the data set includes a long list of fields relating to: NHS number, allergies, medications issued, Repeat medications, Covid-19 status, Active and Past Problems, GP Results, Vitals & Measurements (height/weight, BP, physiological function result), Lifestyle factors (smoking and alcohol), GP encounters, vaccinations and immunisations, Contraindications, OTC and Prophylactic Therapy, Family History, Child Health, Diabetes Diagnosis, Chronic Disease Monitoring.

HDR UK

A unique identifier for each Concept across all domains.

concept_id

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.

Concept

An unambiguous, meaningful and descriptive name for the Concept.

concept_name

A foreign key to the DOMAIN table the Concept belongs to.

domain_id

A foreign key to the VOCABULARY table indicating from which source the Concept has been adapted.

vocabulary_id

The attribute or concept class of the Concept. Examples are ‘Clinical Drug’, ‘Ingredient’, ‘Clinical Finding’ etc.

concept_class_id

This flag determines where a Concept is a Standard Concept, i.e. is used in the data, a Classification Concept, or a non-standard Source Concept. The allowable values are ‘S’ (Standard Concept) and ‘C’ (Classification Concept), otherwise the content is NULL.

standard_concept

The concept code represents the identifier of the Concept in the source vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that concept codes are not unique across vocabularies.

concept_code

The date when the Concept was first recorded. The default value is 1-Jan-1970, meaning, the Concept has no (known) date of inception.

valid_start_date

The date when the Concept became invalid because it was deleted or superseded (updated) by a new concept. The default value is 31-Dec-2099, meaning, the Concept is valid until it becomes deprecated.

valid_end_date

Reason the Concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value

invalid_reason

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.

Concept_class

The name describing the Concept Class, e.g. Clinical Finding, Ingredient, etc.

concept_class_name

A Concept that represents the Concept Class

concept_class_concept_id

A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit.

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.

Vocabulary

The name describing the vocabulary, for example, International Classification of Diseases, Ninth Revision, Clinical Modification, Volume 1 and 2 (NCHS) etc.

vocabulary_name

External reference to documentation or available download of the about the vocabulary.

vocabulary_reference

Version of the Vocabulary as indicated in the source.

vocabulary_version

A Concept that represents the Vocabulary the VOCABULARY record belongs to

vocabulary_concept_id

The source code being translated into a Standard Concept.

source_code

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.

Source_to_concept_map

A foreign key to the Source Concept that is being translated into a Standard Concept.

source_concept_id

A foreign key to the VOCABULARY table defining the vocabulary of the source code that is being translated to a Standard Concept.

source_vocabulary_id

An optional description for the source code. This is included as a convenience to compare the description of the source code to the name of the concept.

source_code_description

The target Concept to which the source code is being mapped.

target_concept_id

target_vocabulary_id

The date when the mapping instance was first recorded.

The date when the mapping instance became invalid because it was deleted or superseded (updated) by a new relationship. Default value is 31-Dec-2099.

Reason the mapping instance was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value

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.

Domain

The name describing the Domain, e.g. Condition, Procedure, Measurement etc.

domain_name

A Concept representing the Domain Concept the DOMAIN record belongs to

domain_concept_id

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.

Concept_synonym

concept_synonym_name

language_concept_id

ancestor_concept_id

descendant_concept_id

min_levels_of_separation

max_levels_of_separation

concept_id_1

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.

Concept_relationship

concept_id_2

The relationship between CONCEPT_ID_1 and CONCEPT_ID_2.

relationship_id

The date when the relationship is first recorded.

The date when the relationship is invalidated.

The type of relationship captured by the relationship record.

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.

Relationship

relationship_name

Defines whether a relationship defines concepts into classes or hierarchies. Values are 1 for hierarchical relationship or 0 if not.

is_hierarchical

Defines whether a hierarchical relationship contributes to the concept_ancestor table. These are subsets of the hierarchical relationships. Valid values are 1 or 0.

defines_ancestry

The identifier for the relationship used to define the reverse relationship between two concepts.

reverse_relationship_id

A foreign key that refers to an identifier in the CONCEPT table for the unique relationship concept.

relationship_concept_id

The Concept representing the Branded Drug or Clinical Drug Product.

drug_concept_id

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.

Drug_strength

The Concept representing the active ingredient contained within the drug product.

ingredient_concept_id

The numeric value or the amount of active ingredient contained within the drug product.

amount_value

The Concept representing the Unit of measure for the amount of active ingredient contained within the drug product.

amount_unit_concept_id

The concentration of the active ingredient contained within the drug product.

numerator_value

The Concept representing the Unit of measure for the concentration of active ingredient.

numerator_unit_concept_id

The amount of total liquid (or other divisible product, such as ointment, gel, spray, etc.).

denominator_value

The Concept representing the denominator unit for the concentration of active ingredient.

denominator_unit_concept_id

The number of units of Clinical Branded Drug or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient.

box_size

The date when the Concept was first recorded. The default value is 1-Jan-1970.

The date when then Concept became invalid.

Reason the concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value.

Unique id of the institutional (physical or organizational) unit where healthcare delivery is practiced

care_site_id

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.).

Care_site

The name of the care_site as it appears in the source data

care_site_name

This is a high-level way of characterizing a Care Site. Typically, however, Care Sites can provide care in multiple settings (inpatient, outpatient, etc.) and this granularity should be reflected in the visit.

place_of_service_concept_id

The location_id from the LOCATION table representing the physical location of the care_site.

location_id

The identifier of the care_site as it appears in the source data. This could be an identifier separate from the name of the care_site.

care_site_source_value

The verbatim value for the care site here, as it shows up in the source.

place_of_service_source_value

The unique key given to a unique Location.

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

Location

address_1

address_2

city

state

country

The verbatim value for the location here, as it shows up in the source.

location_source_value

The Concept Id representing the country. Values should conform to the Geography domain.

country_concept_id

country_source_value

latitude

longitude

The unique key given to a Metadata record.

metadata-id

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

Metadata

metadata_concept_id

metadata_type_concept_id

name

value_as_string

value_as_concept_id

This is the numerical value of the result of the Metadata, if applicable and available. It is not expected that all Metadata will have numeric results, rather, this field is here to house values should they exist.

value_as_number

metadata_date

metadata_datetime

cdm_source_name

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

Cdm_source

cdm_source_abbreviation

cdm_holder

source_description

Refers to a publication or web resource describing the source data

source_documentation_reference

cdm_etl_reference

The date the data was extracted from the source system. In some systems that is the same as the date the ETL was run. Typically the latest even date in the source is on the source_release_date.

source_release_date

The date the ETL script was completed. Typically this is after the source_release_date.

cdm_release_date

Version of the OMOP CDM used as string. e.g. v5.4

cdm_version

The Concept Id representing the version of the CDM

cdm_version_concept_id

Version of the OMOP standardised vocabularies loaded

It is assumed that every person with a different unique identifier is in fact a different person and should be treated independently.

person_id

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.

Person

This is an OMOP CDM built from a flow of primary care data from Cheshire and Merseyside GPs who have signed the ICB Data Sharing Agreement for Population Health. Patients who have signalled that they wish to opt out of their records being shared for secondary uses (i.e. uses beyond Direct Patient Care) are removed as per national data opt-out policy. The source data is refreshed weekly (Sunday evenings) and the data set includes a long list of fields relating to the patient health record.

Cheshire and Merseyside ICB Local Primary Care Data (OMOP)

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.

Drug_era

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.

Measurement

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.

Observation_period

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.

Dose_era

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.

Condition_occurrence

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.

Episode_event

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

Cheshire and Merseyside ICB Local Primary Care Data (OMOP)

Documentation

Coverage

Provenance

Origin

Temporal

Accessibility

Access

Usage

Format and Standards

Origin