Data entry, missing data, and audit

Review status

Included in the proposed model: Datapoint, Datapoint Revision, Missing Data Assertion, Invalid Input Attempt, Data Origin, Event-Date Revision, Form Submission, and human-readable Audit View.

Open: sponsor-side correction authority, offline-entry reconciliation, and the exact controlled reasons used for missing data and correction.

Clinical purpose

EDC must preserve what was reported, what was corrected, who or what originated it, when it was entered, why it changed, and which later decisions depended on it. A current value alone is not a clinical-trial record.

Datapoint

A Datapoint is the stable identity of one placed question for one subject occurrence. Its identity is:

Casebook
+ Visit/Event Occurrence
+ CRF Occurrence
+ Item-Group Row Occurrence
+ Item Placement

Its clinical address can additionally show:

• study, site, subject, and casebook;
• period/cycle and event occurrence;
• CRF placement and CRF occurrence;
• item-group placement and row occurrence; and
• item placement and reusable item definition.

The Datapoint keeps an ordered history of accepted revisions. It does not change identity when its value is corrected or when the casebook adopts a compatible design amendment. Each revision records the design publication and placement definition under which that revision was entered.

A non-repeating item-group has one stable row occurrence. Repeating rows receive stable identities when created. Removing or inactivating an earlier row never renumbers or reuses its identity.

Datapoint Revision

Field	Clinical meaning
Revision number	Stable chronological identity within the datapoint
Reported value	Data-type-checked clinical value or explicit missing assertion
Display and submitted representation	Human-readable value and controlled code where applicable
Unit	Reported unit and any separately governed standardized value
Originator	Person, participant, device, laboratory, EHR, eCOA, or other system
Origin type	Direct eCRF entry, transcription, import, automatic device/system transfer
Source location/type	Where the original record resides when the eCRF is not source
Clinical occurrence time	When the observation or activity occurred, if applicable
Entry/transmission time	When EDC received the revision, in an unambiguous time basis
Actor	Authenticated user/system responsible for the entry
Reason for change	Required according to correction policy
Prior revision	Revision superseded by this one
Related query/request	Cleaning conversation or import correction that prompted it
Definition version	Exact item placement, item definition, and design publication applied

Accepted revisions cannot be changed. A correction creates another revision and never obscures the original entry.

Value and absence states

State	Meaning	Typical behavior
Not yet entered	No report has been made	May create a required-data finding on submission
Valid value	Permitted value in the defined data type	Becomes current reported value
Partial/unknown component	Some allowed components are unknown, such as day in a date	Retained as structured partial value, not invented date
Not done	Assessment/procedure was not performed	Reason may be required; downstream rules see explicit absence
Not applicable	Question does not apply to this subject/occurrence	Must agree with design/clinical context
Not available	Expected information cannot be obtained	Reason and follow-up may be required
Subject refused	Participant declined the assessment or answer	Preserves clinical reason without a fabricated value
Intentionally not collected	Site accounts for an expected blank	Reason required under study policy
Suppressed by condition	Item is not currently applicable	Prior data are retained if applicability later changes
Invalid input attempt	Entry could not be accepted as the clinical value	Retained separately when needed for support/evidence

These states must never be collapsed into database null or empty text. They have different clinical, query, review, and analysis consequences.

Partial dates and times

Partial values are structured. For example, 2026-08-unknown is not converted to 2026-08-01. The item definition says which components may be unknown. Calculations declare whether they can operate on partial values; otherwise their result is indeterminate.

Invalid Input Attempt

An invalid attempt may retain:

• raw entered representation;
• intended datapoint;
• actor and time;
• datatype/range/format failure;
• validation message;
• whether the user corrected or abandoned it; and
• support correlation where applicable.

It is not a Datapoint Revision and never becomes clinical truth. Product review must decide which invalid attempts are regulated evidence versus short-lived entry assistance.

Form submission

Form submission records:

• form occurrence and its design version;
• submitter and delegated site role;
• submission time;
• exact current datapoint revisions and missing assertions;
• unresolved requiredness/findings allowed by policy; and
• submission number.

Submission does not freeze the form. Later authorized correction moves it to In Edit and requires a reason before resubmission.

Actions

• Enter or import a clinical value.
• Mark an item, row, form, or event with an allowed missing/not-done reason.
• Save a valid draft revision.
• Preserve an invalid attempted input separately.
• Submit a CRF.
• Reopen a submitted CRF for correction.
• Correct a datapoint or event date with reason.
• Reset an unused blank occurrence.
• Remove an unused repeating row that has no data, missing assertion, query, review, or signature evidence.
• View current values and reconstruct full audit history.

Correction authority

Site-reported data are normally corrected by the investigator or delegated site staff. Sponsor or data-management personnel should raise a query rather than overwrite the site’s report.

An exceptional sponsor/system correction must identify:

• applicable authority;
• prior agreement or approved procedure;
• person/system performing the correction;
• reason;
• supporting source evidence;
• affected review/signature/lock evidence; and
• notification or confirmation required from the investigator.

Business rules

1. A current value always resolves to one accepted revision that cannot be changed.
2. A correction never obscures or mutates the original revision.
3. Every revision identifies subject, originator, entry time, and definition context.
4. A change reason is required after initial submission and wherever study policy requires it.
5. Automatic transfers preserve originating system, transfer package, and source time.
6. A default or derivation is identified as such; it is never presented as manual observation.
7. The system never auto-enters a clinical value merely because the user bypassed a field.
8. Missing assertions cannot coexist with a current clinical value at the same datapoint.
9. Marking an entire form intentionally blank accounts for contained expected items but does not erase earlier data.
10. Nonblank repeating rows are retained; removal is represented by an auditable clinical/operational disposition.
11. Changing data identifies and reconciles affected checks, queries, reviews, coding, signatures, freezes, and locks.
12. Audit history is readable in clinical context, not only as technical record identifiers.
13. Datapoint identity uses the Item Placement occurrence, not only the reusable Item Definition.
14. Compatible amendment adoption preserves datapoint identity and records the new design context on later revisions.

Review and signature impact

When a value or missing assertion changes, EDC evaluates dependency rather than clearing every status indiscriminately:

• SDV on that exact prior revision becomes superseded or requires review.
• Data-management review of the containing reviewed scope is flagged or superseded.
• Coding based on the verbatim/context becomes Needs Recoding.
• A signature covering the changed data becomes superseded for that scope.
• Freeze or lock may refuse the correction until an authorized unfreeze/reopen occurs.
• Derivations, checks, schedules, and dynamic conditions using the value are reevaluated.

Audit views

The product must be able to show, for one datapoint or form:

1. initial value or missing assertion;
2. every correction in order;
3. who/what entered each revision and when;
4. why each change was made;
5. related query messages;
6. SDV and data-management review against exact revisions;
7. coding decisions based on the verbatim;
8. investigator signatures and their later supersession;
9. freeze, lock, unlock, and relock actions; and
10. amendment/design context.

Audit entries, workflow actions, and logs cannot be disabled or silently edited. Any exceptional redaction of mistakenly entered personal information requires separate authority, justification, and evidence of the redaction itself.

Exceptions

• A site changes the value but forgets to answer the open query.
• The site answers the query and confirms the original out-of-range value.
• A laboratory sends a corrected result after a manual value was already entered.
• An unknown date component later becomes known.
• The wrong unit was selected even though the number was correct.
• A copied default value is found not to have been observed for this subject.
• A controlling answer changes and dependent values become no longer applicable.
• The subject/form is locked when an urgent correction is required.
• An imported file is replayed and must not create duplicate revisions.