Closed remcv closed 3 years ago
Many thanks for this input!
Didn’t know of that list, that could be a great addition. Though it won’t be easy to incorporate all the differences and duplicates in it, e.g. J01CR50 is 8 times in that list…
I’ll update the dataset where I can and also add a test that units should never be missing.
While working on this issue, one thing needs clarification:
ab_ddd()
returns the DDD, but not the unit
This is intended. From the documentation:
# defined daily doses (DDD)
ab_ddd("AMX", "oral") # 1
ab_ddd("AMX", "oral", units = TRUE) # "g"
ab_ddd("AMX", "iv") # 1
ab_ddd("AMX", "iv", units = TRUE) # "g"
We chose to return the value (numeric) so it can be used for other data processing easier. With units = TRUE
, you can retrieve the units.
Do you think this needs more convenience? If we give it an additional class in R, we could have the units printed, while the actual returned values are numeric. Didn’t seem a great idea in 2018 when we came up with these ab_*()
functions, but we’re always open for debate.
Thank you for this great package! I use it quite heavily in my antimicrobial stewardship projects.
By the way, that is AWESOME!!! 🤩
Sorry for not being clear in my issue description. I've read the documentation (which btw is really well made) regarding the return type of ab_ddd() function. The problem I face is the following:
r$> ab_ddd("J01DI54", administration = "iv", units = TRUE)
[1] NA
The return is NA, but it should have been g
https://www.whocc.no/atc_ddd_index/?code=J01DI54.
The same inputs used with atc_online_property() return the corrrect result.
r$> atc_online_property("J01DI54", property = "U", administration = "P")
[1] "g"
Do you think this needs more convenience? If we give it an additional class in R, we could have the units printed, while the actual returned values are numeric. Didn’t seem a great idea in 2018 when we came up with these ab_*() functions, but we’re always open for debate.
I personally do not mind this. I've written my R scripts using ab_ddd() with the units argument TRUE and FALSE, depending on my needs. In other programming languages (Java, C++) it it not possible to have different return types for a function/method, but I do not know if in R this is a bad practice (although it is confusing for people that code in a different language). Another approach is to return an R list with both the number and the unit, if you want to avoid creating a new class or leave it as it is.
The hospital I am doing the analysis for also uses some antimicrobials that are not in the ATC J
category, but in the P
category, like oral metronidazole https://www.whocc.no/atc_ddd_index/?code=P01AB01. When running ab_ddd() on it, the return value is NA:
r$> ab_ddd("P01AB01", administration = "oral")
[1] NA
Warning message:
These ATC codes are not (yet) in the antibiotics data set: "P01AB01".
Please let me know if I should open a separate issue for this.
At this moment, ATC codes are unique identifiers for antibiotics in our data set. This should not be the case, so this requires a big change in our antibiotics
data set. Will be a great addition though.
Please let me know if I should open a separate issue for this.
Nah, not needed.
In other programming languages (Java, C++) it it not possible to have different return types for a function/method, but I do not know if in R this is a bad practice (although it is confusing for people that code in a different language).
Totally with you there, it shouldn't be confusing. So implemented this for the next release:
ab_ddd("AMX", units = TRUE)
#> [1] "g"
#> Warning message:
#> Using `ab_ddd(... , units = TRUE)` is deprecated, use `ab_ddd_units()` instead. This warning will be shown once per session.
I'm also reviewing other AMR
functions regarding this, although I'm pretty certain this is one of the very few that can have different data types as output.
Sounds good :satisfied:. This is a cleaner approach.
I'm pretty certain this is one of the very few that can have different data types as output.
The atc_online_property()
function can also output different data types.
atc_online_property()
retrieves results from an online WHOCC table. I agree it's not the cleanest option that it can return different output values, but I think it would break a lot of code of many people if we change that behaviour. ab_ddd()
is already much more specific, so it's a less impact to deprecate the use of the units
argument there. I have added the atc_online_ddd_units()
function that specifically retrieves units based on the administration (oral / parenteral / ...).
Also found out that our reproduction script to create the antibiotics
data set was lacking the retrieval of units. That explains this:
ab_ddd("J01DI54", administration = "iv", units = TRUE)
#> [1] NA
Updating the data set now.
The development version nows contains the fix to this issue. You can try the latest version yourself using:
install.packages("remotes") # if you haven't already
remotes::install_github("msberends/AMR")
Hi Matthijs, Thank you for your involvement and for the discussion! Will update my repos to the new version 👍
Thank you for this great package! I use it quite heavily in my antimicrobial stewardship projects.
Issue details
ab_ddd() & atc_online_property() both return NA for:
J01EE01
(SULFAMETHOXAZOLUM + TRIMETHOPRIMUM). This happens for combination products where the DDDs deviate from the main principles. These DDDs are included in a separate list: https://www.whocc.no/ddd/list_of_ddds_combined_products/.P01AB01
(metronidazole oral) - not yet in the database (?)J01DI54
(CEFTOLOZANUM+TAZOBACTAM):Session info