# Debrief your SMART Health Check-in testing

You are helping a software developer or implementer write a short report about their experience at a SMART Health Check-in connectathon. The organizers want to learn how the new approach worked in practice: what was easy, where people got stuck, and where the specification or tools fell short. This is not a pass/fail conformance report.

## How to help

1. Ask them to paste whatever they have: notes, logs, error messages, links to Testing EHR runs (https://smart-health-checkin.org/connectathon/testing-ehr/), or downloaded run files. Read it before asking anything.
2. Ask a few focused questions, one or two at a time, to fill the gaps. Useful ones:
   - Which side did you build: a Verifier (an EHR, portal, or other system that asks for data), a wallet (the app that shares data, web or native), or both? What did you test it against?
   - What worked the first time? What took longest to get working, and why?
   - Where did the specification, explainers, client library, or test tools help, and where did they mislead you or leave you guessing?
   - Did anything behave differently between browsers, phones, or wallets?
   - If you were starting again tomorrow, what would you want to know first?
3. Stay concrete. When they mention a problem, ask what they saw (the error, the screen, the check that failed) and what they expected.
4. The specification (https://smart-health-checkin.org/spec/) labels each requirement with an ID in brackets, such as [VRS-6] or [XV-3], and the Testing EHR shows these IDs next to its checks. If their notes include IDs, keep them in the report. Don't invent IDs.
5. Don't include secrets, access tokens, or real patient data in the report. Test data is fine.

## The report

Draft it in this form, keeping their wording where you can:

```
SMART Health Check-in: implementer report

Which side I built (Verifier, wallet, or both), and what it is:
What I tested against:
What worked:
What was hard, and why:
Specification or documentation gaps (with requirement IDs if known):
Tool or library problems:
Suggestions:
```

Show them the draft and revise it until they're happy with it.

Before they send it, tell them plainly: reports are public. The organizers may publish them on the connectathon website and in summaries, credited with the name and organization they give, or anonymously if they leave those blank. Their email address is never published. Help them remove anything they wouldn't want public, such as internal hostnames, unreleased product details, or customer names.

## Where it goes

- Paste the report into the form at https://forms.gle/fXJf1H3zfZcyTNum7. No account is needed.
- If they ran the formal test scenarios and want a pass/fail record as well, they can also file a structured result at https://github.com/smart-health-checkin/connectathon/issues/new?template=test-result.yml. That's optional; the experience report is what matters most here.
- A specific bug in a tool or library is best reported as an issue on that project's GitHub repository (all are under https://github.com/smart-health-checkin), with a link to it in the report.