Kill the Clipboard — CMS Pledge

TendTo participates in the CMS Health Tech Ecosystem as a pledged Patient-Facing App in the Kill the Clipboard category. This page is the canonical disclosure for CMS reviewers, patients, and caregivers.

The Pledge (verbatim)

We pledge to empower patients to retrieve their health records from CMS Aligned Networks or personal health record apps and share them with providers via QR codes or Smart Health Cards/Links using FHIR bundles. When possible, we will return visit records to patients in the same format. We commit to seamless, secure data exchange — eliminating the need for patients to repeatedly recall and write out their medical history. We are committed to "kill the clipboard," one encounter at a time.

How TendTo Implements It

From the Pre-Visit Packet screen a caregiver picks what clinical data goes in the packet (active medications, allergies, recent appointments, recent vitals), and TendTo assembles a FHIR R4 Bundle, encodes it as a SMART Health Card v1, and renders the result as one or more QR codes ready to show at clinic check-in.

SMART Health Card Mechanics

• Format: SMART Health Cards v1 — DEFLATE-compressed JWS over a vc.credentialSubject.fhirBundle payload, signed with ES256 (ECDSA P-256). Numeric encoding for QR per spec (each char = two digits).
• Signing key: EC P-256 keypair held server-side. The private scalar never leaves the server. Public JWK is published at the standard discovery URL /.well-known/jwks.json with alg=ES256 and use=sig.
• Chunking: bundles larger than the per-QR character budget split into multiple QRs (shc:/1/N/..., shc:/2/N/...) which the caregiver UI paginates.
• Verification: any standards-conformant SMART Health Card reader fetches the JWKS, verifies the signature, and inflates the FHIR bundle.
• Insurance card: caregiver-entered payor, member ID, plan, and group number map to a FHIR R4 Coverageresource that travels with the bundle when the caregiver opts into the "Insurance card" checkbox.

SMART Health Link Mechanics

When the caregiver chooses Smart Health Link instead of a one-shot QR, TendTo stores an encrypted snapshot of the SHC server-side and returns a shlink:/-encoded discovery URL the clinic can open in any SMART Health Link verifier.

• Encryption: A256GCM JWE with a 32-byte symmetric key embedded in the shlink:/ payload. Verifiers read the key from the QR, decrypt the JWE, then verify the inner ES256 JWS against the JWKS.
• Manifest endpoint: /api/health-cards/shl/<id>/manifest.json — verifier POSTs an optional recipient string and receives an embedded JWE.
• Lifecycle: caregiver-set expiry (default 7 days, max 90), view cap (default 100, -1 disables), and revocation. Manifest endpoint enforces all three before returning content.
• Trust model: server holds the symmetric key alongside the encrypted content. The shlink:/ URL is itself the capability — treat it like a key and share it only with the intended clinic.

Receiving visit records back from the provider

The pledge asks issuers to also receive visit records back from the provider. TendTo implements this with single-use bearer tokens caregivers issue from /visits. The token URL goes to the clinic on paper or by QR; the clinic's EHR posts a FHIR R4 Bundle to the public inbound endpoint /api/visit-records/inbound/<token>, and TendTo runs the same importer used for Blue Button to merge medications, allergies, conditions, appointments, and observations into the caregiver's circle.

• Token model: 256-bit bearer token; only sha256(token) is stored server-side. Single-use, default 7-day expiry (max 30), revocable.
• Body cap: 5 MB max bundle size.
• Audit: every receipt writes both an activitiesrow visible on the patient feed and an fhir_activity_log row tagged source=visit_record, so caregivers see exactly when a clinic returned their data.

Audit Visibility

Every Blue Button import, SMART Health Card issuance, and SMART Health Link issuance is recorded in the patient-visible activity feed alongside circle activities (medications, appointments, documents, etc.). Caregivers see exactly who accessed which records and when, satisfying the CMS Interoperability Framework's audit-transparency requirement.

Source Data

TendTo connects directly to Medicare Blue Button 2.0, the CMS-operated FHIR R4 endpoint for Medicare beneficiaries. Caregivers grant access via OAuth 2.0 with PKCE; access and refresh tokens are encrypted at rest with AES-256-GCM. Imported resources live in the caregiver's care circle and are the source for the SMART Health Card the caregiver builds.

Privacy & Audit

• Signed, not encrypted. SHC contents are visible to anyone who scans the QR. The Pre-Visit Packet UI surfaces this warning before generation and instructs the caregiver to only show the QR to the clinic at check-in.
• Per-circle membership check. SHC issuance enforces care-circle membership server-side; RLS does the same on every read.
• Audit log. Every issuance is recorded in fhir_activity_log with direction export and source shc.
• Rate limit. One issuance per minute per circle (sufficient for legitimate use).
• HIPAA-aligned operation; BAAs in place with subprocessors that touch PHI.

Provider Workflow

1. Caregiver opens Pre-Visit Packet, picks the data to share, taps Generate.
2. QR appears on the caregiver's device.
3. Front desk staff scans the QR with a SMART Health Card reader.
4. Reader verifies the JWS signature against the JWKS at tendto.ai/.well-known/jwks.json.
5. FHIR bundle inflates into the EHR's registration screen — no clipboard.

Reviewer Contact

For CMS review, security questions, or HIPAA inquiries: [email protected]