...
Fully automatic updating of SoF tables when the underlying data change in RevMan Web is not in scope for this proposal. Primarily that is due to the expected complexity, but it may also be desirable to require human intervention for the updating of the SoF table (e.g. to check if GRADE decisions need updating). A middle ground could be an "update" button that doesn't pull the user into $SofTool, but any rows with changes should be clearly marked as needing user attention.
Alerting the user when they may need to update a SoF table (Phase2)
To alert the user when a SoF table needs updating, RevMan Web needs to be aware which analyses are used in a SoF table (and ideally when the data were retrieved). $SofTool could include this as meta-data, if an appropriate API is provided by ReviewDB. The validation report could be used for this.
Creating a SoF table from $SofTool (Phase2)
When a SoF table is created in a project linked to RevMan Web in $SofTool, the table should also be created in RevMan Web.
Synchronising access to reviews (Phase2)
Besides the check for write permission in the authorization flow described above, it is desirable to synchronise access rights between $SofTool and RevMan for a review. This could be done whenever data is pulled on the review, by comparing the author list from RevMan to the list from $SofTool.
...
A user's token may also become invalid for various reasons that require re-authentication, e.g. after expiry of the refresh token. This needs to be handled, but can be assumed to be a rare occurrence.
Non-Cochrane contributors (not included)
$SofTool may want to allow non-Cochrane users of their tool to contribute to a Cochrane review project. These users then need to be added from within the $SofTool. The main issue is that these users won't have a valid Cochrane token, so synchronisation will have to use the token for another user.
TODO: Cochrane to evaluate if e.g. review-scope tokens can be granted to handle this more smoothly.
Editing of the SoF table in RevMan Web (Phase not determined)
Editing of a SoF table owned by $SofTool will not be allowed at all in RevMan Web. We may consider the following in future:
- RevMan Web may allow the user to copy a SoF table created in $SofTool, and modify the copy. $SofTool will have no ownership over the copy.
- RevMan Web may allow the user to "ignore" a SoF table to exclude it from the published review. This also means that it can't be linked to in the text. $SofTool should not set the "ignored" status of SoF tables.
Widget / iSoF linking (Phase2)
$SofTool may want to include a link to the interactive Summary of Findings widget on it's own platform with the static content of the SoF. Ideally this would allow progressive enhancement on the Cochrane Library - where the iSoF widget would be displayed when possible, or display a standard SoF with a link to the iSoF when not.
Depositing of structured data (not included)
Depositing of structured data by $SofTool can be considered, but we would need to identify a common format between the tools, and the use cases we want to enable. These could be related to publishing/CLib, linked data, or prioritisation. Consultation needed.
Future considerations - changes to data structures (not included)
Should be more easily/reliably able to identify Intervention/Comparator and Outcome for an analysis. Might we also be able to make it easier to identify the Population?