Skip to main content

Patient Registries: What’s Design Got to Do with It? · Part 1 of 1

Removing the Grim from the Reaper

A pre-mortem asks you to imagine that your patient registry has already failed and work backward to understand why. The exercise helps widen the design space, uncover vulnerabilities, and reveal the broader range of factors that need to come together for a registry to succeed.

A hand lifts a cartoon grim reaper off a sheet of paper headed Patient Registry Design, where it crumbles to dust above a diagram linking Patients to eligibility and enrollment, data collection, workflows and processes, data management, and analytics and reporting. A mug reads Better Data Healthier Patients and a sticky note reads Good Design Better Outcomes.

Welcome to the first of what will be many parts in this series on designing patient registries. I admire your bravery. 😊 I’m looking forward to the journey together.

The first several parts of this series will focus on how to better think about patient registries. We’ll start with a little self-examination.

How would you define a patient registry?

I suspect you’d be able to describe the major components, where the registry operates, the people involved, what participants do, how information is collected, and the kinds of value the registry is intended to provide.

The ease with which you can answer that question highlights two important things.

Everyone arrives with a conception of what a patient registry is, shaped by where they have stood.

First, we all come to the table with an existing conception of what a patient registry is. That conception is shaped by our experiences, training, roles, and the settings in which we have worked.

Second, the shape of that definition, and what it means in practice, will vary from person to person. Across those different conceptions, entire components or possibilities may be missing from the picture altogether.

The first step in thinking more clearly about patient registries, then, is to develop a common understanding of what a patient registry is and of the full registry space it may encompass.

By full, I mean seeing enough of the territory that we don’t overlook possibilities simply because they fall outside the kinds of registries we already know. No single registry will include everything that is possible. But we want the larger vision in place so that we can bring them to bear during the design process.

Now try a different kind of question.

If you were looking at a patient registry in operation, what would you see?

Here too, I suspect you could describe quite a bit. You could identify the people involved, the settings in which activities occur, the information moving between people and systems, and many of the things being done to keep the registry operating.

However, James Gibson’s theory of perception gives us an important caution. We don’t simply look at the world and catalog what is there. Much of what we perceive, particularly the functional aspects of our environment, depends on what we are trying to accomplish. We notice things that help us move toward an aim, things that get in the way, and opportunities that become relevant because of that aim.

The same thing happens when we look at a patient registry.

Our experiences, training, roles, technologies, and settings have shaped what a patient registry means to us. That understanding influences the opportunities we notice, the problems we anticipate, and the possibilities that occur to us.

This is why getting the aim right matters so much.

The aim directs our attention and ultimately drives the decisions that shape the registry. But developing a well-formed aim requires an appreciation of the broad range of factors that may be needed for the registry to succeed.

To help with that process, we’ll begin in a somewhat counterintuitive place.

We’re going to imagine that a patient registry fails.

The aim directs attention, and it drives the decisions that shape the registry.

A Vision of Failure

In many fields, post-mortems are routine. After something has gone wrong, teams reconstruct events and ask what happened. Which assumptions were incorrect? Which risks were underestimated? Where did communication, coordination, workflow, or structure break down?

The goal is to understand how the system behaved under real-world conditions and what contributed to the failure.

A pre-mortem simply changes the timing.

Instead of waiting for failure to occur, we imagine that it has already happened and work backward from the outcome. What went wrong? What did we overlook? What worked differently in practice than we expected?

Failing to Spot Failure

In many operational settings, failure is discrete and easy to recognize. A part fails inspection. A machine stops working. A process misses a required specification.

Patient registries often fail differently.

Failure may not arrive as a single catastrophic event. A registry can remain operational while its value gradually erodes.

Enrollment may begin to slow. In a multi-site registry, some sites may stop enrolling entirely while others contribute fewer and fewer participants. Some may remain nominally involved but fall back to contributing only existing data rather than continuing to enroll patients and collect data. At the same time, attracting new sites may become increasingly difficult.

Over time, what began as a broad collaborative effort can shrink to a handful of founding sites, or even become dependent on one particularly committed person who continues to keep things moving.

And yet the registry is still there.

Data are still being collected. Reports may still be generated. Meetings may still occur. From the outside, the registry can appear operational long after meaningful deterioration has begun.

What Failure Shows Us

For our purposes, the value of the pre-mortem is that it forces us to think through a broader registry space and the range of factors involved in making a registry work successfully.

If we focus primarily on a picture of success, it can be easy to concentrate on the most obvious parts of a registry: what information it should contain, what it should produce, and the value we hope it will provide.

Success and failure are wound around the same shaft. The aim has to account for both.

A pre-mortem pushes us beyond that.

By imagining that the registry failed, we must consider what needed to be true for all of its pieces to come together and work successfully. Our view begins to expand from the individual pieces of the registry to the broader conditions, interactions, and dependencies that influence whether the whole thing works as intended.

That broader view also helps us appreciate what a well-formed aim will eventually need to encompass. The aim will need to direct attention not only toward content, outputs, and intended value, but also toward the larger set of factors that allow those things to come together successfully.

Some vulnerabilities uncovered through the exercise can be reduced or eliminated. Others may simply be part of the environment in which the registry has to operate. Those vulnerabilities may need to be accounted for in how the registry functions, monitored over time, or accommodated as circumstances change. In some cases, understanding a vulnerability may even reveal an opportunity that would otherwise have remained hidden.

The same vulnerabilities can also help identify what deserves continued attention. If something is important enough to threaten the success of the registry, it may also be important enough to measure or monitor once the registry is operating.

The goal is not to eliminate every vulnerability. Every patient registry will have them.

The goal is to better understand the full space in which the registry must operate, the factors that need to come together for it to succeed, and the places where that success may be fragile.

The pre-mortem is useful here as a way of expanding how we think about patient registries. It can also be a useful exercise at the beginning of a specific registry effort, when a team is trying to understand what its eventual aim may need to include and what could interfere with achieving it.

In that sense, inviting in the reaper is not about expecting failure. It is about using failure to widen the view before deciding what success will require.

In Part 2, we’ll begin categorizing some of the major risks and vulnerabilities that can shape the success of a patient registry.

All parts in this series

A figure in a navy blazer seated at a desk, whose head is a studio microphone wearing headphones, beside the title Patient Registries: What’s Design Got to Do with It? A stack of books reads Registry Design, Real-World Evidence, and Better Outcomes, and a checklist reads People, Data, Insights, Better Care.
SUMMARY

Patient Registries: What’s Design Got to Do with It?

The possibilities for patient registries have never been greater, and neither have the design choices. This series explores how to frame the registry, work through the tradeoffs, and put it to work.

A hand lifts a cartoon grim reaper off a sheet of paper headed Patient Registry Design, where it crumbles to dust above a diagram linking Patients to eligibility and enrollment, data collection, workflows and processes, data management, and analytics and reporting. A mug reads Better Data Healthier Patients and a sticky note reads Good Design Better Outcomes.
PART 1You are here

Removing the Grim from the Reaper

A pre-mortem asks you to imagine that your patient registry has already failed and work backward to understand why. The exercise helps widen the design space, uncover vulnerabilities, and reveal the broader range of factors that need to come together for a registry to succeed.

Designing something like this yourself?

Tell us what you are building and we will show you how it maps onto Studytrax.

Get started