ALCOA+

What this page is#

ALCOA+ is the data-integrity standard regulators apply to clinical data: data must be Attributable, Legible, Contemporaneous, Original and Accurate, and also Complete, Consistent, Enduring and Available. Each attribute below says what the system does and where its responsibility ends. The questions with a status are on the pages cited and collected in the framework matrix.

Attributable: who did it#

Every action is recorded against the authenticated person, never against a value the browser supplied. An eligibility determination, a query answer and a source verification belong to whoever is signed in, and none can be recorded on behalf of someone else. A person's identity is never deleted or reassigned, so an old action stays attributable to a real person, and a role someone held is ended, not erased, so the role they held at the time remains visible (Invite and manage members). Where the system itself acts (the rule engine raising a query), the event says it is the system's, and names the person whose action set it off.

Legible: readable and permanent#

Data is stored as typed values, not documents: a number, a date as YYYY-MM-DD, a choice as its option value, a list for a multi-select, so what was entered does not depend on how a field is displayed (Field types). Audit events carry the earlier and the new value in readable form. Nothing is held in a format that needs the application to interpret it: exports are CSV, Excel and CDISC ODM-XML (Exports reference).

Contemporaneous: recorded when it happened#

The time of every record and event is the server's, so a browser with the wrong clock cannot misdate anything. Visit windows push entry towards the time of the visit: entry before a window opens is refused unless a person records an exception with a reason; entry after the window is never refused, because a late record is better than none, and the visit is reported as missed (Run a visit). A serious event records the moment the site became aware of it, and a reporting due time is derived from the version's setting (Record an adverse event).

Original: the first capture is preserved#

A saved value is never overwritten. A change is a new value that supersedes the old one, with its reason, and every earlier value stays readable and exportable. A field that holds data cannot be removed from a form, only deprecated with a reason (Versions, reopen and publish). A form version is frozen as an immutable snapshot and the whole study design is sealed with a content fingerprint, so the exact design that collected a value can be reproduced (View the live design). A formula's result is recalculated by the server with the same engine as the browser, and a difference is written to the audit trail.

Accurate: checked at the point of capture#

• Field checks run in the browser as the person types and again on the server when the record is saved: required, minimum and maximum, decimal places, length and pattern, e-mail, phone and time formats, choices that must be one of the options, selection counts, file type, and date limits (Validation, edit checks and their severities).
• Normal ranges open a query rather than refuse a real result (Units and normal ranges).
• Rules across forms and visits can block a save, warn, or raise a query (Rules reference). Some rule triggers and actions exist in the data model and do not run; the editor refuses to save a rule that uses them.
• Source data verification against the site's source, which stops standing if the verified value later changes (Monitor and verify data).
• Queries are the formal means of questioning a value; a correction needs both a reason and a query from someone else that opens the value (Correct data).

A value assignment and the auto-populate of a checkbox or toggle run in the browser only; the server stores the value it is sent (Not built yet).

Complete: nothing is quietly dropped#

• Governed records are retired, withdrawn or archived, never deleted, and a governance test fails the build on a new hard delete.
• A field that holds data can only be deprecated.
• Query threads are append-only, protected by a trigger in the database.
• The casebook derives completeness from the live design each time it is read, so a visit added later still appears (Use the casebook).
• A write that matches no visible row is an error rather than a silent no-op, and a change and its audit event commit together or not at all.

Consistent: the same rules everywhere#

State machines are enforced on the server, not only in the interface, so a rule holds for the screen and for the API alike (Statuses). UAT and Live data are separated at the database, so a test record can never appear in a live view or an export and the reverse (Data and tenancy). Participant numbers, screening numbers and randomization numbers are issued by the server in sequence from a counter, so two coordinators enrolling at the same moment cannot produce a duplicate.

Enduring: it survives#

Records are held in a relational database with foreign-key integrity, and files in object storage with a SHA-256 checksum recorded for each (The database). The audit trail is hash-chained and anchored daily outside the database, so degradation or alteration is detectable (Audit trail and evidence). The application watches for the backups it depends on and alerts when they are stale; making them is the operator's.

Available: retrievable throughout the retention period#

This depends on how you deploy. Backup, restore, the retention period and disaster recovery are the hosting's. Trialion deletes no governed record; whether a record is still there in ten years depends on whoever runs the database and the object store. Inside the application, records are retrievable by role through the screens, the casebook and the exports, and the audit trail can be read and exported whole.

Compliance Q&A#

Related#

Audit trail and evidence · Correct data · 21 CFR Part 11 · Framework matrix