What Trialeco is — in under two minutes and module by module

A clinical trial protocol may contain hundreds of pages. Participation rules, procedures, timelines and site requirements can sit in different sections. Protocol Guard is designed to organise these elements into a working map while retaining the source of every proposed rule. The public demo may use only a public or synthetic protocol with no patient data or confidential information. The module records the version, appendices and tables. A sponsor-confidential document requires a separate protected process and an established right to process it. The system proposes working cards for participation criteria, procedures, visit windows and site requirements. Each card cites its section, page, table and version. A reviewer can see both the proposed interpretation and the exact place that must be checked in the original. In a synthetic protocol, a visit is planned for day fifteen with a plus-or-minus two-day window. The working map shows days thirteen to seventeen. If a procedure table gives a different window, the system does not choose one: it displays the conflict and asks an expert. A medical expert reviews clinical meaning. A biostatistician reviews endpoints and data. A regulatory specialist reviews applicable requirements. The principal investigator assesses site feasibility, and quality specialists review the process. Protocol Guard does not replace these roles or approve the protocol. After review, selected rules may feed preliminary matching in Recruit, approved reminders in Comms and site-data assessment in Site Status. The next step for Protocol Guard itself is testing against expert reference sets, with explicit measures for omissions, distortions and critical errors.

Recruit is a proposed module for preliminary comparison of confirmed study rules with authorised information about a possible participant. It reports a match, a mismatch or insufficient data. It does not decide whether a person is eligible or enrolled. In a professional environment, information may come from a clinical information system, a prescreening form, a physician referral or an authorised export. Every source needs a legal basis, data minimisation and access controls. The public demo uses synthetic profiles only. For each criterion, the module compares a reviewed rule from Protocol Guard with an available fact. It presents the rationale and source. If a date, laboratory value or phrase is ambiguous, the status remains unknown. Missing information is neither a match nor a mismatch. In a synthetic example, age matches an eighteen-plus rule. The date of previous therapy is not confirmed. Recruit marks the first item as a preliminary match and the second as missing information. Only the investigator decides whether screening may continue. The module does not diagnose, make a final eligibility decision or enrol anyone. The investigator checks the current protocol, source medical records and all required procedures. Informed consent remains a separate human process. Before a pilot, experts create a reference set and define metrics in advance. Testing covers omitted criteria, inverted negations, units, dates and unknown information. A critical error must stop the route and escalate the case instead of being hidden inside an attractive overall score.

Comms is a proposed communication module for prescreening, screening and study visits. It helps prepare a clear message, reminder or question. The channel, wording, timing and recipient come from an approved scenario, not from an unconstrained AI decision. Comms receives reviewed schedule elements only. The site team records the actual date and responsible person. The module may prepare an organisational reminder about a visit or required step. Medical instructions and individual advice remain with an authorised professional. A routine organisational question uses an approved template. If a message falls outside that boundary or mentions a symptom, complaint or ambiguity, Comms retains the context and routes the question to the responsible person. It must not invent a medical answer. A symptom report creates a technical signal. It does not by itself classify an adverse event, seriousness, causality or expectedness. A clinician assesses the medical situation. The sponsor's authorised safety function performs documentation and reporting under the established procedure. Each scenario requires a verified communication basis, permitted timing, template version, action history and fallback route. Automatic sending is limited to explicitly approved non-clinical messages. A failure or risk blocks the scenario and transfers it to a person. Comms is not intended to replace communication between a clinician and participant. It helps preserve the question, link it to the relevant visit or rule, assign an owner and show a response deadline. A limited pilot must measure missed handoffs, routing errors and message clarity.

Research-site readiness cannot be reduced to one number. Site Status is designed as an evidence card for team, resources, documents, experience and current workload. It does not select a site or promise recruitment speed without a separately validated method. The site records factual information: team composition and training, equipment and laboratory availability, local procedures, contracting stages, competing studies and expected workload. Every field has an owner, source, date and review status. Protocol Guard supplies confirmed requirements for a specific protocol. Site Status compares them with site facts and highlights a possible gap, such as missing training evidence, unspecified freezer capacity or overlapping workload. A gap is a question for review, not an automatic rejection. The site confirms its data. A contract research organisation assesses and qualifies the site only within documented transferred duties. The sponsor retains oversight and makes the documented decision about site selection and process rules. The dashboard shows states of individual fields: confirmed, needs clarification, expired or not applicable. A user can open the source and see who reviewed the record and when. Recruitment forecasting is allowed only after separate validation of the data and method. In a pilot, Site Status is compared with a documented specialist assessment. Testing measures missed requirements, stale information, false signals and time spent on clarification. When evidence is insufficient, the system must show uncertainty rather than hide it behind a green indicator.

Trialeco Core is designed as an integration layer. It connects module events, process rules and assigned roles. Its purpose is not to make a clinical decision, but to show what happened, who owns the next step and which confirmation is required. An event carries its source, version and time. Protocol Guard may detect a changed visit window, Recruit may find missing data, Comms may receive a complex question, or Site Status may show expired evidence. Core preserves the event's meaning and original context. Every route defines who performs the task, who is accountable, who is consulted and who is informed. A documented transfer of duty must be visible. If ownership or authority is not defined, the transition is blocked and transferred to the process administrator. Whether a separate Orchestrator is needed above Core remains under evaluation. It may propose a next task under an approved rule. It must not duplicate the coordinator or independently choose a medical, ethical or regulatory route. Core should show what changed, who acted, which rule was used and who confirmed the transition. In the public demo this is a project history of actions and versions. It is not a validated operational audit record, electronic signature or clinical source record. Core is useful if it reduces lost tasks, routing errors and unclear handoffs without increasing risk. A pilot compares it with the current process. Every clinically, ethically or regulatorily significant event remains under the control of an assigned professional.

The quality layer is a cross-cutting proposed function of Trialeco. It helps collect possible deviation signals, link them to sources and prepare working evidence for review. The presence of this layer is not itself proof of regulatory compliance. A signal may come from a protocol conflict, missed visit, expired document or communication failure. The system preserves the fact and context. A quality professional determines whether it is a deviation, who investigates it and what action is required. A material problem may require a corrective and preventive action plan, often called CAPA. The module can prepare a working card and collect evidence. Assigned quality roles approve classification, root cause, actions, closure and effectiveness assessment. Design considers applicable good clinical practice principles, data-protection duties, expectations for computerised systems and local procedures. The site must not claim that a module complies with every rule in general. Applicability and validation are established for a specific intended use and pilot. Before operational use, the team defines system requirements, risks and test scenarios. Test results trace to requirements. Model, rule and interface versions are controlled. A material change requires risk assessment, repeat testing and a managed release. Trialeco does not issue an ethics opinion, replace the sponsor, investigator, auditor or regulator, or certify compliance. The value of the layer is connected evidence, clear responsibilities and earlier detection of questions that people must resolve.

Consider an end-to-end synthetic scenario with a test protocol and a synthetic possible-participant profile. This teaching example does not describe a real study, medicine or person and is not used for a medical decision. Protocol Guard extracts proposed criteria and schedule elements. For a day-fifteen visit it shows a day-thirteen to day-seventeen window. An expert compares every critical card with the original and confirms only correct elements. Recruit compares reviewed rules with the synthetic profile. Age is a preliminary match, while a previous-treatment date is missing. The module does not say that the person is eligible. The investigator decides whether screening may continue and which facts need verification. Site Status compares protocol requirements with the test site's information. Team and equipment are confirmed, while training evidence needs clarification. The site provides facts, the CRO assesses within transferred duties, and the sponsor makes the documented decision. After the investigator's decision, Comms prepares an approved organisational message and links it to the process stage. A symptom or medical question stops the automated route and transfers the full context to an authorised professional. Trialeco Core connects events, roles and versions. The quality layer preserves a signal when a rule conflicts with its source or a task is overdue. The team sees one coherent route, while every significant medical, ethical or regulatory action remains with a person.

A polished demo explains an idea but does not prove readiness. Testing starts with a precise defined purpose, prohibited uses and risks for each module. Experts then create a reference standard against which the output can be compared honestly. A test set contains synthetic documents and profiles with known correct answers. Experts annotate criteria, dates, units, conflicts and unknown data. Rare and dangerous errors are included deliberately rather than removed to improve the average score. Extraction testing measures how many reported items are correct and how many expected items were found. Critical omissions, inverted negations, dates, units and source citations are counted separately. Matching tests also count false matches, false mismatches and cases in which the system should have reported insufficient data. Every significant output includes a source and rationale. An expert can correct it and record the reason. If a document is unreadable, rules conflict or confidence is insufficient, the module must stop and transfer the case to a person. The model, instruction, document processor and output schema are versioned. A material change triggers repeat testing on the same reference set and new risk cases. The release process needs a clear owner and a tested rollback route. A pilot starts with one limited process, named roles and a measured current process. Thresholds, critical errors and stop conditions are set before launch. Only a comparison of quality, time and risk can justify expansion from a hypothesis to a testable product.