Real-Time Clinical Trials: A Concept Change?

The FDA announcement on Real-Time Clinical Trials looks important because it is not only about one new digital feature or one more modernization initiative. It questions the traditional rhythm of clinical development.

Real-Time Clinical Trials describe a model in which clinical, operational, quality, and safety data are continuously integrated and analysed throughout the study, enabling proactive oversight and timely decision-making instead of relying primarily on periodic monitoring and retrospective review.

https://www.fda.gov/news-events/press-announcements/fda-announces-major-steps-implement-real-time-clinical-trials

For many years, the clinical trial process has followed a familiar sequence. A study is designed. Sites collect data. Data are entered, cleaned, queried, reviewed, analyzed, summarized, and finally submitted to the regulator. The regulator then reviews the evidence after a significant part of the operational and analytical work has already happened.

This model is familiar, but it is slow. It also creates delay between what is happening in the study and when key decision-makers can see and interpret the information.

The FDA’s Real-Time Clinical Trials initiative appears to challenge this sequence.

The main idea is simple: if important safety signals, endpoints, and data trends can be seen earlier, then the development process may become faster, more efficient, and potentially safer. Instead of waiting until the end of the study or until a full submission package is prepared, selected information could become visible while the trial is still running.

This is why the concept is interesting.

It is not only “real-time data.” It is a different timing of oversight and decision-making.

Why this may be transformational

Clinical trials are often discussed as scientifically complex, but the FDA video also points to an operational reality that many people in clinical research know very well: manual data entry, fragmented systems, paperwork, and delayed information flow.

This is not a small administrative problem. It affects timelines, cost, oversight, and the ability to identify issues early.

If clinical trial data move slowly from sites to sponsors, from systems to reports, and from reports to regulators, then decisions are delayed. Safety signals may be detected later than technically necessary. Strong efficacy trends may also be recognized later than necessary. Development decisions may wait for consolidation of data that already exist somewhere in the system.

RTCT is therefore transformational because it focuses on the time gap between data generation and regulatory visibility.

The traditional model is retrospective from the regulator’s perspective. RTCT introduces the idea of more continuous visibility.

This does not mean that every piece of raw trial data is automatically sent to the FDA. The practical concept appears to be more focused: agreed safety signals, endpoint signals, and decision-relevant data becoming visible earlier.

Still, even this limited change is significant.

Once endpoints and safety signals can be reviewed closer to real time, the clinical trial is no longer only a delayed evidence package. It starts to become a live evidence flow.

What problem is RTCT trying to solve?

The problem is not only that clinical trials take many years. The problem is also that clinical development contains many pauses, handovers, reconciliations, and waiting periods.

Data are collected at sites. Then they are entered or transferred into systems. Then data are cleaned. Queries are resolved. Listings are reviewed. Analyses are prepared. Submission documents are written. Regulators then review structured packages after the fact.

Each step may be necessary, but each step adds delay.

RTCT tries to reduce part of this delay by allowing earlier visibility into selected trial signals.

The most immediate expected benefits are:

Potential benefit	Practical meaning
Earlier safety signal detection	Important safety trends may be recognized sooner.
Earlier efficacy visibility	Strong endpoint signals may be seen before the traditional full reporting cycle.
Faster decision-making	Sponsors and regulators may be able to make development decisions earlier.
Reduced development cycle time	Less waiting between evidence generation and regulatory interpretation.
Less administrative delay	Manual reporting, paperwork, and delayed consolidation may become less central.
Better use of AI and data science	AI may support signal detection, monitoring, and decision quality if properly governed.

This is why RTCT may matter not only for regulators, but also for sponsors, CROs, sites, patients, and clinical operations teams.

A change from correction to prevention

RTCT also fits a broader shift in clinical research: moving from late correction to earlier prevention.

In the traditional model, many issues are identified after they have already happened. Protocol deviations, missing data, delayed safety review, inconsistent data entry, and operational trends may be corrected retrospectively.

But correction is usually more expensive than prevention.

If the trial can show signals earlier, then oversight can also move earlier. This may help identify emerging safety issues, endpoint trends, operational problems, and study conduct risks before they become larger study-level problems.

This does not remove the need for monitoring, data management, statistics, medical review, or quality oversight. But it may change the timing and focus of these activities.

The question becomes less:

“What happened in the trial after we cleaned and reviewed everything?”

And more:

“What is emerging in the trial now, and do we need to act?”

What RTCT does not automatically solve

RTCT sounds powerful, but real-time visibility does not automatically improve data quality.

Real-time bad data are still bad data.

If source data are incomplete, if site workflows are fragmented, if EDC entries are delayed, if laboratory data are not integrated, or if deviations are inconsistently classified, then real-time reporting may simply expose the same problems earlier.

This is important.

RTCT can reduce delay, but it cannot by itself solve all operational fragmentation. It may even make fragmentation more visible.

For example:

Existing issue	What RTCT may change
Manual data entry	RTCT may create pressure to reduce duplicate entry and late reporting.
Fragmented systems	RTCT may require better system integration and clearer data flows.
Paperwork and delayed reporting	RTCT may shift focus toward structured, earlier signal reporting.
Inconsistent deviation tracking	RTCT may expose the need for more standardized operational metadata.
Data cleaning after the fact	RTCT may require higher quality earlier in the process.

This means RTCT is not only a regulatory concept. It is also an operational maturity test.

A sponsor or site cannot become real-time only at the point of reporting to FDA. The underlying data flow must be ready earlier.

Possible tensions

The RTCT concept is promising, but several tensions remain.

The first is speed versus evidence maturity. Faster visibility is useful, but early signals need interpretation. Not every signal is meaningful. Some signals may be immature, incomplete, or affected by missing data, site differences, or operational artifacts.

The second is automation versus accountability. AI may help detect patterns, but clinical and regulatory decisions still require responsibility. If an AI-supported system detects a signal, someone must decide whether it is clinically meaningful, statistically reliable, and actionable.

The third is transparency versus confidentiality. Commercial sponsors may have concerns about protocol details, interim signals, endpoint trends, operational performance, and development strategy. Non-commercial or academic trials may have different sensitivities, but confidentiality, patient privacy, and governance still matter.

The fourth is real-time oversight versus operational burden. If RTCT creates another reporting layer on top of existing systems, it may increase workload. If it replaces delayed manual reporting with better integrated data flows, it may reduce burden. The difference will depend on implementation.

The fifth is standardization versus site reality. Clinical trials are conducted across very different hospitals, clinics, investigators, EHR systems, laboratory processes, staffing models, and vendor platforms. Real-time oversight requires structured data, but clinical trial execution remains heterogeneous.

These tensions do not mean RTCT is a bad idea. They show why implementation will matter.

Why the name matters

The concept is called Real-Time Clinical Trials, not only real-time signal reporting.

This name suggests something broader than a technical data feed. It suggests that the clinical trial itself may become more continuously observable and more connected to development decisions.

At the same time, the current practical starting point appears focused and controlled: selected endpoints and safety or data signals reported earlier.

This may be the right starting point. A narrow first step may be more realistic than attempting to redesign all clinical trial infrastructure at once.

But even a narrow RTCT model may create a wider concept change.

It moves clinical trials from delayed evidence reporting toward earlier evidence visibility.

Why clinical operations should pay attention

RTCT is sometimes discussed as an FDA, AI, or data science initiative. But clinical operations should pay close attention.

Real-time signals depend on operational reality.

They depend on whether sites enter data on time. They depend on whether laboratory data are connected. They depend on whether protocol deviations are captured consistently. They depend on whether endpoint data are complete and reliable. They depend on whether manual trackers, spreadsheets, emails, and disconnected systems can support earlier decision-making.

If operational data are fragmented, RTCT will not remove fragmentation by itself.

It may instead reveal it.

This is why RTCT should not be understood only as a regulatory modernization project. It is also a challenge to the way clinical trials are built, conducted, monitored, and documented.

A practical interpretation

In practical terms, RTCT may be understood as a move from delayed reporting to earlier signal visibility.

It may help answer questions such as:

Are safety signals emerging earlier than expected?

Is the endpoint trend becoming visible?

Are operational risks affecting trial conduct?

Are deviations, missing data, or delays becoming pattern-level problems?

Can development decisions be made sooner?

Can unnecessary waiting between phases be reduced?

These are important questions because they connect scientific decision-making with operational execution.

Conclusion

Real-Time Clinical Trials may become one of the more important clinical development concepts because it challenges the traditional delay between trial conduct and regulatory visibility.

The immediate promise is clear: catch signals earlier, improve safety monitoring, reduce unnecessary delay, and make drug development more efficient.

But the deeper challenge is operational.

Real-time clinical trials require real-time readiness. Data quality, system integration, deviation tracking, endpoint clarity, safety review, and operational oversight must work earlier in the study lifecycle.

RTCT may therefore be more than a faster reporting mechanism.

It may be a concept change from retrospective evidence packaging toward continuous evidence visibility.

The opportunity is faster and more efficient drug development.

The risk is assuming that real-time access alone solves the underlying problems of manual work, fragmented systems, delayed reconciliation, and inconsistent data quality.

Real-time clinical trials will not only test new regulatory processes. They may also test whether clinical trial operations are ready for a more connected and transparent future.

Six Sigma: Refusing to Measure - Refusing to Improve

The Hidden Cost of “Fixing It Later” in Clinical Research

Clinical research quality is usually discussed in the language of compliance: GCP, inspection readiness, audit findings, protocol deviations, CAPA, TMF completeness, and data integrity. This language is necessary. Clinical trials must protect participants, produce reliable results, and withstand regulatory and scientific scrutiny.

A clinical trial may appear compliant at the end, but only after thousands of queries, repeated document corrections, email clarifications, monitoring follow-ups, vendor reconciliations, TMF quality-control rejections, and late-stage remediation activities. The final clinical study report may be based on acceptable data, but the operational question remains: how much rework was required to make the data, documents, and reports correct?

This is where Six Sigma thinking becomes useful.

Six Sigma does not need to be copied mechanically from manufacturing into clinical trials. Clinical research is more variable, more regulated, and more dependent on clinical judgement than most production processes. A patient visit is not a manufactured product, and a protocol deviation is not the same thing as a defect in a machine part. Nevertheless, Six Sigma offers a useful measurement discipline: define the unit, define the defect, define the opportunity for error, measure process performance, and translate poor quality into cost.

Many of the necessary measurement signals already exist in EDC, TMF, laboratory systems, spreadsheets, and emails. The challenge is to connect these signals and use them to measure quality, rework, and process improvement, potentially with AI assistance.

Why Six Sigma Is Relevant, but Not Widely Used, in Clinical Research

Lean Six Sigma has been widely discussed in healthcare, especially in relation to patient flow, waiting times, laboratory processes, hospital administration, operating room efficiency, pharmacy workflows, and documentation processes. The healthcare literature shows that Lean Six Sigma is often applied not only to medical care itself, but also to management and administrative processes. This is important for clinical research, because clinical trials contain a large amount of administrative, documentary, financial, and cross-functional operational work.

Clinical research has many process problems that are comparable to healthcare operations, but they are often less visible. A hospital can observe waiting time in an emergency department. A clinical trial may experience the same type of delay through site activation delays, unresolved EDC queries, late monitoring reports, missing TMF documents, delayed vendor reconciliation, or postponed database lock.

The literature on Lean Six Sigma in healthcare is broader than the literature on Lean Six Sigma in clinical trials. Still, several publications have discussed the applicability of Lean and Six Sigma to clinical and translational research, and industry publications have also considered Lean Six Sigma as a way to improve clinical trial efficiency, reduce rework, and improve data quality.

In parallel, modern clinical trial quality management has moved toward related concepts such as Quality by Design, Critical-to-Quality factors, Risk-Based Quality Management, Quality Tolerance Limits, and Key Risk Indicators. These are not identical to Six Sigma, but they share a similar logic. Important processes should be defined, measured, monitored, and improved. Quality should be built into the trial process rather than inspected only at the end.

This makes Six Sigma relevant to clinical research not as a slogan, but as a question:

How capable is the clinical trial process of producing correct, complete, timely, and usable outputs the first time?

Six Sigma Metrics and Possible Clinical Research KPIs

Before discussing the example in detail, it may be useful to translate several Six Sigma concepts into clinical research process language. The objective is not to claim that clinical trials should be managed as manufacturing processes. The objective is more practical: to define what can be measured, where defects occur, how often they occur, and how much rework they create.

Six Sigma concept	Meaning in process quality	Possible clinical research KPI
Unit	The item or process output being evaluated	One source document, one patient visit, one eCRF form, one TMF document, one monitoring report, one site activation package
Defect	A failure to meet a defined requirement	Missing data, wrong date, incomplete source entry, unresolved query, incorrect TMF metadata, missing signature, inconsistent value between systems
Opportunity	A specific place where a defect could occur	Each required field, signature, date, data point, document attribute, transfer step, QC check, or reconciliation point
DPU — Defects per Unit	Number of defects per evaluated unit	Defects per source document, queries per eCRF form, QC findings per TMF document, monitoring findings per visit
DPO — Defects per Opportunity	Number of defects divided by all possible defect opportunities	Defects divided by total required fields, checks, signatures, metadata points, or reconciliation items
DPMO — Defects per Million Opportunities	Standardized defect rate allowing comparison across processes of different complexity	EDC data-entry defects per million fields, TMF metadata defects per million attributes, reconciliation discrepancies per million transferred values
RTY — Rolled Throughput Yield	Probability that the process passes through all steps without rework	Probability that information moves from source document to EDC, query closure, vendor reconciliation, TMF filing, reporting, and final project delivery without avoidable correction
COQ — Cost of Quality	Total cost of prevention, appraisal, internal failure, and external failure	Cost of training, monitoring, QC, audits, system validation, remediation, CAPA, re-monitoring, and delayed reporting
COPQ — Cost of Poor Quality	Cost that would not exist if work were done correctly the first time	Cost of avoidable queries, email clarification, TMF rejections, duplicate entry, late correction, remediation, delays, and budget overrun caused by rework

This translation is important because clinical research teams often measure activities but not necessarily process capability. For example, a team may know how many monitoring visits were completed, how many queries were open, or what percentage of TMF documents were filed. However, these numbers do not always show whether the process is producing correct outputs the first time, or whether quality is being achieved only through repeated correction.

From a Six Sigma perspective, the more interesting question is not only how many activities were performed. The more interesting question is how many times the process had to be corrected before the final output became acceptable.

The first concept is the unit. In clinical research, a unit can be one source document, one patient visit, one eCRF form, one laboratory result, one adverse event record, one informed consent form, one monitoring visit report, one TMF document, one site activation package, or one protocol deviation. The choice of unit matters because a process can only be measured consistently when it is clear what is being evaluated.

The second concept is the defect. A defect is any failure to meet a defined requirement. In clinical research, this could be a missing value, wrong date, late data entry, inconsistent data between systems, missing source documentation, missing signature, incorrect document version, incorrect TMF metadata, unresolved query, repeated query, missing medical review, late safety reporting, insufficient protocol deviation description, unresolved monitoring finding, or document rejected during TMF QC.

However, clinical research should not count all defects as equal. A missing administrative date, a missing safety assessment, and a data inconsistency affecting the primary endpoint do not have the same significance. Defects may need to be classified by severity, detectability, recurrence, and impact on patient safety, data integrity, reporting, audit readiness, and financial performance.

The third concept is the opportunity. An opportunity is a defined place where a defect could occur. One source document may contain 50 required fields, each representing an opportunity for a missing, incorrect, inconsistent, or unclear value. One TMF document may have several required attributes: correct document type, correct country, correct site, correct date, correct version, correct signature, correct filing location, and correct naming convention. Each attribute is an opportunity for error.

This distinction matters because processes differ in complexity. A short follow-up visit and a complex oncology screening visit should not be compared only by the number of errors. A complex visit has more opportunities for defects. Similarly, a simple administrative document and a multi-country regulatory package should not be compared without considering the number of required elements.

Defects per Unit, or DPU, measures how many defects are found per unit. For example, if 100 source documents are reviewed and 60 total defects are found, the DPU is 0.6 defects per source document. In clinical research, DPU could be used to measure defects per source document, queries per eCRF page, findings per monitoring visit, QC rejections per TMF document, missing fields per visit, or errors per site activation package. DPU is simple and understandable, but it may not fully account for process complexity.

Defects per Opportunity, or DPO, measures defects relative to the number of possible defect opportunities. If 100 source documents each contain 50 required fields, there are 5,000 opportunities. If 60 defects are found, the DPO is 60 divided by 5,000, or 0.012. This means that 1.2% of all opportunities resulted in defects. DPO can be useful when comparing processes of different complexity, such as screening visits versus follow-up visits, high-volume sites versus low-volume sites, laboratory data versus adverse event data, or different TMF document types.

Defects per Million Opportunities, or DPMO, standardizes DPO by multiplying it by one million. In manufacturing, DPMO can be translated into a sigma level. In clinical research, the sigma level itself may be less important than the discipline of standardizing defect rates. DPMO may help compare EDC data-entry defects, TMF metadata defects, laboratory reconciliation discrepancies, or safety database inconsistencies across studies, countries, vendors, or systems.

Rolled Throughput Yield, or RTY, is especially relevant for clinical research because clinical trials are long chains of dependent processes. RTY measures the probability that a process passes through all steps without requiring rework. This is important because clinical research quality is not produced by one step. Source documentation is completed, data are entered into EDC, data are reviewed, queries are generated, queries are answered, data are corrected, monitoring confirms consistency, vendor data are reconciled, documents are filed in TMF, and data are used in the clinical study report.

Even if each step performs reasonably well, the cumulative probability of error-free completion can be much lower than expected. If five process steps each have 95% first-pass quality, the rolled throughput yield is approximately 77%. If ten process steps each have 95% first-pass quality, the rolled throughput yield is approximately 60%. This may explain why clinical trial teams often feel overloaded even when individual functions appear to be performing adequately. The problem is not always that one team is failing. The problem may be that the whole process is designed in a way that normalizes small defects, late detection, and repeated rework.

Cost of Quality, or COQ, helps translate process quality into the language of management. COQ usually includes prevention costs, appraisal costs, internal failure costs, and external failure costs. In clinical research, prevention costs may include protocol review, risk assessment, site training, system validation, source documentation templates, EDC edit-check design, data standards, TMF planning, monitoring plan design, vendor qualification, and Quality by Design activities. These costs are not waste. They are investments intended to reduce future failure.

Appraisal costs include activities required to detect defects. In clinical research, these may include monitoring, source data verification, source data review, data review, medical review, TMF QC, audits, vendor oversight, reconciliation, central monitoring, and other quality checks. Some appraisal activities are necessary in regulated research. However, if a process depends too heavily on late inspection, this may indicate that prevention is insufficient.

Internal failure costs are costs caused by defects discovered before submission, inspection, final reporting, or formal project closure. Examples include query resolution, document correction, TMF remediation, re-monitoring, repeated data review, CAPA implementation, duplicate data entry correction, repeated training, vendor reconciliation, delayed database lock, and correction of statistical outputs due to late data changes.

External failure costs are costs caused by defects discovered after the output has reached an external customer, regulator, inspector, sponsor decision-maker, or final reporting stage. Examples include inspection findings, regulatory questions, delayed approval, major protocol amendments, repeated submission work, reputational damage, additional analyses, loss of confidence in trial data, delayed strategic decisions, and loss of credibility in project reporting.

Cost of Poor Quality, or COPQ, is perhaps the most important concept for clinical trial operations. COPQ includes costs that would not exist if work were done correctly the first time. In clinical research, COPQ may include time spent resolving avoidable EDC queries, email chains required to clarify missing or inconsistent source data, CRA follow-up due to incomplete documentation, site time spent correcting preventable errors, repeated TMF QC rejections, remediation projects before inspection, repeated medical review due to poor deviation descriptions, delayed database lock caused by unresolved queries, additional project management oversight caused by recurring defects, budget overruns caused by rework, delayed milestone completion, and delayed revenue recognition where work cannot be accepted as complete.

COPQ is often hidden because the work is distributed across many people and systems. One missing source value may create a chain of events: source defect, EDC query, email clarification, site correction, CRA follow-up, data management review, medical review, monitoring note, TMF update, QC rejection, correction, and final acceptance. The original defect may appear small, but the cumulative cost may be significant.

Example: Source Documentation, Data Transfer, Queries, and TMF Quality

A practical example can be taken from source documentation and clinical data flow.

In a clinical trial, source documents may contain different types of errors and omissions. These may include missing dates, incomplete medical history, inconsistent laboratory values, unclear adverse event descriptions, missing signatures, incorrect visit windows, or incomplete procedure documentation.

This information is then entered, sometimes manually, into different systems. For example, the same or related information may be entered into the EDC, CTMS, safety database, laboratory portal, vendor system, or local site tracker. Later, the data may be transferred or reconciled with other systems used for reporting, monitoring, statistical analysis, safety review, finance, and Trial Master File documentation.

At each step, there are new opportunities for defects.

A missing or incorrect value in the source document may generate an EDC query. The query may require communication between the data management team, CRA, site coordinator, investigator, and sometimes medical monitor. The same issue may also trigger emails, follow-up notes, monitoring findings, corrective actions, or TMF documentation updates.

Therefore, the cost of poor quality is not limited to the original error.

The total cost includes the full chain of work required to detect, communicate, investigate, correct, verify, document, and close the issue.

In a large clinical trial, this is not one query or one missing document. It may be thousands of queries, thousands of email exchanges, hundreds of monitoring follow-ups, repeated QC rejections, and several months of delayed resolution. Some queries may remain open for weeks or months, delaying data cleaning, medical review, database lock, reporting, audit readiness, and sometimes financial closure of project milestones.

From a Six Sigma perspective, several measurable indicators could be defined. These may include the number of defects per source document, the number of defects per data field, the number of missing or inconsistent fields per patient visit, the number of EDC queries per patient, site, visit, or form, the number of emails required to resolve one query, average query resolution time, the number of repeated queries for the same type of issue, the number of TMF QC rejections per document type, the number of documents returned for correction, the number of monitoring findings related to source documentation, and the cost of CRA, data management, medical, quality, project management, finance, and site time spent on correction.

This allows the organization to ask a more meaningful question:

What is the cost of achieving quality, and what is the cost of poor process quality?

The objective is not only to count errors. The objective is to understand where the process creates defects, where defects are detected too late, and where rework becomes more expensive than prevention.

For example, if source documentation is incomplete at the site, the defect may only become visible later through EDC queries, monitoring review, medical review, vendor reconciliation, or TMF QC. At that point, several functions may already be involved. The issue may no longer be a simple data correction. It becomes a process failure involving time, cost, delay, and potential risk to data integrity.

This also raises another important question:

What is the probability that correct, complete, and consistent information reaches the final clinical study report without rework?

In clinical research, this probability is often assumed rather than measured. Six Sigma and rolled throughput yield concepts can help make this visible. Even if each process step appears to work reasonably well, the cumulative probability of error-free flow across source documentation, data entry, query resolution, monitoring, vendor reconciliation, TMF filing, reporting, and project delivery may be much lower than expected.

This does not mean that clinical trials should mechanically apply manufacturing-style Six Sigma metrics. Clinical research is more variable, more regulated, and more dependent on clinical judgement.

However, the principle remains highly relevant:

If defects are not measured across the process, then the cost of poor quality remains hidden.

By measuring defects, rework, query burden, TMF rejection rates, resolution timelines, and the cost of repeated correction, clinical research organizations can improve not only the quality of outputs, but also the quality of the process itself.

The goal is therefore twofold.

First, to improve the clinical trial process so that fewer defects are created.

Second, to improve the quality process so that defects are detected earlier, corrected faster, and prevented from recurring.

Final Outcomes: More Than TMF Completeness

The final outcome of a clinical trial process is not only a filed document in the TMF. TMF completeness is essential, but it is only one part of the final quality picture.

The broader final outcome includes audit readiness, TMF completeness, data quality, financial performance, and the ability to remain on budget. These dimensions are connected. If source data are incomplete, EDC queries increase. If queries remain unresolved, data cleaning and database lock may be delayed. If documents are incomplete or incorrectly filed, TMF completeness and inspection readiness are affected. If rework increases, additional CRA, data management, quality, medical, site, and project management time is consumed. If effort increases without proper visibility, the project may remain technically active but financially uncontrolled.

Audit readiness depends on more than the presence of documents. It depends on whether the trial story can be reconstructed clearly, consistently, and credibly. The inspector or auditor should be able to understand what was done, when it was done, why it was done, who performed it, and how the trial maintained participant protection and data reliability. A TMF may be complete in percentage terms but still weak if documents are late, inconsistent, incorrectly classified, or disconnected from the operational reality of the study.

TMF completeness should therefore be understood not only as a document-counting exercise, but as a process outcome. If documents are created late, filed after repeated correction, rejected during QC, or disconnected from the work they are supposed to evidence, then TMF quality becomes a downstream reflection of poor process quality. In this sense, TMF completeness is not only a regulatory deliverable. It is also evidence of whether the trial process was controlled.

Data quality is another final outcome, but data quality is not created at the time of final analysis. It is created from the first source entry, the first patient visit, the first data field, the first monitoring review, and the first query response. If correct data reach the final report only after months of queries, repeated clarification, and reconciliation, the final dataset may be usable, but the process that produced it may still be inefficient and expensive.

Financial performance is also affected by process quality. Poor quality consumes time. Time consumes budget. Rework consumes budget again. A query is not only a data-management event. It may represent site effort, CRA follow-up, project management coordination, medical review, system updates, documentation, and delay. A TMF rejection is not only a document-quality issue. It may require correction, refiling, re-review, escalation, and sometimes additional explanation before audit or inspection.

Being on budget therefore depends partly on the quality of the process. A budget may be carefully negotiated at study start, but if the operational process generates avoidable rework, the original assumptions become less reliable. Poor process quality may appear as additional monitoring effort, additional data management time, additional site burden, additional vendor coordination, additional quality oversight, additional project management effort, and delayed milestone acceptance.

This is why clinical research should not only ask whether the final report is correct. It should also ask how efficiently, reliably, and transparently correct data and documents were produced.

Asking the Right Question

Clinical research often asks: is the final report correct? This is essential, but Six Sigma encourages an additional question: what is the probability that correct, complete, and consistent information reaches the final clinical study report without rework?

This question shifts attention from final inspection to process capability. If every step requires correction, reconciliation, or remediation, then quality is being achieved too late and at too high a cost.

The same question can be extended beyond the clinical study report. What is the probability that a source document, data field, TMF document, monitoring report, finance record, or project deliverable passes through the process without avoidable correction? What is the probability that the trial remains audit-ready throughout execution, not only after a remediation exercise? What is the probability that project costs remain aligned with the original budget because the process does not generate uncontrolled rework?

These are practical management questions, not theoretical statistical exercises.

Improving the Process and the Quality Process

The goal is not only to find more defects. The goal is to improve the process so that fewer defects are created.

At the same time, the quality process itself must also improve. Defects should be detected earlier, corrected faster, and prevented from recurring. Better source documentation design may reduce missing data. Better EDC edit checks may prevent incorrect entries. Better site training may reduce repeated deviations. Better system integration may reduce duplicate data entry. Better TMF metadata design may reduce QC rejections. Better dashboards may identify slow query resolution earlier. Better root cause analysis may reduce recurrence.

This creates two levels of improvement. The first is improvement of the clinical trial process itself. The second is improvement of the quality management process that detects, corrects, and prevents defects. Both are necessary. A quality system that only detects defects late may be compliant, but it may also be expensive and inefficient. A mature process should reduce the need for late correction by building quality into the work itself.

Conclusion

Clinical research already pays the cost of poor process quality. It pays through queries, rework, delays, remediation, monitoring follow-up, TMF correction, CAPA, repeated review, avoidable operational burden, and budget pressure.

However, these costs are often not measured as one connected process cost. They are distributed across systems, functions, emails, trackers, vendors, sites, and project teams. As a result, poor process quality may remain visible as individual issues, but invisible as a cumulative cost of trial delivery.

ICH E6(R3) emphasizes that quality should be built into the scientific and operational design and conduct of clinical trials. This is the essence of Quality by Design: important quality factors should be considered early, not repaired only after defects have already propagated through the process. In this context, Six Sigma does not replace GCP, Quality by Design, RBQM, QTLs, or clinical judgement. Rather, it offers a complementary measurement lens.

Six Sigma is useful because it translates quality from a compliance concept into a measurable process and financial concept. It asks not only whether quality was eventually achieved, but how much failure, detection, correction, and rework were required to achieve it. It also asks whether the process itself is capable of producing correct, complete, timely, and usable outputs with limited rework.

Clinical trials do not need to become factories. But they do need clearer measurement of process quality. A clinical trial should not only prove that the final data are correct. It should also be able to show how efficiently, reliably, and transparently correct data were produced, documents were completed, audit readiness was maintained, and budget expectations were protected.

Refusing to measure is refusing to improve.

References:

1. Rathi R, Vakharia A, Shadab M. Lean six sigma in the healthcare sector: A systematic literature review. Mater Today Proc. 2022;50:773-781. doi: 10.1016/j.matpr.2021.05.534. Epub 2021 Jun 7. PMID: 35155129; PMCID: PMC8820448. https://pmc.ncbi.nlm.nih.gov/articles/PMC8820448/

2. Schweikhart SA, Dembe AE. The applicability of Lean and Six Sigma techniques to clinical and translational research. J Investig Med. 2009 Oct;57(7):748-55. doi: 10.2310/JIM.0b013e3181b91b3a. PMID: 19730130; PMCID: PMC2835466. https://pmc.ncbi.nlm.nih.gov/articles/PMC2835466/

3. Lean Six Sigma in the Clinical Trial Industry: Two Perspectives. Applied Clinical Trials. Dawn Pope https://www.appliedclinicaltrialsonline.com/view/lean-six-sigma-clinical-trial-industry-two-perspectives 

4. McDermott, O.; Antony, J.; Bhat, S.; Jayaraman, R.; Rosa, A.; Marolla, G.; Parida, R. Lean Six Sigma in Healthcare: A Systematic Literature Review on Challenges, Organisational Readiness and Critical Success Factors. Processes 2022, 10, 1945. https://doi.org/10.3390/pr10101945

Related posts:

The CRA Workload Behind the Last Unresolved Query

FDA Form 483 Resources

Real-Time Clinical Trials

Can AI Develop Clinical Trial Budgets?