The Bradford Royal Infirmary Maternity extract. Contains textual description of maternity unit visits , with delivery data ,  anonymised patient id ,  reformatted to Connected Bradford FDM standards.

MDW Discover  > Connected Bradford - Secondary Care : Maternity FDM @ 904

MDW Discover

Browse All

London SDE

West Midlands SDE

Kent, Medway & Sussex SDE

MDW - Discover

https://github.com/ConnectedBradford/Connected-Bradford-Secondary-Care-Maternity

The Connected Bradford Bradford Royal Infirmary Maternity  : Flexible Data Model (FDM) Contains routinely collected data for approximately 68,000 patients. The dataset has been fully anonymised, but can link to other Connected Bradford FDM"s.

The Bradford Royal Infirmary Maternity FDM last build date was 2024-05-17 and contains data up to : 2024-004-20.. The observation period for this data is: 2016-03-15 to 2024-04-20


The FDM is made up of 1 source table  using routinely collected data for 68,352
individuals.

The  tables are as supplied with minimal reformatting. 

It includes basic patient demographics, and maternity unit events.

This population within this dataset covers  those individuals who have had a lab test and BRI during a Inpatient, Outpatient , A&E or  other visit to Bradford Royal Infirmary  from 2017 onwards.. There are 1,141,655 an average of 131 tests per patient.

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

cb_maternity_delivery

delivery_serial

deliveryminutes

the abnormality_detected_dating_ultrasound_scan data

abnormality_detected_dating_ultrasound_scan

the activity_date_antenatal_appointment data

activity_date_antenatal_appointment

the activity_not_offered_reason_code_for_maternity_dating_ultrasound_scan data

activity_not_offered_reason_code_for_maternity_dating_ultrasound_scan

the activity_not_offered_reason_code_for_maternity_dating_ultrasound_scan_desc data

activity_not_offered_reason_code_for_maternity_dating_ultrasound_scan_desc

the activity_offer_date_dating_ultrasound_scan data

activity_offer_date_dating_ultrasound_scan

the anaesthesia_given_during_labour_or_delivery data

anaesthesia_given_during_labour_or_delivery

the anaesthesia_given_during_labour_or_delivery_desc data

anaesthesia_given_during_labour_or_delivery_desc

the anaesthesia_given_post_labour_or_delivery data

anaesthesia_given_post_labour_or_delivery

the anaesthesia_given_post_labour_or_delivery_desc data

anaesthesia_given_post_labour_or_delivery_desc

the appointment_date_formal_antenatal_booking data

appointment_date_formal_antenatal_booking

the cigarettes_per_day_mother_at_booking data

cigarettes_per_day_mother_at_booking

commissioning_serial_number

the complex_social_factors_indicator_mother_at_booking data

complex_social_factors_indicator_mother_at_booking

contract_serial

date_of_decision_to_deliver

time_of_decision_to_deliver

delivery_time

delivery_of_placenta_method

the delivery_of_placenta_method_desc data

delivery_of_placenta_method_desc

the discharge_date_mother_maternity_services data

discharge_date_mother_maternity_services

the discharge_time_mother_maternity_services data

discharge_time_mother_maternity_services

the employment_status_mother_at_booking data

employment_status_mother_at_booking

the employment_status_mother_at_booking_desc data

employment_status_mother_at_booking_desc

the employment_status_partner_at_booking data

employment_status_partner_at_booking

the employment_status_partner_at_booking_desc data

employment_status_partner_at_booking_desc

the end_of_third_stage_of_labour_time data

end_of_third_stage_of_labour_time

episiotomy_performed_reason

the estimated_date_of_delivery_method_agreed data

estimated_date_of_delivery_method_agreed

the estimated_date_of_delivery_method_agreed_desc data

estimated_date_of_delivery_method_agreed_desc

exclude_cds

exclude_msds

exclude_pbr

expected_delivery_date

expected_delivery_time

the general_medical_practitioner_antenatal_care data

general_medical_practitioner_antenatal_care

the gestation_length_in_days_dating_ultrasound_scan data

gestation_length_in_days_dating_ultrasound_scan

the gestation_length_in_weeks_at_assessment data

gestation_length_in_weeks_at_assessment

the gestation_length_in_weeks_labour_onset data

gestation_length_in_weeks_labour_onset

the labour_or_delivery_onset_method_code data

labour_or_delivery_onset_method_code

the labour_or_delivery_onset_method_code_desc data

labour_or_delivery_onset_method_code_desc

last_menstrual_period_date

the mental_health_prediction_and_detection_indicator_mother_at_booking data

mental_health_prediction_and_detection_indicator_mother_at_booking

digest

the nhs_service_agreement_line_number data

nhs_service_agreement_line_number

the number_of_fetuses_dating_ultrasound_scan data

number_of_fetuses_dating_ultrasound_scan

the onset_of_established_labour_time data

onset_of_established_labour_time

the onset_of_second_stage_of_labour_time data

onset_of_second_stage_of_labour_time

The Connected Bradford Bradford Royal Infirmary Maternity  : Flexible Data Model (FDM) Contains routinely collected data for approximately 68,000 patients. The dataset has been fully anonymised, but can link to other Connected Bradford FDM's.

The Bradford Royal Infirmary Maternity FDM last build date was 2024-05-17 and contains data up to : 2024-004-20.. The observation period for this data is: 2016-03-15 to 2024-04-20


The FDM is made up of 1 source table  using routinely collected data for 68,352
individuals.

The  tables are as supplied with minimal reformatting. 

It includes basic patient demographics, and maternity unit events.

Connected Bradford - Secondary Care : Maternity FDM

Documentation

Coverage

Provenance

Origin

Temporal

Accessibility

Access

Usage

Format and Standards

Observations

Origin