Clinical process consolidation and adoption models

Clinical operations • Clinical data management • Clinical programming

Version 1.4 • Workflow and record-control reconciliation • Research reviewed October 8, 2026 • Logo areas intentionally blank

Controlled adoption model. 97 catalog SOP topics map to 34 process families; 130 active package forms map to modular record packets. These are new model documents and a catalog-level crosswalk, not a certification of field-level equivalence to existing effective documents, and not rewritten paid packages. CDM references now match the 30-form source package; the earlier 64-entry catalog used different numbering and must be reconciled by title. No existing approval, record or source document is retired by this model.

Return to resource guide and downloadable crosswalk · Use your browser Print command to save or print.

Revision 1.4 — October 14, 2026

Expanded programming intake and independent review, clarified clinical-data acceptance of EDC validation, strengthened TFL approval conditions and restricted communications, and added process-specific record fields to all 34 packets. Original catalog mappings remain intact. Paid source documents have not been replaced or certified as field-equivalent.

For an organization starting without an established process

Use these process steps, role assignments, evidence checks and approval gates as the initial operating model. The model does not require an existing company SOP to explain how the work is performed.

Adoption instruction: appoint the named role holders; select the controlled system and repository; enter study-specific reporting deadlines and retention rules; approve the configured version and train the team. Italic text is implementation guidance or a company-specific entry to complete. Normal text states the model process.

Area	Default operating method	Company entry
Record control	Maintain one controlled study workspace with separate Inputs, Working, Review, Released and Archive areas. Restrict unblinded and personal data. Preserve prior versions and audit history.	Enter the actual authorized system, paths and access owner.
Review cadence	Review significant issues when detected and before each affected decision; define routine review intervals and triggers in the approved study plan based on risk.	Approve the study-specific cadence and escalation thresholds before implementation.
Escalation	Notify the designated owner immediately for participant-safety, significant data-integrity or blind-disclosure concerns. Use the emergency pathway when needed. Track acknowledgment and action ownership.	Enter primary/backup contacts and applicable statutory, protocol and contractual clocks before study start.
Handoffs	Sender provides versioned manifest, review status, restrictions and outstanding issues; receiver acknowledges acceptance or rejection. Retain both sides of the handoff.	Enter sender/receiver names, secure channel and agreed turnaround.
Training and release	A qualified person tests a normal and exception case. Resolve defects, approve the document and record training before use.	Enter approving roles, effective date and training record location.

How to adopt

Confirm study scope, jurisdiction and applicable current requirements. Configure roles, systems, timelines, repositories and retention. Keep vendor names and approval identities blank until the adopting organization assigns them.
Use one process SOP to govern an end-to-end outcome. Keep task execution in WIs and specific checks in controlled form modules. Reuse common metadata without removing independent approval gates.
Reconcile every effective source requirement and form field against the new module. Test a representative normal and exception case. Retain specialized safety, blind-break, release and privacy records separately when required.
Approve, train and release through document control. Record supersession and make prior records retrievable. Do not change active-study baselines silently.

Template instruction: complete company-specific entries in italics, resolve them during adoption, and retain the underlying control. Do not leave unresolved blanks in an effective document.

Cross-functional handoffs

Handoff	Sender → receiver	Required acceptance evidence
Protocol and feasibility	Clinical operations → CDM and programming	Approved protocol version, critical-data requirements, resolved questions and receiving-owner acknowledgment.
Build and collection readiness	CDM → clinical operations and sites	Validated release, current completion guidance, access/training evidence and confirmation that sites are ready to use the release.
Cut and lock	CDM → programming and biostatistics	Cut definition, immutable manifest, signoff status, limitations, integrity verification and acceptance or rejection.
Analysis release	Programming → biostatistics, medical writing and regulatory	Reviewed outputs, metadata, traceability, exact package approval, permitted use and receipt.
Archive	Each function → designated records owner	Accepted inventory, readable records, restrictions, retention/hold requirements and retrieval test.

RACI and release discipline

Assign one accountable owner per decision gate, not one universal approver for every scientific and administrative decision. Responsible executes; Consulted provides input; Informed receives the outcome. Sponsor oversight remains explicit with outsourced execution. Qualified reviewers remain independent where the plan requires it. A tracker or RACI designation is not an approval record.

Specialized programming record supplement

The current catalog omits entries 049–051. Maintain three distinct vendor-neutral records in the blind-management process: (1) blind-maintenance/access review; (2) planned blind-break authorization; (3) accidental disclosure/impact assessment. Include scope, roles, time, exact information disclosed, recipients, authorization or emergency rationale, containment, impact, notifications and closure. Use restricted storage and do not assign invented effective IDs. Emergency medical access follows the protocol and emergency pathway.

Process index

COPS-P01 — Governance, study planning and quality oversight
COPS-P02 — Country/site feasibility and activation
COPS-P03 — Vendor qualification and lifecycle oversight
COPS-P04 — Risk-based monitoring and site issue resolution
COPS-P05 — Oversight of participant consent, eligibility and enrollment
COPS-P06 — Investigational product accountability
COPS-P07 — Safety communication and follow-up
COPS-P08 — Deviations, CAPA and controlled change
COPS-P09 — Interim review and restricted information transfer
COPS-P10 — Inspection readiness and authority responses
COPS-P11 — Significant noncompliance and urgent safety measures
COPS-P12 — Closeout, records retention and decommissioning
CDM-P01 — Data governance, planning and vendor oversight
CDM-P02 — Data standards, collection, build and validation
CDM-P03 — Access, audit trails and system controls
CDM-P04 — External data transfer and reconciliation
CDM-P05 — Clinical data review, queries and critical variables
CDM-P06 — Medical coding lifecycle
CDM-P07 — Safety database reconciliation
CDM-P08 — Database change, migration and regression control
CDM-P09 — Data cuts, lock and programming handoff
CDM-P10 — Records, inspection, archive and authorized sharing
CPROG-P01 — Programming governance, planning and quality
CPROG-P02 — Standards, reusable code and computing environment
CPROG-P03 — SDTM specification through validated release
CPROG-P04 — ADaM derivation through validated release
CPROG-P05 — TFL specification, programming and results traceability
CPROG-P06 — Data intake, independent QC and production release
CPROG-P07 — Integrated, real-world and legacy data programming
CPROG-P08 — Interim/DMC outputs and firewall management
CPROG-P09 — Randomization, treatment handling and blind breaks
CPROG-P10 — Submission metadata, validation and package assembly
CPROG-P11 — Archive and reproducibility
CPROG-P12 — Privacy and external data sharing

Vendor-neutral model • adoption version 1.4

COPS-P01 — SOP model

Governance, study planning and quality oversight

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Establish study governance and risk-based oversight that support participant protection and reliable trial conduct.
Scope: Study planning, delegated responsibilities, quality review and material plan changes. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Protocol, risk assessment and delegation agreements. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Clinical operations lead
Accountable	Sponsor study owner
Consulted	CDM lead; programming lead; quality assurance
Informed	Affected study team and authorized downstream recipients

Clinical operations lead performs and documents the work. Sponsor study owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

The approved plan identifies owners, review triggers and unresolved readiness blockers. Record: Approved study plan, scoped review and disposition.
Each critical activity has an owner and an observable control; high-impact gaps have an action before readiness. Record: Protocol review and critical-process register.
One decision owner is named per gate, and outsourced tasks have a sponsor oversight owner. Record: Approved delegation/RACI and interface decisions.
The decision can be traced to dated evidence; a closed action has closure evidence. Record: Quality review minutes and action register.
No team is instructed to operate from an unapproved or superseded baseline. Record: Change assessment and effective distribution record.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Clinical operations lead performs the sequential instructions in COPS-P01-WI-01 and retains the specified evidence in COPS-P01-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Unassigned critical controls or overdue significant-risk actions block readiness.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

When qualifying vendors or resolving vendor performance issues, use COPS-P03 — Vendor qualification and lifecycle oversight. Retain the decision or accepted handoff reference in this packet.
When findings require monitoring or site follow-up, use COPS-P04 — Risk-based monitoring and site issue resolution. Retain the decision or accepted handoff reference in this packet.
When a deviation, CAPA or controlled operational change is required, use COPS-P08 — Deviations, CAPA and controlled change. Retain the decision or accepted handoff reference in this packet.
When data-management plans or ownership change, use CDM-P01 — Data governance, planning and vendor oversight. Retain the decision or accepted handoff reference in this packet.
When programming plans, assignments or quality decisions change, use CPROG-P01 — Programming governance, planning and quality. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Sponsor study owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

Rework follows controlled change, with impact assessment, review and supersession links. Conditional release is only for explicitly accepted noncritical matters, with owner, deadline, permitted use and closure evidence; it cannot bypass the decision gate.

6. Records and effectiveness

The study plan or equivalent controlled record identifies the actual system of record and filing location for each required record category. Assign a custodian and access restrictions. Link technical evidence from essential records as appropriate to the filing plan; a tracker status alone is not completion evidence.

Retain the approved study plan and quality review record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: COPS-P01-WI-01. Controlled record packet: COPS-P01-FRM-01 — Approved study plan and quality review record.

COPS-P03 — Vendor qualification and lifecycle oversight
COPS-P04 — Risk-based monitoring and site issue resolution
COPS-P08 — Deviations, CAPA and controlled change
CDM-P01 — Data governance, planning and vendor oversight
CPROG-P01 — Programming governance, planning and quality

Adoption instruction: retain these internal links. If local numbering is required, assign a local ID in the document-control register and update every incoming and outgoing reference before approval. Do not delete a linked process merely because another department performs it.

Original-to-new crosswalk

COPS-SOP-001 — Clinical Operations Governance, Sponsor Oversight, and RACI
COPS-SOP-002 — Protocol Operational Feasibility Review and Critical Process Identification
COPS-SOP-003 — Study Operational Plan Development, Approval, and Maintenance
COPS-SOP-026 — Trial Team Governance, Meeting Management, and Decision Documentation
COPS-SOP-027 — Clinical Operations Metrics, KRIs, QTLs, and Quality Review

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

COPS-P01 — WI execution model

Governance, study planning and quality oversight

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate protocol, risk assessment and delegation agreements. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: Clinical operations lead performs and documents the work. Sponsor study owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Sponsor study owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Approved study plan, scoped review and disposition

The Clinical Operations lead obtains relevant medical and statistical input on critical operational assumptions, resolves unassigned controls with the study owner, and submits the study plan and responsibility matrix for study-owner approval before implementation.

Expected result: The approved plan identifies owners, review triggers and unresolved readiness blockers.

Evidence to retain: Approved study plan, scoped review and disposition.

Step 2 — Protocol review and critical-process register

Open the approved protocol and mark each operational activity that can affect participant protection or endpoint reliability. Enter the risk, existing control, accountable function and review trigger in the study plan.

Expected result: Each critical activity has an owner and an observable control; high-impact gaps have an action before readiness.

Evidence to retain: Protocol review and critical-process register.

Step 3 — Approved delegation/RACI and interface decisions

Build the study responsibility table by deliverable and decision. Compare it with signed provider agreements; resolve overlaps or unassigned work with the sponsor owner.

Expected result: One decision owner is named per gate, and outsourced tasks have a sponsor oversight owner.

Evidence to retain: Approved delegation/RACI and interface decisions.

Step 4 — Quality review minutes and action register

At the planned governance review, compare actual results with the approved thresholds. Record data period, source, breach assessment, decision and action due date.

Expected result: The decision can be traced to dated evidence; a closed action has closure evidence.

Evidence to retain: Quality review minutes and action register.

Step 5 — Change assessment and effective distribution record

For an amendment or material change, list affected plans, systems, vendors and training. Obtain scoped review, issue the new version and record acknowledgment.

Expected result: No team is instructed to operate from an unapproved or superseded baseline.

Evidence to retain: Change assessment and effective distribution record.

Company setup: enter the actual system screen, command and repository path beside the relevant step. Test these details against the installed system. The steps above provide the default workflow when no local process exists.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Unassigned critical controls or overdue significant-risk actions block readiness.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Before operational release, replace generic workspace actions with tested navigation for the installed system: screen name → command → expected result → evidence location → recovery path. Test the WI with a qualified user who did not write it. Record system version, normal/exception test results, review and training. Reassess the WI after changes affecting its instructions.

Vendor-neutral model • adoption version 1.4

COPS-P01 — consolidated record packet

Governance, study planning and quality oversight

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Approved study plan and quality review record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Reuse the cover across modules. Preserve each source-specific checklist, expected results and signature gate in its module. This register is not a replacement for unseen source fields. Separate modules may share a packet only if version, access, retention and approval requirements remain satisfied.

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
COPS-FRM-001 Study Operational Plan Template	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-002 Protocol Operational Risk Assessment	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-038 Trial Team Meeting Agenda and Minutes	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-039 KRI/QTL Review and Threshold Breach Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates COPS-SOP-001 — Clinical Operations Governance, Sponsor Oversight, and RACI; COPS-SOP-002 — Protocol Operational Feasibility Review and Critical Process Identification; COPS-SOP-003 — Study Operational Plan Development, Approval, and Maintenance; COPS-SOP-026 — Trial Team Governance, Meeting Management, and Decision Documentation; COPS-SOP-027 — Clinical Operations Metrics, KRIs, QTLs, and Quality Review. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
COPS-P01-F01 — Protocol/risk baseline; critical activity; control owner; review trigger
COPS-P01-F02 — Metric definition/denominator; period/source; threshold; actual value; decision/action

Execution acceptance and decision evidence

Complete each applicable check. A No requires a documented disposition before the affected gate; explain each N/A. Identify the person and date for the check in the evidence record. Link substantive results rather than copying them into this packet.

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: The approved plan identifies owners, review triggers and unresolved readiness blockers.	☐ Yes ☐ No ☐ N/A
Step 2: Each critical activity has an owner and an observable control; high-impact gaps have an action before readiness.	☐ Yes ☐ No ☐ N/A
Step 3: One decision owner is named per gate, and outsourced tasks have a sponsor oversight owner.	☐ Yes ☐ No ☐ N/A
Step 4: The decision can be traced to dated evidence; a closed action has closure evidence.	☐ Yes ☐ No ☐ N/A
Step 5: No team is instructed to operate from an unapproved or superseded baseline.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

COPS-P02 — SOP model

Country/site feasibility and activation

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Activate countries and sites only after applicable readiness requirements are met.
Scope: Feasibility, selection, startup evidence, initiation and authorization to activate. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Approved protocol, country requirements and candidate site evidence. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Study start-up lead
Accountable	Clinical operations lead
Consulted	Regulatory affairs; investigator; medical monitor
Informed	Affected study team and authorized downstream recipients

Study start-up lead performs and documents the work. Clinical operations lead owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Country and site readiness are both established; activation exceptions cannot bypass required approvals. Record: Country/site readiness checklist and activation decision.
Unverified capacity is identified as a risk, not scored as established capability. Record: Feasibility scorecard and qualification evidence.
Approvals cover the correct site, protocol and materials; no critical item is expired or missing. Record: Dated activation checklist and approval links.
Staff can locate contacts and current instructions; unresolved critical actions block activation. Record: Initiation report, training evidence and action closure.
Greenlight is signed/approved before enrollment, and recipients acknowledge it. Record: Site greenlight and distribution record.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Study start-up lead performs the sequential instructions in COPS-P02-WI-01 and retains the specified evidence in COPS-P02-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. No enrollment before applicable approvals and documented activation.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

For study governance, risk thresholds or plan changes, use COPS-P01 — Governance, study planning and quality oversight. Retain the decision or accepted handoff reference in this packet.
When qualifying vendors or resolving vendor performance issues, use COPS-P03 — Vendor qualification and lifecycle oversight. Retain the decision or accepted handoff reference in this packet.
When consent, eligibility or enrollment oversight is affected, use COPS-P05 — Oversight of participant consent, eligibility and enrollment. Retain the decision or accepted handoff reference in this packet.
Before operational closeout or system decommissioning, use COPS-P12 — Closeout, records retention and decommissioning. Retain the decision or accepted handoff reference in this packet.
Before building or releasing a data-collection system, use CDM-P02 — Data standards, collection, build and validation. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Clinical operations lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the site selection and activation dossier, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: COPS-P02-WI-01. Controlled record packet: COPS-P02-FRM-01 — Site selection and activation dossier.

COPS-P01 — Governance, study planning and quality oversight
COPS-P03 — Vendor qualification and lifecycle oversight
COPS-P05 — Oversight of participant consent, eligibility and enrollment
COPS-P12 — Closeout, records retention and decommissioning
CDM-P02 — Data standards, collection, build and validation

Original-to-new crosswalk

COPS-SOP-004 — Study Feasibility, Country Strategy, and Site Selection
COPS-SOP-005 — Investigator and Site Qualification Due Diligence
COPS-SOP-009 — Regulatory, IRB/EC, and Competent Authority Submission Oversight
COPS-SOP-010 — Study Start-Up Milestone Management and Site Activation Greenlight
COPS-SOP-011 — Investigator Meeting and Site Training Management
COPS-SOP-012 — Site Initiation Visit Planning, Conduct, and Documentation

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

COPS-P02 — WI execution model

Country/site feasibility and activation

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate approved protocol, country requirements and candidate site evidence. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: Study start-up lead performs and documents the work. Clinical operations lead owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Clinical operations lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Country/site readiness checklist and activation decision

The startup lead separates country-level approvals from site-specific requirements in the readiness checklist. Obtain regulatory confirmation for the country and verify current site approvals, contract status, training and system readiness. Submit the completed evidence to the Clinical Operations activation approver; retain the dated decision before authorizing enrollment.

Expected result: Country and site readiness are both established; activation exceptions cannot bypass required approvals.

Evidence to retain: Country/site readiness checklist and activation decision.

Step 2 — Feasibility scorecard and qualification evidence

Score each candidate site against protocol-specific recruitment, staffing, facilities and equipment criteria. Cite evidence and record why the chosen site is suitable.

Expected result: Unverified capacity is identified as a risk, not scored as established capability.

Evidence to retain: Feasibility scorecard and qualification evidence.

Step 3 — Dated activation checklist and approval links

Assemble the activation checklist by country and site. Verify ethics/regulatory approvals, approved consent versions, contracts and essential documents against the planned start date.

Expected result: Approvals cover the correct site, protocol and materials; no critical item is expired or missing.

Evidence to retain: Dated activation checklist and approval links.

Step 4 — Initiation report, training evidence and action closure

Conduct the initiation review with delegated site staff. Demonstrate consent, eligibility, safety notification, product and data-entry workflows; record training and open actions.

Expected result: Staff can locate contacts and current instructions; unresolved critical actions block activation.

Evidence to retain: Initiation report, training evidence and action closure.

Step 5 — Site greenlight and distribution record

Submit the exact activation package to the sponsor's authorized greenlight approver. Record the decision and communicate the allowed start date and scope.

Expected result: Greenlight is signed/approved before enrollment, and recipients acknowledge it.

Evidence to retain: Site greenlight and distribution record.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: No enrollment before applicable approvals and documented activation.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

COPS-P02 — consolidated record packet

Country/site feasibility and activation

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Site selection and activation dossier

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
COPS-FRM-003 Feasibility Strategy Worksheet	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-004 Country and Site Feasibility Questionnaire	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-005 Site Selection Scorecard	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-006 Investigator and Site Qualification Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-011 Regulatory/IRB/EC Submission and Approval Log	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-012 Site Activation Package Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-013 Site Greenlight Approval Form	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-014 Investigator Meeting Planning Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-015 Site Training Attendance and Retraining Log	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-016 SIV Readiness Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-017 Site Initiation Visit Report Template	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates COPS-SOP-004 — Study Feasibility, Country Strategy, and Site Selection; COPS-SOP-005 — Investigator and Site Qualification Due Diligence; COPS-SOP-009 — Regulatory, IRB/EC, and Competent Authority Submission Oversight; COPS-SOP-010 — Study Start-Up Milestone Management and Site Activation Greenlight; COPS-SOP-011 — Investigator Meeting and Site Training Management; COPS-SOP-012 — Site Initiation Visit Planning, Conduct, and Documentation. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
COPS-P02-F01 — Country/site; approval and consent versions; validity dates; outstanding prerequisites
COPS-P02-F02 — Readiness criterion; evidence; activation decision; authorized start date and scope

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Country and site readiness are both established; activation exceptions cannot bypass required approvals.	☐ Yes ☐ No ☐ N/A
Step 2: Unverified capacity is identified as a risk, not scored as established capability.	☐ Yes ☐ No ☐ N/A
Step 3: Approvals cover the correct site, protocol and materials; no critical item is expired or missing.	☐ Yes ☐ No ☐ N/A
Step 4: Staff can locate contacts and current instructions; unresolved critical actions block activation.	☐ Yes ☐ No ☐ N/A
Step 5: Greenlight is signed/approved before enrollment, and recipients acknowledge it.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

COPS-P03 — SOP model

Vendor qualification and lifecycle oversight

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Select and oversee qualified vendors and accept their work against agreed requirements.
Scope: Vendor qualification, contracting interfaces, performance review, change and exit. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Service scope, due diligence evidence and contract requirements. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Vendor manager
Accountable	Clinical operations lead
Consulted	Procurement; quality assurance; CDM; privacy
Informed	Affected study team and authorized downstream recipients

Vendor manager performs and documents the work. Clinical operations lead owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Qualification and deliverable acceptance authority are documented; unresolved critical gaps block startup. Record: Qualification assessment and approved acceptance responsibilities.
Evidence supports intended services and significant subcontracting is visible to the sponsor. Record: Due-diligence assessment.
No critical responsibility is left between two organizations without an owner. Record: Approved service/RACI and oversight plan.
Results meet approved acceptance criteria; failures have approved disposition. Record: Kickoff/readiness record.
Vendor closure does not strand essential records, data or unresolved obligations. Record: Performance review and closeout handoff.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Vendor manager performs the sequential instructions in COPS-P03-WI-01 and retains the specified evidence in COPS-P03-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Critical qualification or access deficiencies require disposition before use.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

For study governance, risk thresholds or plan changes, use COPS-P01 — Governance, study planning and quality oversight. Retain the decision or accepted handoff reference in this packet.
When a deviation, CAPA or controlled operational change is required, use COPS-P08 — Deviations, CAPA and controlled change. Retain the decision or accepted handoff reference in this packet.
Before operational closeout or system decommissioning, use COPS-P12 — Closeout, records retention and decommissioning. Retain the decision or accepted handoff reference in this packet.
For external source-data receipt or reconciliation, use CDM-P04 — External data transfer and reconciliation. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

6. Records and effectiveness

Retain the vendor qualification and oversight record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: COPS-P03-WI-01. Controlled record packet: COPS-P03-FRM-01 — Vendor qualification and oversight record.

COPS-P01 — Governance, study planning and quality oversight
COPS-P08 — Deviations, CAPA and controlled change
COPS-P12 — Closeout, records retention and decommissioning
CDM-P04 — External data transfer and reconciliation

Original-to-new crosswalk

COPS-SOP-006 — CRO and Vendor Selection, Qualification, Contracting Inputs, and Oversight
COPS-SOP-007 — Clinical Vendor Kickoff, Specification Approval, and Performance Governance
COPS-SOP-021 — Clinical Supplies, Central Lab, Imaging, ECG, eCOA, IRT, and Specialty Vendor Operational Oversight
COPS-SOP-028 — Subject Reimbursement, Travel, Home Health, and Decentralized Trial Vendor Oversight

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

COPS-P03 — WI execution model

Vendor qualification and lifecycle oversight

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate service scope, due diligence evidence and contract requirements. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: Vendor manager performs and documents the work. Clinical operations lead owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Clinical operations lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Qualification assessment and approved acceptance responsibilities

The vendor manager defines the service risk and acceptance criteria, obtains QA input on qualification appropriate to that risk, and records the qualification decision by the delegated sponsor owner. Assign an acceptance owner for each deliverable and interface, including any subcontracted work; resolve gaps before service initiation.

Expected result: Qualification and deliverable acceptance authority are documented; unresolved critical gaps block startup.

Evidence to retain: Qualification assessment and approved acceptance responsibilities.

Step 2 — Due-diligence assessment

Define each vendor's services, data access, subcontractors and failure risks. Request qualification evidence proportionate to those risks and document gaps.

Expected result: Evidence supports intended services and significant subcontracting is visible to the sponsor.

Evidence to retain: Due-diligence assessment.

Step 3 — Approved service/RACI and oversight plan

Reconcile the contract, specifications and oversight plan. Assign deliverables, acceptance criteria, notification timelines, audit/record access and exit obligations.

Expected result: No critical responsibility is left between two organizations without an owner.

Evidence to retain: Approved service/RACI and oversight plan.

Step 4 — Kickoff/readiness record

Use test cases or readiness evidence to verify interfaces, transfers, contact routes and contingency arrangements before first live use.

Expected result: Results meet approved acceptance criteria; failures have approved disposition.

Evidence to retain: Kickoff/readiness record.

Step 5 — Performance review and closeout handoff

Compare performance and significant changes at each scheduled review. Escalate unresolved risk; at exit obtain records, access transfer and outstanding-action ownership.

Expected result: Vendor closure does not strand essential records, data or unresolved obligations.

Evidence to retain: Performance review and closeout handoff.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Critical qualification or access deficiencies require disposition before use.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

COPS-P03 — consolidated record packet

Vendor qualification and lifecycle oversight

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Vendor qualification and oversight record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
COPS-FRM-007 CRO and Vendor Qualification Scorecard	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-008 Vendor Oversight Plan Template	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-009 Vendor Kickoff Agenda and Minutes	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-031 Specialty Vendor Readiness Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-040 Participant Support Vendor Oversight Checklist	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates COPS-SOP-006 — CRO and Vendor Selection, Qualification, Contracting Inputs, and Oversight; COPS-SOP-007 — Clinical Vendor Kickoff, Specification Approval, and Performance Governance; COPS-SOP-021 — Clinical Supplies, Central Lab, Imaging, ECG, eCOA, IRT, and Specialty Vendor Operational Oversight; COPS-SOP-028 — Subject Reimbursement, Travel, Home Health, and Decentralized Trial Vendor Oversight. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
COPS-P03-F01 — Service/deliverable; vendor/subcontractor; qualification risk; evidence reviewed; decision
COPS-P03-F02 — Acceptance criterion; performance result; issue owner/due date; exit custody and acceptance

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Qualification and deliverable acceptance authority are documented; unresolved critical gaps block startup.	☐ Yes ☐ No ☐ N/A
Step 2: Evidence supports intended services and significant subcontracting is visible to the sponsor.	☐ Yes ☐ No ☐ N/A
Step 3: No critical responsibility is left between two organizations without an owner.	☐ Yes ☐ No ☐ N/A
Step 4: Results meet approved acceptance criteria; failures have approved disposition.	☐ Yes ☐ No ☐ N/A
Step 5: Vendor closure does not strand essential records, data or unresolved obligations.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

COPS-P04 — SOP model

Risk-based monitoring and site issue resolution

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Identify and resolve site risks through proportionate monitoring.
Scope: Monitoring strategy and plan development, conduct, reporting and follow-up. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Monitoring plan, current risk review and site/data signals. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Monitoring lead
Accountable	Clinical operations lead
Consulted	CDM lead; medical monitor; quality assurance
Informed	Affected study team and authorized downstream recipients

Monitoring lead performs and documents the work. Clinical operations lead owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

The plan is approved and the report reviewer and issue-closure owner are assigned. Record: Monitoring plan approval, distribution and revision evidence.
Coverage addresses critical data and participant risks rather than only visit frequency. Record: Monitoring scope and risk rationale.
Each finding is specific, supported and assigned to the responsible site/function. Record: Visit/central-review record and findings.
Report review covers accuracy, evidence and escalation, not just formatting. Record: Reviewed report and comment disposition.
Actions are closed on evidence and effectiveness, not on a promised completion date. Record: Follow-up closure and risk-plan update.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Monitoring lead performs the sequential instructions in COPS-P04-WI-01 and retains the specified evidence in COPS-P04-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Unresolved significant findings escalate; report acceptance is not issue closure.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

For study governance, risk thresholds or plan changes, use COPS-P01 — Governance, study planning and quality oversight. Retain the decision or accepted handoff reference in this packet.
When consent, eligibility or enrollment oversight is affected, use COPS-P05 — Oversight of participant consent, eligibility and enrollment. Retain the decision or accepted handoff reference in this packet.
When a deviation, CAPA or controlled operational change is required, use COPS-P08 — Deviations, CAPA and controlled change. Retain the decision or accepted handoff reference in this packet.
When clinical-data review or query resolution is needed, use CDM-P05 — Clinical data review, queries and critical variables. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

6. Records and effectiveness

Retain the monitoring review and action record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: COPS-P04-WI-01. Controlled record packet: COPS-P04-FRM-01 — Monitoring review and action record.

COPS-P01 — Governance, study planning and quality oversight
COPS-P05 — Oversight of participant consent, eligibility and enrollment
COPS-P08 — Deviations, CAPA and controlled change
CDM-P05 — Clinical data review, queries and critical variables

Original-to-new crosswalk

COPS-SOP-013 — Monitoring Strategy, Risk-Based Quality Management, and Monitoring Plan
COPS-SOP-014 — Site Management, Routine Contact, and Communication Documentation
COPS-SOP-015 — Monitoring Visit Conduct: Onsite, Remote, and Central Monitoring
COPS-SOP-016 — Monitoring Report Review, Approval, and Follow-Up Management
COPS-SOP-029 — Data Cleaning Support, SDV/SDR, and Cross-Functional Data Issue Resolution

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

COPS-P04 — WI execution model

Risk-based monitoring and site issue resolution

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate monitoring plan, current risk review and site/data signals. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: Monitoring lead performs and documents the work. Clinical operations lead owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Clinical operations lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Monitoring plan approval, distribution and revision evidence

The monitoring lead prepares the monitoring plan from the current protocol and risk assessment. Specify critical data/processes, monitoring methods, review frequency, escalation triggers and report review authority. Obtain Clinical Operations approval and distribute the controlled plan before routine monitoring starts; reassess it after material risk changes.

Expected result: The plan is approved and the report reviewer and issue-closure owner are assigned.

Evidence to retain: Monitoring plan approval, distribution and revision evidence.

Step 2 — Monitoring scope and risk rationale

Select sites and activities from the approved monitoring plan using dated risk signals. Record the sample and reason for any change in coverage.

Expected result: Coverage addresses critical data and participant risks rather than only visit frequency.

Evidence to retain: Monitoring scope and risk rationale.

Step 3 — Visit/central-review record and findings

Perform authorized source review or verification against protocol and plan. Record discrepancy location and impact without copying unnecessary identifiers.

Expected result: Each finding is specific, supported and assigned to the responsible site/function.

Evidence to retain: Visit/central-review record and findings.

Step 4 — Reviewed report and comment disposition

Draft the report with findings, severity rationale and immediate actions. Send the same report version to the qualified reviewer; resolve comments visibly.

Expected result: Report review covers accuracy, evidence and escalation, not just formatting.

Evidence to retain: Reviewed report and comment disposition.

Step 5 — Follow-up closure and risk-plan update

Assign follow-up owners and dates. Inspect correction evidence; escalate repeated or overdue significant findings and reassess monitoring strategy.

Expected result: Actions are closed on evidence and effectiveness, not on a promised completion date.

Evidence to retain: Follow-up closure and risk-plan update.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Unresolved significant findings escalate; report acceptance is not issue closure.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

COPS-P04 — consolidated record packet

Risk-based monitoring and site issue resolution

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Monitoring review and action record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
COPS-FRM-018 Site Contact Report Template	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-019 Monitoring Visit Report for Onsite Remote and Hybrid Visits	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-021 Central Monitoring Review Log	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-022 Monitoring Report QC Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-023 Monitoring Follow-Up Action Item Log	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-041 Data Cleaning and Site Query Escalation Log	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates COPS-SOP-013 — Monitoring Strategy, Risk-Based Quality Management, and Monitoring Plan; COPS-SOP-014 — Site Management, Routine Contact, and Communication Documentation; COPS-SOP-015 — Monitoring Visit Conduct: Onsite, Remote, and Central Monitoring; COPS-SOP-016 — Monitoring Report Review, Approval, and Follow-Up Management; COPS-SOP-029 — Data Cleaning Support, SDV/SDR, and Cross-Functional Data Issue Resolution. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
COPS-P04-F01 — Plan/version; site; review date; sampled scope and rationale; reviewer
COPS-P04-F02 — Finding/location; severity and impact; action owner/due date; verification and closure

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: The plan is approved and the report reviewer and issue-closure owner are assigned.	☐ Yes ☐ No ☐ N/A
Step 2: Coverage addresses critical data and participant risks rather than only visit frequency.	☐ Yes ☐ No ☐ N/A
Step 3: Each finding is specific, supported and assigned to the responsible site/function.	☐ Yes ☐ No ☐ N/A
Step 4: Report review covers accuracy, evidence and escalation, not just formatting.	☐ Yes ☐ No ☐ N/A
Step 5: Actions are closed on evidence and effectiveness, not on a promised completion date.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

COPS-P05 — SOP model

Oversight of participant consent, eligibility and enrollment

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Oversee consent, eligibility and enrollment practices to identify and resolve risks to participants and study conduct.
Scope: Sponsor oversight of these activities; investigator site conduct and clinical decisions remain with the investigator. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Approved consent materials, eligibility criteria and recruitment plan. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Site management lead
Accountable	Clinical operations lead
Consulted	Investigator; medical monitor; recruitment lead
Informed	Affected study team and authorized downstream recipients

The site lead coordinates sponsor oversight; the Clinical Operations lead approves oversight actions. The investigator remains responsible for site consent conduct and clinical eligibility decisions. Medical expertise is consulted on clinical questions. Sponsor staff identify concerns and seek documented investigator resolution; they do not substitute their own eligibility decision. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Consent timing, version and authorization are supported; concerns go promptly to the investigator. Record: Consent oversight review.
The responsible clinician records the eligibility decision; unresolved criteria are not assumed satisfied. Record: Eligibility checklist and clinical decision link.
Remediation respects participant choice, privacy and protocol requirements. Record: Enrollment review and approved remediation plan.
Any required approval is obtained before changed materials or procedures are used. Record: Change approval, implementation and effectiveness review.
The recovery decision is supported and does not bypass consent or eligibility requirements. Record: Recovery assessment and authorized action plan.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Site management lead performs the sequential instructions in COPS-P05-WI-01 and retains the specified evidence in COPS-P05-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Investigator retains clinical decisions; consent precedes trial-specific procedures.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

Before site activation or reactivation, use COPS-P02 — Country/site feasibility and activation. Retain the decision or accepted handoff reference in this packet.
When safety information must be communicated or followed up, use COPS-P07 — Safety communication and follow-up. Retain the decision or accepted handoff reference in this packet.
When a deviation, CAPA or controlled operational change is required, use COPS-P08 — Deviations, CAPA and controlled change. Retain the decision or accepted handoff reference in this packet.
When clinical-data review or query resolution is needed, use CDM-P05 — Clinical data review, queries and critical variables. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

6. Records and effectiveness

Retain the participant pathway oversight record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: COPS-P05-WI-01. Controlled record packet: COPS-P05-FRM-01 — Participant pathway oversight record.

COPS-P02 — Country/site feasibility and activation
COPS-P07 — Safety communication and follow-up
COPS-P08 — Deviations, CAPA and controlled change
CDM-P05 — Clinical data review, queries and critical variables

Original-to-new crosswalk

COPS-SOP-017 — Subject Screening, Eligibility, Enrollment, and Randomization Oversight
COPS-SOP-018 — Informed Consent Oversight and Documentation
COPS-SOP-019 — Recruitment, Retention, Diversity, and Enrollment Remediation
COPS-SOP-033 — Study Rescue, Enrollment Recovery, and Operational Remediation

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

COPS-P05 — WI execution model

Oversight of participant consent, eligibility and enrollment

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate approved consent materials, eligibility criteria and recruitment plan. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The site lead coordinates sponsor oversight; the Clinical Operations lead approves oversight actions. The investigator remains responsible for site consent conduct and clinical eligibility decisions. Medical expertise is consulted on clinical questions. Sponsor staff identify concerns and seek documented investigator resolution; they do not substitute their own eligibility decision. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Clinical operations lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Consent oversight review

Check the site's current approved consent version and staff delegation. Verify the documented process covers understandable discussion, questions and required consent before trial-specific procedures.

Expected result: Consent timing, version and authorization are supported; concerns go promptly to the investigator.

Evidence to retain: Consent oversight review.

Step 2 — Eligibility checklist and clinical decision link

Compare eligibility evidence with each protocol criterion through the approved review channel. Send ambiguities to the investigator and medical monitor; do not make undocumented exceptions.

Expected result: The responsible clinician records the eligibility decision; unresolved criteria are not assumed satisfied.

Evidence to retain: Eligibility checklist and clinical decision link.

Step 3 — Enrollment review and approved remediation plan

Compare screening, enrollment and retention trends by site with planned assumptions. Review approved recruitment materials and reasons for avoidable barriers.

Expected result: Remediation respects participant choice, privacy and protocol requirements.

Evidence to retain: Enrollment review and approved remediation plan.

Step 4 — Change approval, implementation and effectiveness review

Before implementing a revised recruitment or retention approach, assess ethics review, training, vendor and consent implications. Track results and adverse consequences.

Expected result: Any required approval is obtained before changed materials or procedures are used.

Evidence to retain: Change approval, implementation and effectiveness review.

Step 5 — Recovery assessment and authorized action plan

When enrollment or site performance threatens study delivery, the Clinical Operations lead reviews the cause and feasibility of recovery with relevant site and medical personnel. Record the proposed recovery actions, resources, risks to participants and data, owner and reassessment date. Obtain sponsor study-owner approval for material changes and investigator agreement for site actions; verify required amended approvals before use.

Expected result: The recovery decision is supported and does not bypass consent or eligibility requirements.

Evidence to retain: Recovery assessment and authorized action plan.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Investigator retains clinical decisions; consent precedes trial-specific procedures.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

COPS-P05 — consolidated record packet

Oversight of participant consent, eligibility and enrollment

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Participant pathway oversight record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
COPS-FRM-024 Eligibility Review Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-025 Informed Consent QC Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-026 Enrollment Remediation Plan	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-027 Recruitment Material Approval Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-047 Study Rescue and Operational Remediation Plan	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates COPS-SOP-017 — Subject Screening, Eligibility, Enrollment, and Randomization Oversight; COPS-SOP-018 — Informed Consent Oversight and Documentation; COPS-SOP-019 — Recruitment, Retention, Diversity, and Enrollment Remediation; COPS-SOP-033 — Study Rescue, Enrollment Recovery, and Operational Remediation. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
COPS-P05-F01 — Site; approved consent version; delegation evidence; consent timing check
COPS-P05-F02 — Eligibility criterion and source reference; ambiguity/decision owner; recruitment change approval

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Consent timing, version and authorization are supported; concerns go promptly to the investigator.	☐ Yes ☐ No ☐ N/A
Step 2: The responsible clinician records the eligibility decision; unresolved criteria are not assumed satisfied.	☐ Yes ☐ No ☐ N/A
Step 3: Remediation respects participant choice, privacy and protocol requirements.	☐ Yes ☐ No ☐ N/A
Step 4: Any required approval is obtained before changed materials or procedures are used.	☐ Yes ☐ No ☐ N/A
Step 5: The recovery decision is supported and does not bypass consent or eligibility requirements.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

COPS-P06 — SOP model

Investigational product accountability

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Maintain traceable investigational-product handling and resolve accountability discrepancies.
Scope: Supply oversight, shipment readiness, reconciliation, excursion handling and final disposition. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Release authorization, shipping conditions and pharmacy readiness. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Clinical supply lead
Accountable	Sponsor supply owner
Consulted	Investigator/pharmacist; medical monitor; quality assurance
Informed	Affected study team and authorized downstream recipients

Clinical supplies personnel reconcile sponsor supply records and coordinate discrepancies. The sponsor supply owner accepts supply readiness. The investigator and delegated pharmacy staff retain site custody and accountability duties. The designated qualified product-quality decision maker authorizes excursion disposition; medical personnel assess participant impact where relevant. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Shipment is authorized and destination can maintain required conditions. Record: Shipment release checklist.
The inventory equation balances or each discrepancy has documented investigation. Record: Accountability reconciliation.
Quarantine remains until permitted disposition; clinical impact is escalated when needed. Record: Excursion assessment and disposition.
Affected stock is not used pending authorized disposition; balances and participant-impact actions are reconciled. Record: Excursion/discrepancy assessment and disposition.
No unexplained stock or outstanding disposition remains at closure. Record: Final product accountability and closure.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Clinical supply lead performs the sequential instructions in COPS-P06-WI-01 and retains the specified evidence in COPS-P06-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Do not use quarantined product without authorized disposition.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

Before site activation or reactivation, use COPS-P02 — Country/site feasibility and activation. Retain the decision or accepted handoff reference in this packet.
When safety information must be communicated or followed up, use COPS-P07 — Safety communication and follow-up. Retain the decision or accepted handoff reference in this packet.
For significant noncompliance or urgent safety measures, use COPS-P11 — Significant noncompliance and urgent safety measures. Retain the decision or accepted handoff reference in this packet.
Before operational closeout or system decommissioning, use COPS-P12 — Closeout, records retention and decommissioning. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Sponsor supply owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the product shipment, accountability and excursion record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: COPS-P06-WI-01. Controlled record packet: COPS-P06-FRM-01 — Product shipment, accountability and excursion record.

COPS-P02 — Country/site feasibility and activation
COPS-P07 — Safety communication and follow-up
COPS-P11 — Significant noncompliance and urgent safety measures
COPS-P12 — Closeout, records retention and decommissioning

Original-to-new crosswalk

COPS-SOP-020 — Investigational Product Management Oversight

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

COPS-P06 — WI execution model

Investigational product accountability

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate release authorization, shipping conditions and pharmacy readiness. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: Clinical supplies personnel reconcile sponsor supply records and coordinate discrepancies. The sponsor supply owner accepts supply readiness. The investigator and delegated pharmacy staff retain site custody and accountability duties. The designated qualified product-quality decision maker authorizes excursion disposition; medical personnel assess participant impact where relevant. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Sponsor supply owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Shipment release checklist

Match the shipment request to authorized site, product, lot, quantity and storage capability. Confirm release documentation before authorizing dispatch.

Expected result: Shipment is authorized and destination can maintain required conditions.

Evidence to retain: Shipment release checklist.

Step 2 — Accountability reconciliation

Reconcile shipped, received, dispensed, returned and destroyed quantities using controlled accountability records. Investigate unexplained differences.

Expected result: The inventory equation balances or each discrepancy has documented investigation.

Evidence to retain: Accountability reconciliation.

Step 3 — Excursion assessment and disposition

When monitoring shows an excursion or an unexplained balance, the supply coordinator records the affected product, lots, locations, quantities, times and measured conditions. Segregate affected stock and block further use in the applicable inventory workflow. Preserve logger data and shipment records, notify the supply owner, and identify any participant exposure for medical assessment.

Expected result: Quarantine remains until permitted disposition; clinical impact is escalated when needed.

Evidence to retain: Excursion assessment and disposition.

Step 4 — Excursion/discrepancy assessment and disposition

For a product excursion or unexplained discrepancy, identify and segregate affected stock, preserve shipment/storage records and notify the supply owner. Obtain documented disposition from the designated product-quality authority and medical assessment if participant exposure may be affected. Reconcile return, destruction or release records before closing the item.

Expected result: Affected stock is not used pending authorized disposition; balances and participant-impact actions are reconciled.

Evidence to retain: Excursion/discrepancy assessment and disposition.

Step 5 — Final product accountability and closure

At closeout, verify authorized return/destruction evidence and reconcile final balances. File the signed reconciliation with custody records.

Expected result: No unexplained stock or outstanding disposition remains at closure.

Evidence to retain: Final product accountability and closure.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Do not use quarantined product without authorized disposition.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

COPS-P06 — consolidated record packet

Investigational product accountability

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Product shipment, accountability and excursion record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
COPS-FRM-028 IP Shipment Release Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-029 IP Accountability Reconciliation Form	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-030 Temperature Excursion Assessment Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates COPS-SOP-020 — Investigational Product Management Oversight. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
COPS-P06-F01 — Product/lot; location; shipped/received/dispensed/returned/destroyed quantities; balance
COPS-P06-F02 — Excursion time/conditions; quarantine; exposure assessment; quality disposition; closure

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Shipment is authorized and destination can maintain required conditions.	☐ Yes ☐ No ☐ N/A
Step 2: The inventory equation balances or each discrepancy has documented investigation.	☐ Yes ☐ No ☐ N/A
Step 3: Quarantine remains until permitted disposition; clinical impact is escalated when needed.	☐ Yes ☐ No ☐ N/A
Step 4: Affected stock is not used pending authorized disposition; balances and participant-impact actions are reconciled.	☐ Yes ☐ No ☐ N/A
Step 5: No unexplained stock or outstanding disposition remains at closure.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

COPS-P07 — SOP model

Safety communication and follow-up

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Transmit safety information promptly and maintain traceable follow-up.
Scope: Operational safety notification and follow-up; case assessment and regulatory reporting follow the designated safety process. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Protocol safety plan, contact matrix and applicable reporting timelines. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Clinical safety coordinator
Accountable	Pharmacovigilance lead
Consulted	Investigator; medical monitor; clinical operations
Informed	Affected study team and authorized downstream recipients

The safety coordinator sends and follows up operational safety communications and verifies receipt. Pharmacovigilance owns case assessment and reporting coordination under the applicable safety arrangements. The investigator supplies clinical information and retains participant-care decisions. Clinical Operations supports site follow-up without delaying reporting. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Required notification is not delayed by incomplete administrative fields. Record: Timestamped notification and acknowledgment.
The log supports oversight and does not become an uncontrolled substitute safety database. Record: Case-reference communication log.
Outstanding safety information remains visible with a named owner and escalation history. Record: Follow-up tracker and communications.
Closure means receipt and disposition are documented, not merely that an email was sent. Record: Safety handoff reconciliation.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Clinical safety coordinator performs the sequential instructions in COPS-P07-WI-01 and retains the specified evidence in COPS-P07-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Do not delay safety reporting while reconciling or completing a form.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

When a deviation, CAPA or controlled operational change is required, use COPS-P08 — Deviations, CAPA and controlled change. Retain the decision or accepted handoff reference in this packet.
For significant noncompliance or urgent safety measures, use COPS-P11 — Significant noncompliance and urgent safety measures. Retain the decision or accepted handoff reference in this packet.
For differences between clinical and safety records, use CDM-P07 — Safety database reconciliation. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Pharmacovigilance lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the safety communication and follow-up record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: COPS-P07-WI-01. Controlled record packet: COPS-P07-FRM-01 — Safety communication and follow-up record.

COPS-P08 — Deviations, CAPA and controlled change
COPS-P11 — Significant noncompliance and urgent safety measures
CDM-P07 — Safety database reconciliation

Original-to-new crosswalk

COPS-SOP-022 — Safety Reporting Operations, SAE Notification, and Follow-Up Oversight

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

COPS-P07 — WI execution model

Safety communication and follow-up

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate protocol safety plan, contact matrix and applicable reporting timelines. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The safety coordinator sends and follows up operational safety communications and verifies receipt. Pharmacovigilance owns case assessment and reporting coordination under the applicable safety arrangements. The investigator supplies clinical information and retains participant-care decisions. Clinical Operations supports site follow-up without delaying reporting. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Pharmacovigilance lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Timestamped notification and acknowledgment

On receipt of safety information, identify the event and awareness time and use the approved urgent notification route. If acknowledgment fails, use the escalation contact immediately.

Expected result: Required notification is not delayed by incomplete administrative fields.

Evidence to retain: Timestamped notification and acknowledgment.

Step 2 — Case-reference communication log

Enter the case reference in the oversight log using only necessary identifiers. Link to the safety system and record the follow-up owner.

Expected result: The log supports oversight and does not become an uncontrolled substitute safety database.

Evidence to retain: Case-reference communication log.

Step 3 — Follow-up tracker and communications

Track requested follow-up to the investigator/site owner. Escalate approaching or missed deadlines using the safety plan and applicable reporting requirements.

Expected result: Outstanding safety information remains visible with a named owner and escalation history.

Evidence to retain: Follow-up tracker and communications.

Step 4 — Safety handoff reconciliation

At reconciliation, compare communication status with safety team receipt. Resolve missed or duplicate handoffs and obtain safety-owner confirmation.

Expected result: Closure means receipt and disposition are documented, not merely that an email was sent.

Evidence to retain: Safety handoff reconciliation.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Do not delay safety reporting while reconciling or completing a form.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

COPS-P07 — consolidated record packet

Safety communication and follow-up

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Safety communication and follow-up record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A	Evidence / exception / reviewer
COPS-FRM-032 Safety Event Communication Log	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-033 SAE Follow-Up Oversight Checklist	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates COPS-SOP-022 — Safety Reporting Operations, SAE Notification, and Follow-Up Oversight. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
COPS-P07-F01 — Case reference; initial awareness date/time; required route and deadline; sender/recipient
COPS-P07-F02 — Acknowledgment time; follow-up owner; due date; reconciliation and escalation outcome

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Required notification is not delayed by incomplete administrative fields.	☐ Yes ☐ No ☐ N/A
Step 2: The log supports oversight and does not become an uncontrolled substitute safety database.	☐ Yes ☐ No ☐ N/A
Step 3: Outstanding safety information remains visible with a named owner and escalation history.	☐ Yes ☐ No ☐ N/A
Step 4: Closure means receipt and disposition are documented, not merely that an email was sent.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

COPS-P08 — SOP model

Deviations, CAPA and controlled change

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Assess deviations and proposed changes and implement proportionate corrective actions or approved changes.
Scope: Deviation assessment, CAPA when warranted, controlled change and effectiveness review. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Issue evidence, applicable requirements and change request. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Clinical operations lead
Accountable	Sponsor quality process owner
Consulted	Medical monitor; regulatory; CDM; programming
Informed	Affected study team and authorized downstream recipients

Clinical operations lead performs and documents the work. Sponsor quality process owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Participant and data impact are assessed before routine root-cause review. Record: Issue assessment and containment evidence.
The cause explains the failure; 'retrain staff' alone is not a root-cause conclusion. Record: Investigation and root-cause analysis.
The approved action addresses the cause and does not introduce uncontrolled changes. Record: CAPA/change plan and implementation evidence.
Closure includes effectiveness evidence and accountable approval. Record: Effectiveness review and closure decision.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Clinical operations lead performs the sequential instructions in COPS-P08-WI-01 and retains the specified evidence in COPS-P08-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Change approval does not waive ethics or regulatory amendment requirements.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

For study governance, risk thresholds or plan changes, use COPS-P01 — Governance, study planning and quality oversight. Retain the decision or accepted handoff reference in this packet.
For significant noncompliance or urgent safety measures, use COPS-P11 — Significant noncompliance and urgent safety measures. Retain the decision or accepted handoff reference in this packet.
Before a database change or migration, use CDM-P08 — Database change, migration and regression control. Retain the decision or accepted handoff reference in this packet.
When programming plans, assignments or quality decisions change, use CPROG-P01 — Programming governance, planning and quality. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Sponsor quality process owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the issue, change and capa record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: COPS-P08-WI-01. Controlled record packet: COPS-P08-FRM-01 — Issue, change and CAPA record.

COPS-P01 — Governance, study planning and quality oversight
COPS-P11 — Significant noncompliance and urgent safety measures
CDM-P08 — Database change, migration and regression control
CPROG-P01 — Programming governance, planning and quality

Original-to-new crosswalk

COPS-SOP-023 — Protocol Deviation, Issue Management, and Escalation
COPS-SOP-024 — CAPA, Quality Event, and Root Cause Management
COPS-SOP-025 — Protocol Amendments, ICF Updates, and Operational Change Control

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

COPS-P08 — WI execution model

Deviations, CAPA and controlled change

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate issue evidence, applicable requirements and change request. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: Clinical operations lead performs and documents the work. Sponsor quality process owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Sponsor quality process owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Issue assessment and containment evidence

The Clinical Operations lead records the event or proposed change, affected baseline, discovery/request date and immediate impact. Classify it as a deviation/noncompliance, a planned change, or both. For deviations, contain impact and assess whether investigation and CAPA are warranted by significance and recurrence. For planned changes, assess prospective risks, approvals and implementation checks; do not require CAPA solely because a change is requested.

Expected result: Participant and data impact are assessed before routine root-cause review.

Evidence to retain: Issue assessment and containment evidence.

Step 2 — Investigation and root-cause analysis

For a deviation requiring investigation, establish the cause from evidence and select corrective/preventive actions proportionate to the risk. For a planned change, document the reason, affected documents/systems, required testing, approvals and transition arrangements. The quality process owner confirms the applicable route and decision authority; link both records when a change implements CAPA.

Expected result: The cause explains the failure; 'retrain staff' alone is not a root-cause conclusion.

Evidence to retain: Investigation and root-cause analysis.

Step 3 — CAPA/change plan and implementation evidence

Define each action, owner, due date, affected documents/systems and verification method. Obtain required change, ethics or regulatory approvals before implementation.

Expected result: The approved action addresses the cause and does not introduce uncontrolled changes.

Evidence to retain: CAPA/change plan and implementation evidence.

Step 4 — Effectiveness review and closure decision

At the planned effectiveness check, compare actual evidence with prespecified success criteria. Reopen or escalate unsuccessful actions.

Expected result: Closure includes effectiveness evidence and accountable approval.

Evidence to retain: Effectiveness review and closure decision.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Change approval does not waive ethics or regulatory amendment requirements.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

COPS-P08 — consolidated record packet

Deviations, CAPA and controlled change

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Issue, change and CAPA record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
COPS-FRM-034 Protocol Deviation Assessment Form	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-035 Issue Escalation Form	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-036 CAPA Plan and Effectiveness Check Form	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-037 Amendment Impact Assessment Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates COPS-SOP-023 — Protocol Deviation, Issue Management, and Escalation; COPS-SOP-024 — CAPA, Quality Event, and Root Cause Management; COPS-SOP-025 — Protocol Amendments, ICF Updates, and Operational Change Control. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
COPS-P08-F01 — Event or proposed change; affected baseline; classification; containment; impact
COPS-P08-F02 — Investigation/cause where required; action owner/date; approval; effectiveness criterion/result

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Participant and data impact are assessed before routine root-cause review.	☐ Yes ☐ No ☐ N/A
Step 2: The cause explains the failure; 'retrain staff' alone is not a root-cause conclusion.	☐ Yes ☐ No ☐ N/A
Step 3: The approved action addresses the cause and does not introduce uncontrolled changes.	☐ Yes ☐ No ☐ N/A
Step 4: Closure includes effectiveness evidence and accountable approval.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

COPS-P09 — SOP model

Interim review and restricted information transfer

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Deliver interim review information to authorized recipients while preserving required blinding.
Scope: Restricted interim information preparation, review, transfer and incident response. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Charter, firewall plan, access list and authorized output scope. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Authorized unblinded coordinator
Accountable	Sponsor designated unblinded owner
Consulted	Biostatistics; DMC secretariat; restricted programming team
Informed	Affected study team and authorized downstream recipients

The authorized unblinded coordinator prepares and checks the transfer. The designated unblinded owner authorizes release within the charter; the DMC/secretariat confirms authorized receipt. Biostatistics resolves statistical content questions. Clinical Operations receives only the blinded decisions or permitted instructions needed to act; unblinded details remain within the firewall. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Recipients are authorized for the information level and blinded personnel are excluded. Record: Restricted request and access review.
Package content and classification match the authorized scope. Record: Restricted package manifest.
Review includes indirect disclosure channels, not just visible tables. Record: Restricted QC and transfer authorization.
Receipt is documented; incidents preserve chronology and containment evidence. Record: Transfer receipt or incident assessment.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Authorized unblinded coordinator performs the sequential instructions in COPS-P09-WI-01 and retains the specified evidence in COPS-P09-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Any unauthorized disclosure triggers containment and blind-impact assessment.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

For an analysis cut, freeze/lock or data handoff, use CDM-P09 — Data cuts, lock and programming handoff. Retain the decision or accepted handoff reference in this packet.
For restricted interim/DMC programming outputs, use CPROG-P08 — Interim/DMC outputs and firewall management. Retain the decision or accepted handoff reference in this packet.
When treatment information or blinding may be affected, use CPROG-P09 — Randomization, treatment handling and blind breaks. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Sponsor designated unblinded owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the restricted interim transfer packet, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: COPS-P09-WI-01. Controlled record packet: COPS-P09-FRM-01 — Restricted interim transfer packet.

CDM-P09 — Data cuts, lock and programming handoff
CPROG-P08 — Interim/DMC outputs and firewall management
CPROG-P09 — Randomization, treatment handling and blind breaks

Original-to-new crosswalk

COPS-SOP-030 — Interim Data Cuts, DSMB/DMC Support, and Blinded/Unblinded Firewalls

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

COPS-P09 — WI execution model

Interim review and restricted information transfer

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate charter, firewall plan, access list and authorized output scope. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The authorized unblinded coordinator prepares and checks the transfer. The designated unblinded owner authorizes release within the charter; the DMC/secretariat confirms authorized receipt. Biostatistics resolves statistical content questions. Clinical Operations receives only the blinded decisions or permitted instructions needed to act; unblinded details remain within the firewall. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Sponsor designated unblinded owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Restricted request and access review

Check the DMC charter and firewall plan against the requested material and recipients. Confirm every recipient's role and authorization in the restricted access list.

Expected result: Recipients are authorized for the information level and blinded personnel are excluded.

Evidence to retain: Restricted request and access review.

Step 2 — Restricted package manifest

Reconcile requested outputs to exact cut, specification and output versions. Mark treatment-revealing materials and store them only in the approved restricted location.

Expected result: Package content and classification match the authorized scope.

Evidence to retain: Restricted package manifest.

Step 3 — Restricted QC and transfer authorization

Have an authorized independent reviewer inspect masking, file metadata, filenames, attachments and the final recipient list.

Expected result: Review includes indirect disclosure channels, not just visible tables.

Evidence to retain: Restricted QC and transfer authorization.

Step 4 — Transfer receipt or incident assessment

Transfer through the approved secure route and obtain acknowledgment. For misdelivery, contain access and trigger disclosure-impact review immediately.

Expected result: Receipt is documented; incidents preserve chronology and containment evidence.

Evidence to retain: Transfer receipt or incident assessment.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Any unauthorized disclosure triggers containment and blind-impact assessment.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

COPS-P09 — consolidated record packet

Interim review and restricted information transfer

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Restricted interim transfer packet

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A	Evidence / exception / reviewer
COPS-FRM-042 DMC/DSMB Materials Transfer Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-043 Blinding Firewall Access Authorization Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates COPS-SOP-030 — Interim Data Cuts, DSMB/DMC Support, and Blinded/Unblinded Firewalls. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
COPS-P09-F01 — Charter/firewall version; meeting; cut; output ID/version; authorized audience
COPS-P09-F02 — Masking/metadata review; reviewer; transfer time/channel; receipt or incident reference

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Recipients are authorized for the information level and blinded personnel are excluded.	☐ Yes ☐ No ☐ N/A
Step 2: Package content and classification match the authorized scope.	☐ Yes ☐ No ☐ N/A
Step 3: Review includes indirect disclosure channels, not just visible tables.	☐ Yes ☐ No ☐ N/A
Step 4: Receipt is documented; incidents preserve chronology and containment evidence.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

COPS-P10 — SOP model

Inspection readiness and authority responses

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Provide accurate, traceable and authorized inspection responses.
Scope: Inspection readiness, request coordination, evidence retrieval, response review and follow-up. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Essential-record inventory and authority request. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Inspection coordinator
Accountable	Sponsor inspection owner
Consulted	Quality assurance; functional leads; regulatory
Informed	Affected study team and authorized downstream recipients

Inspection coordinator performs and documents the work. Sponsor inspection owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Readiness gaps have owners and responses are supported by existing evidence; records are not retrospectively fabricated. Record: Readiness sample results and authorized response evidence.
The response owner understands the exact request and due date. Record: Request intake log.
Evidence is attributable and traceable, including superseded versions when requested. Record: Evidence inventory and gap explanation.
The final response matches evidence and does not overstate compliance. Record: Approved response and review record.
Submitted version is retrievable and commitments have owners. Record: Submission record and commitment log.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Inspection coordinator performs the sequential instructions in COPS-P10-WI-01 and retains the specified evidence in COPS-P10-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Never reconstruct missing evidence as if contemporaneous.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

For significant noncompliance or urgent safety measures, use COPS-P11 — Significant noncompliance and urgent safety measures. Retain the decision or accepted handoff reference in this packet.
Before operational closeout or system decommissioning, use COPS-P12 — Closeout, records retention and decommissioning. Retain the decision or accepted handoff reference in this packet.
For data-management record retrieval, archive or authorized disclosure, use CDM-P10 — Records, inspection, archive and authorized sharing. Retain the decision or accepted handoff reference in this packet.
Before archiving programming evidence or verifying reconstruction, use CPROG-P11 — Archive and reproducibility. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Sponsor inspection owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the inspection request and response record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: COPS-P10-WI-01. Controlled record packet: COPS-P10-FRM-01 — Inspection request and response record.

COPS-P11 — Significant noncompliance and urgent safety measures
COPS-P12 — Closeout, records retention and decommissioning
CDM-P10 — Records, inspection, archive and authorized sharing
CPROG-P11 — Archive and reproducibility

Original-to-new crosswalk

COPS-SOP-031 — Audit Readiness, Inspection Support, and Regulatory Authority Requests

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

COPS-P10 — WI execution model

Inspection readiness and authority responses

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate essential-record inventory and authority request. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: Inspection coordinator performs and documents the work. Sponsor inspection owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Sponsor inspection owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Readiness sample results and authorized response evidence

The inspection coordinator selects a risk-based sample of important study decisions and asks the responsible functions to retrieve supporting versions, approvals and follow-up records. Record missing or inconsistent evidence and assign correction owners. Before an authority response is sent, obtain scoped functional and QA review and authorization from the designated inspection response owner.

Expected result: Readiness gaps have owners and responses are supported by existing evidence; records are not retrospectively fabricated.

Evidence to retain: Readiness sample results and authorized response evidence.

Step 2 — Request intake log

Record the authority request verbatim with scope, deadline, assigned owner and response approver. Confirm ambiguities through the authorized inspection coordinator.

Expected result: The response owner understands the exact request and due date.

Evidence to retain: Request intake log.

Step 3 — Evidence inventory and gap explanation

Retrieve the requested records and establish their version, origin and context. Identify missing records openly and investigate rather than recreating history.

Expected result: Evidence is attributable and traceable, including superseded versions when requested.

Evidence to retain: Evidence inventory and gap explanation.

Step 4 — Approved response and review record

Ask functional and quality reviewers to check factual accuracy, completeness, consistency and permitted redactions. Resolve conflicts before submission.

Expected result: The final response matches evidence and does not overstate compliance.

Evidence to retain: Approved response and review record.

Step 5 — Submission record and commitment log

Submit only through the authorized channel. Preserve exactly what was sent, its recipient and time, and track follow-up commitments.

Expected result: Submitted version is retrievable and commitments have owners.

Evidence to retain: Submission record and commitment log.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Never reconstruct missing evidence as if contemporaneous.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

COPS-P10 — consolidated record packet

Inspection readiness and authority responses

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Inspection request and response record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A	Evidence / exception / reviewer
COPS-FRM-044 Audit/Inspection Readiness Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-045 Regulatory Authority Request Response Log	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates COPS-SOP-031 — Audit Readiness, Inspection Support, and Regulatory Authority Requests. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
COPS-P10-F01 — Authority request; scope; deadline; assigned owner; response approver
COPS-P10-F02 — Record/version supplied; factual review; missing-record disposition; submission and commitment evidence

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Readiness gaps have owners and responses are supported by existing evidence; records are not retrospectively fabricated.	☐ Yes ☐ No ☐ N/A
Step 2: The response owner understands the exact request and due date.	☐ Yes ☐ No ☐ N/A
Step 3: Evidence is attributable and traceable, including superseded versions when requested.	☐ Yes ☐ No ☐ N/A
Step 4: The final response matches evidence and does not overstate compliance.	☐ Yes ☐ No ☐ N/A
Step 5: Submitted version is retrievable and commitments have owners.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

COPS-P11 — SOP model

Significant noncompliance and urgent safety measures

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Contain significant noncompliance and urgent safety risks and authorize appropriate follow-up.
Scope: Immediate protection, escalation, reportability assessment, corrective action and restart decisions. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Event facts, participant impact and jurisdiction requirements. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Clinical operations lead
Accountable	Sponsor designated quality process owner
Consulted	Pharmacovigilance; regulatory; investigator
Informed	Affected study team and authorized downstream recipients

Clinical Operations coordinates containment and follow-up. The investigator/treating physician makes immediate participant-care decisions; the designated medical owner assesses wider safety measures. The quality owner directs significant-noncompliance assessment. Safety and regulatory owners determine applicable reporting and timelines. The sponsor study owner authorizes restart after documented medical and quality acceptance and any required external authorization. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Immediate response follows medical judgment and the emergency pathway. Record: Initial event chronology and containment.
Critical escalation is acknowledged and not left in an unattended inbox. Record: Notification history.
Deadlines are explicit for this event; routine CAPA timing cannot reset them. Record: Reportability assessment and notifications.
Restart decision is supported by participant/data risk assessment. Record: Corrective evidence and restart/closure decision.
Restart is authorized and no unresolved safety or mandatory approval requirement is bypassed. Record: Restart decision and readiness evidence.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Clinical operations lead performs the sequential instructions in COPS-P11-WI-01 and retains the specified evidence in COPS-P11-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Escalation and statutory clocks run independently of routine CAPA review.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

When safety information must be communicated or followed up, use COPS-P07 — Safety communication and follow-up. Retain the decision or accepted handoff reference in this packet.
When a deviation, CAPA or controlled operational change is required, use COPS-P08 — Deviations, CAPA and controlled change. Retain the decision or accepted handoff reference in this packet.
On an inspection request or readiness review, use COPS-P10 — Inspection readiness and authority responses. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Sponsor medical/quality designated owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the significant event assessment and notification record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: COPS-P11-WI-01. Controlled record packet: COPS-P11-FRM-01 — Significant event assessment and notification record.

COPS-P07 — Safety communication and follow-up
COPS-P08 — Deviations, CAPA and controlled change
COPS-P10 — Inspection readiness and authority responses

Original-to-new crosswalk

COPS-SOP-032 — Serious Breach, Significant Noncompliance, and Urgent Safety Measure Management

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

COPS-P11 — WI execution model

Significant noncompliance and urgent safety measures

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate event facts, participant impact and jurisdiction requirements. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: Clinical Operations coordinates containment and follow-up. The investigator/treating physician makes immediate participant-care decisions; the designated medical owner assesses wider safety measures. The quality owner directs significant-noncompliance assessment. Safety and regulatory owners determine applicable reporting and timelines. The sponsor study owner authorizes restart after documented medical and quality acceptance and any required external authorization. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Sponsor medical/quality designated owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Initial event chronology and containment

Protect participants and contain the affected activity without waiting for a routine meeting. Record the known facts and time the organization became aware.

Expected result: Immediate response follows medical judgment and the emergency pathway.

Evidence to retain: Initial event chronology and containment.

Step 2 — Notification history

Notify the designated medical, safety, quality and regulatory contacts using the escalation matrix. Confirm receipt and alternate contact if needed.

Expected result: Critical escalation is acknowledged and not left in an unattended inbox.

Evidence to retain: Notification history.

Step 3 — Reportability assessment and notifications

Have the authorized functions assess reportability, jurisdiction, applicable clock and recipients. Record the legal/regulatory basis and decision, including a decision not to report.

Expected result: Deadlines are explicit for this event; routine CAPA timing cannot reset them.

Evidence to retain: Reportability assessment and notifications.

Step 4 — Corrective evidence and restart/closure decision

The assigned action owners implement containment and corrective work. Record completion evidence against each acceptance criterion and identify any remaining participant, data or operational risk. The medical, quality and regulatory owners review the relevant evidence and determine what additional external approval or notification is needed before the proposed restart.

Expected result: Restart decision is supported by participant/data risk assessment.

Evidence to retain: Corrective evidence and restart/closure decision.

Step 5 — Restart decision and readiness evidence

Before restarting an affected activity, the Clinical Operations lead compiles containment, medical assessment, quality disposition and required external approvals. The sponsor study owner records the restart scope, conditions and rationale after the medical and quality owners confirm acceptance. Communicate only the authorized instructions and verify readiness before resumption.

Expected result: Restart is authorized and no unresolved safety or mandatory approval requirement is bypassed.

Evidence to retain: Restart decision and readiness evidence.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Escalation and statutory clocks run independently of routine CAPA review.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

COPS-P11 — consolidated record packet

Significant noncompliance and urgent safety measures

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Significant event assessment and notification record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A	Evidence / exception / reviewer
COPS-FRM-046 Serious Breach and Urgent Safety Measure Assessment	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates COPS-SOP-032 — Serious Breach, Significant Noncompliance, and Urgent Safety Measure Management. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
COPS-P11-F01 — Awareness time; facts; immediate protection; medical/QA/regulatory notifications
COPS-P11-F02 — Reportability basis and clock; reporting evidence; restart criteria; approval and scope

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Immediate response follows medical judgment and the emergency pathway.	☐ Yes ☐ No ☐ N/A
Step 2: Critical escalation is acknowledged and not left in an unattended inbox.	☐ Yes ☐ No ☐ N/A
Step 3: Deadlines are explicit for this event; routine CAPA timing cannot reset them.	☐ Yes ☐ No ☐ N/A
Step 4: Restart decision is supported by participant/data risk assessment.	☐ Yes ☐ No ☐ N/A
Step 5: Restart is authorized and no unresolved safety or mandatory approval requirement is bypassed.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

COPS-P12 — SOP model

Closeout, records retention and decommissioning

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Close study activities while preserving accessible records and controlled system retirement.
Scope: Ongoing essential-record readiness, closeout reconciliation, archive acceptance and decommissioning. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Filing plan, retention schedule and closeout criteria. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Study closeout coordinator
Accountable	Clinical operations lead
Consulted	Records owner; CDM; programming; vendor; IT
Informed	Affected study team and authorized downstream recipients

The closeout coordinator maintains the essential-record inventory throughout study conduct and reconciles closure obligations. Clinical Operations authorizes operational closeout. The records custodian accepts archive custody after retrieval verification; IT or the vendor executes authorized decommissioning only after retention and access requirements are satisfied. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

The inventory points to retrievable records and distinguishes missing from not applicable. Record: Essential-record inventory.
Closure does not conceal unresolved obligations; approved follow-up has a continuing owner. Record: Closeout checklist and handoff.
The records owner accepts the archive and can retrieve the tested records. Record: Archive acceptance and retrieval test.
No required record becomes inaccessible after the system is retired. Record: Retention decision and decommission authorization.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Study closeout coordinator performs the sequential instructions in COPS-P12-WI-01 and retains the specified evidence in COPS-P12-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Preserve records subject to retention or legal hold; archive acceptance precedes shutdown.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

When qualifying vendors or resolving vendor performance issues, use COPS-P03 — Vendor qualification and lifecycle oversight. Retain the decision or accepted handoff reference in this packet.
When product accountability or disposition is involved, use COPS-P06 — Investigational product accountability. Retain the decision or accepted handoff reference in this packet.
For data-management record retrieval, archive or authorized disclosure, use CDM-P10 — Records, inspection, archive and authorized sharing. Retain the decision or accepted handoff reference in this packet.
Before archiving programming evidence or verifying reconstruction, use CPROG-P11 — Archive and reproducibility. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

6. Records and effectiveness

Retain the essential-record lifecycle and closeout packet, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: COPS-P12-WI-01. Controlled record packet: COPS-P12-FRM-01 — Essential-record lifecycle and closeout packet.

COPS-P03 — Vendor qualification and lifecycle oversight
COPS-P06 — Investigational product accountability
CDM-P10 — Records, inspection, archive and authorized sharing
CPROG-P11 — Archive and reproducibility

Original-to-new crosswalk

COPS-SOP-008 — Essential Documents and TMF/eTMF Management
COPS-SOP-034 — Site Closeout Visit and End-of-Study Activities
COPS-SOP-035 — Study Closeout, Vendor Closeout, Final Reconciliation, and Archival
COPS-SOP-036 — Clinical Trial Records Retention and System Decommissioning

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

COPS-P12 — WI execution model

Closeout, records retention and decommissioning

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate filing plan, retention schedule and closeout criteria. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The closeout coordinator maintains the essential-record inventory throughout study conduct and reconciles closure obligations. Clinical Operations authorizes operational closeout. The records custodian accepts archive custody after retrieval verification; IT or the vendor executes authorized decommissioning only after retention and access requirements are satisfied. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Clinical operations lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Essential-record inventory

Maintain the essential-record inventory during the study. For missing or late records, identify the custodian, reason, due date and escalation; preserve metadata and version history.

Expected result: The inventory points to retrievable records and distinguishes missing from not applicable.

Evidence to retain: Essential-record inventory.

Step 2 — Closeout checklist and handoff

Before site/vendor closure, reconcile open data queries, safety follow-up, product, records and contractual obligations with the responsible functions.

Expected result: Closure does not conceal unresolved obligations; approved follow-up has a continuing owner.

Evidence to retain: Closeout checklist and handoff.

Step 3 — Archive acceptance and retrieval test

Transfer the archive with a manifest and custody record. Test a risk-based sample for readability, access, metadata and retrieval in the receiving repository.

Expected result: The records owner accepts the archive and can retrieve the tested records.

Evidence to retain: Archive acceptance and retrieval test.

Step 4 — Retention decision and decommission authorization

Verify retention, legal holds, access needs and backup/restore arrangements before decommissioning. Obtain authorization and retain the shutdown evidence.

Expected result: No required record becomes inaccessible after the system is retired.

Evidence to retain: Retention decision and decommission authorization.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Preserve records subject to retention or legal hold; archive acceptance precedes shutdown.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

COPS-P12 — consolidated record packet

Closeout, records retention and decommissioning

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Essential-record lifecycle and closeout packet

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
COPS-FRM-010 TMF Start-Up Essential Document Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-048 Site Closeout Visit Checklist and Report	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-049 Vendor Closeout Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-050 Final Study Closeout Checklist	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-051 Archive Transfer and Retrieval Form	□ Yes □ No	□ Yes □ No □ N/A
COPS-FRM-052 Study Lessons Learned Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates COPS-SOP-008 — Essential Documents and TMF/eTMF Management; COPS-SOP-034 — Site Closeout Visit and End-of-Study Activities; COPS-SOP-035 — Study Closeout, Vendor Closeout, Final Reconciliation, and Archival; COPS-SOP-036 — Clinical Trial Records Retention and System Decommissioning. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
COPS-P12-F01 — Custodian; required record; controlled location; missing-item disposition
COPS-P12-F02 — Archive manifest; retrieval result; retention/hold basis; receiving acceptance; shutdown authorization

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: The inventory points to retrievable records and distinguishes missing from not applicable.	☐ Yes ☐ No ☐ N/A
Step 2: Closure does not conceal unresolved obligations; approved follow-up has a continuing owner.	☐ Yes ☐ No ☐ N/A
Step 3: The records owner accepts the archive and can retrieve the tested records.	☐ Yes ☐ No ☐ N/A
Step 4: No required record becomes inaccessible after the system is retired.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CDM-P01 — SOP model

Data governance, planning and vendor oversight

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Establish and maintain an approved data-management approach and oversee its execution.
Scope: Data-management planning, assigned responsibilities, vendor interfaces and quality review. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Protocol, data flows, vendor scope and critical-to-quality factors. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	CDM lead
Accountable	Sponsor data owner
Consulted	Clinical operations; biostatistics; programming; quality assurance
Informed	Affected study team and authorized downstream recipients

CDM lead performs and documents the work. Sponsor data owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

The DMP and critical interfaces are approved before use. Record: DMP review, approval and version distribution.
Each critical variable has a source, review method and accountable decision owner. Record: Data-flow and critical-data inventory.
No data stream or release gate is unassigned or owned only by an unnamed vendor. Record: Approved DMP and responsibility matrix.
A threshold has a defined action and owner, not only a dashboard color. Record: Metrics definitions and escalation plan.
Status statements link to evidence; unresolved significant risks are escalated. Record: Governance review and controlled plan revision.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: CDM lead performs the sequential instructions in CDM-P01-WI-01 and retains the specified evidence in CDM-P01-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Unowned data flows or undefined critical-data checks block readiness.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

For study governance, risk thresholds or plan changes, use COPS-P01 — Governance, study planning and quality oversight. Retain the decision or accepted handoff reference in this packet.
When qualifying vendors or resolving vendor performance issues, use COPS-P03 — Vendor qualification and lifecycle oversight. Retain the decision or accepted handoff reference in this packet.
Before building or releasing a data-collection system, use CDM-P02 — Data standards, collection, build and validation. Retain the decision or accepted handoff reference in this packet.
When programming plans, assignments or quality decisions change, use CPROG-P01 — Programming governance, planning and quality. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Sponsor data owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the data management plan and governance record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CDM-P01-WI-01. Controlled record packet: CDM-P01-FRM-01 — Data management plan and governance record.

COPS-P01 — Governance, study planning and quality oversight
COPS-P03 — Vendor qualification and lifecycle oversight
CDM-P02 — Data standards, collection, build and validation
CPROG-P01 — Programming governance, planning and quality

Original-to-new crosswalk

CDM-SOP-001 — CDM Governance, Data Ownership, Vendor Oversight, and Quality Management
CDM-SOP-002 — Protocol/CDM Feasibility, Critical Data Identification, and Start-Up Risk Assessment
CDM-SOP-004 — Data Management Plan Development, Approval, and Maintenance
CDM-SOP-020 — Clinical Data Quality Metrics, Trends, Escalation, and CAPA
CDM-SOP-021 — Data Review Meeting Governance and Cross-Functional Issue Escalation
CDM-SOP-022 — Vendor Data Management Oversight and CRO Performance Review

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CDM-P01 — WI execution model

Data governance, planning and vendor oversight

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate protocol, data flows, vendor scope and critical-to-quality factors. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: CDM lead performs and documents the work. Sponsor data owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Sponsor data owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — DMP review, approval and version distribution

The CDM lead drafts the data-management plan using protocol requirements and agreed interfaces. Obtain review from functions responsible for critical data, analysis and safety interfaces, resolve comments, and obtain designated data-owner approval before implementation. Repeat scoped review and approval for material revisions; distribute the effective version.

Expected result: The DMP and critical interfaces are approved before use.

Evidence to retain: DMP review, approval and version distribution.

Step 2 — Data-flow and critical-data inventory

Read the protocol with clinical operations and biostatistics. Inventory collected and external data, critical variables, intended analyses, owners and transfer dependencies.

Expected result: Each critical variable has a source, review method and accountable decision owner.

Evidence to retain: Data-flow and critical-data inventory.

Step 3 — Approved DMP and responsibility matrix

Draft the DMP against the inventory. Assign build, cleaning, coding, reconciliation, lock and handoff responsibilities; compare vendor obligations with the sponsor RACI.

Expected result: No data stream or release gate is unassigned or owned only by an unnamed vendor.

Evidence to retain: Approved DMP and responsibility matrix.

Step 4 — Metrics definitions and escalation plan

Set risk-based review frequencies and measures with denominators, source periods and escalation triggers. Document who reviews each signal and how actions close.

Expected result: A threshold has a defined action and owner, not only a dashboard color.

Evidence to retain: Metrics definitions and escalation plan.

Step 5 — Governance review and controlled plan revision

At each review, reconcile vendor evidence, overdue issues and changes with the current plan. Record decisions and update affected plans through approval.

Expected result: Status statements link to evidence; unresolved significant risks are escalated.

Evidence to retain: Governance review and controlled plan revision.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Unowned data flows or undefined critical-data checks block readiness.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CDM-P01 — consolidated record packet

Data governance, planning and vendor oversight

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Data management plan and governance record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
CDM-FRM-001 Study Start-Up Risk Assessment Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-002 Data Management Plan Development, Review, and Approval Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-025 Vendor/CRO Data Management Oversight Review Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-026 Sponsor Deliverable Request and Approval Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-029 CDM Quality Metrics Trend Review, Escalation, and CAPA Intake Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-030 Data Review Meeting Agenda, Minutes, Decisions, and Action Log Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CDM-SOP-001 — CDM Governance, Data Ownership, Vendor Oversight, and Quality Management; CDM-SOP-002 — Protocol/CDM Feasibility, Critical Data Identification, and Start-Up Risk Assessment; CDM-SOP-004 — Data Management Plan Development, Approval, and Maintenance; CDM-SOP-020 — Clinical Data Quality Metrics, Trends, Escalation, and CAPA; CDM-SOP-021 — Data Review Meeting Governance and Cross-Functional Issue Escalation; CDM-SOP-022 — Vendor Data Management Oversight and CRO Performance Review. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CDM-P01-F01 — Data source/critical variable; collection and transfer owner; approved DMP version
CDM-P01-F02 — Quality measure/source/period; review result; issue owner/due date; accepted closure

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: The DMP and critical interfaces are approved before use.	☐ Yes ☐ No ☐ N/A
Step 2: Each critical variable has a source, review method and accountable decision owner.	☐ Yes ☐ No ☐ N/A
Step 3: No data stream or release gate is unassigned or owned only by an unnamed vendor.	☐ Yes ☐ No ☐ N/A
Step 4: A threshold has a defined action and owner, not only a dashboard color.	☐ Yes ☐ No ☐ N/A
Step 5: Status statements link to evidence; unresolved significant risks are escalated.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CDM-P02 — SOP model

Data standards, collection, build and validation

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Release a fit-for-purpose data-collection system supported by approved specifications and testing.
Scope: Collection standards, database specification/build, risk-based validation and production readiness. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Approved protocol, standards versions and intended-use requirements. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Database build lead
Accountable	CDM lead
Consulted	Clinical operations; biostatistics; system owner; independent tester
Informed	Affected study team and authorized downstream recipients

The database build lead prepares specifications and coordinates the build. The CDM lead approves study requirements and data-process readiness. The assigned qualified tester executes documented tests; an independent reviewer reviews evidence where required by the validation plan. The system owner confirms technical readiness. The designated release approver authorizes production use after required CDM and system-owner acceptance. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Required functions are covered by justified testing and release-blocking defects are resolved. Record: Approved requirements, traceability, test results and release decision.
Every critical requirement is represented without unnecessary collection; ambiguous fields are resolved. Record: CRF/metadata specifications and traceability.
Specifications are testable and distinguish warnings from blocking conditions. Record: Build specification and configuration baseline.
Critical failures are resolved and traceability shows what was tested against each requirement. Record: UAT scripts, results, defects and regression evidence.
No untested material change enters production; the release has an approved scope and rollback/contingency plan. Record: Validation summary and go-live authorization.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Database build lead performs the sequential instructions in CDM-P02-WI-01 and retains the specified evidence in CDM-P02-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. No go-live with unresolved participant-safety or critical-data defects.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

When data-management plans or ownership change, use CDM-P01 — Data governance, planning and vendor oversight. Retain the decision or accepted handoff reference in this packet.
When granting, reviewing or removing access, or reviewing audit trails, use CDM-P03 — Access, audit trails and system controls. Retain the decision or accepted handoff reference in this packet.
Before a database change or migration, use CDM-P08 — Database change, migration and regression control. Retain the decision or accepted handoff reference in this packet.
For SDTM mapping, checks and release, use CPROG-P03 — SDTM specification through validated release. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify CDM lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the specification, test and go-live dossier, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CDM-P02-WI-01. Controlled record packet: CDM-P02-FRM-01 — Specification, test and go-live dossier.

CDM-P01 — Data governance, planning and vendor oversight
CDM-P03 — Access, audit trails and system controls
CDM-P08 — Database change, migration and regression control
CPROG-P03 — SDTM specification through validated release

Original-to-new crosswalk

CDM-SOP-003 — CDM Standards, Metadata, CRF Library, and CDASH/SDTM Traceability
CDM-SOP-005 — CRF/eCRF Design, Review, and Completion Guidelines
CDM-SOP-006 — Database Build Requirements, Configuration, and Build Review
CDM-SOP-007 — Edit Check, Derivation, and Data Validation Specification
CDM-SOP-008 — EDC/CDMS Validation, UAT, Production Release, and Go-Live Readiness

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CDM-P02 — WI execution model

Data standards, collection, build and validation

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate approved protocol, standards versions and intended-use requirements. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The database build lead prepares specifications and coordinates the build. The CDM lead approves study requirements and data-process readiness. The assigned qualified tester executes documented tests; an independent reviewer reviews evidence where required by the validation plan. The system owner confirms technical readiness. The designated release approver authorizes production use after required CDM and system-owner acceptance. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify CDM lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Approved requirements, traceability, test results and release decision

The build lead lists protocol-driven data requirements and assigns stable IDs, intended behavior, risk and acceptance criteria. The CDM lead confirms study-specific requirements and the system owner identifies platform controls supported by existing validation evidence. Evaluate that evidence for the actual version, configuration and intended use; identify gaps requiring study-specific testing. Record the boundary between platform qualification, study configuration, interfaces and user acceptance testing. IT approval alone does not authorize the study data workflow.

Expected result: Required functions are covered by justified testing and release-blocking defects are resolved.

Evidence to retain: Approved requirements, traceability, test results and release decision.

Step 2 — CRF/metadata specifications and traceability

Map protocol requirements to CRF fields and downstream data standards. Specify field type, units, allowed values, missing-data behavior and completion guidance.

Expected result: Every critical requirement is represented without unnecessary collection; ambiguous fields are resolved.

Evidence to retain: CRF/metadata specifications and traceability.

Step 3 — Build specification and configuration baseline

Specify edit checks and derivations with input conditions and expected outputs. Build in the controlled test environment and identify the exact configuration version.

Expected result: Specifications are testable and distinguish warnings from blocking conditions.

Evidence to retain: Build specification and configuration baseline.

Step 4 — UAT scripts, results, defects and regression evidence

The tester executes approved normal, invalid, boundary and role/access cases in the identified test configuration. Record each test ID, requirement ID, input, expected result, actual result, evidence, executor and date. Cover applicable edit checks, derivations, transfers, audit trails and workflow permissions. Preserve failures, assign defects, assess clinical-data impact and retest corrections with affected regression cases. The reviewer reconciles untested requirements and deviations before recommending release.

Expected result: Critical failures are resolved and traceability shows what was tested against each requirement.

Evidence to retain: UAT scripts, results, defects and regression evidence.

Step 5 — Validation summary and go-live authorization

The CDM lead checks the validation summary against requirements and test evidence, including unresolved deviations and residual risk. The system owner verifies technical readiness and configuration equivalence between the tested and production versions. The release approver confirms training, authorized access, backup/contingency arrangements and required clinical-data acceptance, then records the exact version and release time. Perform and retain the planned production verification; use the approved contingency route if it fails.

Expected result: No untested material change enters production; the release has an approved scope and rollback/contingency plan.

Evidence to retain: Validation summary and go-live authorization.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: No go-live with unresolved participant-safety or critical-data defects.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CDM-P02 — consolidated record packet

Data standards, collection, build and validation

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Specification, test and go-live dossier

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
CDM-FRM-003 CRF/eCRF Design Review and Completion Guideline Approval Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-004 Database Build Requirements and Design Sign-Off Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-005 Edit Check and Derivation Specification Approval Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-006 EDC/CDMS Validation, UAT Test Evidence, and Deviation Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-007 Go-Live Readiness and Production Release Authorization Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-027 CDM Standards, Metadata, CRF Library, and CDASH/SDTM Traceability Approval Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CDM-SOP-003 — CDM Standards, Metadata, CRF Library, and CDASH/SDTM Traceability; CDM-SOP-005 — CRF/eCRF Design, Review, and Completion Guidelines; CDM-SOP-006 — Database Build Requirements, Configuration, and Build Review; CDM-SOP-007 — Edit Check, Derivation, and Data Validation Specification; CDM-SOP-008 — EDC/CDMS Validation, UAT, Production Release, and Go-Live Readiness. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CDM-P02-F01 — Requirement ID/risk; specification/configuration version; test ID; expected/actual result
CDM-P02-F02 — Tester/date/evidence; defect and retest; coverage disposition; CDM/system-owner acceptance; production authorization

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Required functions are covered by justified testing and release-blocking defects are resolved.	☐ Yes ☐ No ☐ N/A
Step 2: Every critical requirement is represented without unnecessary collection; ambiguous fields are resolved.	☐ Yes ☐ No ☐ N/A
Step 3: Specifications are testable and distinguish warnings from blocking conditions.	☐ Yes ☐ No ☐ N/A
Step 4: Critical failures are resolved and traceability shows what was tested against each requirement.	☐ Yes ☐ No ☐ N/A
Step 5: No untested material change enters production; the release has an approved scope and rollback/contingency plan.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CDM-P03 — SOP model

Access, audit trails and system controls

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Restrict system access to authorized duties and detect inappropriate system or data changes.
Scope: Access approval, provisioning, changes, removal, periodic review and relevant audit-trail review. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Role matrix, training evidence and system configuration. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	System administrator
Accountable	System owner
Consulted	CDM lead; information security; quality assurance
Informed	Affected study team and authorized downstream recipients

The system administrator implements approved access and technical changes. The system owner authorizes access roles, reviews periodic recertification and directs security response. Qualified CDM/data reviewers assess clinical-data audit trails within the approved review plan; technical administrators supply audit records but do not resolve medical meaning. QA reviews significant integrity concerns through the quality process. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Least privilege and blind restrictions are met; shared accounts are not used. Record: Access request and approval.
Actual permissions match authorization and departed users cannot continue access. Record: Access history and periodic review.
Every active account is dispositioned; removal actions have verified completion. Record: Periodic access review and implemented-change evidence.
Unexplained changes and missing rationale receive investigation rather than blanket acceptance. Record: Audit-trail review scope and findings.
Anomaly disposition is attributable and does not erase the original audit trail. Record: Investigation and closure evidence.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: System administrator performs the sequential instructions in CDM-P03-WI-01 and retains the specified evidence in CDM-P03-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Administration is separate from approval where feasible; record compensating review.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

Before building or releasing a data-collection system, use CDM-P02 — Data standards, collection, build and validation. Retain the decision or accepted handoff reference in this packet.
Before a database change or migration, use CDM-P08 — Database change, migration and regression control. Retain the decision or accepted handoff reference in this packet.
For data-management record retrieval, archive or authorized disclosure, use CDM-P10 — Records, inspection, archive and authorized sharing. Retain the decision or accepted handoff reference in this packet.
When treatment information or blinding may be affected, use CPROG-P09 — Randomization, treatment handling and blind breaks. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify System owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the access authorization and audit-trail review record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CDM-P03-WI-01. Controlled record packet: CDM-P03-FRM-01 — Access authorization and audit-trail review record.

CDM-P02 — Data standards, collection, build and validation
CDM-P08 — Database change, migration and regression control
CDM-P10 — Records, inspection, archive and authorized sharing
CPROG-P09 — Randomization, treatment handling and blind breaks

Original-to-new crosswalk

CDM-SOP-009 — User Access, Training, Security, Audit Trail, and System Administration Controls

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CDM-P03 — WI execution model

Access, audit trails and system controls

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate role matrix, training evidence and system configuration. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The system administrator implements approved access and technical changes. The system owner authorizes access roles, reviews periodic recertification and directs security response. Qualified CDM/data reviewers assess clinical-data audit trails within the approved review plan; technical administrators supply audit records but do not resolve medical meaning. QA reviews significant integrity concerns through the quality process. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify System owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Access request and approval

Compare the access request with the approved permission matrix, person's role and training. Obtain the authorized owner's approval before granting access.

Expected result: Least privilege and blind restrictions are met; shared accounts are not used.

Evidence to retain: Access request and approval.

Step 2 — Access history and periodic review

Record granted permissions and activation time. On role change or exit, remove unnecessary access and document when it was removed.

Expected result: Actual permissions match authorization and departed users cannot continue access.

Evidence to retain: Access history and periodic review.

Step 3 — Periodic access review and implemented-change evidence

At the approved review interval and after relevant role changes, the system owner compares current accounts and privileges with authorized duties, training status and the access matrix. Record retain/change/remove decisions; the administrator implements approved changes and returns completion evidence. The owner verifies overdue removals and inappropriate privileges are resolved and assesses exposure when needed.

Expected result: Every active account is dispositioned; removal actions have verified completion.

Evidence to retain: Periodic access review and implemented-change evidence.

Step 4 — Audit-trail review scope and findings

Apply the audit-trail review plan to critical data and suspicious patterns. Examine who changed what, when and why, and compare with source-authorized corrections.

Expected result: Unexplained changes and missing rationale receive investigation rather than blanket acceptance.

Evidence to retain: Audit-trail review scope and findings.

Step 5 — Investigation and closure evidence

Route anomalies to the system/data owner, preserve evidence and assess affected records. Verify corrective access or data changes and obtain closure review.

Expected result: Anomaly disposition is attributable and does not erase the original audit trail.

Evidence to retain: Investigation and closure evidence.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Administration is separate from approval where feasible; record compensating review.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CDM-P03 — consolidated record packet

Access, audit trails and system controls

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Access authorization and audit-trail review record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A	Evidence / exception / reviewer
CDM-FRM-008 User Access Request, Training, and Periodic Review Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CDM-SOP-009 — User Access, Training, Security, Audit Trail, and System Administration Controls. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CDM-P03-F01 — User/role; requested/granted privileges; owner approval; training; activation/removal time
CDM-P03-F02 — Review period/scope; audit-trail finding; retain/change/remove decision; implementation verification

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Least privilege and blind restrictions are met; shared accounts are not used.	☐ Yes ☐ No ☐ N/A
Step 2: Actual permissions match authorization and departed users cannot continue access.	☐ Yes ☐ No ☐ N/A
Step 3: Every active account is dispositioned; removal actions have verified completion.	☐ Yes ☐ No ☐ N/A
Step 4: Unexplained changes and missing rationale receive investigation rather than blanket acceptance.	☐ Yes ☐ No ☐ N/A
Step 5: Anomaly disposition is attributable and does not erase the original audit trail.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CDM-P04 — SOP model

External data transfer and reconciliation

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Accept complete, traceable external data and resolve transfer and reconciliation discrepancies.
Scope: Transfer specification, test transfer, receipt checks, reconciliation and replacement data. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Transfer specification, schema, expected counts and cut dates. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	External data manager
Accountable	CDM lead
Consulted	Vendor data owner; programming; clinical operations
Informed	Affected study team and authorized downstream recipients

External data manager performs and documents the work. CDM lead owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

The transfer specification supports interpretation and reconciliation for the particular data type. Record: Approved transfer rules and test examples.
Both parties approve the same specification and successful test results. Record: Transfer specification and test approval.
Unexpected, incomplete or duplicate files are quarantined until resolved. Record: Intake record and validation results.
Reconciliation accounts for all expected scope and documents approved exceptions. Record: Reconciliation record and issue disposition.
Accepted version and replacement impact are explicit; no silent overwrites occur. Record: Acceptance, supersession and downstream notification.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: External data manager performs the sequential instructions in CDM-P04-WI-01 and retains the specified evidence in CDM-P04-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Never silently overwrite a previously used transfer.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

When qualifying vendors or resolving vendor performance issues, use COPS-P03 — Vendor qualification and lifecycle oversight. Retain the decision or accepted handoff reference in this packet.
When clinical-data review or query resolution is needed, use CDM-P05 — Clinical data review, queries and critical variables. Retain the decision or accepted handoff reference in this packet.
For an analysis cut, freeze/lock or data handoff, use CDM-P09 — Data cuts, lock and programming handoff. Retain the decision or accepted handoff reference in this packet.
Before programming production and release, use CPROG-P06 — Data intake, independent QC and production release. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

6. Records and effectiveness

Retain the external data agreement, intake and reconciliation record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CDM-P04-WI-01. Controlled record packet: CDM-P04-FRM-01 — External data agreement, intake and reconciliation record.

COPS-P03 — Vendor qualification and lifecycle oversight
CDM-P05 — Clinical data review, queries and critical variables
CDM-P09 — Data cuts, lock and programming handoff
CPROG-P06 — Data intake, independent QC and production release

Original-to-new crosswalk

CDM-SOP-010 — External Data Vendor Setup, Data Transfer Specifications, and Transfer Testing
CDM-SOP-011 — External Data Receipt, Loading, Reconciliation, and Issue Management
CDM-SOP-016 — Concomitant Medication, Laboratory, ECG, Imaging, PK/PD, and Specialty Data Reconciliation

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CDM-P04 — WI execution model

External data transfer and reconciliation

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate transfer specification, schema, expected counts and cut dates. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: External data manager performs and documents the work. CDM lead owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify CDM lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Approved transfer rules and test examples

Before transfer testing, the external data manager specifies expected files/records and relevant identifiers, formats, units, reference ranges, specimen and collection timing attributes for the data type. Confirm these rules with the source owner and receiving function. Include missing, duplicate, replacement and out-of-range examples in applicable checks; route scientific ambiguities to the qualified data owner.

Expected result: The transfer specification supports interpretation and reconciliation for the particular data type.

Evidence to retain: Approved transfer rules and test examples.

Step 2 — Transfer specification and test approval

Agree the transfer specification with the provider: fields, formats, units, identifiers, cadence, cut rules, corrections, encryption and acknowledgment. Test representative files before live transfer.

Expected result: Both parties approve the same specification and successful test results.

Evidence to retain: Transfer specification and test approval.

Step 3 — Intake record and validation results

On receipt, log sender, transfer time, file identity and expected scope. Verify integrity, schema, counts and key uniqueness before loading.

Expected result: Unexpected, incomplete or duplicate files are quarantined until resolved.

Evidence to retain: Intake record and validation results.

Step 4 — Reconciliation record and issue disposition

Reconcile received records against expected visits/samples and relevant clinical data. Distinguish missing, duplicate, unmatched and clinically inconsistent records; assign each discrepancy.

Expected result: Reconciliation accounts for all expected scope and documents approved exceptions.

Evidence to retain: Reconciliation record and issue disposition.

Step 5 — Acceptance, supersession and downstream notification

Accept the corrected/verified version and acknowledge it to the provider and downstream users. Preserve prior versions and assess whether analyses or prior reviews must be repeated.

Expected result: Accepted version and replacement impact are explicit; no silent overwrites occur.

Evidence to retain: Acceptance, supersession and downstream notification.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Never silently overwrite a previously used transfer.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CDM-P04 — consolidated record packet

External data transfer and reconciliation

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

External data agreement, intake and reconciliation record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
CDM-FRM-009 External Data Transfer Specification Approval Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-010 External Data Transfer Testing and Receipt Acceptance Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-015 Specialty Data Reconciliation Issue Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CDM-SOP-010 — External Data Vendor Setup, Data Transfer Specifications, and Transfer Testing; CDM-SOP-011 — External Data Receipt, Loading, Reconciliation, and Issue Management; CDM-SOP-016 — Concomitant Medication, Laboratory, ECG, Imaging, PK/PD, and Specialty Data Reconciliation. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CDM-P04-F01 — Transfer ID/version; specification; file/key/count/integrity checks; acceptance
CDM-P04-F02 — Expected/received records; missing/duplicate/unmatched discrepancies; correction and downstream impact

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: The transfer specification supports interpretation and reconciliation for the particular data type.	☐ Yes ☐ No ☐ N/A
Step 2: Both parties approve the same specification and successful test results.	☐ Yes ☐ No ☐ N/A
Step 3: Unexpected, incomplete or duplicate files are quarantined until resolved.	☐ Yes ☐ No ☐ N/A
Step 4: Reconciliation accounts for all expected scope and documents approved exceptions.	☐ Yes ☐ No ☐ N/A
Step 5: Accepted version and replacement impact are explicit; no silent overwrites occur.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CDM-P05 — SOP model

Clinical data review, queries and critical variables

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Identify and resolve clinical-data discrepancies without obscuring source history or medical authority.
Scope: Review-plan preparation, checks, queries, response evaluation and critical-variable review. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Review plan, current listings and source-specific reconciliation rules. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Data reviewer
Accountable	CDM lead
Consulted	Investigator; medical monitor; clinical operations; biostatistics
Informed	Affected study team and authorized downstream recipients

Data reviewer performs and documents the work. CDM lead owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Checks, qualified reviewers and closure criteria are approved and traceable to study needs. Record: Approved data-review plan and review responsibilities.
The reviewer can reproduce the review population and check versions. Record: Data-review execution record.
The query does not suggest an unsupported clinical answer or request unnecessary personal data. Record: Query record and routing.
Closure is supported by an adequate answer and retained audit trail. Record: Query disposition and reviewer evidence.
Critical cross-functional disagreements are resolved or explicitly block release. Record: Critical-variable reconciliation and decisions.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Data reviewer performs the sequential instructions in CDM-P05-WI-01 and retains the specified evidence in CDM-P05-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Do not infer or fabricate missing clinical data.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

When findings require monitoring or site follow-up, use COPS-P04 — Risk-based monitoring and site issue resolution. Retain the decision or accepted handoff reference in this packet.
When consent, eligibility or enrollment oversight is affected, use COPS-P05 — Oversight of participant consent, eligibility and enrollment. Retain the decision or accepted handoff reference in this packet.
When coding or dictionary changes affect the data, use CDM-P06 — Medical coding lifecycle. Retain the decision or accepted handoff reference in this packet.
For differences between clinical and safety records, use CDM-P07 — Safety database reconciliation. Retain the decision or accepted handoff reference in this packet.
For an analysis cut, freeze/lock or data handoff, use CDM-P09 — Data cuts, lock and programming handoff. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

6. Records and effectiveness

Retain the data review, query and decision record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CDM-P05-WI-01. Controlled record packet: CDM-P05-FRM-01 — Data review, query and decision record.

COPS-P04 — Risk-based monitoring and site issue resolution
COPS-P05 — Oversight of participant consent, eligibility and enrollment
CDM-P06 — Medical coding lifecycle
CDM-P07 — Safety database reconciliation
CDM-P09 — Data cuts, lock and programming handoff

Original-to-new crosswalk

CDM-SOP-012 — Data Review Plan, Listings Review, and Risk-Based Data Surveillance
CDM-SOP-013 — Query Management, Data Cleaning, and Site Data Issue Resolution
CDM-SOP-017 — Protocol Deviation, Eligibility, Endpoint, and Critical Variable Reconciliation

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CDM-P05 — WI execution model

Clinical data review, queries and critical variables

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate review plan, current listings and source-specific reconciliation rules. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: Data reviewer performs and documents the work. CDM lead owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify CDM lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Approved data-review plan and review responsibilities

The CDM lead prepares a risk-based review plan defining critical variables, checks, review frequency, query ownership and medical/statistical review triggers. Obtain scoped review and designated data-owner approval before running routine checks. Confirm source clarification remains with the investigator/source owner and define what evidence permits query closure.

Expected result: Checks, qualified reviewers and closure criteria are approved and traceable to study needs.

Evidence to retain: Approved data-review plan and review responsibilities.

Step 2 — Data-review execution record

Run the approved listings and checks against a recorded data version. Review critical variables first and record scope, rules and exclusions.

Expected result: The reviewer can reproduce the review population and check versions.

Evidence to retain: Data-review execution record.

Step 3 — Query record and routing

For each discrepancy, write a precise, non-leading query identifying the inconsistency and requesting clarification. Route it through the authorized site workflow.

Expected result: The query does not suggest an unsupported clinical answer or request unnecessary personal data.

Evidence to retain: Query record and routing.

Step 4 — Query disposition and reviewer evidence

Read the site response and verify the resulting correction or explanation. Keep the query open when it does not resolve the issue; escalate persistent ambiguity to the appropriate clinical owner.

Expected result: Closure is supported by an adequate answer and retained audit trail.

Evidence to retain: Query disposition and reviewer evidence.

Step 5 — Critical-variable reconciliation and decisions

Reconcile eligibility, deviations and endpoint issues with clinical operations and biostatistics. Capture the agreed decision, affected data and follow-up before the release gate.

Expected result: Critical cross-functional disagreements are resolved or explicitly block release.

Evidence to retain: Critical-variable reconciliation and decisions.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Do not infer or fabricate missing clinical data.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CDM-P05 — consolidated record packet

Clinical data review, queries and critical variables

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Data review, query and decision record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
CDM-FRM-011 Data Review Plan and Listing Review Approval Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-012 Query Management Escalation and Resolution Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-028 Critical Data, Eligibility, Protocol Deviation, and Endpoint Reconciliation Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CDM-SOP-012 — Data Review Plan, Listings Review, and Risk-Based Data Surveillance; CDM-SOP-013 — Query Management, Data Cleaning, and Site Data Issue Resolution; CDM-SOP-017 — Protocol Deviation, Eligibility, Endpoint, and Critical Variable Reconciliation. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CDM-P05-F01 — Data version; check/rule; review scope; discrepancy; query ID and source owner
CDM-P05-F02 — Response/correction evidence; medical/statistical decision if needed; recheck and closure

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Checks, qualified reviewers and closure criteria are approved and traceable to study needs.	☐ Yes ☐ No ☐ N/A
Step 2: The reviewer can reproduce the review population and check versions.	☐ Yes ☐ No ☐ N/A
Step 3: The query does not suggest an unsupported clinical answer or request unnecessary personal data.	☐ Yes ☐ No ☐ N/A
Step 4: Closure is supported by an adequate answer and retained audit trail.	☐ Yes ☐ No ☐ N/A
Step 5: Critical cross-functional disagreements are resolved or explicitly block release.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CDM-P06 — SOP model

Medical coding lifecycle

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Produce consistent, traceable medical coding and control dictionary changes.
Scope: Coding, ambiguity resolution, qualified review and dictionary upgrades or recoding. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Verbatim terms, approved dictionary/version and coding conventions. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Medical coding specialist
Accountable	Designated qualified coding reviewer
Consulted	CDM lead; safety; biostatistics
Informed	Affected study team and authorized downstream recipients

The coder applies the approved dictionary and coding conventions and raises ambiguous terms. The qualified coding reviewer accepts coding decisions within their competence; clinical interpretation is referred to the designated medical reviewer. CDM coordinates source clarification and dictionary-change impact. Medical approval is not required for every routine term. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Dictionary/version matches the plan and source terms remain traceable. Record: Coding run and dictionary baseline.
Ambiguity has a documented query or qualified medical disposition. Record: Coding query and decision log.
Reviewer conclusion is tied to the exact coded-data version. Record: Coding review and approval.
No uncontrolled recoding affects delivered data; downstream impact is addressed. Record: Upgrade impact assessment and release record.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Medical coding specialist performs the sequential instructions in CDM-P06-WI-01 and retains the specified evidence in CDM-P06-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Coding changes require traceable rationale and appropriate review.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

When clinical-data review or query resolution is needed, use CDM-P05 — Clinical data review, queries and critical variables. Retain the decision or accepted handoff reference in this packet.
For differences between clinical and safety records, use CDM-P07 — Safety database reconciliation. Retain the decision or accepted handoff reference in this packet.
For an analysis cut, freeze/lock or data handoff, use CDM-P09 — Data cuts, lock and programming handoff. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Designated coding/medical reviewer or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the coding decision and dictionary control record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CDM-P06-WI-01. Controlled record packet: CDM-P06-FRM-01 — Coding decision and dictionary control record.

CDM-P05 — Clinical data review, queries and critical variables
CDM-P07 — Safety database reconciliation
CDM-P09 — Data cuts, lock and programming handoff

Original-to-new crosswalk

CDM-SOP-014 — Medical Coding, MedDRA and WHODrug Coding Review, and Dictionary Version Control

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CDM-P06 — WI execution model

Medical coding lifecycle

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate verbatim terms, approved dictionary/version and coding conventions. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The coder applies the approved dictionary and coding conventions and raises ambiguous terms. The qualified coding reviewer accepts coding decisions within their competence; clinical interpretation is referred to the designated medical reviewer. CDM coordinates source clarification and dictionary-change impact. Medical approval is not required for every routine term. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Designated coding/medical reviewer or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Coding run and dictionary baseline

Load the approved dictionary and coding conventions. Record dictionary version and apply coding to the current verbatim terms without altering the verbatim source.

Expected result: Dictionary/version matches the plan and source terms remain traceable.

Evidence to retain: Coding run and dictionary baseline.

Step 2 — Coding query and decision log

Review uncoded, ambiguous and inconsistent terms. Request clarification from the authorized source owner rather than inventing a diagnosis or drug detail.

Expected result: Ambiguity has a documented query or qualified medical disposition.

Evidence to retain: Coding query and decision log.

Step 3 — Coding review and approval

Have the designated qualified reviewer examine the required coding scope and changed terms. Record review results and resolve disagreements before finalization.

Expected result: Reviewer conclusion is tied to the exact coded-data version.

Evidence to retain: Coding review and approval.

Step 4 — Upgrade impact assessment and release record

For a dictionary upgrade, compare old and new assignments, assess analysis/safety impact and approve recoding scope. Recheck changed terms and communicate the version change.

Expected result: No uncontrolled recoding affects delivered data; downstream impact is addressed.

Evidence to retain: Upgrade impact assessment and release record.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Coding changes require traceable rationale and appropriate review.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CDM-P06 — consolidated record packet

Medical coding lifecycle

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Coding decision and dictionary control record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A	Evidence / exception / reviewer
CDM-FRM-013 Medical Coding Review and Dictionary Version Approval Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CDM-SOP-014 — Medical Coding, MedDRA and WHODrug Coding Review, and Dictionary Version Control. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CDM-P06-F01 — Dictionary/version; convention; verbatim reference; coded term/code; reviewer
CDM-P06-F02 — Ambiguity/query; upgrade impact; changed assignment; approval and downstream notification

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Dictionary/version matches the plan and source terms remain traceable.	☐ Yes ☐ No ☐ N/A
Step 2: Ambiguity has a documented query or qualified medical disposition.	☐ Yes ☐ No ☐ N/A
Step 3: Reviewer conclusion is tied to the exact coded-data version.	☐ Yes ☐ No ☐ N/A
Step 4: No uncontrolled recoding affects delivered data; downstream impact is addressed.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CDM-P07 — SOP model

Safety database reconciliation

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Resolve relevant differences between clinical and safety databases without delaying safety reporting.
Scope: Reconciliation rules, case/field comparison, source correction and joint completion assessment. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Approved matching rules and dated clinical/safety extracts. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Safety reconciliation specialist
Accountable	Pharmacovigilance data owner
Consulted	CDM lead; medical monitor; clinical operations
Informed	Affected study team and authorized downstream recipients

The reconciliation specialist compares agreed clinical and safety fields and records mismatches. CDM and safety data owners direct corrections within their respective systems and jointly confirm reconciliation completion or justified residual differences. Investigators and medical reviewers provide clinical clarification where required. Safety reporting proceeds independently of reconciliation closure. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Both extracts cover the intended scope and preserve source versions. Record: Reconciliation plan and extract manifest.
Each discrepancy can be traced to both system records without broad disclosure. Record: Discrepancy listing.
Resolution is verified in the authoritative systems; reporting continues independently. Record: Correction verification and case disposition.
Critical unresolved mismatches block the affected release; approved interim limitations are explicit. Record: Reconciliation signoff and release-status handoff.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Safety reconciliation specialist performs the sequential instructions in CDM-P07-WI-01 and retains the specified evidence in CDM-P07-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Reconciliation does not replace or delay expedited safety reporting.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

When safety information must be communicated or followed up, use COPS-P07 — Safety communication and follow-up. Retain the decision or accepted handoff reference in this packet.
For significant noncompliance or urgent safety measures, use COPS-P11 — Significant noncompliance and urgent safety measures. Retain the decision or accepted handoff reference in this packet.
When clinical-data review or query resolution is needed, use CDM-P05 — Clinical data review, queries and critical variables. Retain the decision or accepted handoff reference in this packet.
For an analysis cut, freeze/lock or data handoff, use CDM-P09 — Data cuts, lock and programming handoff. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Pharmacovigilance data owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the safety reconciliation record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CDM-P07-WI-01. Controlled record packet: CDM-P07-FRM-01 — Safety reconciliation record.

COPS-P07 — Safety communication and follow-up
COPS-P11 — Significant noncompliance and urgent safety measures
CDM-P05 — Clinical data review, queries and critical variables
CDM-P09 — Data cuts, lock and programming handoff

Original-to-new crosswalk

CDM-SOP-015 — AE/SAE and Safety Database Reconciliation

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CDM-P07 — WI execution model

Safety database reconciliation

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate approved matching rules and dated clinical/safety extracts. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The reconciliation specialist compares agreed clinical and safety fields and records mismatches. CDM and safety data owners direct corrections within their respective systems and jointly confirm reconciliation completion or justified residual differences. Investigators and medical reviewers provide clinical clarification where required. Safety reporting proceeds independently of reconciliation closure. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Pharmacovigilance data owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Reconciliation plan and extract manifest

Agree matching keys, critical fields, data-cut dates and review frequency with safety. Obtain dated clinical and safety extracts through restricted channels.

Expected result: Both extracts cover the intended scope and preserve source versions.

Evidence to retain: Reconciliation plan and extract manifest.

Step 2 — Discrepancy listing

Compare cases/events and the agreed critical fields. Classify missing, unmatched and conflicting records and identify the source-system owner.

Expected result: Each discrepancy can be traced to both system records without broad disclosure.

Evidence to retain: Discrepancy listing.

Step 3 — Correction verification and case disposition

Request correction or explanation from the accountable source owner. Recheck both systems after resolution and preserve the original discrepancy history.

Expected result: Resolution is verified in the authoritative systems; reporting continues independently.

Evidence to retain: Correction verification and case disposition.

Step 4 — Reconciliation signoff and release-status handoff

Summarize completed scope and remaining discrepancies for CDM and safety review before the relevant data release.

Expected result: Critical unresolved mismatches block the affected release; approved interim limitations are explicit.

Evidence to retain: Reconciliation signoff and release-status handoff.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Reconciliation does not replace or delay expedited safety reporting.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CDM-P07 — consolidated record packet

Safety database reconciliation

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Safety reconciliation record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A	Evidence / exception / reviewer
CDM-FRM-014 AE/SAE Reconciliation Review and Sign-Off Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CDM-SOP-015 — AE/SAE and Safety Database Reconciliation. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CDM-P07-F01 — Clinical/safety extract versions; matching keys; cut dates; reconciliation scope
CDM-P07-F02 — Case discrepancy; source-system owner; correction evidence; recheck; CDM/safety acceptance

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Both extracts cover the intended scope and preserve source versions.	☐ Yes ☐ No ☐ N/A
Step 2: Each discrepancy can be traced to both system records without broad disclosure.	☐ Yes ☐ No ☐ N/A
Step 3: Resolution is verified in the authoritative systems; reporting continues independently.	☐ Yes ☐ No ☐ N/A
Step 4: Critical unresolved mismatches block the affected release; approved interim limitations are explicit.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CDM-P08 — SOP model

Database change, migration and regression control

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Implement authorized database changes without compromising data integrity or intended performance.
Scope: Change impact, migration where applicable, testing, rollback readiness and production implementation. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Approved request, impact assessment and validated baseline. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Database change lead
Accountable	CDM lead
Consulted	System owner; independent tester; affected functions
Informed	Affected study team and authorized downstream recipients

The database change lead prepares the impact assessment and implementation evidence. The assigned tester executes risk-based tests and the reviewer confirms results. CDM accepts data-process impact; the system owner accepts technical readiness and recovery arrangements. The designated release approver authorizes the identified change after both applicable acceptances. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Impact assessment includes previously collected data and downstream extracts. Record: Approved change request.
The baseline can be restored and the migration scope is reproducible. Record: Migration plan and backup/restore evidence.
No unexplained loss, altered meaning or broken auditability remains. Record: Migration reconciliation and regression results.
Production matches the approved tested version and the change history remains intact. Record: Release notes, implementation verification and training.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Database change lead performs the sequential instructions in CDM-P08-WI-01 and retains the specified evidence in CDM-P08-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Unexplained data loss or changed meaning blocks release.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

Before building or releasing a data-collection system, use CDM-P02 — Data standards, collection, build and validation. Retain the decision or accepted handoff reference in this packet.
When granting, reviewing or removing access, or reviewing audit trails, use CDM-P03 — Access, audit trails and system controls. Retain the decision or accepted handoff reference in this packet.
For an analysis cut, freeze/lock or data handoff, use CDM-P09 — Data cuts, lock and programming handoff. Retain the decision or accepted handoff reference in this packet.
Before programming production and release, use CPROG-P06 — Data intake, independent QC and production release. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

6. Records and effectiveness

Retain the database change and migration record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CDM-P08-WI-01. Controlled record packet: CDM-P08-FRM-01 — Database change and migration record.

CDM-P02 — Data standards, collection, build and validation
CDM-P03 — Access, audit trails and system controls
CDM-P09 — Data cuts, lock and programming handoff
CPROG-P06 — Data intake, independent QC and production release

Original-to-new crosswalk

CDM-SOP-018 — Data Change Control, Database Amendments, Migration, and Post-Go-Live Updates

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CDM-P08 — WI execution model

Database change, migration and regression control

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate approved request, impact assessment and validated baseline. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The database change lead prepares the impact assessment and implementation evidence. The assigned tester executes risk-based tests and the reviewer confirms results. CDM accepts data-process impact; the system owner accepts technical readiness and recovery arrangements. The designated release approver authorizes the identified change after both applicable acceptances. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify CDM lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Approved change request

Document the requested database change and reason. Compare it with the validated baseline and identify affected data, checks, integrations, access and study instructions.

Expected result: Impact assessment includes previously collected data and downstream extracts.

Evidence to retain: Approved change request.

Step 2 — Migration plan and backup/restore evidence

Preserve a recoverable baseline and define rollback criteria. Test the migration or configuration change using representative data in a controlled environment.

Expected result: The baseline can be restored and the migration scope is reproducible.

Evidence to retain: Migration plan and backup/restore evidence.

Step 3 — Migration reconciliation and regression results

Compare pre- and post-change counts, values, derivations, metadata and access. Run affected regression tests and investigate every unexpected difference.

Expected result: No unexplained loss, altered meaning or broken auditability remains.

Evidence to retain: Migration reconciliation and regression results.

Step 4 — Release notes, implementation verification and training

Obtain release authorization, schedule implementation and notify affected users. Verify the production version and update instructions/training as needed.

Expected result: Production matches the approved tested version and the change history remains intact.

Evidence to retain: Release notes, implementation verification and training.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Unexplained data loss or changed meaning blocks release.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CDM-P08 — consolidated record packet

Database change, migration and regression control

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Database change and migration record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A	Evidence / exception / reviewer
CDM-FRM-016 Data Change Control and Post-Go-Live Update Request Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CDM-SOP-018 — Data Change Control, Database Amendments, Migration, and Post-Go-Live Updates. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CDM-P08-F01 — Change reason; affected validated baseline; data/interface/access impact; rollback criteria
CDM-P08-F02 — Pre/post comparison; test/regression results; deviations; release approval; production verification

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Impact assessment includes previously collected data and downstream extracts.	☐ Yes ☐ No ☐ N/A
Step 2: The baseline can be restored and the migration scope is reproducible.	☐ Yes ☐ No ☐ N/A
Step 3: No unexplained loss, altered meaning or broken auditability remains.	☐ Yes ☐ No ☐ N/A
Step 4: Production matches the approved tested version and the change history remains intact.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CDM-P09 — SOP model

Data cuts, lock and programming handoff

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Deliver an authorized, identifiable data cut and control subsequent changes.
Scope: Cut readiness, freeze/lock decisions, extract transfer, unlock and relock. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Cut definition, completion criteria and functional review evidence. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	CDM release coordinator
Accountable	Sponsor data owner
Consulted	Biostatistics; programming; safety; clinical operations
Informed	Affected study team and authorized downstream recipients

CDM release coordinator performs and documents the work. Sponsor data owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

Database state and unlock controls

The CDM lead defines each database state in the DMP and maps it to actual system permissions. A freeze identifies a controlled cut and restricted work; a soft lock may permit specifically authorized changes; a hard lock prevents routine data changes. Record the exact scope, timestamp, permissions and permitted activity. Do not call a state hard-locked while routine changes remain possible.

The Head of Clinical Data Management, acting as the designated sponsor data owner, authorizes hard lock after documented input from clinical operations, medical/safety, biostatistics and other affected data owners. The authorized administrator applies the state; a separate qualified person verifies the resulting permissions and scope.

An unlock requires a material reason, defined records and changes, authorized performers, time-limited access, impact on analyses and recipients, and approval from the functions that approved lock. Independently verify each change, repeat affected reconciliations, restore the lock and issue a new versioned handoff. Keep the prior snapshot and full change history.

Adoption instruction: enter the system-specific meanings of freeze, soft lock and hard lock, the named administrator, the independent state verifier and the maximum authorized unlock window. Use these role defaults if no local lock procedure exists.

4. Process-specific requirements

The state and permitted changes are explicit; released extracts remain preserved. Record: State authorization, unlock/relock decisions and version links.
Every required source and review has a documented status and owner. Record: Readiness checklist and cut definition.
Signoffs are not blanket approvals and do not hide known critical issues. Record: Functional approvals and exception disposition.
Snapshot is the approved version and unauthorized changes are prevented. Record: Lock evidence and transfer manifest.
The original snapshot is retained and all affected recipients know the replacement status. Record: Receipt, unlock/relock history and supersession record.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: CDM release coordinator performs the sequential instructions in CDM-P09-WI-01 and retains the specified evidence in CDM-P09-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Critical unresolved discrepancies block final lock; interim limitations must be explicit.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

When clinical-data review or query resolution is needed, use CDM-P05 — Clinical data review, queries and critical variables. Retain the decision or accepted handoff reference in this packet.
For differences between clinical and safety records, use CDM-P07 — Safety database reconciliation. Retain the decision or accepted handoff reference in this packet.
Before a database change or migration, use CDM-P08 — Database change, migration and regression control. Retain the decision or accepted handoff reference in this packet.
Before programming production and release, use CPROG-P06 — Data intake, independent QC and production release. Retain the decision or accepted handoff reference in this packet.
For restricted interim/DMC programming outputs, use CPROG-P08 — Interim/DMC outputs and firewall management. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

6. Records and effectiveness

Retain the cut, lock and transfer authorization packet, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CDM-P09-WI-01. Controlled record packet: CDM-P09-FRM-01 — Cut, lock and transfer authorization packet.

CDM-P05 — Clinical data review, queries and critical variables
CDM-P07 — Safety database reconciliation
CDM-P08 — Database change, migration and regression control
CPROG-P06 — Data intake, independent QC and production release
CPROG-P08 — Interim/DMC outputs and firewall management

Original-to-new crosswalk

CDM-SOP-019 — Interim Analyses, Data Cuts, Snapshots, Blinding, and Data Release
CDM-SOP-024 — Database Freeze, Soft Lock, Hard Lock, Unlock, and Relock
CDM-SOP-025 — Final Data Transfer to Biostatistics/Programming, SDTM/ADaM Handoff, and CSR Support

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CDM-P09 — WI execution model

Data cuts, lock and programming handoff

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate cut definition, completion criteria and functional review evidence. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: CDM release coordinator performs and documents the work. Sponsor data owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Sponsor data owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — State authorization, unlock/relock decisions and version links

The release coordinator records whether the requested state is a data cut, freeze or lock and specifies exactly which data and users may still change data. Obtain the designated data-owner authorization. For unlock, record reason, affected records, authorized changes and downstream impact; repeat affected checks, authorize relock and issue a new version with supersession links.

Expected result: The state and permitted changes are explicit; released extracts remain preserved.

Evidence to retain: State authorization, unlock/relock decisions and version links.

Step 2 — Readiness checklist and cut definition

Create the cut/lock request with scope, cutoff, intended use and acceptance criteria. Reconcile all expected data sources, queries, coding and safety review against it.

Expected result: Every required source and review has a documented status and owner.

Evidence to retain: Readiness checklist and cut definition.

Step 3 — Functional approvals and exception disposition

Collect functional signoffs for the named data version and scope. Investigate exceptions; distinguish permitted interim limitations from critical unresolved final-lock defects.

Expected result: Signoffs are not blanket approvals and do not hide known critical issues.

Evidence to retain: Functional approvals and exception disposition.

Step 4 — Lock evidence and transfer manifest

Apply the approved freeze/lock controls and generate the immutable snapshot. Verify file counts, identifiers, schema and integrity against the transfer manifest.

Expected result: Snapshot is the approved version and unauthorized changes are prevented.

Evidence to retain: Lock evidence and transfer manifest.

Step 5 — Receipt, unlock/relock history and supersession record

Transfer securely to programming/biostatistics and obtain acceptance. For a needed correction, obtain unlock authorization, document changes, repeat affected checks and relock with a new version.

Expected result: The original snapshot is retained and all affected recipients know the replacement status.

Evidence to retain: Receipt, unlock/relock history and supersession record.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Critical unresolved discrepancies block final lock; interim limitations must be explicit.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CDM-P09 — consolidated record packet

Data cuts, lock and programming handoff

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Cut, lock and transfer authorization packet

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
CDM-FRM-017 Interim Data Cut, Snapshot, and Blinded Data Release Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-018 Database Freeze and Lock Readiness Certification Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-019 Database Unlock and Relock Authorization Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-020 Final Data Transfer to Biostatistics/Programming Acceptance Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CDM-SOP-019 — Interim Analyses, Data Cuts, Snapshots, Blinding, and Data Release; CDM-SOP-024 — Database Freeze, Soft Lock, Hard Lock, Unlock, and Relock; CDM-SOP-025 — Final Data Transfer to Biostatistics/Programming, SDTM/ADaM Handoff, and CSR Support. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CDM-P09-F01 — Cut/freeze/lock state; scope; cutoff/time zone; allowed changes; authorized owner
CDM-P09-F02 — Readiness/signoffs; snapshot identity; manifest/receipt; unlock/relock and supersession if applicable

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: The state and permitted changes are explicit; released extracts remain preserved.	☐ Yes ☐ No ☐ N/A
Step 2: Every required source and review has a documented status and owner.	☐ Yes ☐ No ☐ N/A
Step 3: Signoffs are not blanket approvals and do not hide known critical issues.	☐ Yes ☐ No ☐ N/A
Step 4: Snapshot is the approved version and unauthorized changes are prevented.	☐ Yes ☐ No ☐ N/A
Step 5: The original snapshot is retained and all affected recipients know the replacement status.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CDM-P10 — SOP model

Records, inspection, archive and authorized sharing

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Preserve retrievable data-management evidence and control authorized disclosure.
Scope: Record inventory, archive acceptance, inspection support and authorized external sharing. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Filing plan, retention requirements and authorized sharing request. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	CDM records coordinator
Accountable	Sponsor data owner
Consulted	Privacy; legal; quality assurance; system owner
Informed	Affected study team and authorized downstream recipients

The records coordinator maintains the inventory and retrieves requested evidence. The records custodian accepts archive custody. The designated inspection owner authorizes authority responses with functional/QA review. The data owner authorizes external use, with privacy/legal assessment where required. These are distinct decisions even when qualified individuals hold more than one role. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Required records are readable, attributable and retrievable, including prior versions. Record: Essential-record index.
Archive acceptance is documented before the system is retired. Record: Archive verification and acceptance.
Access is lawful and authorized for this use; removal of direct identifiers alone is not assumed sufficient. Record: Data-use authorization and privacy assessment.
Only the approved package reaches authorized recipients and retained records remain available. Record: Transfer authorization and custody record.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: CDM records coordinator performs the sequential instructions in CDM-P10-WI-01 and retains the specified evidence in CDM-P10-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Do not decommission before accepted archive; privacy review precedes external transfer.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

On an inspection request or readiness review, use COPS-P10 — Inspection readiness and authority responses. Retain the decision or accepted handoff reference in this packet.
Before operational closeout or system decommissioning, use COPS-P12 — Closeout, records retention and decommissioning. Retain the decision or accepted handoff reference in this packet.
Before archiving programming evidence or verifying reconstruction, use CPROG-P11 — Archive and reproducibility. Retain the decision or accepted handoff reference in this packet.
Before external sharing of programming data, use CPROG-P12 — Privacy and external data sharing. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

6. Records and effectiveness

Retain the records custody, retrieval and sharing record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CDM-P10-WI-01. Controlled record packet: CDM-P10-FRM-01 — Records custody, retrieval and sharing record.

COPS-P10 — Inspection readiness and authority responses
COPS-P12 — Closeout, records retention and decommissioning
CPROG-P11 — Archive and reproducibility
CPROG-P12 — Privacy and external data sharing

Original-to-new crosswalk

CDM-SOP-023 — TMF/eTMF Essential CDM Records Management
CDM-SOP-026 — Study Closeout, Data Archival, Retention, and System Decommissioning
CDM-SOP-027 — Inspection Readiness, Audit Support, and Regulatory Authority Data Requests
CDM-SOP-028 — Data Privacy, De-Identification, Controlled Access, and Data Sharing

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CDM-P10 — WI execution model

Records, inspection, archive and authorized sharing

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate filing plan, retention requirements and authorized sharing request. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The records coordinator maintains the inventory and retrieves requested evidence. The records custodian accepts archive custody. The designated inspection owner authorizes authority responses with functional/QA review. The data owner authorizes external use, with privacy/legal assessment where required. These are distinct decisions even when qualified individuals hold more than one role. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Sponsor data owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Essential-record index

Maintain the CDM record inventory throughout the study, linking plans, specifications, tests, decisions and approvals to controlled repositories.

Expected result: Required records are readable, attributable and retrievable, including prior versions.

Evidence to retain: Essential-record index.

Step 2 — Archive verification and acceptance

At closeout, reconcile the archive manifest to the inventory and test retrieval of data, metadata, audit trails and approvals with the records owner.

Expected result: Archive acceptance is documented before the system is retired.

Evidence to retain: Archive verification and acceptance.

Step 3 — Data-use authorization and privacy assessment

For an external data request, document purpose, recipient, permissions and minimum necessary content. Obtain privacy/legal review and apply approved de-identification.

Expected result: Access is lawful and authorized for this use; removal of direct identifiers alone is not assumed sufficient.

Evidence to retain: Data-use authorization and privacy assessment.

Step 4 — Transfer authorization and custody record

Independently check the outgoing package and restrictions, then record secure transfer and receipt. Preserve source custody, retention requirements and inspection access.

Expected result: Only the approved package reaches authorized recipients and retained records remain available.

Evidence to retain: Transfer authorization and custody record.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Do not decommission before accepted archive; privacy review precedes external transfer.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CDM-P10 — consolidated record packet

Records, inspection, archive and authorized sharing

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Records custody, retrieval and sharing record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
CDM-FRM-021 Study Closeout, Archival, and System Decommissioning Checklist	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-022 TMF/eTMF CDM Essential Records Checklist	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-023 Inspection Request Intake and Response Control Form	□ Yes □ No	□ Yes □ No □ N/A
CDM-FRM-024 Data Privacy, De-Identification, and Data Sharing Request Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CDM-SOP-023 — TMF/eTMF Essential CDM Records Management; CDM-SOP-026 — Study Closeout, Data Archival, Retention, and System Decommissioning; CDM-SOP-027 — Inspection Readiness, Audit Support, and Regulatory Authority Data Requests; CDM-SOP-028 — Data Privacy, De-Identification, Controlled Access, and Data Sharing. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CDM-P10-F01 — Record category; custodian; repository; retention/hold; retrieval test result
CDM-P10-F02 — Sharing purpose/recipient/authority; minimum content; privacy review; exact package and receipt

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Required records are readable, attributable and retrievable, including prior versions.	☐ Yes ☐ No ☐ N/A
Step 2: Archive acceptance is documented before the system is retired.	☐ Yes ☐ No ☐ N/A
Step 3: Access is lawful and authorized for this use; removal of direct identifiers alone is not assumed sufficient.	☐ Yes ☐ No ☐ N/A
Step 4: Only the approved package reaches authorized recipients and retained records remain available.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CPROG-P01 — SOP model

Programming governance, planning and quality

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Plan and oversee programming work that meets approved scientific and quality requirements.
Scope: Programming plans, assignments, oversight, quality review and material changes. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Protocol, SAP, delivery scope and vendor agreements. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Programming lead
Accountable	Sponsor programming owner
Consulted	Biostatistics; CDM; quality assurance; vendor lead
Informed	Affected study team and authorized downstream recipients

Programming lead performs and documents the work. Sponsor programming owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

The plan is approved and material exceptions have authorized disposition. Record: Programming plan approval and linked exception decisions; vendor procedure exception assessment where applicable.
The approved interpretation is recorded before affected programming begins. Record: Protocol/SAP review and decision log.
Each gate has an authorized owner; independent QC is not assigned to the author. Record: Programming plan and responsibility matrix.
A sponsor request alone is not treated as an undocumented waiver of required controls. Record: Quality review and approved procedure-difference record.
Recipients can identify the current approved baseline and superseded work. Record: Change assessment, retest and closure.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Programming lead performs the sequential instructions in CPROG-P01-WI-01 and retains the specified evidence in CPROG-P01-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Trackers are status aids; they do not constitute validation or approval.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

For study governance, risk thresholds or plan changes, use COPS-P01 — Governance, study planning and quality oversight. Retain the decision or accepted handoff reference in this packet.
When data-management plans or ownership change, use CDM-P01 — Data governance, planning and vendor oversight. Retain the decision or accepted handoff reference in this packet.
When selecting or changing programming standards, tools or environment, use CPROG-P02 — Standards, reusable code and computing environment. Retain the decision or accepted handoff reference in this packet.
Before programming production and release, use CPROG-P06 — Data intake, independent QC and production release. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

For a proposed departure from vendor procedures, the programming lead records the exact requirement, reason, affected work, risk, alternative controls, duration and return-to-standard plan. Obtain vendor process-owner agreement and authorized sponsor quality/functional approval before planned use. A sponsor instruction cannot waive applicable law, participant protection or data-integrity requirements. Record urgent actions promptly under the applicable exception route and assess impact; do not retrospectively fabricate approval.

Preserve the failed result and notify Sponsor programming owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the programming plan, decision and quality record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CPROG-P01-WI-01. Controlled record packet: CPROG-P01-FRM-01 — Programming plan, decision and quality record.

COPS-P01 — Governance, study planning and quality oversight
CDM-P01 — Data governance, planning and vendor oversight
CPROG-P02 — Standards, reusable code and computing environment
CPROG-P06 — Data intake, independent QC and production release

Original-to-new crosswalk

CPROG-SOP-001 — Clinical Programming Governance, Data Ownership, Vendor Oversight, and Quality Management
CPROG-SOP-003 — Study Programming Plan Development, Approval, and Maintenance
CPROG-SOP-004 — Protocol, SAP, Estimand, and Programming Alignment
CPROG-SOP-018 — Program Change Control, Defect Management, and Issue Escalation
CPROG-SOP-029 — Programming Quality Metrics, Trend Review, CAPA, and Continuous Improvement

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CPROG-P01 — WI execution model

Programming governance, planning and quality

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate protocol, sap, delivery scope and vendor agreements. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: Programming lead performs and documents the work. Sponsor programming owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Sponsor programming owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Programming plan approval and linked exception decisions; vendor procedure exception assessment where applicable

The programming lead prepares the study programming plan with deliverables, approved scientific inputs, validation methods, roles, repositories and release criteria. Obtain statistical resolution of scientific ambiguities and sponsor programming-owner approval before implementation. Route significant quality concerns or proposed departures from governing procedures to the designated quality owner; an operational lead cannot waive an applicable requirement alone. For a proposed departure from vendor procedures, the programming lead records the exact requirement, reason, affected work, risk, alternative controls, duration and return-to-standard plan. Obtain vendor process-owner agreement and authorized sponsor quality/functional approval before planned use. A sponsor instruction cannot waive applicable law, participant protection or data-integrity requirements. Record urgent actions promptly under the applicable exception route and assess impact; do not retrospectively fabricate approval.

Expected result: The plan is approved and material exceptions have authorized disposition.

Evidence to retain: Programming plan approval and linked exception decisions; vendor procedure exception assessment where applicable.

Step 2 — Protocol/SAP review and decision log

Read the approved protocol, SAP, analysis-data specifications and output specifications together. The protocol governs objectives and endpoint definitions; the SAP defines prespecified analysis consistent with the protocol. Data specifications implement derivations and output specifications implement presentation. Record a conflict with document/version, affected requirement and work held. Obtain the responsible statistical or clinical decision, update the controlling document or approved decision record, and link the resolution in the programming decision log before affected programming proceeds.

Expected result: The approved interpretation is recorded before affected programming begins.

Evidence to retain: Protocol/SAP review and decision log.

Step 3 — Programming plan and responsibility matrix

Assign the production author, independent reviewer and release approver for each deliverable. Compare vendor and sponsor responsibilities and identify the governing procedures.

Expected result: Each gate has an authorized owner; independent QC is not assigned to the author.

Evidence to retain: Programming plan and responsibility matrix.

Step 4 — Quality review and approved procedure-difference record

Review milestones, defect trends and scope changes using dated evidence. For a vendor procedure difference, record exactly what differs, impact, authority and compensating controls.

Expected result: A sponsor request alone is not treated as an undocumented waiver of required controls.

Evidence to retain: Quality review and approved procedure-difference record.

Step 5 — Change assessment, retest and closure

For a material change, record affected programs, datasets, outputs and prior releases. Approve scope, revise the baseline, retest affected work and close on evidence.

Expected result: Recipients can identify the current approved baseline and superseded work.

Evidence to retain: Change assessment, retest and closure.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Trackers are status aids; they do not constitute validation or approval.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CPROG-P01 — consolidated record packet

Programming governance, planning and quality

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Programming plan, decision and quality record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
CPROG-FRM-001 Programming Responsibility Matrix	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-002 Study Programming Plan Template	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-003 Programming Deliverable Request and Approval Form	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-004 Protocol/SAP Programming Review Checklist	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-005 Estimand-to-Output Traceability Matrix	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-025 Programming Change Control Form	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-026 Defect/Issue Escalation Form	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-042 Programming Metrics and Trend Review Record	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-043 Programming CAPA Form	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-052 Sponsor-Directed Vendor Procedure Supersession or Deviation Paper Trail Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CPROG-SOP-001 — Clinical Programming Governance, Data Ownership, Vendor Oversight, and Quality Management; CPROG-SOP-003 — Study Programming Plan Development, Approval, and Maintenance; CPROG-SOP-004 — Protocol, SAP, Estimand, and Programming Alignment; CPROG-SOP-018 — Program Change Control, Defect Management, and Issue Escalation; CPROG-SOP-029 — Programming Quality Metrics, Trend Review, CAPA, and Continuous Improvement. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CPROG-P01-F01 — Protocol/SAP/specification versions; misalignment; affected work; decision owner/date; resolution link
CPROG-P01-F02 — Deliverable/risk; author/reviewer/approver; vendor departure/alternative control; quality action and closure

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: The plan is approved and material exceptions have authorized disposition.	☐ Yes ☐ No ☐ N/A
Step 2: The approved interpretation is recorded before affected programming begins.	☐ Yes ☐ No ☐ N/A
Step 3: Each gate has an authorized owner; independent QC is not assigned to the author.	☐ Yes ☐ No ☐ N/A
Step 4: A sponsor request alone is not treated as an undocumented waiver of required controls.	☐ Yes ☐ No ☐ N/A
Step 5: Recipients can identify the current approved baseline and superseded work.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CPROG-P02 — SOP model

Standards, reusable code and computing environment

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Maintain controlled standards, reusable code and computing configurations suitable for their intended use.
Scope: Selection, qualification, version release, maintenance and retirement of shared programming resources. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Intended use, standards/catalog versions and software inventory. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Standards/tool lead
Accountable	Sponsor programming owner
Consulted	IT; quality assurance; biostatistics
Informed	Affected study team and authorized downstream recipients

Standards/tool lead performs and documents the work. Sponsor programming owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Standards, reusable code and environment each have evidence appropriate to their intended use. Record: Standards decisions, qualification evidence and environment acceptance.
The chosen versions are supported for the intended use and deviations are reviewed. Record: Standards/version decision register.
Requirements are testable and include boundary and error behavior. Record: Reusable-component specification.
Evidence supports intended use; tool qualification is not inferred from popularity. Record: Validation/qualification record.
Users can identify the approved version and reproduce its environment. Record: Release, dependency inventory and change history.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Standards/tool lead performs the sequential instructions in CPROG-P02-WI-01 and retains the specified evidence in CPROG-P02-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Changes require impact assessment and appropriate requalification.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

Before building or releasing a data-collection system, use CDM-P02 — Data standards, collection, build and validation. Retain the decision or accepted handoff reference in this packet.
For SDTM mapping, checks and release, use CPROG-P03 — SDTM specification through validated release. Retain the decision or accepted handoff reference in this packet.
For analysis derivations and ADaM release, use CPROG-P04 — ADaM derivation through validated release. Retain the decision or accepted handoff reference in this packet.
When assembling submission metadata and deliverables, use CPROG-P10 — Submission metadata, validation and package assembly. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

6. Records and effectiveness

Retain the standards decision and reusable-tool qualification dossier, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CPROG-P02-WI-01. Controlled record packet: CPROG-P02-FRM-01 — Standards decision and reusable-tool qualification dossier.

CDM-P02 — Data standards, collection, build and validation
CPROG-P03 — SDTM specification through validated release
CPROG-P04 — ADaM derivation through validated release
CPROG-P10 — Submission metadata, validation and package assembly

Original-to-new crosswalk

CPROG-SOP-002 — Clinical Programming Standards, Systems, Folder Structure, and Version Control
CPROG-SOP-005 — CDISC Standards Strategy, Metadata Governance, and Standards Deviation Control
CPROG-SOP-014 — Controlled Terminology, MedDRA/WHO Drug Inputs, and Version Control
CPROG-SOP-026 — Macro Library, Utility Program, and Reusable Code Development and Validation
CPROG-SOP-027 — Programming Software, Tool Qualification, Package Management, and Computing Environment Control

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CPROG-P02 — WI execution model

Standards, reusable code and computing environment

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate intended use, standards/catalog versions and software inventory. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: Standards/tool lead performs and documents the work. Sponsor programming owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Sponsor programming owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Standards decisions, qualification evidence and environment acceptance

The standards/tool lead records applicable standard versions and differences from the study baseline. For reusable code, document intended use, inputs, expected outputs, tests and release limitations. For the computing environment, confirm dependencies, access restrictions, backup/recovery arrangements and technical-owner acceptance. Release identified versions only after relevant evidence is reviewed; reassess impacted tests after changes.

Expected result: Standards, reusable code and environment each have evidence appropriate to their intended use.

Evidence to retain: Standards decisions, qualification evidence and environment acceptance.

Step 2 — Standards/version decision register

List intended uses and select standards, terminology and software versions against the applicable submission/study strategy. Record rationale for exceptions.

Expected result: The chosen versions are supported for the intended use and deviations are reviewed.

Evidence to retain: Standards/version decision register.

Step 3 — Reusable-component specification

For a reusable component, write its input contract, output behavior, dependencies and failure behavior. Identify risk from incorrect results or incompatible versions.

Expected result: Requirements are testable and include boundary and error behavior.

Evidence to retain: Reusable-component specification.

Step 4 — Validation/qualification record

Run reviewed tests using known expected results, including missing values, limits and invalid inputs. Retain code version, environment, logs and discrepancy resolutions.

Expected result: Evidence supports intended use; tool qualification is not inferred from popularity.

Evidence to retain: Validation/qualification record.

Step 5 — Release, dependency inventory and change history

Approve a versioned release and restrict modification. For upgrades, assess affected uses and rerun appropriate tests before adoption.

Expected result: Users can identify the approved version and reproduce its environment.

Evidence to retain: Release, dependency inventory and change history.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Changes require impact assessment and appropriate requalification.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CPROG-P02 — consolidated record packet

Standards, reusable code and computing environment

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Standards decision and reusable-tool qualification dossier

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
CPROG-FRM-006 Standards Strategy and Version Selection Form	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-007 CDISC Standards Deviation Request	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-008 Controlled Terminology Version Log	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-037 Macro/Reusable Code Requirement Specification	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-038 Reusable Code Validation Record	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-039 Tool Qualification Assessment	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-040 Software and Environment Inventory	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CPROG-SOP-002 — Clinical Programming Standards, Systems, Folder Structure, and Version Control; CPROG-SOP-005 — CDISC Standards Strategy, Metadata Governance, and Standards Deviation Control; CPROG-SOP-014 — Controlled Terminology, MedDRA/WHO Drug Inputs, and Version Control; CPROG-SOP-026 — Macro Library, Utility Program, and Reusable Code Development and Validation; CPROG-SOP-027 — Programming Software, Tool Qualification, Package Management, and Computing Environment Control. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CPROG-P02-F01 — Standard/dictionary/tool versions; intended use; requirement; dependency; exception rationale
CPROG-P02-F02 — Test input/expected/actual result; failures; release limitation; approved version and change impact

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Standards, reusable code and environment each have evidence appropriate to their intended use.	☐ Yes ☐ No ☐ N/A
Step 2: The chosen versions are supported for the intended use and deviations are reviewed.	☐ Yes ☐ No ☐ N/A
Step 3: Requirements are testable and include boundary and error behavior.	☐ Yes ☐ No ☐ N/A
Step 4: Evidence supports intended use; tool qualification is not inferred from popularity.	☐ Yes ☐ No ☐ N/A
Step 5: Users can identify the approved version and reproduce its environment.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CPROG-P03 — SOP model

SDTM specification through validated release

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Produce traceable SDTM datasets that implement approved mappings and pass appropriate checks.
Scope: Mapping development/review, programming, independent checks and dataset release. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Accepted source snapshot and approved standards strategy. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	SDTM programmer
Accountable	Programming lead
Consulted	CDM; standards lead; independent reviewer
Informed	Affected study team and authorized downstream recipients

SDTM programmer performs and documents the work. Programming lead owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Mapping decisions and their review are approved and traceable. Record: Mapping specification, review and approval.
Critical mappings are unambiguous and trace back to the accepted source. Record: Versioned SDTM mapping specification.
No manual untracked dataset edits or unexplained record loss occur. Record: Programs, logs and reconciliation evidence.
Differences are explained and resolved using evidence, not simply matched totals. Record: Independent QC record.
Validator findings have reviewed disposition; semantic correctness is also checked. Record: Validation disposition and SDTM release record.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: SDTM programmer performs the sequential instructions in CPROG-P03-WI-01 and retains the specified evidence in CPROG-P03-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Validator success alone does not establish clinical correctness.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

For external source-data receipt or reconciliation, use CDM-P04 — External data transfer and reconciliation. Retain the decision or accepted handoff reference in this packet.
For an analysis cut, freeze/lock or data handoff, use CDM-P09 — Data cuts, lock and programming handoff. Retain the decision or accepted handoff reference in this packet.
When selecting or changing programming standards, tools or environment, use CPROG-P02 — Standards, reusable code and computing environment. Retain the decision or accepted handoff reference in this packet.
For analysis derivations and ADaM release, use CPROG-P04 — ADaM derivation through validated release. Retain the decision or accepted handoff reference in this packet.
When assembling submission metadata and deliverables, use CPROG-P10 — Submission metadata, validation and package assembly. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Programming lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the sdtm specification and review record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CPROG-P03-WI-01. Controlled record packet: CPROG-P03-FRM-01 — SDTM specification and review record.

CDM-P04 — External data transfer and reconciliation
CDM-P09 — Data cuts, lock and programming handoff
CPROG-P02 — Standards, reusable code and computing environment
CPROG-P04 — ADaM derivation through validated release
CPROG-P10 — Submission metadata, validation and package assembly

Original-to-new crosswalk

CPROG-SOP-006 — SDTM Mapping Specification Development and Review
CPROG-SOP-007 — SDTM Dataset Programming, Validation, and Quality Control

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CPROG-P03 — WI execution model

SDTM specification through validated release

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate accepted source snapshot and approved standards strategy. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: SDTM programmer performs and documents the work. Programming lead owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Programming lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Mapping specification, review and approval

The SDTM programmer prepares mappings from accepted source definitions, including origin, transformations and terminology. The assigned reviewer checks completeness and interpretation with CDM or standards expertise where needed. The programming lead approves the identified specification before production use; changes require impact assessment and repeat checks of affected datasets.

Expected result: Mapping decisions and their review are approved and traceable.

Evidence to retain: Mapping specification, review and approval.

Step 2 — Versioned SDTM mapping specification

Open the accepted source manifest and approved SDTM strategy. Map each variable, origin and transformation in the specification; record unresolved source questions.

Expected result: Critical mappings are unambiguous and trace back to the accepted source.

Evidence to retain: Versioned SDTM mapping specification.

Step 3 — Programs, logs and reconciliation evidence

Program domains from the frozen input version. Record program dependencies and produce reconciliation counts and transformation checks.

Expected result: No manual untracked dataset edits or unexplained record loss occur.

Evidence to retain: Programs, logs and reconciliation evidence.

Step 4 — Independent QC record

Have an independent reviewer verify the prespecified scope, including keys, domains, units, timing and derivations. Compare against source and approved specifications.

Expected result: Differences are explained and resolved using evidence, not simply matched totals.

Evidence to retain: Independent QC record.

Step 5 — Validation disposition and SDTM release record

Run applicable conformance checks, investigate findings and reconcile final data to metadata and specifications. Obtain release approval of the exact manifest.

Expected result: Validator findings have reviewed disposition; semantic correctness is also checked.

Evidence to retain: Validation disposition and SDTM release record.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Validator success alone does not establish clinical correctness.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CPROG-P03 — consolidated record packet

SDTM specification through validated release

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

SDTM specification and review record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
CPROG-FRM-009 SDTM Mapping Specification Template	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-010 SDTM Specification Review Checklist	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-011 SDTM Validation and Release Checklist	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CPROG-SOP-006 — SDTM Mapping Specification Development and Review; CPROG-SOP-007 — SDTM Dataset Programming, Validation, and Quality Control. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CPROG-P03-F01 — Source and specification versions; domain/variable; origin; mapping; terminology
CPROG-P03-F02 — Keys/counts/transform checks; independent QC; conformance disposition; released manifest

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Mapping decisions and their review are approved and traceable.	☐ Yes ☐ No ☐ N/A
Step 2: Critical mappings are unambiguous and trace back to the accepted source.	☐ Yes ☐ No ☐ N/A
Step 3: No manual untracked dataset edits or unexplained record loss occur.	☐ Yes ☐ No ☐ N/A
Step 4: Differences are explained and resolved using evidence, not simply matched totals.	☐ Yes ☐ No ☐ N/A
Step 5: Validator findings have reviewed disposition; semantic correctness is also checked.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CPROG-P04 — SOP model

ADaM derivation through validated release

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Produce analysis datasets that faithfully implement approved statistical intent.
Scope: ADaM specifications, derivations, independent checks and release. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Approved SAP, SDTM snapshot and analysis conventions. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Analysis programmer
Accountable	Programming lead
Consulted	Biostatistician; CDM; independent reviewer
Informed	Affected study team and authorized downstream recipients

Analysis programmer performs and documents the work. Programming lead owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Scientific intent and implementable derivations are approved before production. Record: ADaM specification and statistical/programming approvals.
Definitions agree with the analysis objective and protocol/SAP baseline. Record: Approved ADaM specification.
Each derived value can be traced to inputs and the applied rule. Record: Programs, logs and traceability metadata.
Reviewer checks the scientific rule, not only agreement between two implementations. Record: Independent derivation/QC evidence.
Unresolved endpoint, treatment, population or material lineage issues block approval. Record: ADaM review conclusion and release manifest.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Analysis programmer performs the sequential instructions in CPROG-P04-WI-01 and retains the specified evidence in CPROG-P04-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Unresolved population, treatment or endpoint rules block approval.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

When programming plans, assignments or quality decisions change, use CPROG-P01 — Programming governance, planning and quality. Retain the decision or accepted handoff reference in this packet.
For SDTM mapping, checks and release, use CPROG-P03 — SDTM specification through validated release. Retain the decision or accepted handoff reference in this packet.
For output specifications, TFL production and results traceability, use CPROG-P05 — TFL specification, programming and results traceability. Retain the decision or accepted handoff reference in this packet.
When treatment information or blinding may be affected, use CPROG-P09 — Randomization, treatment handling and blind breaks. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

6. Records and effectiveness

Retain the adam specification and traceability record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CPROG-P04-WI-01. Controlled record packet: CPROG-P04-FRM-01 — ADaM specification and traceability record.

CPROG-P01 — Programming governance, planning and quality
CPROG-P03 — SDTM specification through validated release
CPROG-P05 — TFL specification, programming and results traceability
CPROG-P09 — Randomization, treatment handling and blind breaks

Original-to-new crosswalk

CPROG-SOP-008 — ADaM Specification Development and Review
CPROG-SOP-009 — ADaM Dataset Programming, Validation, and Traceability

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CPROG-P04 — WI execution model

ADaM derivation through validated release

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate approved sap, sdtm snapshot and analysis conventions. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: Analysis programmer performs and documents the work. Programming lead owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Programming lead or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — ADaM specification and statistical/programming approvals

The analysis programmer specifies populations, endpoints, derivations, timing rules, missing-data handling and treatment variables from the approved SAP. Obtain statistical approval of scientific content and programming-lead acceptance of implementability before production use. Resolve conflicts in the controlling document or approved decision record and reassess affected validation after changes.

Expected result: Scientific intent and implementable derivations are approved before production.

Evidence to retain: ADaM specification and statistical/programming approvals.

Step 2 — Approved ADaM specification

Translate approved SAP rules into population, treatment, endpoint, timing and derivation specifications. Obtain statistician decisions for ambiguity before coding.

Expected result: Definitions agree with the analysis objective and protocol/SAP baseline.

Evidence to retain: Approved ADaM specification.

Step 3 — Programs, logs and traceability metadata

Build analysis datasets from identified source versions and record derivation lineage. Preserve identifiers and intermediate evidence needed to explain results.

Expected result: Each derived value can be traced to inputs and the applied rule.

Evidence to retain: Programs, logs and traceability metadata.

Step 4 — Independent derivation/QC evidence

Independently verify critical derivations, including boundary dates, missing values, censoring and treatment/population assignments where applicable.

Expected result: Reviewer checks the scientific rule, not only agreement between two implementations.

Evidence to retain: Independent derivation/QC evidence.

Step 5 — ADaM review conclusion and release manifest

Resolve discrepancies and conformance findings; reconcile datasets, specifications and metadata before release.

Expected result: Unresolved endpoint, treatment, population or material lineage issues block approval.

Evidence to retain: ADaM review conclusion and release manifest.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Unresolved population, treatment or endpoint rules block approval.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CPROG-P04 — consolidated record packet

ADaM derivation through validated release

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

ADaM specification and traceability record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
CPROG-FRM-012 ADaM Specification Template	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-013 ADaM Specification Review Checklist	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-014 ADaM Traceability and Release Checklist	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CPROG-SOP-008 — ADaM Specification Development and Review; CPROG-SOP-009 — ADaM Dataset Programming, Validation, and Traceability. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CPROG-P04-F01 — SAP/specification/source versions; endpoint/population/treatment/derivation rule
CPROG-P04-F02 — Boundary/missing/censoring tests; lineage; independent result; discrepancy and approval

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Scientific intent and implementable derivations are approved before production.	☐ Yes ☐ No ☐ N/A
Step 2: Definitions agree with the analysis objective and protocol/SAP baseline.	☐ Yes ☐ No ☐ N/A
Step 3: Each derived value can be traced to inputs and the applied rule.	☐ Yes ☐ No ☐ N/A
Step 4: Reviewer checks the scientific rule, not only agreement between two implementations.	☐ Yes ☐ No ☐ N/A
Step 5: Unresolved endpoint, treatment, population or material lineage issues block approval.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CPROG-P05 — SOP model

TFL specification, programming and results traceability

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Produce approved, validated TFLs traceable to statistical intent and analysis data.
Scope: Shell/specification development, programming, validation and output approval. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Approved SAP, output shells and analysis snapshot. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	TFL programmer
Accountable	Lead biostatistician
Consulted	Programming lead; independent reviewer; medical writer
Informed	Affected study team and authorized downstream recipients

TFL programmer performs and documents the work. Lead biostatistician owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Approved shells and planned checks cover the output purpose and critical content. Record: Shell specification, statistical approval, feasibility review and validation plan.
No affected programming proceeds on unresolved scientific requirements. Record: Version-confirmed shell/specification handoff.
Output content and presentation match the approved specification. Record: Production outputs and execution logs.
A visually correct output is not accepted without numerical/scientific checks. Record: Output QC and result traceability record.
Scientific ambiguities or incorrect results block the affected output release. Record: Approved output package and conditions record.
Each released result can be traced to its analysis inputs and generating code. Record: Output lineage and applicable results-metadata review.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: TFL programmer performs the sequential instructions in CPROG-P05-WI-01 and retains the specified evidence in CPROG-P05-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Scientific ambiguities block approval; administrative conditions need owner and due date.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

When programming plans, assignments or quality decisions change, use CPROG-P01 — Programming governance, planning and quality. Retain the decision or accepted handoff reference in this packet.
For analysis derivations and ADaM release, use CPROG-P04 — ADaM derivation through validated release. Retain the decision or accepted handoff reference in this packet.
Before programming production and release, use CPROG-P06 — Data intake, independent QC and production release. Retain the decision or accepted handoff reference in this packet.
When assembling submission metadata and deliverables, use CPROG-P10 — Submission metadata, validation and package assembly. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Lead biostatistician or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the tfl specification, qc and results record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CPROG-P05-WI-01. Controlled record packet: CPROG-P05-FRM-01 — TFL specification, QC and results record.

CPROG-P01 — Programming governance, planning and quality
CPROG-P04 — ADaM derivation through validated release
CPROG-P06 — Data intake, independent QC and production release
CPROG-P10 — Submission metadata, validation and package assembly

Original-to-new crosswalk

CPROG-SOP-010 — TFL Shell Development, Output Specification, and Approval
CPROG-SOP-011 — TFL Programming, Validation, and Output Quality Control
CPROG-SOP-012 — Analysis Results Metadata, Traceability, and Results Reproducibility

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CPROG-P05 — WI execution model

TFL specification, programming and results traceability

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate approved sap, output shells and analysis snapshot. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: TFL programmer performs and documents the work. Lead biostatistician owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Lead biostatistician or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Shell specification, statistical approval, feasibility review and validation plan

The Programming Lead coordinates shells prepared from the approved SAP. For each output, identify its population, estimand or endpoint, statistic, denominator, display rules, footnotes and data source. Obtain statistical approval and documented programming feasibility review for Critical Outputs, with the validation method planned before production. The author shall not be the sole person approving both statistical content and feasibility for a Critical Output. Request Clinical, Medical, Safety, DM, Medical Writing or Regulatory review only where content, intended use, criticality or assigned responsibility requires that expertise.

Expected result: Approved shells and planned checks cover the output purpose and critical content.

Evidence to retain: Shell specification, statistical approval, feasibility review and validation plan.

Step 2 — Version-confirmed shell/specification handoff

Obtain the approved output shells/specifications and analysis data baseline. Give the author and independent reviewer the same version; confirm populations, denominators, statistics and labels.

Expected result: No affected programming proceeds on unresolved scientific requirements.

Evidence to retain: Version-confirmed shell/specification handoff.

Step 3 — Production outputs and execution logs

Generate outputs using approved programs and data. Record program/output identity, run time and all relevant logs; inspect pagination, labels, footnotes and suppressed values.

Expected result: Output content and presentation match the approved specification.

Evidence to retain: Production outputs and execution logs.

Step 4 — Output QC and result traceability record

Independently check key results against analysis data and methods, including denominators, rounding, missing data and figure/table consistency. Document review scope and discrepancies.

Expected result: A visually correct output is not accepted without numerical/scientific checks.

Evidence to retain: Output QC and result traceability record.

Step 5 — Approved output package and conditions record

Reconcile the reviewed outputs with the final manifest and obtain the authorized approval. Use an approved-with-conditions status only if the adopted workflow defines it, and only for administrative or non-statistical matters. Record each condition, owner, due date, affected outputs and closure evidence. Close any condition affecting production execution before that execution; close conditions affecting validation, interpretation, blinding or release before the affected release.

Expected result: Scientific ambiguities or incorrect results block the affected output release.

Evidence to retain: Approved output package and conditions record.

Step 6 — Output lineage and applicable results-metadata review

For each released output, the TFL programmer records its identifier/version, analysis-data baseline, generating program/version, parameter or run context and relevant analysis/specification reference. Reconcile applicable results metadata with the output and obtain reviewer confirmation. Record authorized exclusions rather than inventing metadata requirements for an unsupported submission type.

Expected result: Each released result can be traced to its analysis inputs and generating code.

Evidence to retain: Output lineage and applicable results-metadata review.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Scientific ambiguities block approval; administrative conditions need owner and due date.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CPROG-P05 — consolidated record packet

TFL specification, programming and results traceability

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

TFL specification, QC and results record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
CPROG-FRM-015 TFL Shell Review Checklist	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-016 Output QC and Validation Record	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-017 Analysis Results Metadata Tracker Template	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CPROG-SOP-010 — TFL Shell Development, Output Specification, and Approval; CPROG-SOP-011 — TFL Programming, Validation, and Output Quality Control; CPROG-SOP-012 — Analysis Results Metadata, Traceability, and Results Reproducibility. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CPROG-P05-F01 — Output ID/version; criticality; population/denominator/statistic; shell/specification and SAP reference
CPROG-P05-F02 — Statistical approval; feasibility reviewer; validation method/results; condition owner/due date/closure; final manifest

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Approved shells and planned checks cover the output purpose and critical content.	☐ Yes ☐ No ☐ N/A
Step 2: No affected programming proceeds on unresolved scientific requirements.	☐ Yes ☐ No ☐ N/A
Step 3: Output content and presentation match the approved specification.	☐ Yes ☐ No ☐ N/A
Step 4: A visually correct output is not accepted without numerical/scientific checks.	☐ Yes ☐ No ☐ N/A
Step 5: Scientific ambiguities or incorrect results block the affected output release.	☐ Yes ☐ No ☐ N/A
Step 6: Each released result can be traced to its analysis inputs and generating code.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CPROG-P06 — SOP model

Data intake, independent QC and production release

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Release reproducible programming outputs supported by accepted inputs and documented independent checks.
Scope: Input acceptance, validation planning, production execution, discrepancy disposition and release. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Authorized cut, approved programs, specs and environment baseline. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Production programmer
Accountable	Designated programming release approver
Consulted	Independent QC reviewer; CDM; biostatistics
Informed	Affected study team and authorized downstream recipients

Production programmer performs and documents the work. Designated programming release approver owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

The plan defines review scope, method, independence and acceptance criteria before execution. Record: Validation scope and reviewer assignment.
Accepted inputs match the authorized cut; receipt does not imply database lock. Record: Receipt manifest, integrity results and acceptance decision.
Import preserves the defined values and structure without silent conversion or truncation. Record: Import settings, source-to-import checks and log.
Delta handling follows the agreed rules and reconciles to the accepted baseline. Record: Delta reconciliation and downstream impact assessment.
Every output can be tied to the actual run, inputs, code and environment. Record: Run manifest, dependency order, status and complete logs.
No unexplained material log issue, failed fit, stale file or incomplete run remains. Record: Log review with message-level dispositions.
The comparison is complete and independent enough to detect incorrect shared logic. Record: Code review and independent QC results with comparison rules.
Discrepancies and affected regression checks are closed on evidence. Record: Issue disposition, change impact and independent retest.
Only the reviewed version is released; custody, restrictions and supersession are traceable. Record: Final approval, transfer receipt and archive manifest.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Production programmer performs the sequential instructions in CPROG-P06-WI-01 and retains the specified evidence in CPROG-P06-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Author cannot self-certify independent QC; release approval identifies exact versions.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

For an analysis cut, freeze/lock or data handoff, use CDM-P09 — Data cuts, lock and programming handoff. Retain the decision or accepted handoff reference in this packet.
When programming plans, assignments or quality decisions change, use CPROG-P01 — Programming governance, planning and quality. Retain the decision or accepted handoff reference in this packet.
For output specifications, TFL production and results traceability, use CPROG-P05 — TFL specification, programming and results traceability. Retain the decision or accepted handoff reference in this packet.
Before archiving programming evidence or verifying reconstruction, use CPROG-P11 — Archive and reproducibility. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Designated programming release approver or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the intake, run and release evidence packet, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CPROG-P06-WI-01. Controlled record packet: CPROG-P06-FRM-01 — Intake, run and release evidence packet.

CDM-P09 — Data cuts, lock and programming handoff
CPROG-P01 — Programming governance, planning and quality
CPROG-P05 — TFL specification, programming and results traceability
CPROG-P11 — Archive and reproducibility

Original-to-new crosswalk

CPROG-SOP-015 — Clinical Data Receipt, Data Cut, and Source Data Handling for Programming
CPROG-SOP-016 — Programming Validation Strategy, Independent QC, and Quality Evidence
CPROG-SOP-017 — Code Review, Peer Review, Log Review, and Program Documentation
CPROG-SOP-019 — Statistical Analysis Reproducibility, Production Runs, and Release Control
CPROG-SOP-023 — Data Cut, Snapshot, Interim, Draft, and Final Analysis Release Management

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CPROG-P06 — WI execution model

Data intake, independent QC and production release

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate authorized cut, approved programs, specs and environment baseline. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: Production programmer performs and documents the work. Designated programming release approver owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Designated programming release approver or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Validation scope and reviewer assignment

The Programming Lead identifies the requested deliverables, intended use and criticality. Assign a production programmer, qualified reviewer and release approver; document permitted role combinations. Select independent programming, targeted derivation checks or another justified method for each output and agree acceptance criteria before execution. Record any shared code or dependencies so the review addresses common-mode errors.

Expected result: The plan defines review scope, method, independence and acceptance criteria before execution.

Evidence to retain: Validation scope and reviewer assignment.

Step 2 — Receipt manifest, integrity results and acceptance decision

The receiving programmer compares the transfer with the approved request: sender, study, source system, cut date/time and time zone, extraction rules, file names, versions, counts and available integrity checks. Preserve the received originals in the restricted input area. Quarantine an unexpected, incomplete or unauthorized delivery; obtain resolution from the data owner before use. Record acceptance separately from database freeze or lock.

Expected result: Accepted inputs match the authorized cut; receipt does not imply database lock.

Evidence to retain: Receipt manifest, integrity results and acceptance decision.

Step 3 — Import settings, source-to-import checks and log

Read the transfer specification before importing. Set encoding, delimiter, quoting, line endings and variable types explicitly where relevant. Preserve leading zeros in identifiers and distinguish missing values from literal text. Verify date/time interpretation, time zone, units, character lengths and truncation using representative and boundary records. Compare imported counts and key values with the source; retain the import code and log.

Expected result: Import preserves the defined values and structure without silent conversion or truncation.

Evidence to retain: Import settings, source-to-import checks and log.

Step 4 — Delta reconciliation and downstream impact assessment

For a replacement or incremental delivery, identify the prior accepted version and the specified insert, update and deletion rules. Check keys and duplicates before merging; reconcile added, changed, removed and unchanged records. Test reprocessing behavior so the same delivery cannot silently duplicate records. Preserve the prior baseline and document which downstream work must be repeated.

Expected result: Delta handling follows the agreed rules and reconciles to the accepted baseline.

Evidence to retain: Delta reconciliation and downstream impact assessment.

Step 5 — Run manifest, dependency order, status and complete logs

Identify the approved specification, source baseline, code revision, reusable components, software versions and run parameters. Stage the candidate output separately from prior runs. Execute programs in dependency order using authorized access. Capture start/end time, execution status, complete logs and output identities, including failed runs; do not overwrite the only evidence of a failure.

Expected result: Every output can be tied to the actual run, inputs, code and environment.

Evidence to retain: Run manifest, dependency order, status and complete logs.

Step 6 — Log review with message-level dispositions

The reviewer reads the complete log and execution status, then traces relevant messages to the affected data and code. Assess errors, warnings, conversion notes, merge issues, missing/uninitialized variables, empty outputs, incomplete execution and model convergence where applicable. Check that files are newly generated for this run. Record the disposition and evidence for each relevant issue; a clean keyword scan alone is insufficient.

Expected result: No unexplained material log issue, failed fit, stale file or incomplete run remains.

Evidence to retain: Log review with message-level dispositions.

Step 7 — Code review and independent QC results with comparison rules

The reviewer inspects the code against the approved specification and confirms derivations, joins, filters, populations, treatment rules and dependency use. Perform the planned independent checks using the same accepted baseline. Check key uniqueness, required variables, unmatched records, missingness and counts before comparing values. Define justified numeric tolerances before evaluating results; compare unrounded values where needed and do not mask differences by dropping records or suppressing missing values.

Expected result: The comparison is complete and independent enough to detect incorrect shared logic.

Evidence to retain: Code review and independent QC results with comparison rules.

Step 8 — Issue disposition, change impact and independent retest

For each discrepancy, retain expected and actual results, affected versions, impact, owner and disposition. Correct source code or obtain an authorized source/specification correction; do not hand-edit the final output. Assess effects on related datasets, outputs and prior releases. Rerun affected work and have the reviewer verify the corrected result and necessary regression checks against the exact replacement version.

Expected result: Discrepancies and affected regression checks are closed on evidence.

Evidence to retain: Issue disposition, change impact and independent retest.

Step 9 — Final approval, transfer receipt and archive manifest

The release approver reconciles the final manifest with completed reviews and the intended use. Confirm required statistical decisions, blinding status, permitted recipients and closure of release-blocking issues. Approve the exact versions. Transfer through the authorized channel, obtain receipt or escalate failed delivery, and archive inputs, code, logs, QC and approvals with the release. Link superseded releases and notify affected recipients when a correction changes their authorized baseline.

Expected result: Only the reviewed version is released; custody, restrictions and supersession are traceable.

Evidence to retain: Final approval, transfer receipt and archive manifest.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Author cannot self-certify independent QC; release approval identifies exact versions.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CPROG-P06 — consolidated record packet

Data intake, independent QC and production release

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Intake, run and release evidence packet

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
CPROG-FRM-020 Data Receipt and Intake Checklist	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-021 Data Cut/Snapshot Definition Form	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-022 Independent Programming QC Record	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-023 Code Review Checklist	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-024 Program Log Review Checklist	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-027 Production Run and Release Record	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-032 Analysis Release Request Form	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CPROG-SOP-015 — Clinical Data Receipt, Data Cut, and Source Data Handling for Programming; CPROG-SOP-016 — Programming Validation Strategy, Independent QC, and Quality Evidence; CPROG-SOP-017 — Code Review, Peer Review, Log Review, and Program Documentation; CPROG-SOP-019 — Statistical Analysis Reproducibility, Production Runs, and Release Control; CPROG-SOP-023 — Data Cut, Snapshot, Interim, Draft, and Final Analysis Release Management. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CPROG-P06-F01 — Request/cut/time zone; receipt identity; import settings; counts/keys; delta and integrity results
CPROG-P06-F02 — Code/specification/environment/run IDs; full-log review; comparison rules/results; independent retest; release and receipt

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: The plan defines review scope, method, independence and acceptance criteria before execution.	☐ Yes ☐ No ☐ N/A
Step 2: Accepted inputs match the authorized cut; receipt does not imply database lock.	☐ Yes ☐ No ☐ N/A
Step 3: Import preserves the defined values and structure without silent conversion or truncation.	☐ Yes ☐ No ☐ N/A
Step 4: Delta handling follows the agreed rules and reconciles to the accepted baseline.	☐ Yes ☐ No ☐ N/A
Step 5: Every output can be tied to the actual run, inputs, code and environment.	☐ Yes ☐ No ☐ N/A
Step 6: No unexplained material log issue, failed fit, stale file or incomplete run remains.	☐ Yes ☐ No ☐ N/A
Step 7: The comparison is complete and independent enough to detect incorrect shared logic.	☐ Yes ☐ No ☐ N/A
Step 8: Discrepancies and affected regression checks are closed on evidence.	☐ Yes ☐ No ☐ N/A
Step 9: Only the reviewed version is released; custody, restrictions and supersession are traceable.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CPROG-P07 — SOP model

Integrated, real-world and legacy data programming

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Create traceable integrated or converted data suitable for a defined analysis use.
Scope: Integrated, real-world and legacy data intake, harmonization, conversion and limitation assessment. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Study/source inventories, provenance and analysis objectives. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Integration programmer
Accountable	Lead biostatistician
Consulted	Data owners; epidemiology; programming lead; independent reviewer
Informed	Affected study team and authorized downstream recipients

The integration programmer preserves provenance and implements approved transformations. The lead biostatistician, with epidemiology or source-owner expertise as needed, accepts scientific comparability, intended use and limitations. An independent reviewer checks transformation accuracy. The programming lead accepts technical readiness; neither technical acceptance nor conversion success establishes scientific validity. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Unresolved provenance or fitness limitations are explicit and do not disappear after conversion. Record: Recovery inventory, reconciliation and fit-for-use decision.
Technical availability is not confused with scientific suitability. Record: Source fitness and integration assessment.
Differences are explicit and no unjustified equivalence is introduced. Record: Approved pooling/conversion strategy.
Unexpected differences and loss are investigated with traceable disposition. Record: Conversion QC and remediation evidence.
The delivered package states what it can and cannot support. Record: Integration release and limitation statement.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Integration programmer performs the sequential instructions in CPROG-P07-WI-01 and retains the specified evidence in CPROG-P07-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Do not imply comparability or causal validity from technical harmonization.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

For external source-data receipt or reconciliation, use CDM-P04 — External data transfer and reconciliation. Retain the decision or accepted handoff reference in this packet.
When programming plans, assignments or quality decisions change, use CPROG-P01 — Programming governance, planning and quality. Retain the decision or accepted handoff reference in this packet.
For SDTM mapping, checks and release, use CPROG-P03 — SDTM specification through validated release. Retain the decision or accepted handoff reference in this packet.
For analysis derivations and ADaM release, use CPROG-P04 — ADaM derivation through validated release. Retain the decision or accepted handoff reference in this packet.
Before external sharing of programming data, use CPROG-P12 — Privacy and external data sharing. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

6. Records and effectiveness

Retain the integration strategy and remediation record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CPROG-P07-WI-01. Controlled record packet: CPROG-P07-FRM-01 — Integration strategy and remediation record.

CDM-P04 — External data transfer and reconciliation
CPROG-P01 — Programming governance, planning and quality
CPROG-P03 — SDTM specification through validated release
CPROG-P04 — ADaM derivation through validated release
CPROG-P12 — Privacy and external data sharing

Original-to-new crosswalk

CPROG-SOP-020 — Integrated Summaries, Pooled Databases, and Cross-Study Programming
CPROG-SOP-031 — Real-World Evidence, Registry, and Non-Interventional Study Programming Controls
CPROG-SOP-032 — Legacy Study Data Conversion, Rescue Programming, and Remediation

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CPROG-P07 — WI execution model

Integrated, real-world and legacy data programming

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate study/source inventories, provenance and analysis objectives. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The integration programmer preserves provenance and implements approved transformations. The lead biostatistician, with epidemiology or source-owner expertise as needed, accepts scientific comparability, intended use and limitations. An independent reviewer checks transformation accuracy. The programming lead accepts technical readiness; neither technical acceptance nor conversion success establishes scientific validity. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Lead biostatistician or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Recovery inventory, reconciliation and fit-for-use decision

For legacy or rescued data, inventory available source, specifications, code and metadata. Compare recovered records with an authoritative baseline where available; document missing provenance and tests that cannot be performed. Obtain statistical acceptance of the remaining limitations for the intended use before integration or release.

Expected result: Unresolved provenance or fitness limitations are explicit and do not disappear after conversion.

Evidence to retain: Recovery inventory, reconciliation and fit-for-use decision.

Step 2 — Source fitness and integration assessment

Inventory source studies/data and their provenance, permissions, design differences, collection methods and missingness. Ask scientific owners to assess fitness for the proposed analysis.

Expected result: Technical availability is not confused with scientific suitability.

Evidence to retain: Source fitness and integration assessment.

Step 3 — Approved pooling/conversion strategy

Specify harmonization, pooling, conversion and derivation rules. Record incompatible definitions and how they affect interpretation; obtain scientific approval.

Expected result: Differences are explicit and no unjustified equivalence is introduced.

Evidence to retain: Approved pooling/conversion strategy.

Step 4 — Conversion QC and remediation evidence

Run the conversion or integration and reconcile against retained originals. Independently test key values, counts and transformations; quantify information loss where relevant.

Expected result: Unexpected differences and loss are investigated with traceable disposition.

Evidence to retain: Conversion QC and remediation evidence.

Step 5 — Integration release and limitation statement

Document limitations and remaining approved restrictions in the delivery record and reviewer information. Obtain acceptance from the receiving scientific owner.

Expected result: The delivered package states what it can and cannot support.

Evidence to retain: Integration release and limitation statement.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Do not imply comparability or causal validity from technical harmonization.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CPROG-P07 — consolidated record packet

Integrated, real-world and legacy data programming

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Integration strategy and remediation record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
CPROG-FRM-028 Integrated Summary Pooling Decision Log	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-046 RWE Programming Plan Addendum	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-047 Legacy Programming Intake Checklist	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-048 Programming Remediation Completion Report	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CPROG-SOP-020 — Integrated Summaries, Pooled Databases, and Cross-Study Programming; CPROG-SOP-031 — Real-World Evidence, Registry, and Non-Interventional Study Programming Controls; CPROG-SOP-032 — Legacy Study Data Conversion, Rescue Programming, and Remediation. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CPROG-P07-F01 — Source inventory/provenance; permission; study differences; fitness limitation; scientific acceptance
CPROG-P07-F02 — Harmonization rule; counts/values lost or changed; independent checks; residual restriction and approval

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Unresolved provenance or fitness limitations are explicit and do not disappear after conversion.	☐ Yes ☐ No ☐ N/A
Step 2: Technical availability is not confused with scientific suitability.	☐ Yes ☐ No ☐ N/A
Step 3: Differences are explicit and no unjustified equivalence is introduced.	☐ Yes ☐ No ☐ N/A
Step 4: Unexpected differences and loss are investigated with traceable disposition.	☐ Yes ☐ No ☐ N/A
Step 5: The delivered package states what it can and cannot support.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CPROG-P08 — SOP model

Interim/DMC outputs and firewall management

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Provide validated interim/DMC outputs without compromising the study firewall.
Scope: Restricted input handling, generation, independent review, authorization and secure transfer. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Charter, authorized recipients and restricted output plan. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Authorized unblinded programmer
Accountable	Designated unblinded release approver
Consulted	DMC statistician; restricted independent reviewer
Informed	Affected study team and authorized downstream recipients

The authorized unblinded programmer generates the package. The restricted independent reviewer checks outputs and hidden metadata. The designated unblinded approver authorizes the exact package for charter-listed recipients; the DMC statistician/secretariat confirms receipt. Quality review uses suitably authorized personnel and restricted evidence; routine communications disclose no treatment information. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

No blinded user can access treatment-revealing working files or outputs. Record: Firewall/access verification.
Restricted information is not copied into general trackers, email or shared folders. Record: Restricted run and package manifest.
Review and release occur entirely within authorized roles. Record: Restricted QC and approval.
Receipt and any incident disposition are documented without exposing the data further. Record: DMC transfer receipt and incident record.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Authorized unblinded programmer performs the sequential instructions in CPROG-P08-WI-01 and retains the specified evidence in CPROG-P08-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Blinded teams must not receive treatment-revealing outputs.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

When coordinating restricted interim review transfers, use COPS-P09 — Interim review and restricted information transfer. Retain the decision or accepted handoff reference in this packet.
For an analysis cut, freeze/lock or data handoff, use CDM-P09 — Data cuts, lock and programming handoff. Retain the decision or accepted handoff reference in this packet.
Before programming production and release, use CPROG-P06 — Data intake, independent QC and production release. Retain the decision or accepted handoff reference in this packet.
When treatment information or blinding may be affected, use CPROG-P09 — Randomization, treatment handling and blind breaks. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Designated unblinded release approver or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the restricted interim firewall and release record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CPROG-P08-WI-01. Controlled record packet: CPROG-P08-FRM-01 — Restricted interim firewall and release record.

COPS-P09 — Interim review and restricted information transfer
CDM-P09 — Data cuts, lock and programming handoff
CPROG-P06 — Data intake, independent QC and production release
CPROG-P09 — Randomization, treatment handling and blind breaks

Original-to-new crosswalk

CPROG-SOP-021 — Interim Analyses, DMC/IDMC Deliverables, Blinding, and Firewall Controls

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CPROG-P08 — WI execution model

Interim/DMC outputs and firewall management

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate charter, authorized recipients and restricted output plan. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The authorized unblinded programmer generates the package. The restricted independent reviewer checks outputs and hidden metadata. The designated unblinded approver authorizes the exact package for charter-listed recipients; the DMC statistician/secretariat confirms receipt. Quality review uses suitably authorized personnel and restricted evidence; routine communications disclose no treatment information. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Designated unblinded release approver or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Firewall/access verification

Confirm the charter, approved cut, output scope and named unblinded recipients. Verify role separation and access before opening restricted inputs.

Expected result: No blinded user can access treatment-revealing working files or outputs.

Evidence to retain: Firewall/access verification.

Step 2 — Restricted run and package manifest

Produce the authorized outputs in segregated storage using the restricted baseline. Keep logs, output names and metadata within the same protection boundary.

Expected result: Restricted information is not copied into general trackers, email or shared folders.

Evidence to retain: Restricted run and package manifest.

Step 3 — Restricted QC and approval

Have an authorized independent reviewer verify results, masking, hidden metadata and final recipients. Obtain the designated unblinded release approval.

Expected result: Review and release occur entirely within authorized roles.

Evidence to retain: Restricted QC and approval.

Step 4 — DMC transfer receipt and incident record

Before transfer, reconcile the released output IDs, versions, cut, meeting/session and approved audience with the release manifest. Record each recipient, role, authorization and access restriction. If meeting participation is relevant, link the controlled attendance record or record only the attendees who received or accessed the outputs; do not create a duplicate general attendance sheet. Transfer through the authorized channel, record time and receipt, and reconcile delivery failures. For unintended disclosure, preserve the chronology and start containment and impact assessment.

Expected result: Receipt and any incident disposition are documented without exposing the data further.

Evidence to retain: DMC transfer receipt and incident record.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Blinded teams must not receive treatment-revealing outputs.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CPROG-P08 — consolidated record packet

Interim/DMC outputs and firewall management

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Restricted interim firewall and release record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A	Evidence / exception / reviewer
CPROG-FRM-029 Interim Analysis Firewall Plan Checklist	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-030 DMC/IDMC Output Release Log	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CPROG-SOP-021 — Interim Analyses, DMC/IDMC Deliverables, Blinding, and Firewall Controls. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CPROG-P08-F01 — Charter/meeting; cut; output IDs/versions; masking/QC evidence; release approver
CPROG-P08-F02 — Recipient/role/authorization; output access or linked attendance record if relevant; transfer/receipt/exception

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: No blinded user can access treatment-revealing working files or outputs.	☐ Yes ☐ No ☐ N/A
Step 2: Restricted information is not copied into general trackers, email or shared folders.	☐ Yes ☐ No ☐ N/A
Step 3: Review and release occur entirely within authorized roles.	☐ Yes ☐ No ☐ N/A
Step 4: Receipt and any incident disposition are documented without exposing the data further.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CPROG-P09 — SOP model

Randomization, treatment handling and blind breaks

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Control randomization and treatment information and manage necessary or unintended disclosure.
Scope: Allocation preparation/control, treatment derivation, planned and emergency unblinding, and accidental disclosure. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Protocol, randomization specification, emergency pathway and access matrix. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Authorized randomization specialist
Accountable	Sponsor designated blind custodian
Consulted	Investigator/medical monitor; biostatistician; DM/IT; Clinical Operations; safety; QA; authorized DMC/secretariat
Informed	Affected study team and authorized downstream recipients

The randomization specialist controls allocation generation; the designated statistician approves the design and scientific content. The blind custodian controls routine access and planned disclosure. Investigators/treating physicians decide emergency medical unblinding. DM/IT implement authorized data/access containment. Clinical Operations verifies site readiness and communicates permitted operational instructions. Safety personnel manage required safety disclosures under study arrangements. DMC members receive only charter-authorized information and maintain confidentiality. QA assesses significant process failures and corrective action without routine access to unrestricted treatment data. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Blind protection, communication boundaries and emergency/backup access are demonstrably ready. Record: Blind-maintenance plan, access matrix and readiness test.
Allocation conforms to the approved design and custody is established before use. Record: Restricted generation, independent verification, approval and custody evidence.
Custody and role separation are established before handling treatment information. Record: Blind-maintenance and access review.
Randomization/actual treatment distinctions follow the approved analysis plan. Record: Treatment-handling QC record.
Only authorized scope is disclosed and the planned event is fully traceable. Record: Planned blind-break authorization.
Emergency access and backup arrangements are available; care is not delayed and disclosure is documented. Record: Restricted emergency-unblinding event and notification record.
Disclosure extent and impact are assessed; corrective actions and remaining restrictions are documented. Record: Restricted accidental-disclosure assessment and closure record.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Authorized randomization specialist performs the sequential instructions in CPROG-P09-WI-01 and retains the specified evidence in CPROG-P09-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Emergency clinical unblinding must not await routine administrative approval.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

For significant noncompliance or urgent safety measures, use COPS-P11 — Significant noncompliance and urgent safety measures. Retain the decision or accepted handoff reference in this packet.
When programming plans, assignments or quality decisions change, use CPROG-P01 — Programming governance, planning and quality. Retain the decision or accepted handoff reference in this packet.
For analysis derivations and ADaM release, use CPROG-P04 — ADaM derivation through validated release. Retain the decision or accepted handoff reference in this packet.
For restricted interim/DMC programming outputs, use CPROG-P08 — Interim/DMC outputs and firewall management. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Sponsor designated blind custodian or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the separate treatment-handling and blind-break authorization records, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CPROG-P09-WI-01. Controlled record packet: CPROG-P09-FRM-01 — Separate treatment-handling and blind-break authorization records.

COPS-P11 — Significant noncompliance and urgent safety measures
CPROG-P01 — Programming governance, planning and quality
CPROG-P04 — ADaM derivation through validated release
CPROG-P08 — Interim/DMC outputs and firewall management

Original-to-new crosswalk

CPROG-SOP-022 — Randomization, Treatment Assignment, Unblinding, and Analysis Treatment Variables
CPROG-SOP-033 — Maintaining and Breaking the Blind

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CPROG-P09 — WI execution model

Randomization, treatment handling and blind breaks

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate protocol, randomization specification, emergency pathway and access matrix. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The randomization specialist controls allocation generation; the designated statistician approves the design and scientific content. The blind custodian controls routine access and planned disclosure. Investigators/treating physicians decide emergency medical unblinding. DM/IT implement authorized data/access containment. Clinical Operations verifies site readiness and communicates permitted operational instructions. Safety personnel manage required safety disclosures under study arrangements. DMC members receive only charter-authorized information and maintain confidentiality. QA assesses significant process failures and corrective action without routine access to unrestricted treatment data. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Sponsor designated blind custodian or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Blind-maintenance plan, access matrix and readiness test

Before study use and after relevant changes, the blind custodian confirms the access matrix, communication routes, primary/backup contacts and emergency mechanism with site and system owners. Test an authorized emergency-access scenario without disclosing live allocations unnecessarily. Clinical Operations verifies site readiness and training evidence; DM verifies treatment-data restrictions; QA reviews significant failures and their disposition within authorized access.

Expected result: Blind protection, communication boundaries and emergency/backup access are demonstrably ready.

Evidence to retain: Blind-maintenance plan, access matrix and readiness test.

Step 2 — Restricted generation, independent verification, approval and custody evidence

The authorized randomization specialist translates the approved allocation specification into a controlled sequence-generation method. A separate qualified reviewer verifies allocation ratio, strata, block handling where applicable, identifiers and reproducibility within restricted access. The designated statistical approver approves the sequence before controlled transfer to the allocation-system custodian; retain generation and receipt evidence separately from blinded records.

Expected result: Allocation conforms to the approved design and custody is established before use.

Evidence to retain: Restricted generation, independent verification, approval and custody evidence.

Step 3 — Blind-maintenance and access review

The blind custodian confirms the allocation custody agreement and authorized-role matrix. Define who may communicate each category of restricted content, to whom, by which secure route and where the record is retained. Before sending, check recipients, attachments, file names, hidden content and permissions; keep treatment-revealing information out of blinded minutes and general distribution lists. Authorized unblinded personnel follow these restrictions; DMC communications follow the charter. Refer suspected disclosure to the restricted incident route with QA review proportionate to impact.

Expected result: Custody and role separation are established before handling treatment information.

Evidence to retain: Blind-maintenance and access review.

Step 4 — Treatment-handling QC record

Derive treatment variables only from the authorized allocation inputs and approved rules. Have a qualified independent restricted reviewer verify mappings and exceptions.

Expected result: Randomization/actual treatment distinctions follow the approved analysis plan.

Evidence to retain: Treatment-handling QC record.

Step 5 — Planned blind-break authorization

For planned unblinded access or disclosure, the blind custodian records the rationale, affected study/activity, impacted vendor procedure or process if applicable, named authorized personnel, exact unblinded content, access location, effective date/time, closure criteria, approving role/function and required records. Obtain authorization before enabling access. Verify recipient permissions and the content to be disclosed, then retain actual access/disclosure evidence. At closure, verify the criteria, remove time-limited permissions and record the disposition of restricted material.

Expected result: Only authorized scope is disclosed and the planned event is fully traceable.

Evidence to retain: Planned blind-break authorization.

Step 6 — Restricted emergency-unblinding event and notification record

For emergency medical unblinding, the investigator or treating physician uses the tested study-specific mechanism immediately when treatment knowledge is needed for care. Confirm only the necessary allocation is disclosed. Record participant, reason, requester, executor, time, information revealed and subsequent notifications; administrative approval must not delay care.

Expected result: Emergency access and backup arrangements are available; care is not delayed and disclosure is documented.

Evidence to retain: Restricted emergency-unblinding event and notification record.

Step 7 — Restricted accidental-disclosure assessment and closure record

For accidental or suspected disclosure, the recipient stops further distribution, preserves access/transfer evidence and notifies the blind custodian through the restricted route. The custodian records what was disclosed, to whom and when. Obtain statistical/medical assessment of bias and participant impact, CDM/IT containment where applicable and QA assessment of significant process failure. Record affected activities, safeguards, required notifications and authorized closure; do not automatically apply the medical-emergency route.

Expected result: Disclosure extent and impact are assessed; corrective actions and remaining restrictions are documented.

Evidence to retain: Restricted accidental-disclosure assessment and closure record.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Emergency clinical unblinding must not await routine administrative approval.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CPROG-P09 — consolidated record packet

Randomization, treatment handling and blind breaks

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Separate treatment-handling and blind-break authorization records

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A	Evidence / exception / reviewer
CPROG-FRM-031 Randomization/Treatment Data Handling Checklist	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CPROG-SOP-022 — Randomization, Treatment Assignment, Unblinding, and Analysis Treatment Variables; CPROG-SOP-033 — Maintaining and Breaking the Blind. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CPROG-P09-F01 — Blind-maintenance plan; role/access matrix; emergency contacts; readiness test and restricted location
CPROG-P09-F02 — Planned authorization: rationale; impacted procedure/process; personnel; content; location; effective date; closure criteria; approving function; required records
CPROG-P09-F03 — Emergency or accidental event: necessary allocation/content; requester/executor; times; recipients; impact; containment; notifications; authorized closure

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Blind protection, communication boundaries and emergency/backup access are demonstrably ready.	☐ Yes ☐ No ☐ N/A
Step 2: Allocation conforms to the approved design and custody is established before use.	☐ Yes ☐ No ☐ N/A
Step 3: Custody and role separation are established before handling treatment information.	☐ Yes ☐ No ☐ N/A
Step 4: Randomization/actual treatment distinctions follow the approved analysis plan.	☐ Yes ☐ No ☐ N/A
Step 5: Only authorized scope is disclosed and the planned event is fully traceable.	☐ Yes ☐ No ☐ N/A
Step 6: Emergency access and backup arrangements are available; care is not delayed and disclosure is documented.	☐ Yes ☐ No ☐ N/A
Step 7: Disclosure extent and impact are assessed; corrective actions and remaining restrictions are documented.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CPROG-P10 — SOP model

Submission metadata, validation and package assembly

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Assemble consistent, traceable submission datasets and supporting metadata.
Scope: Metadata/reviewer-document preparation, validation, reconciliation and package approval. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Approved datasets, guides, authority standards and package manifest. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Submission programmer
Accountable	Programming submission owner
Consulted	Regulatory; biostatistics; independent reviewer
Informed	Affected study team and authorized downstream recipients

Submission programmer performs and documents the work. Programming submission owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Required supporting documents are authored and reviewed against the actual deliverables. Record: Metadata/reviewer documents, scoped review and version approval.
Metadata describes the actual delivered data and references resolve. Record: Metadata and guide QC.
The validation report belongs to the exact package under review. Record: Validator execution record.
Critical unexplained inconsistencies are not dismissed as tool noise. Record: Findings disposition and retest.
Final inventory matches the reviewed package and the receiving team accepts it. Record: Submission package approval and receipt.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Submission programmer performs the sequential instructions in CPROG-P10-WI-01 and retains the specified evidence in CPROG-P10-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. No unexplained critical inconsistencies; validator report is only one QC input.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

When selecting or changing programming standards, tools or environment, use CPROG-P02 — Standards, reusable code and computing environment. Retain the decision or accepted handoff reference in this packet.
For SDTM mapping, checks and release, use CPROG-P03 — SDTM specification through validated release. Retain the decision or accepted handoff reference in this packet.
For analysis derivations and ADaM release, use CPROG-P04 — ADaM derivation through validated release. Retain the decision or accepted handoff reference in this packet.
For output specifications, TFL production and results traceability, use CPROG-P05 — TFL specification, programming and results traceability. Retain the decision or accepted handoff reference in this packet.
Before archiving programming evidence or verifying reconstruction, use CPROG-P11 — Archive and reproducibility. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Programming submission owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the submission metadata and package qc record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CPROG-P10-WI-01. Controlled record packet: CPROG-P10-FRM-01 — Submission metadata and package QC record.

CPROG-P02 — Standards, reusable code and computing environment
CPROG-P03 — SDTM specification through validated release
CPROG-P04 — ADaM derivation through validated release
CPROG-P05 — TFL specification, programming and results traceability
CPROG-P11 — Archive and reproducibility

Original-to-new crosswalk

CPROG-SOP-013 — Define-XML, Annotated CRF, SDRG, ADRG, and Reviewer Guide Development
CPROG-SOP-024 — Regulatory Submission Package Assembly for Clinical Programming Deliverables
CPROG-SOP-025 — Conformance Validation, Pinnacle 21/Validator Findings, and Issue Disposition

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CPROG-P10 — WI execution model

Submission metadata, validation and package assembly

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate approved datasets, guides, authority standards and package manifest. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: Submission programmer performs and documents the work. Programming submission owner owns the process decision and confirms the authorized reviewer and approver for each applicable gate before work begins. Consulted functions provide input within their expertise; consultation does not itself constitute approval. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Programming submission owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Metadata/reviewer documents, scoped review and version approval

The submission programmer prepares applicable define metadata, annotated CRF and reviewer guides from approved specifications and released datasets. Reconcile variable origin, derivations, terminology and dataset relationships; explain relevant limitations and nonconformance dispositions. Obtain statistical/data-owner input for scientific content and regulatory confirmation of package requirements; independently review consistency before assembly.

Expected result: Required supporting documents are authored and reviewed against the actual deliverables.

Evidence to retain: Metadata/reviewer documents, scoped review and version approval.

Step 2 — Metadata and guide QC

Reconcile the final datasets with define metadata, annotated collection information and reviewer guides. Verify dataset/variable names, labels, types and derivations against the manifest.

Expected result: Metadata describes the actual delivered data and references resolve.

Evidence to retain: Metadata and guide QC.

Step 3 — Validator execution record

Run the applicable conformance rules on the candidate package and record validator/tool version, rule set, date and input manifest.

Expected result: The validation report belongs to the exact package under review.

Evidence to retain: Validator execution record.

Step 4 — Findings disposition and retest

Investigate each finding with the relevant data/standards/scientific owner. Correct the package or record a justified reviewed explanation; rerun affected validation.

Expected result: Critical unexplained inconsistencies are not dismissed as tool noise.

Evidence to retain: Findings disposition and retest.

Step 5 — Submission package approval and receipt

Assemble the final package, reconcile inventory and verify file/link readability. Obtain programming and applicable regulatory authorization before transfer.

Expected result: Final inventory matches the reviewed package and the receiving team accepts it.

Evidence to retain: Submission package approval and receipt.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: No unexplained critical inconsistencies; validator report is only one QC input.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CPROG-P10 — consolidated record packet

Submission metadata, validation and package assembly

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Submission metadata and package QC record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A
CPROG-FRM-018 Define-XML QC Checklist	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-019 SDRG/ADRG Review Checklist	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-033 Submission Programming Package Checklist	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-034 Study Data Package Inventory	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-035 Validation Findings Disposition Log	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-036 Pinnacle 21/Validator Run Record	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CPROG-SOP-013 — Define-XML, Annotated CRF, SDRG, ADRG, and Reviewer Guide Development; CPROG-SOP-024 — Regulatory Submission Package Assembly for Clinical Programming Deliverables; CPROG-SOP-025 — Conformance Validation, Pinnacle 21/Validator Findings, and Issue Disposition. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CPROG-P10-F01 — Dataset/metadata/guide versions; inventory; applicable standard/rule set; validator version
CPROG-P10-F02 — Finding ID; correction or scientific disposition; rerun; link/readability check; transfer approval

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Required supporting documents are authored and reviewed against the actual deliverables.	☐ Yes ☐ No ☐ N/A
Step 2: Metadata describes the actual delivered data and references resolve.	☐ Yes ☐ No ☐ N/A
Step 3: The validation report belongs to the exact package under review.	☐ Yes ☐ No ☐ N/A
Step 4: Critical unexplained inconsistencies are not dismissed as tool noise.	☐ Yes ☐ No ☐ N/A
Step 5: Final inventory matches the reviewed package and the receiving team accepts it.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CPROG-P11 — SOP model

Archive and reproducibility

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Preserve programming evidence sufficient to retrieve and reconstruct released analyses.
Scope: Archive collection, dependency capture, reconstruction verification, custody and retention. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Final manifest, retention schedule and environment records. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Programming records coordinator
Accountable	Sponsor programming owner
Consulted	IT; quality assurance; biostatistics
Informed	Affected study team and authorized downstream recipients

The programming records coordinator collects the released baseline and dependency information. A qualified reviewer independently tests retrieval/reconstruction of the selected analysis. The programming owner accepts completeness and resolves limitations; the records custodian accepts custody and retention arrangements. IT supports environment recovery without placing credentials in the archive. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

An independent person can follow the lineage from output back to authorized inputs. Record: Archive inventory and lineage check.
Reconstruction information is sufficient and credentials remain protected. Record: Environment and reconstruction record.
Retrieval succeeds and material reproduction differences are resolved or explained. Record: Retrieval/reproducibility test.
Required records remain readable and accessible for their retention period. Record: Archive acceptance and decommission handoff.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Programming records coordinator performs the sequential instructions in CPROG-P11-WI-01 and retains the specified evidence in CPROG-P11-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. Superseded versions remain identifiable; no deletion under hold.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

Before operational closeout or system decommissioning, use COPS-P12 — Closeout, records retention and decommissioning. Retain the decision or accepted handoff reference in this packet.
For data-management record retrieval, archive or authorized disclosure, use CDM-P10 — Records, inspection, archive and authorized sharing. Retain the decision or accepted handoff reference in this packet.
Before programming production and release, use CPROG-P06 — Data intake, independent QC and production release. Retain the decision or accepted handoff reference in this packet.
When assembling submission metadata and deliverables, use CPROG-P10 — Submission metadata, validation and package assembly. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

6. Records and effectiveness

Retain the archive and reconstruction record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CPROG-P11-WI-01. Controlled record packet: CPROG-P11-FRM-01 — Archive and reconstruction record.

COPS-P12 — Closeout, records retention and decommissioning
CDM-P10 — Records, inspection, archive and authorized sharing
CPROG-P06 — Data intake, independent QC and production release
CPROG-P10 — Submission metadata, validation and package assembly

Original-to-new crosswalk

CPROG-SOP-028 — Program Documentation, Records Management, Archival, and Retention

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CPROG-P11 — WI execution model

Archive and reproducibility

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate final manifest, retention schedule and environment records. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The programming records coordinator collects the released baseline and dependency information. A qualified reviewer independently tests retrieval/reconstruction of the selected analysis. The programming owner accepts completeness and resolves limitations; the records custodian accepts custody and retention arrangements. IT supports environment recovery without placing credentials in the archive. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Sponsor programming owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Archive inventory and lineage check

Collect the released input, specification, program, log, QC, approval and output versions. Compare them with the final manifest and identify missing links.

Expected result: An independent person can follow the lineage from output back to authorized inputs.

Evidence to retain: Archive inventory and lineage check.

Step 2 — Environment and reconstruction record

Capture software/package versions, dependencies, run order and required configuration without copying secrets into the archive index.

Expected result: Reconstruction information is sufficient and credentials remain protected.

Evidence to retain: Environment and reconstruction record.

Step 3 — Retrieval/reproducibility test

Ask an authorized reviewer to retrieve a risk-based sample and reconstruct selected results in the approved environment. Record expected versus actual results and differences.

Expected result: Retrieval succeeds and material reproduction differences are resolved or explained.

Evidence to retain: Retrieval/reproducibility test.

Step 4 — Archive acceptance and decommission handoff

Transfer archive custody with access restrictions, retention/hold requirements and ownership. Obtain acceptance before retiring working infrastructure.

Expected result: Required records remain readable and accessible for their retention period.

Evidence to retain: Archive acceptance and decommission handoff.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: Superseded versions remain identifiable; no deletion under hold.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CPROG-P11 — consolidated record packet

Archive and reproducibility

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Archive and reconstruction record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A	Evidence / exception / reviewer
CPROG-FRM-041 Programming Archive Checklist	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CPROG-SOP-028 — Program Documentation, Records Management, Archival, and Retention. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CPROG-P11-F01 — Input/code/output/log/QC/approval manifest; software/dependencies; run order
CPROG-P11-F02 — Retrieved sample; reconstruction expected/actual result; discrepancy; receiving custodian; hold/retention

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: An independent person can follow the lineage from output back to authorized inputs.	☐ Yes ☐ No ☐ N/A
Step 2: Reconstruction information is sufficient and credentials remain protected.	☐ Yes ☐ No ☐ N/A
Step 3: Retrieval succeeds and material reproduction differences are resolved or explained.	☐ Yes ☐ No ☐ N/A
Step 4: Required records remain readable and accessible for their retention period.	☐ Yes ☐ No ☐ N/A

Vendor-neutral model • adoption version 1.4

CPROG-P12 — SOP model

Privacy and external data sharing

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

1. Purpose and process boundary

Purpose: Release data only for authorized purposes with appropriate disclosure controls.
Scope: Sharing requests, authorization, privacy transformation, independent checks and transfer. Applies to personnel and contracted providers assigned these activities; delegated execution does not remove sponsor oversight.

2. Initiation and prerequisites

The responsible role opens the process when an approved study milestone, new request, material change, scheduled review or exception triggers work. Confirm current versions of: Approved request, intended use and data-use restrictions. Record scope, study identifier, applicable jurisdictions, intended use, deliverables and exclusions. Missing prerequisites are assigned for resolution before the affected activity proceeds, subject to an authorized emergency pathway.

3. Responsibility and interfaces

Responsible	Data sharing coordinator
Accountable	Sponsor data/privacy owner
Consulted	Legal; privacy; biostatistics; independent reviewer
Informed	Affected study team and authorized downstream recipients

The sharing coordinator assembles the request and delivery evidence. The data owner authorizes purpose and permitted use. The designated privacy/legal reviewer assesses applicable disclosure restrictions and re-identification risk. A qualified independent reviewer verifies the transformation and package; the authorized release owner confirms recipient, restrictions and secure transfer. Document assigned individuals and justified role combinations. Required independent review remains separate from authorship.

4. Process-specific requirements

Purpose and permitted scope are established; unnecessary data is excluded. Record: Data sharing authorization.
Pseudonymized data is not labeled anonymous merely because names were removed. Record: De-identification specification and risk assessment.
No unexplained disclosure finding remains and recipient restrictions are documented. Record: Privacy QC and release approval.
Only the approved recipient receives the approved version. Record: Transfer, acknowledgment and access/retention record.

Required control gates

Readiness: scope, inputs, access, competence and applicable plan are approved.
Execution: Data sharing coordinator performs the sequential instructions in CPROG-P12-WI-01 and retains the specified evidence in CPROG-P12-FRM-01.
Review: check completeness, accuracy, traceability and exceptions against risk-based acceptance criteria. De-identification is contextual; do not equate pseudonymization with anonymity.
Release: the authorized approver identifies exact package versions, allowed use and recipients. The receiver acknowledges the accepted baseline.
Closure: verify action closure or documented permitted conditions, retain evidence, update status and transfer custody.

Apply related procedures at these transitions

For data-management record retrieval, archive or authorized disclosure, use CDM-P10 — Records, inspection, archive and authorized sharing. Retain the decision or accepted handoff reference in this packet.
When integrating or converting heterogeneous or legacy data, use CPROG-P07 — Integrated, real-world and legacy data programming. Retain the decision or accepted handoff reference in this packet.
When treatment information or blinding may be affected, use CPROG-P09 — Randomization, treatment handling and blind breaks. Retain the decision or accepted handoff reference in this packet.
Before archiving programming evidence or verifying reconstruction, use CPROG-P11 — Archive and reproducibility. Retain the decision or accepted handoff reference in this packet.

5. Exceptions and escalation

Preserve the failed result and notify Sponsor data/privacy owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay. Consult medical, safety, quality, security or regulatory personnel according to the actual impact and study escalation arrangements. Record applicable reporting decisions and timelines.

6. Records and effectiveness

Retain the data sharing and privacy review record, inputs, relevant execution evidence, QC results, decisions, approvals and handoff acknowledgment in authorized repositories. Follow the essential-record filing plan; detailed technical working evidence need not all be copied into the TMF. Monitor overdue significant issues, repeat defects, rejected handoffs and retrieval/reconstruction failures. Escalate adverse trends and assess CAPA effectiveness.

7. References used in this SOP

Execution WI: CPROG-P12-WI-01. Controlled record packet: CPROG-P12-FRM-01 — Data sharing and privacy review record.

CDM-P10 — Records, inspection, archive and authorized sharing
CPROG-P07 — Integrated, real-world and legacy data programming
CPROG-P09 — Randomization, treatment handling and blind breaks
CPROG-P11 — Archive and reproducibility

Original-to-new crosswalk

CPROG-SOP-030 — Privacy, De-Identification, Controlled Access, and External Data Sharing for Programming Deliverables

These source catalog topics are incorporated into this process boundary. Effective source text and field-level controls must be reconciled before controlled retirement.

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Vendor-neutral model • adoption version 1.4

CPROG-P12 — WI execution model

Privacy and external data sharing

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Before you start

Open the approved study workspace using your individual authorized account. Confirm your role and training. Record the system name/version and workspace path on the record cover.
Create a working copy of the record packet. Enter study ID, process ID, request/cut identifier, owner, date, version and intended recipients.
Locate approved request, intended use and data-use restrictions. Record each document or dataset version and repository link. Check that author and reviewer use the same baseline; resolve mismatches before continuing.
Open the required modules listed below. Select applicable modules, justify N/A items, and retain separate restricted/approval records rather than flattening them into a general log.

Perform the work

Execution and review: The sharing coordinator assembles the request and delivery evidence. The data owner authorizes purpose and permitted use. The designated privacy/legal reviewer assesses applicable disclosure restrictions and re-identification risk. A qualified independent reviewer verifies the transformation and package; the authorized release owner confirms recipient, restrictions and secure transfer. For each step, retain the executor/date, relevant versions and retrievable evidence reference. Preserve the failed result and notify Sponsor data/privacy owner or the designated backup. Record impact, action owner and disposition. Do not proceed past the affected gate until its acceptance criteria are met or a permitted noncritical condition is authorized. Urgent safety actions follow their emergency pathway without delay.

Step 1 — Data sharing authorization

Record the requester, intended use, recipients, requested variables and permissions. Obtain authorized data-owner/privacy review before preparing an extract.

Expected result: Purpose and permitted scope are established; unnecessary data is excluded.

Evidence to retain: Data sharing authorization.

Step 2 — De-identification specification and risk assessment

Apply the approved de-identification method to the authorized copy, including dates, rare attributes, free text and metadata as appropriate. Assess residual risk in the release context.

Expected result: Pseudonymized data is not labeled anonymous merely because names were removed.

Evidence to retain: De-identification specification and risk assessment.

Step 3 — Privacy QC and release approval

Have an independent qualified reviewer inspect the exact outgoing package and test the defined disclosure checks. Correct failures and reassess utility and risk.

Expected result: No unexplained disclosure finding remains and recipient restrictions are documented.

Evidence to retain: Privacy QC and release approval.

Step 4 — Transfer, acknowledgment and access/retention record

Transfer through the approved channel under the applicable agreement, log the package and obtain receipt. Retain source custody and track permitted use/end-of-access obligations.

Expected result: Only the approved recipient receives the approved version.

Evidence to retain: Transfer, acknowledgment and access/retention record.

Review, hand off and close

Reconcile the packet manifest against all required modules and outputs. Verify versions, access restrictions, missing evidence and unresolved items. Apply the gate: De-identification is contextual; do not equate pseudonymization with anonymity.
Send the exact candidate package to the designated reviewer. Record reviewer identity, date, scope, method, findings and conclusion. Correct findings through a versioned revision and repeat affected checks.
Obtain approval of the reviewed version. Transfer through the authorized channel; record recipients, date, manifest and acknowledgment. Escalate rejected or missing receipt.
File evidence in the defined repository. Put required essential records or reference links in the TMF per filing plan. Record completion with a link to the approved evidence.

System-specific adoption check

Vendor-neutral model • adoption version 1.4

CPROG-P12 — consolidated record packet

Privacy and external data sharing

Status	Model for controlled adoption — not effective or approved
Document ID / version / effective date	________________ / ________________ / ________________
Owner / approver / review date	________________ / ________________ / ________________

Data sharing and privacy review record

Study / project ID
Packet ID / version / date
Purpose / authorized scope / intended use
Input versions / cut date / repository links
Executor / reviewer / approver
System / software version / workspace
Applicable jurisdictions / deadlines
Output manifest / recipients / evidence location

Module register and completion checks

Source / retained module	Applicable? Yes / No	Complete? Yes / No / N/A	Evidence / exception / reviewer
CPROG-FRM-044 Data Sharing Request and De-Identification Checklist	□ Yes □ No	□ Yes □ No □ N/A
CPROG-FRM-045 External Data Transfer Log	□ Yes □ No	□ Yes □ No □ N/A

Additional source-specific checks

Criterion / expected result	Actual result / evidence link	Yes / No / N/A and rationale	Reviewer / date
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A
		□ Yes □ No □ N/A

Exceptions, decisions and release

Issue / impact / affected version
Containment / notification / reporting assessment
Action owner / due date / closure evidence
Decision: rejected / rework / approved / permitted noncritical conditions
Exact released version / manifest / recipients
Receiving owner acknowledgment / date
Archive location / access / retention owner

Review and approval

Enter approver names only after the organization assigns authority; leave signatures and dates blank until actual review and approval occur.

Role	Name / signature or linked approval	Date / version / conclusion
Author
Independent reviewer, where required
Authorized approver

Do not prepopulate names or signatures. An approval must identify the exact controlled version. Retain superseded records and revision history.

Required record details

Incorporates CPROG-SOP-030 — Privacy, De-Identification, Controlled Access, and External Data Sharing for Programming Deliverables. Use the existing evidence reference when information is already controlled elsewhere. Complete separate instances for decisions with different approvers, access restrictions or timing. These fields support the model; they do not certify equivalence to every source-package form.

Field group / required details	Value or exact controlled record reference
CPROG-P12-F01 — Purpose/recipient/legal or permission basis; variables; de-identification method; residual risk
CPROG-P12-F02 — Independent disclosure check; approved package/restrictions; transfer receipt; end-of-access disposition

Execution acceptance and decision evidence

Required check / WI step	Result	Evidence / No or N/A rationale / reviewer and date
Step 1: Purpose and permitted scope are established; unnecessary data is excluded.	☐ Yes ☐ No ☐ N/A
Step 2: Pseudonymized data is not labeled anonymous merely because names were removed.	☐ Yes ☐ No ☐ N/A
Step 3: No unexplained disclosure finding remains and recipient restrictions are documented.	☐ Yes ☐ No ☐ N/A
Step 4: Only the approved recipient receives the approved version.	☐ Yes ☐ No ☐ N/A

Abbreviation legend

SOP	Standard operating procedure
WI	Work instruction
FRM	Form or controlled record template
TRK	Tracker
COPS	Clinical operations
CDM	Clinical data management
CPROG	Clinical programming
RACI	Responsible, Accountable, Consulted, Informed
R	Responsible: performs the activity
A	Accountable: owns the decision and outcome
C	Consulted: provides required input
I	Informed: receives the decision
QMS	Quality management system
QA	Quality assurance
QC	Quality control
CAPA	Corrective and preventive action
CTQ	Critical to quality
GCP	Good clinical practice
ICH	International Council for Harmonisation
CRO	Contract research organization
FSP	Functional service provider
TMF	Trial master file
eTMF	Electronic trial master file
CRF	Case report form
eCRF	Electronic case report form
EDC	Electronic data capture
CDMS	Clinical data management system
DMP	Data management plan
UAT	User acceptance testing
SDV	Source data verification
SDR	Source data review
SAP	Statistical analysis plan
SDTM	Study Data Tabulation Model
ADaM	Analysis Data Model
CDISC	Clinical Data Interchange Standards Consortium
CDASH	Clinical Data Acquisition Standards Harmonization
TFL	Tables, figures and listings
SDRG	Study Data Reviewer's Guide
ADRG	Analysis Data Reviewer's Guide
DMC	Data monitoring committee
IDMC	Independent data monitoring committee
DSMB	Data and safety monitoring board
AE	Adverse event
SAE	Serious adverse event
IRB	Institutional review board
EC	Ethics committee
ICF	Informed consent form
IP	Investigational product
IRT	Interactive response technology
eCOA	Electronic clinical outcome assessment
KRI	Key risk indicator
QTL	Quality tolerance limit
RWE	Real-world evidence
CSR	Clinical study report
PK	Pharmacokinetics
PD	Pharmacodynamics
ECG	Electrocardiogram
SIV	Site initiation visit
MedDRA	Medical Dictionary for Regulatory Activities
WHODrug	WHO Drug Dictionary
IT	Information technology
N/A	Not applicable; documented rationale required

Research basis

Original process synthesis informed by the following primary references. Public company material is illustrative and does not imply access to private SOPs, endorsement or compliance certification. Verify jurisdiction-specific adoption and reference editions at controlled release; draft guidance is not automatically an effective requirement.

FDA E6(R3), final September 2025 — Risk-proportionate lifecycle governance, sponsor oversight and reliable records.
FDA electronic systems guidance, October 2024 — Electronic evidence, trustworthy systems and signature controls.
CDISC foundational standards — Collection, tabulation, analysis and metadata continuity.
CDISC ADaM — Analysis traceability.
SCDM GCDMP — Data management reference framework; verify individual chapter editions before adoption.
TransCelerate risk-based monitoring model — Industry example of risk assessment linked to monitoring.
Pfizer global clinical trial standards — Public sponsor example: retained oversight of outsourced trial activities.
Roche clinical study information policy — Public sponsor example of governed information access.
FDA BIMO sponsor/CRO inspection program — Inspection perspective on sponsor and CRO evidence.
FDA risk-based monitoring Q&A, April 2023 — Monitoring planning and follow-up reference.