OHDSI Home | Forums | Wiki | Github

The result with fact_relationship table for antibiotics sensitivity test

Hi, all

We convert the result of culture test and antibiotics sensitivity test in EMR to CDM with fact_relationship table.

However, we recognize difference between the number of patient in Atlas and the number of patient as a result of sql query with fact_relationship.

In Atlas, we made a condition as follow

Do you have any idea to get the result which is the same to the result from sql with fact_relationship, in Atlas?

Thank you in advance

Aelan Park

Please give me advice @Christian_Reich ~~

Aelan Park

I don’t think Atlas uses the FACT_RELATIONSHIP table. So, your cohort collects all patients with a positive urine culture who also had a antibiogram with clindamycin. But the two are not connected.

@Chris_Knoll knows better what we put into ATLAS.

It’s not in Atlas, usually we get a concrete implementation of a query that uses this type of CDM structure before we can standardize it into something like CIRCE criteria objects. Anyone who has used these tables in actual analytic work should share those queries, and we may be able to identify a generic approach for implementation that satisfies most or all of those cases.

This is how we’ve managed things like Datasources (drived from Achilles functionality) Chaaracterization (derived from cohort ‘generate with features’ functionality), and Pathways (derived from prior proof of concept work I developed back in 2013).

So, the fastest way to get things implemented in atlas is to produce a proof-of-concept that demonstrates the method, and then we work on folding it into our current tools.

@Chris_Knoll: Thiat works. Here is what we need to do: We need to do our homework and specify how these triplets are going to be handled (right now we have the use cases antibiogram for positive culture and allergy testing) and when that’s done and we have data we hand over to you?

Yes, at the minimum, a concrete implementation in CDM-sql that demonstrates the method.

Better: a small sample dataset (including a custom vocabulary, person-level data and test SQL statements with expected outputs) that we can use to create the test cases that we’re trying to attach to all of our new development efforts.

While test cases are an optional item for delivery to the dev team to work on, it won’t make it into a complete release without at least some test cases that demonstrate the expected results. Would be faster if people defining the functionality provide those specifications, but in absence of it, we’ll make up our own test cases (which will take more time).

t