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

Data #2

Open
RobertASmith opened this issue Apr 9, 2021 · 1 comment
Open

Data #2

RobertASmith opened this issue Apr 9, 2021 · 1 comment

Comments

@RobertASmith
Copy link

See other issue on consistent code first.

Several things that could be added to this section:

  • data may be ingested in a number of ways:
  1. from a package. Ideally there would be a single 'NICE' package that includes NICE verified data (e.g. life-tables & QALY scores for a healthy population, or discount rates ... ). These could be updated annually by NICE, who would then have confidence that submissions relying on them were robust.
  2. from a file in the data/rawdata folder - this would then need to be reviewed by someone, the benefit of this is that the code & the data can be made available separately when the data is not publicly available. Ideally the user would make pseudo-data available so that the code could be tested without access to the data.
  3. from an external API - this is risky since this data may change. However it may be useful when large data-sets would make repositories burdensome. For example GitHub has a large file storage system which could be referred to from the repo made publicly available.
  • Data outputs should be standardized. This may include PSA outputs or individual level outputs from a discrete event simulation model. However, I would discuss this within the results/outputs section. Within the outputs/results section I would also include a section on plots/graphs. One of the most pointless things is for different groups to be producing the same plots in slightly different ways. NICE (or others) should converge on one set of plots and provide code and functions in a package to make these plots. These should be tested & verified in much the same way as other functions in health economics packages as discussed in 'consistent code'.

  • the source of all data should be made available, and it should be referred to in the text of any report using the link to the repository/dataset if available so that others can browse the data.

@giabaio
Copy link

giabaio commented Apr 9, 2021

I like the idea of having a repository (perhaps even more helpful than a package?) storing all the data in an organised way. For instance, wouldn't be terribly complicated to store in single place the life tables to be used for extrapolation, or create a dataset of discount rates within different jurisdictions --- some work no doubt, but a worthy exercise! We should try and liaise with NICE (but also other bodies --- CADTH or PBAC, for instance).

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

No branches or pull requests

2 participants