Palladium logo PALLADIUM

ADHOPT Interactive Data Flow Architecture

Interactive architecture aligned to the ADHOPT Functional Requirements Document v0.1 (31 Aug 2026, Ref. ET-AUC-485967-CS-QCBS). Click any component to explore operations, data structures, workflows and FR traceability.

Africa CDC logo AFRICA CDC
i
FRD-aligned view: Every component is tagged to its functional requirement (FR-1 to FR-10) or the REQ11 technical foundation. ADHOPT is shown as the consumer - not the source - of maturity, surveillance and facility data, per FRD Section 1.2.
A

Governance & Access (cross-cutting)

Africa CDC (superuser) and each Member State operate a dedicated, autonomously managed space. Tenancy, roles and audit rules govern every layer below.

Governs all layers
1

Upstream Sources & Data Intake

ADHOPT consumes - it does not collect - maturity, surveillance and facility data. Named upstream platforms feed the observatory through modular adapters; manual intake is the fallback tier where automation is not yet available (FRD Section 4.1).

Raw data received
2

Staging Database

Protected landing zone for raw submissions, processing batches, validation results, and full traceability.

Validate and prepare
3

Data Ingestion, Cleanup and Mapping

Modular adapters and data-quality services transform incoming records into ADHOPT’s canonical, comparable model, minimising coupling with external systems (FRD Section 4.1).

ETL process
4

Data Warehouse

Curated, historical, analytics-ready repository for approved assessments, metadata, measures, and comparative analysis.

Curated insights
5

Analytics, Planning and Publication Layer

Role-governed decision support: status monitoring across the nine FR-3 domains, geographic views, gap-linked intervention planning, CDISAH tool classification, reporting and controlled publication.

TraceabilityRetain source, batch, country, timestamp, processing status, and lineage from submission through analytics.
QualityOnly validated, standardized, and appropriately approved information moves to curated analytics stores.
GovernancePermissions and workflow rules control submitting, reviewing, publishing, viewing, and exporting data.
ScopeADHOPT consumes - it does not replicate - ADHMAT, OKAPI and CMFR data. It handles aggregate, de-identified indicators and ecosystem metadata; never patient-level records.

Technical Foundation - Non-Functional Requirements

ToR REQ11 / FRD Section 5 · applies across all layers above · accepted under Deliverable 2 (Architecture) and Deliverable 6 (Final Platform)

Openness & sustainabilityGlobal/Digital Public Good principles, open-source code and documentation, CI/CD, Principles for Digital Development.
Standards & interoperabilityAPI-first architecture aligned with HL7 FHIR and OpenHIE; modular adapters for DHIS2, national HIEs and SpeedyMesh/OKAPI.
PortabilityCloud-agnostic, containerised deployment across Africa CDC-approved public and private clouds.
Multi-tenancy & sovereigntyCountry-level data ownership and access control within a single shared continental instance.
Security & privacySecurity and data protection by design: encryption, RBAC and audit logging, compliant with applicable standards.
Offline capabilityLocal data capture and synchronisation for field-based assessments in low-connectivity settings.
ScalabilityExpands from pilot Member States to all 55 Africa CDC Member States without redesign.
Accessibility & localizationWCAG 2.1; English and French this phase, Portuguese and Arabic planned for a later phase.
MaintainabilityComprehensive architecture, API and deployment documentation supporting handover to Africa CDC.