Skip to content
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

RXR-373: consistent handling of missing/unrecognized data in calc_ibw()/calc_ffm()/calc_egfr(). #19

Merged
merged 14 commits into from
Sep 13, 2021

Conversation

karawoo
Copy link
Contributor

@karawoo karawoo commented Sep 9, 2021

  • If required information is missing, we throw an error
  • If data is provided but not recognized/supported by the method, we throw a warning and return NULL.
  • If data is provided that doesn't match the intended use of the method but it's possible to still calculate the result (e.g. the age is outside the range the method is intended for) we throw a warning but still calculate the value

For calc_egfr() and calc_ffm(), the functions were relatively long with conditional branches for each method. Rather than add more lines I opted to split the code into separate functions for each method, which seemed a bit cleaner, but does make the diff rather large. I added a number of tests for the calc_ffm() methods; calc_egfr() was already relatively well covered so I just added a test for the new behavior there.

@jasmineirx
Copy link
Contributor

this refactor looks great at a quick glance! I'm so glad you tackled this - it had been bothering me for a while.

Copy link
Contributor

@jasmineirx jasmineirx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm - the decision for when to stop versus warn makes sense. I had two comments.

R/calc_egfr.R Outdated
height = height,
scr = scr
),
FALSE
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want this to be FALSE or NULL?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Originally we were returning FALSE here so I kept that, but NULL makes sense too. In practice I don't think it should matter too much -- if the egfr method isn't recognized we will have thrown an error long before we get to this line, so I don't think we should ever reach this fallback. Maybe we could remove it altogether.

R/calc_egfr.R Outdated
Comment on lines 476 to 488
k <- ifelse(
preterm & age < 1,
0.33,
ifelse(
age < 1,
0.45,
ifelse(
age > 13 & sex == 'male',
0.7,
0.55
)
)
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is how it was written previously, but perhaps this is clearer?

Suggested change
k <- ifelse(
preterm & age < 1,
0.33,
ifelse(
age < 1,
0.45,
ifelse(
age > 13 & sex == 'male',
0.7,
0.55
)
)
)
if (age < 1 ) {
k <- ifelse(preterm, 0.33, 0.45)
} else if (age > 13) {
k <- ifelse(sex == 'male', 0.77, 0.55)
} else {
k <- 0.55
}

we then also could only error if sex is not in c("male", "female") if age > 13.

In practice we should not reach this line as unrecognized methods error earlier
in the function, but good to have as a backup.
@karawoo karawoo merged commit b74a7d1 into master Sep 13, 2021
@karawoo karawoo deleted the RXR-373 branch September 13, 2021 18:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants