Clinician · Site Aran cohort_q4 → 287 patients
POPIAHIPAAGDPR
a_4f2a1b…
Home · Product
One platform. Four sovereign modules. Zero data movement.
LumkoMDX is a federated data infrastructure for healthcare. Identity stays at the source; queries travel; insight returns. Each module works alone, but the whole is what makes sovereignty possible.
4
Sovereign modules
One coherent platform
One coherent platform
0
Records ever leave
the source institution
the source institution
3
Boundaries enforced
by architecture
by architecture
FHIR R5
Native conformance
No vendor lock-in
No vendor lock-in
RING 01
Why it exists
Healthcare data has always required a tradeoff. We removed it.
Every healthcare data system in existence asks the same question: how much identity exposure are we willing to accept in exchange for utility?
Aggregation platforms answer it by copying data into central warehouses. De-identification frameworks answer it by stripping fields and hoping. Both treat sovereignty as a policy enforced by humans — and humans, by definition, can be wrong, hacked, or coerced.
LumkoMDX answers it differently. Identity exposure is made structurally impossible by the Three-Boundary Model below. Patient records never leave the source system. Queries are federated. Only aggregated, consent-validated insight ever moves.
The Three-Boundary Model
Three structural promises. Independently enforceable.
Boundary 1
Identity stays at source
Cryptographic pseudonymisation happens before any field leaves the source EMR. The federation layer never sees identifiers.
Boundary 2
Query is the only thing that travels
A query plan goes out; an aggregate comes back. Records, photos, free-text — all stay where they were created.
Boundary 3
Consent is verified at execution
Every query checks consent at the moment it runs — not at sign-up. Revocations propagate in real time.
If a breach is structurally impossible, you don't need to enforce a policy. The architecture is the policy.
That is what "sovereign by design" means. Not a marketing line — a property of the system.
RING 02
How a query travels
The whole platform in one path.
Every module earns its place by doing one job in this flow. The architecture makes it the only path possible.
01
Ask
A clinician, researcher or executive asks a question — in plain language or as a structured cohort filter.
02
Translate
Insight Studio compiles the question into a federated query plan. No identity touches this layer.
03
Route
The Federation Layer fans the plan out to participating sites. Each site executes against its own local data.
04
Aggregate
Only sums, counts, and consented summaries return. Audit & Consent signs every step before, during, after.
End-to-end, no patient record ever moves between institutions. The query travels — the data does not.
RING 03
The platform
Four modules. Designed to compose.
Each module solves a specific problem. The architecture is what makes them sovereign together.
Tour the platform
Cohort Studio
Build patient cohorts across federated sites
Cohort Browser
Find the right patients — without ever seeing them.
A visual environment for building cohorts across federated sites. Every filter, every join, every count is computed at source. Results return as pseudonymous IDs.
- Natural-language and structured filtering
- Live counts as you refine criteria
- Saveable cohort definitions, versioned and auditable
- Direct handoff to Insight Studio
Insight Studio
Ask clinical questions in natural language.
A reasoning surface for clinical and operational analysis. Translates plain language into federated queries — and translates federated results back into plain answers, with full citation.
- Large-model reasoning, restricted to consented data
- Every answer cites its sources and audit trail
- Designed for operational, clinical, and research workflows
- Export to compliant deliverables
Federation Layer
Query travels. Data does not.
The protocol that makes the rest possible. A secure substrate that routes queries to participating sites, executes them locally, and returns aggregated results — never raw records.
- FHIR R5 native; OMOP and custom adapters on roadmap
- Designed for sub-second routing across federated sites
- Cryptographically signed at each boundary
- Operator-controlled — institutions never lose autonomy
Audit & Consent
Every action signed. Every consent checked.
A continuous record of who asked what, when, and under what authority. Consent is verified at the moment of every query, not at sign-up. Compliance is the byproduct, not the goal.
- Immutable, signed audit log per site
- Patient-level consent verification at query time
- Architecturally aligned with POPIA, HIPAA, GDPR
- Single-export regulator package
RING 04
How we compare
It's the combination that's sovereign.
Other approaches solve parts of this. The LumkoMDX difference is the system: sovereignty, federation, and execution-time consent together — by architecture, not policy.
| Capability | Centralised data lakes |
De-identification pipelines |
Federated research networks |
LumkoMDX |
|---|---|---|---|---|
| Identity stays at source | × | ◐ | ◐ | ● |
| No central data copy | × | × | ● | ● |
| Re-identification structurally impossible | × | × | ◐ | ● |
| Federated query at runtime | × | × | ● | ● |
| Consent verified at execution | × | × | ◐ | ● |
| Population-scale analytics | ● | ● | ● | ● |
● FULL ◐ PARTIAL × NOT BY DEFAULT
See LumkoMDX in action.
We'd rather show you than tell you. Walk through a working environment with real federated data.