A modular architecture designed for clinical operations: existing systems remain in place, connectors are switched on independently, and CliniGA OS provides the identity, audit, workflow and oversight layer. This is an integration-ready foundation—not a claim that every connection is already live.
6
module families
15
connector definitions
5
native OS capabilities
0
public secrets or endpoints
The model connects approved systems rather than replacing them, while adding clinical quality, privacy and validation boundaries.
CTMS, EDC, eTMF, LIMS, ERP, IoT and vendor platforms remain systems of record.
Approved APIs, webhooks, SFTP, exports and protocol adapters are enabled per connector.
Identity, RBAC, mapping, audit events, scheduled jobs, reconciliation and oversight.
Clinical, site, laboratory, equipment, quality, regulatory and business modules activate independently.
Role-aware work queues, status, evidence and decisions without uncontrolled data duplication.
Every card is backed by a typed connector definition with direction, patterns, data classes and activation gates. Status never means a vendor is live unless production evidence says so.
Study planning, data capture, trial files, randomisation and participant-facing systems.
CTMS
bidirectional · REST API
EDC / eCRF
bidirectional · REST API
eTMF / eISF
bidirectional · REST API
IRT / IWRS
inbound · REST API
eConsent / ePRO
bidirectional · Vendor API
Site intelligence, coordinator workbench, recruitment assumptions and approved engagement.
Site & vendor intelligence
inbound · Native CliniGA OS
Site coordinator workbench
bidirectional · Native CliniGA OS
LIMS, central laboratory, sample custody, courier events and reconciliation.
LIMS / central laboratory
bidirectional · REST API
Courier & shipment
inbound · Carrier API
Environmental telemetry, calibration, maintenance, assets and service evidence.
Equipment & calibration register
bidirectional · Native CliniGA OS
QMS, SOP, CAPA, submissions, safety events and inspection-ready records.
QMS / SOP / CAPA
bidirectional · Native CliniGA OS
Safety / pharmacovigilance
bidirectional · Vendor API
Regulatory submissions
outbound · Approved export
CRM, proposals, contracts, budgets, procurement and controlled finance exports.
CRM & proposals
bidirectional · Native CliniGA OS
ERP & finance
bidirectional · Vendor API
Connection layer
The hub standardises how connectors are identified, mapped, monitored, changed and retired. System-specific logic stays inside its adapter; clinical workflows consume a stable contract.
Connector registry and version pinning
Schema validation and field mapping
Role-based access and service identities
Scheduled jobs, delta sync and idempotency
Retry, dead-letter and reconciliation handling
Audit events and operational observability
Environment separation and secret rotation
Change control, pilot evidence and rollback
The same lifecycle applies whether the system is an EDC, central laboratory, courier, ERP or IoT platform.
Intended use, source system, owner, fields, direction and critical records.
Security, privacy, licence, support, continuity and supplier evidence.
Limited scope with measurable completeness, latency, retry and reconciliation criteria.
Approval, monitoring, change control, rollback, periodic review and retirement.
No. Systems of record remain in place. The hub provides a controlled connector, identity, mapping, workflow, audit and oversight layer around approved interfaces.
No. A connector requires supported interface documentation, data ownership, security and privacy review, mapping, acceptance criteria and a successful bounded pilot.
Never in the public website or source code. Production credentials belong in an approved secret store with least-privilege access, rotation and environment separation.
Only fields required for the documented intended use. Operational metadata is preferred; personal, patient or clinical data requires additional necessity, lawful-basis, privacy and retention controls.
Applicability is assessed per record and intended use. Validation is risk-based and covers critical mappings, audit evidence, retries, reconciliation, access, change control and continued monitoring.
Share the systems of record, vendors, workflows and data classes. CliniGA will build the connector map, define the activation gates and propose a controlled pilot.
