Reconstructing Clinical-Trial EDC Workflows from Audit Trails: A Critical Review of Event-Log Design and Interpretation

Abstract

Audit trails in clinical-trial electronic data capture (EDC) systems record who created or changed trial data; when; and, where applicable, why. Process-mining methods could use these time-stamped records to reconstruct data-management workflows. This structured critical narrative review draws on process-mining methodology, healthcare and electronic health record (EHR) audit-log research, and regulatory and industry sources to examine how event-log design constrains what reconstructed EDC workflows can show. Documented PubMed and Crossref searches were run on 28 October 2026. Audit trails are not designed as event logs: event definition, case notion, timestamp semantics, human and system actions, configuration changes, extraction cut-off, and system boundaries all shape the reconstructed process. The searches identified no peer-reviewed study that evaluated process mining of EDC audit trails against independently established quality outcomes, and most transferable evidence is analogical. The review proposes an interpretive framework that separates process observations, process signals, contextual interpretation, independent verification, and verification outcomes; illustrates it with a synthetic event log; and outlines an evaluation design and proposed reporting items. Audit-trail process analysis could support targeted human review within risk-based quality management, but its usefulness remains to be established, and alone it cannot establish data-quality failure, noncompliance, or poor site performance.

1. Introduction

Clinical-trial electronic data capture (EDC) systems are expected to preserve an audit trail for electronic records and changes to them. Regulation and guidance describe an audit trail as a secure, computer-generated, time-stamped record of the actions that create, modify, or delete data, showing what was changed; by whom; when; and, where applicable, why [1,2,3]. The United States Food and Drug Administration (FDA) notes that audit trails allow significant details of trial conduct and source-data collection to be reconstructed [4]. The European Medicines Agency (EMA) expects that the entire audit trail can be exported as a dynamic data file so that systematic patterns across participants and sites can be identified [3], and the International Council for Harmonisation (ICH) good clinical practice guideline E6(R3) asks for review of audit trails and other metadata to be planned and risk-based [2].

An audit trail is also, in effect, a record of work. Aggregate metrics such as query counts, open-query age, or form-completion rates describe volume and status but not the order in which actions occurred, how often work returned to an earlier state, or where waiting accumulated. Those sequential and temporal properties are what process mining was developed to analyse [5,6]. The approach is well established in studies of clinical care [7,8,9,10], and a parallel literature has used EHR audit logs to study clinician activity [11,12,13,14].

The transfer to EDC data is less straightforward than it appears. An audit trail exists to make individual changes traceable for review and inspection, and it becomes an event log only through a transformation. Process-mining research has shown that turning system records into an event log involves consequential choices about extraction, case correlation, and abstraction [15,16,17], and that quality problems in the resulting log distort discovered models [18,19,20]. Healthcare studies add warnings about timestamp meaning, competing case identifiers, and the validation of log-derived measures [14,21,22,23]. Clinical trials introduce a further risk: a reconstructed pattern can easily be read as a finding about data quality, protocol compliance, or site performance when it is, at most, a reason to look more closely.

This review addresses four questions. RQ1: What does the existing literature establish about constructing event logs from system audit records, and how directly does that evidence apply to clinical-trial EDC systems (Section 3 and Section 4)? RQ2: Which EDC-specific design choices condition what a reconstructed workflow can show, and how can their effect be checked (Section 5, Section 6, Section 7 and Section 8)? RQ3: How should process signals be interpreted and verified before they are treated as evidence about data quality, compliance, or site performance (Section 9, Section 10 and Section 11)? RQ4: What should future empirical studies evaluate and report (Section 12, Section 13 and Section 14)?

The contribution is an EDC-specific methodological synthesis rather than a new process-mining method. Existing audit-trail review guidance from industry groups defines use cases and risk scenarios that are mostly implemented with counts, durations, and thresholds [24,25]; event-log quality frameworks and healthcare process-mining methodologies address log construction in general [19,20,21,26,27]; and EHR audit-log research has produced reporting guidance for clinician-activity measures [28]. None of the sources identified addresses the combination that is specific to clinical trials: study-specific and versioned EDC configurations, system-prompted corrections that FDA guidance expects to be recorded, several regulated actor roles writing to one trail, and quality defined relative to critical-to-quality factors and independently documented evidence. The review makes four contributions. It identifies the event-log construction choices that condition what reconstructed EDC workflows can show, and the checks that expose their effect. It proposes an interpretive framework with five levels of inference and explicit criteria for moving from a process signal to a quality outcome. It demonstrates, with a synthetic event log, how two defensible construction choices change the conclusions drawn from identical records. Finally, it outlines an evaluation design and proposed, conditional reporting items for future studies. The final part of Section 3 (Positioning Relative to Existing Guidance and Frameworks) states where the framework overlaps with existing guidance and what it adds. No new process-mining method or empirical data are reported.

2. Review Approach

2.1. Design

This is a structured critical narrative review, not a systematic or scoping review. A narrative approach was used because the relevant evidence spans process-mining methodology, health informatics, clinical data management, and regulatory science, each with its own vocabulary, because direct peer-reviewed evidence on EDC audit-trail process mining is sparse, and because the aim is conceptual and methodological synthesis rather than pooled estimation.

2.2. Information Sources and Searches

Initial searches, completed on 2 October 2026, combined general web searches, searches of PubMed and PubMed Central, and follow-up of reference lists; the number of records they retrieved was not logged. They were supplemented by documented searches on 28 October 2026, whose strings, limits, and record counts are reported in Supplementary Table S2. Six PubMed searches were run on title and abstract fields with no lower date limit. One addressed the central question (process mining combined with clinical trials, EDC, audit trails, or clinical data management). Five addressed supporting topics: audit trails in clinical trials and clinical research; audit logs or audit events combined with process mining, event logs, or workflow; event-log quality, case notion, object-centric logs, and timestamps; validation and reporting of EHR audit-log measures; and central, statistical, or risk-based monitoring. Because much process-mining research appears in computing conference proceedings that PubMed does not index, two Crossref searches were restricted to proceedings articles (process mining with clinical trials; audit trails with event logs and process mining). The first 50 relevance-ranked records of each were screened. Targeted web searches were used to identify grey literature on EDC audit-trail review and process analysis. Scopus, Web of Science, IEEE Xplore, and the ACM Digital Library were not searched directly. Regulatory and standards documents were taken directly from ICH, FDA, the electronic Code of Federal Regulations, EMA, the Clinical Data Interchange Standards Consortium (CDISC), the World Wide Web Consortium, IEEE, the eClinical Forum and the Society for Clinical Data Management (SCDM), and the Association for Clinical Data Management (ACDM); current versions were used. Foundational process-mining methods were included without a date limit; for applied healthcare and clinical-trial sources, work published from 2020 onward was preferred where several sources supported the same point.

2.3. Eligibility, Selection, and Appraisal

Sources were retained if they addressed event-log construction or quality, reported methodological lessons from healthcare process mining or audit-log analysis, set regulatory or standards expectations for audit trails, metadata, or monitoring, or described central or risk-based monitoring as a setting in which operational signals are used. Work on predictive modelling without event-log relevance, descriptions of EDC implementation without reference to audit data, studies of audit data from systems other than EDC or healthcare information systems, conference abstracts and posters without an accessible full text, promotional material, and sources that could not be verified bibliographically were excluded. A source from an adjacent domain was judged relevant when it addressed a mechanism that is also present in EDC audit trails (for example, the meaning of a recorded timestamp, the choice of case identifier, or the effect of a system upgrade on recorded behaviour) and was used only for that mechanism. Where the same work appeared as a conference paper and a later journal article, the later version was cited, and overlapping reviews were cited for distinct claims only. Titles and abstracts were screened, and full texts were read for retained sources, by the single author.

Sources were appraised on four criteria: directness (whether the source concerns clinical-trial EDC audit data, another clinical-trial setting, or an adjacent domain), type of evidence (normative requirement, practice consensus, empirical study, or methodological or conceptual work), peer review, and currency. Their evidential weight was interpreted accordingly. Regulations and guidance set expectations for audit trails and their review but are not evidence that an analytic method performs well. Industry guidance reflects practice consensus but is neither peer-reviewed nor validated. Process-mining methodology establishes properties of techniques, mostly in non-clinical data, and healthcare and EHR studies offer transferable lessons about mechanisms, not evidence about EDC behaviour. Formal risk-of-bias tools were not applied, because most retained sources are methodological, normative, or conceptual. Retained sources were grouped into six evidence bodies (Table 1), and bibliographic details were checked against Crossref, PubMed, or the issuing organisation. Each citation is linked to the statement it supports in Supplementary Table S1.

Table 1. Evidence bodies relevant to EDC audit-trail process mining, their contribution, their limits, and their applicability to EDC audit trails.

Evidence Body	Representative Sources	What It Contributes	What It Cannot Establish Here	Applicability to EDC Audit Trails
Regulation, guidance, and standards for clinical-trial electronic records	[1,2,3,4,29,30,31,32]	Audit-trail content (creation, modification, deletion, date, time, operator, reason where applicable); risk-based review of audit trails and metadata; unambiguous timestamps; exportability for pattern review; centralised monitoring as a basis for targeted review; quality as fitness for purpose	Which analytic methods are valid for sequence-level review, or what a mined pattern means	Direct, normative: sets expectations, not method performance
Direct analyses of EDC or research-database data	[33,34]	Counts and reasons for audit-trailed data changes in one EDC trial database; process mining of programme data held in REDCap	Sequence-level analysis of audit trails as a record of data-management work	Direct but limited to counts or to non-audit data
Industry guidance on audit-trail review	[24,25]	Use cases and risk scenarios (access, data changes, timing, post-lock activity, cycle times); data-preparation advice including time zones; recognition that flagged patterns may be non-issues	Peer-reviewed or validated performance of any use case	Direct, practice consensus; not peer-reviewed
Process-mining methodology	[5,15,16,19,20,27,35,36,37,38,39]	Event extraction, correlation, and abstraction; event-log quality; conformance relative to a model; object-centric analysis; concept drift; uncertain timestamps; project methodology	Which EDC case notion or reference model is appropriate, or whether a signal indicates a quality problem	Transferred; mostly non-clinical data
Healthcare process mining and EHR audit-log research	[8,10,12,14,21,22,23,26,28,40,41,42,43,44]	Lessons on timestamp meaning, case identifiers, data-quality assessment, transformation of audit records into event logs, measure validation, and reporting	Direct validation in clinical-trial EDC systems, whose actors, purposes, and governance differ	Transferred by analogy for shared mechanisms
Clinical-trial monitoring research	[45,46,47,48,49,50,51,52,53]	Statistical cross-site anomalies as prompts for investigation; evaluation against confirmed fraud or inspection findings; matched evaluation of triggered monitoring; adoption of risk-based monitoring	Evidence about sequence-based (process) signals, as these methods analyse data values and key risk indicators	Direct setting; indirect for process signals

2.4. Selection Summary and Framework Derivation

The documented searches returned 500 records (400 from PubMed and 100 from Crossref). Removing duplicates (31 between PubMed searches and 5 between the two Crossref searches; no Crossref record matched a PubMed record by title) left 464 unique records, which were screened on title and abstract. Of these, 433 were excluded and 31 were relevant: 13 were already included from the initial searches and 18 were new (Supplementary Table S2). All 31 were read in full and retained. None of the 31 relevant records applied process mining or another sequence-level analysis to clinical-trial EDC audit trails; the evidence-gap statement in Section 3 is relative to these searches. The 18 new sources were added to the review, and four more came from targeted searches on uncertain timestamps, process-mining project methodology, privacy in process mining, and ICH E8(R1). The 433 excluded records were unrelated (for example, uses of “audit trail” in qualitative research or pharmacology), described audit-trail functionality without analysis of audit data, or provided substantively redundant evidence. Two grey-literature items were also excluded: a conference poster on audit-trail review in REDCap without an accessible full text, and a conference paper on audit trails in a statistical computing environment rather than an EDC system.

The framework (Figure 1), the table of construction choices, and the reporting items were derived in three steps. First, mechanisms by which log construction can distort a reconstructed process were extracted from the process-mining and healthcare literature. Second, each mechanism was mapped to the EDC features that could trigger it, as described in regulatory, standards, and industry sources. Third, each resulting framework component, construction check, and reporting item was classified as directly supported by clinical-trial or EDC sources, transferred from another setting, or the author’s recommendation. The source-to-component mapping is given in Supplementary Table S3.

3. What the Existing Literature Establishes

Table 1 summarises the bodies of evidence drawn on in this review and what each can and cannot contribute.

Regulation establishes the core audit-trail requirement [1], and current ICH, FDA, and EMA guidance adds expectations for interpretable metadata, risk-based review of audit trails, and export for pattern review [2,3,4]; none of these documents addresses analytic methods for sequence-level review. Industry and expert-group guidance sets out audit-trail review use cases and risk scenarios across system access, data changes, data-entry delays, and related categories [24,25]; these documents provide practical recommendations rather than peer-reviewed evidence of the analytical performance of those use cases. Direct peer-reviewed analysis of EDC audit-trail data was rare among the sources identified; a 2011 study of a single multinational, randomised, placebo-controlled dose-finding trial that used one EDC system characterised data-entry errors and audit-trailed data changes [33], but it analysed counts and reasons for change rather than event sequences. Process-mining methodology, by contrast, is mature [5,15,20,35,36], though it grew largely out of business and industrial data. The closest domain analogies come from healthcare process mining and EHR audit-log research [12,14,21,22,28], whose workflows and logs differ from trial data management in purpose, actors, and governance.

In the searches described in Section 2, no peer-reviewed study was identified that applied process mining to clinical-trial EDC audit trails and evaluated the resulting signals against independently established quality outcomes; this is a statement about the performed searches, not evidence that no such study exists. Process mining has been applied to programme data stored in a REDCap database [34], but that study analysed the collected data as a record of programme delivery, not the audit trail as a record of data-management work. The closest technical precedents transform standardised healthcare audit records (Integrating the Healthcare Enterprise audit format or HL7 FHIR AuditEvent resources) into process-mining event logs [43,44,54,55]. They indicate that such transformations need semantic enrichment and can lose events, but they used simulated, synthetic, or no real-world data and did not involve clinical trials (Section 5.3). Central statistical monitoring in trials is better developed, but it analyses data values and their distribution across sites, not the sequence of recorded actions [45,46,47].

Read critically, the literature agrees on three points. Log construction is itself an analytic step whose choices change the resulting models [15,17,20,26]; domain experts are needed to interpret and often to repair what the log shows [23,27,56,57]; and a difference from a reference process does not, in itself, show that something went wrong. Whether such deviations are warranted remains largely unresolved [58]. Several matters remain contested or unresolved. Healthcare studies differ on how far automated discovery can be trusted without expert-guided repair [57]; object-centric representations remove some distortions but are recent and have few clinical applications [40,59,60]; EHR audit-log research has increasingly relied on vendor-derived measures whose validity and comparability across vendors are uncertain [13,61]; and evidence on the value of centralised or triggered monitoring is mixed: a large observational analysis reported improved quality metrics at flagged sites after follow-up [53], whereas a prospective matched-pair study found that monitoring triggers discriminated only modestly between sites [50]. The main limitations of the evidence are that most healthcare process-mining studies are single-site case studies, that audit-log-to-event-log transformations have been demonstrated mainly without real-world data, and that EHR audit-log research has measured clinician time and navigation rather than the correctness of recorded data [12,13].

The EHR analogy has limits that bear directly on interpretation. EHR audit logs are generated by systems built to support clinical care and are often analysed for record access and navigation by clinicians [11,12]. EDC audit trails record data collected for a protocol and, ultimately, for regulatory submission, and they are subject to part 11 and good clinical practice requirements [1,2,4]. The actors differ as well: site staff, monitors, data managers, and automated edit checks and integrations all write to the same trail. EDC configuration is also built separately for each study and may change during conduct through protocol amendments and CRF or edit-check revisions [2], so the meaning of a recorded activity can differ between studies and between periods of the same study. Lessons from EHR research are therefore used below as methodological guidance, not as evidence about EDC behaviour. The features that distinguish EDC audit trails are treated directly rather than by analogy. These are regulatory constraints on what is recorded, several regulated actors and automated processes writing to one trail, and study-specific configurations that change during conduct. They are covered in Section 4 (construction operations), Section 5 (case and object choices), and Section 8 (operational, configuration, and logging change).

Positioning Relative to Existing Guidance and Frameworks

Table 2 compares the proposed framework with the approaches closest to it. The audit-trail review use cases of the eClinical Forum and SCDM are grouped into system access, data changes, data collection, reporting, and device concerns, and are implemented through dashboards, exception reports, and key risk indicators with absolute or relative thresholds [24]. The ACDM risk scenarios add timing, post-milestone, and cross-system comparisons and explicitly note that many flagged patterns are non-issues [25]. Neither describes process mining or the reconstruction of ordered workflows across related objects. The eClinical Forum and SCDM paper does describe confirmation of signals, root-cause analysis, and documented resolution [24], and the ACDM document recommends source verification and follow-up of anomalies [25]; neither sets out levels of inference or what may be claimed at each. Many of their use cases, such as late entry, changes after database lock, or excessive changes to critical data, are well served by counts, status summaries, and durations and do not need process mining. Order and object links matter for a smaller set. The eClinical Forum use case on changes after key timepoints becomes more specific when the timepoint is review of the same form rather than a study-wide milestone, and its use case on entry influenced by edit checks depends on the order of entry, prompt, and change. The ACDM scenarios on query-response cycle times and on verification dates that do not match monitoring records depend on lifecycle and cross-object relations [24,25]. These are the use cases in which sequence information is most likely to add to counts and durations.

Table 2. Overlap and difference between the proposed framework and related guidance and methodological frameworks.

Approach	Main Focus	Not Addressed for EDC Audit Trails	What This Review Adds
eClinical Forum/SCDM audit-trail review position paper [24]	Risk-based use cases for access, data changes, data collection, reporting, and devices; thresholds and key risk indicators	Sequence across related objects; effect of log construction on results; confirmation, root-cause analysis, and resolution are described, but not levels of inference or permissible claims	Construction choices and checks (Section 4, Section 5, Section 6, Section 7 and Section 8); interpretive levels with permissible claims (Section 9)
ACDM risk scenarios and use cases [25]	Risk scenarios scored by impact and likelihood; timing and cross-system comparisons; recognised non-issues	Process reconstruction; version-aware interpretation; evaluation of signal performance (non-issues and source verification are recognised)	Version-aware reference models (Section 7.2); evaluation design (Section 12)
Event-log quality and preparation frameworks [19,20,21,22,26]	Imperfection patterns, data-quality dimensions, quality-driven log preparation	Clinical-trial configuration, regulatory actor roles, and edit-check prompts as sources of apparent behaviour	EDC-specific mapping of construction choices to distortions and checks (Section 4, Section 5, Section 6, Section 7, Section 8 and Section 9)
Event extraction and abstraction research [15,16,17]	Correlation of records to cases; abstraction from low-level events	Which EDC case notions and abstractions are defensible for which questions	Synthetic demonstration of two defensible choices (Section 10.4)
Healthcare process-mining methodology and recommendations [23,27,56]	Project stages; involvement of domain experts; usability of results	Verification against source data and validation with stakeholders are included, but not the distinction between explaining a signal and establishing a trial-quality outcome	Separation of explanatory from establishing evidence, with outcome categories (Section 9)
Frameworks for developing and validating audit-log error measures in EHRs [62]	Development, validation against reference review, and use of audit-log measures of order errors	EDC configuration, actor roles, and trial-quality outcome categories	Evaluation design adapted to EDC process signals (Section 12)
EHR audit-log reporting guidance [28]	Reporting of clinician-activity measures from EHR metadata	EDC versioning, censoring at extraction, and outcome verification	EDC-specific, conditional reporting items (Section 13)
Risk-based monitoring, centralised statistical monitoring, and root-cause analysis [2,29,30,45]	Selection of sites and processes for targeted review; investigation of confirmed issues	Sequence-based signals; explicit criteria for reporting a sequence-based signal as an outcome	Place of process signals as prompts with an explicit evidence gate (Section 9 and Section 11)

What the process perspective adds is limited but specific. It shows the order of actions relative to one another, for example, whether a change preceded or followed source-data verification of the same form. It represents concurrency and dependency across participants, visits, forms, and queries. It treats loops and reopenings as properties of a lifecycle rather than as counts. And it allows comparison with a version-aware reference model. Some elements reflect a combination of features that is characteristic of clinical-trial EDC systems, though no single feature is unique to them. These are study-specific configurations that change during conduct; system-prompted corrections that FDA guidance expects to be recorded [4]; regulated site, monitor, and data-management roles; quality defined by critical-to-quality factors and errors that matter [2,32]; and verification evidence such as source documents, monitoring reports, and query text. Other elements, including case notion, abstraction, timestamp quality, concept drift, and conformance checking, are adaptations of established process-mining concepts [15,20,35,36,38]. The framework is therefore best read as a reorganisation of existing principles around the EDC setting, with new EDC-specific checks and an explicit gate between signal and outcome, rather than as a new methodological paradigm.

4. Why EDC Audit Trails Require Event-Log Construction

Clinical data management covers case report form (CRF) design, data entry, edit checks, discrepancy (query) management, and database lock [63], and EDC systems record much of this activity. A process-mining event log needs, at minimum, a case identifier, an activity label, and an ordering attribute for each event, usually a timestamp [5,64]; the Process Mining Manifesto stressed that logs differ in maturity and trustworthiness and that extraction is a central challenge [18]. An EDC audit trail is nevertheless not an analysis-ready event log. It records changes to data items, typically at field level, with user, role, date and time, previous and new values, and a reason for change where applicable [3,4]. ICH E6(R3) expects systems to retain workflow actions and relevant metadata [2]; in EDC systems these may include query states, verification or review status, signatures, and other status changes, although their availability and linkage in an export depend on the implementation. Exports may be vendor-specific or follow standards such as the CDISC Operational Data Model (ODM), which carries audit information alongside clinical data and metadata [31].

Several features of these records need deliberate handling. Audit trails are organised around records, not processes, so saving one form can generate many field-level entries with the same timestamp, a situation described in the event-log literature as “form-based event capture” and “collateral events” [20]. FDA guidance states that an audit trail need not capture every keystroke but should capture deliberate actions such as saving or submitting and that when an edit check prompts a correction, the original response, the prompt, and the change should all be recorded [4]. A single episode of data entry can thus legitimately appear as entry, system query, and change, which a count of changes after entry would treat as rework without distinguishing prompted from unprompted corrections. Human and system actions are mixed: the data originator may be a person, a computer system, a digital health technology, or an EHR [4]. Activity labels are specific to systems and configurations, so one activity may carry different labels across studies while different activities share a label [20]. Healthcare audit-log studies reached the same conclusion: audit records are designed for accountability, and they become usable for process analysis only after semantic enrichment that maps technical actions to meaningful activities [43,54,55].

EHR process-mining studies add that missing or imprecise timestamps, competing case identifiers, and uneven granularity must be assessed before process mining can be relied on [21,22,65,66], and general taxonomies of log quality list timestamp problems, granularity, ambiguous activity names, and mashed logging among the common failures [19]. For EDC audit trails, the implication is that building the event log is itself an analytic step and needs to be documented as one. Table 3 sets out that step as a sequence of operations, each with the fields it needs and a check that can expose errors, drawing on data-quality-driven preparation methods [20,26], the data-preparation recommendations of industry audit-trail guidance [24], and process-mining project methodology [27].

Table 3. Transformation of raw EDC audit records into an analysis-ready event log: operations, required inputs, and validation checks.

Operation	Required Fields or Inputs	Typical Decisions	Validation Check
1. Extraction	Clinical-data audit records with record, participant, site, visit, form, item, action, previous and new value, user, role, timestamp, time zone, and reason for change; query, review, signature, user-administration, and import logs where available	Which audit components and date range to export; export format (vendor export or ODM)	Reconcile record counts with the source system; confirm that every audit component needed for the question is present
2. Normalisation	Timestamps with time-zone information; code lists; user and role tables	Conversion to coordinated universal time; harmonised activity and status codes	Count records lacking a time zone; check daylight-saving transitions and future-dated or implausible times
3. Actor and source classification	User, role, and system-process identifiers; import and integration logs	Human, system, integration, or unclassifiable originator	Review a sample of each class against system documentation; report the unclassifiable proportion
4. Event abstraction	Field-level records; save or transaction identifiers where available	Grouping of field changes into save episodes; treatment of edit-check prompts and automatic status changes	Compare event counts before and after abstraction; inspect a sample of grouped episodes
5. Case or object correlation	Participant, visit, form, item, and query identifiers and their links	Case notion or object model (Section 5.2)	Check that each event links to the intended objects; count orphaned events
6. Version linkage	Protocol, CRF, edit-check, role, and transfer or mapping versions with effective dates and scope	Version assignment at site, participant, or form level	Report events whose governing version cannot be determined
7. Filtering and cleaning	Results of steps 1–6	Exclusion of test data, migrated records, or records outside scope	Report records removed at each step and their effect on the log
8. Plausibility review	Constructed log; study documentation	Trial discovery and inspection of example traces	Reconstruct known scenarios (for example, user acceptance test scripts) and review sample traces with data managers

5. Constructing Event Logs from EDC Audit Trails

5.1. Event Definition and Abstraction

Event-log construction involves extracting relevant records, correlating events to cases, and abstracting from low-level records to activities that mean something for the question at hand [15]. Abstraction is rarely neutral: grouping field changes into “form saved”, or query states into “query open” and “query closed”, determines which behaviour becomes visible [16]. With EDC data, an analyst has to decide whether a change made in response to an edit-check prompt is its own activity, whether system status changes are kept, and whether repeated saves of a form within minutes are one work episode or several. Different answers can yield different models from identical records [15,17], which is why such decisions are best specified in advance and reported. For example, a site user enters three vital-sign values and corrects one after an edit-check prompt. Treated record by record, this gives six events (three entries, a system query, a change, and an automatic query closure), which a count of changes after entry would treat as rework. If entries sharing a save identifier are grouped into a “form saved” episode, and the first human change to the queried item while its edit-check query is open is classified as a prompted correction, the same records yield one save, one prompted correction, and the opening and automatic closure of the query. This temporal rule classifies the change; it does not, by itself, establish that the query caused it. The prompted correction still records an initial error and the work of correcting it; the two constructions classify the same event differently rather than reducing the amount of rework, and a study should state which events its rework measure counts. Section 10.4 works through this contrast with synthetic records.

5.2. Case Definition and Workflow Reconstruction

Classical process mining assumes one case notion per event log [5,36,64]. EDC data involve several interrelated objects: participant; visit; form; field; query; and, in some systems, review or signature records. Treating the participant as the case merges parallel work on different forms and visits into one trace, creating loops and long cycle times that reflect concurrency rather than rework. A query-level case isolates the query lifecycle but loses corrections made without a formal query, and a form-level case can hide dependencies, as when a laboratory value prompts a change on an adverse-event form.

The case notion affects each process-mining task differently. In discovery, a participant- or visit-level case interleaves the activities of several forms, which can increase the number of variants and introduce apparent loops between activities that belong to different objects, depending on the records, activity labels, and discovery method. In conformance checking, the reference model must be written for the same case notion; a visit-level model that expects source-data verification after entry, applied to a log that does not retain form identity, will report a deviation whenever verification of one form precedes entry on another form of the same visit. In performance analysis, cycle times measured on a participant- or visit-level case include waiting on unrelated objects, whereas form- or query-level cases measure the lifecycle of one object but cannot show waiting caused by dependencies between objects.

Process-mining methodology describes this as the problem of flattening multi-object data, which produces convergence, where one event is replicated across several cases, and divergence, where independent instances of an activity are interleaved within one case [36]. Object-centric event logs and event knowledge graphs retain the relations between events and several object types [37,59], and tools for object-centric discovery and conformance checking now exist [60]. In healthcare, object-centric logs have been built from data in the OMOP common data model [40], and the choice between patient, admission, and unit-stay identifiers has been shown to change the level of analysis [22]. None of this work involves EDC data, but it supports a practical rule: state the analytic question, justify the case notion or object model, and, where feasible, check whether conclusions hold under an alternative.

5.3. Practical Requirements and Limits of Object-Centric Analysis

Object-centric analysis of EDC audit trails has four practical requirements. Object types must be identified and keyed consistently across audit components, which requires study-specific knowledge of the CRF, visit, and query model. Event-to-object relations must be recoverable from the export: a field change links to an item, form, visit, and participant, but a query, a source-data verification flag, or a signature may be stored in a separate log with identifiers that must be joined. The relevant components must be available at all; some vendor exports omit review or signature events, and the CDISC ODM can carry audit records for clinical data but does not, by itself, define query or review workflows [31]. Finally, the log must be expressed in a format that tools accept, such as the OCEL 2.0 standard [59]. Healthcare transformations of standardised audit records into object-centric logs, demonstrated on simulated or synthetic data, suggest that these steps are feasible but can lose events that the source format does not record [43,44], and the one healthcare application to a large data model started from a curated common data model rather than from raw audit records [40]. These requirements are harder to meet with proprietary vendor exports than with standardised research data. Export schemas, activity codes, and the meaning of audit fields are often vendor-specific and incompletely documented; query, review, and signature logs may be available only as separate reports or through vendor services; contractual and licensing terms may restrict which components a sponsor can export or analyse; and schemas can change between vendor releases during a study. Each of these can make object relations unrecoverable without vendor documentation or support, and an object-centric analysis may therefore be feasible only for some studies or some audit components. The standard and tools are recent [59,60], so results should be reported with the software version and the object model, and an object-centric analysis should be compared with at least one flattened view to show what the additional complexity changes.

6. Timestamp Semantics and Temporal Interpretation

An EDC record may carry several distinct times: the clinical date of a visit or assessment entered as data; the system time of entry or change; the times a query was raised, answered, and closed; the time of transfer from an external source; and the time of extraction. ICH E6(R3) expects automatically captured dates and times to be unambiguous, citing coordinated universal time as an example [2], and FDA asks sponsors to indicate the time zone of time stamps in systems that span time zones [4]. Industry guidance adds daylight-saving changes and notes that timestamps can lose their time zone after a device is replaced or reset [24]. Table 4 classifies these times by what they record and what they can support.

Table 4. Classes of time information in EDC audit data, their appropriate analytical uses, and the consequence of misuse.

Time Class	What It Records	Appropriate Uses	Consequence of Inappropriate Use
Clinical date or time (entered as data)	When the visit, assessment, or sample occurred, according to the entered value; often date-only and in local time	Protocol windows and visit scheduling; interval from clinical event to first entry, at day resolution	Treating a date-only value as a precise time creates spurious sub-day intervals and orderings
System entry or change time	When the EDC recorded a create, modify, or delete action	Ordering of recorded actions on the same object; entry and correction timeliness	Read as the time of clinical work, it misattributes waiting caused by source availability or batch entry
Query lifecycle times	When a query was opened, answered, reopened, and closed	Query cycle and waiting times; reopening patterns	Without censoring at extraction, open queries are excluded or truncated and durations are underestimated
Transfer or import time	When external data (laboratory, imaging, electronic patient-reported outcomes) arrived in the EDC	Separating site work from external dependencies	Treated as site entry time, it attributes vendor or laboratory delay to the site
Review, verification, and signature times	When monitoring, source-data verification, data review, or investigator signature was recorded	Ordering of changes relative to review milestones on the same object	Applied at visit or participant level without object identifiers, it flags changes to other forms as post-review changes
Extraction time	When the export was taken	Censoring point for incomplete traces	Treated as an event, it truncates lifecycles and makes recent sites appear faster or slower than they are

When the interval between a visit date and the first EDC entry is treated as a measure of timeliness, it may also reflect scheduled batch entry, late availability of source documents, legitimate retrospective entry, time-zone handling, or migration from another system. Coarse or identical timestamps also make ordering ambiguous and can change discovered sequences [19,67]. A recorded system time shows when a documented system action occurred, not when the clinical work was done or why an interval arose. Healthcare studies illustrate the gap: in one hospital, documented infusion times in the EHR differed from automatically recorded pump events by more than 10 min in about a fifth to a third of infusions [42].

6.1. Ordering Uncertainty and Sensitivity Analysis

Many field-level records from one save share a timestamp, and events from different components may be recorded at second or day precision. A documented tie-breaking rule, such as ordering by audit record identifier, makes an analysis reproducible but does not establish the true order of events. Order can be supported by additional metadata where it exists, for example, a transaction or sequence identifier, a save identifier that links field changes to one submission, or a causal relation such as a query that references the value it was raised on. Where no such metadata exists, events with the same timestamp should be treated as unordered: grouped into one episode if they belong to one save or analysed as a partial order. Process-mining research offers methods that make this uncertainty explicit, by representing each timestamp as an interval and reporting the best-case and worst-case conformance over all possible orderings [39], by applying a tolerance window informed by domain experts [41], or by detecting and repairing ordering imperfections interactively [67]. A simple sensitivity analysis is to repeat the analysis under at least two defensible orderings and report which conclusions change. Events with a missing timestamp cannot be placed in a sequence; they should be counted and reported, placed by a documented rule only where another time field or a causal link fixes their position, and otherwise excluded from ordering-dependent analyses with a check of whether the exclusions cluster by site, form, or period. Records without a time zone should be counted and, where the site’s time zone is known, converted with that assumption stated; where it is not known, intervals shorter than the possible offset should not be interpreted.

6.2. Incomplete Traces and Right Censoring

An extraction cut-off leaves some queries open and some visits incomplete. Excluding unresolved queries from duration analysis keeps only those that were resolved by the cut-off, which are disproportionately the faster ones, so it underestimates typical resolution time; treating the time observed up to extraction as a completed lifecycle also underestimates it. Both errors are larger for sites or periods with recent activity. For example, if a site opened 20 queries in the month before extraction and 12 were still open, the median resolution time computed from the eight closed queries describes only the queries closed by extraction and is likely to underestimate resolution time. A censoring-aware approach treats open items as right-censored at the extraction time and estimates resolution time with time-to-event methods [68]; reports the number and proportion of open items at cut-off by site and period; and compares sites over windows in which all items had a comparable opportunity to close. These methods assume that censoring is non-informative, that is, that queries censored at the cut-off have the same subsequent resolution rate as queries still open after the same elapsed time within the compared groups; this may not hold if recently opened queries differ systematically, for example, after a configuration change or at newly activated sites. The endpoint must also be defined. Resolution may mean first closure, or each interval from opening or reopening to the next closure may be treated as a separate episode; the choice changes the estimate when reopening is common. Final closure requires a pre-defined terminal condition or follow-up horizon, because an observed closure may later be reopened; uncertainty about whether a closure is final is not the same as right censoring at extraction. When the probability of resolution is estimated, terminal states that preclude resolution, such as cancellation or withdrawal of the query, should be treated as competing events rather than as resolution or censoring, and the cumulative incidence of resolution reported [69]. Where the estimated proportion resolved does not reach 50% during follow-up, the median resolution time cannot be estimated and should be reported as not reached.

7. Discovery, Conformance Checking, and Performance Analysis

Discovery, conformance checking, and enhancement, including performance analysis, are the principal process-mining tasks [5,10], and each has distinct interpretive limits when applied to EDC data. No reference process for EDC data management validated against outcomes was identified in the sources reviewed, so in all three tasks a discovered model or a deviation describes recorded behaviour under stated construction choices.

7.1. Discovery

Discovery summarises recorded behaviour as a model or a set of variants. Where parallel form, visit, and query activities are combined within a trace, many variants can be expected, some of which reflect acceptable ordering choices: for example, one site may enter vital signs before laboratory results simply because the results arrive later. A rare variant is a statement about frequency in the log, not about acceptability. Discovery is suited to descriptive questions, such as which paths queries follow from opening to closure, where loops concentrate, or how the query lifecycle differs before and after a configuration change. It is not suited to establishing that a site works incorrectly.

7.2. Conformance Checking and Reference Models

Conformance checking relates observed behaviour to a process model and locates deviations relative to that model [35,70], so its results are only as meaningful as the reference model. In a trial, that model would have to reflect the protocol version, the CRF and edit-check configuration, and the data-management plan in force when each event occurred. A conformance difference is a difference from a chosen representation, which may or may not correspond to a protocol deviation. A healthcare study that checked FHIR audit events from ten cases against a standard operating procedure found several deviations but had no means of judging which were warranted [71], a limitation that is common across computable adherence studies [58].

A defensible EDC reference model can be built from existing study documents: the schedule of assessments, CRF completion guidelines, edit-check specifications, the query-management procedure, and the data-management and data-review plans. Because many orderings are acceptable, it is better expressed as a small set of constraints than as one required sequence. For example, a query closed manually by a data manager should have a site response unless the procedure permits cancellation or withdrawal, whereas one closed automatically by its edit check needs none; and source-data verification of a form should follow the last change to it unless the change is re-verified. Each constraint should be versioned with the study build, so that events are checked against the rules in force when they occurred, and validated by data managers and monitors who walk through the model and replay it on user-acceptance test data or on a sample of known-good traces. Project methodologies for process mining and healthcare studies both recommend this iterative review by domain experts [27,57].

7.3. Performance Analysis

Performance analysis annotates models with waiting and cycle times [70]. Long query-resolution times may arise from dependence on external reconciliation, the timing of monitoring visits, site staffing, or ambiguous query text, as well as from genuine difficulty. Healthcare process-mining guidance accordingly stresses the involvement of domain experts in interpretation [23,56]. Performance questions, such as where waiting accumulates in the query lifecycle, are suited to EDC data if the time classes in Table 4 are kept apart and censoring is handled as described in Section 6.2.

8. Configuration History and Version-Aware Interpretation

Trials change during conduct. Protocol amendments, CRF revisions, new or modified edit checks, changes to roles and permissions, and revised external transfers or mappings alter which actions are possible, required, or automatically generated. Such changes may alter the workflow itself, its recorded representation, or both. Process-mining research treats changes in process behaviour over time as concept drift and has shown that analysing a log as though the process were stationary can give misleading models and comparisons [38,72]; changes in logging or configuration that leave the underlying work unchanged need to be distinguished from drift in the process. A new edit check introduced mid-study may produce a wave of queries and corrections that looks like increased rework; a revised CRF may make a previously normal path appear nonconforming; and participants enrolled before an amendment may complete a newly added form out of the original visit order. A pattern that appears across sites at the same calendar time warrants comparison with configuration-change dates and other shared operational events.

Three kinds of change should be distinguished. An operational change alters what people do, for example, a new requirement to re-verify data after any change. A configuration change alters what the system requires or generates, such as a new edit check. A logging change alters only how actions are recorded, for example, a vendor release that writes one audit record per field instead of one per save, or that adds automatic status events. An EHR study found that a software upgrade during the observation period changed the discovered process models [22], and sequence models of EHR audit logs lose accuracy over time as recorded behaviour drifts [73]. In an EDC study, a release that doubled the number of audit records per save would produce, on the same date at every site, an apparent rise in rework with no change in the number of data values that actually changed. Comparing the ratio of audit records to changed values, and the timing of the shift with release notes and configuration-change dates, could help distinguish a logging change from an operational one, although this diagnostic has not been tested.

Version-aware analysis therefore links each event, where the information is available, to the protocol, CRF, edit-check, role, and transfer or mapping versions in effect when it occurred. The linkage should be made at the site, participant, or form level at which versions were applied, not by calendar date alone. Version periods can then be analysed separately or version treated as an attribute, and events whose governing version cannot be determined should be reported. ICH E6(R3) expects systems to keep logs of user accounts, roles, and permissions [2], which helps with this linkage, and provenance models offer a general vocabulary for recording how derived records relate to their sources, activities, and agents [74,75].

9. From Process Observation to Quality Outcome

The preceding sections identify risks at two levels: in how the event log is constructed and in how the resulting patterns are interpreted. Table 5 summarises the main construction choices, the distortions each can introduce, and the checks that expose them.

Table 5. EDC logging and modelling choices, potential distortions, construction checks, sensitivity or validation checks, and interpretive limits (based on [2,4,15,20,36,38]).

EDC Logging or Modelling Choice	Potential Distortion in the Reconstructed Workflow	Construction Check and Contextual Evidence	Sensitivity or Validation Check	Interpretive Limit
Event abstraction: field-level records, save episodes, or business activities	Field changes from one save inflate event counts; prompted and unprompted corrections are conflated	Specify grouping rules and treatment of edit-check prompts in advance	Repeat key results with field-level and episode-level abstraction; report which conclusions change	The workflow is conditional on the abstraction used
Case selection: participant, visit, form, field, or query as the case	Parallel work collapsed into one trace (apparent loops, long cycle times); events replicated across cases (convergence) or interleaved (divergence); corrections without a formal query invisible in query-level cases	State the analytic question; justify the case notion; document links between objects	Compare an alternative case notion or an object-centric model; report differences in variants, deviations, and durations	The reconstructed workflow is conditional on the stated case notion
Mixed human and system events	Autosaves, imports, scheduled jobs, edit-check firings, and automated status changes can inflate event counts and create apparent rework	Classify each event by originator (user, role, system process, integration) using system documentation	Analyse human and system events separately and together; review a sample of classified events	Attribution of actions to people requires reliable actor classification; interpreting human workflow may also require the linked system events
Timestamp semantics	Clinical dates, entry times, change times, transfer times, and extraction times conflated; time-zone or daylight-saving shifts; identical timestamps for many field changes create ordering ambiguity	Record which time class each timestamp represents (Table 4), its precision, and its time zone; define tie-breaking rules	Repeat ordering-dependent results under alternative orderings or interval timestamps; exclude intervals shorter than possible time-zone offsets	The log assigns this time to a system action; its relation to when clinical work occurred depends on timestamp semantics and clock integrity
Protocol, CRF, edit-check, role, or transfer or mapping changes	Legitimate post-change workflows classified as deviations; waves of queries after a new edit check read as site-level rework	Link each event to the versions in force; use version-aware reference models	Analyse version periods separately; check whether signals align in calendar time with change or release dates	A trace differs from a specified, version-aware reference model
Extraction cut-off and right censoring	Open queries and incomplete visits appear slow or failed; recent sites appear different from established ones	Report extraction date and status at cut-off	Use censoring-aware duration estimates; compare sites over windows with equal opportunity to close	The trace was incomplete at the extraction point
Activity outside the EDC (monitoring, source review, communication, external reconciliation)	Inactivity periods and long intervals that correspond to work recorded elsewhere; missing causal links	Define the system boundary; where appropriate and permitted, consult linked systems or records	Check a sample of long intervals against monitoring or transfer records	The EDC trace is a partial representation of operational work

Figure 1 sets out the proposed interpretive framework, which separates five levels of inference, numbered L1 to L5 in the figure. The seven numbered boxes describe the operational steps; level L1 (process observation) covers steps 1–3, and each of the remaining levels corresponds to one step. Table 6 defines each level, the evidence it typically draws on, the criterion for moving to the next level, and the claim that can be made at that level. Workflow reconstruction refers to the models, variants, conformance results, and performance measures derived from the event log in step 3. A process signal may be a delay, a reopened query, a correction loop, an unusual sequence, inactivity, a bottleneck, a rare variant, or a difference from a reference model. Competing explanations include logging artefacts, automation, permitted exceptions, configuration or protocol changes, dependence on external data, workload, ambiguous instructions, and genuine operational problems. Verification may establish a quality problem, support an alternative explanation, or leave the signal unresolved; a quality outcome, in the sense of a clinically or operationally material problem, is only one of these endpoints.

Table 6. Levels of inference in the interpretive framework: definitions, typical evidence, criteria for moving to the next level, and permissible claims.

Level (Steps in Figure 1)	Definition	Typical Evidence	Criterion for Moving to the Next Level	Permissible Claim at This Level
L1 Process observation (steps 1–3)	Recorded sequence and timing of events in an event log built under stated construction choices	Audit records; documented construction rules and checks (Table 3)	Construction documented and plausibility checks passed; signal definitions specified in advance	The log, built in this way, records this sequence and timing
L2 Process signal (step 4)	A pattern that meets a pre-specified definition and may merit attention	Signal definition and threshold; result under the primary and alternative constructions	No further criterion; sensitivity to construction choices is recorded and informs interpretation, and a signal is not discarded merely because an alternative construction cannot represent it	This pattern merits review
L3 Contextual interpretation (step 5)	Weighing of competing explanations for the signal	Query text and responses, reasons for change, configuration and release history, including known logging changes, transfer logs, site communications	Escalate to verification while a material outcome (Table 7) remains possible, whether or not the observed sequence has been explained; close the signal only when no material concern remains, and record the explanation	Explanation X is supported, or cannot be excluded
L4 Independent verification (step 6)	Examination of evidence outside the reconstructed trace against pre-defined outcome criteria (Table 7)	Source documents, monitoring and source-data verification records, data-management adjudication, safety-database reconciliation	Adjudication completed against the pre-defined criteria, using evidence that adds information beyond the signal, preferably by reviewers blinded to the signal	Verification has been completed against stated criteria
L5 Verification outcome (step 7)	The endpoint of verification: a quality outcome (an established problem within a defined category and unit), a supported alternative explanation, or an unresolved signal	Adjudication record	None; further generalisation requires separate evidence	Only an established problem is a quality outcome, and it applies to the adjudicated unit, not to overall site performance

Figure 1. Proposed interpretive framework for clinical-trial EDC audit-trail process analysis. EDC audit-trail records are transformed into an event log through explicit choices about event definition, abstraction, case construction, timestamp provenance, actor and source classification, and version provenance. Workflow reconstruction can generate descriptive process signals, including variants, delays, reopening, rework, inactivity, or differences from a selected reference model. These signals require contextual interpretation and independent verification, which may establish a quality problem, support an alternative explanation, or leave the signal unresolved. The numbered boxes 1–7 are operational steps; the labels L1–L5 are levels of inference and are shown separately from the step numbers. Process signal ≠ quality outcome.

Figure 1. Proposed interpretive framework for clinical-trial EDC audit-trail process analysis. EDC audit-trail records are transformed into an event log through explicit choices about event definition, abstraction, case construction, timestamp provenance, actor and source classification, and version provenance. Workflow reconstruction can generate descriptive process signals, including variants, delays, reopening, rework, inactivity, or differences from a selected reference model. These signals require contextual interpretation and independent verification, which may establish a quality problem, support an alternative explanation, or leave the signal unresolved. The numbered boxes 1–7 are operational steps; the labels L1–L5 are levels of inference and are shown separately from the step numbers. Process signal ≠ quality outcome.

The distinction between explanatory and establishing evidence is the core of the framework. Evidence at L3 explains why a pattern arose; evidence at L4 establishes whether an outcome occurred, using criteria that are defined before the review and do not depend on the reconstructed trace. The same document can serve both purposes, as when query text explains a reopening and also shows that a value was wrong, but an outcome should never be inferred from the trace alone. Table 7 distinguishes the outcome categories that a verification step might establish, with their units and adjudication sources. The categories correspond broadly to the risk areas used in industry audit-trail guidance [25] and to the attention that ICH guidance gives to critical-to-quality factors and errors that matter [2,32].

Table 7. Categories of quality outcome that verification may establish, with units of analysis, illustrative criteria, and adjudication sources.

Outcome Category	Unit	Illustrative Criterion	Adjudication Source
Data error in critical data	Data item or record	Recorded value differs from source for a variable identified as critical to quality	Source-data review; data-management adjudication
Protocol deviation	Participant, visit, or procedure	Departure from the protocol meeting the sponsor’s deviation definitions, classified by importance	Monitoring findings; deviation review by the clinical team
Operational delay	Form, query, or visit	A timeline exceedance observed in the audit trail is a signal, not an outcome. An operational problem is established only after review confirms that the timeline applied to that item and version, that the timestamps measure the interval the timeline governs, and that no permitted exception applies (for example, pending external data, site closure, or system downtime). Exceptions are confirmed with the site or from source evidence, such as the date source data became available, rather than inferred from the absence of exception records, and, where the timeline starts from a clinical event, its start point is checked against source documentation. Items still open at extraction are handled as in Section 6.2	Plan timelines and their version history; timestamp definitions; source documents and site confirmation; exception and downtime records; data-management or monitoring review (a delay is not in itself a data error)
Safety-relevant problem	Participant or adverse event	Adverse or serious adverse event recorded late, incompletely, or inconsistently with the safety database	Safety reconciliation; medical monitor review
Data-integrity or access problem	User, record, or site	Action inconsistent with permissions or data-integrity principles, such as entry by an unauthorised user	Quality assurance investigation; audit findings
Problem affecting the reliability of results	Site, variable, or analysis population	Errors that matter for critical-to-quality factors and could affect trial conclusions	Independent review committee, blinded where feasible; statistical assessment

An efficient process is also not necessarily a correct one. FDA guidance on risk-based monitoring describes centralised monitoring as a way to identify missing or inconsistent data, outliers, potential protocol deviations, and delays in reporting data, as prompts for follow-up [29], and expects significant issues to be evaluated through root-cause analysis [30]; ICH E6(R3) describes centralised monitoring as supporting the selection of sites and processes for targeted monitoring [2]. In a retrospective study of central statistical monitoring, the analysis was evaluated against previously confirmed fraud [48], so the statistical signal was judged against an independently established outcome.

The framework overlaps with and differs from three related approaches. Validation in process mining includes model-quality measures, such as fitness and precision, that assess how well a model represents the log [35], and, in project methodologies, verification of findings against source data and systems and validation with stakeholders [27]. The framework adopts these steps; what it adds for EDC is a set of pre-defined trial-quality outcome categories and an explicit statement of what may be claimed at each level. Root-cause analysis begins after an issue has been confirmed and asks why it occurred [30], and industry audit-trail guidance already describes confirmation of signals, root-cause analysis, and documented resolution [24]; the framework makes the steps before confirmation explicit for sequence-based signals. Risk-based and centralised monitoring use signals to select sites and processes for targeted review [2,29]; the framework places process signals in that role and adds explicit criteria for when a signal may be reported as an outcome.

Process signals need operational definitions before they can be studied. Table 8 gives illustrative definitions for common signals, the construction decisions on which each depends, and common benign explanations. The definitions and any thresholds are examples, not validated indicators; appropriate thresholds depend on the study, its configuration, and its data-management plan.

Table 8. Illustrative definitions of process signals (not validated indicators; thresholds are study-specific).

Signal	Illustrative Definition	Construction Decisions It Depends on	Common Benign Explanations
Query reopening	A query returns to an open state after a site response	Query object model; separation of automatic reopening on value change from manual reopening	Pending external data; incomplete first response; automatic reopening; changed query conventions
Correction loop	Two or more human changes to the same item after first entry, excluding prompted corrections (the first human change to the item while its edit-check query is open), which are counted separately	Query–item linkage; actor classification	Corrections after source-data verification; late laboratory results; repeat measurements permitted by the protocol
Prolonged inactivity	No recorded human action on an open object for longer than a pre-specified period, censored at extraction	Time class used (Table 4); system boundary	Work recorded in other systems; waiting for source documents; site closures
Unusual variant	A trace variant below a pre-specified frequency within one version period	Case notion; version stratification	Legitimate alternative order; small denominators; configuration change
Change after review	Change to an item after source-data verification or data review of the same object	Linkage of review events to the reviewed object	Correction prompted by the review; re-verification pending

10. Hypothetical Worked Examples

The four examples below were constructed to illustrate the reasoning in Figure 1 and Table 5. They are not drawn from any trial, dataset, or organisation, and the values, intervals, and thresholds in them are illustrative rather than validated.

10.1. Example 1: Query Reopening

A query-level trace reads: query opened, site response entered, query reopened, query closed, where “reopened” is the system’s label for returning a query to the site after a response. The reopening might follow an incomplete first response, a change to the edit check or to query-handling conventions, a pending laboratory reconciliation, an automatic reopening triggered when the underlying value changed, or a substantive data problem. The trace cannot distinguish among these. The query text and responses; the configuration history of the edit check; the system’s reopening rules; and, if a data problem is suspected, the source record are needed before anything more can be said than that the recorded lifecycle included a reopening.

10.2. Example 2: Delayed or Retrospective Entry

The visit date entered for a participant precedes the first EDC entry for that visit by several days. Delayed transcription is one possibility; others include batch entry on scheduled days, waiting for a specialist report, retrospective entry of a form added by amendment, system downtime, and time-zone handling. What the record shows is an interval between a recorded clinical date and a recorded system time. These are different kinds of time (Table 4). The visit date is usually recorded without a time, so the visit may have taken place at any point on that day, whereas the entry time is a precise system timestamp. The interval is therefore uncertain by up to one day. Converting the system time between coordinated universal time and the site’s local time can move it across midnight, which changes a day-level interval by at most one day, because time-zone offsets do not exceed 14 h. Time-zone handling can therefore matter for a requirement such as same-day entry, but it cannot plausibly explain an apparent delay of several days. Whether such a delay reflects a problem with site processes depends on information the audit trail does not hold.

10.3. Example 3: Correction Loops and an Edit-Check Change

A form-level trace shows a value entered, changed, and changed again. If the first change followed an edit-check prompt, the sequence is the expected record of that check [4]; the second change might reflect source-data verification, a late laboratory result, or correction of a transcription error, and the reason for change may say which. Suppose that in the same month a new edit check was deployed and similar loops appear at most sites. Against the pre-change configuration they look like widespread rework; a version-aware model would allow the new check to be considered as an explanation, without establishing the cause of any individual correction. Counting loops without classifying their triggers or without reference to configuration history would merge system-prompted, review-prompted, and spontaneous changes into a single misleading measure.

10.4. Example 4: A Synthetic Event Log Under Two Construction Choices

Table 9 lists 15 synthetic audit records for one participant’s week-4 visit, with a vital-signs form, a local-laboratory form populated by electronic transfer, and two edit-check queries. The visit date was entered as 2 March, without a time, and the extraction was taken on 20 March. The synthetic export is assumed to carry a save identifier shared by records 1–3, and a separate save identifier for record 5, and to link query Q1 to the systolic blood pressure item on the vital-signs form and query Q2 to the potassium item on the laboratory form.

Table 9. Synthetic EDC audit records for one participant visit, with the activity each record becomes under construction B (hypothetical; times in coordinated universal time). Under construction A, each record is one activity labelled by its action.

No.	Timestamp	Originator (Role)	Object	Action	Detail	Construction B: Object, Activity
1	4 Mar 14:02:11	User A (site)	Vital-signs form	Value entered	Systolic blood pressure: 182	Vital-signs form: form saved (records 1–3 share a save identifier)
2	4 Mar 14:02:11	User A (site)	Vital-signs form	Value entered	Diastolic blood pressure: 88	(grouped with record 1)
3	4 Mar 14:02:11	User A (site)	Vital-signs form	Value entered	Heart rate: 72	(grouped with record 1)
4	4 Mar 14:02:12	System	Query Q1	Query opened by edit check	“Systolic > 180 mmHg; please confirm”	Query Q1: opened (system)
5	4 Mar 14:03:40	User A (site)	Vital-signs form	Value changed	Systolic 182 → 128; reason: transcription error	Vital-signs form: prompted correction (separate save, in response to Q1)
6	4 Mar 14:03:41	System	Query Q1	Query closed automatically	Edit-check condition no longer met	Query Q1: closed (system)
7	6 Mar 09:15:30	System (laboratory transfer)	Laboratory form	Value imported	Potassium: 6.1 mmol/L (sample 1)	Laboratory form: result imported
8	6 Mar 09:15:31	System	Query Q2	Query opened by edit check	“Potassium > 5.5; confirm and record adverse event if applicable”	Query Q2: opened (system)
9	10 Mar 16:40:05	User B (monitor)	Vital-signs form	Source-data verification completed	Form verified	Vital-signs form: verified
10	11 Mar 10:22:47	User A (site)	Query Q2	Response entered	“Sample haemolysed; repeat pending”	Query Q2: site response
11	11 Mar 15:05:12	User C (data manager)	Query Q2	Query reopened	“Please update when repeat result available”	Query Q2: reopened (manual)
12	18 Mar 08:01:09	System (laboratory transfer)	Laboratory form	Value imported	Potassium: 4.3 mmol/L (sample 2, collected 17 Mar)	Laboratory form: repeat result imported
13	18 Mar 13:28:40	User A (site)	Laboratory form	Value changed	Sample 1 evaluable: Yes → No; reason: haemolysed, repeat obtained	Laboratory form: original result annotated as non-evaluable
14	18 Mar 13:30:00	User A (site)	Query Q2	Response entered	“Repeat potassium 4.3, within range”	Query Q2: site response
15	19 Mar 11:12:54	User C (data manager)	Query Q2	Query closed	Response accepted	Query Q2: closed (manual)

Construction A treats every audit record as an activity and the participant visit as the case, without retaining form or query identifiers as attributes; it suits a visit-level question, such as the span of recorded activity for a visit. Construction B groups entries that share a save identifier into one “form saved” episode, classifies the first human change to an item while its edit-check query is open as a prompted correction, and classifies each event by originator. It keeps forms and queries as separate, linked objects in an object-centric log, and suits questions about the lifecycle of individual forms and queries. The two constructions differ in abstraction, case notion, and actor classification at once, so Table 10 shows their combined effect rather than isolating each choice.

Table 10. Results of two construction choices applied to the records in Table 9.

Quantity	Construction A: Field-Level Activities, Visit as Case	Construction B: Save Episodes, Actor Classes, Form and Query Objects
Resulting trace	One trace of 15 activities in time order: entered, entered, entered, query opened, value changed, query closed, value imported, query opened, verification completed, response, query reopened, value imported, value changed, response, query closed	13 events across four linked objects. Vital-signs form: saved → prompted correction → verified. Q1: opened → closed. Laboratory form: imported → repeat imported → original annotated. Q2: opened → response → reopened → response → closed
Apparent rework (changes after entry and reopenings counted)	3 (two value changes and one reopening)	The same three events, classified differently: one prompted correction of a transcription error (an error and corrective work did occur), one unprompted annotation that marks sample 1 as non-evaluable without altering a measured value, and one manual reopening of Q2 pending a repeat
Observed time span (rounded to days)	About 15 days from first to last recorded event in the visit trace; the last event is the closure of Q2, not a recorded completion of the visit	Vital-signs form: about 6 days from entry to verification; query Q2: about 13 days from opening to closure, of which about 7 days between reopening and arrival of the repeat result by transfer
“Change after review”	Raised only by a visit-level rule (any change after any verification in the visit): record 13 follows record 9. The same-object definition in Table 8 cannot be applied, because this construction discards form identity; a visit-level log that kept form identifiers as attributes could apply it	Not raised under the Table 8 definition: the verification concerned the vital-signs form and the later change the laboratory form. A relational query that keeps form identifiers would reach the same result
Ordering of records 1–3	Arbitrary; depends on the tie-breaking rule	Not needed; the records form one save episode

Conventional summaries computed directly from the original audit records are the same, regardless of which construction is used afterwards: two queries, two value changes with recorded reasons, one reopening, an interval of two days between the visit date and first entry, and a resolution time of 13 days for Q2. What differs is the interpretation that the sequence supports. Construction A, like the conventional summaries, counts two value changes and one reopening without distinguishing their triggers and shows a change after verification; construction B shows a system-prompted correction completed within 90 s, a laboratory-driven query that waited on an external repeat result, and no change after verification of the same form. Part of this distinction is available without process mining, from reasons for change and query text. The comparison therefore shows how much the interpretation depends on construction rather than demonstrating that process mining is superior to well-designed audit-trail queries: visit-level and object-level durations answer different questions, and the “change after review” result reflects whether object identity is retained, which a well-designed audit-trail query can also do. What the process view contributes is a representation in which the order of actions and their links to objects are kept together for every trace, so that construction choices are explicit and can be varied systematically; whether this improves on programmed audit-trail queries in practice is an empirical question.

The timestamps add a further choice. The two-day interval between visit and first entry compares a date-only clinical value with a precise system time (Table 4). At a site five hours behind coordinated universal time, record 1 was made at 09:02 local time on 4 March, so the elapsed time since the visit lies anywhere between about 1.4 and 2.4 days, depending on the unrecorded time of the visit. An illustrative rule requiring entry within 48 h could therefore be judged met or breached depending on the unrecorded visit time; at the available precision, compliance is indeterminate unless the rule itself is defined in calendar days.

Applying Figure 1 to construction B, the reopening of Q2 is a process signal (L2). Contextual interpretation (L3) supports an alternative explanation, because the query text records a haemolysed sample and a pending repeat. Verification (L4) would examine the laboratory reports for both samples to confirm the values and the haemolysis, but one question cannot be resolved from the trace at all: whether the initial potassium of 6.1 mmol/L required an adverse-event assessment. That question can be answered only by source and medical review, and until it is, the signal remains unresolved with respect to a safety-relevant outcome even though the trace suggests no data error. This example demonstrates the reasoning of the framework; it does not validate the framework, which requires evaluation against adjudicated outcomes (Section 12).

11. System Boundaries and Implications for Risk-Based Quality Management

An EDC audit trail records only actions performed in or transmitted to the EDC system. Monitoring visits; source-document review; site–sponsor communication; safety review; and reconciliation with laboratory, imaging, or electronic patient-reported outcome systems may take place partly or wholly elsewhere. FDA guidance assesses part 11 compliance once data enter the sponsor’s EDC system and treats originating EHR and other real-world data systems differently [4]. An EDC trace is therefore a partial representation of operational work, and an apparent period of inactivity may correspond to work documented in another system.

One plausible use of EDC process signals within risk-based quality management is to help prioritise human review, consistent with the role that ICH and FDA guidance give to centralised monitoring (Section 9) [2,30]. Risk-based monitoring components, including centralised monitoring, have been adopted in industry-sponsored trials [49], and central statistical monitoring already treats cross-site anomalies as prompts for investigation [45,46,47]. Process signals could complement these methods in a specific way. Central statistical monitoring compares the distributions of data values across sites, and the key risk indicators in common use summarise counts and durations; as usually implemented, neither represents the order of actions or the relations between forms, queries, and review events, although custom indicators could be built to do so. A process view could, for example, separate system-prompted from review-prompted corrections or distinguish waiting on external data from waiting on site action, making an existing indicator easier to interpret. These benefits are plausible but have not been demonstrated empirically.

Poorly calibrated signals carry costs. Each flagged pattern consumes reviewer time, may prompt queries or site contacts, and, if presented as a site metric, can be read as a judgement on site performance. Calibration is difficult. One set of fraud-detection risk scores was validated only for its false-positive rate, in a trial without fraud [52]. In a prospective matched-pair study of triggered monitoring, sites prioritised by triggers had only modestly higher rates of important findings than matched untriggered sites [50]. For exploratory or monitoring use, a cautious presentation would give reviewers each signal with its plausible alternative explanations and documented, study-specific escalation thresholds, with their validation status stated; it would also report the reviewer effort each signal generates and would avoid converting signals into site rankings or performance scores.

11.1. Data Privacy, Confidentiality, and Governance

EDC audit trails contain participant identifiers, user identities and roles, timestamps that can be linked to visits, free-text reasons for change, and query text that may include clinical details. Process mining adds further disclosure risk, because a sequence of events can identify a participant or a user even after direct identifiers are removed [76]. Analyses therefore need a defined purpose and legal basis, pseudonymisation of participant and user identifiers, minimisation of free text, and agreement with sponsors and sites on who may see user-level patterns. These constraints limit what can be shared between organisations and make independent replication difficult. Linkage to monitoring records, safety databases, or EHR data for verification adds governance requirements of its own. Synthetic event logs generated by simulation or generative models can support method development and replication without exposing trial data [44,77], although results obtained on synthetic data cannot establish that a method detects real quality problems.

11.2. Differences Between EDC Platforms

EDC platforms differ in how they structure audit trails, which components they export, how they label activities, and whether they record review, signature, and query events in the same log as data changes. The CDISC ODM provides a common structure for clinical data and their audit records [31], and healthcare work on HL7 FHIR AuditEvent resources shows how a standardised audit format can be mapped to process-mining formats [43], but neither standard defines EDC data-management workflows. EHR research shows the consequence of vendor-specific logging: measures of clinician activity offered by different vendors were found to differ in maturity and definition, limiting cross-vendor comparison [61]. The same is likely for EDC platforms. Findings from one platform should therefore not be assumed to generalise to another without mapping its audit structure, and cross-study comparison requires activity mappings that are published with the results.

12. A Feasible Evaluation Design for Future Studies

No study identified in the searches has shown that EDC process signals identify quality problems. An evaluation that could do so would include the following elements, adapted from evaluations of central and triggered monitoring [48,50,51] and from frameworks for validating audit-log measures in EHRs [62].

First, signals, their construction choices, and the outcome categories and criteria (Table 7) should be specified before analysis. Outcome criteria must add information beyond the signal. Where a signal is a timeline exceedance, for example, the outcome cannot be the same exceedance measured on the same timestamps; it must include the checks of applicability, timestamp meaning, and permitted exceptions described for operational delay in Table 7. Where the outcome criterion includes the signal’s exceedance as a necessary condition, every confirmed outcome is flagged, so sensitivity is 100% by construction and the evaluation chiefly estimates positive predictive value. Estimating sensitivity requires a reference review that can identify delays among unflagged units, for example, from source-document dates or from the item-specific timeline that actually applied. Second, verification should cover both flagged and unflagged units. Reviewing only flagged records can estimate how often a signal is correct (positive predictive value) but cannot show how many problems were missed; a stratified random sample of unflagged records, visits, or sites, reviewed with the same procedure, is needed to estimate sensitivity and specificity, with sampling weights applied in the estimates. Because important problems are usually rare, the unflagged sample must be large enough to observe missed problems, and the precision of the sensitivity estimate should be reported. A matched design, in which each flagged site is paired with a comparable unflagged site reviewed at the same time, is a feasible alternative [50]; it estimates the difference in yield between flagged and unflagged sites, but not population-level sensitivity or predictive values. Third, adjudicators should be blinded to whether a unit was flagged. A complementary protection applies to signal generation: analysts should not know the outcomes, as in an evaluation in which statisticians analysed submitted trial data without knowing which applications had failed inspection [51]. The two forms of blinding protect against different biases, and both should be reported. Fourth, signals that remain unresolved after verification should be reported as a separate category rather than counted as negative, and a sensitivity analysis should show how performance estimates change if they are counted as positive or negative. Fifth, the process-based approach should be compared with conventional methods applied to the same records, such as key risk indicators, standard audit-trail review use cases, or central statistical monitoring, in terms of additional confirmed problems, false positives, and reviewer hours per confirmed problem. Finally, the evaluation should span more than one study and, ideally, more than one EDC platform, and should report the effect of construction choices on its results. The illustrative signal definitions, thresholds, and synthetic example in this review are not validated and provide no evidence of predictive performance; establishing such performance is the purpose of the evaluation described here.

13. Proposed Reporting Items for Future Empirical Studies

Reporting guidance has been proposed for analyses of EHR audit-log metadata [28], but none was found for EDC audit-trail process mining. Table 11 proposes reporting items derived from the issues discussed above. Items 1, 2, and 9 adapt elements of the EHR audit-log reporting guidance [28] and process-mining project methodology [27]; items 3–8 and 10–12 are adapted to, or specific to, EDC audit trails and the interpretive framework. The items are conditional on the claim a study makes: essential items (E) apply to every study, whereas conditional items (C) apply when a study makes the corresponding claim, such as a claim to detect quality problems, which additionally needs an independent outcome reference. They have not undergone consensus development, are not a validated reporting guideline, and are offered as a starting point for expert consultation.

Table 11. Proposed reporting items for empirical studies of EDC audit-trail process mining (author-proposed; not validated or consensus-based). E, essential for all studies; C, conditional on the stated claim.

Domain	Item to Report	E/C
1. Question and intended use	Analytic question; whether results are descriptive, intended to support monitoring, or exploratory	E
2. Data source and extraction	EDC platform and version; study characteristics at a level that preserves confidentiality; governance and approvals obtained; export method and format (e.g., vendor export or CDISC ODM); audit components included; extraction date; records included and excluded	E
3. Event definition and log quality	Mapping from audit records to activities; handling of field-level changes from a single save, edit-check prompts, and system status changes; quality assessment, filtering, and cleaning, with their effect on the log	E
4. Case notion or object model	Case identifier(s) or object types and relations; justification; whether sensitivity to the case definition was assessed, how, and under what constraints	E
5. Actor and source classification	How human, system, and integration events were distinguished; role categories; handling of unclassifiable events	E
6. Timestamps	Time class represented by each timestamp; precision; time-zone and daylight-saving handling; ordering and tie-breaking rules; sensitivity of results to ordering	E
7. Versioning	Governing protocol, CRF, edit-check, role, and transfer or mapping versions for the analysed period; where results span a configuration or system change, linkage of events to versions, analysis of change periods, and known logging changes	E (governing versions); C (change analysis)
8. Completeness and boundary	Status of traces at cut-off and censoring-aware handling of durations; activities known to occur outside the EDC and any linked sources	E
9. Methods	Discovery, conformance, and performance methods; software and versions used; parameters; reference models, their provenance, versions, and expert validation	E
10. Signal definitions	Pre-specified signals and thresholds; candidate explanations considered for each	C: when signals are reported
11. Verification and outcome reference	Independent evidence used; outcome categories and criteria; adjudication process; blinding of adjudicators where feasible; sampling of unflagged units; handling of unresolved signals; agreement with signals, false positives, and reviewer effort; acknowledgement that review of flagged records alone cannot show how many problems were missed	C: when detection of quality problems is claimed
12. Reproducibility	Availability of transformation code, activity mappings, and of synthetic or de-identified example data where permitted; limitations and generalisability	E

Because audit-trail data can rarely be shared, reproducibility depends on publishing transformation rules, activity mappings, case or object definitions, ordering and censoring rules, software versions, and parameters, ideally with a synthetic log that reproduces the structure of the export (Section 11.1).

14. Discussion

In EDC audit-trail process analysis, event-log construction and signal interpretation require explicit justification alongside the choice of discovery algorithm. Regulators expect audit trails to be interpretable, exportable for pattern review, and reviewed on a risk basis [2,3,4], but none of their documents addresses process-mining methods. Process mining, for its part, supplies the means to construct event logs, check conformance, and handle multiple objects [15,35,36]. In the identified sources, the regulatory texts and the methodological literature rarely refer to each other, yet the questions that connect them (what counts as an event, what counts as a case, and against which model a trace should be judged) are important methodological vulnerabilities in EDC analyses.

Table 12 separates what the reviewed literature supports from what this review infers and from what remains a hypothesis for empirical work. The literature establishes that log construction changes reconstructed processes and indicates that audit records need semantic enrichment before process analysis, that timestamps and case identifiers are frequent sources of error in healthcare logs, and that statistical monitoring signals are prompts rather than findings. That the same mechanisms operate in EDC audit trails is an inference from shared features, not an observed result. That process signals can improve the detection of quality problems, or reduce reviewer effort, is a hypothesis.

Table 12. Synthesis linking identified gaps to the review’s recommendations and to the validation each recommendation requires. Gaps are those identified in the sources reviewed, except where marked as risks inferred by the review.

Identified Gap	Recommendation in This Review	Validation Required
No documented method for building EDC event logs from audit trails identified	Transformation operations with checks (Table 3); construction choices and sensitivity checks (Table 5)	Application to real exports from more than one platform; inter-analyst agreement on constructed logs
No identified EDC study reporting or testing case notion and abstraction choices	Pre-specification and comparison of alternative constructions (Section 10.4)	Empirical measurement of how much conclusions change across constructions
Guidance addresses timestamp content and time zones, but no identified source addresses ordering uncertainty and censoring in EDC process analysis	Time classes (Table 4); ordering sensitivity and censoring-aware durations (Section 6)	Quantification of ordering uncertainty and censoring bias in real logs
Risk that configuration and logging changes are confounded with process change (inferred)	Version linkage and diagnostic comparison with release dates (Section 8)	Case studies of known configuration and logging changes
Risk that process signals are read as findings (inferred)	Levels of inference with transition criteria (Table 6); outcome categories (Table 7)	Evaluation against blinded, independent adjudication (Section 12)
No identified evidence that process signals add value to existing monitoring	Comparison with conventional methods on the same records (Section 12)	Incremental yield and reviewer effort compared with key risk indicators and statistical monitoring
No reporting guidance for EDC audit-trail process studies identified	Conditional reporting items (Table 11)	Expert consultation and consensus development

A prioritised research agenda follows from this synthesis. The first priority is evaluation against independently adjudicated outcomes, using flagged and unflagged samples, because without it, no signal can be recommended for routine use. The second is empirical sensitivity analysis of construction decisions on real audit exports, which would show which choices matter most and should be standardised. The third is comparison of case-centric and object-centric representations on the same data. The fourth is assessment of operational usefulness within risk-based monitoring, including reviewer effort and the burden on sites. The fifth is consensus development of reporting items with data managers, monitors, statisticians, and process-mining researchers.

As EHR audit-log research grew, investigators came to rely increasingly on vendor-derived measures [13], and calls for validation and reporting guidance followed [14,28]. EDC audit-trail analytics could follow a similar path if vendors and sponsors build dashboards over audit data, which argues for explicit definitions of events, cases, and signals before routine use.

15. Limitations

Because this is a narrative review, source identification and appraisal were not exhaustive, and relevant work may have been missed, particularly conference proceedings, non-English publications, and industry reports outside scholarly indexes. The documented searches covered PubMed and the first 50 relevance-ranked proceedings records in each of two Crossref searches; Scopus, Web of Science, IEEE Xplore, and the ACM Digital Library were not searched directly, and screening and appraisal were done by a single author without formal risk-of-bias assessment. Because direct evidence is sparse, the selection of sources may be biased towards literature indexed in the searched resources, towards the most relevance-ranked conference records, and by the judgement of a single screener. Direct EDC and audit-trail sources are used where available, but much of the methodological evidence comes from healthcare process mining and EHR audit-log research and is applied here by analogy; accordingly, direct EDC and regulatory evidence is distinguished from analogical healthcare and EHR evidence in Table 1 and Supplementary Table S1. Industry guidance on audit-trail review is not peer-reviewed. EDC platforms differ in audit-trail structure and export capability, and no specific system was assessed. The framework, interpretation table, and reporting items have not been tested empirically or through formal consensus methods. No real EDC export was analysed, so the predictive performance of the signals the framework organises remains hypothetical until they are evaluated on real exports against independent adjudication, as proposed in Section 12. The five levels are a logical organisation of existing principles rather than an empirically derived model, and the worked examples, including the synthetic event log, are single hand-constructed cases. Their generalisability is uncertain across trial designs (for example, decentralised trials with substantial electronic patient-reported data or trials with direct EHR-to-EDC transfer), across EDC platforms and study configurations, and across organisations with different data-management practices, in which the meaning and frequency of recorded activities may differ.

16. Conclusions

EDC audit trails contain sequential and temporal information that can support reconstruction of the recorded aspects of data-management workflows. Process-mining and healthcare research shows that the meaning of a reconstructed pattern depends on how events and cases were defined, what the timestamps represent, and whether traces were complete. That the same holds for EDC audit trails, with the added effects of human and system actors, configuration versions, and the system boundary, is inferred from shared features rather than observed directly. Delays, reopened queries, correction loops, unusual variants, and conformance differences are process signals; they should not be read as evidence of data-quality failure, noncompliance, or poor site performance without contextual interpretation and independent verification, which may establish a problem, support an alternative explanation, or leave the signal unresolved. The review contributes an EDC-specific set of construction checks, a framework with explicit criteria for moving from signal to outcome, a synthetic demonstration that defensible construction choices change conclusions drawn from identical records, and an evaluation design and proposed reporting items. Whether audit-trail process analysis helps identify clinically or operationally meaningful quality problems within risk-based quality management remains to be established; until its signals are evaluated on real EDC exports against independent adjudication, their predictive performance should be regarded as hypothetical.