Architecture and integrations

Keep one study model aligned across every system.

Tenvia links approved study intent with relevant historical and public evidence, the systems that execute the study and the records that show what happened. Your specialist platforms remain in place.

Inspect the connected lifecycle
Your studyHistorical trialsReported outcomesLiteratureRegulatory evidence
A core independent of vendors and grounded in evidenceTenvia Protocol Intelligence

Study context · relevant precedent · consequence · authority

EDCCTMSeTMFIRTeCOALabs
Sources, assumptions, decisions and observed results remain linked to the same study.

Connected study lifecycle

Carry approved intent through execution and assurance.

The study remains connected from the approved design to the evidence produced during delivery.

01

Define

Design, simulate and approve the study once.

Protocol intent, relevant precedent, operational assumptions, CRO commitments and downstream requirements become one versioned study definition that is independent of vendors and linked to its evidence.

Approved Canonical Study Definition
02

Build

Translate one approved definition for every target.

Compilers prepare supported configuration packages for each system. Connector capability determines what can be generated, what needs completion and what requires vendor services.

Verified Deployment Manifest
03

Operate

Let specialist systems execute the study.

EDC, CTMS, eTMF, IRT, eCOA, labs, safety and other systems remain accountable for the work and records they own.

Attributable operational state
04

Assure

Detect divergence and govern what changes next.

Tenvia compares observed reality with approved intent, exposes evidence and impact, prepares change sets and waits for the right human authority.

Controlled change propagated

Reference architecture

Clear separation between intent, translation, execution and authority.

Select a layer to inspect its responsibility and its hard boundary.

Layer 03

Canonical Study Definition

Represent protocol structure, visits, assessments, countries, milestones, operational responsibilities, dependencies and approved assumptions without embedding configuration for a particular vendor.

Receives
Approved protocol and operating model decisions, with relevant evidence linked as context rather than treated as study truth
Produces
Stable study objects, evidence relationships and versioned change sets
Hard boundary
It defines the approved study. Clinical records remain in their source systems.

Amendment orchestration

Carry an approved change through the whole study.

A versioned change set links the decision to work for each target, named approvers and the final execution record.

  1. 01
    Approved change

    Eligibility threshold changes

    Amendment 3 changes eGFR ≥45 to ≥60 mL/min/1.73m². Baseline v3.2 remains active until approval is complete.

  2. 02
    Impact graph

    Affected objects identified

    Population assumptions, enrolment forecast, lab requirements, site workload, participant content and build targets become inspectable.

  3. 03
    Change sets

    Work prepared by target

    EDC and eCOA mappings change. CTMS milestones and eTMF expectations require review. IRT remains unaffected.

  4. 04
    Human gate

    Authority stays visible

    The Sponsor approves protocol intent. The CRO owns the coordinated plan. System and content owners validate the work for their targets.

  5. 05
    Deploy & verify

    Supported actions are controlled

    Approved packages move through validated connector boundaries. External identifiers, warnings and verification results enter the manifest.

  6. 06
    Assure

    Reality is reconciled to intent

    Tenvia compares observed versions and attributable evidence with the approved definition, then routes gaps for qualified review.

Build once and prepare every target

Use one definition to create governed packages for each system.

Each target declares what can be generated, what needs completion and what stays with the vendor or system owner.

Architecture direction

EDC

Potential scope
Study structure, visits, forms, fields, specifications for edit checks and metadata where supported.
Human gate
Validation by Data Management and authorised deployment.
Explicit limitation
Exact output depends on the selected platform interface and study validation approach.

Connector lifecycle

Every connection has a defined operating boundary.

Scope, permissions, validation, failure ownership and release status are recorded for each connection.

  1. 01

    Discover

    Confirm the customer’s systems, interfaces, ownership and first decision thread.

  2. 02

    Authorise

    Grant only the required organisation, study, object and operation scope.

  3. 03

    Map

    Bind source and target objects to the canonical definition with provenance.

  4. 04

    Validate

    Test positive, negative, failure, retry, conflict and recovery behaviour.

  5. 05

    Activate

    Release only the approved connector capability for the agreed environment.

  6. 06

    Monitor

    Observe health, latency, version drift, warnings and attributable outcomes.

  7. 07

    Revoke

    Pause credentials and external action without losing the study record.

Required behaviour

Failures remain visible.

  • No silent overwrite of a source system
  • Failed writes remain visible and attributable
  • Retries are controlled, bounded and auditable
  • Conflicts follow deterministic policy or human review
  • Connector access can be paused or revoked
  • Bespoke connections cannot bypass the canonical baseline

AI, evidence and authority

See the evidence behind the insight.

AI can retrieve, compare and explain relevant evidence within the same permissions and provenance model as every other capability. Accountable people still make the decision.

  1. 01

    Understand

    Use the indication, phase, population, endpoints and decision to define what evidence is relevant.

  2. 02

    Retrieve

    Find permitted historical trials, outcomes, literature and regulatory material where legally and technically available.

  3. 03

    Ground

    Retain the source, retrieval date, match basis, assumptions, limitations and provenance.

  4. 04

    Explain

    Compare the evidence with the proposed design and trace the potential downstream consequence.

  5. 05

    Review

    Route the evidence and implication to the person who holds the required authority.

  6. 06

    Decide

    Record the authorised human decision. Tenvia does not make a clinical or regulatory determination.

Current availability

What exists. What is being proved. What comes next.

Procurement decisions should not depend on an implied roadmap.

Available in the foundation

Product foundation

  • Governed study and protocol model
  • Versioned decisions with source relationships
  • Operating model foundations for Sponsors and CROs
  • Product and assurance experience using fixture data
Architecture and contracts being proved

In development

  • Matching of relevant studies with evidence sources attached
  • Canonical coverage that systems can process
  • Attributable evidence and mapping contracts
  • Connector capability model
Planned after architecture review

Platform direction

  • System compilers for named vendors
  • Validated live connectors
  • Configuration drift detection
  • Governed action and assurance across systems

Start with your real environment

Map the systems, owners and authority behind one study.

Inspect the assurance model