FAQ and Decisions

This page contains a selection of common questions and their answers.

Is it really OMOP?

• We will attempt to minimise changes made to OMOP while acknowledging the UK inpatient context of the data for which OMOP was not designed.
  • Costing / insurance / payment information will not be recorded.
• Meta-data beyond the standard OMOP columns is typically handled via fact-relationship tables as standard.
• The transfer format may have additional columns added to it, however those will not be visible to users who will get a standard OMOP presentation of the data.

Why are you using OMOP V5 not V6

At the time we started this project the OMOP tools had not yet had time to migrate to the V6. In the future we may move to V6, however, hopefully we will be able to do this with minimal changes to the data transfer format, and implement most of the changes in the processing pipeline. In that case it may be possible for us to offer data in both OMOP v5 & v6 formats, depending on researcher preference.

Ethnicity/Race in PERSON table

“Race” in OMOP is “ethnicity” in UK parlance. “Ethnicity” as per OMOP is not used here.

What to do with orphaned or misaligned records?

Sometimes there are records (e.g. measurements, observations, drug / device exposures) that are either:

• attributed to a VISIT_OCCURRENCE (equally VISIT_DETAIL) but chronologically fall outside of it,
• or are not associated with any visit.

This is not a problem for the data. However, any such data comes with the risk that if an analyst uses a join from VISIT_OCCURRENCE or VISIT_DETAIL these records could be lost, or look anachronistic. Analysts should be warned of this an advised to always join against PERSON directly to ensure that all records are picked up.

DateTime Encoding

• All times will be UTC.

• Unless otherwise specified, dates are times of results / entry into the Electronic Patient Record.

  Note: This is the most likely time to be recorded, and the first possible datetime at which a clinician can see the information and therefore act.

General Principles

• Data will be provided in as raw a form as possible.
  • We will place as little burden as possible on hospitals providing data.
  • Users will take the responsibility of tailoring views specific to their research processes.
• We will attempt to disambiguate different types of “missingness” (e.g., not recorded, recorded as unknown, etc.).
  • Missing data will be handled on a table by table basis, as missing data should be interpreted according to context.
  • A common EHR convention is that dates are often rounded to midnight where the specific event time is unknown (usually this happens for data that was sourced from outside the Trust - e.g. from the NHS Spine). Within the OMOP instance, instead of following that convention, sites should instead put data into the date version of the column they don’t have the time for (all datetime columns have a date-only version in OMOP).