Verifier developers

For teams building the clinic side (EHRs, portals, and other Verifiers): the check-in page, portal, kiosk, or app that asks a patient's wallet for data.

Background

In the spec's terms you build a Verifier. Your page sends a request listing the items you'd like, and the patient's wallet answers with the records and form answers the patient chose to share, plus a status for every item. The wallet can be an app on the phone, reached through the browser's Digital Credentials API, or a website opened in a tab (a web wallet).

The answer comes back encrypted to a key your page made for that request, and bound to your page's origin. You check it against your request, then show it to staff. Each item and record is judged on its own, so one bad record doesn't lose the rest.

Get started

1. Learn the model. Request and response walks through what a clinic asks for and what comes back, in about ten minutes.
2. Build your page. The client library's Tutorial builds a working check-in page end to end. Try the clinic check-in demo to see the result.
3. Test against known-good wallets. Point your page at the event's wallet registry and check in with the SMART Testing Wallet. To test your error handling, open the Testing Wallet, set faults or a response size in its testing panel, choose "Copy wallet URL for these settings", and add that URL as a web wallet on your page. Then run check-ins from your page as usual; each one gets those options. For example, bad signature is https://smart-health-checkin.org/connectathon/testing-wallet/eyJmYXVsdHMiOlsiYmFkLXNpZ25hdHVyZSJdfQ/ and a 5 MB response is https://smart-health-checkin.org/connectathon/testing-wallet/eyJzaXplIjoiNW0ifQ/. These config URLs are the Testing Wallet's own format, not part of SMART Health Check-in, and the list of faults says how your page should react to each.
4. Building a native app instead of a web page? The Native Verifier apps guide shows both ways: calling phone wallets directly, and running the web flow in a browser tab to reach web wallets too.
5. Register your check-in page or app with the registration form, as a Verifier (role verifier). Verifier is the side that asks for data: EHR check-in pages, patient portals, kiosks, and clinic apps all register as Verifiers. The form opens a pull request that adds you to the Participant directory, so wallet teams can test against you. A web page lists its URL; a phone app lists its platforms and how testers get it (examples).
6. Run the scenarios. Start with the three minimum scenarios on the front page: each gives its request, what passing looks like, and how to run it with the test tools. Then try the advanced scenarios.
7. Share what you found from the developer track on the Share your experience page (details below).

Joining

• Register: register your check-in page or app (step 5 of Get started), ideally a week before the event.
• The live event: on Zoom; the date, time, and link are on the main page. Join the main room for the opening, the hourly check-ins, and the closing report-out. Pair with wallet teams in breakout rooms you start yourself (how).
• Questions: ask in the #kill-the-clipboard channel on the CMS Health Tech Ecosystem Slack.

Share what you found

Debrief your testing from the developer track on the Share your experience page: it has a debrief prompt for any AI assistant, and the experience form. Record each formal scenario run as a structured result too. Reports are public, credited with the name and organization you give.

Reference

What you build

The practice system. Its check-in page builds a request, lets the patient choose a wallet, and handles the response in the same page.

1. Build the request. A small JSON document listing the items you want: records by FHIR profile, or a form to fill in. (§5.2)
2. Wrap it and create a one-time key. The request goes inside an mdoc request, and the page makes a fresh encryption key for the answer. (§8.2)
3. Send it to the wallet the patient picked. A native wallet goes through the browser's Digital Credentials API. A web wallet gets it from your page by postMessage. (VRQ-8)
4. Decrypt the answer and check its signatures. Signature and other mdoc-layer problems are warnings to report, not reasons to reject (§8.5).
5. Check the answer against the request, then show it to staff. (§6.4)

The client library does steps 2 to 5 above for JavaScript pages: drop in <smart-checkin-picker>, or call runCheckin. Install has the install line and the hosted files.