SDTM Rules Development and Documentation Guide
Draft v1.0
Overview
This Guide was developed by the SDS SDTM Validation Rules sub-team for use by the
standards development community. The recommendations in this document are to be
considered best practices for use in formulating and documenting standards compliance
and conformance rules as a supplement to CDISC implementation guidance.
Purpose
The purpose of this guide is to provide instructions and a standard, concise structure for
identifying and classifying IG text that may constitute a rule definition.
Scope
The scope for candidate rules includes standards conformance validation and business
logic. Data validation logic that is not specifically linked to SDTM implementation
guidance is considered out-of-scope.
Rules Template
The following table provides a description of the columns in the CDISC Rules template:
Rules Template
Columns
Rule ID
Description
Identifier used to class and uniquely identify a rule. The ID is
comprised of several tokens arranged from left to right and
separated by underscores. The Rule ID is constructed to be a
concise description of the scope and object of the rule it identifies.
The tokens that make up the Rule ID are defined as follows:

Observation Class token – the Rule ID begins with a token that
denotes whether the rule applies to a specific SDTM
observation class or to all observation classes. The standard
for the tokens are:
 ALL – All observation classes
 SPC – Special Purpose Class
 FND– Findings Class
 EVT – Events Class
 INT – Interventions Class
Note: if a rule applies to several but not all observation classes
then a separate rule should be developed for each observation class
to which the rule applies.
1
SDTM Rules Development and Documentation Guide
Rule
Draft v1.0

Domain token – the second rule token in the Rule ID denotes
the domain that the rule applies to. When a rule applies to all
domains within the observation class scope defined by the first
token then ‘ALL’ should be used. Otherwise the standard
domain two letter abbreviation should be the token.
Exception: RELREC.

Variable token – the variable name is the token is used to
denote the object of the rule. There should be only one object
variable for a rule. If the rule has an interdependent element
e.g. ARM must equal ACTARM if ARM = “Screen Failure”
then there should be two related rules where the object of the
first is ARM and the second ACTARM. The variable name
should be used in the token for the Rule ID except when the
rule applies to a variable across domains/observation classes.
In such cases a stubbed version of the variable name with
dashes in place of the domain abbreviation should be used e.g.
--STDY, --ENDY. If the rule applies across all variables (see
Condition) then the token “GEN” should be used.

Counter token – the last token in the Rule ID is a two digit
integer counter zero-justified e.g. 01, 02, 14, etc. Ensure that
for new rules this counter is one greater than the highest
existing value for rules with the same Observation Class,
Domain, and Variable object.
A concise and unambiguous statement of the conformance or
compliance principle to be applied to the rule variable object.
Only one principle should be stated per defined rule. If the rule
only applies during a particular circumstance or condition then the
condition should be stated separately in the ‘Condition’ column.
For example: “If ACTARM = ‘Screen Failure’ or ‘Not Assigned’
then ACTARM must equal ARM” should be stated as “ACTARM
= ARM”. The Condition column should contain the text:
“ACTARM in (Screen Failure, Not Assigned).
In general all rules should be stated uniquely at the highest
applicable level of the rule hierarchy possible. For example: A
rule stating that “ARM must not be null” should be implemented
instead as a general rule for all classes, all domains, and all
variables, with a condition e.g. Rule: “Variable ^= null”,
Condition:” Core = REQ”.
Additional Rule guidance:
2
SDTM Rules Development and Documentation Guide

Any reference to a variable in a domain other than object
variable’s domain must be in the form “Domain.Variable”
e.g. TA.ARM, DM.SEX.

If a variable’s values should be members of a discrete list
described in guidance but not in CDISC Controlled
Terminology then the syntax should be “Variable in
(value1, value2…)”. Quotes around individual values in
the list are not recommended unless the values contain
special characters such as commas.

If a variable’s values should be members of a discrete list
described in CDISC Controlled Terminology then the
syntax should be “Variable in {CT List Name}”. Note the
use of braces instead of parentheses.

When a variable should not contain a value use the
keyword “null” e.g. “AGETXT = null” rather than phrases
like “is missing”, “equals blank”, “should not be
populated”.

Logical operators should be used in place of phrases such
as ‘less than or equal to’, ‘not greater than’, ‘should be’,
‘must equal’, etc. This is to enforce a concise and
unambiguous rendering of the rule. The following are
examples of logical operator substitutions:
Use:
=
^=
<=
<
>
>=
In
Not in
Condition
Draft v1.0
Instead of:
Should equal, must equal, equals
Not equal to, not equals
Less than or equal to
Less than
Greater than
Greater than or equal to
Must be defined in, must include
Not defined in
Whenever a rule is applied only in a conditional set of
circumstances the condition or conditions should be defined in this
column. Some guidelines for composing the condition statements
follow:
 It is not necessary to prefix each condition with ‘If’. This
is implicit in the fact that it is a condition.
 Multiple conditions should be separated by standard logical
3
SDTM Rules Development and Documentation Guide
Draft v1.0
operators e.g. AND, OR, AND NOT, etc.
Note
IG Section
Item #
Text
Class
Domain
Variable
Not sure if the columns described below are needed in the Rules
IG – need to discuss
Within a domain model, values may be: Description/Overview,
Specification, Assumption, Example
Where applicable, e.g., General Assumptions for All Domains,
include specific section number as reference
If itemized, include specific reference number/letter
IG text that states or implies the rule. It is recommended to
include all directive statements for completeness (i.e. must,
required, should, could, may statements) and to copy/paste text
from IG directly as needed.
For Section 4, General Assumptions for All Domains, suggest
representing once (vs. repeating per domain). Exceptions to be
noted by domain.
Observation Class for Domain type (i.e., Special Purpose,
Interventions, Events, Findings, Findings About, Trial Design,
Relationships)
For reference text that is broader than a single class, values may be
extended: All, General Observation Class, etc.
2-char abbreviation, Exceptions: ALL, RELREC
If variable specific, include variable name
4