| OHDSI Home | Forums | Wiki | Github |
@Gowtham_Rao – I have never seen any one who cares about the specific number, other than first.
It would be good to make a list of all of the diagnosis code flavors and address it. I would be careful about using the word “primary” in place of “first”. Sometimes first is taken to mean primary. Sometimes there is a primary or admitting or present on arrival indicator. Sometimes first is meaningless (as in physician claims).
As part of clean up, for condition_type_concept_id what if we make primary, secondary, admitting as the three main types of condition_types. Rest are either not standard or descendants?
Hmmm… I’m not sure deprecation will work. For example, we have things like Pre-op diagnosis and Post-op diagnosis, which people actually want to use, so we need to save them. On the other hand, Pre-op diagnosis can be a child of both admitting and preliminary diag-s, which makes the hierarchy useless.
So, we can probably solve it by adding new recommendations to the existing OMOP spec ( right now we have the following condition_type_concept_id: admitting, preliminary, final ). For example, I suggest adding to this list postmortem/death/pathology (whatever you want to call it) diagnosis.
Status clean up:
looks something like this: https://docs.google.com/spreadsheets/d/1BhypdwPKRKNo-bZvrPmlx1pOtK9SSYXK1knPmTYFAco/edit?usp=sharing
This conversation has taken many different paths. Just to clarify, that data I have is EHR data. We have the provenance of encounter diagnosis, which is the diagnosis code the provider gives to a patient and billing (not claims) diagnosis, the diagnosis code the hospital uses to bill the insurance company. Both designations are important and are currently in the condition_type_concept_id column. But, we also need to know if this is the Primary diagnosis or a secondary diagnosis. The primary/secondary data also lives in the condition_type_concept_id column. How do we represent a primary, encounter diagnosis when only one concept is allowed in the condition_type_concept_id column?
@mphilofsky what is the difference between encounter diagnosis and billing diagnosis? Are they from two different systems? Is the content the same or different?
Yeah, it’s confusing. Here is what is on the table.
condition_type_concept_id: where the record was taken from.
condition_status_concept_id: When the diagnosis in the process of healthcare was derived (Rimma’s proposal):
Now we need to bake the primary, first, second … 34th into it. What’s the difference between first and primary?
Somebody at some point said we only need primary, first, second-and-all-others. We could permute these with the 3 above and be done.
Inpatient and outpatient should not be here at all. That’s in the VISIT.
Thoughts?
Actually @Christian_Reich did not answer @Gowtham_Rao’s original question: “What is the difference between encounter diagnosis and billing diagnosis?” The encounter diagnosis is what is entered by the physician at the end of a face-to-face encounter (visit) with a patient. The billing diagnosis is what a billing coder assigns to that same interaction. The physician attempts to provide the most relevant CLINICAL diagnosis. The billing coders use specific billing rules and procedures to assign the correct billing code. While these two may be the same, this is not always the case as billing rules may require that the coder assigns a different billing diagnosis than the clinician assigned as the encounter diagnosis.
The difference from a research perspective is that billing diagnoses may be more homogeneous since billing coders are trained to use a specific set of rules for assigning the billing code. But an encounter diagnosis may be a more accurate reflection of the key clinical concern during a visit.
And folks wonder why the medical care system in the US (and similar in other countries) is so screwed up…
Michael Kahn
I see. will add “Encounter diagnosis”. Makes sense.
Thank you @mgkahn
Based on the description of the difference between encounter and billing, the two systems may have different primary diagnosis codes . Did we have a convention that we should have only one primary diagnosis per visit ? I don’t think we do, but it makes sense.
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:
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
and
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:
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.
To answer @Christian_Reich’s question:
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:
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.
I’m not sure what the resolution to this is.
And I’m not sure what @aostropolets means when she says “precoordinated concepts”.
Sounds like we need a meeting.
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.