-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Query Verification: Crohn's Disease Cohort #102
Comments
Edited to reflect "three or more" (>2) not 2. dx_case_inclusion_criteria_1: The SQL is written as if the criteria required the 3 or more occurrences to be different inclusion diagnoses. Another interpretation of the same English is that the same/different inclusion diagnosis appears in three different encounters. If the second sentence is the intended interpretation, then you need to bring in three visit_occurrences (v1, v2,v3), make sure then are not equal (e.g. V1< V2, V2 < V3) and look at their linked diagnoses independently as I sketch out with a previous phenotype that needed two visits 30 days apart. |
dx_case_exclusion_criteria_1: I do not see justification for The English ("any dx") implies that any instant of an exclusion criteria is qualifying. If so, a count >= 1 (including the equals) is correct. |
dx_case_inclusion_criteria_2 CASE TYPE 2 is a confusing case definition. CASE TYPE 1 explicitly removes patients with any UC diagnosis yet CASE TYPE 2 explicitly puts them back in. Between these two definitions, the only UC cases not included have only 1 UC Dx. Is this the intended behavior of the combination of the two inclusion types? Seems so by the text after "CASE TYPE 2" but weird. |
If I followed the logic for controls correctly, the query would allow a person to be declared a control if they had 0-1 relevant codes, 1 relevant medication, 0-1 ulcerative colitis codes and none of the exclusion_criteria_3 and _4 codes. Without looking at what is in exclusion_criteria_3 and _4 codes, this logic would allow somebody who had some "hints" about Crohn's and UC to be included. |
End of comments for Crohn's |
This is the only information we are given: Which, means my initial line of |
OK, I agree with that. In that case, I think I need to verify all exclusion criteria for "any occurrence" and make sure it matches this. |
Here is the information I am provided: Going off of this, like the first example, I believe it is represented correctly. If you still disagree, I'm happy to discuss further. I tried hard to only go off of what the text indicated and not include additional knowledge as that should represent what an "average" person might interpret. Or, at least that was my goal in doing this in the most reproducible manner. |
So, for the control criteria, the definition doc states: Where "none of the above" refers to the case criteria and the "also excludes" is an additional list of ICD codes mentioned in dx_control_exclusion_criteria_3 and keywords I have included in dx_control_exclusion_criteria_4. Given this, do you agree with the way I have written the control query? The full doc is here if you want more than than what I have included in this and the other issues. |
So weird..... Do they provide any examples of implementations of this phenotype on the web site so we can see how others have implemented these criteria? |
This goes back to a fun conversation we had at very beginning of this project 😄. In general, most of the phenotypes we are exploring have been implemented by several universities, but the results of these implantations are not publicly available, although you can gain access to them if you create an account. All that said, the point of this project (in my opinion) is to demonstrate what an average, unbiased approach built on top of OMOP looks like. While I understand wanting to go see how others did it, we also know others have made mistakes and how are we to know you is "right". Further, if we peek for this phenotype, then we would need to do that for the others too otherwise we are introducing more bias. I'd prefer to write a paper that shows a realistic perspective on what it's like to implement eMERGE phenotypes. I strongly believe that it's the only way we will be able to understand how these things can be automated in the future. |
NEW COMMENT: Logic for exclusion criteria is wrong. You need an OR (UNION) rather than an AND. Current logics says that an exclusion needs to meet all exclusion criteria. My understanding is that you are excluded if you meet ANY exclusion criteria. If so, then an OR (UNION) is the right logic in your NOT IN subquery. |
Thanks for bringing this up, this was something that I went back and forth on too. The criteria that we were provided says that the control group can contain "none" of the case group criteria as well as some other criteria. I interpreted that as meaning they wanted to identify people that were the opposite of the case group in that they should have none of the criteria that was used to select cases. Do you disagree? I am happy to do whatever you think is best, but wanted to explain why I chose "AND" and not "OR". |
@mgkahn - Can you please help me verify the query to select Crohn's Disease patients?
COHORT CRITERIA
Case Criteria:
CASE TYPE 1: Crohn’s and medications only
CASE TYPE 2: Crohn’s and medications with Ulcerative Colitis Diagnosis
Control Criteria:
Cohort Logic Table
NOTE.
{database}
withCHCO_DeID_Oct2018
{code_set_group}
Query can be found here and is also included below:
The text was updated successfully, but these errors were encountered: