The Death Certificate  FDM. Contains textual and some ICD10 coding for the death certificate data for the Bradford District population with anonymised patient id  ,  reformatted to Connected Bradford FDM standards.

MDW Discover  > Connected Bradford - Secondary Care : Death Certificate @ 900

MDW Discover

Browse All

London SDE

West Midlands SDE

Kent, Medway & Sussex SDE

MDW - Discover

https://github.com/ConnectedBradford/Connected-Bradford-DeathCertificates

The Connected Bradford - Death Certificate Flexible Data Model (FDM) Contains routinely collected data for approximately 200,000 patients. The dataset has been fully anonymised, but can link to other Connected Bradford FDM"s.

The Autism FDM last build date was 2023-11-15 . The observation period for this data is:1904-01-15 to	2023-08-22

The FDM is made up of 1 source table  using routinely collected data for 218,276 
individuals, aged 0 to 100+

The  tables are as supplied with minimal reformatting. 

It includes basic patient demographics, and information about consultations.

This population within this dataset covers those where a Death Certificate has been issued within the Bradford District

HDR UK

Connected Bradford

Assign an ID to each combination of a location and nature of the site - the latter could be the Place of Service, name or another characteristic in your source data.

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. Choose the concept in the visit domain that best represents the setting in which healthcare is provided in the Care Site. If most visits in a Care Site are Inpatient, then the place_of_service_concept_id should represent Inpatient. If information is present about a unique Care Site (e.g. Pharmacy) then a Care Site record should be created. Accepted Concepts. For information about how to populate this field please see the THEMIS Conventions.

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

Put the place of service of the care_site as it appears in the source data.

place_of_service_source_value

It is assumed that every person with a different unique identifier is in fact a different person and should be treated independently. Any person linkage that needs to occur to uniquely identify Persons ought to be done prior to writing this table. This identifier can be the original id from the source data provided if it is an integer, otherwise it can be an autogenerated number.

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. Use the gender or sex value present in the data under the assumption that it is the biological sex at birth. If the source data captures gender identity it should be stored in the OBSERVATION table. Accepted gender concepts. Please refer to the THEMIS repository for detailed conventions on how to populate this field.

gender_concept_id

Compute age using year_of_birth. For data sources with date of birth, the year should be extracted. If no year of birth is available all the person’s data should be dropped from the CDM instance. For additional information on how to populate this field, please refer to the THEMIS repository.

year_of_birth

For data sources that provide the precise date of birth, the month should be extracted and stored in this field.

month_of_birth

For data sources that provide the precise date of birth, the day should be extracted and stored in this field.

day_of_birth

This field is not required but highly encouraged. For data sources that provide the precise datetime of birth, that value should be stored in this field. For more information on how to populate this field, please refer to the THEMIS repository.

birth_datetime

This field captures race or ethnic background of the person. Only use this field if you have information about race or ethnic background. The Vocabulary contains Concepts about the main races and ethnic backgrounds in a hierarchical system. Due to the imprecise nature of human races and ethnic backgrounds, this is not a perfect system. Mixed races are not supported. If a clear race or ethnic background cannot be established, use Concept_Id 0. Accepted Race Concepts.

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 “Hispanic” and “Not Hispanic”. Races and ethnic backgrounds are not stored here. Only use this field if you have US-based data and a source of this information. Do not attempt to infer Ethnicity from the race or ethnic background of the Person. Accepted ethnicity concepts

ethnicity_concept_id

The location refers to the physical address of the person. This field should capture the last known location of the person. Put the location_id from the LOCATION table here that represents the most granular location information for the person. For additional information on how to populate this field, please refer to the THEMIS repository.

The Provider refers to the last known primary care provider (General Practitioner). Put the provider_id from the PROVIDER table of the last known general practitioner of the person. If there are multiple providers, it is up to the ETL to decide which to put here.

provider_id

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

Use this field to link back to persons in the source data. This is typically used for error checking of ETL logic. Some use cases require the ability to link back to persons in the source data. This field allows for the storing of the person value as it appears in the source. This field is not required but strongly recommended.

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. Put the assigned sex at birth of the person as it appears in the source data.

gender_source_value

Due to the small number of options, this tends to be zero. If the source data codes asigned sex at birth in a non-standard vocabulary, store the concept_id here.

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. Put the race of the person as it appears in the source data.

race_source_value

Due to the small number of options, this tends to be zero. If the source data codes race in an OMOP supported vocabulary store the concept_id here.

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. If the person has an ethnicity other than the OMB standard of “Hispanic” or “Not Hispanic” store that value from the source data here.

ethnicity_source_value

Due to the small number of options, this tends to be zero. If the source data codes ethnicity in an OMOP supported vocabulary, store the concept_id here.

ethnicity_source_concept_id

A Person can have multiple discrete Observation Periods which are identified by the Observation_Period_Id. Assign a unique observation_period_id to each discrete Observation Period for a Person.

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. It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_start_date can be inferred as the earliest Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. If a Person switches plans but stays with the same payer, and therefore capturing of data continues, that change would be captured in PAYER_PLAN_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. It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_end_date can be inferred as the last Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer.

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. Choose the observation_period_type_concept_id that best represents how the period was determined. Accepted Concepts. A more detailed explanation of each Type Concept can be found on the vocabulary wiki.

period_type_concept_id

table_name

This is the generated table that holds the meta data for each table

data_dictionary

column_name

what type of field is it, string, int etc

data_type

a random sample of 5 items with counts for those 5

description

A unique identifier for each Person's visit or encounter at a healthcare provider.

visit_occurrence_id

A Visit Occurrence is recorded for each visit to a healthcare facility.

visit_occurrence

A foreign key identifier to the Person for whom the visit is recorded. The demographic details of that Person are stored in the PERSON table.

A foreign key that refers to a visit Concept identifier in the Standardized Vocabularies.

visit_concept_id

visit_start_date

visit_start_datetime

The end date of the visit. If this is a one-day visit the end date should match the start date.

visit_end_date

visit_end_datetime

A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of source data from which the visit record is derived.

visit_type_concept_id

A foreign key to the provider in the provider table who was associated with the visit.

A foreign key to the care site in the care site table that was visited.

A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the admitting source for a visit.

admitting_source_concept_id

A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the discharge disposition (destination) for a visit.

discharge_to_concept_id

A foreign key to the VISIT_OCCURRENCE table record of the visit immediately preceding this visit.

preceding_visit_occurrence_id

The source code for the visit as it appears in the source data.

visit_source_value

A foreign key to a Concept that refers to the code used in the source.

visit_source_concept_id

The source code for the admitting source as it appears in the source data.

admitting_source_value

The source code for the discharge disposition as it appears in the source data.

discharge_to_source_value

tbl_NEC_Deaths_QWO_20230817_RELEASE

the tbl_NEC_Deaths_QWO_20230817_RELEASE_start_date data

tbl_NEC_Deaths_QWO_20230817_RELEASE_start_date

the tbl_NEC_Deaths_QWO_20230817_RELEASE_end_date data

tbl_NEC_Deaths_QWO_20230817_RELEASE_end_date

dec_marital_status

dec_agec

reg_date

reg_district_code

reg_sub_district_code

reg_number

reg_entry_number

reg_type

cor_designation

cor_area_name

cor_inq_dates

dec_occ_type

out_seccatdm

out_seccathf

soc2kdm

dmic_soc2kdm_group_description

soc2khf

dmic_soc2khf_group_description

dec_retired_ind

dmic_decad_postcode_sector

dmic_decad_stat_postcode_sector

dec_birth_country_code

dmic_pod_stat_postcode_sector

pod_nhs_establishment

pod_establishment_type

pod_code

s_underlying_cod_icd10

the dmic_s_underlying_cod_icd10_chapter data

dmic_s_underlying_cod_icd10_chapter

s_cod_code_1

s_cod_code_2

s_cod_code_3

s_cod_code_4

s_cod_code_5

s_cod_code_6

s_cod_code_7

s_cod_code_8

s_cod_code_9

s_cod_code_10

s_cod_code_11

s_cod_code_12

s_cod_code_13

s_cod_code_14

s_cod_code_15

s_injury_external

The Connected Bradford - Death Certificate Flexible Data Model (FDM) Contains routinely collected data for approximately 200,000 patients. The dataset has been fully anonymised, but can link to other Connected Bradford FDM's.

The Autism FDM last build date was 2023-11-15 . The observation period for this data is:1904-01-15 to	2023-08-22

The FDM is made up of 1 source table  using routinely collected data for 218,276 
individuals, aged 0 to 100+

The  tables are as supplied with minimal reformatting. 

It includes basic patient demographics, and information about consultations.

Connected Bradford - Secondary Care : Death Certificate

Documentation

Coverage

Provenance

Origin

Temporal

Accessibility

Access

Usage

Format and Standards

Observations

Origin