Instruments & Licensing (Validated Scales)

Why this matters

Validated instruments (for example, patient-reported outcome questionnaires, symptom scales, and quality‑of‑life surveys) come with known measurement properties—they have been tested so their scores mean something specific in a defined population. If we change wording, order, response options, or how the questions are presented, we can invalidate those properties. We can also violate licenses if we use or modify an instrument without the owner’s permission.

Finally, scores are derivations. They must be specified, versioned, and change‑controlled like any other algorithm, whether they run in the Electronic Data Capture (EDC) system or later during analysis.

Core concepts & definitions

• Validated instrument — A questionnaire or scale whose reliability and validity have been demonstrated for a particular purpose and population (e.g., adults with depression). In regulatory terms these are clinical outcome assessments (COAs): patient‑reported (PRO), clinician‑reported (ClinRO), observer‑reported (ObsRO), or performance outcome (PerfO) measures.
• Instrument owner/licensor — The individual, university, or company that holds the rights to reproduce, translate, or modify the instrument, or a distributor that licenses it on the owner’s behalf.
• Licensing/permissions — Written authorization that tells you what you can do (paper, electronic, languages, translations, scoring use) and what you cannot (e.g., no edits to wording, no re‑distribution). Some instruments are free to use without asking (the PHQ‑9 is one), but you still file their terms of use, and free to use does not mean free to change.
• Electronic migration (eMigration) — Moving a paper instrument to an electronic format (e.g., tablet or phone). Even without changing text, you must show the electronic version does not alter meaning or usability. ISPOR’s ePRO good‑practice task force scales the evidence to the size of the change: a minor change (layout only, such as one item per screen) needs cognitive debriefing and usability testing; a moderate change (for example, an item split across screens, or response options that need scrolling) needs usability testing plus a quantitative equivalence study (do paper and electronic scores agree?); a substantial change (item wording, response options, or content) needs full psychometric re‑validation.
• Permitted modifications — Small layout adjustments that do not change meaning (e.g., font size, spacing) are sometimes allowed. Changes to item wording, order, or response options always need the owner’s explicit approval, plus new evidence (an equivalence study or re‑validation, as above).
• Scoring algorithm — A defined set of steps that turns item responses into subscale and total scores, including rules for missing items and reverse scoring. Reverse scoring flips the values of items worded in the opposite direction (on a 0–4 scale, 0 becomes 4) so a higher score always means the same thing; prorating scales up the sum of the answered items to estimate the total when a few are missing. Take these rules from the instrument’s official scoring manual (justify any study‑specific change in the statistical analysis plan, SAP), and treat the algorithm like software: name it, version it, and validate it.
• Version control — Track the exact instrument (name, version, language, source), the scoring algorithm version, and where/when each was used.

The process, step‑by‑step

1. Select intentionally Confirm the instrument matches your endpoint, population, and mode (paper vs electronic). Check if it has country‑specific or therapeutic‑area versions.

2. Obtain permissions early Contact the licensor. Ask for:

   • Right to reproduce and use in your study (paper/electronic).
   • Allowed languages and any translation restrictions.
   • Scoring terms: whether you may program the scoring yourselves or must use the licensor’s own algorithm or software.
   • Conditions for eMigration (e.g., usability testing, screen size rules).
   • Required copyright statements and how to cite the instrument.

   File the approval letter/email and the instrument source in your Trial Master File (TMF) or equivalent study repository.

3. Freeze the instrument package Record the instrument name, version, language(s), and source. Store the “as‑received” master copy (often a PDF or Word file) and any permission terms. This becomes your gold standard for build and QC.

4. Design data capture without bias

   • Keep wording, item order, and response options exactly as specified.
   • For electronic patient‑reported outcomes (ePRO), keep one clear question per screen unless the licensor allows grouping.
   • Do not show internal database codes (e.g., “1=Never, 2=Sometimes”) to participants; show the response options exactly as the licensed version shows them. If the scale itself is numeric (for example, a 0–10 rating scale), its numbers are response options, not codes.
   • Respect administration rules (who asks, when, and how often).
   • Apply accessibility best practices (readability, font size, screen reader compatibility) if permitted.

5. Specify and version the scoring Create a scoring specification that includes:

   • Algorithm name and version (e.g., PHQ9_total_v2.0).
   • Inputs (which items feed which subscale/total).
   • Reverse‑scored items and how they are handled.
   • Missing‑item rules, taken from the scoring manual (e.g., “prorate if up to 2 items are missing; otherwise the score is missing”).
   • Output fields (names, types, ranges, categorical bands).
   • Execution location (EDC vs data pipeline vs statistical programming).

   Put the spec under change control.

6. Validate electronic migration

   • Build to match the licensed text and order.
   • Conduct usability testing (can typical users navigate and respond?) and brief cognitive debriefing (do users interpret items as intended?); add an equivalence study or re‑validation when the change is moderate or substantial (see eMigration above).
   • The licensor grants permission and may set conditions (some review and approve screenshots before go‑live); the sponsor, usually with its ePRO vendor, generates and files the evidence. Regulators expect it when scores support an endpoint or labeling claim (for example, FDA’s PRO and clinical outcome assessment guidance).
   • Capture evidence: annotated screenshots, test scripts, defect logs, and a short summary of findings.

7. Train sites and monitor Train site staff on administration rules (timing windows, neutral tone, permitted aids). Monitor completion rates and item non‑response. Investigate any sudden changes after upgrades.

8. Maintain consistency and control changes Use the same version across all sites and timepoints unless a controlled change is approved. If anything changes (instrument text, scoring code, or ePRO rendering), run through impact assessment, licensor approval (if needed), and re‑validation.

What good looks like

• Licensing on file A dated permission letter/email (or contract) that clearly states allowed uses (e.g., ePRO, paper, translations), restrictions, and any mandatory disclaimers or copyright lines.

• Exact rendering The EDC/ePRO build matches the master instrument: same wording, same order, same response options, and only permitted layout adjustments. Annotated screenshots show traceability from source to build.

• Scoring under control A scoring specification with examples, test cases, and named/versioned outputs. Code is validated (unit tests) and change‑controlled. The system logs the algorithm version used for each score.

• Operational readiness Site training materials cover who administers the instrument, when it must be completed, what to do with missed items, and how to handle language needs.

Worked examples

These examples are self‑contained. Each includes the scenario, permissions, build choices, scoring, and validation evidence.

Example 1 — Depression scale in ePRO (smartphone)

Scenario: A nine‑item depression questionnaire (commonly known as PHQ‑9) will be completed by adults on their own phones at baseline and monthly.

Permissions: The PHQ‑9 is free to use: its copyright holder states that no permission is needed to reproduce, translate, display, or distribute it. The team files those terms of use, uses the official English and Spanish versions, makes no changes to wording, item order, or response options, and shows the copyright line on the first screen. (Many other instruments need a written license first; see Example 2.)

Build choices:

• One item per screen with “Back” and “Next” controls; progress indicator shows “Item X of 9.”
• Response options displayed as radio buttons with full text labels (e.g., “Not at all,” “Several days”).
• No numeric codes visible to participants. Internal coding (e.g., 0–3) is stored in the database but not shown.
• Reminder notifications are allowed once per day within the visit window; content is neutral (“You have a questionnaire to complete”).
• Any answer other than “Not at all” on item 9 (thoughts of death or self‑harm) alerts the site under the protocol’s safety procedure; the item itself is unchanged.

Scoring:

• Algorithm name/version: PHQ9_total_v2.0.

• Reverse scoring: None (not applicable for this instrument).

• Missing rule (as written in the study’s scoring specification and SAP): If 1 item is missing, prorate the total based on answered items; if ≥2 items missing, set the total and category to missing.

• Outputs:

  • phq9_total_v2_0 (0–27).
  • phq9_category_v2_0 with labeled bands (e.g., minimal, mild, moderate, moderately severe, severe) based on published cut‑points.

• Execution location: EDC at save time; results stored and version‑stamped.

Validation evidence:

• Annotated screenshots showing item text and order match the licensor’s PDF.
• Usability test with cognitive debriefing (5 participants from the target population) confirms they understand the items as intended and can navigate, select answers, and submit without confusion.
• Unit test file with sample responses and expected totals for 10 synthetic cases (including missing‑item scenarios).

Why this is “good”: Licensing is clear, the on‑screen presentation preserves intent, scoring is versioned, and electronic migration is evidenced by usability and unit tests.

Example 2 — Pain interference scale (paper to tablet) with translations

Scenario: A 7‑item pain interference scale is administered at clinic visits using site‑owned tablets. The study runs in the United States, Brazil, and Germany.

Permissions: Licensor approves tablet use and requires use of their official translations. Any additional languages must go through linguistic validation (forward translation, reconciliation, back translation, and brief cognitive debriefing) before first use.

Build choices:

• Landscape tablet layout to avoid scrolling; large touch targets.
• Instruction screen includes the licensor’s required text.
• Language selector appears before the first item and defaults to the participant’s preferred language stored in their profile.

Scoring:

• Algorithm name/version: PainInt7_total_v1.3.
• Reverse‑scored items: Items 2 and 5; the spec lists the exact remapping.
• Missing rule: No prorating; if any item is missing, total is missing.
• Outputs include a severity band and a flag indicating “incomplete—site follow‑up required.”

Validation evidence:

• Side‑by‑side comparison of the master paper layouts with annotated tablet screenshots.
• Cognitive debriefing summary for Portuguese (Brazil) and German (no official translations existed, so both were newly translated), showing participants understood items as intended.
• Audit trail confirming the correct language version was displayed for each administration.

Why this is “good”: Translations are controlled, the eMigration preserves meaning, and scoring rules are explicit and enforced.

Example 3 — Edge case: “Speed up data entry by printing numeric codes”

Scenario: A site asks to pre‑print numeric codes next to response options on paper forms (“1=Never, 2=Sometimes…”) so staff can type numbers quickly later.

Risk:

• Bias: Numbers can anchor or influence choices.
• Validity: Many licensors prohibit such additions because they can change how participants respond.
• License breach: Adding numeric codes is a modification requiring approval.

Decision:

• Deny the change unless the licensor grants written approval and the sponsor has evidence that responses are not affected (for example, cognitive debriefing or an equivalence study). Propose alternatives: barcode coversheets or site data entry shortcuts outside the participant‑facing form.

Pitfalls & misconceptions

• “Our statistician approves minor wording edits.” → Not enough. Licensor approval is required for changes to validated instruments. Some edits may also require re‑validation.

• “Electronic equals identical, so we don’t need testing.” → Incorrect. Even unchanged text can behave differently on screens. Run usability/cognitive checks as required.

• “Translations are easy—just have the site translate.” → Risky. Use official translations when available. Otherwise, follow a controlled linguistic validation process (forward translation, reconciliation, back translation, cognitive debriefing) and keep records.

• Mixing versions or languages mid‑study. Using different instrument or scoring versions across sites/timepoints can invalidate pooled analyses. Control and document any changeover.

• Hiding algorithm changes. Updating scoring without a new version ID (and without re‑deriving or flagging the scores already calculated) creates traceability gaps and inconsistent results.

Practice in the wild (checklist)

• Permission proof on file with allowed uses (paper/ePRO), languages, required notices, and any eMigration conditions.
• Instrument package frozen: name, version, language(s), source copy stored.
• Build matches source: wording, order, response options; no internal codes shown to participants.
• Scoring specification written: algorithm name/version, inputs, missing rules, outputs, examples.
• Validation evidence captured: annotated screenshots, usability/cognitive notes, unit tests with expected results.
• Administration rules trained: who administers, timing windows, reminders, handling of missed items.
• Change control ready: process to assess, approve, implement, and re‑validate any change (instrument, translation, scoring, or UI).
• Consistency monitored: reports for completion rates, missing items, language/version usage across sites.

Key points to remember

• Licensing is the gate. Obtain written permission for study use, translations, and any electronic migration before build or deployment. Licensor approval is required for any change to item wording, order, response options, most presentation changes beyond minor layout, all non‑owner translations, and any plan to show numeric codes to participants.

• Preserve instrument integrity. Implement the exact wording, item order, and response options. Only make minor layout tweaks permitted by the licensor. Do not display internal numeric codes in participant‑facing screens/forms unless explicitly allowed.

• Validate eMigration. When moving to electronic formats, keep evidence that meaning and usability are preserved: annotated screenshots mapping source → build, brief usability/cognitive checks as required, and unit tests for scoring/logic—filed alongside licensing documents.

• Treat scoring like software. Create a versioned scoring specification and validate it. A complete spec includes: algorithm name & version, inputs (which items feed which scores), reverse‑scored items, missing‑item rules, output fields (ranges/bands), where it runs (EDC vs pipeline), and test cases with expected results. Record the algorithm version used for every stored score.

• Control versions and changes. Freeze the instrument package (name, version, language, source) and use the same version/language across sites and timepoints. Put any change (instrument text, translation, scoring code, or UI rendering) through impact assessment, licensor approval (if needed), and re‑validation.

• Be audit‑ready. Keep on file: the permission letter, the frozen source instrument, ePRO/EDC screenshots, the scoring spec and unit tests, and traceable proof of which algorithm version generated each score.