Hi Louise,

If you can see the two codes by the two reviewers I have an alternative solution for you that I use instead of using the comparison coding function. What I do is I create individual codesets for each reviewer (See below).

You can then use the search function to find the decrepancies between the reviewers by searching for each reviewers codes individually, and then using the combine function to find all the permtations of errors. In my example there would be 9:

Fuchsia [F] Relevant [R] and Wil [W] R

FR and W Unsure [U]

FR and W Not Relevant [N]

FU and WR

FU and WU

FU and WN

FN and WR

FN and WU

FN and WN

This is nice because you can then look at the really important decrepancies first (Relevant and Not Relevant).

So what could do, is create two new codesets (one for each reviewer) and then have the reviewers copy their coding to the new codesets. Then use the search function to find the decrepancies and resolve them through informal discussion. When you resolve the decrepancies I would suggest making an "Executive Codeset" that you code the final decisions into so you can keep track of the number of decrepancies if you need to calculate IIR.

|Cheers, Wil

Hello Louise,

I found the item 'An evaluation of outreach of the Nutrition Program for the Elderly' (ID:36791816) that was causing the problem. There were 2 instances of the code you had selected for this item (INCLUDE for second opinion). Once I removed one of them I was able to click on 'View' stats without the the error message appearing.

If we can ever figure what causes that error we will fix it.

Best regards,

Jeff

Hi Julie,
please accept my apologies for missing your call for help for such a long time. I failed to notice it within the existing thread: my bad. Do remember that we are always contactable also via email (EPPISupport@ucl.ac.uk).

Re your present problem, this is a known bug which we've been unable to eliminate because we could never replicate it. In a nutshell, sometimes it happens that people find a way to create two copies of their own coding (something that isn't supposed to happen - and after spending many hours/days investigating, we still don't know how it happens). This doesn't create problems to most functions, but does break comparisons.

To solve the problem, the only way is to manually fix the data (eliminate the unnecessary second copy), which naturally is something we have to do on a pre-case basis. I will do it after sending this message and report back when done.

This issue is quite rare, we presently log 3-5 incidents of this sort per year, but I understand its rarity doesn't make it less annoying for you.

Many apologies for the inconvenience and the late reply. Hopefully the issue hasn't prevented you from progressing your review.

Dear all,

We are very concerned about this issue and we are experiencing the very same error in the shared review ID: 15908, after screening 5631 titles and abstracts.

As we clearly saw this was a system bug we directly contacted eppisupport@ioe.ac.uk yesterday. However, as another contact was posted in this forum I would like to know if this was a correct contact. I have not experienced this problem in my previous reviews.

Could you help me with this issue?

Sincerely