CaseAIOnderzoeksondersteuning

Een onderzoeksgroep screende voor elke systematische review duizenden titels met de hand. Een AI-ondersteunde screeningsomgeving sorteert nu voor, terwijl elke beslissing bij de onderzoeker blijft.

Klant
Academische onderzoeksgroep
Sector
Onderzoek en kennisinstellingen
Periode
2026 · 8 weken

Een onderzoeksteam dat regelmatig systematische reviews uitvoert.

Deze case is op verzoek van de klant geanonimiseerd. De situatie, de aanpak en de resultaten zijn echt.

01

De situatie

Voor elke systematische review exporteerde het team duizenden zoekresultaten uit literatuurdatabases naar een spreadsheet. Twee onderzoekers beoordeelden onafhankelijk van elkaar titel voor titel of een artikel relevant kon zijn, en vergeleken daarna hun uitkomsten in een derde bestand.

Bij een gemiddelde review ging het om vier- tot zesduizend titels. Die eerste screening kostte per review al snel drie tot vijf werkweken van twee mensen.

02

Het probleem

Het screenen zelf is geen ingewikkeld werk, maar het is veel, eentonig en foutgevoelig. Juist bij duizenden titels op rij verslapt de aandacht, terwijl één gemist artikel de kwaliteit van de hele review raakt.

Wat concreet niet goed werkte:
  • Drie tot vijf werkweken per review gingen op aan het lezen van titels en samenvattingen.
  • Verschillen tussen beoordelaars werden pas achteraf zichtbaar, in een handmatige vergelijking van spreadsheets.
  • Er was geen vaste plek waar de reden voor een in- of uitsluiting werd vastgelegd.
  • Bestaande commerciële tools sloten niet aan op de interne werkwijze en op de eisen rond gegevensopslag.
03

Het doel

Het doel was een applicatie die het screenen versnelt zonder dat de onderzoeker beslissingen uit handen geeft. Elke in- of uitsluiting moest een menselijke beslissing blijven, herleidbaar en met een reden.

Daarnaast wilde het team kunnen aantonen dat de werkwijze niet ten koste gaat van volledigheid, omdat reviews anders niet publiceerbaar zijn.

04

De aanpak van CodeSprinter

Bij AI in onderzoek is de eerste vraag niet wat het model kan, maar wat de onderzoeker moet kunnen verantwoorden. Daar hebben we het ontwerp op gebouwd.

  1. 1

    Screeningproces in kaart

    We liepen twee lopende reviews mee en legden vast waar tijd verloren ging: niet in het beoordelen zelf, maar in het sorteren, vergelijken en terugzoeken.

  2. 2

    Voorsorteren, niet beslissen

    Het model rangschikt titels op verwachte relevantie en licht toe waarom. Het sluit nooit zelf iets uit; het bepaalt alleen de volgorde waarin onderzoekers lezen.

  3. 3

    Prototype op een afgeronde review

    We testten het prototype op een review waarvan de uitkomst al bekend was. Zo konden we meten hoeveel relevante artikelen bovenaan de lijst belandden.

  4. 4

    Dubbele beoordeling ingebouwd

    Twee onderzoekers screenen onafhankelijk in dezelfde omgeving. Verschillen worden direct zichtbaar en in de applicatie besproken en vastgelegd.

  5. 5

    Gegevens binnen de eigen omgeving

    De applicatie draait op de eigen infrastructuur van de instelling. Alleen titels en samenvattingen gaan naar het taalmodel, nooit patiëntgegevens.

05

De oplossing

We ontwikkelden een webapplicatie waarin een onderzoeker zoekresultaten importeert, het model de lijst laat voorsorteren en vervolgens titel voor titel beoordeelt, met bij elk artikel de toelichting van het model en de beslissing van de collega.

Een dashboard toont per review hoe ver beide beoordelaars zijn, waar ze van elkaar afwijken en hoeveel relevante artikelen inmiddels zijn gevonden. Elke beslissing wordt met reden en tijdstip vastgelegd, zodat de methodesectie van de review direct is te onderbouwen.

Schematische weergave van het proces. Bij geanonimiseerde cases tonen we geen productbeelden.
06

Belangrijkste functionaliteiten

  • Import uit gangbare literatuurdatabases
  • Voorsortering op relevantie met toelichting per artikel
  • Onafhankelijke dubbele beoordeling
  • Overzicht van verschillen tussen beoordelaars
  • Vastlegging van de reden per in- of uitsluiting
  • Export voor de methodesectie en het PRISMA-stroomdiagram
07

Het resultaat

  • 62%minder screeningstijd, gemeten over de eerste drie reviews
  • 100%van de beslissingen door een onderzoeker genomen
  • 0relevante artikelen gemist in de vergelijking met een afgeronde review

De eerste screening van een review kost nu ruim een week in plaats van drie tot vijf. Omdat relevante artikelen vrijwel altijd bovenaan staan, kan het team eerder beginnen met het inhoudelijke werk. De vastlegging per beslissing maakt de reviews bovendien makkelijker te verantwoorden.

Wat we onderweg leerden
  • De voorsortering werkt goed bij duidelijk afgebakende onderwerpen. Bij brede vraagstellingen is de winst kleiner, en dat zeggen we ook.
  • We hebben bewust geen automatische uitsluiting gebouwd, ook al zou dat nog meer tijd schelen. Het team moet kunnen zeggen dat elke titel door een mens is gezien.

Het model neemt ons geen beslissingen af. Het zorgt dat we onze aandacht besteden waar die het meest oplevert.

KlantquoteSenior onderzoeker

Besteedt jouw team ook weken aan werk dat vooral aandacht vraagt?

CodeSprinter bouwt AI-toepassingen voor onderzoek waarin het model voorsorteert en de onderzoeker beslist. We bespreken graag waar dat in jouw proces verantwoord tijd bespaart.