How dual screening and team collaboration work in Study Screener
Owner invites collaborators with roles, reviewers screen independently (blinded), disagreements land in the workspace inbox, and the owner records a final decision that persists with an audit trail.
Study Screener supports dual independent screening in a single workspace. The owner invites collaborators with an explicit role. Reviewers record Include / Maybe / Exclude independently while the project is blinded. As soon as there are disagreements (or any Maybes), a compact “Disagreement inbox” appears in the workspace: sample titles, quick search, and an export. When the project is opened, the owner resolves selected items to a final decision. Those resolutions are persisted with who/when and do not vanish on refresh; original votes remain in the log.
The flow at a glance
- Invite collaborators from the team strip (“Invite team members”). Choose a role:
- Reviewer: can screen and see the disagreement inbox in read‑only mode until the project is opened.
- Viewer: read‑only.
- Reviewers screen independently (Include / Maybe / Exclude). While blinded, team details are hidden; after opening, the team strip shows member count, Open status, and κ summaries per reviewer pair.
- Disagreement inbox: once open, a collapsible bar appears in the workspace with counts (e.g., “1 conflict · 1 maybe”), sample titles, search, and “Export CSV”.
- Owner resolves: select one or more rows and choose Include or Exclude. The inbox re‑hydrates from the server — no optimistic deletions — and previously resolved projects surface a compact “All disagreements are resolved” notice with an export button in the same place.
What persists and what stays auditable
- Final decisions are written to the project’s resolution table with resolver, timestamp, and optional notes. These decisions become the effective status for every member’s filters and exports once the project is open.
- Original human votes are not rewritten. They remain visible in team views and in the screening log to preserve auditability and kappa math.
- Resolved counts and the completed notice survive a refresh because the queue re‑loads from the server after each action.
Concrete proof (walked path)
- Invite with role:
- UI: team strip button “Invite team members”; modal shows “Role” selector with “Reviewer (can screen)” and “Viewer (read‑only)”.
- Owner can “Resend” and “Cancel” pending invitations from the same modal.
- Dual decisions:
- While blinded, the inbox area shows a one‑line notice (“Disagreement inbox (blinded)”); reviewers screen independently.
- After opening, the team strip shows “Open” and κ next to reviewer pairs (e.g., “κ 0.61, 0.47…”).
- Disagreement inbox:
- Collapsible toolbar labeled “Disagreements”, count chip “N conflict · M maybes”, quick “Search”, and “Export CSV”.
- Clicking a title dispatches focus to the study pane.
- Resolve with audit:
- Owner‑only include/exclude actions on selected rows.
- POST to the resolve endpoint; the queue immediately re‑fetches team results. On completion, the notice reads: “All disagreements are resolved. Downloads are in the left column.”
Related reading
- Methodology background: Dual‑screening conflicts and Cohen’s κ at title/abstract
- Primer: Getting started with systematic reviews
- Basics: What is screening in a systematic literature review?
