OHDSI Home | Forums | Wiki | Github

Condition being treated by procedure

Implementers
#1

Hi all,

We are looking for insights from other implements about how you are capturing the provenance or meaning (condition_type_concept_id) of cconditions that are explicitly documented in your EHR as being the focus of a specific procedure.

We are pulling data from a professional billing file that contains up to 6 diagnosis codes for each procedure billed - one primary condition and up to 5 additional secondary conditions. We originally used ‘primary diagnosis’ and ‘secondary diagnosis’ as condition_type_concept_ids, but this isn’t accurate. These conditions are not primary or secondary encounter diagnosis, but rather primary and secondary targets of a procedure.

What are folks’ thoughts about a concept similar to:
32892 OMOP4976962 Condition to be diagnosed by procedure

Perhaps something like:
XXXX OMOPXXXXXX Condition treated | targeted by procedure

We believe its important to include these conditions in the CONDITION_OCCURRENCE table, as we’re finding that there are conditions captured discretely in this table that are not captured in any of the other diagnosis tables in our system.

Thanks in advance for any insight you may have,
Piper

#2

Hi @piper ,

When you say:

Do you mean a condition diagnosed by a procedure? Example: the procedure is an exploratory abdominal laproscropy which diagnoses endometriosis.

Or the procedure is used to treat a specific condition? Example: Appendectomy for Appendicitis

I think you are mixing up condition_type_concept_id and condition_status_concept_id. The former represents the provenance of a record and the later represents the “point during the visit the diagnosis was given”.

#3

@MPhilofsky,
Yes, I misspoke. I am referring to condition_status_concept_id.
Is there value in addiing a new standard concept as follows:
XXXX OMOPXXXXXX Condition treated or targeted by procedure.

Best,
Piper

#4

Expanding the definition of the condition_stat_concept_id, will be a repeat of the problem we had with the condition type. The condition type started of as referring to provenance but then started to morph into a qualifier for the diagnosis itself. So that we had to have two separate columns, one for provenance and the other to qualify the diagnosis. Your suggestion seems to lead toward using the condition_status_concept_id for more than one meaning.
Not to argue with your desire to have a relationship between the condition and procedure, but with your proposed solution. Maybe adding columns, like there are in Measurement and Observation that can reference another table/record, to Procedure Occurrence will meet your needs.

#5

In addition to Don’s suggestions, you can also use the Fact Relationship table to link the Procedure record and Condition Occurrence record.

#6

Thanks for this response @Dtorok!

Can you tell me more about this solution?

I was thinking we’d use the FACT_RELATIONSHIP table to relate the procedure to the condition, and was worrying more about how to clearly distinguish conditions in the condition_occurrence table that represent conditions being treated by a specific procedure from those conditions captured in other data sources.

The concept we’re looking really does describe the provenance of the data (i.e., a table that enumerates the condition for which the procedure was performed) as much as the ‘status’ of the condition (i.e., that the condition is the specific target or reason for performing a specific intervention)

We suspect there are several ways to achive the same goal, but would like to follow whatever best practices the community has identified.

Thank you!

Piper

#7

@Dtork,

And now that we’re looking at condition_status_concept_id, we’re wondering whether there may be some duplicate concepts in here (or am I not grasping an intended nuanced distinction)? :

Possibile synonyms

  • Cause of death
  • Death diagnosis
  • Immediate cause of death

Possible synonyms

  • Contributory cause of death
  • Underlying cause of death

Thanks,
Piper

#8

You are not going to find a “best practice or standard OHDSI means” for how to clearly distinguish conditions in the condition_occurrence table that represent conditions being treated by a specific procedure from those conditions captured in other data sources. Because that is not a feature the CDM is designed to track.
The best practice when implementing a custom, site specific feature is to not break the conventions of the OHDSI CDM to accomplish your goal. Example of breaking the CDM is to put information into an existing table column that does not follow documented conventions. Don’t try to bend the rules (coming up with creative definitions for existing concepts) to fit your needs. It may be counter-intuitive, but adding your own tables or columns to an existing CDM table will not break the CDM contract. The additional table or columns will just be ignored by the standard tools. So if you want to distinguish conditions in the condition_occurrence table that represent conditions being treated by a specific procedure add a new column to indicate that.

A question about relationships linking a drug to its adverse reaction
#9

@piper:

You know this is coming: What is the use case? What research question do you want to answer with this connection?

But let’s assume you have a use case: folks often would like to have the indication for a procedure (or for a drug). It actually doesn’t work well. There are many procedures who have no indication, because they are diagnostic. The condition is the result of such procedure, not the cause. Likewise, many procedures and drugs have no clear indication. For example, when the doctor prescribes a sleeping pill - that could be against anxiety, insomnia, exhaustion, or - very often - because the patient is addicted and invents all sorts of reasons why it is needed. Or a mix of everything. So, the value of those cross-links is dubious at best.

Therefore, as @DTorok said, the OMOP CDM is not designed to capture these cross-links. Why not? Because they are the result of the research, not the input. Bottom line: You actually don’t want this thing. :slight_smile:

#10

Absolutely agree with not breaking the CDM. :flushed:

The source EHR is Epic, so we I imagine there must be other sites who have solved this.

I’m wondering how (if?) other Epic sites are loading procedures and conditions capture in ARPB_TRANSACTIONS (professional billing data)?

We originally created the ETLs as follows for these data:

condition_concept_type_id

  • OMOP4976894 EHR billing record

concept_status_id

  • OMOP4976978 Secondary diagnosis (conditions captured in fields DX_[X]_ID, [X]=TWO, THREE, FOUR, FIVE or SIX)
  • OMOP4976972 Primary diagnosis (conditions captured in field PRIMARY_DX_ID)

However, now questioning if these values are accurate, as I’m assuming that:

  • Primary diagnosis means primary encounter diagnosis
  • Secondiary diagnosis means secondary encounter diagnosis

The conditions we are loading from this table are not encounter diagnoses, they are conditions the provider is treating with the procedure captured in this particular billing file.

There are conditions in this source table such as “nausea” captured as PRIMARY_DX_ID not b/c they are primary encounter diagnosis, but b/c they are the primary target of a specific intervention. And the many cases where the same condition for the same person, encounter, provider is captured as both primary and secondary - depending on the procedure record in which it occurs.

Is there value in finding a way to represent this using a standard omop concept and standard attribute of condition? This is a something represented in all Epic instances, so I don’t think this is unique to our site.

Best,
Piper

#11

@Christian_Reich,
Yep, knew that was coming. :wink:

One use case is to understand how many and what kinds of conditions are never captured discretely as encounter diagnoses, but are identified as targets of procedures in procedure billing files.

Althought honestly, the reason for the question is primarily to make sure we are capturing all conditions and procedured documented in the EHR and identifying as accurately and precisely as possible the provenance and other important attributes of these data.

Piper

#12

The HealthCare Workgroup has a number of attendees that have ETL’ed Epic. Or you can go to the Epic Web to ask how others have handled their ETL’s.

Primary and secondary diagnosis really came from the claims world, where there was a designated primary diagnosis and then a place to list additional diagnoses on the claims form. Since as you point out primary and secondary adjectives are applied to the same diagnosis in the source data, I would not worry so much about being that specific in your OMOP CDM.

#13

Well, for a researcher knowing that drugD prescribed to treat conditionC is really good.
Similarly procedureP performed to treat conditionC.

There are past efforts to mine these associations from the EHR.
If a source system is giving this as entered by clinician or coder, that can be useful.

#14

I’m going to push back on this sentiment at 2 levels:

1: if you’re doing a safety study on drug X, does it make sense to ignore drug exposures of X if they aren’t described as treating Z? Put another way: does the drug behave differently based on how the doctor intended it to be used for?

2: Does the statement of ‘Administering drug X to treat Z’ really imply the person has Z? For example, you administer drug X as a prophylaxes for DVT post surgery. You’re trying to prevent DVT, the person doesn’t have it…so how do you distinguish the prevention of disease as treatment vs. a treatment for an existing disease. In CDM terms, you’d have a separate diagnosis of condition on or prior to exposure as one way to establish that the drug was used to treat an existing condition.

#15

Agree @Vojtech_Huser!

#16

@Chris_Knoll, I guess with two distinct concepts: one for prevention/prophylaxis and another for treatment.

Since those kinds of concepts qualify the relationship beween the condition and the procedure or drug, those seem to belong in the FACT_RELATIONSHIP table.

I agree with what you’re saying about also needing to qualify condition_occurrence record to indicate that the condition is not an active condition, but a condition the drug or procedure is designed to prevent.

As @DTorok said perviously, there isn’t an attribute to accomodate this particular kind of “condition status” (at-risk-for condition, condition being treated, condition not being treated) in the condition_occurrence table.

Piper

#17

@MPhilofsky, could you take a look at the concepts highlighted in yellow. These strike me as not really representing the “point during the visit when the diagnosis was given”.

image
image1647×601 49.4 KB

I’m wondering if the concept “Qualifier for type of diagnosis” that I’m seeing in SNOMED might be what we’re trying to capture with condition_status_concept_id ? Or is the goal to intentionally capture something narrower?

image
image1027×583 20.8 KB

Thanks in advance for your insights,
Piper

#18

I hate doing this and raining on your research ideas, @piper, but one last time:

  • There are conditions upstream and downstream of a procedure or other intervention. Upstream are indications (therapeutic interventions) and reasons (diagnostic interventions), downstream are outcomes (therapeutic interventions, which could be absence thereof in case of prevention) and diagnoses (diagnostic interventions).
  • Upstream conditions, which is what you seem interested in, have to be used as justification for a reimbursement claim for the procedure. The payers are the ones to define the rules which procedure is ok to claim based on some indication or reason. If there is more than one procedure only the most expensive can be claimed, and there are tons of rules what things you cannot combine. So, no way you can expect this to be exhaustive. The EHR systems do not require any justification other than to support the claim process. But if something is not claimed the doctors will not justify what they are doing - to whom? Themselves?
  • Downstream conditions, predominantly studied in OHDSI, are only declared for diagnostic procedures. Only in clinical trials you explicitly assign an outcome to a therapeutic intervention, and even that is tentative in most cases - nobody knows if the vomiting of an individual patient is due to the drug or something else. We use population-based studies to calculate a probability or risk for that - in the population. For prevention, it becomes ridiculous. For example, an antihypertensive drug or a bariatric surgery will prevent so many bad outcomes that the physician will never list them out.

Bottom line: I understand very well the desire. But neither will you have the data, nor can you have the data, at least in a reasonably comprehensive form to be able to ask the question if is something missing.

They are usually identical. An encounter tends to happen for conducting a procedure, and you justify the procedure with diagnostic codes. Remember: The doc is not paid for the encounter but for the procedure. That is for fee for service. In the institutional claims you don’t have any of this resolution anyway. In the EHRs there is no system for justification (except for claims generation). The physician states things and does things, no questions asked.

Very laudable, but as @Chris_Knoll said: The procedure or drug doesn’t care how it was justified. It will have an outcome. The OHDSI machine is designed to derive that relationship.

With respect to studying the association between indications and interventions: this is notoriously hard, and we don’t have a good solution. And, it really isn’t about the patient, it is about the healthcare system - is there over treatment or under treatment?. OMOP is patient-centric.

Yes. Except it is wishy washy in SNOMED. For example, “Condition to be diagnosed by procedure” - is this the problem that led to the diagnostic procedure or the result of the diagnostic procedure?

#19

Oops, I accidentally didn’t copy the whole definition for condition_status_concept_id. Sorry! Here it is: “This concept represents the point during the visit the diagnosis was given (admitting diagnosis, final diagnosis), whether the diagnosis was determined due to laboratory findings, if the diagnosis was exclusionary, or if it was a preliminary diagnosis, among others.”

Every record in the Condition Occurrence table should be a diagnosis. The person has this Condition. Except for a very small list of concept_ids (example: non-smoker), we don’t keep the things which didn’t happen in the CDM since there isn’t a way to distinguish the Condition or Visit record which didn’t happen from the record which is a true reflection of the patient experience.

#20

Anything that sounds like a research idea is just a hypothethical use case in response to the question “what’s the use case?” :wink:

My goal is simpler and more concrete - I just want to make sure the data we’re bringing into OMOP are represented as completely, precisely, and accurately as possible. I don’t want to mis-represent the meaning of data we have in the EHR and I don’t want to leave it out because there is no way to accurately represent it in omop.

Circling back to the question of whether some version of “condition that is focus of procedure” might be a valid condition status - in the same way that “condition to be diagnosed by procedure” is a valid status: - can you help me understand what it is about this concept that prevents it from meeting the criteria @MPhilofsky cited:

Thank you (!!), @Christian_Reich, @DTorok, and @MPhilofsky for your patience as I try to wrap my brain around the nuances here. I want to make sure I get this right. :thinking:

Piper

1 Like
t