Change Control & Upgrades — Release Governance

Why this matters

Every change to an Electronic Data Capture (EDC) system can affect data integrity, subject safety, and blinding. Change control makes sure we understand the impact, verify that the system still works for its intended purpose, and can recover if something goes wrong.

Quick definitions (used throughout)

• Change control: The documented process that keeps a validated system validated: every change (vendor upgrade or study build) is requested, assessed, approved, tested, released and recorded.
• Blinding: Keeping treatment assignment hidden from certain users to prevent bias.
• Audit trail: Automatic, tamper‑evident log of who entered or changed what, when and why (old and new values, reason for change); no user can edit or switch it off.
• CSV: Computer System Validation — documented evidence the system is fit for intended use under GxP (regulated) conditions.
• UAT: User Acceptance Testing — end‑user checks the system meets business needs; not the whole of validation.
• CCG: CRF Completion Guidelines (how sites enter data).
• Roles (who you’ll loop in): Data Management (DM), Biostatistics, Pharmacovigilance (PV), Clinical Operations/CRAs, and IT/Quality/CSV.

Inspections often probe how you controlled change, not just the final outcome. Good release governance makes inspections… boring (the best kind).

Impact assessment

Before building or scheduling anything, capture what changes and who/what is affected.

1) Classify the change

• Config (forms, edit checks, roles, workflows)
• Code (custom functions, calculated fields, external apps)
• Integration (e.g., lab feed, ePRO/eDiary (electronic patient‑reported outcomes), IWRS/RTSM (randomization and trial supply systems))
• Infrastructure (EDC version/patch, database engine, OS, hosting)
• Data migration (new fields, derivations, historical loads)

2) Identify risk areas

• Blinding/access: Could new fields, queries, or reports reveal treatment? Do role changes drift from least‑privilege?
• Data integrity: Audit‑trail coverage, edit checks, calculations, derived endpoints, and data already entered (re‑fired checks and new queries, recalculated values, reset signatures or source‑verified status).
• Interoperability: File formats, keys, timezone/units, API versions.
• Performance/availability: Page loads, batch jobs, peak hours.
• Compliance: 21 CFR Part 11 controls (unique IDs, e‑sigs), SOP alignment, vendor release notes with known issues.

3) Stakeholders & approvals

• DM (owner), Biostats (derivations/analysis impact), PV (SAE flows), CRA/ClinOps (site workflows), IT/CSV/QA (validation governance).
• Outcome: Impact Assessment document with risk rating, required testing, training, comms, and go/no‑go criteria.

4) Decide the path

• No‑impact / low‑risk config → limited regression + targeted UAT.
• Moderate/high‑risk (blinding, data model, infrastructure) → full validation plan, restore/rollback rehearsal, broader regression.

Validation & evidence

Validation is not about perfection; it’s about documented confidence that the system is fit for intended use after the change. For a hosted EDC release, the vendor’s testing covers the platform; the sponsor reviews it and still tests its own study configuration.

Plan the testing

• Traceability: Map requirements → risks → tests (requirements traceability matrix, RTM).
• Regression scope: Cover critical paths (create/modify/lock records, queries, roles, exports, reports, integrations).
• Negative tests: Prove the system prevents what it must (e.g., blinded user cannot see treatment; invalid dates rejected).
• Edge cases: Timezones/units, nulls/missing, boundary values, paused visits, screen failures.
• Security/access: Role re‑validation, e‑sig behaviors, password/session rules.
• Who and where: Pre‑approved scripts with expected results, run in a validation/UAT environment on test data by testers other than the people who built the change.

Capture the evidence

• Failed tests must be recorded (kept, never overwritten), with defect IDs, screenshots/logs, and re‑test results. Auditors look for how you handled what went wrong. A minor defect open at go‑live is risk‑assessed and accepted in writing; one affecting data integrity, audit trail, blinding or safety is fixed and re‑tested before go‑live.
• Versioned test assets: Test scripts/cases, datasets, expected results, and actuals.
• Snapshots around upgrades: Export configs, key lists (roles, codelists), and audit‑trail entries before/after.
• Restore proof (if DB/EDC upgraded): Show the pre‑deployment backup restores (your rollback route) and, after go‑live, that a backup of the new version restores with audit trails and e‑signatures intact (smoke tests + data checks).
• Sign‑offs: Tester(s), DM lead, QA/CSV.

Don’t forget data & analysis

• Re‑run critical exports; diff record counts and key fields.
• Confirm derived endpoints still compute as expected; document any statistical analysis impacts for Biostats.

Deployment & rollback

Treat release like a mini‑operation with a checklisted flow.

Before the window

• Choose the window: a low‑activity time across sites’ time zones, agreed with the vendor, clear of data cuts, interim analyses and database lock (defer non‑urgent changes).
• Stage → Prod (staging to production) with like‑for‑like configs; dry run deployment.
• Pre‑checks: Backups complete and restore tested; vendor release notes reviewed; known issues documented with workarounds.
• Pre‑deploy comms: What changes, who’s impacted, downtime, training links, support channel, help‑desk hours.
• Training: Update the CCG (new version, effective date) and short job aids/videos where needed; affected users are trained, with records, before go‑live and do not use changed functions until trained.

During the window

• Freeze non‑essential activities.
• Deploy with two‑person rule for steps that affect blinding/access.
• Keep a runbook: exact steps, timestamps, who executed each step.

After the window

• Smoke tests (live; read‑only, or on a designated test site or test subject excluded from study exports, never real subjects’ records): login, create/edit a test CRF, trigger a common query on it, run a key export/report, confirm a blinded role still cannot see treatment, sanity‑check integration feeds.
• Hypercare: Dedicated support for 24–72 hours; monitor error logs and dashboards.
• Rollback criteria: Define in advance (e.g., repeated HTTP 500 server errors, data corruption, unblinding risk).
• Rollback steps: Restore procedure, cache flush, re‑point integrations, site notification template. Restoring the pre‑deployment backup loses later entries, so decide before sites are let back in; after that, fix forward or roll back without losing their data and audit trail.

Pitfalls & misconceptions

• “UAT = validation.” UAT is necessary but not sufficient; you need risk‑based regression, negative testing, and traceability.
• “We have backups, so we’re fine.” Without a tested restore, you don’t know you can use them.
• Unverified permissions after changes. Role drift can silently unblind a study or expose protected health information (PHI).
• Skipping audit‑trail checks. Upgrades can alter logging behavior or timestamps.
• No communication plan. Even good changes fail if sites are surprised or lack updated CCGs.
• Ignoring vendor “known issues.” Document them and plan mitigations.

Practice in the wild (checklist)

• Impact assessment completed, risks rated (blinding/access, data integrity, integration, performance).
• Stakeholders reviewed (DM, Biostats, PV, CRA/ClinOps, IT/CSV/QA) and signed off.
• Validation plan with traceability (requirements → tests).
• Negative/edge tests included for access and blinding.
• Failed tests logged, defects tracked, re‑tests passed with evidence.
• Backup taken and restore test report attached for DB/EDC upgrades.
• Stage→Prod runbook rehearsed; exact deployment steps documented.
• Pre‑deploy comms sent with downtime, changes, and training/CCG links.
• Post‑deploy smoke tests passed; hypercare monitoring in place.
• Rollback criteria & steps documented and ready.

Worked examples

Example 1 — Patch upgrade of the EDC application (low/medium risk)

Scenario: Vendor releases 2023.1.5 “patch” claiming performance fixes; no schema changes.

Risks: Edit‑check timing, audit‑trail log format, report rendering, unexpected downtime.

Minimum controls:

• Impact assessment cites vendor notes; risks logged with mitigations.
• Regression tests on critical paths: login, CRF save, query open/close, export, role switch, audit‑trail search.
• Negative test: blinded user cannot access treatment field/report.
• Restore rehearsal on a non‑production (lower) environment and documented steps for Prod.

Pass signals: All smoke tests pass, no new errors in logs after 48 hours, performance stable.

Artifacts: Impact Assessment, Test scripts/results (including any failures + re‑tests), Backup/Restore report, Go‑Live email.

Example 2 — Edit check change on a safety field (medium risk)

Scenario: Tighten SAE onset date rule to catch future‑dated entries.

Risks: Blocking urgent data entry at sites; new queries on existing records; PV reconciliation.

Minimum controls:

• Requirements specify rule logic (checked against the site’s local date, so a same‑day onset passes) and that it flags a future date for correction without blocking the SAE form from being saved. SAE reporting never waits on EDC: the site reports to PV directly (e.g., paper SAE form if EDC is down).
• Tests include edge dates, timezones, and negative attempts.
• Communication: CCG update with screen examples; PV alerted to initial query spikes.

Pass signals: No unexpected blocks; PV confirms SAE flow unaffected; initial query spike resolves within a week.

Artifacts: Updated CCG, test evidence, site comms, monitoring plan.

Example 3 — Role/permission refactor in a blinded study (high risk)

Scenario: Consolidate “Site Coordinator” and “Site Enterer” roles.

Risks: Unblinding via reports, exports, or hidden form items; e‑sig scope changes.

Minimum controls:

• Matrix review: each role vs. each object (forms, reports, exports).
• Who gets the merged role: only users who need its rights (per the delegation log), trained on new rights first; casebook e‑signing stays with the investigator.
• Role login test: in the test environment, log in with a test account for each role (never another user’s account) and attempt to view treatment or unblinded fields.
• Report/export review: confirm filter defaults and row‑level security.
• Two‑person review during deployment steps touching permissions.

Pass signals: No blinded content visible to site roles; e‑sig behavior unchanged; audit‑trail shows correct role after switch.

Artifacts: Role matrix, test videos/screenshots, sign‑offs, targeted site messaging.

Example 4 — Integration version bump (labs feed) with unit normalization (medium/high risk)

Scenario: Lab vendor updates file to include SI units; system now maps to both conventional and SI.

Risks: Wrong unit conversions, broken edit checks, derived endpoints shifting.

Minimum controls:

• Mapping spec with units table and examples for high/low/critical values.
• Tests on conversion math (e.g., creatinine 1.2 mg/dL × 88.4 = 106 µmol/L), flag propagation, and negative (mismatched units rejected to an error report; the lab vendor corrects and re‑sends).
• Biostats review on derived variables; data cuts compared before/after.

Pass signals: Concordance within tolerance on a parallel run (old and new mapping on the same files); no unexpected out‑of‑range bursts.

Artifacts: Final mapping spec, parallel‑run results, validation packet, comms to DM/Stats.

Key points to remember

• Start with an impact assessment. Classify the change (config, code, integration, infrastructure, data migration), rate risks (blinding/access, data integrity, interoperability, performance, compliance), identify stakeholders (DM, Biostats, PV, CRA/ClinOps, IT/CSV/QA), and set clear go/no‑go criteria.
• Validate fitness for intended use. Build a traceability matrix (requirements → risks → tests), scope risk‑based regression on critical paths, and include negative and edge‑case testing (roles/e‑sigs, timezones, units, boundary values).
• Evidence is the product. Record failed tests with defect IDs and logs/screenshots, document re‑tests, and version all test assets. Snapshot key configs and audit‑trail entries before/after changes.
• Protect blinding and least‑privilege access. Review role/permission matrices across forms, reports, and exports; log in with a test account for each role to prove blinded users cannot see treatment; apply a two‑person rule for permission changes; confirm audit‑trail behavior.
• Backups must be restore‑tested. For upgrades that touch data or platforms, take backups and demonstrate a successful restore on a like‑for‑like environment, with smoke‑test evidence.
• Deploy deliberately. Pick a low‑activity window clear of data cuts, interim analyses and lock; rehearse a Stage→Prod runbook; freeze non‑essential activities during the window; issue pre‑deploy comms (what changes, who’s impacted, downtime); update CCG/job aids as needed and train affected users before go‑live.
• Verify live and monitor. After deployment, run smoke tests, read‑only or on a test site or test subject and never on real subjects’ records (login, CRF create/edit, queries, exports/reports, integrations, blinded roles still unable to see treatment). Establish hypercare for 24–72 hours with log/error monitoring.
• Plan for rollback. Define objective rollback criteria in advance and keep step‑by‑step procedures ready (restore, cache flush, re‑point integrations, site notification); make the call before sites are let back in, because restoring the pre‑deployment backup loses later entries.
• Check data and analysis impacts. Re‑run critical exports and compare counts/key fields; confirm derived endpoints behave as expected; involve Biostats when calculations/units change.
• Stay compliant and vendor‑aware. Align with SOPs and Part 11 controls (unique IDs, e‑sigs, password/session rules). Review vendor release notes/known issues and document mitigations.