MDW - Discover Metadata Catalogue

MDW Discover  > Eastern England SDE Secondary Care EPR dataset @ 1506

MDW Discover

Browse All

London SDE

West Midlands SDE

Kent, Medway & Sussex SDE

MDW - Discover

This data has been assembled to support health and care research using pseudonymized NHS patient data in the Eastern England Secure Data Environment. The dataset contains inpatient, outpatient and emergency care records from secondary care trusts.  This covers demographic information, diagnoses, events, prescribing information and lab test results for patients from 2015 to today. Currently the dataset contains data from Cambridge University Hospitals foundation trust. Over time, the dataset will be extended to include additional secondary care trusts from across Eastern England.

HDR UK

This research was enabled by secure access to data through the Eastern England Secure Data Environment (SDE) (Project ID: SDE_EE_PROJ_AXXXX.VXX  https://easternsde.nhs.uk/projects ), part of the NHS Research Secure Data Environment Network. This work uses de-identified data provided by patients treated in Eastern England and collected by the NHS as part of their care and support. Data discovery and access was facilitated by the Health Data Research Gateway.

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 field is meant to capture the biological sex at birth of the Person. This field should not be used to study gender identity issues.

gender_concept_id

year_of_birth

month_of_birth

day_of_birth

birth_datetime

This field captures race or ethnic background of the person.

race_concept_id

This field captures Ethnicity as defined by the Office of Management and Budget (OMB) of the US Government: it distinguishes only between &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;Hispanic&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot; and &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;Not Hispanic&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;. Races and ethnic backgrounds are not stored here.

ethnicity_concept_id

The location refers to the physical address of the person. This field should capture the last known location of the person.

location_id

The Provider refers to the last known primary care provider (General Practitioner).

provider_id

The Care Site refers to where the Provider typically provides the primary care.

care_site_id

Use this field to link back to persons in the source data. This is typically used for error checking of ETL logic.

person_source_value

This field is used to store the biological sex of the person from the source data. It is not intended for use in standard analytics but for reference only.

gender_source_value

Due to the small number of options, this tends to be zero.

gender_source_concept_id

This field is used to store the race of the person from the source data. It is not intended for use in standard analytics but for reference only.

race_source_value

race_source_concept_id

This field is used to store the ethnicity of the person from the source data. It is not intended for use in standard analytics but for reference only.

ethnicity_source_value

ethnicity_source_concept_id

A Person can have multiple discrete Observation Periods which are identified by the Observation_Period_Id.

observation_period_id

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

The Person ID of the PERSON record for which the Observation Period is recorded.

Use this date to determine the start date of the Observation Period.

observation_period_start_date

Use this date to determine the end date of the period for which we can assume that all events for a Person are recorded.

observation_period_end_date

This field can be used to determine the provenance of the Observation Period as in whether the period was determined from an insurance enrollment file, EHR healthcare encounters, or other sources.

period_type_concept_id

Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit.

visit_occurrence_id

This table contains Events where Persons engage with the healthcare system for a duration of time. They are often also called &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;ldquo;Encounters&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;rdquo;. 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.

visit_occurrence

This field contains a concept id representing the kind of visit, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain.

visit_concept_id

For inpatient visits, the start date is typically the admission date. For outpatient visits the start date and end date will be the same.

visit_start_date

visit_start_datetime

For inpatient visits the end date is typically the discharge date.  If a Person is still an inpatient in the hospital at the time of the data extract and does not have a visit_end_date, then set the visit_end_date to the date of the data pull.

visit_end_date

If a Person is still an inpatient in the hospital at the time of the data extract and does not have a visit_end_datetime, then set the visit_end_datetime to the datetime of the data pull.

visit_end_datetime

Use this field to understand the provenance of the visit record, or where the record comes from.

visit_type_concept_id

There will only be one provider per visit record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). If there are multiple providers associated with a visit in the source, this can be reflected in the event tables (CONDITION_OCCURRENCE, PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.

This field provides information about the Care Site where the Visit took place.

This field houses the verbatim value from the source data representing the kind of visit that took place (inpatient, outpatient, emergency, etc.)

visit_source_value

visit_source_concept_id

Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.

admitted_from_concept_id

admitted_from_source_value

Use this field to determine where the patient was discharged to after a visit. This concept is part of the visit domain and can indicate if a patient was transferred to another hospital or sent to a long-term care facility, for example.  It is assumed that a person is discharged to home therefore there is not a standard concept id for &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;home&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;.  Use concept id = 0 when a person is discharged to home.

discharged_to_concept_id

discharged_to_source_value

Use this field to find the visit that occurred for the person prior to the given visit. There could be a few days or a few years in between.

preceding_visit_occurrence_id

Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit detail.

visit_detail_id

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.

visit_detail

This field contains a concept id representing the kind of visit detail, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain.

visit_detail_concept_id

This is the date of the start of the encounter. This may or may not be equal to the date of the Visit the Visit Detail is associated with.

visit_detail_start_date

visit_detail_start_datetime

This the end date of the patient-provider interaction.  If a Person is still an inpatient in the hospital at the time of the data extract and does not have a visit_end_date, then set the visit_end_date to the date of the data pull.

visit_detail_end_date

visit_detail_end_datetime

Use this field to understand the provenance of the visit detail record, or where the record comes from.

visit_detail_type_concept_id

There will only be one provider per  **visit** record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). This is a typical reason for leveraging the VISIT_DETAIL table as even though each VISIT_DETAIL record can only have one provider, there is no limit to the number of VISIT_DETAIL records that can be associated to a VISIT_OCCURRENCE record.

This field provides information about the Care Site where the Visit Detail took place.

This field houses the verbatim value from the source data representing the kind of visit detail that took place (inpatient, outpatient, emergency, etc.)

visit_detail_source_value

visit_detail_source_concept_id

Use this field to find the visit detail that occurred for the person prior to the given visit detail record. There could be a few days or a few years in between.

preceding_visit_detail_id

Use this field to find the visit detail that subsumes the given visit detail record. This is used in the case that a visit detail record needs to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship.

parent_visit_detail_id

Use this field to link the VISIT_DETAIL record to its VISIT_OCCURRENCE.

The unique key given to a condition record for a person. Refer to the ETL for how duplicate conditions during the same visit were handled.

condition_occurrence_id

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 PERSON_ID of the PERSON for whom the condition is recorded.

The CONDITION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a condition

condition_concept_id

Use this date to determine the start date of the condition

condition_start_date

condition_start_datetime

Use this date to determine the end date of the condition

condition_end_date

condition_end_datetime

This field can be used to determine the provenance of the Condition record, as in whether the condition was from an EHR system, insurance claim, registry, or other sources.

condition_type_concept_id

This concept represents the point during the visit the diagnosis was given (admitting diagnosis, final diagnosis), whether the diagnosis was determined due to laboratory findings, if the diagnosis was exclusionary, or if it was a preliminary diagnosis, among others.

condition_status_concept_id

The Stop Reason indicates why a Condition is no longer valid with respect to the purpose within the source data. Note that a Stop Reason does not necessarily imply that the condition is no longer occurring.

stop_reason

The provider associated with condition record, e.g. the provider who made the diagnosis or the provider who recorded the symptom.

The visit during which the condition occurred.

The VISIT_DETAIL record during which the condition occurred. For example, if the person was in the ICU at the time of the diagnosis the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.

This field houses the verbatim value from the source data representing the condition that occurred. For example, this could be an ICD10 or Read code.

condition_source_value

This is the concept representing the condition source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Condition necessary for a given analytic use case. Consider using CONDITION_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.

condition_source_concept_id

This field houses the verbatim value from the source data representing the condition status.

condition_status_source_value

The unique key given to records of drug dispensings or administrations for a person. Refer to the ETL for how duplicate drugs during the same visit were handled.

drug_exposure_id

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.

drug_exposure

The PERSON_ID of the PERSON for whom the drug dispensing or administration is recorded. This may be a system generated code.

The DRUG_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source concept id which represents a drug product or molecule otherwise introduced to the body. The drug concepts can have a varying degree of information about drug strength and dose. This information is relevant in the context of quantity and administration information in the subsequent fields plus strength information from the DRUG_STRENGTH table, provided as part of the standard vocabulary download.

drug_concept_id

Use this date to determine the start date of the drug record.

drug_exposure_start_date

drug_exposure_start_datetime

The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient.

drug_exposure_end_date

drug_exposure_end_datetime

This is the end date of the drug exposure as it appears in the source data, if it is given

verbatim_end_date

You can use the TYPE_CONCEPT_ID to delineate between prescriptions written vs. prescriptions dispensed vs. medication history vs. patient-reported exposure, etc.

drug_type_concept_id

The reason a person stopped a medication as it is represented in the source. Reasons include regimen completed, changed, removed, etc. This field will be retired in v6.0.

This is only filled in when the record is coming from a prescription written this field is meant to represent intended refills at time of the prescription.

refills

quantity

days_supply

This is the verbatim instruction for the drug as written by the provider.

route_concept_id

lot_number

The Provider associated with drug record, e.g. the provider who wrote the prescription or the provider who administered the drug.

The Visit during which the drug was prescribed, administered or dispensed.

The VISIT_DETAIL record during which the drug exposure occurred. For example, if the person was in the ICU at the time of the drug administration the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.

This field houses the verbatim value from the source data representing the drug exposure that occurred. For example, this could be an NDC or Gemscript code.

drug_source_value

This is the concept representing the drug source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Drug necessary for a given analytic use case. Consider using DRUG_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.

drug_source_concept_id

This field houses the verbatim value from the source data representing the drug route.

route_source_value

This field houses the verbatim value from the source data representing the dose unit of the drug given.

dose_unit_source_value

The unique key given to a procedure record for a person. Refer to the ETL for how duplicate procedures during the same visit were handled.

procedure_occurrence_id

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.

procedure_occurrence

The PERSON_ID of the PERSON for whom the procedure is recorded. This may be a system generated code.

This dataset contains structured EPR data from inpatient, outpatient and emergency care from secondary care trusts. Covering demographic information, diagnoses, events, prescribing information and lab test results for patients from 2014 to today. Currently the dataset contains data from Cambridge University Hospitals foundation trust.  Over time, the dataset will be extended to include additional secondary care trusts from across Eastern England.

Eastern England SDE Secondary Care EPR dataset

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

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.

note

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

metadata

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.

concept_ancestor

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.

death

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 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 (&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lsquo;Cardiovascular disease&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;rsquo;), detailed clinical elements (&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lsquo;Myocardial infarction of the anterolateral wall&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;rsquo;), 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.

concept

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.

cohort

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.

episode

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

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

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.

Eastern England SDE Secondary Care EPR dataset

Documentation

Coverage

Provenance

Origin

Temporal

Accessibility

Access

Usage

Format and Standards

Observations

Origin