From Vision to Implementation: Why Dr. Charles Kaplan's "UIID on SMART on FHIR" Describes Exactly the Bridge We Built

By LINKSPREED — the team behind UIID

When a Physician Describes the Architecture Better Than the Architects

It doesn’t happen often that you read an article and think: That’s exactly what we built this for.

Dr. Charles Kaplan — internist, infectious disease specialist, and health informaticist — accomplished something in his piece “UIID on SMART on FHIR” that we as a development team rarely manage: he explained the technology not from the perspective of cryptography, but from the perspective of the exam room. And in doing so, he landed precisely on the point where digital identity stops being an IT topic and starts being a clinical one.

At LINKSPREED, we developed UIID — Universal Internet Identity. Dr. Kaplan independently described what it can accomplish in healthcare. This article is our response: a complement, not a correction. Because there is very little in his analysis to correct.

Read the original first: UIID on SMART on FHIR by Charles Kaplan MD

The Central Insight: No Additional System Is Missing

The strongest sentence in Dr. Kaplan’s article is also the least spectacular:

“The missing piece is not necessarily another EHR or another health information exchange.”

This insight is so valuable precisely because it contradicts the industry’s dominant reflex. The usual answer to interoperability problems is: another platform, another exchange format, another central registry.

Dr. Kaplan argues differently — and from our perspective, correctly. The infrastructure already exists:

Building Block	Status	Function
EHR systems	Established	Store the clinical data
FHIR	Standardized	Defines Patient, Observation, Condition, MedicationRequest, Encounter
SMART / OAuth	Established	Authorizes applications
Patient portals	Widely adopted	Give patients access
Portable identity	⟵ the gap	Who is requesting? And were they authorized?

That last row is exactly why UIID exists. Dr. Kaplan frames it as two questions:

Who is requesting access?
Has the patient authorized that person to have it?

That is not a database question. It is an identity and delegation question. And it can be solved without rewriting a single FHIR endpoint.

What Dr. Kaplan Gets Right About UIID Aliases

We were particularly impressed by how precisely Dr. Kaplan captured the alias concept — a point that is frequently misunderstood in conversation.

He writes that a user can generate separate aliases for healthcare, banking, shopping, and other purposes without repeatedly exposing or correlating the root identity. Each alias is secured by a public/private key pair: the public portion allows verification, while the private key remains under the user’s control.

That is exactly the design principle. And Dr. Kaplan draws the decisive conclusion from it:

“This allows a person to prove, for example, that they control a particular healthcare identity without revealing the private key — or unnecessarily exposing their root UIID.”

Why this matters more in healthcare than anywhere else: a healthcare alias reveals nothing about the same person’s banking alias. Treatment relationships stay separate from every other area of life. Contextual separation here isn’t a convenience feature — it’s privacy at the core.

Equally important is his point about the confidentiality of the delegation list. Dr. Kaplan emphasizes that a patient’s relationships must not become visible through a publicly readable list — and that encrypting the delegated aliases within the healthcare alias object is precisely what ensures this. Who consults which physician is itself sensitive information. He saw that without anyone having to explain it to him.

And he draws the line exactly where it belongs:

“PHI itself remains secure inside existing EHR infrastructure, and placing actual health data into UIID identity formats would not be permitted.”

Identity is not the place for health data. UIID answers who may access — not what is stored. Naming that separation cleanly is a clarification we’re grateful for.

The Three Paths: An Analysis We’re Adopting

Dr. Kaplan’s comparison of authentication flows is so clearly structured that we deliberately reproduce it here in his own logic.

Path 1 — The Patient Portal

Patient requests portal access → backend prompts for username/password/MFA → backend verifies against stored encrypted password → JWT token or browser cookie issued → portal queries the PHI database → user interacts with the interface

His verdict: within one institution, this works well. He names two limits precisely:

The institution owns the patient’s portal identity
Delegation to a healthcare proxy is not supported

And then the sentence that captures the underlying problem:

“The patient may accumulate several portals and several institutional identities, even though every one of them represents the same human being.”

We spent a long time looking for a better formulation of the motivation behind UIID. This one is better.

Path 2 — SMART on FHIR

Launch third-party app → authentication handed off to the patient portal → username/password/MFA → SMART/OAuth token → FHIR API requests

Dr. Kaplan explicitly credits what SMART on FHIR solves: the third-party application never sees the password, because OAuth handles it. Genuine progress.

His three remaining limitations — stated soberly and without polemic:

The username/password/MFA step remains
Only one EHR can be reached at a time
Delegation to proxies is not supported

Path 3 — UIID on SMART on FHIR

UIID authentication → patient-controlled delegation verified → MFA → SMART/OAuth token → FHIR API requests

His core argument, which we consider the single most important strategic observation in the entire article:

“UIID allows us to change the first part of that architecture, while leaving much of the rest alone.”

Only the first step changes. The rest stays.

Concretely, as Dr. Kaplan describes it: the UIID healthcare alias functions much like a portal username and can be registered by the healthcare organization just like an email address. Instead of a password, the backend sends a fresh cryptographic challenge. Only a device holding the private key can sign it. MFA — FaceID, for example — authorizes use of the key and adds a second layer of identity verification. The backend verifies the signature and checks the requesting UIID against the encrypted proxy aliases stored in the account holder’s data field. If everything is valid, the flow from that point onward is exactly Path 2.

He also names the institutional benefits: no more storing encrypted passwords, therefore less attack surface, reduced liability exposure from breaches and identity theft, and lower maintenance overhead.

From an implementation standpoint, this is the decisive point. A proposal that required redefining FHIR resources or replacing OAuth would be practically unadoptable. A proposal that swaps out only the authentication step is adoptable.

Mary’s Case: 12 Hours, a QR Code, and an Overlooked Aorta

Dr. Kaplan’s clinical scenario deserves to be remembered.

The situation: Mary arrives at the Emergency Department by ambulance. Severe upper back pain, low blood pressure. No formal health records immediately available. The interview surfaces only one relevant history: a benign, asymptomatic lung nodule, monitored annually by CT.

The ED physician’s differential: coronary heart disease, pulmonary embolism, various infections, musculoskeletal injuries, spine and nerve conditions.

The UIID flow:

Mary unlocks her phone
She opens her UIID app
She scans the ED’s QR code
This generates a request for 12 hours of temporary access to all of her portals
She consents with a private consent password
FaceID reconfirms her identity

The finding: the ED pulls up her most recent CT report and images from her imaging portal. The lung nodule is stable and benign. But the report contains an incidental finding: an irregularity in the wall of her aorta.

The consequence: the team now considers aortic dissection — rare, but life-threatening. The diagnostic workup is reprioritized accordingly. In time.

What makes this story so effective: the decisive information was an incidental finding. Nothing anyone would have specifically searched for. Nothing Mary could have mentioned — she didn’t know about it. It sat in a report that nobody in the room had.

That is the difference between “the data exists” and “the data is in the right place at the right time.” Dr. Kaplan made that gap more visible in a single case than any architecture diagram could.

What Dr. Kaplan Says About Delegation — and Why It’s the Core

His delegation section describes the use case that occupied us most during design. He names four situations:

A spouse should have access to advance directives
A primary care physician should have continuing access to a specialist record
A cardiologist should be able to review prior electrocardiograms
An ED physician should get temporary access to multiple sources during an emergency

And he describes delegation the way a patient actually thinks about it:

“My primary care physician is authorized. My cardiologist is authorized. My spouse is my healthcare proxy.”

Plus the time boundaries: cardiologist six months, ED physician 24 hours, spouse with a distinct scope under an advance directive.

Then comes the sentence that answers the governance question:

“Adding an authorized alias to a UIID creates the delegation; removing it revokes the delegation.”

Delegation is a state change in the patient’s alias object — not a ticket, not a workflow, not an approval process. Dr. Kaplan states it plainly: the patient should not have to wait for a hospital, an EHR vendor, or an IDaaS provider to approve every change. It is effective instantly and secured cryptographically — at any time, in any place.

And he adds the necessary realism: all of it within appropriate healthcare, security, and legal policies. That framing — patient control within a regulatory framework, not alongside it — is why his proposal stays implementable.

Our Addition: Healthcare Is a Use Case, Not the Use Case

Dr. Kaplan deliberately stays within the clinical context — and that is the strength of his article. We’d like to complement his analysis with a perspective that adds nothing to it, but extends it.

The questions he raises — Who is asking? Was this person authorized? For how long? Can the individual revoke it at any time? — are not confined to healthcare.

They arise with power-of-attorney access to bank accounts. With legal guardianship. With government processes conducted on someone else’s behalf. With managing digital services for family members. Anywhere one person may act for another — in a bounded, verifiable, revocable way.

Dr. Kaplan chose the use case where the consequences are most immediate. Mary’s aorta doesn’t wait for an approval process. But the underlying pattern is universal — and that is precisely why it’s called Universal Internet Identity.

His article shows what the layer accomplishes in healthcare. Our work is to make that same layer available everywhere the same questions are asked.

Why This Perspective Matters

We build infrastructure. Dr. Kaplan treats patients and works on EMR interoperability. His own description sums up what’s at stake:

“EMR Interoperability is a Public Health Problem and can be solved”

The two belong together. Technology that people in the field don’t recognize as an answer to a real problem remains a demo. Dr. Kaplan’s article is the proof that someone who knows both worlds — medicine and informatics — not only understands what UIID does technically, but can translate it into an emergency department where every minute counts.

His conclusion stands on its own:

“Most important of all, it can provide for a better user experience for both patients and caregivers, and can improve health outcomes.”

We have nothing to add to that.

Credits & Attribution

This article is based entirely on the analysis, architectural paths, and clinical scenario from:

“UIID on SMART on FHIR” by Charles Kaplan MD — Internal Medicine, Infectious Diseases, Health Informatics 👉 https://medium.com/@squidroe58585/uiid-on-smart-on-fhir-9343d9b6e2a0

All quotations, the three-path framework, the delegation model, and the “Mary” case originate from his article. We thank Dr. Kaplan explicitly for a presentation that is clearer than much of what we’ve formulated ourselves — and for the time and care he invested in an independent analysis.

LINKSPREED is the team behind UIID (Universal Internet Identity), an implementation of the W3C standard for Decentralized Identifiers (DIDs).