docs: ✨ initial draft of functions to classify diabetes type #75
Conversation
including post and figure
signekb
changed the title
|
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
docs: change date format based on @Aastedet s review Co-authored-by: Anders Aasted Isaksen <[email protected]>
we'll try to keep things simple(r) by only having one user facing function, `classify_diabetes`
Co-authored-by: Luke W. Johnston <[email protected]>
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.
@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
Description
This PR describes the functions for classifying the diabetes type from the diabetes population using the
osdcpackage.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 :)))