Version 6.16.3.0 adds DeepSeek to the list of Large Language Models available for Auto-Coding tasks. Additionally, it includes significant improvements on how the Coding tools are shown/handled, and a new search type. There are also new functionalities available in the Account Manager (which has a marginally renewed "look") and a couple of bug fixes.

New LLM-coding model available: DeepSeek

Earlier this year, DeepSeek made headlines as a new groundbreaking Large Language Model which happens to be remarkably accurate and, at the same time, cheaper than comparable OpenAI models, both to run and to build (especially the latter). This release includes some substantial "behind the scenes" work to support the usage of not-OpenAI models in EPPI Reviewer. Having obtained this possibility, we implemented the connection to the DeepSeek model without further ado.
DeepSeek is a "reasoning" model, which returns a description of how the model supposedly reached the answers it supplies, along with the answers itself. However, in EPPI Reviewer, there is no clear "place" to store/show/use this "reasoning" part of the DeepSeek output, so, regretfully, this part of DeepSeek answers gets discarded by EPPI Reviewer.
On the other hand, the "reasoning" part of DeepSeek's answers is not optional, so it always contributes to its cost in the form of "output tokens". The consequence is that DeepSeek is not as cheap as it may look: while the cost per input/output tokens we currently charge is low (£1 and £3 per million input and output tokens), DeepSeek generates more output tokens than the other models currently available, increasing its cost.

New feature: expanding/collapsing coding tools

The full "forest" of coding tool trees appears in three main places within EPPI Reviewer: the left-column in the main screen, in the "Item Details" page, and in "Edit coding tools". Until now, the expanded/collapsed state of the trees shown was retained for the main screen, and automatically arranged upon opening the "Edit coding tools" page (to show the currently selected code). However, when opening the Item Details page, the trees were always shown as collapsed.
This arrangement was far from ideal and is now changed as follows:

1. The expanded/collapsed state of nodes is now preserved across all three pages, so that the same state is carried over and remains consistent within EPPI Reviewer.
2. Additionally, if necessary, when reaching the "Edit coding tools" page, the required nodes are automatically expanded (and the vertical scrolling adjusted) so to make currently selected code visible.
3. In the Coding Only UI, the coding tools appear only in the "Item Details" page, the expanded/collapsed state of nodes is now remembered when users switch back and forth to/from this page.

We also added a much requested new functionality: expand/collapse all codes from here. When clicking on a code name (which "selects it / activates it"), if the code has children a new icon appears to the right of the code name. This icon allows to expand or collapse all nodes that appear "downstream" to the selected code, with just one single click.
Together, these two features should speed up common activities in EPPI Reviewer, perhaps substantially.

New feature: create search results from the current Priority Screening list

Priority screening relies on an ordered list of items, built by applying the most recent model created from already made screening decisions. This process assigns a "score" (from 0, up to, but excluding 1) to each item (representing the likelihood of inclusion), and the list is thus ordered accordingly.
On occasion, it is useful for users to "peek" into this list, but until now, the only way to obtain these details was to contact EPPI Support. We have now added a new type of search: "From Current Priority Screening List". This option only appears when there is a useable Priority Screening list present (i.e. a list is present, and contains at least one item that still needs to be screened).
Searches created via this new option will generate search results that are similar to ordinary "Classifier" results (can visualise the scores distribution, and use the functions that come with it). Scores associated to items in these searches are distributed in the range between 0 and 999, rather than between 0 and 99 (like regular classifier results).
When this new feature is used against a priority list that is currently in "Random mode", the search results will list all items in the list, but will not order the items in their relevant to-be-screened (random) order, this is because items in this type of list have no score.

Additionally, when a list of "Classifier" search results is retrieved, EPPI Reviewer now automatically sorts the current page in the list "by score, descending".

Account Manager: new "credit transfer" features 

• Transfer credit from unactivated (ghost) accounts to an existing account. From the online shop, it's possible to purchase "new accounts", which get created as what we call "ghost accounts", to signify that they are "not yet functional"; such accounts don't have email, username and password values, and can be "activated" at any time after purchasing them. They hold a given number of "months credit" which will be applied when they get activated. Sometimes people may find that they would like to use the "months credit" purchased for a not-yet-used ghost account to renew a different (existing and fully functional) account. This is now possible via a new "Transfer" link available for ghost accounts in the "Summary" tab of the Account Manager.
• Users can also purchase "credit" as a lump sum that can be used later, for example, to renew subscriptions as and when necessary. Sometimes people renew subscriptions in this manner, and then realise the renewal wasn't needed/necessary and would like to undo it. This is now supported by the Account Manager, via "RTC links" (RTC stands for "return to credit") in the "Credit history details" table that can be obtained from the summary page. In writing this feature, we opted for a "safety first" approach, whereby the link is made available if/when it is absolutely sure that, given the renewal history of a given account, the action would be permissible. For all other cases, please contact EPPI Support.
• We have refreshed the look and feel of the main pages/tabs in the Account Manager too. So to make it look a little bit less "dated".

Improvement: editing Items

Up until now, EPPI Reviewer 6 used an "optimised for speed" system to save changes of edited items. This system was sending the request to save the changes and did not reload the item data in the user interface after receiving the signal that the save operation succeeded. This created a number of small oddities, for example the "edited by" value and  "authors" string wouldn't update immediately. We changed what happens upon saving edited items, so that EPPI Reviewer retrieves the just-saved item from the database after saving it, so to show it in its final state. We also saved how the authors string is shown in the user interface: before it took the form of "author1 ; author2 ; [authorN]", i.e. the semicolon separator had a space before and after it. This has been changed to "author1; author2; [authorN]" (no space before the semicolon).

Bugfix: LLM-coding batches running out of credit

EPPI Reviewer supports the use of LLMs for automatically assigning codes to references. This functionality becomes available when people purchase some Credit and then make it available for "auto-coding" within a review. Unfortunately, our initial implementation of the "cost tracking" system had a couple of bugs, which made EPPI Reviewer react in undesirable manners when the purchase credit ended. These problems have been fixed. The implemented behaviours are as follows:

1. Upon queueing an auto-coding batch, EPPI Reviewer looks for credit records that contain at least £0.01 still available. It assigns the 1st such record to the batch, at "submission time".
2. If no such credit is found, an error is shown in the user interface immediately.
3. Upon running a batch, the amount of credit left is computed after processing each item. If the amount remaining drops below £0.01, the batch stops. In the batch log, the last error included will report "Error: There is no credit (left) to use" and mention the ItemId of the first item that was NOT processed.

The above thus allows people to detect the "there was no credit left" situation, purchase additional credit and re-submit new batches, while taking into account what items were or were not processed.

Bugfix: per-item comparison coding report

Not selectable codes were being ignored in this report. This is probably OK in most cases, but can be very confusing or misleading in some contexts, so it has been fixed. From now on, if a "not selectable" has been applied to the current item, this fact will be visible in per-item coding comparison reports.