Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Below we use $SofTool to generically refer to GradePRO or MAGIC.

Creating a linked account

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.

...

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

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}

...

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

$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.

...

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?