Below we use $SofTool to generically refer to GradePRO or MAGIC.
Creating a linked account (Phase1)
Users will log in to $SofTool using their Cochrane Account. If they did not log in previously, this will create a new account in $SofTool linked to their Cochrane Account.
Any Cochrane-review linked projects that were previously created will be shown in their list of projects.
If a user's details have changed on their Cochrane Account, they are also updated in $SofTool upon login.
It is possible that accounts are de-duplicated in Archie, in which case the person ID may change, in which case the account link is lost, and the user would end up in a new empty account. There is a RabbitMQ event stream that would allow $SofTool to handle these events automatically. However this is not a hard requirement, as this is expected to be extremely rare at the stage where someone is a Cochrane author. So handling any cases through support when they arise would be acceptable. Cochrane will be able to confirm if a de-duplication took place for a particular ID.
Create a SoF table from RevMan Web(Phase1)
RevMan Web will have a button to "Create Summary of Findings table in $SofTool". This will link out to $SofTool to a Cochrane namespaced URL, e.g. POST ${createCochraneSofUrl}?reviewId={reviewId}
- If there is no logged in user, the user is prompted to login.
- The login prompt can be Cochrane-specific, as the user is coming from another Cochrane tool.
- If the logged in user doesn't have a linked Cochrane Account, permission is denied.
- If the linked Cochrane Account does not have write permission to the review, permission is denied.
- If there is already a project in $SofTool for {reviewId}, this will create a new SoF table within that project. If there isn't one, this will create a project linked to the relevant Cochrane review, and create a new SoF table within that review.
- The newly created SoF table will be opened for editing in $SofTool.
$SofTool will query ReviewDB for the relevant information to populate a SoF table, and present a similar user interface as currently for projects based on a RM5 file.
$SofTool will create the SoF table in RevMan Web as soon as it has been set up. It will persist the ID of the SoF table in RevMan Web, so that changes to the SoF table can overwrite the previously inserted SoF table.
$SofTool will update the SoF in RevMan Web whenever it is saved in $SofTool (but throttling to limit rapid-fire updates is acceptable).
$SofTool will have full ownership of the SoF table in RevMan Web. The user will not be able to edit the SoF table directly in RevMan Web, and will instead be directed to $SofTool to do so. $SofTool may overwrite the contents of a SoF table it owns at any time. Deleting the SoF table can only be done in $SofTool.
RevMan Web will have a button to "Edit Summary of Findings table in $SofTool". This will link to $SofTool to a Cochrane namespaced URL, e.g. GET ${editCochraneSofUrl}?reviewId={reviewId}&sofTableId={sofTableId}, where {sofTableId} is the RevMan Web ID of the SoF table.
ReviewDB will provide an API to retrieve analysis results (this does not currently exist).
Updating a SoF table when the underlying data changes in RevMan Web (Phase1)
$SofTool will allow the user to check for changes to the review. This may happen on login to $SofTool, but the user should also be able to do this by clicking a "Check review for changes" button. $SofTool will check which SoF tables are affected (if any), make the required changes, and alert the user to them if necessary.
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
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
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
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.
It may also be that the user does not have the right to read or write the review, although he/she is a author. This could be when the review is in editorial phase, or when it is checked out from Archie. This would result in errors returned from the ReviewDB API. In those cases changes to be pushed need to be queued up. Messaging to the user is also needed.
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
$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
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
$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
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
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?