We want to distinguish primary diagnosis from secondary diagnoses in our EHR data. The condition_type_concept_id seems like the appropriate place for this data. However, we also distinguish between Encounter vs Billing diagnosis and the data goes into the condition_type_concept_id column. We need both. What do others do?
Add an additional field for primary vs secondary diagnosis.
Can you make encounter and billing as separate visits? Use visit_type_concept_id to differentiate between visits derived from a record in encounter vs billing systems. Use condition_type_concept_id to differentiate between primary vs secondary. The composite of visit_type_concept_id and condition_type_concept_id may give you the level of granularity needed.
It is only one visit. Creating a separate “billing” visit would double the size of the visit table, create two visits for every condition, and require us to link visits via the “ugly” Fact Relationship table.
I think @DTorok’s idea of adding another column. It keeps the solution in line with the data. And will be more useful for our querying purposes.
@DTorok - what did you name the new column?
I would think you want to create 2 separate CDM databases. One for encounter and one for billing. This way, you will avoid double counting. This is particularly true if the procedure also has records from both encounter and billing.
Since it was a non-OMOP column and a special request from a user, we copied the field name and possible values from the source and called it PRIMARY_FLAG with the possible values of Y/N.
According to OMOP conventions, condition_type_concept_id reflects “the source data from which the condition was recorded”. It’s perfect to indicate “Encounter” vs “Billing”. @MPhilofsky.
Primary and secondary diagnoses have been also historically recorded in this field. But I think it is a separate important attribute that indicates diagnosis weight that may grant for a separate field. Agree with @DTorok.
Just for completeness, there is also a relatively new field in this table, condition_status_concept_id, intended to reflect another aspect of diagnosis provenance: Admitting, Preliminary, or Final/Discharge. This is also an important indicator, but I am not sure how widely it is used.
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.