01 — Professional work · June 2026 — presentBuilt · user acceptance next
CEPS
CEPS Data Platform & Explorer
At CEPS, I am the sole designer and developer of a data platform and its business application, working with domain teams and the ministerial IT department (DNUM).
CEPS Explorer · amounts, dates and sensitive information maskedEnlarge ↗
0
integrated sources
~0 M
database rows · 6.4 GB
0
business & quality SQL views
0
automated tests
Figures as of 30 September 2026
Architecture
CEPS Data Platform & Explorer
Components, data flows and trust boundaries of the system.
Scroll the diagram →
Technologies
Python
DuckDB
SQL
FastAPI
Next.js
TypeScript
GitLab CI
PostgreSQL (next)
Docker (next)
Design decisions
01
Source files are preserved as-is and tracked by SHA-256 fingerprint; every import is transactional and logged.
02
No identifier mapping is invented: every linkage keeps its method and status, and missing values stay missing.
03
The API is read-only: the business application can never modify the warehouse.
04
Tests run on synthetic data; no data in Git or Docker images, nothing sent to external services.
The problem
Medicine-price negotiations require sales, reimbursement, hospital, rebate and regulatory data. The starting point: scattered files and competing identifiers.
What I built
I built a pipeline that validates these sources, preserves their history and brings analysis into one application.
An application for business teams
Product search, sales and reimbursement by channel, price/volume/mix growth decomposition, HAS assessments and exceptional-access pathways, CSV/Excel exports and one-page product PDFs.
End-to-end traceability
442 source files tracked by SHA-256, 675 logged ingestion runs and 3,922 recorded data-quality issues. Preserved sources, transactional imports and human-approved corrections.
What I own
Requirements, business rules, source adapters, identifier normalization, history preservation, SQL models, API, interface and handover documentation. 113 versioned, logged SQL migrations.
Explicit data rules
No invented identifier mapping. Missing values remain missing. Revisions replace the relevant periods without erasing previous versions. Every linkage retains its method and status.
A controlled working environment
Synthetic-data tests, no data in Git or Docker images and no confidential data sent to external services. A data dictionary, ingestion procedures and a technical handover package are prepared.
Next: user acceptance and ministerial infrastructure
The platform and application are built. Next: user acceptance testing, PostgreSQL/Docker migration to DNUM infrastructure and the remaining business decisions.