-
Notifications
You must be signed in to change notification settings - Fork 1
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
docs: ✨ initial draft of functions to classify diabetes type #75
docs: ✨ initial draft of functions to classify diabetes type #75
Conversation
including post and figure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I add the summary from Steering group meeting (including roadmap for improvements e.g. birth register and date of diagnosis) to #69
Based on update meeting: I will add the final data.frame: PNR, inclusion date (two columns: stable and raw), and type |
@Aastedet @lwjohnst86 ready for another review 🎉 @Aastedet rather than creating an "extended" version of the flow chart for classifying the diabetes type, I have added a section elaborating on the "hierarchy" or "ordering" of primary diagnosis from endocrinological and medical specialties. What do you think? Is that sufficient? |
…functionality-flow-classify-diabetes-type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a bit of date formatting
docs: change date format based on @Aastedet s review Co-authored-by: Anders Aasted Isaksen <67263135+Aastedet@users.noreply.github.com>
we'll try to keep things simple(r) by only having one user facing function, `classify_diabetes`
Co-authored-by: Luke W. Johnston <lwjohnst86@users.noreply.github.com>
Based on review from @lwjohnst86
3. **raw_inclusion_date**: The *raw* inclusion date (i.e., the date of | ||
the second inclusion event as described in the [Extracting the | ||
diabetes population](#extracting-diabetes-population) section above) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lwjohnst86 At the Steering Group meeting we decided to provide both, but the "stable_inclusion" being the clear default, while we are explicit to the user that the "raw_inclusion" is experimental/use-at-own-risk.
I'm not sure if that guides us towards an answer here though. Depending on the study design, the user might have a clear need for the "raw_inclusion" date.
I lean towards including both, but naming them to "inclusion_date" and something like "unstable_date" or "_date" to make it clear which is the default (and also obscuring the non-default variable name so users will have to read the documentation to know what the variable is).
The filter distinction isn't necessary, since we're not sure whether this would actually increase performance and omitting this distinction simplifies the classification
…add them to vignette
…evels based on that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I've only done very small formatting and text edits. Otherwise looks good now!!!
Description
This PR describes the functions for classifying the diabetes type from the diabetes population using the
osdc
package.This is a stacked PR (meaning that it builds upon the PR that describes how the diabetes population is extracted, #71).
Closes #26.
As we have discussed, this is an initial draft meant to help us specify exactly what we want to build.
So, as with the other PR, please chime in with questions, suggestions, and corrections :)))