OpenLake
Clinical analytics without
surrendering the data.
Most health data platforms begin by asking you to copy patient records into their tenancy. OpenLake deploys inside your own cloud account, so PHI never transits our infrastructure - there is nothing on our side to hold, log, or lose.
FHIR in, OMOP out
Clinical systems speak FHIR. Research and analytics tooling speaks OMOP. The gap between them is where most health data projects lose a year.
Ingest
FHIR resources land as they arrive - bundles, bulk export, or a feed - and are versioned as Iceberg tables, so every load is reproducible and you can query what the data looked like on any past date.
Map
Resources are mapped into the OMOP Common Data Model: person, visit, condition, observation, and the vocabulary tables that make them mean something. The mapping is declarative and lives in version control, not in someone's notebook.
Analyse
The result is a CDM your existing tooling already understands. Standard OMOP analytics, cohort queries, and dbt models run against it directly, with no OpenLake-specific dialect to learn or migrate off later.
PHI controls that hold however the data is reached
A mask applied in a dashboard protects the dashboard. These are enforced underneath it, in the engine that answers every query.
Identifier columns are found, then masked
As tables are catalogued, columns holding identifiers - names, dates of birth, record numbers, contact details - are detected and masked by default. A role sees the real value only where it has been explicitly entitled to it.
Because the rule is enforced in the query engine, it applies equally to a notebook, a BI tool, a JDBC client, and an ad-hoc SQL prompt.
Every query is on the record
Who ran what, against which columns, when, and how much it scanned - captured for every query, not sampled. That is the evidence an audit actually asks for, and it is queryable like any other table.
Administrative actions - access grants, configuration changes - are recorded separately with the same discipline.
Your keys, your directory
Storage is encrypted under KMS keys you own and can revoke; revoking them ends our access and yours alike, which is the point. Sign-in federates to your own identity provider, so joiners and leavers are handled where you already handle them.
Isolated and air-gapped deployment
The same platform deploys into networks with no internet egress at all, using a delivered-boundary IAM model and an offline artifact path. Built as a first-class target rather than retrofitted after the commercial version shipped.
What has actually been proven
Health claims deserve to be specific, so here is the honest state of this capability rather than a badge.
Validated against synthetic records
The FHIR to OMOP path has been exercised end to end on synthetic patient data: US Core profile validation clean, and the resulting CDM reconciled row-for-row against an independent implementation of the same mapping.
Synthetic data is the correct place to prove a mapping. It is not a claim about operating your production PHI, and we will not make one we have not earned.
HIPAA is your boundary, not our badge
There is no such thing as a HIPAA-certified product, and anyone selling you one is worth a second look. What OpenLake offers is architectural: the platform runs inside the compliance boundary you already operate and attest to, rather than adding a vendor to it.
Encryption, access control, and audit are yours to configure and yours to evidence - we make that practical, not automatic.
Bring us a real dataset and a real question.
The fastest way to judge this is against your own FHIR extract in your own account. If the fit is wrong, we would rather find out early too.