One governed health data warehouse. Every team, one standard.
An Entrepôt de Données de Santé serves many analysts and data scientists at once, from many source systems. Polnor stands up that warehouse on FHIR and OMOP inside your own cloud, on an HDS-certified host, with ingestion, de-identification, mapping, quality control and lineage running themselves. Open standards throughout, so there is no lock-in.
Many source systems, one governed OMOP layer.
You onboard several hospital and departmental systems into a single warehouse. Each is de-identified, standardized to OMOP and quality-checked, then published as governed tables that analysts and data scientists query directly, without a single row leaving your cloud. Here is the path, and how little of it is manual.
| source | persons | OMOP rows | governance |
|---|---|---|---|
| hospital_a · EHR | 612,340 | 48,220,110 | governed ✓ |
| hospital_b · EHR | 408,915 | 31,904,772 | governed ✓ |
| lab_network | 531,207 | 19,551,203 | governed ✓ |
| claims_feed | 897,004 | 72,118,640 | governed ✓ |
Illustrative interface and figures, shown to explain the workflow. Not results from a Polnor customer.
Getting to a governed layer is automated.
Before the first analyst logs in, the platform has already ingested every source, de-identified it, standardized it to OMOP and quality-checked it. Your teams start from governed tables, not raw extracts.
Every source in, at the FHIR standard
EHR extracts, lab feeds and claims from each onboarded system are pulled and normalized to FHIR R4 automatically, one typed table per resource. Adding the next source does not mean writing bespoke ETL again.
| source | resource | status |
|---|---|---|
| hospital_a | Observation | ✓ auto |
| hospital_b | Condition | ✓ auto |
| lab_network | DiagnosticReport | ✓ auto |
GDPR de-identification and OMOP mapping, hands-off
Direct identifiers are masked and dates shifted by preset, then every source is converted to the OMOP CDM with OHDSI concept mapping and clinical quality control. Teams query one common model over Apache Iceberg tables, not one dialect per system.
| source | → OMOP concept | std |
|---|---|---|
| icd10:E11 | Type 2 diabetes | S |
| loinc:4548-4 | HbA1c | S |
| atc:A10BA02 | Metformin | S |
Many teams, one warehouse, at scale
This is where your analysts and data scientists work: define cohorts in SQL or notebooks on the shared OMOP tables, publish reusable features to the feature store, and, when needed, train, track and serve models with MLflow-compatible tooling. Everything runs on compute next to the data, and nothing is exported.
| team | workload | on |
|---|---|---|
| epidemiology | cohort SQL | OMOP |
| data science | feature store | shared |
| ml platform | model serving | /v1 |
The platform runs the warehouse. Your teams run the analysis.
The line is deliberate: the repetitive, error-prone, compliance-heavy work of running a shared warehouse runs itself, so your teams spend their time on questions, not preparation.
Govern the whole warehouse, and stay free to leave.
PHI is classified, every access to patient data is logged, and lineage traces each governed table back to its source. Export follows EHDS-aligned manifests, retention runs as a reviewable dry-run first, and the data never leaves your HDS-certified cloud. Because the warehouse is built on FHIR, OMOP, Apache Iceberg and MLflow-compatible tooling, there is no lock-in: your data and models stay in open standards.
From many source systems to one governed layer, in your cloud.
Book a 30-minute demo. We stand up the automated pipeline on a case that looks like yours, and show you exactly where the automation ends and your teams' work begins.