Data & Technology — Glossary¶
The eClinical systems, data standards, and integration patterns that comprise the typical biopharma operational stack — and where Flusso sits in relation to them.
Terms covered:
- eClinical
- CTMS (Clinical Trial Management System)
- EDC (Electronic Data Capture)
- eTMF (electronic Trial Master File)
- CDISC standards (SDTM, ADaM, ODM)
- HL7 / FHIR
- REDCap
- Veeva Vault
- Medidata Rave
- Oracle Health Sciences (Argus, Siebel CTMS, Inform)
- Single source of truth (SSOT)
- Data residency
eClinical¶
Definition. Umbrella term for the family of software systems used to design, conduct, manage, and report clinical trials. The major eClinical categories are CTMS, EDC, eTMF, IRT/RTSM (randomisation and trial supply management), eCOA (electronic clinical outcome assessment), safety databases, and CDMS (clinical data management).
In practice. A typical mid-cap biotech eClinical stack includes:
- One or more CTMS (sponsor-side and CRO-side)
- An EDC (often Medidata Rave, Oracle Inform, or Veeva Vault EDC)
- An eTMF (often Veeva Vault eTMF)
- A safety database (often Oracle Argus or Veeva Vault Safety)
- An IRT system for randomisation and drug supply
- Various supporting systems (lab data, imaging, PRO)
Why it matters. The eClinical stack is the operational backbone of clinical development. Stack fragmentation across multiple systems (and across CRO + sponsor instances of the same systems) is the dominant source of cross-system reconciliation work.
Where Flusso fits. Flusso is not an eClinical system — it doesn't replace any of them. It's the orchestration and insight layer that sits above the eClinical stack and produces the cross-system views that no individual eClinical system provides.
CTMS (Clinical Trial Management System)¶
Definition. A system that manages the operational and administrative aspects of clinical trials — site information, enrolment tracking, milestone tracking, study budgets, monitoring visits, document tracking, and study-level reporting. Distinct from the EDC, which captures clinical data from patients.
In practice. Major CTMS platforms:
- Veeva Vault CTMS — sponsor-side, increasingly the standard for new deployments
- Oracle Health Sciences Siebel CTMS — CRO-side, very widely deployed
- Medidata CTMS — sponsor-side
- Wingspan (acquired by IQVIA) — CRO-side
- Various smaller / regional players
A typical mid-cap biotech operates with both a sponsor CTMS (Veeva Vault) and exposure to one or more CRO CTMS (Oracle Siebel via the CRO).
Why it matters. The CTMS is the canonical operational data source for trial status — site activation, enrolment, monitoring visits, milestone progression. When CTMS data is fragmented across sponsor and CRO instances, sponsor leadership lacks a unified operational view.
Where Flusso fits. Flusso reads from CTMS systems via APIs and produces the unified operational view that sits above the fragmentation. Source CTMS systems remain the system-of-record; Flusso provides the orchestration and reporting layer.
Related: Veeva Vault · Oracle Health Sciences · EDC
EDC (Electronic Data Capture)¶
Definition. The system used to capture clinical trial data from patients — case report forms (CRFs), lab results, vital signs, adverse events, medication histories, and protocol-defined assessments. The "patient data system" of clinical trials.
In practice. Major EDC platforms:
- Medidata Rave — dominant globally; widely used in oncology
- Oracle Inform (formerly Phase Forward Inform)
- Veeva Vault EDC — newer entrant gaining share
- Castor EDC — popular in academic / smaller trials
- REDCap — open-source, very common in academic medicine and IITs
- Various boutique EDCs for specific therapeutic areas
A typical sponsor uses one EDC across most of its trials, often Medidata Rave for oncology programs.
Why it matters. The EDC holds the clinical data that ultimately supports regulatory submissions. EDC data quality, lock readiness, and query rates are core operational signals.
Where Flusso fits. Flusso reads operational signals from the EDC (enrolment, AE/SAE counts, query rates, completion status) but does not replicate clinical data into Flusso. The EDC remains the system-of-record for the clinical dataset.
Related: Medidata Rave · REDCap · Query / query resolution
eTMF (electronic Trial Master File)¶
Definition. The system that holds the Trial Master File — the regulatory-required collection of all essential trial documents (protocols, investigator brochures, ethics approvals, site contracts, signed consent forms, monitoring reports, etc.). Required by ICH-GCP and inspectable by regulators.
In practice. The TMF is structured according to the DIA TMF Reference Model — a standardised taxonomy of ~250 document types organised into zones, sections, and artefacts. Modern eTMF systems support this taxonomy natively.
Major eTMF platforms:
- Veeva Vault eTMF — dominant
- Wingspan / IQVIA eTMF
- Phlexglobal Trial Interactive
- Various others
Why it matters. The eTMF is regulatory-critical — TMF inspection findings are a leading source of clinical inspection observations. TMF completeness is a continuous concern, not just at trial close-out.
Where Flusso fits. Flusso integrates with the eTMF to surface document-status visibility (what's complete, what's overdue, what's expiring) without replicating the document store itself. Document quality and completeness become a tracked operational metric, not just a TMF-team concern.
Related: ICH-GCP · Veeva Vault
CDISC standards (SDTM, ADaM, ODM)¶
Definition. Data standards developed by the Clinical Data Interchange Standards Consortium for clinical trial data. Adopted by FDA and PMDA as required submission formats; widely used elsewhere as de facto standards.
The main CDISC standards:
- SDTM (Study Data Tabulation Model) — standardised structure for collected (raw) clinical trial data
- ADaM (Analysis Data Model) — standardised structure for analysis-ready datasets derived from SDTM
- ODM (Operational Data Model) — XML-based standard for exchanging clinical trial metadata and data, commonly used for EDC-to-EDC and EDC-to-warehouse data movement
- Define-XML — metadata standard describing SDTM / ADaM datasets in submissions
- CDASH (Clinical Data Acquisition Standards Harmonization) — standardised CRF design elements
In practice. A typical regulatory submission includes SDTM datasets, ADaM datasets, define-XML metadata, and analysis programs. CDISC compliance is a non-negotiable requirement for FDA submissions and a strong expectation elsewhere.
Why it matters. CDISC is the lingua franca for clinical trial data exchange. CDISC-aligned data flows enable cross-sponsor data sharing (which Adagene does with Merck, Sanofi, Roche, Incyte) and make regulatory submissions feasible.
Where Flusso fits. Flusso speaks CDISC native — ODM for data exchange, SDTM-aware for operational reporting. No new format introduced; Flusso integrates into the standards your existing systems already use.
Related: EDC · HL7 / FHIR
HL7 / FHIR¶
Definition. Healthcare data interoperability standards developed by Health Level 7 International:
- HL7 v2 — legacy messaging standard, still dominant in hospital-to-hospital and hospital-to-system messaging
- HL7 v3 — never widely adopted
- FHIR (Fast Healthcare Interoperability Resources) — modern REST + JSON-based standard; rapidly becoming the dominant healthcare data exchange standard, including for clinical trial data
In practice. FHIR is increasingly used for:
- Real-world evidence (RWE) data extraction from electronic health records
- Decentralised clinical trial data flows
- Patient-facing apps integrating with sponsor systems
- Cross-system clinical data exchange in modern eClinical platforms
Why it matters. FHIR is the bridge between the clinical-trials world (CDISC-centric) and the healthcare-delivery world (HL7-centric). Decentralised trials, real-world evidence, and EHR-to-EDC integrations all depend on FHIR.
Where Flusso fits. Flusso supports FHIR-based integrations for connecting to healthcare-delivery systems (hospital EHRs, lab systems) where required by the operational use case.
REDCap¶
Definition. Research Electronic Data Capture — an open-source, web-based system for building and managing data capture for research studies, developed by Vanderbilt University. Enormously popular in academic medicine, investigator-initiated trials, and registry studies.
In practice. REDCap is typically the EDC of choice for:
- Investigator-initiated trials (IITs)
- Academic-led registries
- Smaller pharma-supported exploratory studies
- Many institutional research office trials
REDCap supports webhooks (Data Entry Triggers — DETs) for event-driven integration, making it easier than many commercial EDCs to integrate with downstream systems.
Why it matters. A pharma sponsor supporting IITs (like Adagene supporting the NUH Singapore neoadjuvant CRC trial) often has IITs running in REDCap. REDCap data lives outside the sponsor's commercial EDC, which is part of why IITs are operationally invisible without explicit integration.
Where Flusso fits. Flusso integrates with REDCap via DET webhooks and the REDCap API, surfacing IIT operational data alongside sponsor-led trial data. This brings IIT visibility to the same dashboard as sponsor trials.
Veeva Vault¶
Definition. A family of cloud-based content and data management applications from Veeva Systems, purpose-built for life sciences. Widely deployed across pharma and biotech for content management (RIM, eTMF, QualityDocs), CTMS, EDC, and safety.
In practice. Common Veeva Vault applications in clinical operations:
- Vault CTMS — sponsor-side trial management
- Vault eTMF — Trial Master File management
- Vault EDC — clinical data capture (newer entrant relative to Medidata)
- Vault Safety — pharmacovigilance and safety case management
- Vault Submissions — regulatory submissions management
- Vault QMS / QualityDocs — quality management
A modern biotech often standardises on Vault for sponsor-side systems.
Why it matters. Veeva is the dominant sponsor-side clinical platform vendor for new deployments. Replacing a Vault implementation is enormously costly — preserving Vault is a strong default.
Where Flusso fits. Flusso integrates with Vault via Vault APIs (Vault has well-documented integration interfaces) as a read consumer. No Vault validation impact; no Vault data migration; Vault remains system-of-record.
Related: CTMS · eTMF · Computer Systems Validation (CSV)
Medidata Rave¶
Definition. The dominant global Electronic Data Capture (EDC) platform, owned by Medidata Solutions (a Dassault Systèmes company). Particularly entrenched in oncology trials.
In practice. Rave is the EDC for the majority of large-cap pharma oncology programs and a significant portion of mid-cap biotech oncology programs. It supports CDISC-aligned data structures natively and exposes integration via Rave Web Services and CDISC ODM exports.
Why it matters. Like Vault, Rave is enormously expensive to displace — re-validation alone is a multi-month effort, and CRO familiarity with Rave is universal. Rave is rarely a system to replace; almost always a system to integrate with.
Where Flusso fits. Flusso integrates with Rave via Rave Web Services and CDISC ODM exports. Operational signals (enrolment, AE/SAE counts, query rates, completion status) flow into Flusso's operational dashboards without disrupting Rave or the CRO workflows around it.
Oracle Health Sciences (Argus, Siebel CTMS, Inform)¶
Definition. Oracle's family of life sciences applications, broadly used in clinical operations:
- Oracle Argus — dominant pharmacovigilance / safety database (used by most of large-cap pharma)
- Oracle Siebel CTMS — widely deployed at CROs as the operational backbone of trial conduct
- Oracle Inform — EDC platform (less dominant than Medidata Rave but significant share)
- Oracle Health Sciences Cloud — newer cloud-native rebranding
In practice. A typical sponsor's CRO partner runs trial operations on Oracle Siebel CTMS; the sponsor's safety database is often Oracle Argus; the EDC may be Oracle Inform or Medidata Rave.
For Adagene specifically (per public information): Oracle Cloud CTMS is deployed via the CRO; Veeva Vault CTMS is the sponsor-side system; Medidata Rave is the EDC.
Why it matters. Oracle systems are deeply embedded in clinical operations, particularly on the CRO side. Bridging the Oracle / Veeva / Medidata divide is the central operational data integration challenge for most modern biotechs.
Where Flusso fits. Flusso reads from each Oracle system via published APIs and CDISC-aligned exports. Sponsor sees a unified view including CRO-hosted Oracle data alongside sponsor-side Vault data alongside Medidata Rave data — without renegotiating any underlying system.
Related: CTMS · Veeva Vault · Medidata Rave · Pharmacovigilance
Single source of truth (SSOT)¶
Definition. A data architecture principle where every data element has one authoritative source — the system that owns it and from which all other consumers derive their copy. The opposite of multi-system fragmentation where the same data element lives independently in multiple systems with potential drift.
In practice. True SSOT is rarely achievable in clinical operations because each eClinical system is the natural source for its domain (CTMS for operational status, EDC for clinical data, eTMF for documents, safety database for AEs). The pragmatic version is federated SSOT: each system is the source for its domain, and a unified view layer provides cross-system visibility without claiming to be the source.
Why it matters. Multiple "sources of truth" for the same data element is the root cause of reconciliation work. Federated SSOT — done well — eliminates the reconciliation work without forcing system replacement.
Where Flusso fits. Flusso operates as the unified view layer over the federated SSOT — every source system remains authoritative for its domain; Flusso provides the consolidated cross-system view.
Related: eClinical
Data residency¶
Definition. The legal and operational requirement that certain data physically resides within specific geographic jurisdictions. Driven by data protection laws (GDPR in EU, PIPL in China, CCPA in California, the Australian Privacy Act, etc.) and by sector-specific regulations.
In practice. Common data residency considerations in clinical trials:
- EU GDPR — personal data of EU residents requires safeguards on transfer outside EU
- China PIPL — strict requirements on data export from mainland China; most clinical trial data must be processed within China
- Australia Privacy Act — health information requires consent or specific exception for cross-border transfer
- US HIPAA — sectoral US health data law; less restrictive on geographic flow than EU/China
Why it matters. A multi-jurisdictional trial can have data residency requirements pulling in different directions — particularly for trials with Chinese sites (Adagene's Sanjin and Dragon Boat partnerships are both China-resident).
Where Flusso fits. Flusso supports multi-region deployment; pilot data stays within the residency boundary specified by the customer. For mainland China data, separate residency models apply; this is typically scoped during discovery rather than committed in a first conversation.
Related: Major regulatory authorities