OHDSI Home | Forums | Wiki | Github

Mapping Microbiology Susceptibility into OMOP CDM4 Observations

(Philip Zachariah) #21

In case it helps…maybe a little window into how this works in a clinical setting will help. Sorry if this is repetitive.

Morphology and other characteristics
Microbiology testing is done in stages- in the direction of increasing specificity. Historically this has been because the full identification usually takes days. So initially the lab report will say something like “gram positive cocci in clusters” or “ gram negative rod oxidase negative”. So doctors can change/adapt antibiotics if needed quickly before the final ID arrives. But this is superseded by the final ID when it arrives. So if the final ID says Staphylococcus aureus- we know the morphology was gram positive cocci in clusters or if it says E.coli we know it is oxidase negative. So in most situations, the final ID/ susceptibilities are all you need. The one place where this could be relevant is for that small group of organisms where the culture takes a long time to grow (e.g. ,months). Tuberculosis is a classic example – where you could have an initial result “AFB smear positive” and it will take weeks to months for the culture to finalize. But again with the kind of mostly long term retrospective studies that are planned this should not be that big an issue.

Most times, the micro lab will not quantify the amount of bacteria that grows. An important exception is urine cultures where depending on how the urine specimen is collected ( via catherization or asking the patient to pee in a cup)- the lab does a rough estimate of how much bacteria was there ( expressed as colony counts). There are specific thresholds (10K, 50K , 100K etc) and depending on the value you adjudicate whether this is a real infection vs just contamination of the specimen that occurred during collection. So if this is available, specially for urine cultures this is useful information to include. In Karthik’s proposal this would be a row in the measurement table tagged to the specific organism( if I understand it correctly).

Antibiotic susceptibility results outside of Sensitive/Resistant and MIC values
Antibiotic susceptibility is usually tested using methods where different concentrations of antibiotics are tested against the organism. There are pre-specified cut offs used by each lab to classify a specific bug as sensitive vs. resistant. But occasionally the lab will test for other specific resistance mechanisms to groups of antibiotics-using a gene probe, PCR or other methods. In the example above, the beta-lactamase test will identify whether the organism produces enzymes that can destroy penicillins or related drug classes. So the clinician knows that this means that a specific class of antibiotics should not be used. In real life, one can guess if some of these resistance mechanisms are present, by looking at the specific drugs being R vs S in the antibiotic susceptibility panel which arrives later. And there is a lot of diversity in whether laboratories choose to do these tests. But if included these will need to be linked to the specific organism that is identified.


(Don Torok) #22

@ nzvyagina, @ Dymshyts
This is in response to the proposed set of relationships:
1-3 - Lab test performed on specimen
2-3 - Lab test performed on specimen
1-2 - Related lab test
2-1 - Related lab test
3-1 - Specimen used for lab test
3-2 - Specimen used for lab test

Looks like the number of relationships will grow exponentially if you were to add another event (Observation or Measurement) to the group. That is a problem. Also, there has been a convention that relationships are directional and have an inverse. What would be the inverse ‘Related lab test’? There is probably an ordering or dependency to the events. Urine > E coli > Susceptibility make sense, but Urine > Susceptibility or the inverse Susceptibility > Urine without the intervening E coli does not make sense.

(Seng Chan You) #23

Can we leverage episode extension proposed by oncology WG for this purpose? How do you think? @rimma @mgurley

(Nadya Zvyagina) #24

@MPhilofsky, I would propose the following:
*status - I would not create a record in case ‘Not detected’ because observation_concept_id (E.Coli) may mislead someone if they do not look at the result. So since there are only 2 values Detected and Not detected, there is no necessity of creating a separate record for status.
*morphology - observation_concept_id (E.coli) + value_as_concept_id (some morphology value)
*oxidase status - to tell the truth I do not know what it is. But taking into account what @philipzach wrote, looks like it is not that important since you already know the final ID (E.coli, staphylococcus aureus etc). May be I am wrong.

(Melanie Philofsky) #25

Thank you, @philipzach, for the detailed explanation. It is helpful to know the clinical perspective.

Very good point! Without a specific use case, it isn’t necessary or useful.

(Christian Reich) #26

@cukarthik et al.

Hm. This looks like a gigantic solution for a rather small problem. I think. Correct me if I am wrong.

Rather than the pair “measurement - result” you are identifying a triplet situation here: “organism - antibiotic testing - result”. And in your proposal the organism would reside in MEASUREMENT, the testing and result would be MEASUREMENT_ATTRIBUTE. And then you link the two. Correct?

Why not do the following: Have two records in MEASUREMENT.

  • Blood culture - staphylococcus areus
  • Antibiotic testing - resistant

I also understand you don’t like the FACT_RELATIONSHIP table as a mechanism to connect the two. Neither do I. Instead, we could add a field “reference_measurement_id” to the table, which links the latter to the former. This would also solve @MPhilofsky’s problem that there might be more than one subsequent test on the staph colonies. Each of them would refer to the same original blood culture record.

Seems to work to me, and a lot less change.


(Nadya Zvyagina) #27

Hi @Christian_Reich, reference_measurement_id will work in case of only one related measurement. But adding this field should entail a rule that only one reference measurement can exist, otherwise we will get two (or more) identical records differing by reference_measurement_id only.

(Michael Gurley) #28

All EAV tables (MEASUREMENT and OBSERVATION) should uniformly be able to polymorphically reference an Entity that the Attribute (measurement_concept_id /observation_concept_id) and Value (value_as_number, value_as_string,value_as_concept_id) are about. I am assuming that Person is not a fine-grained enough Entity for many use cases. Using a polymorphic pairing would remove only being able to reference a specimen_id.

OBSERVATION already has a polymorphic column pairing giving it the ability to reference an Entity: observation_event_id and obs_event_field_concept_id. The Oncology CDM extension is proposing to add a polymorphic column pairing to MEASUREMENT: modifier_of_event_id and modifier_of_field_concept_id. I think it would be better to make these pairings adhere to a consistent naming convention.

The other item that this proposal raises is the need to group EAV rows into ‘panels’, ‘collection’ or ‘rows’ . This is a common requirement that all EAV systems need to eventually embrace or reject. Often some kind of grouper column is added to the EAV table that pulls all the desired EAV entries into a collection. Something like ‘measurement_grouper’ or ‘observation_grouper’. You could put a GUID in the rows you want to be able to make into a ‘panel’, ‘collection’ or ‘row’.

If you are a relational purist this would all be done in a two separate tables OBSERVATION_GROUP and OBSERVATION_GROUP_OBSERVATION and MEASUREMENT_GROUP and MEASUREMENT_GROUP_MEASUREMENT. This would be more in line with the proposal’s MEASUREMENT_ATTRIBUTE table (which I think is a confusing name since it is grouping attributes together).

(Karthik) #29

I’m still trying to understand polymorphically pairing :slight_smile:, but I think I get it. I do agree we need to keep a standard naming convention for these references. I’m not opposed to an additional column in the measurement table that’s either a GUID or a reference measurement id. From a query point of view, I suppose it would be a self-join on the measurement table, which somewhat similar to joining to a new measurement_attribute or measurement group table. If you go the route as mention by @mgurley and @Christian_Reich, we would also need to introduce the specimen_id field into the measurement table, which is a needed in my opinion.