# SMART Health Check-in > SMART Health Check-in is a draft open standard for pre-visit check-in: a clinic's page asks for what the visit needs, and the patient answers from a health app of their own choice that already has their records and can help with the clinic's questions. The patient decides item by item what to share, and the answer comes back to the clinic's page as FHIR data. The site has four sections, each with its own llms.txt: this one (the home page and the shared background), the spec, the developer docs and demos, and the connectathon. This file is the shared background (https://smart-health-checkin.org/llms-background.md) followed by the full text of the 2 pages of this section (SMART Health Check-in), converted to Markdown. The other sections' llms.txt files are listed under "The site" in the background. --- # SMART Health Check-in: background Shared background for every section of smart-health-checkin.org, for an AI model helping someone understand SMART Health Check-in or build with it. Where this page and the specification differ, the specification is right. ## What it is Before a visit, clinics ask patients for the same information again and again: allergies, medications, insurance, intake questionnaires. SMART Health Check-in lets the patient answer from a health app of their own choice: an app that already holds their records, collected from their doctors' and hospitals' patient portals, and that can help them answer the clinic's other questions. The clinic's page asks for what the visit needs, the patient decides item by item what to share, and the answer comes back to that page as FHIR data. The phone or browser finds the patient's installed app, so the clinic's page doesn't need to know which one they use. ## Roles - **Verifier:** the software that asks, then checks the response against its request before using it: an EHR's check-in page, a patient portal, a front-desk kiosk, or a clinic's native app. - **Wallet:** the patient's health app, native on the phone or a web wallet (a website that opens in a browser tab). It shows the request to the patient and builds, signs, and encrypts the response. - **Holder:** the patient, or a person acting for them, who decides what to share. ## How a check-in works 1. The Verifier builds a request: an `id`, an optional `purpose`, and `items`. Each item has an `id`, a `title` shown to the patient, a selector in `content`, and the media types the Verifier can read in `accept`. `required` is advice, never consent. 2. A `selection.fhir` selector asks for existing FHIR resources by profile, profile family, or resource type. A `form.fhir` selector asks the patient to fill in a FHIR Questionnaire. 3. The Wallet shows each item and who is asking (the calling page's origin, from the browser). 4. The response has `artifacts`, the shared content, each listing the items it answers in `fulfills`, and `requestStatus`, exactly one status per item. Artifacts are `application/fhir+json` (a resource, a Bundle, or a `QuestionnaireResponse`) or `application/smart-health-card`. One Artifact can answer several items, and one item can have several Artifacts. 5. Each status is `fulfilled`, `partial`, `unavailable`, `declined`, `unsupported`, or `error`. A declined item tells staff what is left to ask at the desk. 6. The Verifier decrypts the response and checks it against the request. Only a malformed response or a wrong `requestId` rejects all of it; other problems affect one item or Artifact. ## Transports The request and response are the same whichever way they travel. - **Digital Credentials API, for native wallets.** The Verifier calls `navigator.credentials.get` with protocol `org-iso-mdoc`. The response is one mdoc element holding the whole response JSON, signed by the Wallet and encrypted with HPKE to a one-time key the Verifier made for this request and bound to the calling origin, so only that page can read it. Android wallets register with Credential Manager; on iOS 26 a wallet answers Safari through an Identity Document Provider extension. On a computer, the browser shows a QR code and the patient answers on their phone. - **Web wallets, in a browser tab.** The Verifier opens the wallet in a new tab; the wallet posts `ready`, the Verifier posts the same request it would give the API, and the wallet posts back the same encrypted response. The wallet takes the Verifier's origin from the browser, never from the message. Nothing to install. - **Kiosk and cross-device.** A kiosk has no wallet. It builds the request, keeps the private key, and shows a QR code; the patient's phone opens a hand-off page that asks the phone's wallet or a web wallet, and the sealed answer returns through a relay that can't read it. Hand-offs are outside the spec; the client library implements one. ## Status SMART Health Check-in 1.0 is an editor's draft for implementer review. The project publishes reference implementations, conformance tests, and test apps: a demo web wallet, the SMART Testing Wallet, the SMART Testing EHR, and a reference Android wallet. No health app that patients use today supports it yet. A connectathon is planned; its date isn't set. ## The site Each section has one llms.txt: this background, then the full text of the section's pages. - **Home** (https://smart-health-checkin.org/): the home page, this background, and the shared look. https://smart-health-checkin.org/llms.txt - **Spec** (/spec/): the draft specification, its explainers, and a capture inspector. https://smart-health-checkin.org/spec/llms.txt - **Developers and Demos** (/client/, /client/demo/): the JavaScript library's guides, API reference, and live demos. https://smart-health-checkin.org/client/llms.txt - **Connectathon** (/connectathon/): pages for each kind of participant, test scenarios, the Testing EHR and Testing Wallet, and prompts for writing an experience report with an AI assistant. https://smart-health-checkin.org/connectathon/llms.txt ## Repositories and releases All at https://github.com/smart-health-checkin. - **spec:** the specification, explainers, fixtures, and conformance cases, tagged `vX.Y.Z`. - **client:** the JavaScript and TypeScript library `@smart-health-checkin/client`: `runCheckin`, the `` element, and a React component for Verifiers, plus modules for web wallets, the kiosk hand-off, FHIR, testing, and the wire format. Install it from a GitHub release's tarball (it isn't on the npm registry) or load hosted ES modules; the Install page at /client/docs/install.html has the current install line, the entry points, and the hosted files. - **android-wallet:** the reference Android wallet and an example native Verifier app, which checks in through Credential Manager directly or through the browser in a Custom Tab. Each release carries both APKs. - **swift:** a Swift package with the Verifier and Wallet roles, installed with Swift Package Manager from tags. There is no reference iOS wallet app yet. - **connectathon** and **smart-health-checkin.github.io:** the connectathon site, and the home page with the shared look and this background. ## Terms - **Item:** one entry in a request's `items`: one decision for the patient, one entry in `requestStatus`. Its `content` is the **selector**. - **Artifact:** one piece of shared content in a response's `artifacts`. - **Origin:** the calling page's origin as the browser reports it, or for a native app the string its platform reports. The response is bound to it. - **mdoc:** the ISO/IEC 18013-5 format built for mobile driver's licenses, used here as an envelope. The Wallet signs its own mdoc, so the signatures show the bytes are intact, not who issued the content; that evidence is inside Artifacts, such as a SMART Health Card's signature. - **Reader authentication:** an optional signature by the Verifier over its request. - **Wallet registry:** a `wallets.json` file listing the web wallets a Verifier's page offers. - **FHIR:** HL7's standard format for health data. - **SMART Health Card:** FHIR data, such as an immunization record, signed by the organization that issued it. --- # SMART Health Check-in Source: https://smart-health-checkin.org/ Open standard · draft 1.0 Before a visit, patients are often asked to write out their allergies, medications and insurance details again, on a clipboard or a web form. SMART Health Check-in lets the patient answer from a health app of their own choosing instead: an app that already has their records, and that can help them answer the clinic's other questions too. The patient decides what to share, and the clinic's page receives it directly from the app. It is a draft open standard. A health app installed on the phone is reached through the W3C Digital Credentials API, the browser feature that is also used for digital driver's licenses; a health app that runs as a website works in any browser. This project publishes reference code and test apps, but no health app that patients use today supports it yet. ## How it works Diagram: How check-in works, in three steps. A clinic's check-in page asks for three things: allergies, an insurance card, and two questions about mood. In a health app of their choice, the patient shares the allergies from their records, answers the mood questions in the app, and decides not to send the insurance card. The page gets back a sealed answer: the allergy list and the patient's answers received, and the insurance card marked declined, with nothing sent. The patient's health app, called a wallet in the specification, is an app that already holds their health information: records it has collected from their doctors' and hospitals' patient portals, and cards such as an insurance card. It can also show the clinic's questionnaires and help the patient answer them. It can be an app on their phone or a website that opens in a browser tab. The clinic's page doesn't need to know which one the patient uses; the phone or browser lets the patient pick, and tells the app which website is asking. The app shows the patient each item the clinic asked for. Nothing is sent until they approve, and they can share some items and decline others. The clinic learns which items were declined, so staff know what is still left to ask at the front desk. For each request the clinic's page creates a one-time key, and the app encrypts its answer to that key, so only that page can read it. The records arrive in FHIR, the standard format for health data that clinic record systems already use. The [Request and response explainer](https://smart-health-checkin.org/spec/request-response.html) shows the data sent at each step. ## Try it The demos check in a made-up patient at a pretend clinic. The patient's side is one of this project's test apps: a demo web wallet, the [SMART Testing Wallet](https://smart-health-checkin.org/connectathon/testing-wallet/), or the [reference Android wallet](https://github.com/smart-health-checkin/android-wallet/releases/latest). Online ### [Check in from a phone](https://smart-health-checkin.org/client/demo/#wallet=platform) The clinic's page asks the wallet apps installed on your phone, so you need a test wallet such as the reference Android wallet. On a computer, the browser shows a QR code so you can finish on your phone. Try it → In person ### [Check in at a kiosk](https://smart-health-checkin.org/client/demo/kiosk.html) For a shared screen at the front desk, which has no wallet of its own. You scan its QR code, approve on your phone, and the answer goes back to the screen. Try it → Any browser ### [Check in with a web wallet](https://smart-health-checkin.org/client/demo/) Nothing to install. A demo wallet opens in a new tab, shows you what the clinic asked for, and sends back what you approve. Try it → ## Next steps - ### [Build a check-in page](https://smart-health-checkin.org/client/docs/tutorial.html) For developers of clinic websites, patient portals and electronic health record systems. A tutorial that builds a working check-in page with this project's JavaScript library. - ### [Build a wallet](https://smart-health-checkin.org/client/docs/build-a-wallet.html) For developers of patient health apps. How a wallet receives a clinic's request, shows it to the patient, and sends back the answer. For a wallet that runs in a browser tab: [Web wallets](https://smart-health-checkin.org/client/docs/web-wallets.html) - ### [Read the spec](https://smart-health-checkin.org/spec/request-response.html) For implementers and anyone reviewing the standard. The Request and response explainer walks through the data of one check-in. The specification itself: [SMART Health Check-in 1.0](https://smart-health-checkin.org/spec/) **Connectathon:** an online testing event where developers connect their software and patients and clinic staff try it. Date to be announced. [Join us](https://smart-health-checkin.org/connectathon/). --- # Pre-Visit Check-in: Closing the Loop Source: https://smart-health-checkin.org/ktc/closing-the-loop/ CMS Health Tech EcosystemKill the Clipboard · August 2026 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 advance with → or space 02Where this came from ## An update from the breakout 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: ### Lay out the problem Describe it in terms everyone on this call can evaluate, without breakout shorthand. ### Walk through the two models What the proposals share, where they differ, and what each one asks builders to build. ### Preview the fall demos Working, multi-vendor demonstrations are within reach this fall, without waiting on anyone who isn't ready. 03The problem ## Practices say what data they expect, and when. Apps help patients select and share. Maria books a Thursday appointment. Her practice needs different things from her at different moments, not one blob of data on arrival: At booking - Insurance card - Medication list - History, allergies - Reason for visit Day before - PHQ-2 depression screen - Anything changed since booking? Answers stay fresh, and a positive screen doesn't sit unread for a week. At arrival - Copay - Consents - "You're checked in." 04Common ground ## Points of consensus - PROVIDER-TIMING**Providers communicate a structured request.**It names the items wanted (questionnaires, coverage, history) and when each is wanted: at booking, the day before, or at the desk. - PATIENT-CHOICE**Patients share only the items they choose.**Consent is per item, not an all-or-nothing grant. - WORKS-WITHOUT-APP**It must work with no app at all.**Roughly half of patients do any online check-in today, and connected-app adoption will start small, so portal and front-desk flows remain the baseline. - BETTER-WITH-APP**Patient apps improve the experience without gating it.**An app should upgrade check-in for patients who have one without blocking patients who don't. 05The design space ## The models differ on where the response goes 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. ### Entry: shared by both models Each of these lands the patient in the same check-in flow. portal messageemail / SMS linkQR at the deskapp discovers appointment ### Response: where they split 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. Diagram: Four entry points, portal message, email link, QR code, and app discovery, all converge on one check-in flow; the models differ on what happens after the patient answers. Entry points all funnel into the same flow; the models differ on what happens after the patient answers. 06Walkthrough ## The Autofill model 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. Diagram: The provider's check-in page sends a request to the patient's chosen app; the signed response returns to the same page, which then continues to copay, consents, and done. Request out, response back, workflow continues: no accounts created, no app pre-registered. ### Backend integration: out of scope 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. ### The mdoc transport 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. Large responses and consent UX still need real testing. 07Walkthrough ## The API Submission model 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. Diagram: The patient's app pushes data toward the EHR, either directly or through CMS-aligned networks; each app joins and gets credentialed per network, the network-to-EHR write path is not defined today, and the provider's check-in page never hears back. Networks in the middle split pairwise setup into two halves, app-to-network and network-to-EHR. Both still have to exist; the write path is undefined. ### What has to be specified before this works - Which endpoint receives the write: the EHR, or a network? Which one? - How does each app get a client registration there, at scale? - What does the patient's authorization step look like? - How does the provider learn the data arrived and match it to the visit? - How does the patient get back to copay and consents? 08Side by side ## Scoring the two models 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 | 09What's next ## Demos by Thanksgiving ### This fall · volunteers 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. ### As EHR and provider systems come aboard First-party portal integration, testing against real sandboxes, and a Connectathon with the full membership. Josh's take 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. 10Discussion ## How can I help? - **Building a patient app?**The fall demos need wallets. The request/response model is small, the SDK does the heavy lifting, and partial implementations are welcome. - **Running an EHR or provider system?**Watch the fall demos, point us at your sandbox when you're ready, and tell us now how the receiving page should land results in your backend. - **Everyone:**What's missing from the common ground or the scorecard? If there's a requirement this framing doesn't capture, this call is the place to say it. [demo](https://smart-health-checkin.org/client/demo/) [SMART Health Check-in 1.0](https://smart-health-checkin.org/spec/) [spec (markdown)](https://smart-health-checkin.org/spec/spec.md) Pre-visit check-in breakout · reach out in the KTC Slack channel to join **Josh Mandel** · SMART Health IT A1Appendix · the trust question ## Trust attaches to the data, not the app "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: ### Signed artifacts stay signed A SMART Health Card carries its issuer's signature no matter which app presents it. The receiving system verifies the signature, not the messenger. ### Patient answers are patient answers Unsigned responses are the patient's own statements, exactly as trustworthy as their handwriting on the clipboard was. Nobody ever vetted the pen. ### Nothing to revoke 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. A2Appendix · where the work stands ## The ingestion half is already built 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. ### What the QR work taught us 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. ### Draft spec: SMART Health Check-in 1.0 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. ### Running code 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. [live demo](https://smart-health-checkin.org/client/demo/) [SMART Health Check-in 1.0](https://smart-health-checkin.org/spec/) [Request and response](https://smart-health-checkin.org/spec/request-response.html)