OHDSI Home | Forums | Wiki | Github

Mapping Microbiology Susceptibility into OMOP CDM4 Observations

Implementers
#35

I don’t think you should store record #1 in the Specimen table

because the data is inherent in

RE: Measurement.value_as_concept_id
I would like to petition the CDM working group to include more domain_ids allowed in Measurement.value_as_concept_id because the current convention,

Is too restrictive.

If allowed, the staphylococcus identified in the 4th record would live in the Measurement.value_as_concept_id field of record #2. Eliminating the need for a separate 4th record. AND, IMHO, this is the most logical representation of the data. The Measurement record is a blood culture test (measurement_concept_id) and the result of the test is it grew Staph (value_as_concept_id).

The current structure of the CDM would require the susceptibility record to be a separate Measurement record as you described:

This topic has been around over 5 years. Clear conventions would be helpful to make the data available for a network query.

1 Like
#36

Normally, Meas Value is the result of some measurement by design (Qualifier Value of SNOMED or Answers of LOINC), but here’s the class of Organisms.
It’s hard to imagine the cases when organisms could be used in OMOP CDM except of results of bacterial culture, but still domain change should be thought through.

If we want to keep this Meas Value constaint, @Alexdavv please explain what is the usefulness of this restriction by Meas Value domain.
Shouldn’t it be said that it is recommended to use Meas Value, but other domains are allowed if needed?

What if we introduce specimen_concept_id instead?

Here’s another related topic

#37

Agree. A simple rule might be applied: everything that doesn’t make sense to be stored in the event_as_concept_id field, might go to the Meas Value Domain. This is a good constraint that prevents the creation of such events, actually. There are probably a few exceptions. I think organisms are not among them.

Not very useful. But once Domains are adjusted as described above, you’ll not need to violate this restriction so often. All the cases when we put Procedures/Conditions/Devices in the value_as_concept_id field go to the Observation table, agree? The only exception that comes to my mind is the Drugs recorded as values with some Measurements having a nominal scale, e.g. Drugs identified in Gastric fluid by Screen method.

Currently, we store the specimen data in the specimen table as well as it’s a piece of the Measurement concepts semantics. If we add specimen_concept_id, the specimen table together with all the included data should be retired then?

#38

I am in the process to integrate microbiology too, and I haven´t found any news/choices about this question. From several reading below I think @TBanokina proposal is a good move and I took it as a basis with some slight modifications:

  1. added specimen_id to measurement table as a clear foreign key to specimen
  2. used Modifier_of_event_id / Modifier_of_field_concept_id to store the relation between records (susceptibility derive from of culture)
  3. I am thinking about a microbiology_era table which could synthesize the information and ease the analysis (related to https://github.com/OHDSI/CommonDataModel/issues/281)

This has the benefit to not use the fact relationship table. Still the self joins on measurement to link the culture is a performance problem as mentioned by @cukarthik. I also wonder if a dedicated culture table is not a better choice.

#39

+1 for expanding the domain constraint for MEASUREMENT.value_as_concept_id

Let’s open this up, so when the use cases arise, the data is already mapped to standard concepts in the cdm. US EHR data usually has 100,000+ custom codes for the value_as_concept_id field. This field is rarely standardized at the source.

@Christian_Reich, @clairblacketer Should we add this to the conventions :slight_smile:

1 Like
#40

Hi,
We are also in the process of mapping laboratory microbiology data onto OMOP CDC v6.0 and have encountered similar issues as the ones discussed here and is other threads. Our use case may be summarized saying that we aim at detailed observing tests performed in a lab network.
As shown below this relates to a several discussion threads for which we have not seen a firm answer yet.
In the situation of micro-organism identification and subsequent antibiotic susceptibilities, our model raises questions similar to what is described by @parisni, @TBanokina and @nzvyagina
It includes a specimen table (eg. Veinous Blood sample) that is linked by fact_relationship to one or more measurement table.

  • It includes a specimen table (eg. Veinous Blood sample) that is linked by fact_relationship to one or more measurement table.
  • A first measurement table stores information about the microorganisms identification tests and system level results. Such as, in the case of a mass spectroscopy malti-tof test,
    measurement_concept_id = OMOP code for LOINC describing the test eg. 76346-6 Microorganism identified in Isolate by MS.MALDI-TOF
    Value_as_concept_id = OMOP code for the concept representing the organism identified
  • This table is linked by fact_relationship to several measurement tables for antibiotic susceptibility tests & results.
    Measurement table storing antibiotic susceptibility results.
    measurement_concept_id = OMOP code for the LOINC describing the antibiotic test, eg. 28-1 Ampicillin [Susceptibility] by Minimum inhibitory concentration (MIC)
    Value_as_number would be the MIC result
    Value_as_concept_id = OMOP code for the concept representing the corresponding category (R/I/S)

This leads to several questions appearing in several discussion threads for which we seek answers

  1. How can we confirm that using both value_as_concept_id and value_as_number to store antibiotic susceptibility results (MIC & category) for the same measurement is allowed ?
    This is also
  1. We have the same issue than @TBanokina concerning Meas.value domain

It is especially challenging to store organisms identification in value_as_concept_id (eg. Escherichia coli) because SNOMED derived codes for organisms are considered as Observation domain (ID = 4011683). To follow the generally accepted paradigm of “LOINC as the question and SNOMED as the answer”, one would need to allow code from SNOMED vocabulary to be also used as value_as_concept_id
So, how can we proceed to modify and clear this vocabulary issue, thus allowing SNOMED vocabulary to be used for value_as_concept_id in the MEASURMENT table?
Note that a related discussion appears in the thread from @Vojtech_Huser (Duplicate standard concepts for value_as_concept_id in OMOP Vocab) showing that data duplication appear between LOINC answers and SNOMED codes.

  1. We agree with @Christian_Reich, connecting specimen and measurement by the fact relationship is not the cleanest of all options. As @parisni and @Alexdavv suggested (see also Link between SPECIMEN and MEASUREMENT) adding specimen_id as a foreign key to the Measurement table would reduce the need for fact_relationship between those two table (Modifier_of_event_id / Modifier_of_field_concept_id)
    How can we help the community to move forward in this direction and make a decision ?

  2. Lastly what is the status of the proposal for a microbiology or culture area table ? (https://github.com/OHDSI/CommonDataModel/issues/281 and Adding Cultures into OMOP v5)
    Is this still a living proposal ? how can we participate to its improvement (if needed) and blessing ?

Considering that options 3 and 4 are likely mutually exclusive.
E. Theron // X. Gansel

#41

This is of one longest existing topics on a forum, and I think to solve it, we lack a good use case, I’m actually surprised @Christian_Reich didn’t asked that before.
So maybe someone has a good use case of how they would like to analyze microbiology data? What research questions you want to ask?
This will help us to shape the data in the OMOP CDM.

#42

It’s pretty much any ID question. What are the outcomes of patients with MRSA? Does one antibiotics work better than another? And the list goes on, including characterization, comparative effectiveness and quality measures.

I think All Of Us came up with a model for microbiology data they use, but I don’t know the details.

#43

@cukarthik do you know the details?

#44

Is there an update or decision on best practice regarding how to capture microbiology data?

#45

Microbiology data in general, or the specific question of germ sensitivity to antibiotics? The former never was a problem, the latter needs finishing.

#46

Both.

That means, linking the records of the specimen table and measurement table via the fact relationship table is currently the way to go for samples/specimen and isolates/measurements until an updated version of the CDM includes the possibility for a more direct relationship.

Where will the decision for the Antibiogram be published? In the documentation of the CDM?

#47

In CDM v5.4 both the Observation and Measurement table now have had columns added to allow the Observation or Measurement to link back to another table.
meas_event_field_concept_id, Put the CONCEPT_ID that identifies which table and field the MEASUREMENT_EVENT_ID came from.
measurement_event_id, If the Measurement record is related to another record in the database, this field is the primary key of the linked record.
This is the more direct relationship.

1 Like
#48

Hello,

I am relatively new to the OHDSI community and found this thread regarding microbiology susceptibility. Our group is working on a phenotype that will rely on bacterial cultures and antibiotic susceptibility test results (MIC values). Is there a defined convention for this in OMOP v5.3.1 and 5.6?

Thank you for any assistance or updates on this matter. I greatly appreciate it.

Kind regards,
Alyssa

#49

Hello @ARBeck and welcome to OHDSI!

FYI: There isn’t a v5.6 OMOP CDM. Most of the OHDSI community is on version 5.4 of the CDM with some sites still on v5.3.1.

The most recent discussion I see is on GitHub for the CDM from October 2021 states there will be pre-coordinated concepts added to the vocabulary. However, up above in this thread, in June 2023 @Christian_Reich states it still needs finishing.

@Christian_Reich @clairblacketer @cukarthik Where does this stand? If it’s finished, we (CDM WG or Themis WG) should write up some guidance for ETLers and researchers.

#50

I am also relatively new to OHDSI and interested in the current status of microbiology within the CDM. From this thread it appears there are several solutions over time which might be useful for a more standardized implementation.

#51

Hello, is there an update on the domain question regarding how/where to store organisms? I couldn’t find any further information or conclusion, and I have the same issue concerning the Meas value domain of organisms.

My problem is that less than 20% of the organisms present in our data can be mapped to the Meas Value domain. The rest didn’t have a match in this domain but in the observation domain instead. And it would also be possible to map all the organisms that I mapped to the Meas Value domain to the Observation domain. In other words, the vocabulary used for the Meas Value domain (LOINC) is not complete at all, but the vocabulary used for the Observation domain (SNOMED) is almost complete.
Having the data mapped to two different vocabularies does not seem appropriate when I could just map everything to SNOMED which is in the observation domain.

Now I am wondering what is the preferred way to handle this situation.

  • Using the measurement table, mapping everything to the observation domain
  • Using the observation table, mapping everything to the observation domain
  • Using the measurement table, mapping as much as possible to the Meas Value domain and the rest to the observation domain and having mixed terminologies for the organisms
  • Split the data in the measurement and observation tables based on the domain to which the data can be mapped

Thank you very much for your help and opinion on this topic! I am looking forward to learning more about the approaches and mindset.

#52

Excellent questions, @HeideNei!

I am pinging @Christian_Reich @clairblacketer @cukarthik to help answer the question for you.

Also, in addition to the above question, @Christian_Reich, should @HeideNei submit the request for domain change to the Vocab team’s community contribution? How should they proceed?

#53

A short answer is what @willgarneau pointed to. There are different approaches (as you can see by the length of this thread) to microbiology data in the community: creating an extension table, mapping organisms to Meas Value organisms, mapping test + organism to pre-coordinated terms (note that it not only requires new concepts but also ETL work to combine fields) and more.

A very pragmatic solution is to implement something you can use to enable your research right here and right now.

A larger scale proper solution (I think, based on what I read so far) is to move forward with the proposal for pre-coordinated susceptibility testing + organism terms as per this GitHub. This requires some resources/time/funding/prioritization to make vocabulary changes happen.

#54

I don’t see a problem in using the measurement table as it is right now, as I only want to store organisms and no additional information like germ sensitivity to antibiotics, for example. The only problem I have is a vocabulary/domain problem.
As the measurement table is currently defined (v5.4), the detected organism would be included in the value_as_concept_id attribute. This attribute has the restriction that the categorical value should be mapped to a standard concept in the ‘Meas Value’ domain. However, only few organisms can be found in this domain. On the other hand, all the organisms can be found in the Observation domain.
I am wondering what the standard procedure is for this case.

t