OHDSI Home | Forums | Wiki | Github

Perhaps `condition_end_datetime` should also be mandatory?

CDM Builders
#1

For the move to CDMv6, perhaps condition_end_datetime should be not null as consistent with other tables?

I’ve noticed drug_exposure_end_datetime is mandatory. This is smart since analysis logic doesn’t have the background necessary to easily know when a drug exposure period has ended, besides guessing that it’s the start_datetime plus the days_supply, or failing that, the start_datetime + 1day. In this case, an ETL process could make a better guess, and this guess can be seen in the database itself.

For other tables, end_datetime is also mandatory, except for condition, where it remains nullable. Why? Perhaps a null ending datetime might indicate a condition isn’t yet resolved and is ongoing? But, there’s a challenge with this. Most of the cohort logic that I’ve reviewed is defaulting a missing end_date to start_date + 1day – it is not defaulting to the last day of the observation period. In other words, the cohort logic doesn’t treat the null value as an indeterminate interval ending, as is the treatment in the Clinical Quality Language (CQL). Instead, the default logic (making it equal to start_date +1 day) is applied universally, when other information at the data source might be better equipped to make a more plausible ending value on a case by case basis.

1 Like
#2

@cce:

Very apropos. @clairblacketer, @Patrick_Ryan and I are rewriting the logic behind what is mandatory and needs be inferred, and what isn’t. We also are fixing some mistakes in the documentation.

In your example, you are right: For drugs, it’s easier to infer the duration, for conditions it is not. The reason is that drug duration is anticipated and planned, and the ETL can figure out the way to determine that. While conditions come and go as they please (some are more acute than others, but still). When people heal, they just stop showing up at the healthcare system. There is often little explicit resolution of a condition provided in our data. Usually, conditions are just captured in a moment of time.

The cohorts actually can be specified whether or not the end is based on the start date or the end date of the indexing feature for exactly that reason.

#3

@Christian_Reich It’d be nice to document how a null condition_end_datetime should be treated with various cohort definition use cases, as a cross reference. For the most part, I’ve only run across end_date = start_date + 1day in CDM5 SQL cohort logic. Regardless, for the limited cohort SQL that I examined, the inclusion logic seems to be driven only from the start_date (aka index date) and not this calculated end_date. Are there public examples of cohorts where the end_date of a condition is relevant to the query logic?

1 Like
#4

Hi @Christian_Reich
Since conditions are just captured in a moment, when and how should we fill the STOP_REASON field for inpatients or outpatients?

Looking forward for your response!

#5

@qiongwang In most cases, you do not have a stop reason for the condition. You only fill it in if your data has this information. The field is not require so if you do not have this information, don’t fill it in.

#6

Thank you!

#7

Because that’s how Condition data get captured. Essentially, they are snapshots. When the patient comes in with a problem, or when the diagnosis is conducted, or when the treatment commences, the Condition information is provided. But both provider and patient notoriously fail to tell the system that things have gotten better. They just stop mentioning the Condition. The Condition Era constructor assumes exactly this: As long as somebody mentions the Condition, it is still active. When the data become silent we assume the patient is healed.

If you ask me, we remove the End Date, and we certainly remove the Stop Reason. But they don’t hurt anybody, and removing something that is not in the way has a lot lower priority than introrducing something that’s badly needed. As a result they are still alive and kicking. But I think we should run a Network Study and find out if anybody ever has that information. If not, we get rid of the fields.

Exactly.

#8

Some EHR folks have condition end dates. The values I’ve seen for a stop_reason in a structured data type column are fairly generic, but a network study would give us more insight. stop_reason could probably be mined from Notes.

#9

To me the question is about the following event:
Primary doctor D reviewed the problem list for his patient P and decided to delete 2 conditions from the problem list.

It would be nice to hear from advanced EHR sites how end dates are actually captured in Epic and Cerner and … (and how deleting item from problem list actually happens)

#10

@Vojtech_Huser because you asked! At the U of Colorado- UCHealth we have advanced use of Epic (HIMSS Stage 7). “Start-” and “end-dates” are only recorded in two ways in our EHR. The first is with the use of Episodes-which I consider an indirect recording method and would not use. Episodes are used to support some bundled payment programs and occasionally things like Transitional Care Management services- as a an episode is truly more about an episode of service than the time period of a condition. The second is via the Problem List, where encounter dx can be added to the Problem List (PL) or added directly at any time. When added via an encounter dx and it is a new dx - it generates the encounter date as the start date. A concern is that very similar problems can be, and often are, added to the PL (ex DM without complications; DM with complications, renal; DM with complications, neuropathy)- all with therefore different start dates. A problem can also be added outside of an encounter at any time, and then the date would have to manually entered or would default to the entry date - which is technically called ‘date noted’ in our system-as the vendor knows that it is not a ‘start date’. Problem List information can be manually edited, so I can edit the date notes - so if a patient is new to me- and has DM for 10 yrs already I could add DM to the PL and edit the date noted-- most providers do not bother to do this. I can also Delete, Resolve, or Resolve & Add to History any Problem on the PL. For Resolve- it defaults to the date the action was taken or I can manually enter a date. Delete likely captures the date I deleted the condition but I cannot manually enter a delete date. IMO, condition_end_datetime should not be mandatory (maybe you’ve already come to that conclusion) because data are likely to not exist and when they do exist they are likely to be very inaccurate. In our system, specialist very rarely keep PL up to date in a meaningful way and primary care providers try to keep non-essential diagnoses off the PL, so they do a a lot of cleaning up (all 3 methods above, no convention) but mainly just deleting or resolving but not manually adding meaningful dates.

1 Like
#11

Thanks, @schillil. You said it all.

But the question remains: If the information is rarely there, and when it is there who knows what it means, why not get rid of the End Date and treat Conditions as snapshot assertions. Like we effectively already do anyway.

#12

I hope one day this would change. And the CDM should be gearing up for that and support the advanced EHR user today. The snapshot approach would be old way while new better EHR would start to prevail. As outlined in this vision https://doi.org/10.1093/jamia/ocz125 by Cimino

#13

Not sure it’s a problem of the EHR. It’s how healthcare works. Say, you got an acute bronchitis and show up at the Urgent Care center. You get prescribed some mucolytic and antibiotic medication. You go home and after a week it is gone. Obviously, you don’t go to the Urgent Care center again to gladly announce you are healed now. The first experience was more than enough. Who is now going to enter an end date?

See my point?

#14

Agree :slight_smile:

However, end dates for some Conditions (cancer being at the top of my head) are useful data. Let’s not banish the end date from the Condition table. It isn’t a mandatory field, if you have it, put it in. And continue with the current logic to

#15

Definitely. We are thinking to put that information into the EPISODE table. That allows complex abstraction rules to define when thing really start and end. Not just a code to show up or stop showing up.

#16

With regards to condition_end_date, we must also take into account that there are conditions that are never resolved such as diabetes. This is another reason in my opinion that the end date in not a necessary field, unless the meaning is indeed that the diagnosis was recorded by mistake and at a later date removed.

#17

That is certainly not the meaning. The ETL should have taken out such a record to begin with. But you are right, we need a convention for Conditions that don’t resolve. Type 1 DM is an example like that, Type 2 you can shed if it isn’t too far progressed and you lose weight and start exercising and eating better.

1 Like
t