Version 4.17.1.0 includes a new type of "duplicates report" and a (for now) restricted to selected people/reviews new "auto reconciliation" mode for priority screening.
New Features
Duplicates report (type 3)
In the "References" tab, the submenu of the "Export to RIS" button offers a number of "not about coding" reports. These include two reports about duplicates, showing information about what items are or have duplicates and what their source was. We've been asked to create a 3rd type of report, which is more or less a "combination" of the two pre-existing reports.
Experimental "auto reconcile" mode: Retain All Include Codes (RAIC)
This mode is currently hidden to ordinary users, as it requires thorough testing and validation, which will be done as soon as possible, as we (at the EPPI Centre) plan to use it for a family of already active living reviews.
The RAIC auto reconcile mode is designed to support a very specific (and emerging) workflow, whereby a number of related living reviews share a "multi purpose" screening on title and abstract phase, after which references are routed to one or more "review-specific" screening on full text steps.
To, support this workflow, RAIC adopts the already implemented general "safety first" approach (Exclude decisions need to be unanimous, Include decisions trump exclude ones, in case of disagreements) but extends it to support the application of multiple screening codes to items.
All previously implemented "auto reconcile" modes work on the assumption that in the vast majority of cases each screened reference will receive one "code" (either an include or an exclude code) and very rarely two or more. RAIC, in contrast, expects included references to often receive multiple include codes, one per review-specific phase of screening on full text.
To make this work, RAIC creates the "agreed screening coding" in the name of a placeholder user ("Auto-Reconcile User") which will include all include codes picked by any reviewer (if any), or all exclude codes (when no reviewer picked an include code).
Should our internal trial work well, we expect to make this feature public in the next release.
New "Latest changes" link in the footer
The EPPI Reviewer login page includes a short summary of what changed in the latest release, and provides a link to the corresponding "announcement" post. This system isn't ideal to keep users informed, because most users do breeze through the login page and may not notice the "what's new" section. For this reason, we've added a new button to the footer of internal EPPI Reviewer pages. This button shows the current version number and is brightly coloured when the version is new. Clicking on the button opens a new tab showing the corresponding announcement post.
In-app help system
EPPI Reviewer includes a system to get contextual help in real-time. The "Help" button on the top left of the header is "aware" of what page the user is on, and will show help dedicated to that page (if present). Under the hood we've done a number of changes that will help us to keep the relative help content up to date and relevant.
"Imported Id" of references
In the "Edit Reference" page, the "Imported ID" field is now editable. Until now, it was read-only.
New "Oldest known Id" field for codes and coding tools
Codes and coding tools can be and are often "copied". To help track coding tools provenance, the corresponding records in the database have an "Original Id" field that is automatically populated whenever a coding tool is being copied, and points to the Id of the record that is being copied. This helps to show relations within "one generation" of copies. However, it's often useful also to be able to quickly find out what the oldest know "origin" of a given tool (and codes therein) was. For this reason, EPPI Reviewer now:
- Tracks the "Oldest known ID" for all copies that are generated after this release.
- Shows the "Oldest known ID" and "Original Id" values (when present) as read-only properties of coding tools and codes within the "Edit coding tools" pages.
- Includes these fields in the "JSON (quick) coding report".
Bugfixes
Running Configurable reports while using the "selected items" option could fail to respect that option and run the report using a (previously selected) "all items with this code" selection.
Running Configurable reports using the "items with this code" option would fail if the code selected had been added to the same item more than once, which is possible, and expected, when using (intervention) arms.
When using "linked items" it becomes possible to add PDF coding to the item representing the whole group of linked items, while using the PDFs that were uploaded to any of the items that belong to the group. Configurable reports were not showing this coding information (while quick coding reports did) when reporting about the item onto which the PDF coding was added (i.e. the one chosen to represent the whole group of linked items).
These problems are now solved.
Searching for items "with/without any code from this coding tool". These searches could target the wrong coding tool, whenever the tool chosen had a not-unique tool name within the review. This problem is now solved.