OHDSI Home | Forums | Wiki | Github

Adding Cultures into OMOP v5

CDM Builders
,
#1

This is a post very similar to an old topic. We’ve been looking at how to model cultures in OMOP. In my opinion there are two options:

  1. Adopting a table similar to PEDSnet called measurement_organism.
  2. Creating a new relationship.

For option 2, it would store susceptibility information in the measurement table and organism information in the observation table; however, there isn’t a relationship to connect the two, like a ‘organism tested’ and ‘antibiotic tested’ relationship.

For example, if we are testing Cefuroxime susceptibility (concept_id= 3042086) on streptococcus pneumoniae (concept_id=4321152), for both approaches there would be one measurement row for the test where measurment_concept_id=3042086 and the value_concept_id would be one of three possible values: Susceptible (4038110), Indeterminate (4219043), or Resistant (4148441).

I’m thinking option 2 is the way to go, but we’d need a new relationship to connect the test to the organism. I’m ignoring MIC values in this case where there would be another row in the measurement table added.

The other thing we would want to consider is how either decision (of course after the CDM/Vocab WG reviews) would affect Atlas. Right now, it doesn’t seem that relationships are part of Atlas. Calling out @Chris_Knoll on his input on the application side.

1 Like
Link between SPECIMEN and MEASUREMENT
Mapping Microbiology Susceptibility into OMOP CDM4 Observations
Relationship options for fact_relationship table
#2

I wanted to follow-up on this post and get peoples opinions.

#3

@cukarthik:

You’d have to submit this to the CDM Working Group, which you can consider having done with this. Then you have to right a proposal including the fields of that new table. @clairblacketer will help you. Then you have to withstand the grilling of the team and voting.

#4

Before I put together a proposal, I wanted to get peoples opinions on which is a better approach. Creating new relationships are easier, but can be more difficult from a query perspective. I’m also wanting to understand which is also a better choice from an Atlas perspective. I’m happy to write up a proposal after getting some input from the community. @Frank @bailey @Gowtham_Rao @hripcsa do you have an opinion on the approach

#5

Could you explain the use case in more detail.

From what i understand – Person had an observation. That led to a follow up test, that had a result. Person was observed to have a microorganism. That led to a test of sensitivity, which had a result. We want to relate the records that led to a sequence together in a way that Atlas may use it?

#6

That’s correct. So, one question might be: how would I find all patients who have a bacteria that is resistant to a particular antibiotic. From what I can tell using Atlas, you can only create a measurement criteria to search for resistance to Cefuroxime susceptibility, but you can’t link that to a particular bacteria found.

#7

How would you relate the two records in the cdm? Do they have a visit record? Are they part of the same visit_occurrence or different or don’t have a visit record?

#8

Friends:

One way of doing it without the ugly FACT_RELATIONSHIP or without new tables is this:

  • You put a Measurement in with concept_id=‘Blood culture’ and value_as_concept_id=‘Staphylococcus’
  • You put another Measurement in the same day with concept_id=‘Staphylococcus’ and value_as_concept_id=‘Cephalosporin’

We would add a convention that people would understand this. ATLAS could also pick it up.

Thoughts?

#9

Is there a way we can use the Specimen table here? This is just a thought but maybe instead of one Measurement with concept_id=‘Blood culture’ and value_as_concept_id=‘Staphylococcus’ we start off with one Specimen record with specimen_concept_id = ‘Staphylococcus’ and specimen_type_concept_id = ‘Blood culture’. Then we have the Measurement on the same day with concept_id=‘Staphylococcus’ and value_as_concept_id=‘Cephalosporin’ with some way to link the specimen and measurement records.

#10

@clairblacketer:

Another good idea. Except I don’t know how it would work, since the specimen refers to the blood, not the wonderful organism growing in it. :smile: Because the specimen gets created before the measurement, not after. But we could change that.

#11

Hi, @Christian_Reich,
I might suggest adding an additional convention to creating the 2 measurements: assign them the same visit_occurrence_id, and that way in atlas you can use the ‘during the same visit’ option to find the blood culture at the same visit as the stapylococcus measurement.

Additionally, we could enhance the measurement criteria object to find the association by joining the measurement record’s value_as_concept_id to the other measurement record’s concept_id (restricting to the same day/same visit). I’m not sure what I would call this ‘association’ (for labeling purposes in the UI, as I’m not familiar enough with the lingo in this usecase to suggest a moniker). We could also join over to the specimen table if that would be appropriate.

#12

@Chris_Knoll:

I like the visit clamp, except there could be more than one blood culture in the visit. In fact, if there is a patient with sepsis or so they will do a lot of blood cultures in a row.

So, your second idea is better. but it would have to be a special thingy. Not sure how well that’s going to fit into the ATLAS UI.

#13

@Christian_Reich @Chris_Knoll why the hate for the Fact_Relationship table. It looks just like the concept_relationship table to me.

Agree with @Chris_Knoll. This is where I was going with

This is where the newly minted visit_detail table comes into play.! And its has preceding_visit_detail_id (i know that is horrible, but we have it). Visit_detail is not yet supported by Atlas - but it can be added.

Another problem with specimen table is – it does not have visit_occurrence_id or visit_detail_id, so only way to relate to the other tables is thru person_id + temporal relationship.

#14

Hello,

Thank you for your email regarding [OHDSI Forums] [CDM Builders] Adding
Cultures into OMOP v5.

I am currently at a training and I have limited email access. I will respond
to your e-mail upon my return on Friday, November 17th.

Thanks for your patience,
Valerie.

#15

It seems to me that none of the proposed solutions work in Atlas today, so that does not differentiate among them. The fact_relationship table directly addresses the requirement today without a need to change the schema. As Karthik suggested, I would try putting the organism in the observation table, and put the antibiotic and resistance or titer in the measurement table and link the organism to the antibiotic with the fact relationship. I think the latter will be used infrequently enough that adding one more table into the join compared to some of the other solutions mentioned above won’t be too costly.

#16

Hello,

Thank you for your email regarding [OHDSI Forums] [CDM Builders] Adding
Cultures into OMOP v5.

I am currently at a training and I have limited email access. I will respond
to your e-mail upon my return on Friday, November 17th.

Thanks for your patience,
Valerie.

#17

This is just my perspective:
The benefit of the fact relationship is also its greatest weakness.

With the fact_relationship table, you can introduce any new data relationship without ever needing to alter the cdm schema! Sounds great, except with that sort of flexibility, fact_relationships are now completely left to the implementation of the source-specific ETL process. That means that I could write a query that uses fact_relationship on one db, but there’s no guarantee that those relationships would hold the same meaning or even exist on another CDM. It’s almost as bad as a pure EAV model (where any entity could have any attribute of any value), but at least in the case of CDM and fact relationships, you’re relating structured data to another piece of structured data.

This all being said, we can create a fact-relationship criterion for every criteria type that is supported by CIRCE. It would work something like this:

a condition occurence of {conceptset}
[x] for the first time in a patients history
[x] at age betwwen {start} and [end]
[x] with a relationship of {fact_relationship_type} with:
   a proceudre occurrence of [conceptset]
   [x] (additional procedure occurrence criteria here)

Essentially, the ‘factRelationship’ criteria takes the form:

{
  relationshipType: someRelationshopTypeConceptId,
  criteria : { a instance of one of the criteria types }
}

In the SQL generation, if a fact_relationship was indicated, we just do the join to the appropriate table, using the fact_relationship to bridge them.

If this looks desirable, I can get a more formal mockup put together, and maybe it’s something we can collaborate on implementing.

-Chris

1 Like
#18

Hello,

Thank you for your email regarding [OHDSI Forums] [CDM Builders] Adding
Cultures into OMOP v5.

I am currently at a training and I have limited email access. I will respond
to your e-mail upon my return on Friday, November 17th.

Thanks for your patience,
Valerie.

#19

This seems like something worth looking into in my opinion. Having a general solution for fact_relationship being incorporated into Atlas would be good.

As for cultures in particular, you’re right, @Chris_Knoll, that standardizing cultures with the fact_relationship table will be difficult. We would have to create an implementation guide for cultures. This could be something that the Themis group releases if the CDM working group approves this solution. I think it would be good to try this approach first and if we have issues then we revisit if the community complains about performance or other deficiencies.

#20

Hello,

Thank you for your email regarding [OHDSI Forums] [CDM Builders] Adding
Cultures into OMOP v5.

I am currently at a training and I have limited email access. I will respond
to your e-mail upon my return on Friday, November 17th.

Thanks for your patience,
Valerie.

t