Screening Hierarchy#555

When screening articles, there are a few problems that I often encounter:

1) Many articles should be rejected for mulitple reasons. Usually, some rejection reasons are more important to the project than others, or are more-or-less general cases of another exclusion reason.

2) Especially when there are many rejection reasons, it can be easy to miss/mis-assign rejection reasons.

3) The current method is prone to inconsistent ratings–both between users and within a single user.

All of this chis can be a problem for which articles are ultimately included, but also when the project criteria are changed and previously-screen articles must be rescreened. More accurate rejection-placement would greatly increase the speed and accuracy of these rescreenings.

This may be remedied by a hierarchy of rejection reasons. This could be arranged either as a nested list or, maybe more interestingly, as a decision tree wherein the user is led through a series of questions that terminates at either “Include” or the most appropriate rejection reason.

Hey Nick! We do in fact allow you to configure exclusion reasons into a hierarchy. This is presented as a nested listing. See documentation here: https://wiki.nested-knowledge.com/doku.php?id=wiki:autolit:screening:configure&s[]=exclusion&s[]=reason#editing_ordering_and_deleting_exclusion_reasons

Let me know if that solves your problem; I will leave this issue open either way though, because I like the idea of allowing you to configure exclusion reasons as questions.

I think the biggest change in this proposition is selecting multiple exclusion reasons per record. We’ve had this request prior but decided against adding for a couple reasons:

1. It harms usability for a majority of users. e.g. single click exclusion + jump to next record is no longer possible, e.g. exports all may have multiple reasons vs one, adjudicating multiple/partially overlapping exclusion reasons becomes hard.
2. The functionality you are really talking about sounds a lot like tagging-in-screening.

We don’t do a great job of (2) currently, for example:

• By allowing specification of screening-specific tagging questions
  • This is somewhat possible via grouping questions by root tag & then making your screening questions the first root.
• Providing a way of marking a record as tagging-during-screening complete without having screening being complete yet.

The idea being you’d apply bulk actions to discriminate applied tags / answered questions into exclusions/inclusions as your study protocol changes.

In summary– I’d propose addressing this concern by making tagging-in-screening a better supported feature, such as:

1. Better supported inside the existing screening module (e.g. Nick’s proposition of FBT responses auto-designating an exclusion reason)
2. A precursor module to screening
3. An alternative screening mode