ADaM QRS Supplements — Public Review, Deep Dive, and Practical Implementation Guide

Deep Dive Series — CDISC Open Source Ecosystem clinstandards.org | Published: March 2026

Abstract

CDISC has an active public review open for ADaM Questionnaire, Ratings, and Scales (QRS) supplements to the ADaMIG — currently featuring the Craig Handicap Assessment and Reporting Technique Short Form (CHART-SF). This is not an isolated event; the ADQRS sub-team operates a continuous pipeline of supplement development, public review, and publication covering a library of 317+ instruments. Yet most statistical programmers still treat QRS data as an afterthought — a "just use BDS and call it ADQS" domain that gets built last and documented least. That is a mistake, and regulators notice it. This article covers what ADaM QRS supplements are, why they exist, how the public review process works, what the FDA now expects from PRO/COA data in submissions, how to build a standards-compliant ADQS dataset from a published supplement, and how to participate in shaping new standards. All content is drawn from primary CDISC and FDA sources.

Table of Contents

1. Background — What QRS Is and Why It Matters Now
2. The Four Instrument Categories
3. The ADaM QRS Supplement — What It Contains
4. Current Public Review — CHART-SF and the ADQRS Pipeline
5. The Public Review Process — How It Works and How to Participate
6. ADaM Structures for QRS Datasets
7. The ADQS Dataset — Variable-Level Deep Dive
8. SDTM-to-ADaM Traceability for QRS Data
9. Scoring Logic — The Core Programming Challenge
10. Missing Data and Phantom Records
11. The FDA PROCCT — Regulatory Expectations for PRO/COA Data
12. PARCATx Variables — The Most Misunderstood Part of ADQS
13. Worked Implementation Example — GDS-SF
14. Writing ADaM Specs for QRS Datasets
15. Common Errors in QRS Programming
16. Summary and Key Takeaways

References

1. Background

1.1 Why QRS Data Is Not Just Another BDS Dataset

Patient-Reported Outcomes (PROs), Clinician-Reported Outcomes (ClinROs), Observer-Reported Outcomes (ObsROs), and Performance Outcomes (PerfOs) — collectively Clinical Outcome Assessments (COAs) — are increasingly the primary endpoints in modern clinical trials. The FDA's 2009 Patient-Reported Outcome Guidance and the subsequent Patient-Focused Drug Development (PFDD) series made COAs central to drug development strategy, not supplementary. Many NDA/BLA primary endpoints now rest on a questionnaire score, not a biomarker.

Yet the data standards ecosystem for these instruments has lagged behind their clinical importance. Historically, sponsors programmed QRS data in ad hoc ADaM structures that varied wildly across compounds, companies, and CROs — different PARAM naming, different scoring logic, inconsistent handling of missing items, and no standard approach to subscores vs. total scores. FDA reviewers were spending disproportionate time decoding bespoke ADQS structures instead of reviewing the clinical science.

CDISC develops SDTMIG and ADaMIG QRS supplements that provide information on how to structure the data in a standard format for public domain and copyright-approved instruments. The ADaM supplements specifically address analysis datasets — what variables to use, how scoring should be represented, how to handle derived parameters, and how to document everything in define.xml metadata.

1.2 The Regulatory Stakes

The FDA Study Data Technical Conformance Guide (sdTCG) explicitly directs sponsors to "consult current CDISC guidance (SDTM Implementation Guide, applicable Questionnaire Supplements, and CDISC Controlled Terminology)" when a QRS supplement exists for an instrument being used in a study. This is not optional guidance — when a supplement exists and is not used, FDA reviewers may flag the non-conformance during review. For studies submitted after January 2021, FDA expects alignment with published supplements for all instruments for which supplements exist.

The FDA has clearly stated that understanding both the quantity and reasons for missing PRO data is critical to their regulatory decision-making process. This expectation — that PRO data quality, completeness, and derivation logic be transparent — is exactly what ADaM QRS supplements are designed to support.

1.3 The Scale of the Published Library

The CDISC QRS standards package includes 317 instruments spanning questionnaires, functional tests, clinical classifications, and disease response instruments. Of these, many now have paired ADaMIG supplements providing analysis dataset specifications. The ADQRS sub-team — a dedicated group within the broader QRS team — recently published the first ADaM QRS supplement describing the structure of a typical dataset that could be used for summarization and analysis of the Geriatric Depression Scale Short Form (GDS-SF), and also released readme files providing the rationale for not developing ADaM supplements for four single-item questionnaires, ratings and scales.

The library is growing rapidly. Recent additions include the 4-Stair Ascend and 4-Stair Descend functional tests (September 2024), APACHE II updates (May 2025), and the CHART-SF currently in public review.

2. The Four Instrument Categories

The QRS team develops Controlled Terminology and SDTM tabulation supplements; the ADQRS Team develops ADaM analysis supplements. Understanding the four instrument categories is essential because they map to different SDTM domains and different ADaM dataset naming conventions.

Table 2.1 — QRS Instrument Categories

*Clinical Classifications and Disease Response instruments use the RS domain in SDTM and are typically represented in ADRS in ADaM, alongside tumor response endpoints. See the RECIST Deep Dive on clinstandards.org for full ADRS coverage.

2.1 The Questionnaire Category in Detail

The questionnaire category is by far the largest and the one most central to the ADaM QRS supplement program. A questionnaire instrument has these defining characteristics per CDISC:

• It is a named, standalone instrument — it has a formal title, a copyright holder (or is public domain), and a standard structure
• It consists of conceptually related items that are typically scored — each item maps to a variable in SDTM QS as a QSTESTCD/QSTEST pair
• It usually has documented administration and analysis methods — the scoring manual defines how item scores are combined into subscores and total scores
• It produces one or more scores that serve as analysis parameters in ADaM

The distinction between questionnaires and ratings/scales matters for SDTM domain selection (QS vs. RS or FT), but at the ADaM level, the ADQS dataset structure is broadly the same across all questionnaire-type instruments. What varies is the PARAMCD hierarchy, scoring logic, and the handling of item-level vs. score-level records.

3. What a Supplement Contains

QRS supplements to the ADaMIG describe how to structure the questionnaire analysis dataset based on data structures described in the ADaMIG. Included in ADaMIG supplements are sample analysis descriptions, scoring for the statistical analysis plan, data checks, and examples of analysis dataset metadata, analysis variable metadata, and value-level metadata. Also included is an example of the final analysis dataset to be used for analysis and regulatory submission.

3.1 Anatomy of an ADaMIG QRS Supplement

Every published ADaMIG supplement follows a standard template developed by the ADQRS sub-team. The major sections are:

Table 3.1. ADaMIG QRS supplement anatomy. All sections are normative content — they must be followed for a conformant implementation.

3.2 README Files — When No Supplement Is Developed

Not every instrument warrants a full ADaM supplement. The ADQRS sub-team also publishes README files — brief documents explaining why an ADaM supplement was not developed for a particular instrument. Common reasons:

• Single-item instruments: An instrument with only one item (e.g., a single global impression question) does not require a supplement — the BDS structure with a single PARAMCD is self-evident
• Scoring not applicable: Some functional tests record only a single numeric measurement with no scoring algorithm
• Copyright barriers: If the copyright holder has denied permission or not responded, CDISC cannot develop a supplement with meaningful example data

The existence of a README file is itself informative — it tells the programmer that CDISC has considered the instrument and made a deliberate decision not to publish a supplement.

4. Current Public Review — CHART-SF and the ADQRS Pipeline

4.1 The Active Public Review

CDISC currently invites comments on the Craig Handicap Assessment and Reporting Technique - Short Form (CHART-SF) Questionnaire Supplement to the ADaMIG. Public review is a key quality step in CDISC's Standards Development Process. CDISC relies on community input to ensure neutral, consensus-based data standards are developed and adopted by a diverse global community interested in improving research processes and quality for the benefit of all.

4.2 The CHART-SF Instrument

The Craig Handicap Assessment and Reporting Technique Short Form (CHART-SF) is a well-validated instrument used to assess participation and social integration outcomes in individuals with physical disabilities, particularly spinal cord injury (SCI), traumatic brain injury (TBI), and other acquired disabilities. Its clinical context makes it a priority instrument for CDISC standards development:

Table 4.1. CHART-SF instrument characteristics. The ADaM supplement in public review addresses how to structure the ADQS dataset for CHART-SF scoring and analysis.

4.3 Why CHART-SF Is a Meaningful Test Case

CHART-SF is a technically interesting instrument for ADaM supplement development because:

Multiple subscales plus a total score: The programmer must decide how to represent six subscale parameters plus the total in the ADQS PARAMCD hierarchy, and document the relationship in PARCAT1/PARCAT2 (see Section 12).

Imputation rules for missing items: CHART-SF has explicit scoring rules for handling missing responses — in some subscales, a missing item can be imputed from other items or context. This creates a scoring vs. imputation tension that must be addressed in the data checks section.

Proxy reporting: CHART-SF can be administered to a proxy (caregiver) rather than the subject. The SDTM QSEVAL and QSEVALID variables must capture this, and the ADaM supplement must specify how proxy-reported vs. subject-reported scores are handled in analysis.

Score directionality: Higher CHART-SF scores indicate more independence (better outcome). This is opposite to many symptom-burden scales (where lower is better). The supplement must make directionality explicit to prevent misinterpretation.

4.4 The Broader ADQRS Publication Pipeline

The CHART-SF public review is part of a continuous pipeline. Each QRS instrument is a series of questions, tasks or assessments used in clinical research to provide a qualitative or quantitative assessment of a clinical concept or task-based observation. The QRS team develops Controlled Terminology and SDTM tabulation supplements; the ADQRS Team develops ADaM analysis supplements.

Recent publications and upcoming supplements include:

Table 4.2. Recent ADQRS publications and pipeline. The program has accelerated significantly since 2022.

5. The Public Review Process

5.1 Why Public Review Matters

Public review is a key quality step in the CDISC Standards Development Process. CDISC relies on input from the community to ensure neutral, consensus-based data standards are developed and adopted by a diverse global community interested in improving research processes and quality for the benefit of all.

A supplement that goes through public review and incorporates community feedback is significantly more likely to be implementable in practice — and significantly less likely to require a post-publication revision that forces sponsors to re-derive existing datasets.

5.2 Who Should Review and Comment

Any statistical programmer, biostatistician, data manager, or clinical operations professional who:

• Has implemented the instrument being reviewed in a clinical study
• Has experience with the therapeutic area and can assess whether the scoring logic is clinically correct
• Has expertise in ADaM BDS structures and can assess whether the dataset design is technically sound
• Has encountered edge cases (e.g., missing item handling, proxy reporting, equipment-based administration) not covered in the draft

CDISC explicitly welcomes comments from all stakeholders, including industry, academia, CROs, and regulatory agencies. FDA staff participate in CDISC standards development as volunteers.

5.3 How to Submit Comments — Step by Step

To provide comments, you will need to log in or register for the CDISC Wiki. If you already have an account on Wiki or JIRA, the issue-tracking system, simply log in using the same login credentials. The CDISC Wiki uses a different login from cdiscID.

The process:

1. Navigate to cdisc.org/public-review/qrs-supplement-adamig to find all currently open reviews
2. Click the instrument name to open the supplement document on the CDISC Wiki
3. Log in (or register) with your CDISC Wiki credentials
4. Navigate to the specific section you wish to comment on
5. Add your comment via the Wiki commenting interface — include: (a) the section/line reference, (b) the issue you have identified, (c) your suggested resolution, and (d) the rationale
6. CDISC's ADQRS sub-team reviews all comments and responds with disposition (accept, reject, modify)

5.4 What Makes an Effective Comment

The CDISC review process is more rigorous than most public comment processes. Effective comments:

• Are specific — cite the exact section, table row, or variable specification
• Are technical — explain why the current text creates an implementation problem or ambiguity
• Propose a concrete resolution — do not just flag a problem; suggest how it should be fixed
• Are grounded in practice — reference your implementation experience or a regulatory precedent

Comments like "this is unclear" without a specific reference and resolution are unhelpful. Comments like "Section 4.2, PARAMCD for the total score: the current text suggests CHARTSFTS, but the FDA's PROCCT uses ZQTOTS as a total score convention — the supplement should clarify which naming convention takes precedence" are exactly the level of precision CDISC needs.

6. ADaM Structures for QRS Datasets

6.1 Two Permitted Structures

The different ADaM data structures that could be used for QRS supplements are: ADaM Basic Data Structure (BDS), which contains one or more records per subject, per analysis parameter, per analysis time point, with parameters mapped from –TEST and –TESTCD and additional parameters created as needed for derived scores; and ADaM Other, which may also be used when the analysis has special needs that are not met by the BDS structure.

For the vast majority of questionnaire instruments, BDS is the correct choice. ADaM Other is reserved for instruments with genuinely unusual analysis requirements that cannot be accommodated within BDS.

6.2 BDS for QRS — The Standard Architecture

In a BDS ADQS dataset for a multi-item questionnaire, there are typically three levels of records:

Table 6.1. BDS record hierarchy for a multi-item questionnaire. Item-level, subscore, and total score records coexist in the same ADQS dataset, distinguished by PARAMCD.

6.3 PARAMCD Conventions for QRS Instruments

The PARAMCD naming convention for QRS datasets follows a structured pattern that supplements document explicitly. The general pattern for questionnaire instruments:

Item-level:     [INSTRUMENT_SHORT_NAME][ITEM_NUMBER]
                e.g., GDSSF01, GDSSF02, ... for GDS-SF items

Subscore:       [INSTRUMENT_SHORT_NAME][SUBSCORE_ABBREVIATION]
                e.g., CHARTSF_PI for CHART-SF Physical Independence subscore

Total score:    [INSTRUMENT_SHORT_NAME]TOT or [INSTRUMENT_SHORT_NAME]TS
                e.g., GDSSFTOT for GDS-SF total score
                      CHARTSFTOT for CHART-SF total score

The exact PARAMCD values are defined in the supplement — this is one of the key normative outputs. CDISC Controlled Terminology also assigns standard QSTESTCD values that align with the PARAMCD convention.

NOTE: PARAMCD values in ADaM are not required to exactly mirror QSTESTCD values from SDTM, but the supplement will specify the mapping. Where a supplement uses a different PARAMCD from the SDTM QSTESTCD, the ADaM define.xml derivation metadata must document the mapping. This is a common source of define.xml non-conformance findings.

7. The ADQS Dataset — Variable-Level Deep Dive

7.1 Core Variable Set

The ADQS dataset is a BDS dataset named ADQS by convention. The following table shows the core variable set required for all QRS instrument implementations:

Table 7.1 — ADQS Core Variable Set

*AVAL is required where the parameter has a numeric value. For purely categorical parameters (e.g., some PRO ordinal items represented as characters), AVALC may be the primary value and AVAL may be null.

Table 7.1. ADQS core variable set. "Cond." = conditionally required; presence depends on protocol and instrument scoring requirements.

7.2 Variables Retained from SDTM QS

A critical ADaM QRS principle is that traceability-enabling SDTM QS variables must be retained in ADQS. The FDA's PROCCT guidance specifically requires retaining:

QSTESTCD     → Used to construct or verify PARAMCD mappingQSTEST       → Source of PARAM labelQSORRES      → Original character response (especially for ordinal items)
QSSTRESC      → Standardized character resultQSSTRESN     → Standardized numeric result (the primary source of AVAL for item-level records)
QSSTAT       → Collection status ('NOT DONE' drives phantom record creation)
QSREASND     → Reason not done (critical for missing data analysis)
QSDTC / ADT  → Date of assessmentVISITNUM     → Source for AVISITN mapping

These retained variables enable a reviewer to trace any ADQS analysis value directly to the source SDTM record without needing to re-run the mapping programs.

8. SDTM-to-ADaM Traceability for QRS Data

8.1 The Traceability Chain

Traceability in ADQS operates at two levels:

Level 1 — Item to SDTM QS: Each ADQS item-level record (PARCAT2 = 'ITEM') must trace directly to a SDTM QS record via USUBJID + QSTESTCD + VISITNUM (or ADT). The AVAL in the ADQS item record must equal — or be explicitly derived from — QSSTRESN (or QSSTRESC for character items) in the source QS record.

Level 2 — Score to Items: Each subscore or total score record (PARCAT2 = 'SCORE') in ADQS must be derivable from the item-level ADQS records within the same dataset. The scoring algorithm must be documented in the define.xml derivation comment and in the ADaM spec.

/* ADQS traceability — linking item records to SDTM QS */

proc sort data=sdtm.qs(where=(qscat='GDS-SF')) out=qs_gdssf;
  by usubjid qstestcd visitnum; run;

/* Map QSTESTCD to PARAMCD per GDS-SF supplement mapping table */
data adqs_items;
  set qs_gdssf;
  length paramcd $8 param $200 parcat1 $40 parcat2 $10;

  /* PARAMCD = GDSSF + item number (zero-padded to 2 digits) */
  paramcd = cats('GDSSF', put(input(substr(qstestcd,7,2),8.), z2.));
  param   = cats('GDS-SF Item ', substr(qstestcd,7,2), ': ', qstest);
  parcat1 = 'GDS-SF';
  parcat2 = 'ITEM';
  aval    = qsstresn;
  avalc   = qsstresc;
  adt     = input(qsdtc, yymmdd10.);
  /* Retain source variables for traceability */
  /* qstestcd, qsstresc, qsstresn, qsstat, qsreasnd retained */
run;

Figure 8.1. SAS pseudocode for ADQS item-level record creation from SDTM QS. PARAMCD naming follows the GDS-SF supplement convention. Source SDTM variables are retained.

8.2 Annotated CRF and SDTM QS Mapping Table

Published QRS supplements include (where copyright permits) an annotated CRF showing the SDTMIG submission values (QSTESTCD, QSTEST) for each item. This is the definitive mapping authority. Programmers must use the CDISC-published QSTESTCD values — not ad hoc values developed by the sponsor — to ensure that the SDTM QS data passes Pinnacle 21 / CORE validation against CDISC Controlled Terminology.

NOTE: Copyright-approved supplements include the actual CDISC Controlled Terminology codes for QSTESTCD and QSTEST. Public domain supplements also include full CT. For instruments where permission has been denied or not received, only a README file exists — the programmer must construct the QS and ADQS structure using CDISC naming conventions as closely as possible, and note in the Data Reviewers Guide that no official supplement exists.

9. Scoring Logic — The Core Programming Challenge

9.1 Why Scoring Is Difficult to Standardize

Questionnaire scoring algorithms span an enormous range of complexity:

• Simple sum: Add all item scores. Total = Σ(item scores). (e.g., PHQ-9, GDS-SF)
• Subscale then aggregate: Compute subscale scores independently; aggregate to total. (e.g., CHART-SF — six subscales, each 0–100, total is sum of subscales)
• Reverse scoring: Some items must be reversed before summing (e.g., item score of 4 on a 0–4 scale becomes 0; item score 0 becomes 4). (Common in SF-36, PROMIS instruments)
• Weighted scoring: Items have differential weights in the total score formula. (e.g., APACHE II — clinical variables are weighted by severity)
• Normative scoring / T-score conversion: Raw scores converted to norm-referenced T-scores using published lookup tables. (PROMIS item banks, RAND-36)
• Imputation within scoring: Missing items handled per the instrument's scoring manual (e.g., CHART-SF allows subscale score computation when all non-missing items allow a valid range)

9.2 The Supplement as the Definitive Scoring Authority

The supplement's scoring section is the only authoritative source for how scores should be computed in a CDISC-compliant implementation. If the sponsor's SAP scoring description conflicts with the supplement, the supplement governs (or the conflict must be documented as a deviation with explicit justification).

The supplement documents:

• Which items contribute to each subscore/total score
• How to handle missing items (prorated, not calculated, imputed from valid items)
• Any reverse scoring required
• The valid score range for each parameter (drives data check rules)
• Whether the analysis value (AVAL) represents the raw score or a transformed score

9.3 Scoring Example — GDS-SF

The GDS-SF (Geriatric Depression Scale Short Form) illustrates a simple scoring implementation:

GDS-SF SCORING:
  - 15 items (GDS01–GDS15)
  - Each item scored 0 or 1 (binary response)
  - Total score = sum of items scored in the depressive direction
  - Items scored 1 for "Yes": GDS01, GDS02, GDS03, GDS04, GDS07, GDS08, GDS09,
    GDS10, GDS12, GDS14, GDS15
  - Items scored 1 for "No": GDS05, GDS06, GDS11, GDS13
    (these are reverse-scored items)
  - Total score range: 0–15
  - Interpretation: 0–4 Normal; 5–8 Mild; 9–11 Moderate; 12–15 Severe

In ADaM ADQS:

• 15 item-level records per visit with PARCAT2 = 'ITEM'; AVAL = 0 or 1 (after reverse scoring applied to applicable items)
• 1 total score record per visit with PARAMCD = 'GDSSFTOT', PARCAT2 = 'SCORE', AVAL = sum of 15 item AVALs

WARNING: Reverse scoring must be applied at the ADaM level — not at the SDTM level. SDTM QS represents the raw response as collected. The SDTM QSSTRESN for a "No" response to item GDS05 would be 0 (the raw response code). The ADQS item-level record would then set AVAL = 1 (the scored value after reversal). The define.xml derivation for PARAMCD = 'GDSSF05' must explicitly state that the item is reverse-scored.

10. Missing Data and Phantom Records

10.1 The Regulatory Imperative for Missing Data Transparency

Understanding the reasons for and prevalence of missing PRO data is critical to FDA review and regulatory decision-making. FDA reviewers routinely examine the pattern of missing QRS data in a submission to assess whether missingness is informative — i.e., whether subjects who dropped out had different disease trajectories than those who completed all assessments. If missing data is not properly represented in ADQS, this analysis is impossible.

The ADaM convention for representing missing scheduled assessments is the phantom record — a record with DTYPE = 'PHANTOM' for each scheduled visit at which a required QRS assessment was not performed.

10.2 Phantom Records — Structure and Purpose

A phantom record in ADQS has the following characteristics:

Table 10.1. Phantom record structure in ADQS. These records are created for each subject × scheduled visit where the QRS assessment was required by protocol but not performed.

/* Creating phantom records — conceptual approach */

/* 1. Build expected assessment schedule: all subjects × all required QRS visits */
proc sql;
  create table expected_visits as
  select a.usubjid, b.avisitn, b.avisit
  from adsl a
  cross join (select distinct avisitn, avisit from adqs_observed) b
  where a.saffl = 'Y';quit;

/* 2. Left join against observed records — missing = phantom */
proc sql;
  create table adqs_with_phantom as
  select e.usubjid, e.avisitn, e.avisit,
         coalesce(o.aval, .) as aval,
         coalesce(o.dtype,'') as dtype_obs,
         /* Set DTYPE = PHANTOM where no observed record */
         case when o.usubjid is null then 'PHANTOM' else '' end as dtype
  from expected_visits e
  left join adqs_observed o
    on e.usubjid = o.usubjid and e.avisitn = o.avisitn;quit;

Figure 10.1. Conceptual phantom record creation. The phantom record framework must be applied separately for each PARAMCD to ensure missing item-level and score-level records are both captured.

10.3 Missing Score Derivation Rules

When some but not all items are missing at a visit, whether the total score can still be computed depends on the instrument's scoring manual. The supplement documents this rule explicitly. Common patterns:

• All items required: If any item is missing, the total score is NE (not evaluable) → AVAL is null for the total score record at that visit
• Prorated scoring: If ≥ N of M items are present, compute score = (sum of present items / N present) × M total — this is the most common pattern for long instruments
• Subscale-level prorating: Prorated by subscale, then aggregate — used in instruments like SF-36 and CHART-SF

The prorating formula (when permitted) must be precisely specified in the ADaM spec and documented in define.xml derivation metadata for the total score PARAMCD.

11. The FDA PROCCT — Regulatory Expectations for PRO/COA Data

11.1 What the PROCCT Is

The Patient-Reported Outcome Collected in Clinical Trials (PROCCT) is a set of FDA technical specifications for the clinical trial data submission of Patient-Reported Outcomes and related COA data. It is part of the FDA's PFDD (Patient-Focused Drug Development) series. The PROCCT is non-binding but represents FDA's stated expectations — "non-binding" means you are not penalized for deviating, but you will be questioned, and you need a compelling justification.

The PROCCT provides variable specifications for key questionnaire variables such as QSCAT, QSTEST, QSTESTCD, etc., and notes that PRO data should be tabulated using the SDTM QS domain specifications. For select measures, CDISC publishes QRS Supplements that provide guidance on representing named COA measures in the SDTM. CDISC also provides submission values within the controlled terminology related to named COA measures. These resources should be consulted for guidance on a PRO measure, in addition to the guidance provided in the SDTM and ADaM IGs.

11.2 PROCCT ADQS Recommendations — Key Points

The PROCCT's ADaM section provides the following key directives for ADQS:

1. Follow the CDISC ADaM IG and QRS supplements as closely as possible. If a published ADaM QRS supplement exists, implement it. The PROCCT explicitly endorses the supplement as the primary guidance document.

2. Ensure all items needed for analysis and traceability from SDTM QS and ADSL are included. To achieve traceability, ADQS should retain key SDTM QS variables including QSTESTCD, QSTEST, QSSTRESC, QSSTRESN, QSSTAT, and QSREASND, enabling reviewers to trace each ADQS record back to its original SDTM source.

3. Create phantom records for missing scheduled assessments. The PROCCT provides explicit phantom record examples showing how missing visits should be represented, with DTYPE = 'PHANTOM', null AVAL, and the scheduled visit label preserved.

4. Document missing data reasons. QSREASND must be populated where the reason for non-collection is known. This enables the FDA to distinguish "subject refused" from "site error" from "subject withdrawn" — patterns that have very different implications for the integrity of the PRO analysis.

5. Use PARCATx variables to organize item and score hierarchies. The PROCCT emphasizes the importance of PARCAT1 and PARCAT2 (see Section 12). These variables are the primary navigation mechanism that FDA reviewers use to identify which records are item-level vs. score-level in a complex ADQS dataset.

11.3 The PROCCT and the Study Data Standardization Plan (SDSP)

It is advised that your Study Data Standardization Plan (SDSP) include the PROCCT if you plan on using the guidance. In the sdTCG, the FDA states that technical specification documents provide detailed information for content on specific topics, where applicable, submitted to FDA for an application. Sponsors should consult with the review division early in the process to discuss issues with trial design or conduct that may affect the content of these datasets.

This has a concrete implication: if your study uses a PRO as a primary or key secondary endpoint, the SDSP should:

• Reference the PROCCT version being followed
• Reference the CDISC QRS supplement (if published) for each instrument
• Document any deviations from the PROCCT or supplement guidance with justification

12. PARCATx Variables — The Most Misunderstood Part of ADQS

12.1 What PARCATx Does

PARCAT1 and PARCAT2 are parameter category variables in the BDS structure that provide a two-level classification of parameters within a dataset. In the ADQS context, they are used to organize the parameter hierarchy — which is particularly important for multi-item, multi-subscore instruments.

The conventional usage for ADQS:

12.2 Example PARCAT1/PARCAT2 Population

For a hypothetical subject with one assessment of GDS-SF at Week 12:

Table 12.1. PARCAT1/PARCAT2 population example. PARCAT1 = 'GDS-SF' groups all records for this instrument. PARCAT2 = 'ITEM' vs. 'SCORE' enables filtering.

NOTE: When ADQS contains multiple instruments (e.g., both GDS-SF and EQ-5D-5L in the same dataset), PARCAT1 is the only mechanism for segregating them. PARAMCD values alone cannot reliably segregate instruments because PARAMCD character limits may force abbreviated names. Always populate PARCAT1 with the full instrument --CAT value from the Controlled Terminology.

12.3 Why PARCAT2 = 'ITEM' Records Must Be Included

A common shortcut is to include only total score and subscore records in ADQS, omitting item-level records. This is non-conformant with the ADaM QRS supplement specifications and will generate FDA review questions for two reasons:

1. Traceability requirement: Without item-level records in ADQS, the scoring derivation cannot be verified from the dataset alone — a reviewer must re-run the source programs to verify that the total score is correctly computed
2. Missing data analysis: The pattern of missing items (which items are missing, for which subjects, at which visits) is only visible if item-level records exist — including phantom records for missing items

The PROCCT is explicit: item-level records must be present.

13. Worked Implementation Example — GDS-SF

13.1 Instrument Background

The Geriatric Depression Scale Short Form (GDS-SF) is the first instrument for which CDISC published an ADaM QRS supplement. It is a 15-item self-administered questionnaire used to screen for depression in older adults. All responses are binary (Yes/No). The ADQRS sub-team published this first ADaM QRS supplement describing the structure of a typical dataset that could be used for summarization and analysis of the Geriatric Depression Scale Short Form.

13.2 End-to-End Data Flow

CRF → SDTM QS → ADQS (GDS-SF)
─────────────────────────────────────────────────────────────
SDTM QS Domain:
  QSCAT  = 'GDS-SF'
  QSTESTCD = 'GDSSF01' through 'GDSSF15'
  QSORRES = 'YES' or 'NO'
  QSSTRESC = 'YES' or 'NO'
  QSSTRESN = 1 (for YES) or 0 (for NO) — raw response code

ADQS Item Records (15 per visit):
  PARAMCD = 'GDSSF01' through 'GDSSF15'
  PARCAT1 = 'GDS-SF'
  PARCAT2 = 'ITEM'
  AVAL = 0 or 1 (AFTER reverse scoring applied to items 05,06,11,13)
  AVALC = 'YES' or 'NO' (from QSSTRESC — pre-reversal)
  Source: QSSTRESN (with transformation for reverse-scored items)

ADQS Total Score Record (1 per visit):
  PARAMCD = 'GDSSFTOT'
  PARCAT1 = 'GDS-SF'
  PARCAT2 = 'SCORE'
  AVAL = SUM(item AVALs for items 01–15 at this visit)
         = NULL if any item is missing (per GDS-SF scoring rules)
  Source: Derived from item AVAL values

ADQS Phantom Records (for missing visits):
  DTYPE = 'PHANTOM'
  AVAL = .
  AVISIT = scheduled visit label
  QSSTAT / QSREASND populated if SDTM QS 'NOT DONE' record exists

Figure 13.1. GDS-SF SDTM-to-ADQS data flow. The three record types (item, score, phantom) map to three distinct programming steps.

13.3 Define.xml Value-Level Metadata for ADQS

The ADaM QRS supplement specifies Value-Level Metadata (VLM) for the ADQS dataset. VLM in define.xml defines variable attributes separately for each PARAMCD value, enabling the reviewer to understand what AVAL means for each parameter:

Table 13.1. Illustrative VLM entries for ADQS define.xml. The reversal logic for item 05 is explicitly documented in the Derivation field.

14. Writing ADaM Specs for QRS Datasets

14.1 Spec Structure

An ADaM spec for ADQS must contain more instrument-specific content than most ADaM dataset specs. The recommended structure:

Table 14.1. ADaM ADQS spec required sections.

14.2 Deviation from the Supplement — How to Document It

If the sponsor's protocol requires a deviation from the published supplement (e.g., a different baseline definition, a different handling of missing items), the deviation must be:

1. Identified explicitly in the spec — "This implementation deviates from Section X.Y of the CDISC GDS-SF ADaMIG supplement as follows: …"
2. Justified clinically and statistically — "The protocol specifies a 5-item minimum for total score computation because the instrument manual indicates that 5 of 15 items are sufficient for a clinically valid estimate. This differs from the supplement's all-or-nothing rule."
3. Noted in the Data Reviewers Guide — FDA reviewers check the DRG for supplement deviations; if a deviation is not documented there, it appears as a non-conformance

15. Common Errors in QRS Programming

Table 15.1 — Common ADQS Programming Errors

Table 15.1. Common ADQS programming errors. Most are preventable through systematic use of the published supplement as the implementation specification.

16. Summary and Key Takeaways

The CDISC ADaM QRS supplement program is maturing rapidly, and the regulatory expectations for ADQS data quality are rising in lockstep. The CHART-SF public review is a visible signal that the ADQRS team is expanding coverage into rehabilitation and disability medicine — therapeutic areas that have historically been underserved by data standards. Here are the essential takeaways:

1. Check for a published supplement before writing a single PARAMCD. The CDISC QRS library covers 317+ instruments. If your questionnaire has a published ADaMIG supplement, that supplement is normative — implement it. If it is in public review, contact CDISC and consider participating in the review.
2. PARCAT1 and PARCAT2 are not optional metadata decoration. They are the primary navigation mechanism FDA reviewers use in ADQS. PARCAT1 segregates instruments; PARCAT2 segregates items from scores. Missing these variables makes ADQS opaque.
3. Phantom records are required, not optional. Without them, the missing data pattern is invisible. FDA PRO review specifically looks for evidence that missing data was handled appropriately. Phantom records are the first line of evidence.
4. Reverse scoring belongs in ADaM, not in SDTM. SDTM QS represents collected data. ADQS represents analysis-ready data. The transformation lives in the derivation; the value-level metadata documents it.
5. The PROCCT is your regulatory framework for PRO data. Even though it is non-binding, deviating from the PROCCT without documentation in the SDSP and DRG generates FDA review questions. Follow it, or justify not following it.
6. Participate in public reviews. The quality of CDISC standards depends directly on the quality of community feedback. If you have implemented an instrument that is in public review, you have knowledge that the ADQRS sub-team needs. The barrier to participation is low — CDISC Wiki registration and a CDISC account.
7. Document supplement deviations in the DRG. If you deviate from a published supplement for any reason — even a minor one — document it in the Data Reviewers Guide under the ADQS section. Undocumented deviations appear as non-conformances during review.
8. The supplement is not just the scoring algorithm. It also specifies data checks, define.xml value-level metadata, analysis dataset metadata, and example records. Use all of it — the data checks in particular are frequently overlooked and catch SDTM QS data quality issues before they propagate into ADQS scores.

References

• CDISC. Questionnaires, Ratings and Scales (QRS). CDISC Foundational Standards. cdisc.org/standards/foundational/qrs
• CDISC. QRS Supplement to the ADaMIG — Public Review Page. cdisc.org/public-review/qrs-supplement-adamig
• CDISC. Analysis Data Model Implementation Guide (ADaMIG) v1.3. cdisc.org/standards/foundational/adam
• CDISC. ADaM Basic Data Structure (BDS) Specification. cdisc.org
• CDISC. ADaM QRS Supplement — Geriatric Depression Scale Short Form (GDS-SF). First published ADaM QRS supplement. cdisc.org/standards/foundational/qrs
• CDISC. ADaM QRS Supplement Template. CDISC Wiki. wiki.cdisc.org
• CDISC. ADaM Questionnaire Supplements (ADQRS) Sub-Team Publications. Current and Forthcoming ADaM Publications webinar series. cdisc.org
• CDISC. QRS Supplement to the ADaMIG — CHART-SF (Craig Handicap Assessment and Reporting Technique Short Form). Currently in public review. cdisc.org
• FDA. Submitting Clinical Trial Datasets and Documentation for Clinical Outcome Assessments: Technical Specifications. Patient-Reported Outcome Collected in Clinical Trials (PROCCT). fda.gov
• FDA. Study Data Technical Conformance Guide (sdTCG). Current version. fda.gov
• FDA. Guidance for Industry: Patient-Reported Outcome Measures — Use in Medical Product Development to Support Labeling Claims. December 2009. fda.gov
• FDA. Core Patient-Focused Drug Development (PFDD) Guidance Series. fda.gov
• CDISC. CDISC Controlled Terminology. Distributed via NCI Thesaurus. cdisc.org/standards/terminology/controlled-terminology

Published by clinstandards.org — Technical Reference for the CDISC Statistical Programming Community. All content is based on primary CDISC and FDA sources.

Part II — Extended Topics

The following sections extend the core article with topics that arise in practice once the foundational ADQS structure is in place: copyright and permission handling, multi-instrument dataset architecture, responder and ADTTE derivation from ADQS, the three-level PARCAT hierarchy, Associated Persons (AP-QRS) instruments, CORE validation, and the high-priority instruments programmers will encounter most frequently across therapeutic areas.

17. Copyright and Permission Tiers — What They Mean for Programmers

17.1 Why Copyright Matters in CDISC QRS

Statistical programmers rarely think of copyright as a data standards problem — but for QRS instruments, it is. Every named questionnaire is either in the public domain or owned by an individual, institution, or company. The copyright status of an instrument determines what CDISC can publish in the supplement, what the programmer can access for implementation, and what the sponsor must do before using the instrument in a study.

CDISC must obtain permission to create a QRS supplement for copyrighted instruments. The permission tier assigned to each instrument on the QRS page is not merely administrative metadata — it has direct consequences for how a programmer implements the instrument and what resources are available.

17.2 Permission Tier Reference

Table 17.1. CDISC QRS permission tiers and their practical implications for programmers.

17.3 High-Profile Copyright Cases

PHQ-9: The Patient Health Questionnaire-9 is one of the most widely used depression screeners in clinical research. The PHQ-9 is owned exclusively by Pfizer, Inc. Use of the PHQ-9 is subject to Pfizer's terms of use, but Pfizer has granted CDISC permission to develop a supplement. This means the CDISC supplement with full CT exists and is accessible, but the sponsor must obtain a separate Pfizer license to use PHQ-9 in clinical trials. The supplement itself does not grant usage rights. Programmers should confirm with their Regulatory Affairs team that the license is in place before implementing PHQ-9 in a submission.

EQ-5D family: The EuroQol EQ-5D instruments (EQ-5D-3L, EQ-5D-5L, EQ-5D-Y) are owned by the EuroQol Research Foundation and require licensing for clinical use. EuroQol has worked with CDISC on terminology development. Programmers implementing EQ-5D should verify the current permission status on the CDISC QRS page and confirm their site license with EuroQol.

PROMIS instruments: PROMIS (Patient-Reported Outcomes Measurement Information System) instruments are NIH-funded and are largely in the public domain. CDISC has developed supplements for PROMIS item banks with full CT support. Note that PROMIS uses IRT (Item Response Theory)-based scoring — the AVAL in ADQS for a PROMIS instrument is typically a T-score (mean = 50, SD = 10) computed from raw item responses, not a simple sum. The supplement must specify whether the T-score is computed by the sponsor's program or by a licensed PROMIS scoring service, and how the source of the T-score is documented in SDTM.

EORTC QLQ-C30: The European Organisation for Research and Treatment of Cancer Quality of Life Questionnaire Core 30 is owned by EORTC. A license is required for clinical use; EORTC has a well-established licensing process. The QLQ-C30 has a complex structure — 30 items, 15 domains (5 functional scales, 3 symptom scales, 6 single items, 1 global health status/QoL scale) — and each scale uses a linear transformation to produce a 0–100 score. The ADQS for QLQ-C30 must handle item, raw score, and transformed score levels across 15 domain parameters. This instrument is a frequent source of scoring errors in programming.

NOTE: The CDISC permission status for any instrument can change. A supplement that was "Pending" when your study was designed may be published by the time of submission. Conversely, a supplement may be revised post-publication in ways that affect your implementation. Always check the current version on cdisc.org/standards/foundational/qrs against the version your implementation followed, and document which version you used in the ADaM spec.

18. Multi-Instrument ADQS Architecture

18.1 One Dataset or Many?

A study collecting three questionnaires (say, PHQ-9, EQ-5D-5L, and PROMIS Pain Interference) must decide: one ADQS dataset containing all three instruments, or a separate dataset per instrument?

It is preferable for the QS domain to be split into separate analysis datasets for each individual questionnaire, rating, or scale. These instruments are analyzed separately, and the associated datasets may be rather large. In addition, scoring calculations may vary widely for different questionnaires, so separating them simplifies the programming logic and makes them easier to use.

This recommendation has strong practical support:

Table 18.1. Comparison of single vs. multi-dataset ADQS architecture. Separate datasets per instrument is the recommended approach.

18.2 Dataset Naming Conventions for Multiple QRS Datasets

When multiple QRS datasets exist for a study, the naming convention must differentiate them while remaining ADaM-compliant (eight-character limit, starts with "AD"):

Table 18.2. Dataset naming for multiple QRS instruments. The name should encode the instrument. Document all names in the Data Reviewers Guide and define.xml.

18.3 ADSL Variables in Instrument-Specific ADQS Datasets

Each instrument-specific ADQS dataset must contain the full set of ADSL variables needed for the analysis of that instrument: treatment flags, stratification factors, baseline disease characteristics used as covariates in the primary model, analysis set flags (ITTFL, SAFFL, or a PRO-specific evaluability flag), and TRTSDT/TRTEDT. Do not assume that a reviewer will join ADSL to ADQS — the dataset should be self-contained for the analyses it supports.

19. Responder Analyses and ADTTE Derivation from ADQS

19.1 The Responder Definition

For many PRO endpoints, the primary analysis is not the mean change from baseline — it is the proportion of responders, where a responder is defined as a subject who achieves a threshold improvement from baseline that represents a clinically meaningful change. This threshold, often called the Minimal Clinically Important Difference (MCID) or Minimally Important Difference (MID), is instrument-specific and must be pre-specified in the SAP.

Examples:

Table 19.1. Common responder thresholds by instrument. The threshold must be pre-specified in the protocol or SAP — not selected post hoc.

19.2 Responder Flag in ADQS

The responder classification is stored in ADQS using analysis flags, not by creating a separate dataset. The conventional approach:

/* Example: Adding responder flag to ADQS for PHQ-9 total score */
data adphq9;
  set adphq9_base;

  /* CRIT01: >=50% reduction from baseline */
  length crit01 $200 crit01fl $1;
  crit01 = 'Change from Baseline >= 50% Reduction in PHQ-9 Total Score';
  if paramcd = 'PHQ9TOT' and not missing(base) and base > 0 and not missing(chg) then do;
    pchg_check = (chg / base) * 100;   /* CHG is negative for improvement */
    if pchg_check <= -50 then crit01fl = 'Y';
    else crit01fl = 'N';
  end;
  else crit01fl = '';

  /* CRIT02: Remission (total score <= 4) */
  length crit02 $200 crit02fl $1;
  crit02 = 'PHQ-9 Total Score <= 4 (Remission)';
  if paramcd = 'PHQ9TOT' and not missing(aval) and avisitn > 0 then do;
    if aval <= 4 then crit02fl = 'Y';
    else crit02fl = 'N';
  end;
  else crit02fl = '';

run;

Figure 19.1. CRITxxFL implementation for PHQ-9 responder analysis. Both a proportional reduction criterion (CRIT01) and an absolute threshold criterion (CRIT02) are flagged. The text variables (CRIT01, CRIT02) must exactly match the SAP language.

19.3 Time-to-First-Response — ADTTE from ADQS

When a time-to-event analysis is planned for the questionnaire endpoint (e.g., time to first sustained response, time to first deterioration), a record in ADTTE must be derived from the ADQS dataset. This is a programming bridge that many programmers implement incorrectly because they try to derive ADTTE directly from SDTM QS rather than from the analyzed ADQS records.

The correct chain:

SDTM QS → ADQS (with CRITxxFL populated) → ADTTE (time-to-response endpoint)

Key ADTTE variables derived from ADQS:

  AVAL     = Time from STARTDT to first visit where CRITxxFL = 'Y' (event)
             OR time from STARTDT to last adequate assessment (censored)
  CNSR     = 0 (event) or 1 (censored)
  ADT      = Date of event (first response visit) or censoring date
  STARTDT  = First dose date (ADSL.TRTSDT)
  EVNTDESC = 'FIRST RESPONSE ON [INSTRUMENT]' — e.g., 'FIRST RESPONSE ON PHQ-9'
  CNSDTDSC = Description of censoring reason
  PARAM    = 'TIME TO FIRST RESPONSE (PHQ-9, >=50% REDUCTION FROM BASELINE)'
  PARAMCD  = 'TTFRPHQ9' or similar

The STARTDT for the time-to-first-response endpoint must be anchored to the same date as the primary analysis — typically TRTSDT. The ADT for the event must be the date of the first assessment at which the responder criterion is met, not the date of a subsequent assessment confirming the response (unless sustained response is the definition, in which case the confirm date is the ADT).

WARNING: A common error is deriving the time-to-first-response ADTTE using the date of the scheduled visit window rather than the actual assessment date from ADQS. The event date must be the actual ADT from the ADQS record where CRITxxFL = 'Y' first occurred, not the planned visit date.

20. The Three-Level PARCAT Hierarchy for Complex Instruments

20.1 When PARCAT2 Is Not Enough

For instruments with a three-level score structure — item → symptom/domain → total — two levels of PARCAT are insufficient to distinguish all record types. The FDA's PROCCT scenario for complex PRO instruments (such as symptom diaries with multiple symptoms, each with multiple attributes) describes the use of PARCAT3 to represent the third level.

The PROCCT provides an explicit example showing consistent use of parameter category variables to allow for easy identification of the measure, symptoms (e.g., rash, headache), and attributes (e.g., presence, severity, frequency) within an example PRO measure — where PARCAT2 reports the stand-alone symptom and PARCAT3 reports the stand-alone attribute.

20.2 Three-Level PARCAT in Practice

Consider an oncology symptom diary with the following structure:

Instrument: Example Symptom Diary (ESD)
  Symptom 1: Nausea
    Attribute 1a: Presence (Yes/No)
    Attribute 1b: Severity (0–10 NRS)
    Attribute 1c: Frequency (Never / Sometimes / Often / Always)
  Symptom 2: Fatigue
    Attribute 2a: Presence (Yes/No)
    Attribute 2b: Severity (0–10 NRS)
  Composite: Total Symptom Score (sum of severity scores)

The PARCAT structure for this instrument:

Table 20.1. Three-level PARCAT structure for a symptom diary. PARCAT1 = instrument; PARCAT2 = symptom; PARCAT3 = attribute type. The total score record uses only PARCAT1 and PARCAT2.

20.3 Impact on Define.xml VLM

Using three levels of PARCAT requires the define.xml VLM to be organized to allow filtering at each level independently. Reviewers commonly filter by:

• PARCAT1 = 'ESD' → all records for this instrument
• PARCAT2 = 'NAUSEA' → all records for the nausea symptom across attributes
• PARCAT3 = 'SEVERITY' → all severity attribute records across symptoms

The VLM must document AVAL at the level of PARAMCD — each combination of PARCAT1 + PARCAT2 + PARCAT3 that defines a unique PARAMCD requires its own VLM row. For a complex symptom diary, this can mean 30–60 VLM rows for a single ADQS dataset.

21. AP-QRS — Instruments for Associated Persons

21.1 The AP-QRS Distinction

A category of QRS instruments collects data not from the study subject directly, but from an Associated Person (AP) — typically a caregiver, parent, legally authorized representative, or observer. These instruments present a structural challenge: the data pertains to the study subject, but is reported by someone else.

CDISC published a guideline on when to use AP-QRS domains vs. QRS domains for QRS instruments related to associated persons. The critical distinction:

Table 21.1. QRS vs. AP-QRS domain assignment. The key question: who is the source of the data — the subject or a separate associated person?

21.2 Programmer Implications of AP-QRS

When an AP-QRS instrument is used, the ADQS dataset must handle two critical complications:

QSEVAL and QSEVALID retention: These variables from SDTM QS identify the evaluator (e.g., QSEVAL = 'CAREGIVER'). They must be retained in ADQS and documented in the define.xml VLM. If the same instrument is administered both to the subject and to a caregiver (as parallel forms), the two sets of records must be distinguishable in ADQS via QSEVAL — and the analysis must specify which evaluator's data is primary.

CHART-SF proxy reporting: The CHART-SF — currently in public review — can be administered by proxy. The ADaM supplement in review must address how proxy vs. subject responses are handled in ADQS: are they separate PARAMCDs, or are they distinguished by QSEVAL within the same PARAMCD? The community's public review comments on this point are particularly valuable.

22. CDISC CORE Validation for ADQS

22.1 What CORE Checks for QRS Datasets

The CDISC Open Rules Engine (CORE) applies conformance rules from ADaM and QRS standards to submitted datasets. For ADQS, the relevant rule categories are:

Table 22.1. CDISC CORE validation rule categories for ADQS. Rules are applied during submission validation; findings require resolution or formal justification.

22.2 The Pinnacle 21 / CORE Overlap for QRS

Pre-publication tools (Pinnacle 21 Enterprise, now Certara's submission validator) apply CDISC conformance rules that partially overlap with CORE. As CORE matures and more QRS-specific rules are codified, the validation landscape for ADQS is tightening. Programmers who build ADQS with non-standard PARAMCD values, free-text PARCAT1, or missing CT alignment will face an increasing number of validation findings that require formal justification in the submission.

The practical implication: if a CDISC QRS supplement exists for your instrument, its PARAMCD and CT specifications define the conformant implementation. Deviating from those values — even for minor convenience — generates validation findings that must be documented in the define.xml and Data Reviewers Guide.

23. High-Priority Instruments — What Programmers Will Encounter Most

23.1 The Regulatory Priority List

FDA members provide guidance by sitting on various CDISC teams and review submissions on which instruments they commonly see or would like to see prioritized. The following instruments appear most frequently in FDA submissions across major therapeutic areas and are those for which programmers must have implementation fluency:

Table 23.1 — High-Priority QRS Instruments by Therapeutic Area

Table 23.1. High-priority QRS instruments for statistical programmers. Supplement status is as of March 2026 — verify current status at cdisc.org/standards/foundational/qrs before implementation.

23.2 Instrument-Specific Programming Notes

EQ-5D-5L Index Score: The EQ-5D-5L index value is not computed from a simple scoring formula. It requires a country-specific value set — a set of preference weights derived from general population valuation studies — to convert the 5-dimension health state profile to a single index value between 0 and 1 (where 1 = perfect health, 0 = dead, and some states are below 0). The value set used must be pre-specified in the SAP (e.g., UK value set, US crosswalk, EQ-5D-5L EQ-5D-3L crosswalk). In ADQS, the PARAMCD for the index value must reflect which value set was applied. The VAS (visual analogue scale, 0–100) is a separate parameter requiring no value set.

PROMIS T-score computation: PROMIS item banks use IRT-based scoring. The raw item responses produce a theta (ability parameter) estimate, which is converted to a T-score (mean 50, SD 10 in the US general population reference sample). If the sponsor is using PROMIS Computer Adaptive Testing (CAT), different items are administered to different subjects, which makes conventional item-level ADQS representation non-trivial. The supplement must address how CAT items are stored when each subject may have answered a different subset. Contact the relevant CDISC supplement team for current guidance if implementing PROMIS CAT.

SF-36 Physical and Mental Component Summary (PCS/MCS): The SF-36 PCS and MCS scores are derived from the eight subscale scores using a normative-based scoring algorithm that involves factor score coefficients from a US general population reference sample. The computation is non-trivial and the formula must be implemented exactly — errors in the factor score coefficient table are a frequent source of incorrect PCS/MCS values. The supplement documents this algorithm; verify your implementation against the supplement's worked example.

HAM-D version control: Multiple versions of the Hamilton Depression Rating Scale exist (HAM-D-17, HAM-D-21, HAM-D-24, HAM-D-6 short form). The SDTM QSCAT value and PARAMCD structure must reflect the specific version used in the study. Mixing items across versions in a single ADQS dataset — or using QSTESTCD values from the HAM-D-17 supplement for a HAM-D-21 study — is a data integrity error.

24. ADQS in Integrated Analyses and Pooled Studies

24.1 Pooling PRO Data Across Studies

When a sponsor pools PRO data across two or more studies for an integrated efficacy summary (ISS) or meta-analysis, the ADQS datasets from each study must be harmonized. Common problems:

Instrument version differences: Study A used PHQ-9 and Study B used PHQ-9 — but Study B used a different validated translation (e.g., English vs. Spanish). If both are included in the pooled analysis, the pooled ADQS must document the language version in a non-standard variable (NSV) retained from SDTM SUPPQS or an ADQS variable added by the sponsor.

Baseline definition differences: Study A defined baseline as the average of screening and Day 1 scores; Study B defined baseline as the Day 1 score only. A pooled analysis must resolve this to a single baseline definition — which requires re-deriving BASE and ABLFL for the pooled dataset using a harmonized rule documented in the pooled SAP.

Visit window harmonization: Study A's Week 12 window was ±7 days; Study B's was ±14 days. AVISITN assignment in the pooled ADQS must use a harmonized windowing rule, and records that fall outside the harmonized window must be excluded from ANL01FL even if they were included in the study-level ADQS.

24.2 NSV Handling in Pooled ADQS

Non-standard variables (NSVs) needed for pooled ADQS — such as the language version of the instrument, the administration mode (paper vs. ePRO), the device type used for ePRO, or the translation validation status — should be represented using the CDISC Non-Standard Variable Registry naming conventions. The NSV Registry stores NSVs for users' reference in developing CDISC-compliant representations of data that does not fit standard variable specifications.

If an NSV is needed that is not in the Registry, the sponsor must add a non-standard variable with a unique name following CDISC naming rules (typically a prefix reflecting the sponsor or a standardized pattern), document it in define.xml with an origin of 'Derived' or 'Assigned', and note its non-standard status in the Data Reviewers Guide.

25. Documenting QRS Implementation in the Data Reviewers Guide

25.1 What the DRG Must Say About ADQS

The Data Reviewers Guide (DRG) is the roadmap that FDA reviewers use to navigate the submission datasets. For ADQS, the DRG must contain:

Instrument inventory: A table listing every QRS instrument in the submission with the corresponding ADQS dataset name, CDISC supplement version followed, and whether the instrument is a primary, secondary, or exploratory endpoint.

Supplement deviations table: For any deviation from a published supplement, a table entry must document: (a) the supplement section, (b) the deviation, (c) the justification, and (d) the impact on analysis.

Baseline definition: The DRG must state which visit defines baseline for each instrument in ADQS, referencing the SAP section where this is specified.

Missing data approach: The DRG must describe how phantom records were created (which scheduled visits required them) and summarize the missing data rates observed per visit — ideally a table of available data rates per scheduled assessment.

Proxy reporting: If any instrument permitted proxy administration, the DRG must describe how proxy responses are distinguished in ADQS.

25.2 PRO Data Completeness Tables in the DRG

The FDA specifically looks for evidence that PRO data completeness was monitored and reported. The PROCCT recommends including the following in the submission documentation:

• Available data rate per scheduled assessment (number of subjects with a valid assessment / number of subjects expected to have the assessment at that visit)
• Completion rate separately for clinical benefit assessments vs. safety and tolerability assessments
• Summary of reasons for missing data by QSREASND category

These are not standard TFLs — they are DRG-level summaries. Programmers should generate these tables from ADQS (counting DTYPE = 'PHANTOM' vs. observed records per AVISITN) and provide them to Medical Writing for inclusion in the DRG.

26. The Future of ADaM QRS Standards

26.1 Integration with CDISC Biomedical Concepts

CDISC is developing Biomedical Concepts (BCs) — machine-readable, ontology-linked representations of clinical concepts that underpin CDISC standards. As BCs mature, QRS instruments will be represented as structured BCs with defined concept hierarchies — items → subscores → total score — in a form that supports automated dataset generation, validation, and regulatory review.

This has direct implications for the ADQRS supplement program: future supplements will likely be published not just as narrative Wiki documents but as machine-readable BC specifications that can be directly consumed by standards-aware programming tools. The CDISC 360i initiative and USDM (Unified Study Definition Model) are building toward this future. Statistical programmers who understand the QRS supplement structure today will be well-positioned to work with its machine-readable successor.

26.2 ePRO and Digital Health Technology Data in ADQS

Electronic Patient-Reported Outcomes (ePRO) — instruments administered via smartphone, tablet, or wearable device — present new data representation challenges that the QRS supplement program is beginning to address. Key emerging considerations:

Timestamped responses: ePRO data includes precise timestamps (date + time) for each item response, not just a visit date. SDTM QS QSDTC includes the full ISO 8601 datetime. ADQS ADT should preserve this precision for ePRO data.

Skip logic: Many ePRO implementations use skip logic — certain questions are asked only if a prior question's response meets a criterion (e.g., "If you answered 'Yes' to pain presence, rate your pain severity"). Skip-logic items that were not presented to a subject must be distinguished from items that were presented but unanswered. QSSTAT = 'NOT DONE' is not the right code for a skipped item; a sponsor-defined NSV may be needed.

Device-associated metadata: Screen size, operating system, app version, and administration mode (active vs. prompted) may all affect data quality. The PROCCT specifically notes that operational details such as acceptable screen sizes, operating systems, and types of assistance provided should be documented. Whether and how to carry device metadata into ADQS is instrument- and study-specific.

26.3 The Expanding Geographic Scope of QRS Standards

The CDISC QRS program has historically been most focused on instruments validated in English-speaking populations. As global clinical trials expand and as PMDA, EMA, and NMPA (China) increase their PRO/COA data expectations, validated translated versions of instruments — and their specific item wording — become critical to the supplement. The CT values for an instrument administered in Japanese may differ from the CT values for the English version if the Japanese regulatory authority has required instrument modifications.

Programmers working on global studies with PRO endpoints should confirm with Regulatory Affairs whether the instrument version used in each country is the same version covered by the CDISC supplement — or a nationally validated translation with different item wording that may require different QSTESTCD values or separate QS domains.

References (Extended)

All references from Part I remain applicable. The following additional sources support Part II:

• CDISC. Non-Standard Variable (NSV) Registry. cdisc.org/standards/terminology/non-standard-variables
• CDISC. Guideline on When to Use AP-QRS Domains vs. QRS Domains for QRS Instruments Related to Associated Persons. CDISC Knowledge Base. cdisc.org/kb
• CDISC. CDISC Biomedical Concepts. cdisc.org/cdisc-biomedical-concepts
• CDISC. CDISC 360i Initiative. cdisc.org/cdisc-360i
• FDA. Submitting Patient-Reported Outcome Data in Cancer Clinical Trials (PROCCT — Oncology Supplement). fda.gov/media/173581/download
• FDA. Patient-Focused Drug Development (PFDD) Guidance Series — Four Guidance Documents on Patient Experience Data. fda.gov
• EuroQol Research Foundation. EQ-5D Instruments and Licensing. euroqol.org
• PROMIS Health Organization and PROMIS Cooperative Group. PROMIS Instruments, Scoring Manuals, and T-Score Conversion Tables. healthmeasures.net
• EORTC. EORTC QLQ-C30 Scoring Manual and License Information. eortc.org
• Pfizer, Inc. PHQ Screeners — Terms of Use. phqscreeners.com
• CDISC. QRS Supplement Best Practices (CDISC Wiki). wiki.cdisc.org

Published by clinstandards.org — Technical Reference for the CDISC Statistical Programming Community. All content is based on primary CDISC and FDA sources.