HEALTHCARE AND LIFE SCIENCES
Affine Foundry
A self-service data platform that maps scattered clinical and operational data into analysis ready datasets on the OMOP standard.
- PROJECT
- Affine Foundry
- INDUSTRY
- Healthcare and Life Sciences
- STACK
- React · Python · FastAPI · OMOP CDM · PostgreSQL · Apache Airflow · dbt · HL7/FHIR · AWS
OVERVIEW
The project
Healthcare organisations sit on clinical and operational data in formats that do not agree with each other. Affine Foundry maps those sources into a common data model built on the OMOP standard, so analytics, research and reporting all read the same structure, and an analyst can reach a usable dataset without joining an engineering queue for every request.
CHALLENGE
What made it difficult
Healthcare source systems disagree on almost everything: coding, granularity, field names, and what even counts as a patient encounter. Reconciling them is the whole job, and it is not something that can be done once and then forgotten.
Privacy and compliance sit on top of that. Access rules and data handling cannot be an application concern bolted on afterwards, because by the time the application sees the data it has already moved.
WHAT WE DID
The work delivered.
- 01
OMOP common data model layer
A canonical mapping layer that normalises disparate source schemas into OMOP tables before anything downstream reads them.
- 02
Orchestrated pipelines
Apache Airflow orchestrating the transforms that turn raw source extracts into validated, versioned CDM tables.
- 03
Transformation with tests
dbt for transformation logic and testing, giving each data model documented lineage and automated data quality checks.
- 04
Self-service tooling
Interfaces that let non technical stakeholders assemble datasets without writing SQL or raising an engineering request for each one.
- 05
Governance in the pipeline
Access controls and data governance policies implemented inside the platform, so healthcare privacy and compliance requirements hold by default.
ARCHITECTURE
How it fits together
- A canonical OMOP CDM mapping layer sitting between source extracts and everything downstream
- Airflow orchestrated ETL producing validated, versioned CDM tables
- dbt transformations carrying documented lineage and automated data quality tests
- HL7 and FHIR handling at ingestion, ahead of concept mapping
- Self-service dataset assembly built on the common data model rather than on raw sources
TECHNOLOGY
The stack
- React
- Python
- FastAPI
- OMOP CDM
- PostgreSQL
- Apache Airflow
- dbt
- HL7/FHIR
- AWS
OUTCOME
What exists now.
An analyst goes from a data question to a usable dataset without an engineering ticket standing in between
Analytics, research and reporting read one structure, so a definition agreed once holds across all of them
Privacy and access rules apply in the pipeline rather than in each downstream tool, which is the only place they can be enforced consistently
NEXT
Related work.
NEXT STEP
Tell us what you're building.
Bring us the problem with its real constraints attached. We will tell you what we would build, and what we would not.