You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several things that could be added to this section:
data may be ingested in a number of ways:
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.
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.
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.
The text was updated successfully, but these errors were encountered:
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).
See other issue on consistent code first.
Several things that could be added to this section:
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.
The text was updated successfully, but these errors were encountered: