giabaio / bcea Goto Github PK

It can be really useful to have an integrated news file. I see that most of this is covered on your blog but it would great to have this all in one place.

Linked to #6

How can I plot info rank plot when we have multiple comparators in the BCEA object.

Personally I really like using html websites to navigate through package documentation. It can also be a great way of centralising all of the resources for your package.

The {pkgdown} package makes constructing these very easy with the sites then being able to be hosted on GitHub pages. It can be nice to have the package built externally (i.e on Travis) so that it updates without package author interventions

Happy to help with this if interested.

Linked to #6

It can be very reassuring for users to get package code (as well as methods etc.) peer reviewed. JOSS is a good way of getting this done (I could have missed that you have already done this).

We are talking about getting as many Excel users to switch too R as possible and I think making your excellent package look as official as possible would be great.

Linked to #6

While writing the (regression) unit tests to replace the current internal evppi() function with the {voi} package version, an error occured. For the smoking example, the data I have has different number of rows for the cost and effectiveness matrices and the parameter posterior sample size. They should correspond. BCEA::evppi() actually doesn't throw an error so I don't know how it handles this or if its done correctly.

• Am I understanding this correctly? What should we do about it?
• Could recalc c,e using the posterior samples?
• Could use the same fix thats already in BCEA::evppi() but not sure if this assumes row match e.g. first 500 of 1000?

This is the voi::evppi() error:

Error in check_outputs_matrix(outputs$c, inputs, "outputs$c") : 
  Number of rows of `outputs$c` (500) should equal the number of rows of `inputs` (1000)

This is the test code:

  data(Smoking, package = "BCEA")
  treats <-
    c("No intervention", "Self-help",
      "Individual counselling", "Group counselling")
  
  bcea_smoke <- bcea(eff, cost, ref = 4, interventions = treats, Kmax = 500)
  inp <- createInputs(smoking_output)
  EVPPI_smoke <- BCEA::evppi(bcea_smoke, param_idx = c(2,3), inp$mat, h.value = 5e-7)

  # error
  voiEVPPI <- voi::evppi(bcea_smoke[c("e","c","k")], pars = c("d.3.", "d.4."), inputs = inp$mat, h.value = 5e-7)

My understanding of the analysis is that the output needs to be based on some kind of simulation that gives a distribution of outcomes.

Does this need to be a true Bayesian posterior or could it be a prior distribution or sample arrived at using other means?

Obviously, it would be better if everyone went bayesian but might it be a good idea to point out that this is optional (if it is)?

It would be really great to have BCEA tested against multiple versions of R (release, devel, and older etc.) It would also be great to have testing against Linux, MacOS, and Windows (I might have missed this).

Linked to #6

Hi @giabaio,

TLDR: Sorry for the huge number of issues. All are suggestions so feel free to ignore/close. Equally if you are interested but have no time then I am happy to do some work on these.

I've been attending an R health economics hackathon and been reviewing your package to see if more tooling is needed for cost effectiveness analysis (it's not - your package is great!). We actually started on a package and realised very shortly after finishing the infrastructure that yours did everything we were considering doing.

That being said we identified a few things that we thought could be changed to improve the user experience for people using BCEA with non-traditional models. I am going to open a few issues highlighting some of our thoughts but feel free to close any/all of them if you think it isn't required.

Very happy to work on any or all of these issues if that would be helpful - just let me know 😄

Here some ideas for (probably relatively minor) changes in the main code of BCEA and some of its functions to improve visualisation of the output (particularly the CEAC).
@seabbs --- something else to think about?

Depending on your thinking regarding user contributions it would be really great to have some sort of guidance for how you would like features to be suggested.

I have implemented this as a folder previously (and in the README but other solutions could be equally as good.

Linked to #6

@n8thangreen I think there's a slight inconsistency in the way you've refactored the summary method. You have coded rownames(EU_tab) <- he$interventions[c(he$ref, he$comp)] which implies that the first row of the table must be the reference intervention. But this doesn't propagate to the full table, so in the examples I was checking, you actually have data in the order provided by the eff, cost matrices (so: first column=intervention1, second column=intervention2 and so, with no reference to the choice of the reference intervention), but then the row names are not matching that.

The drawback is that you'd get blatant inconsistencies, such as with the most cost-effective intervention not being associated with the highest expected utility (simply because of reordering of the row labels...).

I've fixed it temporarily by simply changing the code above to rownames(EU_tab) <- he$interventions --- but I'm not sure this breaks something else down the line...

Can you please when you have a moment have a look?

Thanks!

We discussed how suited your package was to a shiny app. It looks like you have implemented this which is great!

Would you be interested in implementing {shinymeta} so that the code that is being used can be outputted for the user? For some novice R users this could be a really great way of moving from a non-reproducible workflow to a reproducible one!

Linked to #6

It can really help users trust a package if it has robust testing, external validation and code reports. There are some great R packages (as I am sure you are aware) like {testthat} for unit testing code and {vdiffr} for testing plots.

Running tests externally (i.e with travis as set up here) can be really nice + a code coverage report can then be generated.

Very happy to help get this set up and start adding some tests!

Linked to #6

Appreciate that you have the book (which gets excellent reviews) would you be interested in some additional vignettes explaining package functionality in more detail for users without the book/introduced in open source resources?

Linked to #6

In my group we have a lot of people working on dynamic infectious disease models and then running cost effectiveness. This means they are typically working with simulation output for model states that they then apply health utilities and costs to.

Would you be interested in either some additional tooling or a simple vignette walking through how to take a model like this and use {BCEA} with it.

Linked to #6

R returns the following error when trying to knit an automated report using BCEA:

Error in abs_path(input) : The file '/report.Rmd' does not exist.

Hi, I would like to plot a comparison of A, B, C, with A as the reference.
Using the standard ceplane.plot, it plots A-B, and A-C.
However, I wanted to show B-A and C-A.
Is it possible to change it?

Hi!
Pretty minor but error message when providing data frames instead of matrices to bcea could be clearer. Reproducible example below

library(BCEA)
c1 <- data.frame(c1 = runif(100),
                 c2 = runif(100) )

e1 <-data.frame(c1 = runif(100),
                c2 = runif(100))

m <-bcea(c = as.matrix(c1) ,e =  as.matrix(e1) ,interventions = c("Intervention", "SoC"),Kmax = 60,ref = 1)
class(m)
#> [1] "bcea"
m <-bcea(c = c1 ,e =  e1 ,interventions = c("Intervention", "SoC"),Kmax = 60,ref = 1)
#> Error in rep(e, K) * rep(k, each = n.sim * n.comparators): non-numeric argument to binary operator

^{Created on 2021-03-02 by the reprex package (v0.3.0)}

It can be really great to be able to link to specific package versions using a DOI. Zenodo is a nice tool for doing this. What do you think?

Linked to #6

I thought your presentation based overview was really great - it would be excellent if this was included in the README.

Lots of packages have informative READMEs and I find this really helps.

Linked to #6.