Do we allow events that fall out of observation period?

[aostropolets]

TYPE	NOTES
ITEM	The OBSERVATION_PERIOD table contains records which uniquely define the spans of time for which a Person is at-risk to have clinical events recorded within the source systems, even if no events, in fact, are recorded (healthy patient with no healthcare interactions).
FORUM POST	(OLD THREAD) http://forums.ohdsi.org/t/observation-period-flavors-first-themis-focus-group-2-now-discussed-everywhere/3850/18 (CURRENT THREAD) http://forums.ohdsi.org/t/data-outside-of-observation-period/4557
SOLUTION	1. Events CAN fall out of observation period. 2. Payer plan period should be used to capture coverage (including partial e.g. Medicare part D) and can overlap with the observation period. 3. Every patient must have at least one observation period.
RECOMMENDATIONS	1. not use time outside of an observation period for identifying people. 2. to ensure quality do not use events outside of an observation period for an analysis. 3. if patients do not meet criteria for observation period (e.g. have partial Medicare D coverage), create an alternative CDM that allows for them to fall in OBSERVABLE_TIME.
NEXT STEPS	Update CDM Wiki for OBSERVATION_PERIOD to discussion in the conventions.

[cgreich]

Can you remember why we said 3) Every patient must have at least one observation period?

[chrisknoll]

From a cohort definition perspective: this is used to determine if we have enough prior history in the patient record to establish a washout.

[aostropolets]

I remember Patrick had issues with patient count otherwise. Must have been something with incidence rates. Chris: right, but whenever you pick any washout period, those who have no observation period will be automatically excluded.

[chrisknoll]

those who have no observation period will be automatically excluded.

So a cdm with no observation periods can not be used in any study that need a washout?

[cgreich]

Ah, yes. Patrick wants "real" analyzable patients in the counts, not just fake records.

Chris: In your cohort logic - do you look into the OBSERVATION_PERIOD table, or only if a washout or follow-up period is given?

[chrisknoll]

We also look in the observation period to find correlated criteria that occur within the same observation period (I believe this is alluded to in point 2 above). So if there are no observation periods, then no cohort events will be identified because during the process we need to know which observation period the 'primary events' were found in.

[cgreich]

And that's true even if there is not a single qualifying criterion?

[chrisknoll]

That's a bit of a paradox: can you have a cohort definition without a single qualifying criterion? To answer my own question: "No, you can't have a cohort definition without a single qualifying criterion, and so having no observation periods will keep any people from being identified using CIRCE cohort expressions". Of course, anyone can create their own records in the cohort table, but without observation periods, how are you to ensure that for Point 2:

2. to ensure quality do not use events outside of an observation period for an analysis.

To add to this: for CIRCE cohort definitions: a you specify criteria for entry into the cohort, and if no exit criteria are specified, then you stay in the cohort until the end of the observation period the event occurred in. If you have no observation periods, then this won't work.

[aostropolets]

Chris, you are totally right. That’s why we leave the restriction to keep at least one observation period. Still, there are people who want to use Medicare D patients, whose plan doesn’t qualify as an observation period. They need to relax their CDM in order to be able to store those patients.

[cgreich]

The exit criterion argument makes sense. Still not sure why the entry criterion needs a observation period. I know you did it that way.

[aostropolets]

Because we want to make sure that we study something from the very begininning and we haven’t missed any interventions/events

[jenniferduryea]

Maybe to clarify @chrisknoll , if you are looking for events to be included in incident rate analysis, then you can only use events within a patient's observation_period. But, if you are looking for patients with a "history of" to describe patients in a cohort, then you can use all events (including the ones outside of an observation_period). I understand CIRCE does not do that. But this is necessary for people who are querying the CDM manually and need to see data outside of an observation_period.

Getting back to @cgreich and @aostropolets , I'm still not understanding the use case for solution 3 and recommendation 3. From what I understand, Patrick wanted to only see "valid" patients when doing a "select " on the person table. But, since we are allowing data to live outside of the observation_period, users are going to have to join their query with the observation_period table consistently to find valid events (i.e. find all valid diabetes events will require the user to join the observation_period table to the condition_occurrence table). Users cannot just "select " on the condition_occurrence table to find diabetes events now - they need to join it to the observation_period table. So if users have to join the observation_period table to all of the fact tables in the CDM, I do not see why we should break convention and make joining the observation_period table to the person table optional.

[cgreich]

@chrisknoll: I think @jenniferduryea has a point. You may want to do even something nice, by incorportating some UI support for the way history and family history is stored: Either as a pre-coordinated concept, or split into History of/Family history of and the actual Condition in the value_as_concept, and this time without the OBSERVATION_PERIOD join. Thoughts?

[chrisknoll]

Hi, @cgreich and @jenniferduryea, The idea of being able to use events from observation periods outside the cohort's index date has been brought up a few times, and I've been beaten into submission about only using events that fall within the index's OP :). Patrick has explained to me that this is what the prior convention was, but this new convention described here supports the idea that data can exist outside OPs.

If the convention is adopted that data can exist outside of OPs then we can make the necessary changes to support this (such as making the joins to OBSERVATION_PERIOD optional).

So from a completely CIRCE cohort expression perspective:

1. Looking for events outside of OP for historical evidence: I don't think it makes sense to hard-code logic around specific concepts for purposes of sometimes locking it to the OP and other times allowing it to look anywhere in the data (as @cgreich suggests with the family history concepts). However, providing an option to the user to 'use all events' (disabled by default), allowing the criteria to use data outside OP is possible.

2. Because we have to maintain a bit of backwards compatability, we wouldn't enable external OP events by default because historical cohort defs assume these rules and conventions and we don't want to change the logic of historical cohort definitions. That's why the suggestion is to add a new option to 'allow all events' that the user needs to 'opt-in'. Alternatively, we could make it part of the release notes for a new version of CIRCE that we now look at all data by default. Users would have to go back to existing cohorts and use an option to 'restrict events to index observation period' if they want the prior convention (or if they want that convention for their study design). But either way, I believe an option would be required for the user to specify how the data external to the index OP is found depending on what their study needs are.

I'm sorry to hijack this part of the thread on an implementation detail of CIRCE. My suggestion: once the Themis recommendations are adopted by the CDM WG, we can create circe specific issues under OHDSI/circe-be repository to address the new conventions that we need to support.

Thanks everyone for your thoughts!

-Chris

[alondhe]

Just teasing this up here as well: we may need to change the era logic to join with the observation period: https://github.com/OHDSI/Era-Constructor/issues/5

[alondhe]

I've created a forked version of the Era-Constructor here: https://github.com/alondhe/Era-Constructor/tree/master/v5.3.

There's one small hurdle, which is to change the use of EPOCHs into something that SqlRender can translate into all dialects. Anyone know how? Tagging @chrisknoll

[cgreich]

@chrisknoll: not sure I ever answered in writing to your two points, but I agree on both. Plus, it is already ratified.