Lumen builds Continuity: infrastructure that keeps the source beneath the models you already run, so the evidence is still reachable when the question changes. It was built against clinical data, which is about as unforgiving as data gets. Nothing in the mechanism is specific to it.
None of it would need building if that were already true.
Your organization has a list of questions it stopped asking. Nobody wrote it down. That is what makes it expensive.
They were not dropped for being unimportant. Answering one properly meant four datasets, a stratification nobody anticipated, and a metric that was in no report — a week of analyst time for an answer the meeting had already moved past. So it got deferred. Then deferred again. Then it stopped being a question anyone remembered asking.
The answer was in your data the whole time. It still is. What stood between you and it was arithmetic: asking properly cost more than the answer was worth, and that held every time, so the list only ever got longer.
The answer was already there. Nobody could afford to look.
cohort shrinkage from cumulative ETL steps when full data exhaustivity is required
Priou et al., 2024per-step ETL transfer rates that look acceptable in isolation
Priou et al., 2024the dominant missingness pattern in EHR data — non-random and clinically informative
Haneuse et al.; multipleEvent ordering and timing flatten into date fields.
“Provisional”, “disputed”, “as reported by” — hedges and attributions do not survive an enum.
Who recorded it, why, and from where, drops off in transit.
Measurements ↔ classifications ↔ outcomes break apart in flight.
Schemas forget. Lumen remembers.
All three were measured in healthcare, because that is where the measuring was done. What they measure — what a projection discards on the way in, and what cannot be rebuilt afterwards — is a property of the pipeline, not of the clinic.
Priou S, et al. "Where have my patients gone?" — A simulation study on real-world data processing in Clinical Data Warehouses. ScienceDirect, 2024.
Haneuse S, Daniels M. A General Framework for Considering Selection Bias in EHR-Based Studies. Am J Epidemiol, 2016.
Klann JG, et al. The Generalized Data Model for Clinical Research. BMC Med Inform Decis Mak, 2019.
A real investigation, run on a client’s live healthcare operations. Management arrived with two movements in volume that looked like they needed explaining. The work took minutes. What it returned was not what anyone went looking for.
Two apparent anomalies in volume, both surfaced by leadership, both looking like business events that needed a cause. Explain them.
Neither was a business event. Both resolved to scheduling artifacts — the calendar moving underneath the measurement, not the work changing. Two questions answered and closed.
A third movement was sitting in the same data: a step change a couple of weeks old that no one owned and no report had flagged. Isolating it meant stratifying on a variance structure that only became visible mid-analysis, ruling out three hypotheses against three different datasets, and finally settling it on a lag metric that appears in no standing report.
Every step was chosen by the one before it. The stratification did not exist until the second answer suggested it. The third dataset was out of scope until the second hypothesis failed. The metric that settled it had never been built, because until that morning nobody had needed it.
A dashboard could not have produced this. Nobody knew to build it.
The question worth asking is not whether that was clever. It is what has to be true of a system before a question can move like that at all.
Two things have to hold. This is the first.
For thirty years, organizations have shoehorned reality into rigid schemas. ETL, ELT, early-binding, late-binding, "right-time" binding — every one of them decides what to carry and drops the rest. The unstructured document. The free-text exception. The signal that did not have a column.
The problem was never the model. It was that the model became the only copy. Once the source is gone, every step after it can only lose more, and no later question can reach what an earlier one discarded.
So keep the source. Then project as many models over it as the work requires — curated, governed, fast. When the question changes, re-project instead of re-engineer.
Data must conform. What doesn't fit, dies in transit.
Per-step transfer rates often look fine — Priou et al. measured 73–100% per step. Multi-step cumulative loss is what hurts.
Views are built over a source that is kept. When the question moves, the view is rebuilt from it.
Continuity preserves the narrative nuance, temporal context, and provenance that a pipeline loses when the source does not survive it.
Illustrative — cumulative loss compounded across a six-step pipeline, from the per-step rates cited above.
Keeping the source only helps if three things hold.
Documents, records, images, transactions — everything is preserved in the form it arrived in. Models are projections over that record, not replacements for it. No column, no row, no enum can quietly make a signal unrecoverable.
The same record can be irrelevant today and decisive tomorrow. We re-evaluate against the current question, not against a frozen schema written six years ago.
Embedded intelligence joins, weighs, and synthesizes — turning the lake of preserved signal into operational and analytical answers, fast enough to act on.
Curated views are how access limits and query performance get expressed. Continuity doesn't remove them — it puts something underneath them, so a view can be narrowed, rebuilt, or replaced without another migration. Nothing is migrated to adopt it. The warehouse stays where it is; the source goes underneath.
Continuity within boundaries. Keeping the source raises the question of who can reach it.
That's half of it. The other half is what a question can do once the source stays put.
A dashboard answers the questions it was built for. It cannot answer one whose shape depends on a finding not yet made — where the second question is set by the first answer, where ruling something out means reaching across domains that were never modelled together, and where the metric that finally settles it was in no report.
That loop is what a preserved record makes possible, and it is what turns a week of analyst work into minutes. Lumen sits between the systems you have and the answers you need.
Grain that double-counts when summed, maturity windows before a rate means anything, reversals that have to be excluded — these are built into how the query is constructed and shown in the result. Prompt instructions are not controls.
An answer arrives with the records behind it, so the person asking can check it rather than trust it. A number nobody can trace is a number nobody should act on.
That loop is not ours to run alone.
Continuity is the platform. Everything Lumen sells runs on it — and so do solutions built and sold by other organisations, under their own brands, to their own customers. Customers build on it too, for themselves, inside their own boundaries. One substrate, more than one kind of builder on top of it.
It is also why the range reaches from pharmacy billing to probate without Lumen being a consultancy that takes whatever work comes through the door. The domain changes. The thing underneath it does not.
What the ecosystem shares is the platform. The data is never shared at all — a record stays inside the organization it belongs to, guarded by that organization's own access controls, whoever built the solution reading it.
Document analysis across probate, personal injury, workers’ compensation IME, prescription prior authorization, and personal health records — sold under Bluebird’s brand, to Bluebird’s customers, and built on Lumen’s platform using Lumen’s coding packages. The medical-records capability underneath it is the one the healthcare products use, which is what makes the platform the shared part rather than the industry.
Allocates general ledger costs through operational and physical metrics. Nothing in its data model is specific to an industry: it was first implemented in long-term care, and the domain arrived as authored drivers and a cost centre structure rather than as code.
Different industries, different buyers, the same architecture underneath — and no record that crosses between them.
Two kinds of builder — and two ways of reaching them.
Lumen builds the platform once and reaches its customers two ways. It implements solutions directly, inside a client’s environment under contract. And it supports organisations building their own solutions on the platform, who own their product, their brand, and their customer relationship — Lumen does not sell to the people they sell to.
Either way, technology gets adopted at the speed of trust, not the speed of features. Where we implement, we embed alongside your team — sharing accountability for outcomes, not just delivery. That work spans implementation, change management, and the slow craft of getting AI to behave well in front of the people who have to rely on it.
Engineers and domain specialists on-site, not on a Zoom from a thousand miles away.
Pricing tied to measurable results — not seat licenses or API calls.
Your operational realities shape the product. The product’s capability shapes your operations.
That is the delivery model. What follows is what gets delivered.
Every solution here reads one preserved record — the organization's own, continuous inside it and stopping at its edges — and runs the same investigative loop. That includes NovaDoc, which Bluebird sells under their brand, built on Lumen's platform using Lumen's coding packages.
They are not separate installations that happen to share storage. They talk to each other as they run, so what one establishes is there for the next while the work is still going on — not after something carries it over.
The detail is on the product pages — every solution in depth, or the healthcare vertical end to end.
That is the argument. What follows is only about the name.
In anatomy, the lumen is the open passageway inside a vessel — the space that lets blood, air, light pass through unobstructed. It's also the unit of luminous flux: how much light a source actually emits into the world. Our name carries both.
Evidence is meant to move. Between the record and the decision, between the question and the answer, between the finding and what gets done about it. We build the lumen — the open passage that lets it flow without friction, without loss, without translation tax.
Four arcs facing inward. The people who hold the data, the people who need the answer, the people who pay for it, and the people who build on it — all of them oriented toward a shared center. We are called Partners because nobody does this alone. The work happens at the meeting point.
That is the name. The rest is a conversation.
We are selective about partnerships — we work best with organisations ready to do the integration work that makes AI actually useful, and with teams building their own solutions on the platform. Tell us where you are stuck.