OHDSI Home | Forums | Wiki | Github

Urine Color or Clarity Lab result values in Observation or Measurement depending on how they are mapped

Vocabulary Users
#1

Can someone enlighten me why the same term depending on which codesystem is mapped to it would be transformed into Measurement Table or Observation Table?

Example: Urine Color (part of a Urinalysis panel lab order) reported as a lab result (LOINC encoded) and it’s value (Amber, Yellow, Red) which would be mapped in the US (per USCDI) to SNOMED CT Qualifier Value codes and ETL into OMOP Observation Table.

The same Urine color value of Amber, Red, Yellow, etc. if mapped to a LOINC Answer Code would ETL into OMOP Measurement Table.
(Also laboratory medicine does not make the distinctions of lab result into Measurement and Observation, but I realize others outside of laboratory medicine like to categorize results and their values as seen here into different tables. Hence the issue.)

Was there a reason OMOP decided to split the same item into 2 different tables? It seems if users are not aware, they can miss a portion of lab results with their queries/analyses. With multicenter studies, they’d have to query both not knowing how an individual site may have mapped this term to ensure it’s included in all cases.

Also given USCDI lists SNOMED CT Qualififer values as the codesystem standard for qualitative result values, it would be nice if they were in the same table as the results from which they originate. It would be nice if all lab results were in the same table too.

Thank you for helping me to understand the why behind this design.

#2

Hello, @apitkus. In OMOP we use measurement-result pairs. We try to measure something and get some result (answer). And the answer can only reflect to measurement, but not to another answer.
In the first case Urinalysis is Measurement and Urine color is Answer (result). In this case it’s value (Amber, Yellow, etc. can not belong to Answer (result), because it would appear that one answer belongs to another, and it does not make sense. So it should be Observation.
On the other hand, in the second case Urine color is the measurement, and value of Amber, Red etc is the answer.

#3

The distinction between the OMOP Measurement Table and Observation Table for representing similar concepts, such as qualitative lab results, stems from the historical evolution and modeling choices made within the OMOP Common Data Model (CDM). While the specific design decisions may not be universally agreed upon, they were made with certain considerations in mind.

Here’s a brief overview:

  1. Historical Reasons: The OMOP CDM has evolved over time, and the decision to have separate tables for Measurement and Observation may have been influenced by the desire to accommodate different types of data sources and use cases.
  2. Semantic Differences: In the healthcare domain, the terms “measurement” and “observation” may have different semantic meanings. Measurements are often considered quantitative values, while observations may include more qualitative or categorical information. The distinction was made to capture these nuances in the data.
  3. Compatibility with Source Data: The OMOP CDM aims to be compatible with a wide range of source data, which may have different structures and conventions. The separation of Measurement and Observation tables could be an attempt to accommodate the diversity of data representations in source systems.
  4. Use Case Specificity: The OMOP CDM is designed to support a variety of use cases and research questions. Having separate tables allows users to make more specific queries tailored to their needs, even if it may result in more complex querying for certain scenarios.

While there might be practical reasons for maintaining separate tables, it’s important to acknowledge that such design decisions can introduce challenges for users who are not familiar with the nuances of the model. It’s always a trade-off between accommodating diverse data sources and simplifying data access and analysis.

If you find that this design poses challenges for your specific use case, you may consider providing feedback to the OMOP community or exploring ways to harmonize the representation of such data in your own data processing pipelines. Keep in mind that the design of data models often involves balancing various factors and considerations.

#4

Thank you for your reply. It appears that we are describing the same “term” with different meaning and thus different behavior. I’m a laboratory professional who has performed urinalysis testing and work on global laboratory interoperability whether for clinical, public health or research/RWD needs.

Globally, laboratories have an urinalysis panel order they map (in most countries) to LOINC (other countries SNOMED may be used). (Some outside laboratories call these procedures, but you are correct they are expected to be in OMOP Measurement table.) of note, orders do not have values. Values (numeric or qualitative, organism, etc are reflected in combination with the result–the value of the result as a separate field.) Here’s the order panel for a Urinalysis dipstick only panel where you can see the individual LOINCs for each result that is part of the order panel (parent)

So for urinalysis results that are part of the panel, each represented by it’s own LOINC code, each would have a value/answer from analysis of each patient specimen. Some of the values are quantiative with units, others are qualitative (pos, neg), and others may be semi-quant (1+, 2+, 3+) while color is nominative/short answer of each color and Clarity is also a nominative/short answer of choices like hazy, clear, cloudy, etc.

What I’d been noticing is the Color and Clarity individual result items are mapped to LOINC in measurement table which is good. The values of those results however, are populating either OMOP’s measurement table or observation table depending on how they are mapped, which doesn’t make sense to me as an informaticist or lab professional. The value of the lab result should be in the same table as the lab result (as should units if applicable).

Results and result values are built as separate fields in the LIS/EHR (in accord with lab accreditation regulations globally) and are mapped to different terminologies.

It looks like this issue has been resolved in the recent vocabulary release as the result values, whether mapped to LOINC Answer codes or SNOMED CT qualifier Value codes (the standard per USCDI) are now both listed (as expected) in the Measurement Value Domain for the Measurement Table.

t