Case study · September 2026

Personal health record

I'm assembling my health history in one folder. What it can do today, and the much larger system I'm building on that foundation.

The nine-year-old scan

In August, my doctor told me that my ferritin and rheumatoid factor were still elevated, and he didn't have a clean explanation for either. He ordered a liver elastography, a scan that measures fat and stiffness in the liver. That surprised me. I rarely drink, I'm lean and active. I wasn't trying to rule out a liver problem but I wanted to know whether I already had evidence that could put it in my specific context. Nine years ago I'd had a whole-body MRI done, and I vaguely remembered that it said something about my liver. Was anything in there relevant?

I asked the agent that runs my personal health record, and two minutes later I had that prior evidence. The December 2017 scan had looked at my liver and put liver fat at 2 percent, with anything under 4 percent counted as normal. It also came with caveats: the scan is nine years old, it wasn't elastography, it never measured stiffness, and it couldn't rule out anything that developed since. In other words, the old result didn't make the new scan unnecessary. I then asked for a short note for my doctor along with the relevant data for review. The agent built that document, which I sent directly to the doctor.

Nothing got diagnosed in that exchange. Nine years of my own history, which the healthcare system doesn't know exists, showed up in the right conversation in a couple of minutes and went back into the formal record. It's a small, recent example of what I'm building. The rest of this piece is about what had to exist for that to happen, and what I intend to build on that foundation.

One folder: originals below, views above

The personal health record is one folder on my laptop. The bottom half is a vault: every original health file I've been able to get my hands on, kept exactly as I received it. That includes lab reports, imaging, my genome, wearable exports, and messages from my doctor. The top half is a reading room: summaries, trend lines, and one file per health topic (blood work, genomics, and so on), all generated from the vault. The originals never change, and the disposable views get regenerated whenever I check in a new record or improve the procedure that builds them.

There's almost no code in the record. It runs on three plain formats, YAML for the catalog cards, Markdown for the views, and SHA-256 checksums for the files, plus a set of written procedures. I run the record with Claude Code or Codex, which let a model read and modify files on my computer, so I can give it instructions in plain English instead of building an application. The procedures don't depend on which model reads them. When I say "check this file in," an agent session runs the check-in procedure: assign the next accession number,§ wrap the file in a catalog card that records where it came from and when, checksum it, and regenerate whatever views it touches. Git records every change to the text, and checksums reveal if the bytes in an original file ever change. Because the folder is my medical history, it has no git remote and doesn't live in a synced folder. That's written into the agent's operating rules as a standing rule, right after "never modify anything in the vault."

None of this design is meant to be original.* Archivists worked out how to keep records long before software existed, and I'd rather borrow what works than invent something new. Archives assign accession numbers. Libraries keep the closed stacks apart from the reading room. The Library of Congress checksums its collections. I explained it to a friend this way: you always keep the primary sources, they sit at the bottom, you build derived data on top, and you keep a way to connect every claim and every insight back to the original it came from.

envelope_version: "1"
id: "2026-0030"
title: "HLI Health Nucleus — 2017-12-21 Whole-Body-MRI Mid-Thigh
  Report Normal-PIRADS1-LiverFat-2pct"
type: "imaging-report"
source: "Human Longevity Inc — Health Nucleus, San Diego"
event_date: "2017-12-21 (inferred)"
acquired_date: "2026-05-15 (inferred)"
notes: "Whole-body MRI (mid-thigh) report. […] event_date
  2017-12-21 from filename. HLI report scanned/re-rendered
  2021-04-14 (PDF metadata), so PDF CreationDate is the scan
  date, not the event date."
events:
  - {date: "2026-06-10", type: "ingestion", agent: "claude",
     detail: "migrated via procedures/migration.md"}

That catalog card is what connects the answer about my liver to its citation. The [2026-0030] at the end of the agent's message is an accession number. Follow it and you get the card. The card sits next to the original PDF, byte for byte what Health Nucleus handed me in 2017. Notice the card is already arguing with itself about dates, because the PDF's metadata says 2021 and the filename says 2017, and the agent wrote down which one to believe and why. Yay metadata.

Every file was checksum-verified when the record launched in June, and every new file is verified on the way in.† The point of holding the files, instead of a login to each place they live, is durability. Data available only through someone else's portal can't be a foundation I control. Access can disappear but I retain possession. Data sovereignty starts with a folder I own, containing the original files. The reading room can be wrong and get rebuilt. The vault is the part nobody else can revoke or lose.

Nobody is watching the whole picture of you

My health history is spread across a half-dozen health systems, and in some cases you have to pay to get copies of your own records. Care is organized around specific encounters and the immediate clinical question, not maintaining a complete picture of me over time. Each clinician sees what their system contains and what I remember to bring. A problem that's persistent but not dangerous doesn't get sustained attention unless I keep pushing for it. No one is responsible for integrating my history across providers, devices, and years. In practice that job falls to me.

We also learn, and are socialized, to put up with persistent aches, bad sleep, and generally feeling unwell. Who do you complain to that could help? You're not a doctor. What do you know? So you learn to live with it, and a pain in your foot becomes a limp, and a limp becomes a lifelong compensation. I've written about step zero, confirming what the problem actually is before you work on it. A fifteen-minute preventative appointment with a physician won't run step zero on your life.

This spring I ran a large direct-to-consumer blood panel through Function Health. The testing itself is comprehensive. The analysis layer on top, however, read like someone had spent thirty seconds on it. There were a few warnings, and no attempt to make sense of the broader picture against my goals and current situation. The sense-making is the hard part.

My annual physical in July is a concrete example of what sense-making looks like. I'd been working through some symptoms with one of my other AI advisors and I wasn't sure how to proceed. The health advisor, the one that reads the record, helped me identify the three relevant questions to take to my physical, along with backing evidence. Based on that evidence, my doctor ordered workups on all three and added a fourth. Without that back-and-forth, the appointment would have been a lost opportunity. The results came back into the record, and that's where the ferritin workup at the top of this piece started.

So if the jobs of integrating and sense-making are mine, what does the record have to do? The first requirement is that it has to hold the actual files, in my custody. The other four are harder. It has to give every signal a place to meet. It has to treat me as a process, not a snapshot. It has to keep representations above the evidence, because the evidence is outgrowing what any person can read. And it has to say only what the evidence supports.

Every signal needs a place to meet

Checking everything into one folder is only the first step, because sitting in the same folder isn't integration. The extraction procedure places each new record's information into shared topic and trend views, with a citation back to its accession, and an agent session can then assemble those views around a question. My current ferritin thread is the working example. It connects this summer's bloodwork, two generations of genetic evidence, the 2017 liver imaging, and my doctor's current plan. They remain different kinds of evidence, from different years and different institutions, but they can finally appear in the same investigation.

### Flagged results [2026-0045]
- Ferritin 431 ng/mL (H; ref 16–243), verified by repeat analysis.
  This rose from 388 ng/mL on 2026-05-07 [2026-0024][2026-0045].
- Rheumatoid factor 37 IU/mL (H; ref <=14), down from 47 IU/mL on
  2026-05-07 but still elevated [2026-0024][2026-0045].
### HFE hemochromatosis panel [2026-0045]
- C282Y negative; […]; S65C negative. ARUP's
  interpretation states that this genotype has not been associated
  with symptoms of hereditary hemochromatosis.
- This clinically confirms the HFE […] observation
  previously reported by HLI research WGS and reproduced in its VCF
  [2026-0035][2026-0044][2026-0045].
- On 2026-08-23, [my doctor] wrote that the single […] copy does
  not appear to indicate hemochromatosis disease. He considered fatty
  liver the most common explanation for the elevated ferritin, planned
  to review the liver ultrasound, and would consult hematology if the
  ultrasound does not show fat [2026-0045].

Nothing in that view was written by hand. It was generated from the vault, and every line carries the accession it came from, so when my doctor's plan changes, the next extraction changes the view and the citation with it. In practice, "a place to meet" means putting a lab value from one institution, a genetic result from a second, a research genome from a third, and a doctor's message from the portal, all in one file, each traceable to its original.

A person is a process, not a snapshot

A blood pressure taken once a year at the doctor's office is one reading, in one setting, on one day, after you drove there and sat in the waiting room. It's a fact, but it isn't a picture. Your heart rate in bed and your heart rate after climbing the stairs to the office are two very different numbers from the same body. A blood panel doesn't know where in a woman's cycle she was. We collect a few isolated points about a person and then reason from them as if they were a complete picture.

The record needs to keep the conditions with the value. I don't want just a number, but the number on this date, fasting or not, after this kind of week, on this medication. A lab report tells you whether a result is inside the reference range. That doesn't tell me how the result compares with my own history or goals.

Population benchmarks have limits. Lab ranges differ by institution. Function Health flagged a lipid result that my doctor reads as fine. Other benchmarks are built from coarse measures designed for groups, not individuals. BMI doesn't distinguish muscle from fat. Mine is 27, which the chart labels overweight, and the body-composition tests in the same record show why that label is misleading. A clinically acceptable result may still be far from my target.

Your own baseline is a different kind of reference. A high-level endurance athlete can have a resting heart rate low enough to alarm an emergency room, and against the population it looks abnormal. Against their own history it's expected. So the record needs three reference points. The population range says what's unusual across people. My own history says what's unusual for me. And my current target is a reference point nobody keeps for me.

We are still measuring too little

The obvious fix for snapshots is to measure more often. The objection is that you end up hoarding data you never use, which is half right. More data is not automatically more knowledge. It can create noise, false patterns, and more material than anyone can interpret. But precision isn't the only thing that makes data useful. A slightly noisy measurement taken every day can tell you more about a changing person than a precise measurement taken once a year. The stream gives you a baseline and a direction, and it makes departures from your normal visible. One fasting number a year tells you where you were that morning. A continuous glucose trace shows how you respond to a meal, and whether that response is changing.

We don't yet know which streams will matter. Some cheap, consistent measurements will turn out to reveal changes nobody knew to look for, and most such experiments will produce nothing. Where collection is cheap and low-risk, I keep more. The raw evidence that can't be recollected stays. For routine streams, I extract the durable patterns and prune the rest under written rules. Collection shouldn't be random. The system I want would identify a measurement that's cheap to get and likely to matter, then ask for it next.

Health records were designed for sparse snapshots. Continuous streams need machinery that can preserve and compress them without losing provenance. That machinery also has to compare them against your baseline and make them interpretable. The reading room is meant to do that. There's one more reason to collect more data. A model can only reason about the data it's given, and right now every model meets me with almost no context about me. Much of what I'm doing here is making myself legible to systems that get more capable every few months.‡

The record is outgrowing what a person can read

For most of medical history the picture of a person was whatever a clinician could collect and hold in their head. A blood pressure, a panel, a note, an image reduced to a paragraph of radiology report. That model of a health record no longer fits the volume of data we can collect. If you wear an Oura ring, you generate a stream. A continuous glucose monitor turns one annual number into a curve. A full-resolution imaging study is a few gigabytes. A genome is over a hundred. Nobody can read or reason about the raw stream.

My genome made this concrete. It arrived as 109.55 GiB of raw sequencing files. The check-in procedure put them in the vault untouched and never opened them again. The analysis used the 91 MiB variant file and a gigabyte of local scratch space. Nothing was uploaded. I ended up with seven reports whose conclusion, for the variants they could analyze, was that none justified a claim about my health.

I'd rather get no conclusion than have a system make one up to sound useful. The genome also shows how to handle a record that's too big to read. At the bottom are the raw reads. Above them is the variant file, a thousandth the size, which discards detail to become usable. Annotated reports sit above that, followed by a view for one specific question and then a decision. Each layer becomes more useful for a particular question while keeping a link to the evidence below it. Imaging is starting to take the same shape. The raw images behind that 2017 MRI report arrived at the end of August, 466 MB of DICOM files, checked in next to the two-page report.

My representations are crude, and they aren't the complete answer. The principle I'm confident in is to preserve high-fidelity evidence below and produce selective, replaceable views above it without confusing the view for the record.

It has to say only what the evidence supports

More data doesn't give you certainty. Most of the time, the evidence isn't enough to settle the question. Cases where one gene decides it are rare. Usually you're weighing incomplete evidence and making the smartest call you can within your context. The record gives me more evidence, better arranged, with the gaps marked. It helps me make better decisions without pretending the uncertainty has gone away.

Saying only what the evidence supports has to be built into the routine work, not just the answers, because most of what the record says later comes from what got extracted at check-in. When my annual exam was checked in this July, the agent wrote a log of what it did and didn't extract.

# Extraction Run - 2026-0040
- Source: […] annual exam visit details, event date 2026-07-27

## Extraction decisions

- The PDF embeds a photograph of the 2026-05-07 Function Health /
  Quest laboratory summary. Those measurements were already
  extracted from the source-of-record PDF at 2026-0024 and were
  not extracted again from 2026-0040.
- Accession 2026-0040 contributes the […] clinician's
  interpretation, diagnoses/problem-list context, orders, current
  visit vitals, and treatment plan.
- Historical […] BP readings displayed in the visit's "last 3
  encounters" table were added to the blood-pressure trend and
  cited to 2026-0040.
- The current clinic weight was added to the weight trend with its
  clinic-scale context. No body-fat value was inferred.
- Ordered tests were recorded as pending orders, not as
  completed results.

Left to itself, a model will fill in a missing result or count the same lab twice. Writing down each extraction decision guards against those errors. The log doesn't prevent every mistake, but it makes them recoverable.

Together, those five requirements make the record a foundation I can build on.

A record that gets better with use

Each new file extends the evidence. Each question exposes what's missing. When I correct a procedure, the correction becomes a standing rule. Better models are the second source of improvement. Because the original files weren't flattened into somebody else's schema, a new model can reread the same evidence and produce a better view. New models arrive every few months. Most software stays exactly as capable as the day you bought it until someone rebuilds it. The record gets better the more I use it, and it gets better when the models do.

The foundation the 2014 advisor was missing

I've been thinking about this problem since at least 2014, when I published a short piece called Building a compass out of tea leaves. The argument was that we make health decisions every day with almost no guidance, that the professional guidance we do get is episodic and blurry, and that what we needed was an advisor combining expert knowledge, lots of data, and human judgment. It named three problems: every expert is limited by what they know, there's more relevant knowledge than any one person can sift through, and it's hard to find the action with the most leverage. It opened with a nurse reading my blood pressure at an annual screening and ended with me admitting I still didn't know what to do with those two numbers.

A model can now surface useful evidence across a personal record quickly enough to make that advisor practical. My fitness advisor is one example. What I missed in 2014 is what has to sit underneath it. An advisor can't integrate evidence it can't access or see a trend without history. If the original is gone, it can't revise an interpretation. And it shouldn't sound more certain than the record allows.

Isn't this terrible privacy practice?

I've been feeding my medical records and my genomic data through commercial AI systems. Isn't that a terrible idea? Maybe.

My records were already scattered across portals, labs, and insurers, under agreements I never read, so the alternative wasn't fully private either. But consolidating them isn't free, and there are two separate risks. Consolidation gives me custody and makes the record usable, while increasing the consequences of a local compromise. Using hosted models adds an exposure to providers whose policies I don't control. I've decided those risks are worth it for me, with safeguards, and I'm still working out better ones.

Here is how I handle those risks now. The record as a whole never leaves my machine. It has no remote or cloud sync. For a given question, an agent session sends the relevant topic and trend files to a hosted model, not the vault. The genome work ran locally and never uploaded a read. I've turned off model training on both of my personal AI accounts. For Claude, that puts me under its 30-day retention policy.

The preservation and security layer of the record is unfinished. That isn't a reason to leave everything scattered across systems that don't connect and don't serve you. Secure backup and tested recovery come next, before the record grows further. And it's a fair argument that this shouldn't be a hobbyist's job at all.

What it costs to run

Aside from the cost of the models, the biggest cost is the attention it takes to operate and develop the record and the advisors on top of it. I'm the user, the systems integrator, the data operator, the product designer, the health interpreter, the LLM operator, and the bullshit detector. This requires a bit of data engineering, a little systems thinking, some knowledge of how a body works, and enough technical depth to run it all. It isn't an app, and it isn't usable by most people.

The deepest failure mode took me a while to see. As models get stronger, their explanations get more plausible whether or not they're correct. If I can't evaluate those explanations, I stop being a check on the model and become dependent on it. I end up approving conclusions I no longer understand. In August, one of my other AI advisors, reading the health record, treated an old blood-count question as unresolved.

log/2026-08-14-labs-partial.md
## 3. ⚠ The eosinophil question may not have been answered

log/2026-08-28-labs-closed.md
## ✔ Eosinophils — CLOSED by clinical decision, not by omission
Correction, 2026-08-28. Earlier entries in this project recorded the
eosinophil question as having "fallen through" because no differential
was ever run. That was wrong, and it is the second time this advisor
has carried an item as open that Laurence had already closed.

STATE-OF-PLAY.md · Standing, low-cost
- Stop re-opening closed items. Twice now this advisor has carried
  something as unresolved that he had already settled […]. When he
  says a question was answered, it was answered.

The machinery worked as designed. The error remains in the log, and the correction is dated. But the correction only happened because I remembered the appointment well enough to challenge a plausible story with a clean citation. Someone who couldn't evaluate that story might have accepted it.

The next version has to be designed for supporting discernment, not requesting approval. That means keeping observations, interpretations, recommendations, and actions separate, so I can see which is which. It also has to recognize when a question exceeds both its competence and mine, and route it to an expert or another system. Turning this into a product isn't just adding a friendly interface. It means building in the expertise I currently supply by hand, without taking away the person's ability to understand, question, and override the system.

The unfinished parts: custody is fragile because the record lives on one machine and independent recovery isn't complete. Most of my wearable history, including Oura and Apple Health, isn't in it yet. The representations are crude. The current record answers when I ask but does nothing on its own, so it never raises anything by itself. Interpretation can be wrong even with perfect provenance. And there's no clinician directly in the loop. I'm relying heavily on the models plus my judgment.

What gets built on the foundation

The personal health record is the evidence and the representations. The personal health system is the whole loop around it: the record, the agents and advisors that use it, me, my doctors, the decisions we make, and the new evidence those decisions produce. The agent operates on the record. It isn't the record, and it isn't the judgment.

The capabilities I want are all points on that loop. The first is a front page for the record, a summary that tells me which parts of my health matter most for my goals right now, instead of making me ask. The second is personal baselines, so that meaningful change is detectable against my own history rather than a population range. The third is a doctor-visit loop that carries my reasoning into the appointment and captures the clinician's judgment coming out. The fourth is translation at the edges, so the record can take in whatever a provider sends and emit whatever a clinician's system expects, with real validation on the way out, instead of everyone first agreeing on one schema. And the last is long-term custody, so the loop survives changes of provider and model, and eventually outlives me, since my history is part of my kids' history too.

vault · reading room · check-in procedure     working, in daily use
cited answers, send-ready exports             working
other advisors reading the record             working
raw imaging checked in beside its reports     working, since late August
genome pipeline, run locally                  ran once
continuous glucose in the vault               two exports; Oura next
longitudinal trends, personal baselines       crude
front page                                    prototyped once, not in use
visit loop (prep in, reasoning out)           designed
cadence: what to measure next                 designed
translation at the edges                      long-term
outlives me                                   long-term

Some products already recommend when to repeat a standard panel or suggest a follow-up test. What I haven't found is one that looks across the whole record, identifies the uncertainty most worth reducing, and tells me which measurement would reduce it. My fitness advisor already answers a similar question: what's the highest-value thing I can do with the next 30 minutes? The next version of the health advisor will ask the same question of the record.

What should I measure next?

The 2014 piece ended with two blood-pressure numbers I didn't know what to do with. They're in the vault now. As best I can tell the reading behind that piece was taken on January 24, 2014, and it was 122/74. It sits in a table with every other blood pressure I have on record, from 2012 to this summer, each one cited to the document it came from.

Date        BP (mmHg)              Source                  [Accession]
2012-03-14  118/70                 biometric screening     [2026-0007]
2014-01-24  122/74                 biometric screening     [2026-0008]
2017-12-21  130/67                 HLI echo header         [2026-0046]
2018-02-14  132/82 134/84 136/84   insurance physical      [2026-0009]
2023-02-02  126/78                 prior encounters        [2026-0040]
2025-04-11  100/60                 prior encounters        [2026-0040]
2026-07-27  112/74                 annual exam, seated     [2026-0040]

The record still doesn't hand me an answer, for the blood pressure or for the ferritin. What it can do now is put this summer's 112/74 next to fourteen years of my own readings, as well as the population range, instead of leaving it as another isolated number.

So what do I do with those two numbers? Twelve years later I have an answer, at least for now. They go into a system I own and keep improving, where they're finally usable. That was the idea I took from David Deutsch's The Beginning of Infinity, which I cited at the end of the 2014 piece. Progress comes from a process that corrects its own errors and doesn't have a final state. In 2014 I had the idea and not the process. Now I have the first version of the process, and the two numbers are in it.

More writing → · How it fits together →