Skip to content
This repository has been archived by the owner on Sep 3, 2024. It is now read-only.

Add PERSON_ID to PERSON inclusion critieria #11

Open
pbr6cornell opened this issue Apr 17, 2015 · 2 comments
Open

Add PERSON_ID to PERSON inclusion critieria #11

pbr6cornell opened this issue Apr 17, 2015 · 2 comments

Comments

@pbr6cornell
Copy link
Contributor

Use case: a group already has a cohort, which is defined by a set of PERSON_ID. we should be able to import a comma-separated list of PERSON_IDs, and then apply zero or more additional criteria to those patients. The list of PERSON_ID should be joined to OBSERVATION_PERIOD to set cohort_start_date = OBSERVATION_PERIOD_START_DATE and cohort_end_date= OBSERVATION_PERIOD_END_DATE.

@chrisknoll
Copy link
Contributor

Can we dig a little deeper in to this use case? I'm trying to understand:

Additonal criteria means that you're looking for a count of something relative to the index date. So, by providing a list of person_ids to create a group of people, what are we counting, exactly?

Ex: index dates of condition_occurrence, additional criteria of a drug exposure = count number of drug exposures within X days of the condition occurrence.

Additionally, person_ids are completely data-source specific. How would this make the expression portable?

@pbr6cornell
Copy link
Contributor Author

You are 100% correct that a query using PERSON_IDs is not portable across
different systems.

And yes, I was should have been more specific in the description: In both
the primary event filters and the add event filters, if you select
observation periods, i'd like to add an attribute filter for PERSON_ID,
which would allow a user can specify a list of personids that are 'in' the
cohort by providing a comma-separated list of PERSON_IDs. Whether that's
actually implemented as a SELECT * FROM OBSERVATION_PERIOD WHERE PERSON_ID
IN () or whether the list is first written to a temp table and joined
to OBSERVATION PERIOD is not important. If this attribute filter is
selected as a primary event filter, the index date will be set to
observation period. If this attribute filter is selected within an
additional filter, the index date will be defined by the primary event
filter and we'd simply be restricting the set of eligible people.

The anticipated use case, which Regenstrief and Columbia have introduced,
is that they have a list of PERSON_IDs from some external system that was
generated off the same source data. Given that set of PERSON_IDs, which
was defined in some external way that may or may not be definable only by
elements in the CDM, they'd like to 'recreate' the cohort in their CDM so
that they can then take advantage of the various OHDSI tools, such as
HERACLES and the methods library. So, as a standard workflow, we'd like
that process to start with CIRCE to create a cohort definition that can be
saved for future use. That cohort definition would then to used to
instantiate the cohort (where the webAPI function of generateCohort is
called, whether in CIRCE, CALYPSO, HERACLES, elsewhere, or having to
options for all of those still needs to be sorted out).

On Fri, Apr 17, 2015 at 6:49 PM, Chris Knoll [email protected]
wrote:

Can we dig a little deeper in to this use case? I'm trying to understand:

Additonal criteria means that you're looking for a count of something
relative to the index date. So, by providing a list of person_ids to create
a group of people, what are we counting, exactly?

Ex: index dates of condition_occurrence, additional criteria of a drug
exposure = count number of drug exposures within X days of the condition
occurrence.

Additionally, person_ids are completely data-source specific. How would
this make the expression portable?


Reply to this email directly or view it on GitHub
#11 (comment).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants