Skip to content
Clindaddy

Platform

One platform. Two engines. One clinical data lifecycle.

Clinical data work is one continuous chain of translation: protocol to study design, collected data to standards, standards to analysis, analysis to submission artifacts. Clindaddy splits that chain into two engines that meet in the middle.

Request a DemoSee how it works

The lifecycle

Eight stages from protocol to submission.

FlashEDC is accountable for the front of the chain — protocol, study build, and the data capture that follows. FlashAnalysis is accountable for everything downstream. The middle stage is no longer a handoff to a system we do not touch: it is where the study the platform built is used to collect its own data.

FlashEDC

Protocol → EDC & Data Capture

01

Protocol

The sponsor protocol and its amendments define what must be collected.

02

Study Build

Visits, forms, fields, code lists, and edit checks become an EDC study design.

03

Data Capture

Sites and subjects enter data into the EDC environment.

FlashAnalysis

Clinical Data → Analysis → Submission

04

SDTM

Collected data is mapped to CDISC SDTM submission datasets.

05

ADaM

Analysis-ready datasets and derivations are produced.

06

Analysis

Tables, listings, and figures are generated with traceability to source.

07

QC

Independent and cross-artifact checks review the outputs.

08

Submission

Define-XML, aCRF, cSDRG, ADRG, and the eCTD-lite package are assembled.

The two engines

Each engine owns a clearly bounded piece of the work.

Neither product is a general-purpose assistant. Each one takes a defined input, produces a defined artifact, and stops at a point where a person can review it.
01Protocol → EDC & Data Capture

FlashEDC

Transform a clinical trial protocol into a structured EDC study design, then capture study data against it.

  • Visit structure
  • Forms & CRFs
  • Fields & controls
  • Code lists
  • Edit checks
  • Generated programming code
  • +6 more
Explore FlashEDC

FlashEDC · Study builder · Protocol SYN-014

Illustrative

Form · Demographics

FieldTypeCode list
BRTHDTCDateISO 8601
SEXRadioCDL_SEX
RACECheckboxCDL_RACE
COUNTRYDropdownCDL_COUNTRY
02Clinical Data → Analysis → Submission

FlashAnalysis

Transform clinical data into standards, analysis-ready datasets, clinical outputs, QC evidence, and submission artifacts.

  • Data intake
  • Provenance governance
  • SDTM
  • ADaM
  • TLFs
  • Independent QC
  • +10 more
Explore FlashAnalysis

FlashAnalysis · Standards pipeline · Study SYN-014

Illustrative

VS · Vital signs

USUBJIDVSTESTCDVSORRESVSSTRESN
1001SYSBP128128
1001DIABP8282
1002SYSBP134134
1002DIABP8686

Interfaces shown are illustrative and built with synthetic values. They are not customer systems, and no study data is reproduced anywhere on this site.

How the two connect

A single chain of custody, rather than two handoffs.

Point tools create the gap they were meant to close: the design lives in one system, the datasets in another, and the submission documents in a third. The platform is built so the same study identity runs through both engines.

One study identity

A study is identified once. The design produced at study build and the datasets produced downstream belong to the same study rather than to two disconnected tools.

Specifications carry forward

The structure produced at study build — visits, forms, fields, code lists, and edit checks — is the same specification that governs downstream processing.

Consistent governance

Provenance policy, audit logging, independent QC, and human review apply across both engines instead of being re-implemented per tool.

Explore FlashEDCExplore FlashAnalysisRead about the technology

One protocol read, many systems

One protocol read, projected into the systems a trial runs on.

FlashEDC does not build one system. It reads the protocol once and produces a canonical, system-neutral study model — visits, forms, fields, code lists, edit checks — with each element carrying the protocol page and sentence behind it. That neutral model is the product; each trial system is a projection of it.
  1. 01Protocol readThe protocol is read once, by the interpretation pipeline.
  2. 02Canonical study modelA system-neutral design with provenance on every element.
  3. 03ProjectionThe model is projected into each target system's design format.

EDC is our first projection, not our product. The product is the model underneath it.

Illustration of the Clindaddy character holding up one glowing study model card, with light beams projecting from it into eight system panels labelled EDC, RTSM, eSource, CTMS, eTMF, ePRO, eCOA, and eConsent. Only the EDC panel is fully lit; the other seven are faint outlines.
Illustration. One study model, projected outward — EDC built, RTSM in development, the rest architected. The status column below is the one to read.

EDC

Electronic data capture

Built

Visits, forms, edit checks, codelists.

RTSM / IRT

Randomisation and trial supply management

In development

Randomisation and supply.

eSource

eSource

Architected, not built

Source data capture.

CTMS

Clinical trial management system

Architected, not built

Trial and site management.

eTMF

Electronic trial master file

Architected, not built

Trial master file.

ePRO

Electronic patient-reported outcomes

Architected, not built

Patient-reported outcomes.

eCOA

Electronic clinical outcome assessments

Architected, not built

Clinical outcome assessments.

eConsent

Electronic informed consent

Architected, not built

Electronic informed consent.

Read the status column literally. Only EDC is built, against development builds. Everything below it is the roadmap this work points at, not capability we have today. The claim worth making is architectural, and it is true now: the same neutral study model that projects into an EDC is what will project into a different system.

Destination

The destination is an AI CRO.

A CRO is paid to do the work of running a trial, with software as its instrument. Software that can produce trial systems from a single protocol read points somewhere further: a CRO whose instrument is that software. That is the destination this architecture points at — not where Clindaddy is today.

Today Clindaddy is a clinical data automation company with two engines. EDC is built; RTSM is in development; the rest of the systems above are architected, not built.

Governance

Neither engine is allowed to be the last word.

AI assists with interpretation. Deterministic engines execute the specifications. Humans approve the result, and the reasoning behind every number stays traceable.

Read the governance model

Demonstration

See the workflow, step by step.

Evidence is more useful than adjectives. Walk the pipeline each product runs, and the artifact it produces at every stage.

FlashEDC · Study builder · Protocol SYN-014

Illustrative

Form · Demographics

FieldTypeCode list
BRTHDTCDateISO 8601
SEXRadioCDL_SEX
RACECheckboxCDL_RACE
COUNTRYDropdownCDL_COUNTRY

Upload protocol

Document intake with format detection and job initialization.

Illustrative walkthrough using a synthetic protocol. No customer or confidential study material is shown.

Next step

See the platform against a study you already know.

We will walk through one protocol and one dataset, and show exactly where the automation stops and a reviewer takes over.

Request a DemoTalk to Clindaddy