OHDSI Home | Forums | Wiki | Github

Alternative to v6.0 deprecation of cdm.drug_exposure.stop_reason column

Hi, as we have seen, the v6.0 version deprecates the stop_reason column from the drug_exposure domain. Which is the alternative proposed to store the reason for discontinuation?

1 Like

@oriol.moles:

None. Nobody has data for that. But right now the active version is 5.4, so if you have data feel free to use it and show us your use cases.

Hi Christian,

Thank you for your response and for providing context on the current version status. Let me give you some context, I’m with IOMED, a company specializing in NLP-driven healthcare insights (link: Home). We’ve developed NLP models capable of extracting detailed insights from clinical notes, including discerning whether a drug has been suspended or if treatment is ongoing.

Previously, we relied on the stop_reason column to store discontinuation reasons using internal concept_ids like “Suspension due to unknown reasons” or “Suspension of treatment due to adverse effect” even though it was not a perfect solution for us. However, with its deprecation in v6.0, we’re exploring alternatives.

Given our NLP capabilities, could we be the ones to propose it? We’ve devised a method that enhances our understanding of drug discontinuation and would appreciate guidance on integrating it effectively, possibly through collaboration within the relevant working group and submitting a pull request to the repository.

Looking forward to your insights.

Best regards,
Oriol Moles

No worries, @oriol.moles. Version 6 is dead. Version 5.4 is alive and kicking, and unless use cases push us into the moving forward (probably to 6.1) you are safe. Your use cases will help preserve it when that happen.

That is what we call “flavor of null”. You must not store that at all. If we don’t know something we don’t have a record.

That’s better, but use cases for the OMOP CDM try to find these, not to have them as input. At the end of the day it is not possible to know if something is an adverse effect. Only statistics of a population can tell us if there is a risk.

What other concepts do you have?

Let me illustrate each concept with an example commonly found in hospital records.

Suspension due to unknown reasons:

Hospital note: We are stopping the mesalazine treatment.

Our models indicate that the patient was previously prescribed mesalazine, but the treatment was suspended without a specified reason.

Suspension of treatment due to adverse effect:

Hospital note: The patient stopped mesalazine due to nausea.

In this instance, our models reveal that the patient ceased taking mesalazine due to experiencing nausea, which is categorized as an adverse effect.


We think that these basic examples emphasize the necessity of including a cause-of-discontinuation column, significantly enhancing data comprehensiveness.

Is there a forum or working group where we could propose a modification to the current stop_reason column to enable more efficient storage of these use cases?

All you need to do is to fix the drug_exposure_end_date. There is no reason, and if there is no reason, we don’t write a record (rather than saying “no reason”).

There is a reason given here, but its value for our use cases is low: Whether or not the nausea is due to the drug or something else - neither the patient nor the doctor knows. It’s a guess. Since we are not treating the patient we have no say in whether or not to stop the drug. But what we can do is to calculate whether patients on mesalazine are more likely to experience nausea than some control group. Which means, it is the outcome of the research, not the input.

Bottom line: Write Nausea into CONDITION_OCCURRENCE at the date the drug was stopped and be done with it. Feel free to add it as a stop reason, but probably nobody will ever pick it up for reasearch.

Don’t you think that fixing the drug_exposure_end_date column does not represent the meaning of the note? What we can understand from it is that, at some point, the decision to stop the treatment was taken, but it does not specify when the action was applied.

Oh. Well, that is up to you and your knowledge of the source. Typically, if the decision to stop a medication is taken it takes effect immediately. Why keep the patient nauseous? There are other drugs than mesalazine.

That’s the point, our input here is that rather than making a suposition on the end date, storing the stop reason gives us a more accurate solution and represents better the clinical information that we were provided with. Don’t you think?

Well, put yourself into the shoes not of the ETLer shoving data somewhere, but of the analyst, who has to design and execute an analytic.

The idea of the OMOP CDM, and the expectation of the analyst, is data representing the medical facts, not some intentions of some doctors. And there are two facts: (i) the patient was on mesalazine, and (ii) the patient experienced nausea. You should capture as best as you can the timing (and drug dose) of these facts. If you cannot, leave it empty. The analyst can take it from there.

1 Like

Well, it seems we have different points of view on this matter.

If the medical note resembled something along the lines of:
The patient was on mesalazine. The patient experienced nausea. The patient stopped taking mesalazine

I would have accepted your interpretation and implemented it accordingly, but thats not the case. Hence, I interpret the third point (iii) the patient stopped taking mesalazine due to experiencing nausea.

Ultimately, this data is valuable, and I believe it’s fair to retain it. Understanding real-world instances such as patients discontinuing mesalazine treatment due to nausea can provide significant insights from an analytical standpoint, particularly in the context of retrospective observational studies.

Thank you for sharing your perspective on the matter. We will continue using the column, considering that, as you noted Version 6 is dead. Version 5.4 is alive and kicking.

t