How a provider asks, how a patient answers, and how the visit moves on.
Update from the pre-visit check-in breakout
Josh Mandel · SMART Health IT
We ran three breakout calls on pre-visit check-in design, covering workflow, timing, and candidate protocols. Two proposals are on the table. Today is an update, not a decision ask:
Describe it in terms everyone on this call can evaluate, without breakout shorthand.
What the proposals share, where they differ, and what each one asks builders to build.
Working, multi-vendor demonstrations are within reach this fall, without waiting on anyone who isn't ready.
Maria books a Thursday appointment. Her practice needs different things from her at different moments, not one blob of data on arrival:
Answers stay fresh, and a positive screen doesn't sit unread for a week.
A portal prompt, a texted link, a kiosk QR code, or an app that notices the appointment: any of these can start the flow, under either model. The choice worth making carefully is what happens when the patient answers.
Each of these lands the patient in the same check-in flow.
The Autofill model returns the response to the page that asked, and the visit continues there. The API Submission model has the app write to a server, and the exchange ends in the app.
The provider's check-in page issues the request through the browser, the same credential surface phones already use to present a driver's license. The patient approves item by item in an app they choose, and the answer returns to the page, which continues to copay and consents. A kiosk QR or texted link lands walk-ins in the same exchange, so pre-visit and on-site check-in share one protocol.
Deliberately: the receiving page forwards results into whatever the practice already has. FHIR-ready systems POST FHIR; others use their existing intake pipeline. Start now, build toward FHIR everywhere instead of blocking on it.
Rides the W3C Digital Credentials API over ISO mdoc: rails that ship on iOS and Android today, maintained by platform vendors for licenses and IDs (and drawing EHR interest beyond check-in). The machinery is heavier than plain JSON; a shared browser SDK handles it. Size limits and consent UX still need real testing.
The patient's app writes the data to a server: the EHR's FHIR endpoint, or one of the CMS-aligned networks in between, using a registered client identity and an explicit authorization step. One backend serving many use cases is the appeal; the exchange ends in the app.
Requirements from the common ground, plus the practical questions raised in the walkthroughs.
| Requirement | Autofill | API Submission |
|---|---|---|
| FINISHPatient finishes check-in in the provider's flow | Yes: the response returns to the page mid-flow | Needs added return machinery to be designed |
| PATIENT-CHOICEPatients share only the items they choose | Yes: per-item consent in the credential picker | Yes: per-item choice in the app |
| WORKS-WITHOUT-APPWorks for patients with no app | Yes: the portal form works on its own, and can optionally offer an app link-out | Yes: portal fallback |
| ANY-APPAny app the patient chooses can answer | Yes: no enrollment, no credentials issued to the app | Each app registers and is vetted with each network or write endpoint |
| ON-SITESame protocol at the front desk | Yes: a kiosk QR or texted link lands in the same flow | Would need its own walk-in design |
| BACKENDWhat EHR and provider systems must build first | Nothing standardized: each EHR manages its own backend design (FHIR included) | Write API, client registration, and authorization at every system, or a new network write path |
| DEMOEnd-to-end demo by Thanksgiving | Yes, with volunteer wallets and one or more EHRs | Writes to a test endpoint, without integration into a provider check-in flow |
| TRUSTWhere trust lives | In the existing patient session + optionally signed artifacts + patient attestation | In API and identity credentials held by each app |
A reference check-in surface backed by one or more EHRs, answered by wallets from the patient apps and platform vendors ready to move now. The reference surface forwards results into its backend, showing the backend-integration pattern live.
Nothing blocks on EHR or provider systems; they can join at whatever depth suits their timelines, or just watch.
First-party portal integration, testing against real sandboxes, and a Connectathon with the full membership.
We should put our energy into the Autofill wire protocol, with app-discovered entry and per-system backend integration documented as patterns on top. I'm aiming to have running demos to react to by Thanksgiving.
Pre-visit check-in breakout · reach out in the KTC Slack channel to join
Josh Mandel · SMART Health IT
"Shouldn't the app be vetted?" is the natural question about the Autofill model, where any app can answer. The answer is that the app is a carrier, and the things worth trusting travel with the data:
A SMART Health Card carries its issuer's signature no matter which app presents it. The receiving system verifies the signature, not the messenger.
Unsigned responses are the patient's own statements, exactly as trustworthy as their handwriting on the clipboard was. Nobody ever vetted the pen.
The app never receives backend credentials, so there is no standing access to vet, monitor, or revoke. App listings and identity assurance solve account access, which is a different problem.
The API Submission model needs app vetting because it hands apps API credentials. That's a requirement the model creates, not one the use case has.
EHRs that support the Kill the Clipboard QR-code flow already verify and ingest SMART Health Cards. The Autofill response carries those same artifacts, so it lands in the pipeline those systems already run. This is a new front door on existing plumbing, not a new stack.
Front-desk scanning never took hold, because site-by-site hardware and workflow change doesn't happen. The verification and ingestion backends shipped anyway, and they carry over unchanged.
A normative, transport-neutral clinical request/response model, plus a same-device binding over the W3C Digital Credentials API (ISO mdoc). FHIR-native selectors, inline questionnaires, per-item status, SMART Health Card and raw FHIR artifacts.
Android wallet, browser verifier SDK, live web demo, and a kiosk handoff demo, all validated against real captured byte fixtures by test suites in three languages.