The Bradford Royal Infirmary Lab Results extract. Contains textual description of tests with results, anonymised patient id and dates of test ,  reformatted to Connected Bradford FDM standards.

MDW Discover  > Connected Bradford - Secondary Care : Lab Results  - FDM @ 897

MDW Discover

Browse All

London SDE

West Midlands SDE

Kent, Medway & Sussex SDE

MDW - Discover

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

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

The Bradford Royal Infirmary FDM last build date was 2024-004-23 and contains data up to : 2024-04-17.. The observation period for this data is: 2017-03-02 to 2023-05-24


The FDM is made up of 1 source table  using routinely collected data for8,691
individuals.

The  tables are as supplied with minimal reformatting. 

It includes basic patient demographics, and information about tests including results

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

Contains the extracted LabResults data from the Bradford Royal Infromary EPR system

tbl_LabResults

tbl_LabResults_start_date

tbl_LabResults_end_date

labperesonref

participanttype

age_y_test

age_m_test

encntr_id

performed_date

order_id

catalog_description

event_description

result

result_unit_desc

result_normal_low

result_normal_high

Internally used reference data used to identify

cb_datasetref

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

The Bradford Royal Infirmary FDM last build date was 2024-004-23 and contains data up to : 2024-04-17.. The observation period for this data is: 2017-03-02 to 2023-05-24


The FDM is made up of 1 source table  using routinely collected data for8,691
individuals.

The  tables are as supplied with minimal reformatting. 

It includes basic patient demographics, and information about tests including results

Connected Bradford - Secondary Care : Lab Results - FDM

Documentation

Coverage

Provenance

Origin

Temporal

Accessibility

Access

Usage

Format and Standards

Observations

Origin