Raw FHIR to a deployed model, without the data ever leaving your cloud.
Polnor runs the entire health-data lifecycle, ingestion, de-identification, OMOP structuring, analytics and AI, inside your own infrastructure. Our platform issues the instructions; your patient data never crosses the boundary. Here is exactly how that works.
Two planes, one boundary the data never crosses.
Polnor is split in two. The control plane, the orchestrator, the SQL compiler, the scheduler, is operated by us. The data plane, your patient records, your compute, your models, lives entirely in your cloud, on an HDS-certified host. Only instructions travel from left to right. Data never travels back.
Concretely: a lightweight agent runs in your namespace, connects out to the control plane, and executes the work locally against your object storage and compute. The control plane persists no derived data; logs, query outputs and model artifacts are written back to your bucket, not ours.
Five stages, from source system to production model.
Each stage is pre-built and runs in your cloud. You connect a source once; the platform carries the data from raw FHIR to AI-ready cohorts and deployed endpoints, without you rebuilding the health-data plumbing.
Connect your source at the FHIR standard
Patient records, lab results and clinical reports are pulled from your FHIR server via a $export job and normalized to FHIR R4. Every resource type lands as its own typed “bronze” table, instead of dozens of incompatible extracts.
| resource | rows | status |
|---|---|---|
| Patient | 12,480 | ✓ ready |
| Observation | 1,204,933 | ✓ ready |
| Condition | 88,210 | ✓ ready |
| MedicationRequest | 301,774 | ✓ ready |
Remove what identifies a patient, keep what serves the science
Column-level presets mask direct identifiers, generate stable pseudonyms (so records still link across tables), shift dates consistently and bucket ages. The transformation runs in your cloud, the raw values never reach us. Toggle it on the sample:
| name | ins | birth | dx |
|---|---|---|---|
| Marie Durand | 2 85 03… | 12/03/1985 | E11 |
| Jean Bernard | 1 78 11… | 30/07/1978 | I10 |
| Amina Cherif | 2 90 06… | 05/06/1990 | J45 |
Convert to OMOP, with clinical quality control
The de-identified data is flattened to a “silver” layer, then converted to the OMOP Common Data Model, the reference schema of the global research community (OHDSI). Source codes are mapped to standard concepts, and automated checks catch out-of-range values before they reach analysis.
| source | → OMOP concept | std |
|---|---|---|
| loinc:2339-0 | Glucose [Mass/Vol] | S |
| icd10:E11 | Type 2 diabetes | S |
| atc:A10BA02 | metformin | S |
Build cohorts and features, in SQL or notebooks
Query your OMOP tables directly: assemble cohorts, join lab and clinical data, and materialize features, in SQL or in a notebook, on compute that sits next to the data. Nothing is exported to run an analysis.
SELECT person_id, avg(value) glycemia FROM measurement WHERE concept = 'glucose' AND age > 50 GROUP BY person_id;
Train and serve models, next to the data
Track experiments with MLflow, version your models in the registry, and deploy inference endpoints, all co-located with the data they were trained on. From cohort to production model, nothing is exported. The MLflow tracking API is drop-in compatible, so your existing training code runs unchanged.
| model | AUC | endpoint |
|---|---|---|
| readmission-30d | 0.87 | /v1/predict |
| sepsis-early | 0.91 | /v1/sepsis |
What crosses, and what never does.
“Health-blind” is not a slogan; it is an architectural guarantee. Here is what the control plane can and cannot touch.
Crosses: instructions
SQL text, job definitions, DAG orchestration and table metadata. Enough to schedule and compile work, never the rows themselves.
Never crosses: PHI
Patient records, lab results, cohorts, features and trained models stay in your bucket. Query outputs and logs are written back to your storage, not ours.
Yours throughout
Your cloud credentials are encrypted, data residency is configurable, and every access is logged. We never train our models on your data.
A diabetes cohort, from question to result, nothing exported.
The same workspace your team uses day to day. A query runs against your OMOP tables in your cloud; the result is counted, not extracted.
| person_id | glycemia | n |
|---|---|---|
| p_8f3a… | 1.42 g/L | 36 |
| p_2b71… | 1.28 g/L | 28 |
| p_c04e… | 1.67 g/L | 41 |
The traceability healthcare demands, built in.
HDS hosting
Deployed with HDS-certified hosts (OVHcloud, Scaleway). Your cloud, your country.
PHI access log
PHI classification, an access log over health data, and retention rules. Audit-ready.
EHDS export
Export manifests aligned with the European Health Data Space (EHDS).
Onboarding is measured in weeks, not years.
The health-data complexity is already solved. You bring your cloud and your source; the pipeline is pre-built.
Connect your cloud
Bring your own OVHcloud or Scaleway account. Encrypted credentials, your VPC, your bucket. The agent deploys into your namespace.
Plug in your FHIR source
Point Polnor at your FHIR server or a bucket of bundles. The $export pull and bronze tables are configured for you.
Run the pipeline
De-identification, OMOP and quality control run end to end. Your team is querying AI-ready cohorts in weeks.
How it works, in detail.
Where does the compute actually run?+
What can Polnor see?+
Which standards do you support?+
Do we have to move or copy our data to you?+
Can we use our own models and tools?+
How long until we see results?+
Watch the full pipeline run in your cloud.
In a 30-minute demo we start from your data and walk the complete flow, FHIR → de-identified → OMOP → analytics → AI, without a single row leaving your infrastructure.