I know we have deviated from the thread header (“Primary dx vs Secondary dx”) but as long as we have started down the rabbit how of “How many different types of diagnoses are there that have potential analytics value (channeling Patrick here)”, I thought I would enumerate some additional diagnoses to consider. Other folks may want to add (or remove) from this list:
Reason for visit. Often used in emergency visits and (in our setting) a wildly uncontrolled terminology.
Pre-operative diagnos(es) – what the surgeon thought she was dealing with before starting the procedure.
Post-operative diagnos(es) – what the surgeon found after she finished the procedure
Pathology diagnos(es) – if there was any tissue sent from above, what the pathologist found
Others can continue to grow this list as is appropriate to their health care environment.
We would like to distinguish Primary diagnosis from secondary diagnosis.
The primary diagnosis is the root cause of the visit.
The Secondary diagnosis/diagnoses, are the other conditions that were either present on admission & directly affect the care given for this visit or developed as a direct result of the Primary diagnosis.
Use case: Person is admitted with heart and kidney failure. Did the heart failure cause the kidney failure? Or the kidney failure cause the heart failure? The treatment path is very different. Our researchers want the primary diagnosis to study comparative effectiveness of various treatments for a specific primary condition.
Here’s my quick suggestion for condition_type_concept_ids and condition_status_concept_ids
@MPhilofsky How would you put Primary admitting/final and secondary admitting/final diagnosis then? A doctor may put renal disorder as the primary diagnosis when a patient is admitted and then, after labs and examination, decide that the primary cause is hypertension and renal failure is the complication (e.i. secondary diagnosis). We do want to know if it’s final diagnosis or just a preliminary one.
As for me, it looks like 2 options: add a column or create precoordinated concepts (e.g. primary admitting).
Hm. Sounds like exactly what I was proposing. Nobody is listening to meeee!!!
My question is what the difference is between for example 38000183,“Inpatient detail - primary” and 38000184 “Inpatient detail - 1st position”? Does anybody know?
I am! It took a while to admit that we need this precoordination
I don’t, but they look just the same.
Then, if everybody agrees, we can proceed with clean up and new concepts creation. Although we still need to preserve the existing concepts in case some data don’t have the necessary granularity.
Agree with cleanup and precordination. My recommendations
we don’t precordinate visit_concepts in condition_type.
we discourage use of numbered positions for secondary diagnosis. E.g. all numbered condition type are secondary. E.g. we make “inpatient detail - 1st position” a secondary diagnosis (many data sources start counting up secondary diagnosis from position#1, with primary diagnosis and admitting diagnosis having their own separate fields)
We use hierarchy in condition type with primary, secondary being on the top
The above works. We don’t always have the pre-coordinated in our source data, so we need Primary and Secondary as stand alone concepts. And changing the vocabulary is easier/better than modifying the CDM.
What I think may be best and what I was trying to show with my google sheet would be to further define the condition_type_concept_id ad condition_status_concept_id:
condition_type_concept_id = provenance of the data (i.e. EHR
encounter diagnosis, Claims, Death Record, Observation recorded from
EHR, etc.)
condition_status_concept_id = what the data represents, what “type” or status of diagnosis
(i.e. admitting diagnosis, primary diagnosis, problem list diagnosis,
etc.).
Then we would move the Chief Complaint, Patient Self-Reported Condition, and Problem List diagnoses -maybe others- from the condition_type_concept_id field to the condition_status_concept_id field. While separating the provenance of the diagnosis from the status/type of diagnosis works our EHR data, I’m not sure if this would work for other EHR & claims data sources.
I’m looking at the wiki and there is NOT a condition_status_source_concept_id column in the CDM. Standard practice is to have a *_source_concept_id for every *_concept_id and *_source_value field.
These concept_ids specifically created for Janssen’s Truven Marketscan ETL, authored by @ericaVoss. The concept_ids refer to specific tables (i.e. Inpatient Detail) and columns (i.e. “primary” vs. “dx1”) for that specific database. The “inpatient detail - primary” comes from the ICD9 code that is stored in the “inpatient detail” table, column “primary”. “inpatient detail - 1st position” comes from the ICD9 code that is stored in the “inpatient detail” table, column “dx1”. These ICD9 codes can be different and it is important to know the difference. However, these type_concept_ids are not really representative of claims in general - hence the type_concept_ids are very specific to Truven Marketscan. Since these were one of the first type_concept_ids used, users have used these type_concept_ids for variety of things. But, basically, these type_concept_ids are very data source specific, and are not representative of standard claim fields.
I do need to disagree with my my pal @Gowtham_Rao on the following quote:
After reading the description of where these type_concept_ids come from, you will now know that you cannot turn “inpatient detail - 1st position” into a “secondary diagnosis”. This is referring to how Marketscan organizes data. This is not referencing the UB04 fields.
Only claim information coming from facility claims (i.e. UB 04 forms) have “primary” diagnoses. Claim documentation shows that box 67 of the UB04 form is considered the “principle diagnosis” for both inpatient and outpatient facility billing (see sections 10.3 and 10.2 of the Medicare billing manual here) Facility claims can come from inpatient facilities (i.e. acute inpatient admissions from an ER encounter) and outpatient facilities (i.e. cataract surgery) and only these claims have “primary” diagnoses fields. HOWEVER, claim information coming from physician claims (i.e. HCFA 1500 forms) do not have a “primary” diagnosis. They DO have “line diagnoses” which refer to the specific diagnosis the procedure code was paid for. Some claim datasources provide line diagnoses for procedure codes.
So for claims data, I suggest the following condition_types, since these fields are standardized from claims data:
primary
secondary (or “supplemental” if we want to prevent users from thinking “secondary” = “dx2”)
admitting
line diagnosis
I could debate whether to include a “patient reason” type_condition_id since there is a field on the UB04 claim form to store the ICD9/ICD10 code associated with the patient’s reason for visit. But I have never seen any claim dataset available to researchers that provide those codes.
Now there seems to be some confusion as to what is stored in the type_concept_id and what is stored in the status_concept_id.
@Gowtham_Rao suggests type_concept_id should contain information related to position (i.e. primary and secondary).
@MPhilofsky suggests type_concept_id should contain EHR, Claim, and other data source provenance information.
I’m not sure what the resolution to this is.
And I’m not sure what @aostropolets means when she says “precoordinated concepts”.
I’m all for removing any elements of the CDM that are tightly coupled to some source system’s object model. If that’s the origions of Line - 1-12 and others, then those shoudl definitely be cleaned up and we should set the ETL map those source-specific columns into OMOP CDM standardized concepts.
Good post Jennifer. My reasoning is that the condition_occurrence table is linked to visit_occurrence table, and the vo.visit_type_concept_id has the provenance information for the visit record ie. EHR, claim, or other data source visit provenance. So, the condition_type_concept_id does not need visit type information in it. The combination of visit_concept_id, visit_type_concept_id and condition_type_concept_id can say if the condition_occurrence record is a primary diagnosis, inpatient visit, facility claims data.
You are right! Agree with you about the HCFA 1500 forms. Yes, line diagnosis is a better descriptor here. In CMS 1500 form - one claim may have many line with each line having a CPT/HCPCS code. Each of these CPT/HCPCS code may have upto 4 diagnosis codes. But overall there may be 12 diagnosis code total for the claim form.
Right now type_concept_id stores both position detail and provenance detail. So, when we want to preserve both of the attributes we literally don’t have a place for that. Therefore, we need to add a new column, move one of these attributes to a different field, or create concepts that will have position attribute and condition status (again, like primary admitting diagnosis). In this way, we’ll be able to put Encounter/Billing into type_concept_id and these newly created concepts into status_concept_id. Does it help?
Do you know if in OMOP CDM v6, CONDITION_STATUS_CONCEPT_ID can be used for storing an information related to position/type of diagnosis as it was discussed above?
My current issue is where to indicate the detailed type of the diagnosis coming from EHR data. For example, it can be classified into primary diagnosis, secondary diagnosis, diagnosis related to a prescription, diagnosis related to a test and etc.
Should I use CONDITIONT_TYPE_CONCEPT_ID or CONDITION_STATUS_CONCEPT_ID ?
Is there official THEMIS guidance on this that I could reference?
For example, if I had a data set that listed diagnosis positions I would map it the following:
DIAG_POS_1 = 38000184 - Inpatient detail - 1st position
DIAG_POS_2 = 38000185 - Inpatient detail - 2nd position
DIAG_POS_3 = 38000186 - Inpatient detail - 3rd position
This data set didn’t have a specific “primary code” entry so I wouldn’t assert it. However from the conversation above I would think individuals would say DIAG_POS_1 was the 38000183 - Inpatient detail - primary.
The primary etc. designation we are going to move to the condition_status_concept_id. Has nothing to do with the provenance (even though you could formally say that). Will update soon.
Trying to close this out after months and years of having this debate open. How about the following Condition Status. There is a mini-hierarchy in which Admission diagnosis, Referral diagnosis and Discharge diagnosis permuted with Primary and Secondary. There are three Causes of death, which similarly all have Cause of death as the parent.
Condition Status
Status Ancestor
Status Ancestor
Admission diagnosis
Cause of death
Condition to be diagnosed by procedure
Confirmed diagnosis
Contributory cause of death
Cause of death
Discharge diagnosis
Immediate cause of death
Cause of death
Preliminary diagnosis
Preoperative diagnosis
Primary admission diagnosis
Admission diagnosis
Primary diagnosis
Primary diagnosis
Primary discharge diagnosis
Discharge diagnosis
Primary diagnosis
Primary referral diagnosis
Referral diagnosis
Primary diagnosis
Referral diagnosis
Resolved condition
Secondary admission diagnosis
Admission diagnosis
Secondary diagnosis
Secondary diagnosis
Secondary discharge diagnosis
Discharge diagnosis
Secondary diagnosis
Secondary referral diagnosis
Referral diagnosis
Secondary diagnosis
Suspected diagnosis
Underlying cause of death
Cause of death
True, but still: From the instructions: CMS 1500 Field Location 21 “Required Diagnosis or Nature of Illness or Injury” - Enter all letters and/or numbers of the ICD-9-CM code for each diagnosis, including fourth and fifth digits if present. The first diagnosis listed in section 21.1 indicates the primary reason for the service provided.
with my my pal 