Linkedin Envelope
Contact

Automated literature research

Systematic literature reviews are slow for a boring reason: the same publications have to be found across several databases, stripped of duplicates, and then judged one by one against criteria that live in someone’s head. We built a platform that does the finding and the bookkeeping, so the reviewers only do the judging.
A review starts with one research question and ends with hundreds of candidate publications pulled from separate databases, each with its own interface, its own export format and its own duplicates. Teams track the screening in shared spreadsheets, read what, who scored what, why a paper was, and by the second review round the file is no longer a reliable record of anything.
For a customer in the health products sector, that process had to be repeatable, defensible and auditable. So it had to stop being a spreadsheet.

What we built

  • One query, four databases.

    A single search runs against PubMed/Medline, the Cochrane Library, the FDA MAUDE device database and the EU Clinical Trials Register. Each source has its own crawler behind a common interface, so adding a fifth database is a contained piece of work rather than a rewrite.

 

  • Automatic deduplication.

    Results arriving from different sources are matched on publication identifiers and collapsed into one record, so the same paper is never screened twice.

 

  • Searches run in the background.

    Queries are queued and executed by a worker process, with visible state, running, done, so a large search doesn’t block anyone’s browser and progress is never guessed at.

 

  • Multi-phase screening.

    Reviews progress through numbered phases, mirroring the way systematic reviews actually run: a broad screen, then a narrower one, then full text. Publications judged relevant in one phase are carried into the next automatically; the rest stay on file with the reason they were dropped

 

  • Relevance rules you configure, not code.

    Each phase has its own questions, yes/no or scored, and a rule set decides what “relevant” means: at least *n* of these criteria, at most *n* of those, a minimum or maximum point total, evaluated across combinations of answers. The definition of inclusion becomes an object in the system instead of a convention in a team’s memory.

 

  • Several reviewers on the same review.

    Users belong to an organization, work through the same phases, and answer the same questions independently.

 

  • A complete history of every judgement.

    Every ranking and answer is versioned, changed what, when, and what the value was before. When a decision is challenged months later, the record is there.

 

  • Runs on your own infrastructure.

    Containerized, PostgreSQL-backed, deployable in-house, which matters when the review underpins a regulatory submission.

Have a process like this one?

Repetitive searching, manual consolidation, judgement calls recorded in a spreadsheet, the shape recurs in far more industries than literature review. If that sounds like something your team does every month, it’s usually worth automating.
Talk about your project