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…
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).
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
condition_status_concept_id = what the data represents, what “type” or status of diagnosis
(i.e. admitting diagnosis, primary diagnosis, problem list diagnosis,
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:
secondary (or “supplemental” if we want to prevent users from thinking “secondary” = “dx2”)
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 ?