This release represents a major milestone as it marks the point where the "Web" version of EPPI Reviewer is feature-complete, meaning that all essential activities supported by the old client (EPPI-Reviewer4, based on Silverlight) are now supported by the newer version. At the same time, to mark the milestone, we are renaming EPPI-Reviewer Web to EPPI Reviewer 6, while removing the "Beta" qualifier and changing the "version number" conventions. Feature-wise, this release includes a full implementation of Meta Analysis functions in EPPI-Reviewer Web, paired with improvements in the data-entry forms for Outcomes, along with the usual mix of small enhancements and bugfixes.

EPPI Reviewer 6 and new version number conventions.

When EPPI-Reviewer "Web" was launched in 2019, after the soft-launch of the "Coding" web app, it was lacking many advanced functionalities of the full (Silverlight-based) version. We opted for labelling it as "Beta" because of its incompleteness and because of course, its core architecture was still somewhat experimental. The "Beta" label then remained, as EPPI Reviewer "Web" still lacked the full range of EPPI Reviewer 4 functions, most notably the Meta Analysis features.
This release changes this last detail, while in the real-world the architecture of EPPI Reviewer Web is now known to be solid: it is currently used more than 97% of the time. Concurrently, we are renaming EPPI-Reviewer Web to EPPI Reviewer 6, a change reflected in the new look of login and welcome pages.

At the same time, we're changing the meaning of our version numbering system. EPPI Reviewer 6 will now be represented by version number starting with "6." (as in: V.6.x.y.z), EPPI-Reviewer4 will keep its old convention, starting with "4." (as in: V.4.x.y.z). However, both versions share a large amount of code, since what runs on the server side is either exactly the same, or extremely similar. Thus, many changes to the code-base require us to update the server-side code of both versions, which is represented by the remaining version numbers, after the 6 and 4, respectively. Thus, we'll have V6/V4.x.y.z. Where increments to "x" mark major releases, which introduce relatively big/notable additions, "y" mark minor releases, which come with some new functionalities, but of limited scope/impact, and "z" increments, which are used to mark releases that mostly include bugfixes and no or very little new functionalities.
You may wonder why we have moved from version 4 to 6 though! This is because there is an "EPPI Reviewer version 5", but it isn’t available for public access, as it’s designed for internal use at NICE.

Meta Analysis in EPPI Reviewer 6

In the "review home" of EPPI Reviewer 6, a new "Meta-A" button is present. It opens the new Meta-Analysis page, which has been designed to support all (relevant) functionalities of the Meta-Analysis window in EPPI-Reviewer4. As per the core functionalities, understood as those required to configure and run Meta-Analyses, versions 6 and 4 have little or no differences, since the code that runs "under the hood" has not changed at all.

What is different of course is the user interface, which has been designed to improve the user experience in a number of ways.

• When setting up a new Meta-Analysis, a crucial task is that of identifying what outcome measures should be used. For this reason, V4 has a powerful "filtering" system available on the Outcomes table. This system has been ported into V6, made more visible, and hopefully much easier to operate. The filtering settings and Outcome selections are saved along with the Meta-Analysis and are compatible with both versions.
• The Outcomes table is also extensible, allowing us to display more coding data associated with outcome measures. The system to add and remove optional columns in V6 has been re-designed for better usability and remains compatible with V4.
• Options to run Meta-Analyses, on the other hand, are not saved in the database, and now sit in separate panels, which hopefully makes them easier to use, and also removes the ambiguity between what options are saved (outcomes optional columns, filters, sorting and selections) and what doesn't (options to run an analysis).
• EPPI Reviewer doesn't try to support all possible analyses that may be useful and aims instead at lowering the entry barriers of conducting Meta-Analyses. The side effect of this approach is that very often, people will need to export their data, so to run analyses in specialised software. To support this requirement, V6 extends the range of export formats, which are available (and apply to) the Outcomes table.
• V6 also includes a new streamlined system to identify "networks" of outcomes, which may be suitable for running Network Meta-Analyses. However, it's important to note that these functionalities only look at what's "technically possible" as they "map" only "interventions" and "comparators", while they ignore all other PICO dimensions, as well as time-points. Thus, they can be used to guide the first "search" for networks to analyse but do require people to think carefully about the logical validity and feasibility of any Network Meta-Analysis that can technically "run".

Outcomes input form

In Version 6, the outcomes form has been refactored to improve usability, resulting in a number of improvements which are mostly too subtle to list here. However, they also acquired two new capabilities and one bug-fix:

• Copy outcome: studies often report multiple outcome measures, taken at different time-points. For this reason, it can be convenient to create exact copies of an existing outcome, which can then be edited to change name, time-point and effect measures as needed.
• Unselecting drop-down values: outcomes can (and usually should be) associated with values from multiple drop-downs (intervention, comparator, time-point, arms, and more); until now, it was not possible to remove such selections (they could be changed, but not removed).
• Bug-fix: deleting Arms. Upon deleting Arms, EPPI-Reviewer Web was not reporting about "Outcomes associated with an Arm" and was only accounting for "Codes associated with an Arm". This problem has been resolved and the relevant "confirmation dialog" now reports both figures (when relevant).

Sorting tables in V6

Version 6 is a JavaScript (/TypeScript) client, which is rich in "client-side" functionalities. One of these is the ability to sort tables by different columns. However, JavaScript has an odd default behaviour when sorting text: unlike most other systems, it is case sensitive by default. This meant that in multiple places, sorting by a text-based column was using the case-sensitive JavaScript approach, which is usually undesirable. This oddity should now be entirely removed from the user interface of version 6.

Bug-fix: deduplication

Deduplication could sometimes systematically fail, when new references included some titles written in non-Latin characters and ending with a space. This problem was obviously very rare but would prevent the completion of "find new duplicates" routines in the affected reviews and has now been solved.

Other legacy functionalities in version 4

With the end of the lengthy Beta phase of the (formerly known as) "Web" version, we are also explicitly identifying as "legacy" some functionalities that are present in version 4, but are not planned to be ported into V6 in a 1 to 1 fashion. The most visible is the "diagrams" function, which relies on an ancient and proprietary component, so is virtually impossible to port into V6 while remaining compatible with both versions. For the purpose of creating PRISMA diagrams, we recommend to collect the "data flow" figures (mostly done via frequencies) and then use this utility to create and update the diagrams as needed.
Most of the other legacy functions can be found in the Meta-Analysis area, where functions such as "Run (old method)", "Sub-group analysis" and "GRADE" can be found.
In some cases (Diagrams, Sub-group analysis) the current plan is to write new functionalities as part of larger upcoming upgrades, which will meet (and exceed) the requirements of the old legacy functions. In other cases ("GRADE" and some other minor features), we do not plan to re-implement such functions in version 6. Please do note that our plans are always flexible, so please do get in touch in case there is one or the other function in EPPI-Reviewer4 which you presently rely on and wish to see implemented in Version 6!