How subject and visit filters work

When a user creates a Subject or Visit filter, he or she must specify a filter driver model, the clinical data model that contains the Subject Visit table to use. The table can be in any clinical data model in the study, but it must have the SDTM table identifier SUBJECTVISIT and the user must have View privileges on the table.

Tip:

Associate only one table per study with the SDTM identifier SUBJECTVISIT, so that users have only one choice when they create filters. If they create using different driver models and use them at the same time, in the Discrepancies page the system does not apply either filter.

OR create public filters with the filter driver model set to the same model. Data reviewers can modify public filters instead of creating their own.

The filter logic checks this Subject Visit table and finds each distinct subject/visit combination that meets the criteria of the filter. It then creates a join with the table the user is viewing in the Listings page and displays those records. The filter logic uses different join columns on the Listings page and Discrepancies page, as shown below:

Table 8-4 Join columns required for subject and visit filters

Page	Join Column for Subject Filters	Join Column for Visit Filters
Listings	USUBJID	VISITNUM
Discrepancies	SUBJID	VISIT

Therefore, all tables with data that users may need to view must have columns linked to SDTM identifiers USUBJID, SUBJID, VISITNUM, and VISIT. Note that some of these names are used differently in InForm; see SDTM column equivalents in InForm.

In addition, to support all possible filters, the Subject Visit table must have columns linked to the SDTM identifiers COUNTRY, SITENAME, SITEID, INVNAM, INVID, SUBJID, USUBJID, EPOCH, VISITNUM, VISITDY, VISIT and EPOCH. Users can filter on one of these columns only if it exists in the Subject Visit table and is mapped to the corresponding SDTM identifier.