Anyone who has seen a new doctor knows the drill. You get a clipboard, write your medication list from memory, and sign forms asking for details you gave last year. Later, someone at the front desk types it all back in.
That ritual is now a federal target. Under its "Kill the Clipboard" push, the Centers for Medicare & Medicaid Services (CMS) wants patients to show a QR code on their phone instead, with their records landing straight in the clinic's system. For developers, the interesting part is what sits behind that code: a SMART Health Link, an encrypted, expiring pointer to a FHIR bundle that carries its own decryption key. So let's take one apart.
Why the clipboard became a federal project
The effort began in July 2025, when CMS launched its Health Tech Ecosystem and asked health tech companies and EHR vendors to sign a pledge. More than 700 organizations have signed since. Then, on April 9, 2026, the agency held a "first wave" launch featuring tools from over 50 companies, plus a new Medicare App Library for vetted patient apps.
Look at the fine print, and the architecture becomes clear. Clinics are asked to accept a patient's verified identity and health history through a QR code, SMART Health Card or SMART Health Link. Apps seeking a library listing also need FHIR R4, SMART on FHIR authorization, a CMS Aligned Network connection, and identity verification through ID.me or CLEAR. In short, the patient's app does the heavy lifting, and the QR code is just the handoff.
What's inside a SMART Health Link
Point a generic QR reader at one of these codes and you'll see shlink:/ followed by a long run of base64url text. Decode that text, and you get a small JSON object:
{
"url": "https://shl.example.com/files/_KWT4w-FCc8K7aG9yTB7W2quku_zLixWZfciwfQURAk",
"key": "Z7oi6XIuOVp8itc9AsebPDJYmheayD2GZB9sdHSlQ0E",
"exp": 1793978100,
"flag": "U",
"label": "Maria's records for today's visit"
}Field by field, it's fairly simple. The url is where the encrypted data lives, and it must contain at least 256 bits of randomness, so nobody can guess it. The key is 32 random bytes, and it's the only way to decrypt what the url returns. As for exp, that's when the link dies (the placeholder above has already expired, so generate a fresh one if you test), while the label is a note for humans.
Next, the flag field sets the behavior. P requires a passcode, L marks a long-lived link, and U means the url points straight at one encrypted file. Without U, the receiver first POSTs to the url for a manifest listing the files.
Now for the neat trick: where the key lives. Because it travels inside the link, the hosting server never sees it, and the files themselves are JWE objects encrypted with AES-256-GCM. A breached host therefore leaks only ciphertext. Even when the link is shared as a web URL, the payload sits after the #, which browsers never send to servers, so it stays out of logs too.
For check-in specifically, a draft profile on GitHub called the KTC spec narrows things further. Patient apps must use the U flag and set an expiry, and the clinic's system must add a recipient parameter so the patient's app can log who opened the link. The draft even suggests lifetimes: 5 to 15 minutes for a code on a phone, a day or two for a printed one.
Decoding a link in a few lines of JavaScript
Since it's all built from standard parts, a working receiver is surprisingly short. Here's a minimal version for Node 18+, using the jose library:
import { compactDecrypt } from "jose";
import { inflateRawSync } from "node:zlib";
export async function openShlink(scanned, recipient) {
// Handles bare "shlink:/..." codes and "https://viewer/#shlink:/..." URLs
const i = scanned.indexOf("shlink:/");
if (i === -1) throw new Error("Not a SMART Health Link");
const link = JSON.parse(Buffer.from(scanned.slice(i + 8), "base64url").toString());
if (link.exp && link.exp * 1000 < Date.now()) {
throw new Error("Link expired. Ask the patient for a fresh code.");
}
if (!link.flag?.includes("U")) {
throw new Error("Manifest-based links need the POST flow instead.");
}
const url = new URL(link.url);
url.searchParams.set("recipient", recipient);
const res = await fetch(url, { signal: AbortSignal.timeout(5000) });
if (!res.ok) throw new Error(`Fetch failed: ${res.status}`);
const key = Buffer.from(link.key, "base64url");
const { plaintext, protectedHeader } = await compactDecrypt((await res.text()).trim(), key);
const bytes = protectedHeader.zip === "DEF" ? inflateRawSync(plaintext) : plaintext;
return JSON.parse(new TextDecoder().decode(bytes)); // a FHIR Bundle
}That's still a starting point, and production code needs more care. The KTC draft warns that several popular JOSE libraries have dropped support for compressed JWE payloads, and compression tripped up receivers in field testing. When I tested this, jose decrypted a "zip": "DEF" payload without complaint but returned the compressed bytes, so the code above inflates them itself. Otherwise, the base HL7 SMART Health Links specification covers the manifest flow, and the KTC project publishes test vectors you can run in CI.
What the receiving end has to get right
Honestly, decryption is the easy part. Everything after it is about trust and workflow.
To begin with, that url came from a stranger's phone. The KTC draft therefore recommends fetching it through an isolated service: HTTPS only, no private or loopback addresses, redirects re-checked, short timeouts, and no access to internal systems. If that reads like a textbook SSRF checklist, it is one.
Once decrypted, the bundle is a FHIR collection holding a Patient resource plus shared content, which can include discrete resources and two kinds of PDF: a readable rendering of the data and a patient-written note. At minimum, the clinic's EHR must store problems, medications, allergies, immunizations and those PDFs, attach them to the right chart, and flag them as patient-supplied.
Then there's the question of where the scan happens. A hospital can mount scanners at registration. In a small practice, though, the obvious spot is a front-desk tablet or a medical check-in kiosk that already captures IDs, insurance cards and intake forms. There, a QR code would be one more input on a screen patients already use.
Where it still gets messy
Even so, several problems sit outside the spec, which is why the clipboard won't vanish next month.
Identity comes first. The patient's app has verified who the patient is, but the clinic still has to match the incoming Patient resource to the right chart, and demographic matching has never been healthcare's strong suit. That's why the draft wants staff to check the bundle's demographics before anything gets filed.
Trust, however, is trickier. Patients can edit data before sharing it, so the draft defines an optional App Attestation, a signed JWT confirming that a recognized app helped build the bundle. To its credit, the draft calls this a provenance signal rather than a content signature. I think that's the honest choice, since signing patient-editable data would promise integrity nobody can deliver.
Volume, on the other hand, is the part clinicians will feel. A bundle pulled from several networks can carry years of history, and someone has to review it before it lands in the chart. That's where AI should earn its keep. Some practice platforms already offer AI tools that turn charts, faxes and lab results into short summaries, and a patient-shared bundle is an obvious next input, provided a human still signs off.
Last but not the least, there's the human side. In May, Deven McGraw of Citizen Health told TechTarget that clinics would need new front-desk devices and new places in the EHR for what patients bring. My bet is that the front desk, not the crypto, decides how fast this spreads.
Why it's worth building against now
Still, if you write software that touches patient data, this is one of the rare health-IT standards you can prototype over a weekend. The payload is plain JSON and the crypto is standard JOSE. Better yet, the hard parts, like fetching untrusted URLs safely or matching records, are problems web developers already deal with.
Of course, mobile boarding passes took years to go from novelty to default, and the clipboard will probably fade on a similar curve. The plumbing works today, though. And the first time a patient checks in with a scan instead of a pen, nobody at the front desk will miss the clipboard.
