Polnor.
Hospitals

A modern clinical data warehouse, on infrastructure you control.

Care improvement, quality indicators, research cohorts: the questions are clinical, but the answers wait behind ETL, de-identification and standardization. Polnor stands up the analytical foundation of a modern EDS inside your own cloud, on an HDS-certified host, with a pipeline where almost every step runs itself.

A worked case

Which patients came back within 30 days?

A care-improvement question, answered on your own clinical data. From your FHIR server to a standardized cohort, you define the index admissions, count the readmissions, and read a rate, without a single row leaving your cloud. Here is the path, and how little of it is manual.

app.polnor.net / hospital-eds● health-blind
hospital_eds › omop › readmission_30d.sql
▶ Run-- 30-day readmission after index inpatient stay SELECT count(distinct person_id) cohort, avg(readmit_30d) rate FROM visit_occurrence v JOIN condition_occurrence c USING (person_id) WHERE visit_concept_id = 'inpatient';
results · index cohort0 rows exported ✓
metricvaluewindow
index admissions18,647ref
30-day readmission rate11.4%30d

Illustrative interface and figures, shown to explain the workflow. Not results from a Polnor customer.

The features behind it

Everything up to the cohort is automated.

By the time your team writes that query, the hard part is done: the platform has already ingested, de-identified, standardized and quality-checked your clinical data. You start where the clinical question starts.

Automated · ingestion

Straight from your FHIR server, at the standard

Your hospital source is pulled and normalized to FHIR R4 automatically, one typed table per resource. No bespoke ETL per feed, and nothing to reconcile by hand.

Connectors + automated $export pull
Typed bronze tables, refreshed on schedule
ingestion · fhirauto
resourcerowsstatus
Encounter2,418,904✓ auto
Condition6,201,550✓ auto
Observation14,882,110✓ auto
Automated · de-identification & OMOP

GDPR de-identification and OMOP mapping, hands-off

Direct identifiers are masked and dates shifted by preset, then the data is converted to the OMOP CDM with OHDSI concept mapping and clinical quality control. Your cohorts run on standardized concepts, not on free-text local codes.

GDPR presets + stable pseudonyms, applied automatically
Automated OMOP conversion, concept mapping and QC
omop · mappingauto
source→ OMOP conceptstd
icd10:I50Heart failureS
icd10:J44COPDS
loinc:718-7HemoglobinS
You · analysis & models

Cohorts, indicators and models, where the clinic is

This is the part your clinical and quality teams own: define index admissions and readmission windows, compute the indicator, and, if you need it, train and track a risk model with MLflow. Everything runs on compute next to the data, and nothing is exported.

Cohort builder, SQL and notebooks on your OMOP tables
MLflow-compatible tracking and serving in your cloud
mlflow · runserved
modelAUCendpoint
readmit-risk-30d0.81/v1/readmit
los-predict0.86/v1/los
Almost everything is automated

The platform does the plumbing. Your team does the clinic.

The line is deliberate: the repetitive, error-prone, compliance-heavy work runs itself, so your clinical and quality teams spend their time on judgment, not preparation.

Automated by Polnor
FHIR ingestion · refresh
GDPR de-identification
OMOP conversion · concept mapping
clinical quality control
feature materialization · lineage · access log
Your team decides
the clinical question
cohort & index definition
the indicator & its window
the model, and the interpretation
Governance-ready

An EDS you can account for, with a trail behind it.

Every access to patient data is logged, PHI is classified, retention is enforced, and export follows EHDS-aligned manifests. Because the warehouse runs on infrastructure you control, on an HDS-certified host, and we never train our models on your data, the provenance of every cohort is unambiguous.

See it on your data

From your FHIR server to a defensible cohort, in your cloud.

Book a 30-minute demo. We run the automated pipeline on a case that looks like yours, and show you exactly where the automation ends and the clinical work begins.