Chapter 7: Settle the protocol, dictionary, and consent before enrollment opens¶
In this chapter you will learn to:
- Draft a one-page protocol synopsis with an IRB-approved place for unsolicited information.
- Write data dictionary entries that someone else could use.
- Walk a likely scenario to its conclusion and list what it would require.
- Explain why a global unique identifier belongs in the first registry.
Case study: A Registry That Grew One Opportunity at a Time¶
I have worked with several organizations that have been around for five to ten years, and their registries evolved in the same way. They started with a contact registry of their own. Then they wanted a fuller registry and signed up with a vendor, and later with a different vendor, each with its own consent. Then an industry partner wanted to run one. Then an academic researcher who was already working in the field had a study of his own. Then they learned that one of the large rare disease registries was collecting their gene, and that an ambitious genetic analysis was planned somewhere else. None of these were bad decisions. They took advantage of new funding, new studies, and new opportunities as they came, and you cannot fault them for failing to anticipate every one of them.
What they could not do, by the time I arrived, was put the pieces together. The registries had different consents. There was no global unique identifier, so the same person could not be matched from one to the next. They spent a large share of their time on administrative questions: who can share what, with whom, under which consent; signing data use agreements; tracking down the original study doctor; chasing data held by a drug company that had since lost interest in the variant and left the space, to find out who was allowed to see it and whether it could be combined with anything. Some of that could have been contemplated at the start, with a broad protocol that allowed sharing and harmonization and assigned an identifier that would travel. Some of it could not have been anticipated by anyone. Either way, the clean-up was years of human work, and AI could not do any of it. You cannot fix bad governance with AI.
Lessons for registry leaders¶
Taking each opportunity as it came was reasonable. What made the later work slow was the absence of a broad protocol, a shared identifier, and a roadmap that anticipated sharing. Decisions made at the start determine how much of a registry's time later goes to administration instead of research.
The rules¶
- Write a one-page protocol synopsis before the first participant: purpose, primary question, case definition with tiers, inclusion and exclusion, outcomes with their validated instruments or common data elements, follow-up windows, team and roles, ethics and governance, data management, and an IRB-approved place for unsolicited information: an open-ended question at each contact and how its answers are recorded.
- Write the data dictionary before collection. A dictionary written afterward is an autopsy.
- Get IRB review. Patient-led registries are not exempt, and independent and central IRBs exist for groups without a university.
- Decide specific versus broad consent now, and make the protocol broad enough to allow data sharing, harmonization with other studies, and participation in larger registries, because changing it later means reconsenting everyone.
- Assign a global unique identifier to every participant from the first registry onward, and carry it into every later vendor, study, and partner, so that one person can be matched across all of them.
- Name the data custodian and a small governance group with at least one family member, and write the criteria for approving data requests. Decide who owns or holds the data under each arrangement, whether with a vendor, an academic partner, or a sponsor, and put the answer in writing. That decision rests on your community's interests and your agreements, and no AI tool can make it for you; my Data Sharing in a Box playbook and my guide to meeting a registry vendor walk through the questions.
- Version every document and keep the old versions.
- Write a research roadmap with your advisors, in a conversation held without AI: what you will do when a new opportunity arrives, how you will harmonize and share, who keeps track of which agreements, and what you could be working on now.
- Walk each likely scenario to its conclusion before enrollment opens, and record what each one would require of you. An industry partner takes a treatment to the FDA in five years. A drug approved for a related condition is repurposed for yours. You need a new outcome measure to make a trial feasible. You want to educate teachers, therapists, and health systems about children in your community. For each: what data would you need to have collected, at what granularity, who would you need to share it with, and what consent and identifiers would that take. This is concrete enough to ask a partner, and it is a page in the Slow Registry Workbook.
- Sort everything you plan into buckets, because each condition is different and no tool can sort them for you. What is essential: you cannot have a coffee shop without coffee, and you cannot have a registry without the core data and the people who collect them. What is nearly essential: it is hard to run the shop without pastries, and hard to run a registry without records or the other modalities your purpose needs. What improves your chances: music, which is the ongoing recruitment and retention work; people may still come without it, but more of them come with it. What people rely on: predictable hours, which are predictable visit windows and predictable outreach, with consistency rather than a flurry of activity whenever a grant comes in.
- Set the hours realistically. Most people running these registries are caring for a child with a rare disease or have one themselves. I have had whole seasons when one health crisis after another in my own family meant I could do nothing extra at all. Plan for that, in the schedule and in the staffing, from the start.
- You cannot fix bad governance with AI. The data use agreements, the vanished sponsor, the vendor's incompatible consent, and the unmatched participants are human problems to be solved after the fact, slowly, or prevented in the documents you write now.
What AI can do, and what only a person can do¶
What AI can do¶
Draft the synopsis, the dictionary, and consent elements from your notes for you to correct; once the data exist, generate the reports and outputs each scenario calls for.
What only a person can do¶
Take legal and ethical responsibility; decide who owns or holds the data; convince a clinician to serve as medical advisor; get an IRB to approve; sit with the advisors and decide the roadmap; sign the data use agreement.
Take-home¶
You cannot fix bad governance with AI; the documents you write before enrollment, and the roadmap you write with your advisors, are what let the registry take the next opportunity without years of administrative clean-up.
Practice¶
Exercise¶
- Using the synthetic Lantern Registry export, write data dictionary entries for
onset_age,dev_delay,sex, andsz_per_month: the variable name, its meaning, its type, the allowed values and units, the codes for missing values, and its source. - Open the scenario walk-through. Take the scenario of an industry partner bringing a treatment to the FDA in five years and list the data, granularity, sharing permissions, consent, and identifiers it would require.
- Draft your own registry's protocol synopsis.
Check your work: example dictionary entries
| Variable | Meaning | Type | Allowed values and units | Missing codes | Source |
|---|---|---|---|---|---|
onset_age_months |
Age at first seizure | Number | 0 to 216, in months; birth recorded as 0 | Unknown, declined, not asked | Parent survey at enrollment |
dev_delay |
Developmental delay present | Coded | Yes, no, unknown | Declined, not asked | Parent survey, confirmed against clinical note where available |
sex |
Sex assigned at birth | Coded | Female, male, intersex | Unknown, declined | Parent survey at enrollment |
sz_per_month |
Number of seizures in the previous 30 days | Integer | 0 or more; values above 300 flagged for review | Unknown, declined, not asked | Seizure diary summary at each follow-up |
Note the renamed onset variable: the unit belongs in the name or the dictionary, not in each cell.
Your workbook page¶
The Protocol synopsis 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¶
Why assign a global unique identifier from the very first registry?
So that one person can be matched across every later vendor, study, and partner. Without it, combining data later means reconstructing who is who by hand.
Can an AI tool decide who owns the registry's data?
No. Who owns or holds the data depends on each arrangement, your agreements, and your community's interests, and people decide it with their advisors and put it in writing. The Data Sharing in a Box playbook and the guide to meeting a registry vendor walk through the questions.
Can AI fix bad governance after the fact?
No. Data use agreements, incompatible consents, a sponsor that has left the field, and unmatched participants are human problems, solved slowly after the fact or prevented in the documents written before enrollment.
Up next: With the plan written, enrollment opens, and the first question every reviewer will ask is whether the people in your registry have the condition. Continue to Chapter 8.