Saturday, June 13, 2026

Real-Time Clinical Trials: A Concept Change in Clinical Development?

 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.

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 benefitPractical meaning
Earlier safety signal detectionImportant safety trends may be recognized sooner.
Earlier efficacy visibilityStrong endpoint signals may be seen before the traditional full reporting cycle.
Faster decision-makingSponsors and regulators may be able to make development decisions earlier.
Reduced development cycle timeLess waiting between evidence generation and regulatory interpretation.
Less administrative delayManual reporting, paperwork, and delayed consolidation may become less central.
Better use of AI and data scienceAI 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 issueWhat RTCT may change
Manual data entryRTCT may create pressure to reduce duplicate entry and late reporting.
Fragmented systemsRTCT may require better system integration and clearer data flows.
Paperwork and delayed reportingRTCT may shift focus toward structured, earlier signal reporting.
Inconsistent deviation trackingRTCT may expose the need for more standardized operational metadata.
Data cleaning after the factRTCT 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.



Thursday, June 11, 2026

Six Sigma: Refusing to Measure Is 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 conceptMeaning in process qualityPossible clinical research KPI
UnitThe item or process output being evaluatedOne source document, one patient visit, one eCRF form, one TMF document, one monitoring report, one site activation package
DefectA failure to meet a defined requirementMissing data, wrong date, incomplete source entry, unresolved query, incorrect TMF metadata, missing signature, inconsistent value between systems
OpportunityA specific place where a defect could occurEach required field, signature, date, data point, document attribute, transfer step, QC check, or reconciliation point
DPU — Defects per UnitNumber of defects per evaluated unitDefects per source document, queries per eCRF form, QC findings per TMF document, monitoring findings per visit
DPO — Defects per OpportunityNumber of defects divided by all possible defect opportunitiesDefects divided by total required fields, checks, signatures, metadata points, or reconciliation items
DPMO — Defects per Million OpportunitiesStandardized defect rate allowing comparison across processes of different complexityEDC data-entry defects per million fields, TMF metadata defects per million attributes, reconciliation discrepancies per million transferred values
RTY — Rolled Throughput YieldProbability that the process passes through all steps without reworkProbability 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 QualityTotal cost of prevention, appraisal, internal failure, and external failureCost of training, monitoring, QC, audits, system validation, remediation, CAPA, re-monitoring, and delayed reporting
COPQ — Cost of Poor QualityCost that would not exist if work were done correctly the first timeCost 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


Monday, May 25, 2026

Will LLMs Make CROs Redundant?

As large language models (LLMs), GenAI, workflow automation, and integrated operational platforms continue to evolve, an increasingly uncomfortable question is beginning to emerge within clinical research:

Why are so many additional organizational, management, and software layers still required to run clinical trials?


For decades, CROs have played a central role in pharmaceutical research. Historically, this made complete sense. Pharmaceutical companies needed global operational infrastructure, therapeutic expertise, monitoring capacity, regulatory operations, staffing, laboratory services, and the ability to rapidly execute increasingly complex multinational clinical trials.

However, modern clinical trial operations have also become heavily fragmented.

Today, Sponsors, CROs, vendors, laboratories, and sites often maintain overlapping operational systems, duplicated reporting layers, reconciliation trackers, parallel oversight structures, and multiple disconnected software environments. Data frequently moves between CTMS, EDC, TMF, IRT, spreadsheets, emails, vendor portals, laboratory systems, dashboards, and manually maintained trackers.

A substantial amount of operational work is therefore no longer directly related to science or patient care, but rather to:

  • coordination,
  • reporting,
  • reconciliation,
  • duplicated data entry,
  • oversight,
  • and movement of information between disconnected organizations and systems.

At the same time, one important regulatory reality often remains unchanged:

Overall responsibility and accountability for trial execution still sit with the Sponsor, not the CRO.

Even when operational execution is outsourced, Sponsors still retain responsibility for:

  • patient safety,
  • regulatory compliance,
  • data integrity,
  • oversight,
  • inspections,
  • and overall trial quality.

This creates a difficult strategic question.

If the Sponsor already retains ultimate accountability, while research sites perform the actual clinical activities, how much additional management and operational infrastructure is truly required between Sponsors and investigators?

This question becomes even more relevant as AI-assisted operational systems continue to mature.

Modern AI-assisted development environments are already demonstrating how quickly operational workflows, budgeting systems, workload forecasting, documentation processes, and quality oversight concepts can be prototyped and visualized.

If operational systems become increasingly:

  • integrated,
  • protocol-driven,
  • interoperable,
  • transparent,
  • and AI-assisted,

then some current operational structures may gradually become harder to justify economically.

Importantly, this discussion is not really about replacing CRAs, physicians, statisticians, safety experts, or operational subject matter experts.

Much therapeutic and operational expertise already sits with experienced individuals, project teams, and site personnel rather than inside corporate structures themselves.

The deeper question is whether future clinical research models may rely more directly on:

  • Sponsor oversight,
  • site execution,
  • embedded experts,
  • specialized vendors,
  • and integrated operational platforms,

while reducing some intermediary administrative and management layers.

Many Sponsors are already increasingly moving toward:

  • FSP models,
  • embedded staffing,
  • centralized oversight,
  • direct operational visibility,
  • and more specialized outsourcing structures rather than fully independent operational ecosystems.

One possible long-term direction is that operational systems may gradually move closer to Sponsors and research sites themselves rather than being duplicated across multiple organizational layers.

If CTMS, EDC, TMF, budgeting, operational planning, quality oversight, and reporting workflows eventually become more integrated and interoperable, one could imagine more centralized operational infrastructures where Sponsors, sites, vendors, and potentially regulators operate on more transparent shared environments rather than fragmented parallel systems.

This may potentially reduce:

  • duplicated reconciliation activities,
  • overlapping reporting structures,
  • administrative overhead,
  • fragmented data layers,
  • and some middle-management coordination functions.

At the same time, there are still strong reasons why CROs are unlikely to disappear completely. Clinical trials remain operationally difficult, globally distributed, and highly regulated. Large organizations still provide scalability, pharmacovigilance infrastructure, inspections and audit readiness, staffing flexibility, country-level operations, and execution under uncertainty.

Large technology companies such as Google, Amazon, Microsoft, NVIDIA, and others are also increasingly entering healthcare infrastructure, biomedical AI, cloud platforms, and operational data environments. While they are not replacing CROs directly, they are clearly accelerating digital transformation pressure across the clinical research ecosystem.

The most realistic outcome may therefore not be the disappearance of CROs entirely, but a gradual restructuring of how clinical research operations are organized, coordinated, and technologically supported.

The key question may ultimately become not:
“Will AI replace CROs?”

but rather:

“If Sponsors already retain accountability, and sites perform the actual research, how much of the current CRO management and software infrastructure reflects true operational necessity. And how much reflects historical organizational complexity built around fragmented systems and workflows?”

Friday, May 22, 2026

Clinical Trial Budgeting Software Prototype Using AI

(Please drop a comment or reach out if you would like to discuss the development of this concept, exchange ideas, validate assumptions, or explore potential collaboration opportunities.)

Over the last weeks, I have been experimenting with AI-assisted development platforms such as Codex and Base44 to explore whether integrated clinical trial budgeting and operational planning concepts can now be prototyped much faster than traditionally possible with multiple disconnected systems.

As an educational proof-of-concept, I used publicly available clinical trial protocol examples to generate prototype Clinical Trial Budgeting and Project Management environments (links below).

The broader goal is not to create a validated production system at this stage, but rather to explore whether a lightweight educational platform could eventually help research groups, startups, CROs, and biotech teams:

  • estimate study budgets,
  • evaluate operational feasibility,
  • understand budget drivers,
  • model resource requirements,
  • and visualize operational complexity earlier in the planning process.

The current prototype explores concepts such as:

  1. Creating and modifying protocol-derived work units, including classification into contracted scope and Out-of-Scope (OOS) activities
  2. Drilling down from high-level assumptions into operational detail:
    site-level planning, visit schedules, resource allocation, employee roles, and unit composition updates (standard vs. study-specific assumptions)
  3. Generating linked operational outputs such as:
    budget grids, resource plans, contract-related structures, and project plans
  4. Exploring governance concepts where operational units may eventually be linked to supporting evidence of completed work (for example visit reports or TMF-related documentation)
  5. Estimating planned effort and operational workload required to complete study activities, including earned value-style concepts
  6. Exploring study metrics and operational oversight approaches connected to workload and delivery status

What is particularly interesting is how functional these AI-generated prototypes already appear at an early exploratory stage.

Of course, any budgeting logic, assumptions, calculations, or operational recommendations would require careful validation against real-world studies, operational practice, governance requirements, and financial controls before any practical use.

One especially interesting direction may be comparing traditional Excel-based budgeting approaches with AI-assisted relational database and rule-driven systems.

If budgeting logic can already be implemented in spreadsheets, similar logic may potentially be implemented in structured relational systems with:

  • more traceable assumptions,
  • reusable rule frameworks,
  • integrated operational planning,
  • and improved visibility into how budgets are constructed and maintained.

The next step will likely involve continuing similar experiments using:

  • @Base44,
  • Oracle APEX,
  • Power BI-based offline environments,
  • and other educational prototyping approaches.

This remains an early-stage exploratory concept and should not be interpreted as a validated budgeting methodology or operational system.

However, the speed at which these concepts can now be tested, modified, and visualized using modern AI-assisted development approaches is quite remarkable.

If anyone is interested in discussing the concept, validating assumptions, contributing ideas, or exploring potential student/research collaboration opportunities, I would be very interested to connect.

Links and References

  1. System prompt:
    https://github.com/DmitryHubPM/CPMS/blob/main/base44-prompt.md
  2. Codex prototype:
    https://dmitryhubpm.github.io/CPMS/
  3. Base44 prototype:
    https://cpms.base44.app
  4. Publicly available protocol document referenced solely for educational and illustrative prototype purposes:
    https://dac-trials.org/wp-content/uploads/PNE-Pneumonia-2019-Alexander-LEAP2.pdf

Tuesday, May 12, 2026

Can AI Develop a Clinical Trial Budget Calculator?

Over the last months, I have been experimenting with whether modern AI-assisted development platforms can support the creation of structured operational and budgeting systems for clinical research.

One interesting experiment was the development of a simplified Clinical Trial Budget Calculator (CTBC) using the AI-assisted platform Base44.

The result is a working prototype application:

https://ledger-flow-76f4f135.base44.app/

(The application currently requires free authorization via Google or email.)


Wednesday, April 29, 2026

Clinical Trial Protocol and ChatGPT: Why Can’t You Upload It?


Many newcomers to clinical research ask a surprisingly modern question:

If generative AI can read long documents, summarize complexity, detect inconsistencies, build schedules, and help teams prepare faster: - why can’t project teams simply upload a clinical trial protocol?

What Is an ICF in Clinical Research?

 A Practical Guide for Students and Future Trial Participants

Clinical research uses many technical abbreviations, but few are as important as ICF, which stands for Informed Consent Form. Although often described simply as “a form to sign,” this is only part of the picture. In reality, the ICF is one of the core ethical safeguards in modern human research.

An Informed Consent Form is the document, and more importantly, the communication process, through which a potential participant receives information about a clinical study before deciding whether to join. It is intended to help a person understand what the study is about, what participation may involve, what risks may exist, what possible benefits may or may not occur, and what rights remain with the participant throughout the study.

In simple terms, the ICF is where science meets human choice.

Examples of Informed Consent Forms (ICF)

Students often ask what an actual Informed Consent Form looks like in practice. Below are several publicly available examples and templates for educational review. These documents help illustrate structure, tone, and the type of information participants usually receive.

1. Real Clinical Trial ICF Example – ClinicalTrials.gov

Public example of an informed consent form filed in connection with a registered study: Sample Clinical Trial ICF PDF ( PDF: https://cdn.clinicaltrials.gov/large-docs/95/NCT01873495/ICF_001.pdf)

Sunday, April 19, 2026

What Is a Contract Research Organization (CRO)? Role in Clinical Trials and Future Trends

Clinical trials are essential for developing new medicines, but they require coordination across many different participants, including sponsors, hospitals, and regulatory authorities. One of the most important—yet often less understood—participants in this process is the Contract Research Organization (CRO).

A Contract Research Organization is a company that provides services to support the planning, management, and execution of clinical trials. CROs play a key role in helping sponsors run studies efficiently, especially when trials involve multiple countries, sites, and complex regulatory requirements.

What Does a Contract Research Organization Do?

Thursday, April 16, 2026

Lessons Learned in Project Management: Why They Fail and How to Make Them Work

Lessons learned help improve project outcomes, but often fail in practice. Learn how to classify issues, define ownership, and ensure real operational change.

What Are “Lessons Learned”?

Monday, April 13, 2026

From Dialogue to Noosphere: The Evolutionary Role of Generative AI in Idea Formation

(Summary of my recent chat with GPT)

Introduction

Generative AI changes how ideas are developed, not by replacing knowledge creation, but by altering how ideas are assembled, refined, and connected. Interaction no longer depends entirely on direct discussion, access to specific authors, or long feedback cycles. Instead, a generative system enables continuous reformulation of thoughts, exposure to missing elements, and structured expansion.

This shift introduces a different constraint. Previously, the development of ideas was limited by access to interaction. With generative AI, interaction becomes continuously available, but its structure is mediated. As a result, ideas can evolve faster, yet they may also converge in systematic ways.

Saturday, April 4, 2026

From Paper to Integrated Data Flow? (PDC->MDC->EDC?)

A short dream about the future of clinical trials

Sometimes it feels like clinical trials are very modern and very digital.
We have electronic systems, dashboards, remote monitoring, and cloud platforms.

But if we look closely at how clinical data actually moves, the story is more interesting.

It is not really a story about paper becoming electronic. It is a story about manual transcription slowly disappearing.

You could describe the evolution of clinical trials data capture in four stages:

PDC → MDC → EDC → IDF

And we are probably somewhere between stage 2 and stage 3.

Stage 1. PDC (Paper Data Capture)

In the beginning, everything was paper.

The investigator wrote data in the medical record.
Then the site copied the data into a paper CRF.
Then someone at the sponsor or CRO entered the paper CRF into a database.

So the data was written three times:

  1. Source document
  2. Paper CRF
  3. Database

Paper was not the problem.
Transcription was the problem.

Stage 2. MDC (Double-Manual Data Capture)

Then came EDC systems.

Paper CRFs disappeared, but something interesting happened:
The process did not become electronic — it became manual data entry into an electronic system.

The workflow now looked like this:

  • Data written in source
  • Site manually enters data into EDC
  • CRA compares source vs EDC (SDV)
  • Queries are raised
  • Corrections are made
  • Emails are sent
  • Monitoring reports are written

So the system was electronic, but the process was still manual transcription.

You could argue that many trials today are still in the Manual Data Capture era.

Stage 3. EDC (True Electronic Data Capture)

True electronic data capture means something different:
Data is created electronically at the source and transferred directly into the database.

Examples:

  • ePRO
  • Wearables
  • Devices
  • Lab data transfers
  • eSource
  • EMR integrations

In this world, data is not copied anymore.
It is generated digitally and transferred automatically.

If there is no transcription, then many traditional processes change:

  • Less SDV
  • Fewer queries
  • More central monitoring
  • More data analytics
  • Monitoring becomes process and risk review instead of document comparison

We are moving in this direction, but we are not fully there yet.

Stage 4. IDF (Integrated Data Flow)

The final stage is not just electronic data capture, but integrated data flow.

In this model:

  • Data is captured once
  • Systems are connected
  • Quality metrics are generated automatically
  • Escalations are workflow-driven, not email-driven
  • Documentation is generated from the process itself
  • Databases, TMF, CTMS, and quality systems are connected

At that point, clinical trials will not be document-driven anymore.
They will be process- and data-flow-driven.

This is probably the direction the industry is slowly moving toward.


Summary Table

StageNameHow data is capturedTranscriptionMain control
PDCPaper Data CapturePaper CRFDouble manualSDV & data entry checks
MDCManual Data CaptureManual entry into EDCSingle manualSDV, queries, monitoring
EDCTrue Electronic Data CaptureDigital source → databaseNo transcriptionEdit checks, central monitoring
IDFIntegrated Data FlowConnected systemsNo transcriptionProcess control & analytics

One Important Thought

If we look at this evolution, the biggest change is not paper vs electronic.

The biggest change is this:

Clinical trials are slowly moving from transcription-based data collection to data-flow-based data collection.

And maybe one day, SDV will be remembered as something that existed mainly because humans had to copy data from one system into another?



Friday, April 3, 2026

EMA Data Quality Framework for Medicines Regulation

The European regulatory environment has recently introduced a dedicated framework specifically addressing data quality in the context of medicines regulation and the use of real-world data. This framework is documented in the Data Quality Framework for EU Medicines Regulation - Application to Real-World Data, published by the European Medicines Agency:

https://www.ema.europa.eu/en/documents/other/data-quality-framework-eu-medicines-regulation-application-real-world-data_en.pdf

Thursday, March 26, 2026

Making Unaccounted Costs Accountable in Clinical Research

Clinical trials operate under strict timelines, regulatory requirements, and complex coordination between sponsors, CROs, sites, and vendors. When delays occur or issues arise, project teams often resolve problems by working longer hours rather than by adjusting timelines, budgets, or processes.

In many organizations, a standard working day is approximately eight hours. However, Clinical Research Associates, Project Managers, and other clinical operations staff may regularly work ten or more hours per day, especially during critical study phases.

If only eight hours are recorded in time sheets while ten hours are actually worked, two hours per day become unaccounted operational effort.

Individually, this may appear minor. Over the duration of a clinical trial, the financial impact can be substantial.

Financial Example: Unaccounted Hours Over a Project Duration

Monday, March 16, 2026

Hidden, Absorbed, and Unaccounted Costs in Clinical Trials

Clinical trials are widely recognized as expensive and complex projects. Budget discussions usually focus on visible cost elements such as labour fees, investigator grants, site payments, vendor contracts, other passthorough. These costs are clearly documented in study budgets and contracts and are typically tracked through project accounting systems.

However, the real operational cost of clinical trials often extends beyond these visible budget lines. During study execution, additional effort frequently arises from inefficient processes, fragmented systems, and operational challenges that require extra coordination by project teams.

Some of this work eventually appears in project effort reports. Some of it is absorbed by organizations when project budgets are exceeded. And some effort may never be formally recorded at all.

To illustrate this situation, it can be useful to distinguish between four different categories of costs in clinical trial operations: visible costs, hidden costs, absorbed costs, and unaccounted costs.

Monday, March 9, 2026

What Are AI Agents and How Can They Help Optimize Clinical Trial Operations

Removing duplication in clinical trial operations could significantly reduce costs and increase research capacity. One emerging technology that may help enable this transformation is the concept of AI agents. But what exactly are AI agents, and how could they improve clinical trial operations?

What are AI agents?

An AI agent is a software system designed to perform tasks autonomously based on defined goals, available data, and operational rules.

Traditional software typically executes predefined commands. AI agents, in contrast, can interpret information, analyze context, and trigger actions within complex workflows.

In practical terms, AI agents can:

  • interpret structured information

  • coordinate operational processes

  • trigger workflows across systems

  • monitor data and identify anomalies

  • generate reports or documentation

Rather than acting only as databases or static tools, AI agents can function as digital operators that help coordinate processes and information flows.

Why clinical trial operations are suitable for AI agents

Could Clinical Trial Costs Be Reduced by Half?

Could Halving Clinical Trial Costs Double the Benefits of Clinical Research?

Clinical trials are essential for developing new therapies, but they are also widely known to be expensive. Conducting a single clinical study often requires large budgets, complex coordination, and significant operational infrastructure.

But this raises an important question: How much of the cost of clinical trials is driven by scientific requirements—and how much is driven by operational complexity?

Clinical trials must support patient care, medical procedures, and the evaluation of investigational treatments. These elements are essential and cannot be eliminated. However, a substantial portion of clinical trial budgets is also devoted to coordinating processes, documenting activities, reconciling information across systems, and managing regulatory workflows.

In this sense, clinical trials are not only scientific investigations. They are also large operational systems.

Understanding how these systems are organized may reveal opportunities to improve efficiency without compromising scientific quality.

Wednesday, February 25, 2026

Validation vs Usability in Clinical Trial Systems: Balancing Reactive Control and Preventive Design

Clinical research operates within a tightly regulated environment in which digital systems are subject to rigorous validation requirements. Data capture platforms, trial master file systems, safety databases, and financial tracking tools must demonstrate reliability, traceability, and compliance with Good Clinical Practice principles. Validation is foundational. Without it, data integrity and participant safety cannot be assured.

Yet validation alone does not guarantee that a system supports efficient and stable trial execution. A platform may perform exactly as specified under documented test conditions, and still generate friction in day-to-day operations. This distinction between validation and usability is rarely explored explicitly, but it carries structural implications for quality management in clinical research.

Under frameworks such as ICH E6(R2) and ICH E6(R3), computerized systems must be fit for purpose and maintain data integrity throughout the study lifecycle. The regulatory emphasis is appropriately placed on reliability, auditability, and control. However, “fit for purpose” can be interpreted narrowly as technical compliance, or more broadly as operational adequacy. The difference matters.

Validation confirms that a system behaves as intended according to predefined requirements. It answers the question: does the software function correctly under documented scenarios? 

Usability, by contrast, addresses whether real users can execute complex workflows efficiently, consistently, and without excessive workaround behavior. It asks: does the system support how work is actually performed in a clinical trial?

Is Clinical Trial Software Truly Fit for Purpose?

Clinical research today operates within a dense digital ecosystem. Electronic data capture systems, trial master file platforms, safety databases, project portfolio tools, and financial tracking solutions collectively form the infrastructure of modern study execution. From a technical standpoint, these systems are validated, cloud-enabled, and increasingly interoperable. Yet a more fundamental question often remains insufficiently examined: does the existing software landscape actually cover the functionality required by the study it supports?

The concept of “fit for purpose” is frequently used in regulated environments, particularly under frameworks such as ICH E6(R2) and ICH E6(R3). Within this context, systems must ensure data integrity, reliability, traceability, and appropriate documentation. However, regulatory compliance alone does not automatically imply operational adequacy. A system may meet validation standards and still fall short in representing the real operational complexity of a study.

Saturday, January 31, 2026

Clinical Trial Automation: The Naming Conventions Challenge

Is cross-system clinical trial automation failing not because workflows cannot be executed, but because protocol terminology cannot be interpreted consistently across systems and clinical studies?


Discussions about automating clinical trials often focus on advanced technologies such as workflow engines, interoperability standards, and AI/ML. In practice, cross-system automation most often breaks much earlier, at a far more basic level: inconsistent naming conventions

Clinical protocols are written in natural language, where the same term can legitimately carry different meanings depending on study design, therapeutic area, or regulatory intent. Software systems, by contrast, assume that identifiers are stable, explicit, and unambiguous. This mismatch creates friction long before questions of execution logic or governance arise.

Several academic and industry initiatives have proposed encoding protocol elements, such as eligibility criteria, visits, milestones, consent states, into structured system logic. While technically feasible, these efforts consistently encounter a semantic problem: the protocol terms being encoded do not have a single, invariant meaning. Instead, their interpretation is context-dependent and often only becomes clear when the protocol is implemented across multiple systems such as CTMS, EDC, TMF, and finance. Automation struggles not because systems cannot execute logic, but because they cannot reliably infer what a term is supposed to mean.

Friday, January 30, 2026

Blockchain to Clinical Trial Automation – What Are the Obstacles?

Why promising concepts have not translated into practical implementation? Lessons Learned.

The idea of using blockchain to automate clinical trials emerged from a compelling analogy: if financial contracts can be expressed as executable smart contracts, why not clinical protocols? 

Wednesday, January 28, 2026

Project Management and Modular Outsourcing

Platforms, GenAI, and modular services. How can this impact Project Management? 

Work organization is evolving across many knowledge-intensive industries. Digital platforms, GenAI-assisted production, and global access to qualified specialists are changing how services are offered, priced, and evaluated. This development is visible even in domains traditionally characterized by strong regulation and institutional structures, like clinical research. Rather than asking whether regulated projects are “moving” to open platforms, a more precise question is:

Monday, January 26, 2026

Swissmedic Submissions and Project Timelines: Why Approval Speed Determines Your Study Start

Clinical trial timelines in Switzerland are tightly linked to the efficiency of submissions to Swissmedic.

Delays at this stage do not remain confined to regulatory milestones. They cascade into site activation, contracts, budgets, and overall project duration.

From a project-management perspective, Swissmedic approval is frequently on the critical path. Even minor, avoidable issues (missing annexes, outdated guidance, inconsistent documents) can postpone study start by weeks or months.

Sunday, January 25, 2026

Longevity as a Project

What changes if we consider life as a project?


Projects fail rarely because of one catastrophic event. They fail because small deviations accumulate, risks go unnoticed, and performance is not tracked against expectations. Aging may follow a similar pattern.

Instead of asking “How do we defeat aging?”, we can ask a different question:

What if we consider life as a long-running project, and manage it using basic project control logic?

This reframing does not promise immortality. It proposes something more modest and potentially more useful: governance of healthspan over time.

Project management analogy: Planned, Actual, and Longevity Value

Friday, January 23, 2026

Innovative Mobile Platforms for Clinical Research and Evidence Generation

Advances in mobile technology have opened new pathways for clinical research that go beyond traditional site-centric models. Mobile apps now play a growing role in study visibility, participant engagement, and data collection, both within regulated clinical trials and in healthy-population research.

Rather than replacing clinical trial systems, these platforms operate at a different layer:
they connect people to research, standardise how participation occurs, and enable more continuous, real-world data capture. Over time, this may support more structured datasets, easier study access, and more reliable evidence for analysis and decision-making.

Below are two groups of mobile platforms illustrating this shift.

Mobile Platforms Supporting Clinical Trial Participation

(Patient-facing, trial-specific apps)

Science 37 — Studies App

Focus: Decentralized and hybrid clinical trials

Science 37’s Studies App allows participants to discover, consent to, and take part in clinical trials remotely. The platform reduces dependence on physical sites and lowers participation barriers, particularly for patients who would otherwise not have access to research centers.

Thursday, January 22, 2026

"Fit for Purpose" in Clinical Research

One trial, one purpose or many stakeholder perspectives?

The expression “fit for purpose” appears 14 times in **ICH GCP ICH E6(R3). This repetition is not accidental. It signals a deliberate regulatory shift away from rigid, one-size-fits-all compliance toward a more contextual, risk-based understanding of quality, proportionality, and oversight in clinical research.

At the same time, the phrase itself is deceptively simple. According to the Cambridge Dictionary, fit for purpose means:

“Suitable and good enough to do what it is intended to do.”

Fit for Purpose in ICH GCP (R3)

Within ICH GCP E6(R3), fit for purpose is used to describe a wide range of elements, including trial processes, quality management systems, oversight mechanisms, data handling approaches, and supporting technologies. Across all these contexts, the underlying principle is consistent: systems and processes should be appropriate for their intended use, proportionate to risk, and focused on what truly matters for participant safety and reliable decision-making.

Wednesday, January 21, 2026

"Quality by Design" in Clinical Trials

What is Quality by Design according to ICH GCP E6(R3)? 

E6(R3) Good Clinical Practice (GCP) places Quality by Design as a a key and recurring principle across the guideline. The concept is introduced in the context of clinical study design, risk identification, and planning, and is reinforced at multiple points throughout the document as follows:

Tuesday, January 20, 2026

FDA Warning Letters to Investigators: Tutorial Examples

FDA warning letters are most often associated with manufacturing or product-related issues, but they can also be issued directly to clinical investigators when significant regulatory concerns are identified during inspections. 

These letters are typically issued months after the underlying events, following:

  • an on-site inspection,

  • documented observations,

  • and review of written responses provided by the investigator or site.

As a result, a warning letter may appear long after the clinical activity in question has already concluded.

Here are 2 examples from December 2025:

  • Example 1  - https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/purushothaman-damodara-kumaran-md-721325-12222025
  • Example 2 - https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/devalingam-mahalingam-md-phd-721145-12112025

What such letters generally indicate