Introduction

By the end of Lessons 4 and 5, a review team holds the results of several database searches, documents from websites and organizations, and references found by citation chasing, in different file formats and with overlapping content. Before anyone can screen them, the team has to gather them in one place, count them, remove the copies, and move a clean set into a screening platform without losing a record. This work is clerical, and it is also part of the method: a review that cannot say how many records it found and how many duplicates it removed cannot complete its flow diagram, and a review that loses records during import has quietly narrowed its own search.

This section explains the units that the work counts, describes what a reference manager does, and walks through import and de-duplication with the running case. Sections 2 to 4 cover screening platforms, screening itself and the PRISMA 2020 flow diagram.

1.1 Records, Reports and Studies

Three words recur throughout this lesson, and PRISMA 2020 gives each a specific meaning (Page et al., 2021). A record is the title, abstract or both of a report as it is indexed in a database or on a website. When MEDLINE returns a citation with its abstract, that citation is a record. A report is a document that supplies information about a study, such as a journal article, a preprint, a conference abstract, a thesis, a trial registry entry or a government report. A study is the investigation itself, for example a trial of a befriending program with a defined group of participants, an intervention and outcomes. One study can produce several reports, and one report can be indexed as a record in several databases.

These distinctions matter because different stages of the review count different units. De-duplication works on records: its job is to make sure that each report enters screening once, however many databases indexed it. Linking reports to studies happens later, usually at full-text screening, when the reviewer can read enough to see that a conference abstract from 2020 and a journal article from 2022 describe the same trial. If the team tried to merge reports of the same study during de-duplication, it would have to judge study identity from titles and abstracts alone, and it would risk discarding a report that holds information the full article leaves out.

1.2 What a Reference Manager Does

In a review, the same software does a different job: it serves as the team's central store of records between the search and the screening platform, holding each export in its own collection, finding duplicates and exporting a clean file for screening. Zotero's online group libraries let the whole team work from one shared library. EndNote (a commercial product from Clarivate) and Mendeley (from Elsevier) offer similar functions, and many librarians who support reviews work in EndNote. The principles in this section apply to any of them.

Teams organize this stage in one of three ways, and the choice depends on the size of the search, the tools the institution supports and the preferences of the librarian.

1.3 Exporting and Importing Records

Each database interface exports records in its own way, and the team's first task is to export every record from each final search, with abstracts, in a format the reference manager can read. The RIS format is a plain-text format in which each field sits on its own line with a two-letter tag, such as TY for the type of reference, AU for an author, TI for the title, PY for the year and ER for the end of the record. A fictional record exported in RIS looks like this.

TY  - JOUR
AU  - Lindqvist, Maren
AU  - Osei, Kwame
TI  - A telephone befriending service for community-dwelling older adults: a pilot evaluation
JO  - Journal of Community Ageing
PY  - 2021
VL  - 14
SP  - 112
EP  - 124
DO  - 10.0000/fictional.2021.0112
AB  - Loneliness was measured with a three-item scale at baseline and twelve weeks...
ER  - 

Several practical rules prevent lost records. Some interfaces cap the number of records per export, so a large result set may need several batches whose sizes should add up to the search total. Each file should be named with the database and the date of the search (for example, CINAHL_2026-02-10.ris), kept unchanged as the original export, and imported into its own collection, and the number that arrives should be compared with the number exported. A shortfall usually means that a batch was skipped or that the import stopped at a malformed record.

The Cedar Valley import log above shows the check the intern completed before de-duplication began. The first import of the Embase file brought in only 500 records, because the librarian had exported the results in two batches and the second file had been saved in a different folder. The log made the shortfall obvious, and the second batch was imported before anyone started screening.

1.4 Finding and Removing Duplicates

A duplicate record is a second or later copy of the same report. Duplicates arise mainly because databases overlap: a gerontology article in a well-known journal is likely to be indexed in MEDLINE, Embase, CINAHL and PsycINFO, and to appear in Web of Science as well. Duplicates also arise within a single database when a report is indexed twice, for example once as an online-first version and again in its print issue.

De-duplication can go wrong in two directions. A false-positive merge joins two records that describe different reports, and the second report disappears from the review before anyone screens it. This error reduces recall, which Lesson 3 identified as the property that reviews protect most carefully. A false-negative leaves two copies of the same report in the set, so screeners see it twice. That error costs time and can produce inconsistent decisions on the same report, but it does not remove evidence, and it is usually caught later. For this reason, teams set automated matching to be cautious and send uncertain pairs to a person.

Matching on fields

Software decides whether two records match by comparing fields. The DOI (digital object identifier) is the strongest single identifier, but older records and conference abstracts often lack it. Titles differ across databases in punctuation, capitalization, spelling and the handling of subtitles, and author names appear as full names in one database and as initials in another. Good matching therefore normalizes fields (for example, by removing punctuation and converting text to lower case) and combines several fields, such as title, first author, year and journal.

The Cedar Valley de-duplication

The intern de-duplicated in three passes and recorded the number removed at each pass.

The 27 duplicates found in the manual pass were mostly pairs in which one record lacked a DOI and the titles differed in punctuation or spelling (for example, "behaviour" in one database and "behavior" in another). The 12 found in Covidence were pairs whose author lists had been formatted differently. During the manual pass the intern also found nine pairs that looked alike but were different reports, including a conference abstract and its later journal article, and kept both records in each pair with a note for the full-text stage.

1.5 Keeping an Audit Trail

An audit trail is a written record that would let another person repeat the steps and arrive at the same numbers. For record management it has three parts: the original export files, kept unchanged; a log of counts for each source and each de-duplication pass; and a copy of the library exported before merging, so that any merge can be checked later.

The records found through grey-literature searching and citation chasing are kept in their own collections and counted separately, because PRISMA 2020 reports them in a second column of the flow diagram. Records from citation chasing should be checked against the database records before they are counted, so that a study the databases already found is not counted twice. Section 4 returns to these numbers.

With 1,870 unique records counted and logged, the Cedar Valley team is ready to move them into a screening platform. Section 2 describes the two platforms most often used for that step.

Introduction

Screening is the process of deciding, record by record and then report by report, which items meet the review's eligibility criteria. With 1,870 records to screen, the fictional Cedar Valley team needs a place where two people can make independent decisions, where disagreements are found automatically, where reasons for exclusion are recorded, and where the numbers at each stage can be counted at the end. A spreadsheet can do some of this for a small review, but it makes blinding difficult, invites errors when people sort or overwrite rows, and leaves the team to count everything by hand. Dedicated screening platforms were built to solve these problems.

This section describes what screening platforms do, compares the two most widely used in health sciences, Covidence and Rayyan, and walks through setting up the Cedar Valley screening project. The decisions themselves, and how to measure whether two screeners agree, are the subject of Section 3.

2.1 What Screening Platforms Do

Most screening platforms share a core set of functions. They import records in RIS and similar formats and check for duplicates on the way in. They present one record at a time, with the title and abstract laid out for reading and with chosen keywords highlighted. They let each reviewer record a decision (usually include, exclude or maybe) without seeing the other reviewer's decision, a feature called blinding. They compare the two sets of decisions and list the conflicts, meaning the records on which the reviewers disagree, for resolution. They store reasons for exclusion and notes, and they export decisions so that the team can keep its own copy and report its numbers.

Keyword highlighting deserves a caution. Highlighting the word "residential" in red helps a reviewer notice that a study may have been set in long-term care, but in the record above the word appears in a sentence that contrasts the program with residential care. Highlights direct attention; they do not make decisions, and a reviewer who screens by colour alone will make errors.

2.2 Covidence

Covidence is a web-based platform produced by Veritas Health Innovation, a not-for-profit organization in Melbourne, Australia, and it is widely used by Cochrane review teams. It is a subscription service, and many universities and health organizations hold licences for their staff and students. Covidence organizes a review as a fixed sequence of stages: import, title and abstract screening, full-text review, and then data extraction and quality assessment, which Lesson 8 covers.

At the title and abstract stage, each reviewer votes yes, no or maybe on each record. By default Covidence asks for two votes on every record, keeps each reviewer's votes hidden from the other, and moves a record forward or out when the votes agree. Records with disagreeing votes go to a list of conflicts for the team to resolve. At the full-text stage, reviewers upload or attach the full text, and an exclusion must be accompanied by a reason chosen from a list that the team writes in advance. Covidence keeps a running count of records and reports at each stage and can produce a PRISMA flow diagram from those counts, which the team should still check against its own log. It also lets the team mark several reports as belonging to one study.

2.3 Rayyan

Rayyan was developed at the Qatar Computing Research Institute and described by Ouzzani and colleagues as a web and mobile application for systematic reviews (Ouzzani et al., 2016). It offers a free plan with limits on features and paid plans for larger teams. Rayyan presents all imported records in a single screening space, where each reviewer marks records as include, exclude or maybe and can add exclusion reasons, labels and notes. In blind mode, which collaborative reviews use during screening, no reviewer can see another's decisions; when the team turns blind mode off, the platform shows where decisions conflict, and the team resolves them.

Rayyan is more flexible than Covidence and less structured. It does not force a sequence of stages, so the team decides how to run full-text screening, for example as a second round in a separate review. Its filters, keyword highlights and labels make it easy to sort records, and it detects possible duplicates on import. The flexibility suits small teams and student projects, and it places more responsibility on the team to keep its stages and counts organized.

Both platforms change often, and the features above should be checked against the current version before a team commits to one. For the Cedar Valley review, the librarian's university holds a Covidence licence, and the team chose Covidence because its fixed stages and required exclusion reasons would make the PRISMA counts straightforward for a team that included a first-time screener. A student team without a licence could run the same process in Rayyan's free plan by setting its own rules for reasons and rounds.

2.4 Setting Up a Screening Project

A screening project should be set up before anyone screens a record, because changing the rules part of the way through makes earlier decisions inconsistent with later ones. The steps below apply to any platform.

The Cedar Valley screening guide

A screening guide turns eligibility criteria into questions that a screener can answer from a title, an abstract or a full text. Each question should have a clear rule for the common borderline cases, because borderline cases cause most disagreements. The Cedar Valley guide below follows the review's Population, Concept and Context (PCC) question from Lesson 2: adults aged 65 and older who live in the community, community-based interventions evaluated for their effects on loneliness or social isolation, and studies conducted in high-income countries.

2.5 Privacy, Licences and Records

Bibliographic records do not contain information about study participants, so screening carries little privacy risk. Three related matters still need a decision before screening begins. The first is the institution's policy on cloud-based tools, which some health authorities restrict, and which may determine whether staff can use a given platform. The second is the licence under which full texts are obtained: PDFs supplied through a university library are licensed to that library's users, and the team should share them only among members entitled to access them. The third is the team's own copy of its decisions. Platforms can change their plans, and accounts can lapse, so the team should export the screening decisions and exclusion reasons at the end of each stage and store them with the audit trail described in Section 1.

With the platform set up and the guide written, the Cedar Valley screeners are ready to begin. Section 3 follows them through a pilot, through title and abstract screening and full-text screening, and through the calculation of their agreement.

Introduction

Screening moves through two stages. At title and abstract screening, reviewers read the short record for each item and remove those that clearly fail the eligibility criteria. At full-text screening, reviewers obtain and read the full report for each item that survived the first stage, and decide whether it meets every criterion. The two stages exist because reading 1,870 full texts would take months, while most records can be excluded safely in a few seconds from the title and abstract. The cost of the two-stage design is that the first stage must be inclusive: a relevant study excluded on its abstract never reaches a reader who could see that it belonged.

This section follows the fictional Cedar Valley screeners through both stages, the pilot that came before them, and the agreement statistics they used to check that two people were applying the same rules.

3.1 Title and Abstract Screening

The working rule at the title and abstract stage is that a record moves forward unless it clearly fails at least one criterion. When the abstract is silent about a criterion, the record moves forward. When a record has no abstract, the screener decides from the title, and moves the record forward if the title leaves the question open. Most teams use three options, include, exclude and maybe, and treat maybe as include for the purpose of moving records to the next stage. The value of the maybe option is that it tells the full-text reviewer which records were uncertain and why.

Reasons for exclusion are usually not recorded at this stage. PRISMA 2020 asks only for the number of records excluded at title and abstract, and recording reasons for more than a thousand quick exclusions would slow the work without improving the report. Reasons become mandatory at full text.

3.2 Full-Text Screening

At full text the team first has to obtain the reports. Most come through the university library; others come through interlibrary loan, from the authors, or from organization websites. Reports that cannot be obtained after reasonable effort are counted as reports not retrieved and listed in the review, which is more honest than leaving them out of the count. The Cedar Valley team sought 145 reports and could not retrieve three: a doctoral dissertation indexed in PsycINFO that was not available from the awarding university, and two articles from journals the library could not supply within the review's timeline after requests to the authors went unanswered. That left 142 reports to assess.

Full-text screening applies every criterion strictly. Each excluded report receives exactly one reason, the first reason in the ordered list from Section 2 that applies. This is also the stage at which reports are linked to studies: when two or more reports describe the same study, the reviewer links them so that the study is counted once. The Cedar Valley team included 40 reports, which described 38 studies, because two studies had each been reported in both a conference abstract and a journal article.

3.3 Piloting the Screening Guide

A pilot (sometimes called a calibration exercise) is a small round of screening that both screeners complete before the main screening begins. Each screener works through the same random sample of records independently, and the team then compares the decisions, discusses every disagreement, and revises the guide. The pilot catches criteria that are ambiguous, rules that the guide leaves unstated, and differences in how screeners read the same words. Teams repeat the pilot with a fresh sample if agreement is poor or if the guide changed substantially.

3.4 Dual Independent Screening and Resolving Conflicts

In dual independent screening, two reviewers screen every record without seeing each other's decisions, and the team resolves each disagreement afterwards. The method rests on a simple observation: careful people make errors when they read hundreds of abstracts, and two people rarely make the same error on the same record. Methodological studies support the practice. A methodological systematic review comparing single with double screening found that single screening missed more eligible studies (Waffenschmidt et al., 2019), and a randomized trial of abstract screening reached the same conclusion for single-reviewer screening (Gartlehner et al., 2020). The Cochrane Handbook recommends that at least two people, working independently, decide whether each study meets the eligibility criteria (Higgins et al., 2023).

Conflicts are resolved in one of three ways. The two screeners can discuss the record and agree; a third reviewer can decide; or the team can use discussion first and refer anything unresolved to the third reviewer, which is the Cedar Valley approach. Whatever the method, the protocol should state it, and the platform should record the final decision. A record of conflicts is also useful in its own right, because a run of conflicts on one criterion signals that the guide needs another rule.

Rapid reviews sometimes reduce dual screening, for example by having one person screen most records while a second person screens a sample or checks all exclusions. These shortcuts save time at a known cost in missed studies, and Lesson 10 examines the guidance on when they are acceptable. The Cedar Valley protocol planned a shortcut of this kind: two reviewers would screen the first 20 percent of titles and abstracts (374 records, starting with the pilot sample), and one reviewer would then screen the rest while a second checked every exclusion. In the first 374 records, 345 (92 percent) were excluded, so checking every exclusion would have saved only about 3 percent of the work. The team amended its protocol on 20 February 2026, at the end of week 5, and screened every remaining record in duplicate, because the number of records was manageable and the planning team would rely on the review to choose a program model. Full texts were screened by two reviewers independently, as the protocol planned.

3.5 Measuring Agreement Between Screeners

Teams often summarize how well two screeners agreed, either for the pilot, to decide whether the guide is ready, or for each stage, to report in the methods. The two most common statistics are percent agreement and Cohen's kappa. Both start from a two-by-two table that cross-classifies the two screeners' decisions.

Agreement expected by chance

Cohen's kappa corrects for this by asking how much agreement two screeners would reach if each made decisions at their own overall rate but independently of the content of the records. The intern included 30 of 200 records (0.15) and the officer included 28 of 200 (0.14). If their decisions were unrelated, the expected proportion of records that both include is 0.15 × 0.14 = 0.021, and the expected proportion that both exclude is 0.85 × 0.86 = 0.731. The chance-expected agreement is the sum, 0.021 + 0.731 = 0.752. In counts, this is 4.2 expected joint includes and 146.2 expected joint excludes, or 150.4 of 200 records.

Cohen's kappa

Cohen's kappa (Cohen, 1960) is the agreement achieved beyond chance, divided by the largest possible agreement beyond chance.

Interpreting kappa

Kappa equals 1 when agreement is perfect, 0 when agreement is no better than chance, and falls below 0, to a minimum of −1, when screeners agree less often than chance would predict. The most often cited labels for values in between come from Landis and Koch (1977), who proposed them as convenient benchmarks for discussion. McHugh (2012) argued that these labels are too generous for health research, where a kappa in the 0.60s still leaves a substantial share of decisions in doubt. Labels are therefore a starting point for judgement.

The Cedar Valley pilot's kappa of 0.72 falls in the band Landis and Koch called substantial. The more useful reading comes from the table itself. Of the 36 records that at least one screener wanted to include (22 + 8 + 6), the screeners agreed on only 22, which is the agreement that matters most at this stage. That observation, together with the pattern in the disagreements, is what led the team to revise its guide before continuing.

High agreement, low kappa

Kappa depends on the proportion of records that are included. When very few records are relevant, chance-expected agreement is already close to 1, so even a small number of disagreements produces a low kappa. Feinstein and Cicchetti (1990) described this as a paradox of high agreement and low kappa. It is common in screening, where included records are usually a small minority: in Cedar Valley, the 40 included reports came from 1,870 screened records, about 2 percent. For this reason, a review should report the two-by-two table or the number of conflicts alongside kappa, and should judge agreement mainly by how the screeners did on the records that either of them included.

With 38 studies included from the database search, and the reports and exclusions counted at each stage, the Cedar Valley team has the numbers it needs for the left-hand column of its flow diagram. Section 4 adds the grey literature and citation chasing and draws the complete PRISMA 2020 flow diagram.

Introduction

The PRISMA 2020 statement (Preferred Reporting Items for Systematic reviews and Meta-Analyses) is a 27-item checklist of what a systematic review report should contain, published with an explanation and elaboration paper and a set of flow diagram templates (Page et al., 2021). Item 16a asks authors to describe the results of the search and selection process, from the number of records identified to the number of studies included, ideally with a flow diagram. Item 16b asks authors to cite studies that might appear to meet the inclusion criteria but were excluded, and to explain why. The flow diagram answers item 16a in a single figure: it shows how many records the searches found, how many were removed at each stage and why, and how many studies and reports the review finally included.

The diagram is the public face of the record management and screening work in Sections 1 to 3. Every number in it should come straight from the team's log, and a reader should be able to add and subtract their way from the top of the diagram to the bottom. This section explains the structure of the 2020 diagram, draws the complete diagram for the fictional Cedar Valley review, and shows how to check it.

4.1 What the Flow Diagram Shows

A reader looks at a flow diagram to answer practical questions. How large was the search? How many records were duplicates? What share of records survived title and abstract screening? Were any reports impossible to obtain? Why were reports excluded at full text, and was any one reason dominant? How many studies did the review include, and how many reports described them? Answers to these questions help the reader judge whether the search was broad enough, whether the criteria were applied as described, and how the review's results might change if, for example, the unretrieved reports had been found.

The diagram does not describe the search strategies themselves. Those belong in the methods and appendices, reported according to PRISMA-S (Rethlefsen et al., 2021), which Lesson 4 introduced. The diagram also does not replace the list of excluded studies that item 16b asks for; it summarizes the reasons as counts, while the list names the specific studies that a reader might have expected to see included.

4.2 From PRISMA 2009 to PRISMA 2020

The original PRISMA statement (Moher et al., 2009) included a four-phase flow diagram labelled identification, screening, eligibility and included. The 2020 update kept the top-to-bottom design and changed its content in several ways that reflect how reviews are now conducted.

4.3 Choosing a Template

PRISMA 2020 offers templates for two kinds of review and two kinds of search. A new review starts from nothing; an updated review builds on a previous version and reports both the earlier and the new studies. A review that searched only databases and registers needs one column; a review that also searched websites, contacted organizations or chased citations needs the version with a second column for other methods.

4.4 The Cedar Valley Flow Diagram

The Cedar Valley review searched five databases (Sections 1 to 3), searched grey literature, trial registries and websites and contacted organizations (Lesson 5), and chased citations from the included studies and from relevant reviews (Lesson 5). It therefore uses the template for new reviews with other sources. The left-hand column summarizes Sections 1 to 3 of this lesson. The right-hand column summarizes the other methods. The grey-literature searches produced 771 records and items, of which 214 were duplicates; the remaining 557 were screened, and 61 were sought as full reports. Organizations contacted during the environmental scan sent 7 documents, all of which were sought. Citation chasing retrieved 2,448 records, of which 1,288 were duplicates or had already been screened; the remaining 1,160 were screened, and 23 were sought. In all, 91 reports were sought. Two could not be obtained (a program report that an organization had withdrawn from its website and an internal evaluation that its authors could not share), 89 were assessed, and 30 were included: 26 grey-literature documents, such as program evaluation reports and agency reports, and 4 reports of 4 further studies found by citation chasing. PRISMA 2020 places study registers beside databases in the left-hand column. The Cedar Valley team searched the trial registries in week 5 with its other grey-literature sources and screened their records in that set, so it counted them in the right-hand column and explained the adaptation in its methods; none of the registry records led to an included study.

The final box reports three numbers. The review includes 42 studies (38 from the databases and 4 from citation chasing), described in 44 reports (40 and 4). It also includes 26 grey-literature documents. The team decided at the protocol stage to chart grey-literature documents separately from research studies because their methods are often reported briefly, and it adapted the final box to show them. PRISMA 2020 presents its flow diagram as a template that authors can adapt, and an adaptation of this kind should be explained in the methods.

4.5 Checking That the Numbers Reconcile

Before a flow diagram goes into a report, someone other than the person who drew it should check every number against the log. The check is arithmetic: each box should equal the box above it minus the exclusions beside it, the reasons for exclusion should add up to their total, and the included counts should add up across columns.

Two of these steps deserve attention. The first is the move from records to reports between title and abstract screening and retrieval. In Cedar Valley, each record that passed screening led to one report, so the number of reports sought equals the number of records that survived. In some reviews a single record leads to more than one report, or the team discovers at retrieval that two records point to the same document, and the diagram should then show the change with a note. The second is the move from reports to studies in the final box. The number of studies can never exceed the number of included reports, and when it is smaller the methods should say how reports were linked to studies.

4.6 Adapting the Diagram for Scoping and Rapid Reviews

The Cedar Valley review is a rapid scoping review, and its reporting follows PRISMA-ScR, the extension for scoping reviews (Tricco et al., 2018). PRISMA-ScR asks for the same information about selection as PRISMA 2020, using the term "sources of evidence" because a scoping review may include documents that are not research studies. A scoping review can therefore use the PRISMA 2020 template with labels that fit its sources, as the Cedar Valley team did. A rapid review that used shortcuts, such as single screening of part of the records, should keep the same boxes and explain the shortcut in the methods; Lesson 10 discusses how rapid reviews report their shortcuts.

The environmental scan is reported separately. Its counts (18 programs identified, 11 responding to the survey and 7 taking part in key informant interviews) describe organizations and people, and Lesson 11 shows how to report a scan, including a simple flow of programs from identification to participation.

Tools for drawing the diagram

The PRISMA website provides the templates as editable documents. Covidence draws a PRISMA diagram from its stage counts, and the PRISMA2020 package for R and its accompanying Shiny web application produce compliant diagrams from a table of numbers (Haddaway et al., 2022). Any of these tools is acceptable. Whichever tool the team uses, the numbers must come from the team's own log, because a platform cannot know about duplicates removed in a reference manager before import or about records that were never imported.

The Cedar Valley team now knows which 42 studies and 26 grey-literature documents it will chart. Lesson 8 turns to data extraction and the appraisal of those studies.

Bringing It All Together

This lesson followed the fictional Cedar Valley evidence team from the moment its database searches finished to the moment it knew which studies it would chart. The team exported 2,480 records from five databases, imported them into Zotero by source and checked every batch, and removed 610 duplicates in automated, manual and platform passes, keeping a log that would later supply the first boxes of its flow diagram. Throughout, it kept the PRISMA 2020 distinction between records, reports and studies in view: duplicate records were merged, while different reports of one study were kept and linked at full text.

The team then set up a screening project in Covidence with a screening guide, an ordered list of exclusion reasons and blinded dual review, and compared that choice with Rayyan, which suits teams without a licence. A pilot of 200 records produced 93 percent agreement and a kappa of 0.72, and the pattern of disagreements, more than the kappa value itself, led the team to add two rules before screening the rest. Dual screening at both stages narrowed 1,870 records to 40 reports of 38 studies.

Finally, the team drew a complete PRISMA 2020 flow diagram, with a second column for grey literature, organizations and citation chasing, and checked every number against its log. The review includes 42 studies described in 44 reports, together with 26 grey-literature documents reported separately.

The final reflection asks you to turn the Cedar Valley numbers into the methods and results paragraphs that a published review would contain.

Final Knowledge Assessment

Definitions of the terms, tools and people introduced in this lesson on managing records and screening studies.