SMART on FHIR: the app-store model for health records

In 2009, two Boston physician-informaticians, Kenneth Mandl and Isaac Kohane, published a pointed idea in the New England Journal of Medicine: health IT should work like a smartphone — a stable platform underneath, substitutable apps on top, and the freedom to delete an app that disappoints you. At the time, an electronic health record was a sealed appliance. Every new feature was a negotiation with the vendor; every integration was a bespoke engineering project, priced accordingly.

The idea grew into SMART — Substitutable Medical Applications, Reusable Technologies — a project at Boston Children's Hospital and Harvard Medical School, seeded with federal innovation funding. When the FHIR standard matured, SMART rebased onto it, and SMART on FHIR became what it is today: the app-store model for health records, and an HL7 standard in its own right.

What SMART on FHIR actually is

SMART on FHIR is an open standard that combines OAuth 2.0 authorization with the FHIR data API, so a single app can run against any compliant health-record system without custom integration.

The two halves do different work. FHIR gives health data a common, machine-readable shape — the standard we unpack in what is FHIR. OAuth 2.0, the same authorization machinery behind the "sign in with" buttons all over the consumer web, handles who may see that data and for how long. SMART's contribution is the binding between them: how an app announces itself to a health system, how it asks for access, and what each permission means precisely enough that an app written once runs at hospital A and clinic B alike. Substitutable, as promised.

How an app actually connects

A SMART app never receives a database password. It receives a token, scoped to exactly what was approved and nothing more.

The handshake is deliberately boring. The app sends you to the health system's own login page — your credentials never pass through the app. After you sign in, an authorization screen lists what the app is requesting. Approve it, and the app receives a short-lived access token that works only for the granted permissions, only for the granted record. There are two launch modes: an EHR launch, where a clinician opens the app inside the record system mid-visit, and a standalone launch, where a patient at home connects an app to the portal account they already have. The official SMART App Launch specification at HL7 defines both flows in full.

Scopes are the permission slips

A scope is a one-line sentence describing access, and the entire privacy posture of a SMART app is the list of sentences it asks you to approve.

Reading scopes is a learnable habit, and a revealing one. A sleep-tracking app that requests patient/*.read is asking the wrong question, and an authorization screen that displays the request honestly gives you a fair chance to say no. The principle underneath is minimum necessary access: ask for what the job needs, nothing else. Most software never has to state its appetite this plainly; SMART forces the statement onto one screen.

From experiment to federal plumbing

SMART stopped being optional in the United States when patient-access regulation made it certification plumbing.

Under the certification rules adopted pursuant to the 21st Century Cures Act, certified EHRs must expose a standardized FHIR R4 patient-access API — and the access framework the criteria point to is SMART App Launch. In practice, most Americans with a patient portal can already connect a standalone SMART app to their own record; Apple's Health Records feature, which pulls hospital data onto an iPhone, is the best-known SMART client in the world. The practical steps are covered in how to download your own health data as FHIR, and the shape of the data those APIs serve is set by the profiles we describe in FHIR R4 and US Core, explained.

Where HIPAA stops following

The moment your records flow into an app you chose, HIPAA usually stops traveling with them.

HIPAA binds covered entities — providers, health plans, clearinghouses — and the business associates working on their behalf. A consumer app acting on your own instruction is generally none of those things. Once your data lands in it, the app's privacy policy and general consumer-protection law are most of what protects you, with newer state laws such as Washington's My Health My Data Act reaching further. None of this is a reason to avoid SMART apps — the same is true of mailing yourself a paper copy. It is a reason to read the scope list and the privacy policy as one document: what does it take, what does it keep, whom does it tell.

The lesson scoped access teaches research

The deepest idea in SMART is not technical. It is that access should be narrow, inspectable, and revocable — and that the person whose record it is should hold the switch.

That is the grammar research consent ought to follow, and mostly does not. A typical research release is broad, hard to inspect, and effectively permanent. A SMART authorization is the opposite: a named app, an explicit scope, a screen you actually saw, a connection you can sever from your portal settings tomorrow.

Mithras Health applies that grammar to research participation. Each study a patient joins receives its own scope-limited, revocable consent — this study, these data elements, this purpose, until revoked — granted as one decision over two documents, a plain-language summary and a formal authorization, and enforced by the platform rather than promised by policy. The records underneath are kept as FHIR R4 with US Core 6.1.0 profiles, so what a study is permitted to see has the same well-defined shape a SMART app would see: scoped, structured, auditable.

"Substitutable" was always the radical word in the acronym. An app you can replace is an app that must keep earning its place — and a study you can disconnect from carries the same obligation. The app-store model's real export to medicine is not convenience. It is the switch.