The record they give you is not your record

This is Part 4 of Blood Work, in the subseries The Extraction. Part 3 ended with four requests filed and 888 documents on their way back. This part is about what was in them, and what was not.

Federal law says I can have my medical record. Epic has a button for it. I pressed the button four times, waited, and got 288 megabytes of XML back.

I want to be fair here, because it would be easy to write the cynical version of this article and the cynical version would be wrong. The export works. It is thorough, it is properly structured, it carries reference ranges and performing labs and collection timestamps, and it arrived in under an hour without anyone's permission but mine. Ten years ago this would have been a box of paper and a copying fee.

But the document each system hands you first is not your record. It is a view of your record, sized to fit something, and it does not tell you what it left out. That turns out to be true in four different ways, and I found every one of them by accident.

How the export works

In any Epic MyChart, the path is Sharing Hub, then "Download health and visit summary." You get three choices: a single visit, a date range, or all visits. Always take all visits.^*

The build is asynchronous. You ask, Epic assembles a zip, and some minutes or hours later it appears on the Requested Records page and an email tells you it is ready. Decline the password protection it offers. It encrypts the archive in a way that no parser can open, and you will be the one who has to open it.

What lands is a zip containing IHE_XDM/Andrew1/DOC0001.XML through however many documents your history warrants, a metadata file, a styled HTML index, and a paginated PDF rendering of the whole thing. For Providence that was 656 documents and 200 megabytes. For MultiCare, six documents and two.

Read the top of any of those XML files and Epic tells you plainly what you are holding:

"This document contains information that was shared with Andrew D Palmer. It may not contain the entire record from Optum Care Washington."

That sentence is in every health summary, from every organization, and it is the most honest thing in the entire export. It is also the only warning you get, and it is far too soft for what it is describing.

The first way: it expires in a week, not a month

The ready notification says, verbatim, that the release "will expire in 30 days."

The Requested Records page, for the same export, says: Expires 08/03/2026 9:49 PM. The request was made on 07/27.

Seven days. Not thirty.

I had a follow-up reminder scheduled off the email's number. It would have fired on August 4th, one day after every export had already died, and I would have had to request all four again from scratch, including Providence's 200 megabytes.

Trust the portal, never the email. And understand what the seven days actually mean: these are rentals. The institution is not giving you a copy of your record. It is lending you one, briefly, and reclaiming it. That single fact is the entire argument for the archive I will describe in Part 5.

The second way: it stops at 200 entries and says nothing

Every export leads with a document called Patient Health Summary. It is first in the list, it is the one the portal previews, and it reads like the whole thing.

It is not.

Two of them stopped at exactly two hundred. The two that did not stop are the two that had fewer than two hundred results to report. That is a cap, not a coincidence.

The cap keeps the most recent entries and drops the rest. Here is what that costs:

• Providence: 8,767 of 14,165 result observations. 62 percent. Everything from 2009 through 2021 vanishes, including all 2,300 observations from 2016, the year I was diagnosed and the year of the most intense treatment in the entire record.
• Fred Hutch: 5,148 of 10,125. 51 percent. All of 2019, 2020 and 2021, which is the complete pre-transplant workup.

For a dataset about a chronic illness, keeping the newest and dropping the oldest is precisely inverted from what matters. The recent values are the ones I can get from a doctor in five minutes. The 2016 values are the ones nobody has looked at in a decade.

And the document does not say it happened. There is no count. No "showing 200 of 1,489." No truncation notice. Nothing in the file distinguishes a complete health summary from one that quietly discarded two thirds of a life. The only way I found it was by parsing the per-visit documents too and noticing that the totals did not agree.

It is not confined to the health summary either. One per-visit Summary of Care document, DOC0218.XML, also stopped at exactly two hundred.

If you take one operational thing from this series: parse every document in the export, never the health summary alone. The summary is a preview that looks like a deliverable.

The third way: what the screen shows is not what the file contains

Open Providence's MyChart and the results list includes tests performed at Optum and at Fred Hutch. Epic calls this Care Everywhere, and it is genuinely impressive: organizations that compete with each other exchanging records so a doctor in one can see what a doctor in another ordered.

It is right there on the screen. It is not in the export.

I checked all 656 Providence documents for the marker Epic uses to tag a record that arrived from another organization. Zero. Then I checked it a second way, comparing Providence's results against Fred Hutch's on exact date and component, across years both organizations cover. Zero overlap. If the export aggregated, that number would have been large.

So the web interface and the export are answering two different questions. The interface answers "what should this patient's care team be able to see," which reasonably includes records from elsewhere. The export answers "what does this organization hold," which reasonably does not. Both defensible. Neither one told me which question it was answering, and the difference is the entire difference between exporting one portal and exporting four.^†

The fourth way, which is the one that actually bothers me

Everything above is about Epic, and everything above is a design tradeoff I can at least reconstruct the reasoning for.

clonoSEQ is different.

clonoSEQ is a test made by Adaptive Biotechnologies that measures minimal residual disease: it looks for the specific genetic fingerprint of my leukemia and reports how much of it is left, down to roughly one cell in a million. Ordinary blood counts tell you whether things look normal. This tells you whether the disease is still there. Across seventeen years of records it is, by a wide margin, the most informative measurement in the dataset.

It does not live in any hospital portal. Adaptive runs its own, at mychart.clonoseq.com, which is Epic again in a specialty coat.

I got access. It holds ten results, September 19, 2022 through November 11, 2025.

My first clonoSEQ test was in June 2016, at diagnosis.

I am confident about that date for a reason that still strikes me as absurd when I write it down. In 2016 or 2017 I toured Adaptive's labs and recorded a patient testimonial, which the company used during clonoSEQ's push toward FDA approval. Approval came in 2018. My testing predates the approval of the test I was testimonial for, which means those early results ran as a lab-developed test or under a trial protocol.

So the portal starts six years after my testing did, and roughly six years of the single most sensitive measurement in the record is not in it. Not truncated at a cap. Not withheld. Just not there, with no indication on the screen that there is a "there" before September 2022.

There is a second wrinkle that took a while to untangle. I did have an Adaptive credential from October 2022, sitting in my email. It is for diagnostics.adaptivebiotech.com, which is the ordering portal, used by clinicians. Different system, same vendor, no results. One company, two portals, and the one you have a login for is not the one with your data in it.

I wrote a phone script for this. Adaptive Assist, 1-855-236-9230, two asks in order: activate the patient portal, and in parallel open a records release under the right of access, because if the activation code takes two weeks the request should already be running. I had prepared for the fight.

I did not need it. The portal came through, and a written right-of-access request for everything predating it went to Adaptive's clinical services address the same afternoon. Thirty-day clock, running now.

But note what the good outcome looks like. The best case, the one where nobody obstructed anything and every system worked as designed, is that I have ten of what I estimate to be twenty-something results, and getting the rest requires a formal legal request and a month of waiting. The right of access is clear, federal, and unambiguous. Exercising it is still an email, a form, and thirty days.

What I actually have

Four exports, 888 documents, 288 megabytes, collected one day into a seven-day window. Seventeen years of results, reaching back to a metabolic panel from 2009 that nobody has had a reason to look at since.

It is a genuinely remarkable amount of data to be able to obtain by pressing a button, and I want to be clear that the button working at all is the good news of this series.

It is also a subset, in at least four ways, three of which are invisible from inside the document and one of which required knowing my own history well enough to notice that six years were missing.

Next, in Part 5: getting all of it onto a disk I control, which turned out to be the part that would not automate.

Numbers in this post come from the loaded dataset and are reproducible from the exports. Provider and organization names appear as they appear in my records.