This page will document our evolving understanding of interactions between Covidence and Cochrane tools (Archie, Reviews DB, RevMan Web, RevMan 5). Initially it will mostly track use cases and topics for discussions, but it should evolve into a shared specification of how these interactions will work.

TODO: integrate FORP-CAST minutes.docx - notes from Seoul Colloquium 2016

Current interactions

  • Covidence uses Archie's OAuth flow to authenticate Cochrane users
  • Covidence can do a "bare minimum" title search to find Cochrane reviews so that users can link the Covidence project to a review, and thereby get free access to Covidence
  • Covidence can load a RevMan 5 file to insert/append Covidence data into; however ability to merge data is very limited due to mismatch in data models

Desired interactions

TODO: populate from slides and notes

Desired interactions from RevMan:

  • Know that Covidence is being used for this review
    • Could be simple ping-back
  • Jump to Covidence page for this review
    • Should be easy given ping-back, but question: what happens if the user clicking through did not previously register with Covidence? Should we just use the OAuth flow?
  • Know the overall status of this review in Covidence
    • Could be simple API call, but what information is needed?
  • Show when Covidence holds extra information for a study – eg RoB annotations – see attached mockup
    • This seems more complex.
  • Jump to the Covidence page for a study
    • Should be simple, but Covidence does not currently have a unique page for a study. There are separate pages for RoB and data extraction, which are linked from an overview of studies. However, this might change.

Desired interactions from Covidence:

  • CRS could be used for studyfication
  • Crowd data could be used to filter out non-RCTs (if those are excluded)

Tighter linkage between "Cochrane Review" and "Covidence Project"

Currently, a Cochrane user of Covidence has to go create a project in Covidence, and then use a title search to find their (pre-existing) review. This process feels somewhat backwards. In addition, there is the question of what happens if another user links their project to the same review. Ideally, there should be only one Covidence project for each review. Can we align things so that:

  • There is a one-to-one relationship between Cochrane reviews and Covidence projects
  • Anyone with author permissions on the Cochrane review automatically also has access to the Covidence project
    • Covidence is going to work on organizational accounts, those models could map more easily to Archie permission structures, so that a review team could own the review instead of whoever created it first.
  • Authors can initiate a covidence project from RevMan (and Archie?)
  • In Covidence, display to a Cochrane user which reviews they have access to, and which ones are already present in Covidence
  • In RevMan and Archie, show which reviews have a Covidence project associated with them, and allow linking out to those projects

There is also the question of what happens when a review is being worked on simultaneously in RevMan Web and Covidence. Potentially working in Covidence could lock the review, similar to how a checkout to RevMan 5 works, or how RevMan Web's offline mode will work. Then vice versa, once the lock on the Reviews DB is released, should the Covidence project also be locked?

  • Question: Do we want to avoid locking? If so, does the reviews API provide version information for entities?

Problem areas

There is a mismatch in data model and data granularity between Covidence and RevMan. The most important of these seems to be that RevMan works in terms of comparison tables, whereas Covidence extracts data per arm. Mapping Covidence data to a RevMan file with no data is generally not a problem, because the RevMan data can be derived from the Covidence data. However, the other way around is more problematic, as the arm-based data can not be back-calculated from the comparison data, and determining from the comparison table which arms are in a study may also not be fool-proof.

  • We are assuming that the updating/syncing problem only needs to be solved for Reviews DB / RevMan Web, and potentially this could be desirable as a unique selling point for moving your review to the web.
  • Is it possible for Reviews DB to support arm-based information in addition to the contrast-based information? That could facilitate round-tripping through Reviews DB and updating reviews. At least it would be helpful to identify arms clearly in the comparison tables.
    • Update: In most cases, RevMan does have the arm-based information, so this is puzzling. Does covidence not use the right data structures in some cases?
    • Question: Is this somehow related to the effect size calculator that will be part of RevMan Web, or is that only concerned with converting between different contrast-based measures?
  • Can Covidence support contrast-based data in addition to arm-based data? Sometimes contrasts are all that is reported in study reports, and this would get around the dis-aggregation problem.
    • Question: Are we correct that this is currently not supported by Covidence? Anneliese should be able to confirm.
  • Action: Gert & Bo to work on comparing domain models, look for ways to better align them.

Other questions

  • If multiple full texts correspond to the same study, do you do a single data extraction for all of those together?
  • Do reviewers sometimes include more than two interventions in the same comparison table?

Mockups

  • No labels