AI prompt library¶

The book's position on AI is that it belongs on top of the habits, not in place of them. This page holds a prompt for each chapter's topic, so that a registry leader can use a general-purpose AI tool to organize thoughts, find published work, and draft a starting point, and then do the part only a person can do. Every prompt is paired with that part, because the output is a draft to be read, not a decision.

How to use the prompts¶

Copy a prompt into the AI tool you use, and replace everything in square brackets with your own registry's details.
Give the tool counts, invented examples, and published sources. Never paste participant records, names, dates of birth, contact details, or anything else that could identify a person, and check your IRB (institutional review board) approval and any data use terms before any registry data go into a tool at all.
Read the output the way Chapter 17 describes: trace every claim to its source, and treat anything the tool could not have known about your community as a question to take to a person.
Record what you did with the output in the AI use register: which task the tool did, who reviewed it, and how the output was checked.

The prompts are written for a tool that can search the web. If yours cannot, drop the requests for citations and verify everything it names.

Chapter 1: Decide who the data are for ¶

Use it when: You are drafting the list of people who will use the registry's data and want to test the registry against a published Table 1.

I lead a patient registry for [condition]. The people who may use its data are [list them: trial sponsors, academic researchers, regulators, clinicians, families].

1. For each user, list what they typically need to see in a registry before they would trust its data, and which fields that implies.
2. Find three published natural history studies or registry reports in [condition or a related condition] and list the rows of each paper's Table 1, with the citation and the PubMed identifier.
3. Mark which of those rows a new registry could fill from a short baseline survey and which need a medical record or a laboratory report.

Do not invent studies. If you cannot find three, say so and list what you found.

Then, the person: Confirm each citation in PubMed, then ask one person from each user group what they would need to see, and record their answers in the Table 1 test page. The ranking of users is a decision the registry makes, not the tool.

Chapter 2: Start with the analysis plan ¶

Use it when: You know what the registry's first product will be, or are choosing between a descriptive paper, a trial-ready cohort, and a partner-ready data set, and want the requirements set out.

My registry for [condition] intends its first product to be [a descriptive publication of the population / a cohort a sponsor could recruit from when a trial opens / a data set an industry partner could evaluate], with a target date of [month and year].

1. List what that product requires: the population and denominator, the Table 1 rows, the outcomes, the comparisons, the samples, the consent provisions, and the governance a user of that product would expect.
2. For each requirement, suggest the field, the source, the method of collection, and the standard the field expects (instrument, frequency, who answers), with a note on whether the method is one the measure was validated for.
3. Organize what different kinds of researchers (geneticists, clinical trialists, natural history investigators, health services researchers, industry scientists) tend to need from a registry like this, as questions I should ask them in conversation.
4. List researchers publishing on [condition] or on [mechanism or related condition] in the last five years, with the citation that shows their interest.

Label every item that is a general pattern rather than a finding about [condition]. Do not invent researchers or citations.

Then, the person: Sit down with the researchers the tool found, and with the ones it did not, and ask what they would need to see, what they would be glad to have, and what they would not need. The hypothesis that will shape the registry is often not published yet, and only the conversation reaches it. Record both lists, families' and researchers', in the first product and analysis plan page, and name the product yourself.

Chapter 3: Look at who is already in the space ¶

Use it when: You are about to build and want to know who is already in the space.

List the existing registries, natural history studies, precision medicine programs, biobanks, and patient advocacy groups for [condition, variant, or subgroup]. For each, give the name, the lead institution or organization, what it collects, the population it covers, how a family would enroll, and the source where you found it. Then list what none of them appears to cover (a modality, a population, a question), with the reasoning, and label anything you are unsure about.

Then, the person: Verify each entry at its own web site, then contact the lead of the most similar effort and ask how you could collaborate and what gap you could fill. Deciding to join, to amplify, to fill a gap, or to build is yours.

Chapter 4: Decide what to capture before you go looking ¶

Use it when: You are deciding what to capture, from where, and at what granularity.

For a registry of [condition] whose first product is [product], list the fields it should capture. For each field give the best source (participant or caregiver report, medical record, laboratory report, device, biological sample), the granularity (a value, a date, a coded term), the standard vocabulary or common data element that applies, a validated instrument if one exists and the population it was validated in, and the schedule. Mark the fields that a medical record usually holds and the ones it usually does not.

Then, the person: Check whether the record holds each field it is said to hold, by reading a few records with permission, and ask families how burdensome each instrument would be. The plan that results is reviewed by a person who knows the condition.

Chapter 5: Put a person between the form and the participant ¶

Use it when: You are writing or improving the coordinator's contact plan.

Draft a plan for a registry coordinator's contact with participants in a registry of [condition]: the first call after enrollment, the request for a document such as a genetic report, the reminder for an overdue survey, and the check-in that asks nothing. For each, give the purpose, the questions to ask, what to record afterward, and what to avoid. Write for a parent of a child with a rare condition, in plain language, at a reading level a tired caregiver can take in.

Then, the person: Read every draft aloud and change anything you would not say to a family you know. The coordinator decides what to say; the tool supplies a starting point.

Chapter 6: Know who belongs on the data team ¶

Use it when: You are deciding who belongs on the data team.

A registry of [condition] intends to [product] and will hold [list the data types: surveys, medical records, genetic reports, biological samples, device data]. List the roles the core data team needs and the expertise it should be able to call on, with what each one would do, which decisions each one should be present for, and the denominator each one is best placed to check. Note which roles are often combined in a small organization and what is lost when they are.

Then, the person: Match the roles to people you can name, and ask an advisor in your disease area which expertise you are missing. The tool does not know who is available to you.

Use it when: You are drafting the protocol synopsis, the data dictionary, or the consent, and want a draft to react to.

Draft a one-page protocol synopsis for a registry of [condition] with the first product [product]: purpose, population and case definition, data collected, data sources, follow-up schedule, governance (who approves data requests, under what agreements), data sharing, and withdrawal. Then draft data dictionary entries for [list fields]: variable name, meaning, type, allowed values and units, codes for missing values, and source. Then list the consent provisions the synopsis requires, including recontact, broad data sharing, uploading documents, and future use of samples, with the questions an IRB (institutional review board) is likely to ask about each.

Then, the person: Take the draft to your IRB and to a person with registry experience before anything is finalized. Governance cannot be added later, and the tool cannot know what your IRB will approve.

Chapter 8: Verify the diagnosis before you count it ¶

Use it when: You are defining tiers of diagnostic evidence, or deciding what evidence every field needs.

For a registry of [condition], propose tiers of diagnostic evidence from self-report to a laboratory report reviewed by a qualified person, with what each tier requires and which registry purposes each tier supports. Then, for these fields [list them, for example a functional rating scale completed by caregivers monthly, a seizure count from monthly recall, a weight from a home scale], state the method of collection, whether that method is the one the measure was validated for, the uses the field supports, and the uses it does not support without further validation.

Then, the person: A qualified person reads the reports and records the conclusion, and the registry decides the tier its purpose requires. The tool can suggest the tier a record appears to meet; it cannot confirm a diagnosis.

Chapter 9: Keep records someone else could read ¶

Use it when: You are setting up curation, definitions, and extract logs so that someone else could rebuild a cohort.

Draft templates for a registry's curation log (every change to a value, with the raw value kept), its definitions log (every grouping or derived variable, with a version), and its extract log (every cohort reported, with the rows it came from and the definitions used). Then write the data management section of a methods paragraph for a paper from a registry of [condition], following the STROBE guideline's items on data sources, variables, and missing data.

Then, the person: Fill the logs from the registry's own work, and trace one reported number back to its rows to confirm the logs are enough to rebuild it. The tool drafts the template; the trail is kept by people.

Chapter 10: Track every sample and every link ¶

Use it when: You are tracking samples and identifiers across labs and vendors.

A registry of [condition] sends samples to [labs or vendors] and links to [health systems or other data sources]. List every identifier a participant could acquire along that route, propose a crosswalk table that leads each one back to the registry identifier, and list the checks a sample manifest should pass before results are accepted: the registry identifier exists and is consented, the collection date falls after enrollment, the lab identifier is unique, the consent version is recorded, and a result has been returned within the expected time.

Then, the person: Reconcile the real manifest against the real crosswalk, by hand, and chase every sample that fails a check. The tool can list the checks; the registry holds the crosswalk.

Chapter 11: Hold the weekly meeting ¶

Use it when: You are building the agenda for the weekly meeting from the registry itself.

Here are counts from a registry of [condition] as of [date]: [enrolled, confirmed by tier, surveys overdue, samples without results, open queries, data requests pending]. Draft a weekly meeting agenda from them: follow-ups from last week first, then one item per count that needs a decision, each with a proposed owner (by role) and a proposed date. Keep it to one page.

Then, the person: Replace the proposed owners with named people in the meeting, and record the minutes. Paste counts only, never participant records.

Chapter 12: Go and find out why the data are missing ¶

Use it when: You are investigating why data are missing.

In a registry of [condition], [describe the gap in counts, for example: of 120 participants enrolled, 38 have no follow-up survey, and 30 of those enrolled through one site]. List the possible causes of a gap with that pattern, grouped by where in the process it could arise (design, collection, transfer, vendor, participant), the evidence that would distinguish them, who to ask, and what to look at in the intermediate tables before the final extract. Then list the reason codes a registry could assign to each gap, and the handling strategies an analysis plan could specify for missing data of each kind.

Then, the person: Go and look: query the intermediate tables, ask the vendor with the evidence in hand, and ask the coordinators. Assign the reason codes from what you find, and decide the handling strategy with a statistician for each use.

Chapter 13: Stay in touch on a schedule ¶

Use it when: You are planning a year of contact with participants.

Draft a twelve-month outreach calendar for a registry of [condition] that gives back as much as it asks: newsletters, results shared back, reminders, check-ins that ask nothing, and the survey requests themselves. For each contact give the purpose, the channel, who sends it, and what it gives the family. Then list what the registry should report back to participants each year, in plain language.

Then, the person: Ask families what they want to hear from the registry and how often, and adjust the calendar to what they say. The calendar is a plan for human contact, and people keep it.

Chapter 14: Be part of the community, not a website ¶

Use it when: You are planning how to be part of the community, in both directions.

A registry of [condition] wants to be present in its community rather than a web site. List the places where families of [condition] gather, online and in person, the kinds of events a registry could attend or host (office hours, conference sessions, newsletters, results sessions), and what the registry should bring to each one and take back from it. Suggest how to record each interaction and what it changed.

Then, the person: Show up. Hold the office hours, report back on what the registry learned, and record what each conversation changed in a decision. Presence is the part no tool can do.

Chapter 15: Keep the researchers close ¶

Use it when: You are mapping the researchers who might use the registry, by condition and by mechanism.

List researchers who have published in the last five years on [condition], on [its mechanism or gene family], and on [a neighboring condition that shares the mechanism], with the citation that shows the interest, the institution, and the kind of data each one used. Group them by what they study. Then draft a short message a registry leader could send to one of them, describing the registry in two paragraphs and asking what they would need to see before using its data.

Then, the person: Verify each researcher's current work, and send the message yourself; the conversation that follows is where you learn what they are hoping to study next. Keep the researcher map and the data request log from what they say.

Chapter 16: Have the conversations only you can have ¶

Use it when: You are preparing for a conversation with a regulator, a consortium, or an industry partner.

A registry of [condition] has been invited to [present to a consortium that advises the FDA / meet a company considering the registry for a trial]. Prepare a briefing pack outline: what the registry holds (enrolled, confirmed by tier, evaluable for the main outcome), how its key fields were collected and what evidence stands behind each, its governance and data sharing route, what it cannot yet support, and the questions the other side is likely to ask. Then list the questions I should ask them.

Then, the person: Fill the pack with the registry's own counts and the real answers to how each field was collected, and have the conversation yourself. The room a regulator or a company sits in is one the tool cannot enter.

Chapter 17: Read what the machine wrote ¶

Use it when: You are reading an AI-written summary of registry data and want to check it.

Here is a summary written from a registry export, and here are the counts I computed myself: [paste the summary and your counts, no participant records]. For each sentence of the summary, state what it claims, which field and denominator it must rest on, whether my counts support it, and what question I should ask of the data before I believe it. List the sentences that pool categories without saying so, use a placeholder value as a number, or count a field that does not measure what the sentence says.

Then, the person: Trace every number back to its rows yourself before any summary leaves the registry. The reading is yours; a second tool reading the first tool's output is not a check.

Chapter 18: Build so that a machine can use it ¶

Use it when: You are making the registry's data usable by machines: standard vocabularies, a common data model, and machine-readable definitions.

The field [name] in a registry of [condition] holds these free-text values: [list the distinct values]. Map each to a term in [the Human Phenotype Ontology / SNOMED CT / RxNorm / LOINC], with the identifier and the release, and flag values that map to more than one term or to none. Then describe how the registry's tables would be represented in the OMOP Common Data Model, which vocabularies each field would use, and what a FAIR (findable, accessible, interoperable, reusable) description of the registry would need to include.

Then, the person: Check every mapping against the vocabulary's own browser and record the release you used, and have a person who knows the condition review the terms that were ambiguous. A mapping is a curation decision with a trail, not a lookup.

The library grows with the book. If a prompt served you well, or failed you, say how.