SMART Health Check-in connectathon

An online event where patients, clinic staff, and software teams try a new way of checking in for a visit and tell us how it feels.

How the event works

Draft. The event date isn't set yet, so dates below say "To be announced". Everything else linked here is live. Components marked "not yet" in the Participant directory aren't ready for testing.

• When and where. KTC pre-visit check-in connectathon, To be announced, about 3 hours, on Zoom: To be announced.
• What it's for. Experience with a new way of checking in, not a formal conformance test. Software teams connect clinic systems to patients' health apps, and patients, clinic staff, and community members try the result. It uses the SMART Health Check-in 1.0 draft specification.
• One Zoom meeting. Everyone joins the main room for the opening, the hourly check-ins, and the closing report-out, where participants share what they found.
• One chat. Questions, pairing, and links go in #kill-the-clipboard on the CMS Health Tech Ecosystem Slack (open channel).
• Breakout rooms you start yourself. Two people debugging together: start a Slack huddle in a direct message; it has video and screen sharing. A group, or someone not on the Slack: open https://meet.jit.si/ktc-checkin-<ehr>-<wallet> and post the link in the channel.
• Registration is for software. Teams bringing an EHR, portal, or wallet register it so others can test against it (see the register step for Verifier developers or Wallet developers). Everyone else just joins.
• Made-up data only. Every patient, record, and clinic in the demos and test tools is synthetic. Never use real health information, even your own.

Schedule

• Three weeks before (To be announced): reference implementations, the SMART Testing EHR and SMART Testing Wallet, the wallet registry, and the scenarios with their requests are live.
• One week before (To be announced): software teams aim to have their component up for self-serve testing and to have tried a first connection.
• The event: ideally spent on the harder problems and live debugging. Some people will still be finishing basic setup, and that's fine.

How to test

Software teams bring a Verifier (a clinic's check-in page, portal, kiosk, or app, which asks for data) or a wallet (the patient's health app, which answers). Make your component testable without you in the room, and list it in the Participant directory by registering: a Verifier lists its check-in page URL, a web wallet goes into the wallet registry, and a native wallet says how testers get it. Verifier and wallet teams run the scenarios in pairs, with as many counterparts as they can reach. Test early and alone against the SMART Testing EHR and the SMART Testing Wallet, so the live event is left for problems that need two people. A failure is as useful as a pass, since it often points to a gap in the spec or an interoperability bug.

Each scenario gives its request, the step for the person using the wallet, what the Verifier should see, what counts as a pass for each side, and how to run it with the test tools. Every response must also pass the spec's own checks, which the SMART Testing EHR runs and links to their requirements. Section links such as §5.6 go to the spec, SMART Health Check-in 1.0.

Ground rules

• Open trust. Wallets accept any Verifier origin and don't require reader authentication, and Verifiers accept responses from any wallet. There are no certificates or trust lists (§7).
• Patients don't need to match. Each wallet holds its own synthetic patient, so what arrives won't match a Verifier's test chart. A Verifier that matches patients should still let these scenarios run to the end and show what arrived.
• Handoff is a plain link. The patient opens the Verifier's check-in page in a browser. Portal buttons, text messages, and QR codes are product choices outside the spec (§1.3).
• FHIR R4 and US Core. Every request asks for FHIR 4.0.1 as application/fhir+json; the insurance item also accepts a SMART Health Card (§5.6).
• Responses under 512 KB. Every minimum scenario's response fits in 512 KB. Larger responses have their own scenarios.
• Your own devices. Native-wallet testing needs an Android phone with Chrome, or an iPhone with Safari 26, with a wallet installed. For Android there is the reference Android wallet; for iOS, use participants' own wallets.

Minimum scenarios

Every Verifier and every wallet should pass these three scenarios. Record each run as a result. Teams that pass them can go on to the advanced scenarios.

Scenario 1: Share records

The patient shares their records and insurance card from a wallet: all of them, some of them, or none. Any status for an item passes, including unavailable and declined. A web wallet is listed in the Verifier's wallet registry and opens in a new tab; a native wallet is an app on the phone, reached through the phone's wallet chooser. A team runs whichever path its component uses, and a Verifier that supports both runs each.

Request: records.json asks for demographics, problems, allergies, medications, immunizations, and the insurance card (sample response).

Pass for the wallet: The wallet shows the Verifier's origin during consent.

Pass for the Verifier: The Verifier shows each item's status and whatever records came back, including the member, payer, and plan from an insurance card, whichever profile or format the wallet chose. It shows an unavailable or declined item, and a response with no records at all, as a normal outcome, not as an error. It sets a record aside, with a warning, only when the spec's cross-checks (§6.4) say to. If the wallet returns a SMART Health Card, the Verifier verifies its signature before showing it.

How to run it:

• Wallet teams: open the SMART Testing EHR with share-records chosen, choose your wallet under “Which wallet” (“Your phone's health app” for a native wallet), and send.
• Verifier teams: on the web path, check in from your page with the SMART Testing Wallet, which is in the wallet registry; on the native path, check in on an Android phone with the reference Android wallet, picking it from the phone's wallet chooser.

Also: On the native path, record the phone, OS version, browser, and wallet app.

Spec: §8.5, §8.6, §6.4, §A.2, §5.6

Scenario 2: Fill in a form

The wallet fills in a form sent inline, and its QuestionnaireResponse names exactly the requested form.

Request: form-phq2.json asks for demographics and the answers to the PHQ-2 form, sent inline (sample response).

Step for the person using the wallet: Fill in the PHQ-2 form and share it.

Checks, besides the spec's own: “Two questions about your mood” is fulfilled (the step was done).

Pass for the wallet: The wallet renders the inline form.

Pass for the Verifier: The Verifier shows each answer next to its question.

How to run it:

• Wallet teams: open the SMART Testing EHR with fill-form chosen, choose your wallet under “Which wallet” (“Your phone's health app” for a native wallet), and send.
• Verifier teams: on the web path, check in from your page with the SMART Testing Wallet, which is in the wallet registry; on the native path, check in on an Android phone with the reference Android wallet, picking it from the phone's wallet chooser and doing the step in it.

Spec: §5.4.2, §5.5

Scenario 3: Decline one item

The person declines one item, so the Verifier is sure to receive a declined status.

Request: records.json, the same request as share-records, asks for demographics, problems, allergies, medications, immunizations, and the insurance card.

Step for the person using the wallet: Decline Immunizations and share whatever else the wallet offers.

Checks, besides the spec's own: “Immunizations” is declined (the step was done).

Pass for the Verifier: The Verifier shows Immunizations as declined, as share-records describes.

How to run it:

• Wallet teams: open the SMART Testing EHR with decline-item chosen, choose your wallet under “Which wallet” (“Your phone's health app” for a native wallet), and send.
• Verifier teams: on the web path, add https://smart-health-checkin.org/connectathon/testing-wallet/eyJzdGF0dXMiOnsiaW1tdW5pemF0aW9ucyI6ImRlY2xpbmVkIn19/ as a web wallet on your page and check in with it; at that address the SMART Testing Wallet does the step itself (config URLs); on the native path, check in on an Android phone with the reference Android wallet, picking it from the phone's wallet chooser and doing the step in it.

Spec: §5.7, §6.2

Recording results

Record each run through the result form: the Verifier, the wallet, the path (web wallet or native wallet), the scenario, the device and browser, pass or fail, and a note. Attach a screenshot of what the Verifier showed and, where you can, the captured request and response or the Testing EHR's log. After a run, the Testing EHR's “File this result” button fills in the form for you. The Results page collects every run.

Shared resources

The event's resources are all under https://smart-health-checkin.org/connectathon/.

Wallet registry

The event registry, https://smart-health-checkin.org/connectathon/wallets.json, lists every web wallet in the participant directory whose status is up. Verifier pages read it to list the wallets a patient can choose. It uses the format the client library reads (Registry format):

{
  "source": "KTC SMART Health Check-in connectathon registry",
  "wallets": [
    {
      "id": "example",
      "name": "Example Health App",
      "walletUrl": "https://example.org/checkin-wallet",
      "description": "Web wallet with synthetic patient Jane Test.",
      "homepage": "https://example.org",
      "iconUrl": "https://example.org/icon.png",
      "target": "tab"
    }
  ]
}

You don't edit this file. The registration form adds your web wallet to your organization's participant file, and the registry is built from those files (fields). Native wallets aren't in it, because the phone's own wallet chooser reaches them; they're listed in the Participant directory only.

The list changes during testing, so a Verifier should load it each time its check-in page opens, or sync it automatically, rather than build it in.

Reference Android wallet

A native wallet for Android, holding the same synthetic patients as the SMART Testing Wallet. Download the latest APK.

• On the phone: open the link, download the file, and allow installs from your browser when Android asks.
• With adb: download the file first, since adb can't install from a URL:

  curl -LO https://github.com/smart-health-checkin/android-wallet/releases/latest/download/smart-health-checkin-wallet.apk
  adb install -r smart-health-checkin-wallet.apk

• Requirements: Android 8 or later, and a Chrome version with the Digital Credentials API. Open the app once after installing, so it registers with the phone's Credential Manager.
• Test patient: choose Aria Test on the app's home screen, or the large record for large-response.

Pick your path

Sharing what you found

Everyone is invited to write a short experience report: what you tried, what worked, what was hard, and what you'd change. The Share your experience page has a track for each kind of participant, patients, clinic staff, developers, and observers, with prompts that turn any AI assistant into a guide and the form to send your report. Reports are public, credited with the name and organization you give, or anonymous.