From Data Collection to Learning: The Research Data Gap

It takes 10-15 years and billions of dollars to bring a new drug to market 

That’s too long, too expensive, and it doesn't scale. Something has to give, and the usual suspects get the blame: recruitment delays, trial costs, clunky site operations, painful data collection.

Those are symptoms. The disease underneath them is simpler and less discussed: research systems don't learn from real-world patient experience systemically, routinely, or at scale.

Nowhere is that more visible than in data collection. A typical Phase III pivotal study now generates close to six million data points. Most of that still moves through spreadsheets, disconnected point tools, and workflows that were never built to hold it. When a network runs on one coordinator’s Excel file here and a REDCap form there, data doesn’t accumulate into knowledge, it just accumulates. And when data doesn’t flow between centers, learning doesn’t happen and the field holds still.

That’s the actual crisis, and it’s a workflow problem wearing a data problem’s name.

What a learning health system promises, and why most stall in practice

Learning Health Systems have been discussed for years as an answer to exactly this gap. The concept, as the Agency for Healthcare Research and Quality describes it, depends on leadership committed to continuous learning, real-time evidence gathering, IT systems that get new evidence back to clinicians fast, participants treated as members of the learning team, not just its subjects, and a genuine feedback loop between outcomes and process.

It’s a strong idea. In practice, however, most LHS efforts stay aspirational, whether as a strategy document, a static database, or a dashboard nobody built a habit around. The intent doesn't survive contact with the workflow.

The Flipped Learning Health System

We took the LHS concept and inverted the starting point. Instead of centering the system on data collection, we centered it on immediate value for whoever is expected to use it that day, clinicians, coordinators, participants, investigators. Once each of them gets something back immediately, data becomes a by-product of using the system rather than the point of it.

We call this the Flipped Learning Health System. In practice, it means:

1. Workflows curated per stakeholder - not one generic process imposed on everyone
2. Dedicated interfaces per role - for instance, a perfusionist and a surgeon need different screens, not the same form
3. Lower burden than the method it replaces - digital entry has to beat paper on speed, or adoption doesn’t happen
4. Validation at the point of capture - so an error surfaces while it can still be fixed, not six months later
5. Real-time, collaborative records - visible across sites the moment they’re entered
6. A living workflow, not a static repository - one that keeps evolving with how people actually use it

For example, no one is compelled to use a consumer messaging app. Billions do, because the value is immediate and the friction is close to zero. We brought that same logic into clinical research infrastructure. Data flowing into a central research hub becomes the consequence of that design, not its objective.

What that looks like running: the PUMP Liver Consortium

The clearest demonstration of this model is our work with the PUMP Liver Consortium, an international transplant-center consortium built around a shared dataset for liver perfusion research.

The goal was a living data repository that could support research on pumped livers and help centers expand the pool of viable donor organs. The obstacle was familiar: transplant centers traditionally keep data in siloed local systems that can’t interoperate, so there’s no shared standard, no collective insight, and no simple path to scale the network.

We went beyond simply handing the consortium a bigger database; we instead built the workflow its clinicians actually wanted to use:

• A mobile application configured per center - not one deployment with a center dropdown, but an environment fitted to each center’s operational reality
• 400+ harmonized data fields, defined once and structured consistently, so data from any center is comparable without retrospective reconciliation
• Automated ingestion from perfusion devices - where the machinery already generates data, the platform captures it directly instead of asking someone to transcribe it
• Redesigned workflows for perfusionists and surgeons - perfusionists received streamlined entry tools; surgeons received dashboards and alerts that improved decision-making rather than reporting on it after the fact
• Analytics, available to the centers generating the data - not only to the consortium aggregating it

The results so far: approaching 1,000 cases, roughly 400 datapoints per case, and 400,000+ data points in the PUMP dataset, and growing. More significant than the volume is the direction of travel:

More users → better workflows → more data → better insight → stronger clinical practice → more users.

Each turn strengthens the next. This is what a learning health system looks like when it’s operating, not being described. And, thankfully, the dataset stays in academia, harmonized and ready for the next decade of research, rather than accruing to a private vendor.

The full case study on how the PUMP Liver Consortium built this - the method, the adoption story, and the framework behind it - is coming soon.

Applying this to your own registry or network

The liver transplant specifics aren’t quite the transferable part, the method is:

1. Identify the role whose day you can measurably improve - not the person who wants the dataset, the person whose work is currently hardest. In PUMP, that was the perfusionist. Data follows adoption, and adoption follows relief.
2. Establish the value that person gets on day one. If the answer involves a future publication, the model won’t work. The benefit has to land in the same shift as the effort.
3. Design per role, not per organization. A single form meant to serve five different jobs reliably serves none of them and that’s the most common reason well-funded registries stall.
4. Harmonize fields before collection, not after. Retrospective harmonization is the expense that quietly consumes registry budgets.

The full framework of all seven steps, including how PUMP decided data ownership before the first center joined, will be in the case study once it’s published.

Where traditional approaches still fail

Many research networks still believe that building a central database will produce learning. It doesn’t, not without the workflows, the interfaces, the incentives, and the role-specific value that make the database worth populating in the first place. Databases don’t transform fields; workflows do. That’s the missing link, and it's a real part of why trials remain slow, expensive, and hard to scale.

The future of trials is a living, learning workflow

This model isn’t specific to liver transplant research. This model isn’t specific to liver transplant research. The same logic of solving the operational pain acute enough to earn the data applies across cardiology, oncology, neurology, maternal health, and public health research just as directly as it applies to organ perfusion.

We built this for consortia, sponsors, academic centers, and registries because the underlying problem is the same everywhere. Research doesn’t only need a bigger database, it needs a workflow good enough that people want to use it, with the data as the by-product, not the ask.

See how this comes together across the rest of the platform. 

And if you want the full story behind the numbers above, the PUMP Liver Consortium case study is on its way; we’ll publish it here as soon as it’s ready. Follow Studypages on LinkedIn to know the moment it's live.