Skip to content

Chapter 17: Read what the machine wrote

In this chapter you will learn to:

  • Read an AI-generated summary against what you know about the data.
  • Describe fields so that a tool can choose among them correctly.
  • Trace a number in an output back to the rows that produced it.

Case study: Three Fields Called Genetic

Many registries record genetics in more than one place, and the example below is a pattern I have seen often, not a practice I recommend. A self-report survey asks whether the participant has a family history of the condition, yes or no, and stores the answer in a variable named genetic_1. Results from the registry's biorepository testing, or from abstraction of an uploaded genetic report, go into genetic_2. Genetic information arriving later from the electronic health record goes into genetic_3. The people who built the registry know what each one means because they work with it every day. An AI tool does not.

Which field is right depends on the question. To ask whether families knew of a family history before they enrolled, genetic_1 is the answer. To ask who has a confirmed variant for the condition, one of the later fields is. A participant can say no in genetic_1 and have a confirmed variant in genetic_3, and each answer is correct for its own purpose.

I have analyzed data with an AI tool that chose the wrong field, because I had not described the data well enough for it to choose correctly. I caught it because I knew what the fields meant and read what the tool produced. The tool was not the problem; the structure and the documentation were.

The consequences grow when data are shared. Downstream users inherit the same ambiguity and publish on it, and the registry may never learn that a number was wrong. I have seen this come to light years later, when someone asks why every published figure for the percentage of participants with a genetic cause is lower than what they found using the confirmed-variant field. If participants or samples were labeled by genetic cause for later analyses, including machine learning models, the error is built into every one of them.

In rare epilepsy, many families, in my experience more than not, have found a genetic cause in recent years, often long after a registry first asked. It took us 16 years to find Charlie's. A registry that still answers "does your child have a genetic cause?" with the no I gave at enrollment, and ignores the field holding his variant, gets him wrong. Variant nomenclature can be intimidating, and I find it intimidating too. It is understandable to cover your ears and say, I'm not a data person. Over the years, though, that stance lets one poorly labeled variable carry its error into every analysis built on it, and it keeps the registry from using AI as well as it could.

A barista tastes the coffee before it goes to the customer. Reading what the tool produced, with knowledge of what the data mean, is the same step.

Lessons for registry leaders

An AI tool can choose among fields only as well as the fields are described. Clear variable names, a data dictionary that says which field answers which question, and a person who reads the output with that knowledge keep one ambiguous variable from spreading through every analysis and every shared copy of the data.

The rules

  1. Read every summary, table, and paragraph the tool produces, in full, before anyone else sees it.
  2. Before giving data to an AI tool, give it the data dictionary: what each variable means, where it came from, when it was collected, and which question it answers. A tool cannot tell three fields named genetic apart unless someone has described them.
  3. Name variables for what they hold and where they came from, such as family_history_reported_at_enrollment or variant_from_lab_report, rather than by sequence numbers.
  4. When several fields answer similar questions, document which field answers which analytic question, and name the field used in the plan for each output.
  5. Check whether the tool knew your definitions: which tier counts as confirmed, which window counts as evaluable, which identifier links to samples. If it did not, the output describes a different registry.
  6. Ask for the output in the format you need, and check that it came back in that format.
  7. Trace at least one number in every output back to the rows that produced it.
  8. Keep the code or the prompt that produced the output alongside the output, so someone else could run it again.
  9. Never let generated text be the first time a claim about your participants is made.
  10. When you share data, share the documentation with it, and ask downstream users how they define key variables before they publish. An error in shared data spreads to every study built on it, including labels used to train models.
  11. Revisit definitions whenever the registry adds variables, changes hands, or learns something new about participants, such as a genetic cause found years after enrollment.

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

What AI can do

Draft, summarize, code, chart, and propose, and choose the right field when the data dictionary explains how.

What only a person can do

Know what the data mean; describe them so that a tool can use them; notice what a summary got wrong or left out; put their name on it.

Take-home

AI can generate the summary; reading it, and knowing whether it understood your data, is still your job, and whether it can understand your data depends on how well you have described them.

Practice

Exercise

  1. Read this summary, written as an AI tool might write it from the synthetic Lantern Registry export and the genetics fields file. Find every error.

    The Lantern Registry has enrolled 32 participants with Epilepsy Syndrome X, all with a genetic diagnosis. Participants have a mean of 47.3 seizures per month. Developmental delay is reported in 81 percent of participants. Mean weight is 16.1 kg. Follow-up data are complete for 28 participants (88 percent). Only 25 percent of participants have a known genetic cause.

  2. In the genetics fields file, genetic_1 is the family history question asked at enrollment, genetic_2 is the variant abstracted from an uploaded laboratory report, and genetic_3 is the variant received from the health record. Decide which field answers each of these questions: Did the family know of a family history at enrollment? Does the participant have a confirmed genetic cause?

  3. Write data dictionary entries for the three fields, with names that say what each holds.
Check your work
  • 32 participants: 32 records for 31 children; LR-012 duplicates LR-005.
  • All with a genetic diagnosis: 25 have a qualifying report on file, and none has been reviewed by a qualified person yet; the rest are self-reported, pending, a clinician letter, a variant of uncertain significance, a conflicting gene, or not a case.
  • 47.3 seizures a month: the mean includes the placeholders 999 and -1. Among the 15 evaluable participants the mean is 14.5.
  • 81 percent with developmental delay: counts only the exact word "Yes" over every record.
  • 16.1 kg: includes a weight that was probably entered in pounds.
  • 28 with complete follow-up: counts any date, including one before enrollment and one from 2042.
  • 25 percent with a genetic cause: this is the family history field, genetic_1. Using the confirmed variants in genetic_2 or genetic_3, 9 of the 12 participants in the file, or 75 percent, have a pathogenic or likely pathogenic variant. LR-011 and LR-027 have variants that arrived later from the health record, so their tiers should be reviewed.

Example names: family_history_reported_at_enrollment, variant_from_lab_report, variant_from_ehr.

Your workbook page

The AI use register 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

An AI tool chose the wrong field for an analysis. Whose problem is that?

Usually the registry's. A tool can choose among fields only as well as the fields are described; clear names, a data dictionary that says which field answers which question, and a person who reads the output prevent it.

What is the least you should do with every number an AI tool produces?

Trace at least one number back to the rows that produced it, and check that the tool used your definitions of confirmed and evaluable.

Up next: The reason the reading goes well, or badly, is decided by how the registry was built in the first place. Continue to Chapter 18.