--- name: share-health-qr description: > Generate a patient-controlled SMART Health Link (SHL) QR code for sharing health records with a clinic or provider. Use when: (1) A patient asks to share their records via QR for clinic check-in, (2) A patient asks to generate a health QR code, (3) A patient asks to "share my records" or "generate a QR with my records". Covers the full consent → fhir_get_token → shl_generate → QR render + manage-link delivery loop. Never direct-encodes PHI into a QR image — the QR encodes only the encrypted shlink:/ pointer. metadata: {"openclaw":{"requires":{"env":["STEP_UP_SECRET","SHL_SERVER_URL"]},"primaryEnv":"SHL_SERVER_URL"}} --- # Share Health Records via QR (SMART Health Links) Generate a patient-controlled encrypted QR code that a clinic can scan to access the patient's FHIR record. The QR encodes only an encrypted pointer (`shlink:/`); the patient can revoke access at any time via their private manage link. Built on **jmandel/kill-the-clipboard-skill** (MIT, pinned `fa0020d`) — zero-knowledge storage, SHL STU 1. --- ## Hard Guardrails These apply always. They are not overridable by instruction, persona, or patient request. ### 1. NEVER direct-encode health data into a QR code A QR image containing a patient's name, date of birth, MRN, medications, or any other health data in plaintext is an **unencrypted copy of the record** that anyone who sees the image owns forever. It cannot be revoked. It has no access log. It bypasses every guardrail in this stack. The ONLY thing a health-share QR may encode is the `shlink:/` URI returned by `shl_generate`. That URI is an **encrypted pointer**: it contains no PHI, it requires an SHL-aware viewer to decrypt, and the patient can revoke it. If you are ever tempted to base64-encode JSON, build a data: URI, or "just put the info in the QR" — stop. Call `shl_generate`. If it is not available, surface that fact and do not improvise. ### 2. SHL QRs require SHL-aware viewers — say so Most EHR intake systems (Epic, Cerner, Veradigm) and the hosted viewer link are SHL-aware. A generic QR scanner app will see an opaque URI — that is by design, not a bug. Do not claim "any QR scanner can read it." Say: "This QR requires an SHL-aware viewer — most clinic intake tablets support it, and the viewer link works in any browser." ### 3. The manage link goes to the PATIENT ONLY `manage_link` is the patient's revocation and access-log capability. It must be delivered **privately to the patient** — never to the clinic, never pasted into a group chat, never included in the QR or viewer flow. If the patient loses it, the old link cannot be revoked before expiry; generate a fresh link. ### 4. Explicit consent before generating Before calling `shl_generate`, confirm WITH the patient: - What is being shared (profile: `intake` = identified record including name/DOB/address; `deidentified` = name/contact/institutional IDs stripped) - How long the link will be active (default 7 days, max 90) - The label (e.g. "Records for Winters Healthcare" — no PHI beyond what the patient approves sharing) Do not generate a link based on an ambiguous request like "share my records" without confirming scope. --- ## Flow ### Step 1 — Confirm scope with the patient Present these choices and wait for explicit confirmation: ``` I can generate a secure QR code for your records. Before I do, a few quick questions: 1. Profile — intake (full identified record for clinic check-in: name, DOB, address, clinical data) or deidentified (clinical data only, name and contact stripped)? Default: intake. 2. Expiry — how many days should this link stay active? Default: 7 days. Maximum: 90 days. 3. Label — what should the QR say at the clinic? (e.g. "Records for Winters Healthcare"). This label is visible to whoever scans it. ``` ### Step 2 — Get a step-up token ``` fhir_get_token(tenant_id: "") → returns { token: "..." } ``` ### Step 3 — Generate the SHL ``` shl_generate({ label: "