Why AI in Clinical Trials Still Needs Human Judgment
AI can produce convincing answers even when information is incomplete, ambiguous or wrong. Clinical trials therefore need more than technically capable models. They need defined use cases, controlled inputs, documented review and clear accountability. Convincing Errors AI systems can generate statements that sound plausible but are not supported by the source information. In clinical trials, this can affect data interpretation, statistical methods, process requirements, regulatory statements, coding decisions and risk assessments. Missing Context AI may not understand study-specific conventions, operational history, informal decisions, sponsor expectations, protocol intent, why a deviation was accepted or which source is authoritative. Human review is needed to place outputs in the correct context. Data Privacy and Confidentiality Clinical trial data may contain confidential, sensitive or personal information. AI use therefore requires careful control of uploaded content, user access, data storage, retention, third-party processing, contractual requirements and anonymisation or pseudonymisation. Bias and Incomplete Information AI output depends on its training data and the information provided. Incomplete inputs can lead to incomplete or biased conclusions. Fitness for Purpose Not every AI tool is suitable for every task. The required level of control depends on the intended use, the risk of an incorrect output, whether the result affects study data, whether it influences a regulatory decision, whether the output is advisory or operational and whether the result can be independently verified. Validation and Testing AI-supported workflows may require defined acceptance criteria, representative test cases, error handling, documented limitations, human review steps, audit trails, change control and periodic performance checks. Accountability AI can support preparation, comparison and prioritisation. It cannot take responsibility for approving a document, closing a query, changing study data, selecting a statistical method, determining compliance, declaring database-lock readiness or making a sponsor decision. Conclusion The value of AI in clinical trials depends not only on what the tool can do, but on how responsibly it is used.
AI for SOPs and Quality Processes
SOP systems contain large amounts of text, dependencies and recurring requirements. AI can help locate information, compare documents and identify possible inconsistencies. It should not independently approve a procedure or determine compliance. SOP Review A controlled AI-supported SOP review could use a predefined checklist, search the SOP for relevant passages, extract matching text, document source locations, highlight missing or unclear content and present findings to the reviewer. The reviewer then decides whether the finding is relevant and whether changes are needed. Comparison of Documents AI can help compare SOPs, work instructions, Data Management Plans, Statistical Analysis Plans, templates, process descriptions and training materials. This can reveal inconsistent terminology, missing responsibilities or conflicting process steps. Gap Analysis AI may support gap analyses by identifying missing sections, undefined roles, incomplete escalation paths, inconsistent timelines, unclear approval steps, missing documentation requirements and differences between procedures and operational plans. Training Materials AI can help create role-specific summaries, training questions, short process explanations, practical examples, checklists and refresher materials. These materials still need to be checked against the approved SOP. Inspection Readiness AI can support inspection readiness by helping teams locate evidence, compare required and available documents, organise checklists, identify missing records, summarise process changes and prepare document inventories. Traceability For controlled use, the workflow should document which documents were reviewed, which AI version or tool was used, which prompts or rules were applied, which passages were identified, who reviewed the findings and what decision was made. Conclusion AI can reduce the time required to search and compare large document sets. But quality decisions still require professional judgment.
AI in Biostatistics and Statistical Programming
AI can generate code, suggest statistical approaches and help structure analysis documents. But producing code is not the same as producing reliable statistical evidence. In regulated work, results must remain understandable, reproducible, reviewed and traceable. Statistical Analysis Plans AI can support SAP structure, first drafts of standard sections, consistency checks, alignment with protocol endpoints, wording of analysis methods and identification of missing definitions. The statistical reasoning and final decisions must remain with the statistician. TLF Planning AI can help prepare TLF shells, programming specifications, population definitions, proposed display structures, standard footnotes and consistency checks between SAP and outputs. Programming Support AI can assist with R or Python code generation, syntax conversion, code explanation, debugging, documentation, repetitive programming tasks and draft test cases. Generated code must still be reviewed, tested and validated for its intended use. Quality Control AI can support QC by suggesting test cases, identifying inconsistencies, comparing specifications and outputs, highlighting suspicious results, checking naming conventions, preparing review checklists and explaining differences between two implementations. Reproducibility and Traceability Every AI-supported result needs documented inputs, version-controlled code, clear specifications, review records, reproducible execution, appropriate testing and defined responsibility. Interpretation AI may help summarise results, but it can miss study context, overstate conclusions or produce convincing but incorrect explanations. Interpretation therefore remains a professional responsibility. Conclusion AI can accelerate programming and documentation, but reliability depends on review, testing and traceability.
AI in Sponsor Oversight: Using Limited Resources Where They Matter Most
Sponsor Oversight often involves large amounts of information from CROs, vendors, sites and internal teams. The difficulty is not simply collecting more information. It is recognising which signals matter, where risks are developing and where expert attention is needed. AI can help summarise information, identify patterns and support the prioritisation of oversight activities. Bringing Information Together Sponsors may receive information through status reports, meeting minutes, risk logs, issue trackers, vendor reports, data-quality reports, milestone plans, email communication and dashboards. AI can help structure these different sources and bring related information together. Identifying Emerging Risks Individual issues may not appear critical when viewed separately. A delayed reconciliation, recurring query pattern, missed milestone and repeated action item may together indicate a developing study risk. AI can help identify these connections earlier. Summarising Status and Actions AI can support concise summaries showing what has been completed, what is delayed, what is at risk, what requires a decision, who owns the next action and which issues remain unresolved. This reduces the time required to review long and fragmented reports. Prioritising Expert Attention Oversight resources are often limited. Not every issue requires the same level of attention. AI can help teams focus on high-impact risks, unresolved critical actions, repeated problems, cross-functional dependencies, issues affecting timelines or data quality and decisions requiring sponsor involvement. Risk-Based Oversight AI can support risk-based oversight by helping teams review trends rather than isolated data points. The purpose is not to automate sponsor responsibility. It is to improve the use of limited oversight time. Connection to Octovis In combination with a structured dashboard such as Octovis, AI-supported summaries and risk signals could help sponsors see current study status, data-quality trends, key risks, delayed deliverables, unresolved actions and areas requiring intervention. The value lies in turning scattered information into clearer priorities. Conclusion AI can support Sponsor Oversight by helping teams recognise important signals earlier and use limited resources more effectively.
AI in Clinical Data Management: Where the Real Potential Lies
Clinical Data Management contains many repetitive review, comparison and coordination tasks. This makes it one of the areas in clinical trials where AI can provide immediate practical support. The greatest potential is not autonomous data management. It is helping Data Managers find relevant information faster, prioritise review activities and spend more time making decisions instead of searching. Protocol Review and Data Requirements AI can support the structured review of protocols by identifying endpoints, visits and time windows, eligibility criteria, safety-relevant data, required assessments, possible inconsistencies and missing or unclear data requirements. This can give the Data Manager a structured starting point for CRF design and database planning. CRF and eCRF Review AI can help compare protocol requirements with planned CRF content. Possible use cases include identifying protocol requirements that are not represented in the CRF, finding duplicate or unnecessary data collection, checking whether visit structures are consistent, suggesting clearer field labels or completion instructions and comparing CRF versions. The final design decision must remain with the Data Manager and the study team. Edit-Check Suggestions AI can support the preparation of edit-check specifications by suggesting range checks, missing-data checks, date consistency checks, cross-form checks, visit-sequence checks and protocol-specific checks. These suggestions still need to be assessed for relevance, feasibility and the risk of unnecessary queries. Data Cleaning and Query Prioritisation AI can help structure open data issues according to their relevance. Examples include issues affecting primary endpoints, safety-related discrepancies, long-standing queries, repeated issues at the same site, data that may block analysis, reconciliation differences and unusual patterns across subjects or visits. This can help Data Managers use limited review time more effectively. Query Management AI may support grouping similar queries, identifying duplicate queries, improving query wording, classifying queries by topic, summarising recurring site issues and identifying potential root causes. AI should not automatically close queries or make final data decisions. Reconciliation Support Potential use cases include AE/SAE reconciliation, laboratory-data reconciliation, coding reconciliation, external-data comparison, ePRO or eCOA reconciliation and comparison between EDC, SDTM and external sources. AI can help identify likely matches and explain differences, but the final assessment still requires human review. Document and Metadata Review AI can support the comparison of protocols, Data Management Plans, CRF specifications, edit-check specifications, SOPs, work instructions, metadata and mapping specifications. A controlled workflow could provide a predefined checklist, locate relevant passages and present the findings to the reviewer. Conclusion AI can reduce time spent on searching, sorting and preparing information. It can help Data Managers focus on the areas where professional judgment is most valuable.
Change Control, Database Lock and Archiving
Clinical trial databases change. Protocol amendments, clarified requirements, new edit checks, revised external-data specifications and operational findings may all require updates during the study. The objective is not to avoid every change. It is to ensure that each change is justified, assessed, tested, approved and traceable. Small changes can create wide consequences A seemingly simple field change may affect data entry, edit checks, exports, mappings, listings, statistical programs, reconciliation and documentation. Change control should therefore consider the full chain rather than only the screen being modified. Database lock is a readiness decision Database lock should confirm that predefined review and reconciliation activities are complete. It should not be the moment when the team first discovers unresolved study-wide problems. A lock-readiness process may include: The decision should be based on defined criteria and visible evidence, not on general confidence that the study is probably ready. Archiving protects the story of the data Archiving is more than storing the final database. It preserves the evidence needed to understand how the data were collected, reviewed, changed and finalised. Conclusion Controlled change, visible lock readiness and complete archiving protect both the final analysis and the credibility of the process that produced it.
From Protocol Intent to EDC Reality
A protocol describes what a clinical study intends to evaluate. An EDC system must turn that intent into visits, forms, fields, workflows, checks and user actions that work under real study conditions. This translation is where many avoidable problems begin. A database may be technically functional and still fail to support the study effectively if its design does not reflect how sites enter data, how reviewers work and how downstream teams use the information. CRF design is more than placing fields on a form A good CRF collects the information needed for the protocol and analysis while remaining clear and practical for sites. It should minimise ambiguity, unnecessary duplication and avoidable free text. Edit checks should support data quality, not create noise Edit checks are valuable when they identify meaningful inconsistencies early. They become counterproductive when they generate large numbers of low-value queries, repeat checks that are already covered elsewhere or do not reflect study context. A proportionate edit-check strategy considers the importance of the data, the likelihood of error, the possibility of independent verification and the operational burden placed on sites and reviewers. External data must be planned as part of the database design Laboratory data, ePRO/eCOA, imaging, safety systems and other external sources should not be treated as late technical imports. Identifiers, transfer schedules, formats, reconciliation rules and ownership need to be defined before data begin to arrive. UAT must test realistic workflows User Acceptance Testing should not be limited to confirming that forms open and fields save. It should test realistic study scenarios, including expected and unexpected user behaviour. UAT is also a communication test. It shows whether protocol, Data Management, statistics, clinical operations and vendors have interpreted the requirements in the same way. Conclusion A successful EDC build is not simply technically correct. It supports the real work of sites, reviewers and downstream teams. The closer database design and UAT reflect actual study workflows, the fewer surprises appear during conduct.
Live Data Review and Data Cleaning: Where Oversight Really Matters
Data cleaning is often described as a process of generating and resolving queries. That description is too narrow. Effective data cleaning combines ongoing review, prioritisation, communication and oversight. It asks not only whether individual values are plausible, but whether the study is progressing toward a complete, consistent and analysis-ready database. Data review should begin while the study is running Waiting until close-out to understand data quality creates avoidable pressure. Live review helps teams identify missing assessments, delayed entry, repeated site errors, coding backlogs, unresolved queries and reconciliation differences while corrective action is still possible. Cleaning is more than query counts A dashboard showing the number of open queries can be useful, but it does not automatically show risk. Ten routine queries may matter less than one unresolved discrepancy affecting a primary endpoint or serious adverse event. Meaningful review therefore considers context: Query management needs consistency and judgment Queries should be clear, respectful and answerable. They should request only the information needed to resolve a meaningful discrepancy. Poorly designed queries create site burden without improving data quality. Review teams should also look for systemic causes. Repeated queries may indicate unclear CRF instructions, ineffective edit checks, insufficient training or a design problem rather than poor site performance. Reconciliation connects separate views of the same event Safety, laboratory, coding and external-data reconciliation are not isolated close-out activities. They are ongoing comparisons between systems that may describe the same subject, event or assessment differently. The objective is not merely to make two systems identical. It is to understand and document legitimate differences, correct errors and ensure that important information is complete and consistent across sources. Where oversight adds value Oversight connects operational details to the wider study picture. It helps teams see whether issues are isolated or recurring, whether timelines are at risk and whether limited expert resources are focused on the most important areas. Octovis can support this by bringing together status information, data-quality indicators, risks, deliverables and unresolved actions. The value is not simply another report. It is a clearer basis for prioritisation and decisions. Conclusion Good data cleaning is continuous, risk-aware and connected across functions. It makes important problems visible early enough to manage them without turning every discrepancy into an emergency.
Why Clinical Data Management Starts Before the First eCRFIs Built
Clinical Data Management is sometimes treated as a function that begins when the database is ready for data entry. In reality, many of the most important data-quality decisions are made much earlier. Before the first eCRF is built, the protocol already defines what the study intends to measure, when assessments should take place and which information will support safety and efficacy conclusions. If these requirements are unclear, inconsistent or difficult to operationalise, the problem does not disappear during database build. It usually returns later as missing data, ambiguous queries, protocol deviations, reconciliation issues or analysis limitations. Protocol review as a data-management activity A Clinical Data Management review should look beyond whether a protocol is medically or statistically plausible. It should ask whether the planned information can be collected consistently and translated into usable data. The Data Management Plan as an operational framework The Data Management Plan should not be a generic document completed after the database design is largely fixed. It should describe how the study will handle data collection, review, query management, coding, reconciliation, external data, changes, lock readiness and archiving. A useful DMP turns responsibilities and expectations into an operational framework. It should make clear who reviews which information, how often reviews occur, what evidence is retained and how unresolved issues are escalated. From data requirements to annotated CRF An annotated CRF and related specifications create the bridge between protocol intent and downstream datasets. Early decisions about field structure, terminology, formats, units and origins influence edit checks, exports, SDTM mapping, programming and final analysis. This is also the stage where unnecessary data collection should be challenged. Every additional field creates work for sites, Data Management, monitoring, programming and review. Collecting more data does not automatically create better evidence. What auditors and inspectors may later ask Later review often focuses not only on the final data, but on whether the process was planned, controlled and traceable. Teams should be able to explain why data were collected, how important variables were reviewed, which standards were applied and how changes were handled. Conclusion Good Clinical Data Management begins before the first eCRF is built. Early involvement helps translate the protocol into a data process that is clear, proportionate and fit for purpose.