OHDSI Home | Forums | Wiki | Github

Concept Type consolidation - please take a look

CDM Builders
#1

Friends:

This is a proposal for the the long-awaited consolidation of Type Concepts. Right now, Type Concepts are organized by Domain, creating a ton of duplications, and they are a wild mixture of provenance and categorization (really “type”) indicators. Also, some of them are badly pre-coordinated and many are not intelligible if you don’t know the US reimbursement claims system.

This is a proposal to fix all that:

  • Type Concepts now really indicate provenance. We should rename them to “Provenance Concepts”, but that would be too much of a change - almost all use cases and tools would have to be refactored. So, my proposal is to bite the bullet and keep calling them “Type Concepts”.

  • All Concepts are now called in such a way that they can finish the sentence “This record was obtained from a …”. So, Concepts like “Inferred from procedure claim” is being renamed to “Claim” - they all are inferred, and there is no such a thing as a procedure claim.

  • Era 0 day persistence window records were dropped like in 2010. We don’t need that anymore.

  • Medical claims are now Inpatient, Outpatient, Facility and Professional claims. Non-medical are pharmacy, vision and dental.

  • Type concepts have a simple hierarchy. So, all of the above claims are descendants of “Claim”. The hierarchy is single-parent.

  • Instead of the 338 records we have now 63:

    image
    image694×408 131 KB

  • All positions on the various claims forms, which often are used to distinguish between primary (the condition the encounter is about) and the many subsequent positions go to a single “secondary” Concept in the CONDITION_STATUS_CONCEPT_ID. All death-related Type Concepts also are stripped to the actual provenance, and the death becomes a status in Condition Status; which will be released in a subsequent Forum post.

  • Condition Procedure, Primary Procedure and Secondary Procedure are not Type Concepts. They are Domain assignments.

The following table shows the current Type concepts, and what they are mapped to, and their hierarchy.

Please take a look and critique.

4 Likes
Primary dx vs Secondary dx
REDCap data to OMOP-CDM
Many domain="Type Concept" stoped being standard. What to do?
Procedure Status
Drug_type_concept_id values from drug exposure table, what do they represent? Is there overlap?
Questions about Type_concept_ids
Important vocabulary release: Type Concept and Condition Status
Analyzing visits : variations by source
How to search the codes of dispensed in the inpatient office and in the emergency office?
How to populate _concept_id fields in CDM Note table?
Measurement_type_concept_id for lab results
CPT4 and HCPCS Procedure Modifiers
Questions about book exercises ch. 4 and 5
Type concept conventions
#2

I should probably explain the spreadsheet:

Columns A and B are the current Type Concepts, column C their Domain assignment (and also VOCABULARY_ID). Column D are the new Domain-free Type Concepts they would be mapped to, column E their parents and column F the grandparents.

1 Like
#3

In US medical claim, there is professional claim (filed for services by a person/provider/human e.g… CMS 1500) and facility claim (filed for services by an organisation/institute/not human e.g… UB04). Based on where these services are rendered, they may then be inpatient, outpatient, etc. - the later (inpatient, outpatient) is not provenance of data, but TYPE of service. Each of these medical claim may have a one claim header (= visit_occurrence), and many claim detail (= visit_detail) records. For US claims, we can propose conventions on concepts allowed to populate visit_type_concept_id and visit_detail_type_concept_id.

We will not have solved the type concepts in other domain tables. Each visit_* record may have multiple condition_* , procesure_* records that have their own *_type_concept_id (condition_type_concept_id, procedure_type_concept_id etc.). What provenance concepts should be allowed here?

Then there are non medical claims - e.g. pharmacy. They are claims, but from provenance standpoint may be considered non medical.

#4

Thanks for the summary, @Gowtham_Rao, but are you agreeing with me or disagreeing? I cannot decipher from your post.

#5

Thank you @christian_reich . I am actually not sure what to recommend. If we are trying to capture only provenance - then ‘Outpatient claim’ is probably incorrect.

Outpatient is a place of service/type of bill (visit_concept_id). Facility claim or professional claim is truly the provenance (visit_type_concept_id)

Another thought, how do at take US specific provenance and standardize them? we don’t have _source_type_concept_id vs. _type_concept_id fields

1 Like
#6

Looks good! A few comments about Death:

I have seen death recorded in the EHR in 5 different ways. A Person has a date in a “death date” column, a Person’s status = “expired, deceased or dead”, a Person has a “cause of death” value, a Person has a discharge status = “expired, deceased or dead” or a Person has a discharge to = “morgue”. With the death now being recorded in the Person table, maybe there should be a death_type_concept_id column in the Person table? It’s the logical spot for the provenance of the death record. All the “causes of death” would still belong to their respective domains.

#7

How will ETL record a ‘Primary’ Condition or Procedure?

I think Header and Detail are an artifacts of Truven. Remove Professional Claim Detail and Header and just have Professional Claim. Similar for Facility Claim, remove ‘Facility Claim Header’.

Are the prefixes ‘Inpatient’ and ‘Outpatient’ on ‘Claim’ necessary? Know it an inpatient or outpatient event from the visit.

By my count then there would be: Professional; Facility; Pharmacy; and just plain ‘Claim’ claims.

#8

That would be a lossy coversion. The line level links procedure to diagnosis at line level. Otherwise, we will have an array of procedures and conditions for a claim. Line links each procedure and condition together within the array.

1 Like
#9

I do not understand how you use type Claim header vs Claim detail to group events. Can you give an example of how not having header or detail will affect an analysis.

#10

I know. Is there another way to call it? I don’t like the “outpatient”, either. The idea is not to declare that the visit is Outpatient, but the claim is through the system that small offices use. Any idea?

#11

Wait. It will be in the CONDITION_STATUS_CONCEPT_ID. Is that not good?

#12

I like it, if we can agree with it.

And we need this for Visit or for Cost, @Gowtham_Rao?

#13

Both. If we want to know what condition/diagnosis justified a procedure code (e.g. an expensive laboratory test was ordered as a procedure to evaluate breast cancer). Claim lines capture that relationship/linkage.

#14

If we are strictly referring to provenance - then for US medical claims, there may be two types of children (professional and facility). These may have more children based on adjudication system (pre-adjudicated, post-adjudicated complete, post-adjudicated deferred, post-adjudicated denied).

#15

@Gowtham_Rao I understand your need to link a condition with a procedure, but do not understand how you do this using the _type_concept_id. Would having the condition and procedure belonging to the same visit_detail record accomplish this?

#16

Not every Death has an associated Condition record. Sometimes there is only a death date.

#17

Yes!

#18

Argh. I see. Should we enforce people to also write a CONDITION_OCCURRENCE records of death? And then we don’t need to add another field?

#19

I can verify this. As a FQHC network, it would be extremely rare for us to have the cause or condition of death. Many times we do not even get the date of the death, we only get a notification that the patient has expired.

#20

I see. That sounds like we need to write a Concept of Death the day we decide the patient died, and add a QA to check that date against the PERSON table.

t