Data Quality and Data Management

At 09:41 on a Tuesday, a study nurse inflates a cuff and reads a participant's blood pressure: 142 over 91. Follow that number. Within the hour it is written down; within a week, typed into a database; within a month, questioned by a stranger in another city. It will be corrected, transferred between systems, frozen at analysis, archived — and, decades from now, deliberately destroyed. Almost everyone who touches it will never meet the participant whose artery it came from.

That journey is this module's subject. A trial's answer is only as good as its numbers, and the participant accepted real risk on the promise that those numbers would be handled honestly. Data management is how a site keeps that promise after the cuff comes off.

The route: the standard every record answers to; the systems that must be sound before the first entry; then the life cycle in order — capture, recording, review, correction, movement and the lock, and the afterlife of storage and destruction. Last, the person inside the data: codes, anonymisation, breach response.

Learning Objectives

After this module, you can:

• Hold any trial record to the E6(R3) standard: attributable, legible, contemporaneous, original, accurate and complete
• Judge whether a computerised system is fit for a trial — validated before use, released only after approval, secured, every user individually accountable
• Capture and record data cleanly: source records defined before the trial, transcription minimised, the reported data consistent with source
• Work the data's review cycle: answer queries from source, correct errors through the audit trail, and treat the lock as final
• Protect the person inside the data: store and destroy data and samples lawfully, guard the code, and act on a breach

The Standard the Whole Cycle Answers To

Six words decide whether anything this trial records can later be believed. E6(R3) requires source records to be attributable, legible, contemporaneous, original, accurate and complete — the standard Module 11 introduced at the data's birthplace, now held to at every later station. ICH E6(R3)

Each word is a working test, not a slogan. The first two:

• Attributable — the record says who made it. An entry nobody signed is a claim nobody made. The failure is borrowed identity: a nurse charts a reading in a colleague's open session, and the trial now asserts, permanently, that the wrong person observed it. Accuracy does not repair that — nobody can vouch for a value whose witness is misnamed.
• Legible — readable by someone else, years later, media regardless. The failure is rarely dramatic: a cramped abbreviation only its author could expand, a fax faded to grey, a file format nothing at the site still opens. A record that has to be guessed at is evidence lost in place.

The remaining four:

• Contemporaneous — written when it happened, not reconstructed afterwards. The failure mode is the honest Friday afternoon: charting Tuesday's assessment from memory, three days of other participants in between. The values may even be right — but nothing can show they are, and showing is the property's whole job.

• Original — the first capture, or a verified copy of it; never a retyped substitute passing as the first. The failure is tidiness: a coordinator rewrites a messy worksheet "clean", files the pretty version, and bins the real one. The trial's actual first capture is now in the wastepaper — and no signature on the clean copy can resurrect it.

• Accurate — it matches what happened. The failure arrives through small frictions: a transposed digit, the wrong participant's row, a unit conversion done in the head. One wrong systolic value can move a participant across an eligibility line nobody meant to cross — and an eligibility error harms a real person, not just a dataset.

• Complete — nothing relevant missing: the changes, the context, the unfavourable values too. The failure is selective memory: the repeat measurement that "didn't count", the abandoned questionnaire never mentioned, the correction made without its reason. A record trimmed to look good has stopped being a record of what happened.

Changes are allowed; data work would be impossible otherwise. But a change must be traceable, must never obscure the original entry, and is explained where necessary through an audit trail ICH E6(R3) — the mechanism this module's correction section owns.

You will meet the label ALCOA+ in SOPs, sponsor manuals and inspection reports. Be precise about what it is: E6(R3) itself never uses the label — the guideline's own wording is the six properties above, and its definition of data integrity adds that data should also be secure and reliable, such that they are fit for purpose. The "+" attributes beyond these — consistent, enduring, available — come from wider regulatory guidance, not from the R3 text, so this course anchors to the standard as R3 words it. ICH E6(R3)

Before the First Data Point: The System Must Already Be Sound

By the time a trial collects its first blood pressure, whether its data can be trusted is already half-decided. E6(R3)'s data-governance section asks investigators and sponsors for documented processes across the whole data life cycle, proportionate to the risks to participants and the reliability of the results. ICH E6(R3) That is Module 8's proportionality principle, applied to data.

The central obligation is validation: the documented demonstration that a computerised system does what the trial needs it to do, consistently, from design until decommissioning. Validation is risk-based, scaled to the system's intended use and its power to affect participants and results. And it covers what actually runs in your trial, not just the vendor's product: the protocol-specific configurations, the automated checks and calculations, the interfaces between systems. Critical functionality — randomisation, dosing, endpoint data — gets the closest attention. ICH E6(R3)

The sponsor's side of the bargain: data acquisition tools fit for purpose, validated and ready before their required use. What the trial collects, and how, is pre-specified in the protocol. The operational detail, including a data flow diagram where needed, lives in a protocol-related document; the guideline's own example is a data management plan. Where a sponsor-investigator runs the trial, both halves of the bargain are yours. ICH E6(R3)

Three more duties frame the start. A trial-specific system is released for a site only after that site's approvals are in place — going live is a regulated event, not an IT convenience. Everyone using a system is trained in it. And security is managed for the whole life cycle: authentication and password rules, patching, monitoring, backup and disaster recovery — tested periodically, not assumed. ICH E6(R3)

One duty decides whether attributable survives contact with a busy ward: user management. Access controls limit systems to authorised users and tie every action to an individual. Permissions follow a person's duties, their organisation, and the blinding arrangements; they are revoked when no longer needed, reviewed periodically, and documented with dates. The site owes its share: secure, attributable access on its own systems, and prompt word to the sponsor when someone's access to a sponsor system must change or end. ICH E6(R3)

Capture: Where a Datum Is Born

Back to 09:41 on Tuesday. The cuff deflates, the monitor shows 142/91, and the nurse writes it in the ward's observation chart. The trial's copy of the truth now exists in exactly one place. That first capture is a source record — and as Module 11 taught, your site defined before the trial what its source records are and where they live. E6(R3) adds the operational half: the methods of data capture are defined up front too, and updated when they change. How a number is born decides how much can go wrong later. ICH E6(R3)

The craft of writing records that pass the six-property standard has a working name in every quality system: Good Documentation Practice. The label comes from the wider GxP world — shorthand for the family of "good practice" quality regimes, GMP and GCP among them; in R3 terms it is simply §2.12.2 applied at the moment of writing. Record as it happens. Date what you write, with your identity attached. Never obliterate — a wrong value is corrected, not erased. And never let an uncontrolled scrap of paper become the real first capture: whatever captured first is a source record and must be kept as one.

Transcription is where clean captures decay. The guideline is blunt: avoid unnecessary transcription steps between the source record and the data acquisition tool — the form or system the trial reports into, the next section's subject. Every copying step is a fresh chance to introduce an error the original never had. Where transcription is genuinely necessary, as when paper or an electronic health record is typed into the trial's system, verification scales with the criticality of the data. An endpoint value earns a second pair of eyes; a shoe size does not. ICH E6(R3)

One more thing is born at 09:41 besides the number: its context. Acquired data from any source should be accompanied by relevant metadata — the information that makes a data element interpretable: whose value, captured when, by what, in which unit. ICH E6(R3) The correction section takes metadata up in earnest.

Why provenance — a datum's traceable origin — deserves this much discipline is best shown by what happens without it.

Recording: The CRF and Its Electronic Kin

Between the ward chart and the sponsor's analysis stands a form, and the form has opinions. It asks for the protocol-required subset of everything the site knows, in a fixed structure, one participant at a time. That is the case report form (CRF). In R3's vocabulary it is one kind of data acquisition tool: a paper or electronic tool that collects data and its metadata from a data originator and reports them to the sponsor. The originator can be trial staff, the participant, or a machine. CRFs, interactive response systems, electronic patient-reported outcomes (ePRO), wearables: all data acquisition tools, whatever the media. ICH E6(R3)

Keep the geometry straight: the CRF is a structured window onto the source, not the source itself. Its electronic form is the eCRF, and the geometry is identical. The exception proves the rule. Where data is first captured in the tool — a participant answering an ePRO questionnaire in an app — that entry is the source record, and there is no paper behind it to check against. Everything else in the CRF reports a source record living elsewhere.

Two companion duties complete the picture. Data reported to the sponsor is consistent with the source records — or the discrepancy is explained, visibly, rather than smoothed over. And sponsor-deployed tools are used as specified: a field used "creatively" is a field the sponsor's edit checks and the trial's analysis no longer understand. Who may enter and change data at your site is a delegation-log question, settled before the system went live. ICH E6(R3)

In a blinded trial, the database also has to keep the secret. Blinding is safeguarded in system design, user accounts and roles, data access at the site, transfers, and the database review before planned unblinding. Who may see unblinded information is defined and documented in advance; blinded site staff are shielded from fields and reports that would reveal the assignment. Any unplanned unblinding — inadvertent or emergency — is documented and its impact assessed; the emergency code-break itself is Module 10's ground. ICH E6(R3)

Review: Queries and the Data Conversation

A number nobody ever questions is not clean — it is unexamined. GCP builds the questioning in, and it starts at the moment of entry. Automated validation checks, implemented where risk justifies them, fire the instant a value is implausible — a systolic pressure of 14, a visit dated before enrolment. Their configuration is controlled and documented. ICH E6(R3)

What those checks, the sponsor's data managers, and the monitors all produce is the same object: a data query. That is a documented question attached to a data point: confirm, correct or explain. Monitoring itself is Module 14's ground; what belongs here is the machinery every query moves through, whoever raised it.

Review runs in both directions. The investigator is not only the queried party but a reviewer too. E6(R3) expects timely review of the trial's data, including data arriving from external sources — central laboratory results, centrally read imaging, ePRO. Eligibility, treatment and safety decisions hang on it. The protocol may carve out exceptions to what you see, to protect the blind. ICH E6(R3)

The sponsor's powers in this conversation are deliberately bounded. The sponsor should not change data you or your participants entered unless the change is justified, agreed with you in advance, and documented. And the sponsor should never hold exclusive control of the data — exactly so that undetectable changes are impossible. Corrections you request are supported by source records from around the time of original entry. ICH E6(R3)

Answer queries as they come, while the source's context is fresh; the lock section shows what a backlog turns into.

Correction: The Audit Trail Never Blinks

Week 9, and a query fires on our Tuesday number: the eCRF says 124/91, the chart says 142/91 — a transposition, typed in a hurry. The fix takes thirty seconds. What makes the fix legitimate is that the record afterwards tells the whole story: first value, new value, who, when, why.

On paper, that story is told by hand: a single line through the error — the original still legible underneath — the correct value beside it, initialled, dated, with the reason. In an electronic system, the same story is told automatically by the audit trail: metadata records that capture the initial entry and every change or deletion — by whom, when and, where applicable, why. The trail is secure, computer-generated and time-stamped. One mechanism, two media; the margin note and the audit trail are the same promise kept. ICH E6(R3)

The audit trail belongs to a larger family this module has been hinting at: metadata, the contextual information required to understand a data element. A capable system logs more than data changes: account creation, role and permission changes, user access, workflow actions. E6(R3) is specific about its treatment: audit trails, reports and logs are not disabled; an audit trail is modified only in rare circumstances — the guideline's example is a participant's name typed where it should never be — and only with a log and justification. Trails must stay interpretable and reviewable, timestamps unambiguous (coordinated universal time, UTC, exists for a reason), and the responsible party decides which metadata is reviewed and retained. Reviewing data and its audit trail is a planned, risk-based activity — the trail is read, not just kept. ICH E6(R3)

Corrections themselves have a four-part standard: attributed to the person — or system — making them, justified, supported by source records from around the time of the original entry, and made in a timely manner. Which is why every correction goes through the system's correction function, never around it. Deleting and re-entering a record, editing a database table directly, having IT "fix it quietly": each produces a clean-looking value with no history. And a value with no history fails the standard even when it happens to be right. ICH E6(R3)

Movement and the Lock: Data on Its Way to Analysis

Data does not stay where it was born. It moves — from the site's systems to the sponsor's, between the sponsor's own systems, and wholesale when an ageing system is replaced mid-trial. Every move risks the two things this module guards: integrity and confidentiality. So transfers, exchanges and migrations run through validated processes or documented reconciliation: counts and checks that what arrived is what left, metadata included. The move itself is documented for traceability. Migration is the audit trail's sternest test: the data must change house without losing its history. ICH E6(R3)

Then the movement stops. Before analysis, the dataset is finalised — the operation the field calls database lock and R3 names finalisation of data sets prior to analysis. What "clean enough to analyse" means is defined in advance. The activities that get the data there are confirmed and documented under pre-specified procedures. They include reconciling the relevant databases against each other — the safety database against the eCRF, classically. They include rectifying errors and, where possible, omissions; medical coding; and working through the impact of noncompliance, protocol deviations included. Extraction and the assembly of analysis sets then follow the planned statistical analysis — Module 15's territory. In a blinded trial, the database review before planned unblinding — flagged in the recording section — sits here. ICH E6(R3)

Our Tuesday number crosses the lock as 142/91 — queried once, corrected once, its whole biography in the trail. After the lock, that value is what the analysis will forever have seen. This is also where a query backlog comes due. Every unresolved query at lock must now be analysed as is, explained, or have the lock reopened for it — expensive versions of a conversation that was cheap in week 9.

Locked does not mean untouchable in some absolute, physical sense. It means that from here on, a change is an event, not an edit. An event has a pre-specified procedure, a documented justification, the correction standard in full, and visibility all the way to the analysis. A dataset that can be quietly adjusted after lock is a dataset whose lock certifies nothing. ICH E6(R3)

After the Trial: Storage, Archiving, Destruction

The analysis ends; the data's obligations do not. Trial data and its relevant metadata are archived so they can be retrieved and read — not merely possessed — and protected from unauthorised access and alteration for the whole retention period. Readable includes the audit trail: an archive that keeps the values but loses their history has kept the answers and thrown away the proof. How long is Module 11's twenty-year rule; in what condition is this section's business. ICH E6(R3)

The systems holding all this age faster than the obligations do. Three duties see the data through. Contingency procedures ensure that data essential to participant safety, trial decisions or trial outcomes never becomes inaccessible — failure is planned for. Incidents in a system's use or operation that may significantly or persistently affect trial data or security are reported to the sponsor and, where applicable, the ethics committee. And validation runs until decommissioning. When a system is switched off — the sponsor's portal, the site's ancient eCRF server — the data's exit happens while the system still works, into the site's own retained records. ICH E6(R3)

Destruction is the life cycle's last governed act — not its escape. Trial data and metadata may be permanently destroyed only when no longer required under the applicable regulatory requirements — in Switzerland, not before Module 11's twenty-year floor has run out. And destruction is itself a processing operation, documented like the rest. ICH E6(R3)

Somewhere in the 2040s, an authorised person will destroy our Tuesday number: deliberately, on schedule, leaving a record of having done so. That is the only death GCP permits a datum.

The Person Inside the Data

Strip the name off a record and it feels harmless. Swiss law is not fooled: behind every value this module has followed stands a person who can be helped or harmed by where it travels. Health data is sensitive personal data under the nDSG, and "processing" means any handling at all — collection, storage, disclosure, archiving, destruction: everything in this module. nDSG The legal framework is Module 6's ground; what belongs here is the operational practice at the site.

The nDSG's principles land on trial work directly. Processing is proportionate and purpose-bound: a CRF collects what the protocol needs and nothing more — every extra field is data-protection exposure and data-quality risk with no scientific return. Data no longer required for its purpose is destroyed or anonymised. And whoever processes personal data must ensure it is accurate — the legal twin of the standard this module opened with. nDSG

E6(R3) gives the investigator the same duties from the GCP side. Implement measures protecting participants' privacy and confidentiality in line with data-protection law. And protect trial data on your systems: from unauthorised access, disclosure, dissemination or alteration, and from inappropriate destruction or accidental loss. ICH E6(R3)

The machinery making both sides workable is the code. Data reported to the sponsor is identified by an unambiguous participant code — never the name — and only the investigator/institution can trace it back to the person. Swiss law names the states precisely: coded (encoded) means linked to a person via a code; anonymised means the link cannot be restored without disproportionate effort. The distinction has teeth: the HRA does not apply to anonymised biological material or anonymised health-related data at all. But anonymisation is a high bar. It is met only when the key is gone and re-identification from the remaining attributes — age, diagnosis, a rare condition, a small town — would take disproportionate effort. Deleting the name column is not anonymisation. ICH E6(R3) HRA

Guard the key like the identity it is. The code list lives separately from the trial data, its access restricted to those who need it and documented — Art. 18's measures, applied to the most sensitive record the site holds.

Protection sometimes fails, and the law assumes it will. A breach of data security is any security failure leading to accidental or unlawful loss, deletion, destruction, modification, or unauthorised disclosure of or access to personal data. A stolen laptop, a misdirected e-mail, an intrusion: all qualify. Where a breach is likely to lead to a high risk to the data subject's personality or fundamental rights, the controller notifies the Federal Data Protection and Information Commissioner (FDPIC) as quickly as possible. With health data, high risk is usually the working assumption. The notification states at minimum the nature of the breach, its consequences, and the measures taken or planned; a processor notifies the controller on the same clock. Swiss law sets no 72-hour deadline — that is the EU's rule, not the nDSG's. Operationally: settle before the trial which role your site holds for which data — the FDPIC line is not something to work out mid-incident. Report it up immediately, in writing, while containing the breach. nDSG

Module Summary

You followed one number from a Tuesday morning to the 2040s. The standard travelled with it: attributable, legible, contemporaneous, original, accurate and complete — enforced by validated systems and one accountable human behind every account.

Capture defined where data is born and made every copy step earn its place. Recording kept the CRF consistent with source; review put every value through the query conversation; correction kept every change inside the audit trail. The lock turned edits into documented events, the archive kept data readable and protected for twenty years, and destruction ended the cycle as a governed act. Around all of it, the person: coded data guarded with its key, anonymisation a high bar, a breach met "as quickly as possible" — not on a borrowed 72-hour clock.

You can now:

• Hold any trial record to the E6(R3) standard: attributable, legible, contemporaneous, original, accurate and complete
• Judge whether a computerised system is fit for a trial — validated before use, released only after approval, secured, every user individually accountable
• Capture and record data cleanly: source records defined before the trial, transcription minimised, the reported data consistent with source
• Work the data's review cycle: answer queries from source, correct errors through the audit trail, and treat the lock as final
• Protect the person inside the data: store and destroy data and samples lawfully, guard the code, and act on a breach

The participant will never see the eCRF, the audit trail, or the code list. They took a risk on the promise that what the trial learned from their body would be true, protected, and used as agreed. Data management is that promise, kept daily, by name, for decades.