Chapter 1: Decide who the data are for

In this chapter you will learn to:

• Name the people who will use your registry's data, and rank them.
• Explain why an IRB-approved contact registry is a sound first step when the purpose is not settled yet.
• Apply the Table 1 test to a published paper and to your own registry.
• Tell enrolled, confirmed, and evaluable counts apart.

Case study: A Registry Built on Interesting Questions

This is a pattern I have seen in many registries, one way or another, and part of it is natural evolution. One example from years ago stays with me. A group built a registry around the questions its parents found most interesting. They had not consulted researchers with experience in registries or real world evidence; the researchers they did consult were clinicians with their own clinical interests. Little of it was standardized. The registry asked about an arbitrary list of medications and not about others, and about an arbitrary list of genetic variants and genetic tests that no one had vetted, and it grouped answers in arbitrary ways. Age at key events was asked as an age group rather than as an age, and when researchers later needed finer categories, they could not separate one bracket from another.

I am no longer involved with that registry, and researchers who obtained its data through data use agreements still contact me. They are frustrated that they cannot learn basic facts about the participants, and that what they can publish is limited. Findings that could be exciting are taken less seriously when a paper cannot report the demographics a reader expects in its Table 1, the table that describes the study population.

The opposite failure is paralysis. New registry leaders hear conflicting advice from every direction and worry so much about collecting the wrong thing that they collect nothing. Both problems have the same answer: start small, decide whom the data are for as the conversations with those users grow, and add to the registry step by step.

Lessons for registry leaders

A registry built on questions that seemed interesting, without its future users at the table, keeps costing its community long after its founders have moved on. Starting with a contact registry and growing step by step guards against both collecting too much of the wrong thing and collecting nothing at all.

Start small and grow

The registry journey can be taken one step at a time, each step justified by the conversations before it. A contact registry comes first. Then a look at who else is in the space (Chapter 3), study of established registries, and conversations with the people who will use the data. Only then a standardized core, and the modules each purpose requires.

The registry journey, from a contact registry to data fit for its end user.

The first step carries the least risk and keeps every later option open. Each later step waits until conversations with researchers, sponsors, regulators, and advisors show what it should hold, which guards against investing early in a large, unvetted survey.

Learn from registries that are widely respected

Long-standing, community-developed research programs, such as those built around Parkinson's disease by the Michael J. Fox Foundation or around cystic fibrosis by the Cystic Fibrosis Foundation, show what to collect and what can be done with it. Even without their data dictionaries, their publications show what they were able to report. A practical test: find a published paper similar to the one you hope your registry will support, and look at its Table 1. Could your registry answer every row? Are there rows you think it should have included? If your inspiration is another organization that brought a treatment before the FDA, immerse yourself in what it did: read the documentation, and study which of its data the FDA considered and which it did not. Being a student of this work is part of leading it, especially for anyone who came to registries as a patient advocate without research training.

The rules

1. Name who will use the data, in priority order: trial sponsors, academic researchers, regulators, clinicians, families. Let the top user decide design conflicts. What families most want to know (often quality of life) and what is clinically meaningful or useful to a sponsor are different things; both can be in the registry, but they serve different users with different fields, and conflating them is the most common planning mistake I see.
2. If you do not know the purpose yet, do not stall. Get IRB approval for a contact registry: a few questions, on software as simple as a form, with two consents, may we send you the newsletter to keep you updated, and may we contact you about other study opportunities. That is not consent to those studies, and you may need to reconsent people later, but you can recruit from it. There is no harm in it, and it puts a small nonprofit in a strong position early. In a rare condition, or in a subgroup of one (women with the condition, one disorder within a family of disorders), documentation of who people are and how they can be reached is valuable on its own.
3. Grow the registry one step at a time, each step justified by the conversations before it, rather than collecting everything at once.
4. Frame the primary question in four parts (population, characteristic, comparison, outcome) before choosing a single field.
5. Ask each intended user what they would need to see before they would trust the data, and record the answers.
6. Learn from established registries. Read what widely respected, community-developed programs publish, and use the Table 1 test: find a paper like the one you hope to support and check that your registry could answer every row.
7. If you are inspired by an organization that brought a treatment before the FDA, study what it did, including which of its data the FDA considered and which it did not.
8. Ask the people who have done this. Get an advisor with registry experience, and use the networks in your disease area; in epilepsy, for example, the Rare Epilepsy Network, Combined Brain, and DEE-P Connections. Posting a question on social media is a reasonable start, and an AI tool can summarize what is known if you give it a good prompt.
9. Collect values, not groups, and use standard lists. Ask age at an event as an age, not an age group, and use vetted, standard lists of medications and genetic tests rather than an arbitrary selection.
10. Plan for the registry to evolve, because it will. Contemplate every purpose you might have at the beginning, and write a broad protocol with the IRB that says the disease is poorly understood and modules may be added later. Start basic, with a head-to-toe survey and basic demographics, and add validated instruments or common data elements as they appear, such as a newly validated caregiving or quality of life questionnaire, without starting over.
11. Consent people for the broadest data sharing the IRB will approve, even if no one has asked for the data and you cannot imagine sharing them. That can change, and reconsenting everyone is the alternative.
12. In a family of disorders, decide whether the registry covers the whole family or one subset. When the conditions are poorly understood, go broad, because they may have more to do with one another than is known now, and use branching logic to subset by variant or phenotype.
13. Estimate participation burden before you launch. Walk through the demonstration registry as a participant would: it counts the questions possible, opened, and skipped at enrollment, so the burden of the whole package is concrete, and its question builder estimates the minutes each visit asks of a participant. Most groups underestimate it.
14. Define enrolled, confirmed, and evaluable as different counts, and report which one you are using every time.

What AI can do, and what only a person can do

What AI can do

Turn a rough question into the four-part form; draft a synopsis or a contact-registry consent from your notes; summarize guidance documents and, with a good prompt, what established registries have published.

What only a person can do

Decide what the registry is for; ask a sponsor or a regulator what they need and hear the answer.

None of the decisions in this chapter can be made by AI, and if you ask it to fill them in it will not know, because it does not know your community, and your community is often brand new.

Take-home

A registry built to answer anything answers nothing in particular, no tool can supply the purpose after the fact, and the way to find the purpose is to start small and grow the registry as the conversations with its users grow.

Practice

Exercise

Open the Table 1 test in the workbook.

1. In PubMed, find a published natural history study or registry report in a condition related to yours. Copy the rows of its Table 1, the table that describes the study population, into the worksheet.
2. For each row, mark whether your registry could fill it now (yes, partly, or no) and what it would take to fill it.
3. Repeat the test with the synthetic Lantern Registry export, the book's synthetic practice data set. Open it in a spreadsheet and mark the same rows.

Check your work on the synthetic Lantern Registry

The export can answer, after cleaning: age (from date of birth, once the impossible dates are queried), sex (once the codes are harmonized), country, the genetic variant and its classification for most participants, age at seizure onset (once the units are harmonized), seizure types, developmental delay, and current medication.

It can partly answer how the diagnosis was established: an upload flag says a report exists, but not who reviewed it.

It cannot answer race or ethnicity, how participants were recruited, age at diagnosis, other conditions, or anything about change over time beyond a single follow-up date and a single seizure count. Each of these is a field to consider adding, if the users you named need it.

Your workbook page

The Table 1 test page of the Slow Registry Workbook applies this chapter to your own registry. Fill it in online or print it and work by hand. The AI prompt library has a prompt for this chapter's topic, paired with the step only a person can do.

Check your understanding

A family-led group cannot agree on what its registry is for. What is a sound first step?

An IRB-approved contact registry: a few questions, consent to receive the newsletter, and consent to be contacted about other studies. It keeps every later option open and lets the group recruit when the purpose becomes clear.

Why ask age at an event as an age rather than an age group?

Values can always be grouped later, but a group can never be turned back into values. A bracket that straddles a threshold someone needs later cannot be split.

What separates enrolled, confirmed, and evaluable?

Enrolled participants have consented and provided baseline data. Confirmed participants meet the case definition at a stated tier. Evaluable participants have the data a given analysis needs. They are different counts, and every report says which one it uses.

Up next: Knowing who the data are for is half of the plan; the other half is deciding what the registry will produce first, and planning backward from it. Continue to Chapter 2.