Including 95% CI and SE as available measures of data variability#413

When extracting variables that include 95% confidence intervals, there are a few snags in the current NK approach.

Example: I am attempting to record the annualized relapse rate for both study arms. Currently, our best approach to abstracting relapse rates is to create a continuous extraction variable, select mean and range for central tendency/dispersion measure, treat the range as the 95% CI value, and then post-export revise the table columns to reflect that range is really 95% CI.

Is there a more elegant solution to including 95% and SEs?

Great question - we currently don’t allow extraction of CIs, or any inferential statistic in our quantitative extraction tool. As you’ve found, you can hack on this usinng ranges, but this approach will often lead to confusion & improper inferential statistics on our end.

Our answer, to date, has been to back-compute SDs from the CIs (e.g. as proposed in the Cochrane Handbook). However, I say this from the aloof position of a statistician, where descriptive statistics are usually preferred for pooling & MA, vs. inferentials.

I take it you desire to report CIs as given directly from the source trials, vs. inferentials stats we compute? (which, I would expect to be approximately equal under standard assumptions)

Hi @Karl Holub, apologies for the delayed response. Yes, we would prefer to report directly from the source to ensure accuracy. We often report on 95% for qualitative purposes, not just our econ modeling work.

Previously, we flirted with the idea of using the tag feature to include the rate/proportion, 95% CI, and p-value for each arm but that would require us to manually preface every value with whever arm it was for, which we think would be too time consuming. Thoughts?

Good question– If you have tags for each arm that you are applying, and do so consistently, I could see a tag for rate / 95% CI / p-value being informative. If you are reporting these for qualitative purposes, then that is actually a good solution in my opinion, since you could generate a table of arms & these data. However, it is obviously non-optimal if you want to actually use these data for calculations / combining the information, so please let me know anything that holds you back on the front of quantitatively combining these comparative values. Thx, Kevin