Protocol Intelligence · Product scope
Follow a protocol choice from its study objective through evidence, visits and specialist questions to a recorded decision. Explore a prepared example now. Confirm which capabilities are available for your team’s product version before using study material.
See the workflow in the sample experience. Confirm the exact capabilities, controls and outputs for a customer evaluation before introducing study data.
Current public scope · 19 October 2026
You can explore three guided, fictional protocol decisions in your browser today. They use prepared material. Live customer collaboration, document handling, approvals and outputs must be confirmed for the specific release your team evaluates.
Compare a collection schedule → Then use the register below to separate what the website demonstrates from features whose customer availability has not been confirmed.
25 capabilities
The planned workflow connects structured study elements to versioned M11 and CDISC USDM mapping targets. Confirm exact standard versions, field coverage, unresolved mappings and validation for the evaluated release. Mapping is not regulatory endorsement or proven conformance.
Check structured output scope →The planned workflow reuses authorised protocols, feasibility material, CRO proposals and lessons within their permitted organisation and study scope. Historical material retains its version, access rights, applicability and uncertainty; prior decisions do not automatically apply to a new study.
Review private material handling →The intended synopsis, protocol and Schedule of Activities derive from the same structured study version. Confirm contradiction checks, sources, unresolved content, draft/approved labels and permitted output formats. The website does not generate customer clinical documents.
Check generated-output boundaries →Later commercial planning may compare permitted proposals and scope changes against a pinned study baseline, retaining currencies, exclusions, assumptions and quote dates. It is not a launch product or a public bid-comparison service; competing CRO bids remain private.
Review expansion boundaries →Begin with a fictional collection-schedule change, then explore separate historical amendment and imaging-window preflight examples. Prepared sources and reviewer perspectives support browser-only draft responses; no live AI, external invitation or approval occurs.
Explore the three examples →The product scope links original protocols to later amendments, observed differences and documented reasons. Live source access, coverage, lineage and extraction quality need confirmation for the evaluated release.
Explore amendment evidence →The intended workflow focuses specialists on material decisions, captures disagreement and prevents unresolved required reviews from being treated as completion. Live assignments, prioritisation and version-bound approvals need release evidence.
Explore attention and review →Future authorised observations may link back to protocol decisions. Operational ingestion, outcome learning and EDC connections are not activated by this website; private study history is subject to agreed access and use rights.
Review learning scope →Try a fictional collection-schedule comparison. Full customer editing of visits, windows, assessments, procedures and collection requirements, plus automated schedule checks, needs release-specific confirmation.
Explore the schedule example →The website links objectives, endpoints, assessments, procedures, visits and data requirements in a prepared model. Endpoint and eligibility changes surface possible review questions; they do not establish clinical validity or update an external system.
Explore the connected change map →Prepared examples show conflicting protocol statements and missing links. Comprehensive scanning, schedule validation and amendment consistency checks need confirmation for the evaluated release.
Explore the review questions →The planned workflow surfaces attributable findings, owners and incomplete coverage across design rules, visits and relevant approved documents. The website example is a prepared conflict; no comprehensive check, clinical validation or regulatory readiness is demonstrated.
Explore preflight scope →The public example has prepared comments only. External identity, invitation scope, expiry, revocation, privacy review and decision-bound feedback need qualification before customer invitations.
Explore the review roles →The planned views need supported inputs about eligibility, site capacity, result turnaround, resources and technology workload. No live site simulation or recruitment forecast is offered by the website.
Explore study consequences →The intended workflow compares a baseline and proposed amendment, including rationale, affected elements, required review and unresolved issues. The public examples are not a formal amendment or approval record.
Explore decisions and amendments →The intended impact package links exact changed versions to affected documents, systems, sites, roles and proposed training requirements. A prepared website list is not a destination update, training record or evidence of effective use.
Explore the handoff scope →Inspect an ICH guidance excerpt and a printable fictional decision record. Neither is a customer product export.
Inspect the example →The website shows objectives, assessments, evidence, comments and version context. It does not establish a complete customer workflow.
Explore the model →This page does not confirm a customer product version, supported file types or available writing and download features.
Inputs and outputs →The comments are prepared examples. Confirm live editing, task assignments, notifications, permissions and sign-in controls for the product version you will use.
Review the document availability list →The named sources are being considered for use. This website does not demonstrate live search or access to every relevant source.
Review source coverage →The demo calculates collection counts and time from explicit sample inputs. It does not predict study feasibility, outcomes or total burden.
Inspect the calculation →The draft examples do not demonstrate verified electronic signatures, formal audit records or protocol downloads for live study use.
Check output boundaries →No live EDC, eTMF or other clinical-system connector is demonstrated. Automatic regulatory submission is not offered.
Review integration scope →Specifications for EDC, eCOA, IRT/RTSM, labs and imaging are future platform direction. Mappings, outputs and interfaces need separate verification; no named vendor connector is claimed as live.
Explore planned handoff →“Release not confirmed” means availability has not been confirmed on this page. It does not mean the feature is absent from all development versions, or promise when it will be available.
Team workflow
This is the team process Tenvia is designed to support. Confirm each feature for the version your team evaluates. The public example illustrates a prepared discussion and a working-draft decision. Formal approvals, signatures, document downloads and amendments need separate evidence for the product version being evaluated.
Create a study or import an authorised protocol and check extracted information.
Invite colleagues and define view, edit, review and approval responsibilities.
Develop connected protocol sections and the visit schedule, with comments and change history.
Review permitted evidence, assumptions and missing information.
Assign review questions, record responses and resolve decisions.
Obtain the required Sponsor approvals for an exact version and preserve the released record.
Prepare and check the controlled protocol document for a regulatory publishing handoff.
Compare amendments, repeat review and approval, and retain earlier versions.
Each evaluation must confirm the available capabilities, access controls, review and approval records, version handling and document output for the exact release.
Explore the team workflowRegional document requirements
Define the controlled protocol documentation needed for the selected countries and application. The Sponsor or CRO’s regulatory team assembles, validates and submits the complete application.
EU/EEA medicines trials: protocol documentation for the clinical trial application through the Clinical Trials Information System (CTIS).
UK medicines trials: protocol documentation for combined MHRA and research ethics review through the Integrated Research Application System (IRAS).
Electronic Common Technical Document (eCTD) publishing: controlled protocol documents for US applications and EU centralised marketing authorisation applications.
Document checks for each country, reviewed translations and protocol synopses.
Separate versions for public disclosure where required, with human review of personal data and confidential information.
Retain the protocol identifier, version, date, approval record and exact regional handoff; track later amendments separately.
CTIS and IRAS applications are distinct from eCTD publishing. Your regulatory team assembles and transmits complete applications. Confirm supported outputs and validate regional document readiness for the selected application; no regulatory acceptance is guaranteed. Internal Sponsor approval is not regulatory or ethics approval.
Explore the regional handoffProduct evidence
The public scenarios use fictional RD-204 and HX-101 study material to examine a historical eligibility amendment, a collection schedule and an imaging-window preflight. Invented documents and prepared reviewer perspectives illustrate a workflow; they are not clinical precedent.
The three guided examples run in the browser without live AI, customer workspace, real external invitations or live document checks.
Collection time is illustrative arithmetic with stated assumptions, not total participant burden. The preflight identifies only gaps in three prepared passages.
The printable record and session-only draft responses are website content, not product exports, approvals or training records.
Other screenshots use a separate 180-participant example. They do not show one complete, connected process.
These are separate examples. Confirm product behaviour and controls for the version and study use being evaluated.
Try the preflight exampleFuture direction
The future study-learning scope links exact protocol decisions and assumptions to authorised execution observations. No live outcome ingestion or learning integration is activated by this website.
Potential signals include recruitment, screen failures, dropout, deviations, missed assessments and later amendments.
Each comparison needs source identity, signal definition, denominator, observation period and missing-data context.
A before/after association is not proof that a protocol amendment caused an improvement.
Private history stays within agreed organisation and study permissions; cross-customer pooling is not included.
Connections to other systems
Each connection needs an approved interface, agreed data permissions and evidence that it works for the relevant product version and planned use. No live clinical-system connector is demonstrated or required to inspect the public sample product.
No certification, regulatory endorsement, protocol approval or autonomous clinical decision is claimed.
The connected scope
Find the design, evidence, review and handover capabilities relevant to your team. These labels describe the demonstrated approach, planned capabilities and future direction; they do not establish customer release availability.
Core design approachCore approach illustrated with sample workflows. Confirm customer availability for the agreed product version.
Planned capabilityPart of the product scope being developed. Release readiness and availability need confirmation.
Future directionFuture architecture beyond the current protocol-development focus.
Introducing Tenvia to your team
A new study question or an existing protocol. Agree the document format, permitted data and first review objective.
Name the study owner, contributors and reviewers. Define Sponsor and CRO access, onboarding and support requirements.
Specify protocol documents, decision records and version history, including the formats your next team needs.
See the proposal checklist and four-stage evaluation plan.
Discuss a platform fee and study-based scope. Your proposal should identify the included studies, users, onboarding, support and any additional services. Prices and commitments are agreed in the order form.
Confirm your support contact, hours, response commitments, training and escalation route before starting. Your study team retains clinical and regulatory responsibilities.
Review the contracting path →Standards and regulatory boundaries
ICH M11, the CDISC Unified Study Definitions Model (USDM) and the TransCelerate Common Protocol Template provide reference points for structured protocol information. For each document or data file, confirm its format, supported fields and evidence that it meets the relevant standard. Naming a standard does not mean compliance has been verified.
Request a demo
See the sample workflow and discuss the people, evidence and product scope your team would need to evaluate.
No confidential study information is required for an introductory discussion.