Thanks, @rimma. I think you are straight on. Plus this is a Themis issue we need to fix anyway. As a solution, we could precoordinate Admitting, Preliminary and Final with first, second, third, seventeenth. Much better than the current precoordination between Visit and provenance. Will put something out soon.
In claims data, is there a value or use case for knowing if a secondary diagnosis is in the fifth position or fifteenth position? I don’t know of any.
Why cannot we put Primary/Secondary into condition_type_concept_id? This the place where it supposed to be stored. Then put preliminary/discharge into condition_status_concept_id. In this way we don’t need to create any precoordinated concepts.
“Admitting, Preliminary, or Final/Discharge. This is also an important indicator, but I am not sure how widely it is used.” we use it everywhere 
Agree with Gowtham, don’t see how knowing if it’s fifth or tenth position will make the difference.
1 Like
@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).
1 Like
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.
- EHR - problem list, chief complaint, referral, observation, diagnostic test, billing diagnosis, encounter diagnosis
- Claim - header, detail
- Billing
condition_status_concept_id: When the diagnosis in the process of healthcare was derived (Rimma’s proposal):
- Admitting diagnosis: 4203942
- Final or discharge diagnosis: 4230359
- Preliminary diagnosis: 4033240
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
2 Likes
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:
- 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
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:
- 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.