How to download your own health data as FHIR — portals, APIs, and apps

Ask for your records and you will often receive a 300-page PDF: scanned faxes, sideways pages, a decade of lab results rendered as pictures of tables. Somewhere in there is your creatinine trend. Good luck plotting it.

The PDF is your record the way a photograph of a piano is an instrument. What you want is the data itself — and since US law forced open the interfaces, getting it has become genuinely possible. The format that comes out of those interfaces is called FHIR, and learning to ask for it is the single most useful records skill a patient can have.

Why a PDF is not your data

Human-readable and machine-readable are different things, and the difference decides what your record can do. A FHIR copy represents your history as structured resources — each lab result an Observation with a code and a value, each prescription a MedicationRequest, each diagnosis a Condition — so software can search it, graph it, merge it with last year's, and line it up against records from four other providers. A PDF can only be read, slowly, by you.

For anyone with a chronic condition seeing multiple specialists, this is not a technical nicety. The fragmentation problem — six portals, none complete — is only fixable by aggregation, and you can only aggregate structure. We describe that lived reality in six specialists, six portals. And if you ever want your history to count in research, structured data is the difference between a contribution and a shoebox of paper.

The law that forced the doors open

The 21st Century Cures Act, signed in December 2016, did two load-bearing things. It made information blocking illegal — providers, EHR vendors, and health-information networks may not unreasonably interfere with the access, exchange, or use of electronic health information, including by the patient, with civil penalties for vendors and networks reaching a million dollars per violation. And its implementing rules required certified EHR systems to expose a standardized, patient-facing API built on FHIR R4, the requirement that took full effect at the end of 2022.

The plain-English consequence: if your providers run a certified EHR — and nearly all US hospitals and the large majority of office-based physicians do — there is a documented, standards-based interface to your data, and a legal regime that frowns on anyone who stands between you and it. This API right runs alongside, not instead of, your classic right to copies under HIPAA, which we cover in your right to a copy under HIPAA and GDPR.

Route one: your patient portal

Start with the portal you already have. Most major EHR portals now offer an export or "transmit to a third party" function for your structured record, alongside visit summaries. Portal exports vary in completeness and polish, but they are the zero-setup option, and for a one-time grab of your current chart they are often enough. Ask the practice which data the export includes — the certified baseline is the USCDI data set: problems, medications, allergies, labs, vitals, notes, and more.

Route two: a SMART on FHIR app

The more durable option is an app that speaks the API directly. The pattern is called SMART on FHIR — OAuth2 sign-in with your portal credentials, scoped permission, then an ongoing connection — and we explain its mechanics in SMART on FHIR: the app-store model for health records.

The best-known example is Apple's Health Records feature, which connects iPhones to hundreds of health systems and pulls allergies, conditions, immunizations, labs, medications, procedures, and vitals into on-device storage that syncs itself going forward. Equivalent apps exist on other platforms. The experience is what records access should have been all along: connect once, stay current.

One caution belongs in bold: once your data flows to a consumer app at your direction, HIPAA generally no longer covers it. The app is usually not a covered entity; its privacy policy is the governing document, backstopped by consumer-protection law. Read it. The doors the Cures Act opened are also doors — choose what you invite through them.

Route three: your insurer's Patient Access API

Providers hold clinical data; payers hold the claims story — every encounter, prescription fill, and procedure that generated a bill, across all your providers. CMS interoperability rules require Medicare Advantage, Medicaid, CHIP, and ACA-exchange plans to offer FHIR Patient Access APIs, and original Medicare offers claims through Blue Button 2.0. Claims data is coarser than clinical data, but it is often the most complete longitudinal index of your care that exists anywhere.

What you are actually downloading

The payload behind all of these is HL7 FHIR — the modern health-data standard, R4 being the version US regulation pins — shaped by US Core profiles that say which fields American systems must support. You do not need to read the spec to use your data, but knowing the names helps when an export looks thin: "does your API support the US Core profiles?" is a question that gets better answers than "where's the rest of my stuff?" The standard has its own story, told in what is FHIR?

Expect imperfection. Notes may be missing, older history may predate the structured era, and two providers may code the same condition differently. The honest pitch for FHIR access is not that it is flawless — it is that every flaw is visible, correctable, and one-time, whereas a PDF's flaws are forever.

From download to contribution

Here is why this matters beyond convenience. Research on chronic disease starves for exactly the data patients can now carry: longitudinal, multi-provider, real-world histories. A patient with a structured copy of ten years of care holds something no single institution can produce — an argument we make at length in your medical paper trail is a research asset.

Mithras Health is built on this plumbing. The platform — patient-mediated research data for chronic disease, currently pre-launch — uses FHIR R4 with US Core 6.1.0 as its system of record, which means the copy you download is the shape the platform speaks natively. Patients bring their records in under their own control, and each study sees data only through a revocable, scope-limited consent granted per study.

The deeper point is who the APIs were built for. A decade of interoperability policy has mostly moved data between institutions. The patient-facing FHIR API is the one interface where the patient is the integration point — the only party present at every encounter, with every provider, across every system. The law now hands you the cable. Plug it in.