Why model data?¶
A short read, about 5 minutes, before you open Airtable.
Before you build anything, it is worth being clear on what a data model is and why anyone bothers making one. The exercise that follows is just a way to practice this thinking. The tool is incidental.
What a data model actually is¶
A data model is a deliberate description of three things:
- the things you care about (patients, visits, clinicians),
- the facts you record about each of them (a patient's date of birth, a visit's date), and
- how those things relate to one another (a visit belongs to a patient).
It is a set of decisions about structure, made before you type in a single row. The rows are the data. The model is the shape you pour them into.
Why bother modelling at all?¶
You could put everything in one big spreadsheet: one row per visit, with the patient's name, date of birth, and community copied in beside every visit. It works, until it doesn't. A good model earns its keep in a few specific ways.
- One source of truth. A patient's date of birth is stored once, not re-typed on every visit. Correct it once, and it is correct everywhere.
- No silent drift. When the same fact is copied into many places, the copies stop agreeing. "Sarah Nguyen" and "Sara Nguyen" quietly become two different people. One Patients table prevents that.
- Questions become answerable. "How many patients did this clinician see last month?" is easy when visits link to clinicians, and painful when everything is flattened into a single sheet.
- Quality is built in. Structure lets you require a field, restrict it to a date, or limit it to a set of choices, so bad data is harder to enter in the first place.
- Privacy has somewhere to live. When sensitive facts sit in a clearly bounded table, you can reason about who should see them. In a flat sheet, everything is exposed to everyone.
Modelling is cheap. Fixing a bad model after it has filled with real data is not.
Tables are things; fields are facts about them¶
This is the single most useful distinction in the exercise:
- A table is a kind of thing that exists in its own right and that you have several of. Patients. Visits. Clinicians.
- A field is a fact that describes one of those things. A name. A date. A role.
So the recurring question, "why is this its own table rather than just another column?", is really asking: is this an independent thing I have many of, or just a detail about something else?
A quick test: if you find yourself copying the same value onto row after row (the same clinician's name against fifty visits), that value is probably a thing in its own right, and it wants its own table.
Choosing your fields: the questions to ask¶
For every field you are tempted to add, ask:
- What question does this field answer? If you cannot name one, you may not need it.
- Is it a fact about this thing? A patient's date of birth is about the patient. The clinician who saw them is not, that is a fact about the visit.
- Will it repeat? A value that recurs across many rows is a hint that it belongs in its own table, referenced by a link.
- Does anyone actually need it? Especially for sensitive data, the safest field is often the one you choose not to collect. Record what the work requires, and no more.
Relationships: how the things connect¶
Once you have your tables, you decide how they link.
- One to many. One clinician has many visits, and each visit has one clinician. This is the common case, and a single linked field handles it cleanly.
- Many to many. A visit may involve several medicines, and a medicine appears across many visits. This needs a linking table (Airtable creates one for you behind a linked field).
The point of a link is that it refers to a thing rather than copying it. The visit does not store the clinician's name, it points at the clinician. Update that clinician once, and every visit still points at the right, current record.
Why this matters for AI in healthcare¶
This is not just database housekeeping. In an AI in healthcare context, the model underneath your data decides what is even possible later.
- A system can only learn from, and answer questions about, what the model records. What you leave out is invisible to it.
- Duplication and inconsistency in the data become error and bias in anything trained on it. "Garbage in" starts at the model, not the algorithm.
- The choices you make here (what counts as a patient, which location field you record, who links to whom) quietly encode assumptions about the people in the data.
- Who can see what is itself a modelling decision. Putting sensitive facts in a bounded, access-controlled table is how privacy becomes real rather than aspirational.
Hold onto these as you build. The reflection at the end will ask you to make some of these trade-offs explicit.