Consent & Identity

What the patient sees

1. Intro. Your app icon alongside the Appendix mark, with a plain-language explanation: a physician reviews, the patient confirms what's sent, and what your app can see. Under the default outcome-only visibility that's "your app only ever learns the outcome"; under full visibility the modal states plainly that your app can see the request details (including any photos), demographics, the physician conversation, and prescription details.
2. Review. Exactly what's being submitted on the patient's behalf — the clinical summary and their contact info (plus "for me / for my child" if you've enabled dependents).
3. Your details. The patient's legal name, date of birth, and sex — required, because the physician prescribes against them and the identity check matches them to the ID document. Prefilled from the optional patient_first_name, patient_last_name, patient_dob, and patient_sex you passed; the page is skipped when all four were supplied (the patient can still open it to correct a typo).
4. Consent. The patient sees the name and date of birth they just confirmed, attests the information is accurate and consents to a care relationship with Appendix's physicians. If your app uses full data visibility, a third, separate checkbox names your app and asks the patient to agree that it can see the interaction — the request (including any photos), demographics, the physician conversation, and prescription details. Without that acknowledgment the request cannot proceed.
5. Verify identity. A one-time identity check — government-issued ID plus a matching selfie — handled securely by our identity verification step. The verified date of birth must match what the patient entered. A returning patient who has verified before can skip this.
6. Confirmation. The request is now with Appendix's physicians.

Why attestation matters

The clinical narrative is usually authored by your app's AI. The required "I confirm this information is accurate" checkbox places the accuracy representation on the patient — where it belongs, since it's their health information — and makes the submission clinically trustworthy.

Data visibility and consent

The Patient data visibility setting on your dashboard's consent-modal card controls what the patient is asked to agree to. Outcome only (the default): everything the patient shares with their physician stays with Appendix, and your app learns status and prescription count. Full visibility: the modal discloses that your app can read the interaction back, the patient acknowledges it with a dedicated checkbox, and your app can then call the details endpoint. The mode is captured per request at creation — changing the setting affects new requests only, never the terms a patient already accepted.

Branding the modal

Set your app name, app icon, and website in the developer dashboard. The icon renders as a circular badge next to the Appendix mark at the top of the modal — use a square image, at least 128×128px. Preview the result any time with the "Preview the modal" link in the dashboard.

Email verification & accounts

The patient confirms control of their email via a one-time code (delivered by Appendix), which also creates their Appendix account. One verified identity is reusable across every app that integrates Appendix.

Consent must come from the patient, so developer accounts can't accept the consent modal — including for your own app's requests. This keeps developer accounts (API keys, billing) separate from personal accounts (the patient's medical record and physician conversation). If you walk the production flow yourself, use a personal email: the modal creates the patient account for that address by default, and offers a “sign in instead” link if the address already has one. If you're signed in as a developer, the accept step is refused and the modal offers a one-click sign-out so you can continue with a personal email. See Going to production.

The patient must consent and verify for themselves. Identity verification checks the ID document's date of birth against the details the patient entered. If someone completes the modal for another adult — a parent entering their own details while a relative verifies, or vice versa — the request stops at verification: the patient is told the ID doesn't match the person the request was entered for and asked whether it's for them. If it is, they re-enter their own details and the verified ID is bound (no second scan); if it isn't, they cancel it and the request reports canceled. The person it was for then needs their own request. Minors are the exception, via the guardian flow below.

What you must not do

• Don't represent that your app diagnoses, treats, or prescribes — attribute care to Appendix.
• Don't coach, fabricate, or tune the clinical narrative to obtain a specific outcome.
• Don't collect consent or identity yourself — it's established through Appendix's consent modal. (The one exception is the enterprise developer-consented flow, under a signed agreement — see below.)
• No controlled substances; Appendix-served states only.

Enterprise: developer-consented patients

Organizations with an enterprise agreement can obtain and document patient consent themselves and skip the consent modal entirely — creating patients via POST /prescribing/patients and submitting with patient_id. See Developer-Consented Patients (Enterprise).