OHDSI Home | Forums | Wiki | Github

Disentangling Condition Types

CDM Builders
#1

We should talk about the other Condition Types. They are ugly. We have these Inpatient detail, Inpatient header, Outpatient detail, Outpatient header and Carrier claim header permuted with primary, and then 1st -15th position. Isn’t Inpatient and Outpatient something that doesn’t belong to a Condition, but to a definition of a visit? What is a Carrier Claim? Why not just turning them into “Primary diagnosis stated on claim”, “1st diagnosis stated on claim”, “2nd diagnosis stated on claim”?

It’s open now.

This one. Any good ideas?

New type_concept_id for suspicious conditions
#2

The anchor is obviously is a record in visit_occurrence. The visit record in visit_occirrence represents whether it is inpatient, outpatient, etc. The record has enough information in OMOP standard visit concept form and source-visit-types (using visit_type_concept_id, visit_source_concept_id etc). All other clinical tables like observation, condition, measurement are linked/anchored to visit_occcurrence. So carrying this information to these clinical tables is redundant and inefficient, IMO. So I see value in “disentangling” and removing inpatient, outpatient etc. for not just condition, but also procedure, observation, measurement etc.

I don’t see a reason for “stated on claim” because, I think, visit_type_concept_id should say if the data came from claim, or EHR or other.

For US claims codes: Position is important, especially primary vs secondary vs admitting, or 1st, 2nd, 3rd, 4th position till at least 25 to 30 etc. This is generalizable to condition, procedure, observation, measurement etc. So we can create generalized concept id to represent all these. However, also important is whether the source is a claim summary (header) vs claim detail (line) vs claim other (unknown). So this makes it a composite of these two attributes - position and claim source. I.e. concept id for claim-summary-primary-position, claim-detail-primary-position, claim-summary-13th-position etc.

#3

What we are doing is simply to add a sequence number (new column) and use the “type concept id” for what the condition is (problem list, diagnosis, admitting diagnosis, primary diagnosis, etc.) So, if a sequence number is present (diagnosis 12, for example), it can go in the sequence number column, and there is no limit to the number of them.

#4

just to be clear, the sequence number (12 in the example above) goes in the sequence number column, not the code

#5

@TBanokina,
@IYabbarova
Some day you were asking about these Condition Types, please follow the this conversation.

#6

@Gowtham_Rao let me explain why we are using “inpatient”, “outpatient”, and “carrier” designations in these type fields. OHDSI likes to combine multiple claims into one visit_occurrence_id. A common example is combining all of the UB04 and HCFA forms related to a patient’s inpatient admission into one visit_occurrence_id. This causes a problem when trying to identify if a condition was associated with the hospital’s claim or the physician’s claim. Therefore, we started using the “inpatient” (for inpatient UB04 claims), “outpatient” (outpatient UB04 claims), and “carrier” (physician HCFA claims) designations to represent the provenance of the condition. So I do think we need to indicate the provenance of these codes since multiple claims can be represented in one visit_occurrence_id. I’m open to renaming the type_concept_ids to better represent the provenance and not get users confused with place of service codes.

#7

@jenniferduryea:

That’s the first time somebody explained this to me in a succinct manner: You want to characterize the diagnoses, with the rationale of why e.g. a hospitalization happened, and why a certain procedure happened. I get it.

Except we still have to rank the diagnoses. And we have only one field. So we are back to permuting them? Or is there another creative solution?

#8

I think the visit_occurence vs visit_occurrence_era proposal here http://www.ohdsi.org/web/wiki/doku.php?id=documentation:next_cdm:visits_microvisits
may solve the provenance issue that @jenniferdureya and I are experiencing. It’s absolutely important for some use cases to not combine records (_era like) during ETL. That proposal will help retain information with 1:1 lineage/ provenance and allow to not mix the different claims. If we accept the proposal, then we don’t need in inpt, outpatient, carrier claim ec to be cobbled and can be disentangled.

We will only need rank and whether it in detail vs summary.

#9

condition types are in our source data - but I don’t think any of the R packages support restricting to only consider conditions of certain type. (I could be wrong).

Similarly do we have phenotypes in Atlas public server that restrict phenotype definition by condition type?

EDIT: Yes we do:

image.png1148×386 23 KB

#10

I created one: http://www.ohdsi.org/web/atlas/#/cohortdefinition/919585

-Chris

1 Like
t