# Patient-Shared Health Document via SMART Health Links
> **Status:** Draft
> **Version:** 0.2.0
## Introduction
This implementation guide defines a constrained profile of SMART Health Links (SHLinks) for patient-to-provider sharing of health documents at the point of care. A patient presents a QR code; the provider's EHR scans it, downloads an encrypted PDF, and stores it.
### Requirements
> 1. Patient app creates a SHLink pointing to any FHIR resources, and including a DocumentReference to a "Patient-Shared PDF". This PDF should include:
> - All available USCDI data or a summary of elements specified by IPS, as filtered/selected by the patient. (Discrete data shared in the PDF should also be offered as FHIR discrete data.)
> - Any additional information the patient wants to share
>
> 2. The provider can scan the SHLink QR, resolve + decrypt the data, and store this information.
> - At minimum, the EHR must be able to store the Patient-Shared PDF and present it to users.
> - The EHR may also display, ingest, and use other content from the SHLink.
>
> 3. At no point in this flow does a patient need to sign into an EHR Portal.
>
> — *Kill the Clipboard Working Group, 1/30/2025*
### Scope
This IG defines:
1. SHLink payload constraints for patient-shared documents
2. A FHIR Bundle profile containing the patient summary and DocumentReference
3. Requirements for patient apps (senders) and EHRs (receivers)
### Actors
| Actor | Role |
|-------|------|
| Patient App | Generates SHLink QR containing encrypted patient summary |
| Patient | Presents QR to provider |
| Provider EHR | Scans QR, downloads and stores patient-shared document |
---
## Workflow
```
┌──────────────┐ ┌──────────────┐
│ Patient App │ │ Provider │
│ │ │ EHR │
│ 1. Generate │ 2. Present QR │ │
│ PDF │ ─────────────────────────────────► │ 3. Scan QR │
│ + Bundle │ │ │
│ + SHLink │ │ 4. Decode │
│ │ │ SHLink │
│ │ 5. HTTP GET (+recipient) │ │
│ │ ◄───────────────────────────────── │ │
│ │ │ │
│ │ 6. Encrypted payload │ │
│ │ ─────────────────────────────────► │ 7. Decrypt │
│ │ │ + Store │
│ 8. Audit log │ │ │
└──────────────┘ └──────────────┘
```
> **Try it:** A working prototype with a sample QR code is available at [pshd-shl.exe.xyz/prototype.html](https://pshd-shl.exe.xyz/prototype.html).
---
## SHLink Constraints
This IG profiles the [SMART Health Links specification](https://hl7.org/fhir/uv/smart-health-cards-and-links/STU1/links-specification.html) with the following constraints.
### SHLink Payload (decoded)
```json
{
"url": "https://patient-app.example.com/Y9xwkUdtmN9wwoJoN3ffJIhX2UGvCL1JnlPVNL3kDWM",
"flag": "U",
"key": "rxTgYlOaKJPFtcEd0qcceN8wEU4p94SqAwIWQe6uX7Q",
"exp": 1706745600,
"label": "Jessica Argonaut's health summary"
}
```
| Field | Cardinality | Constraint |
|-------|-------------|------------|
| `url` | 1..1 | Endpoint returning encrypted payload |
| `flag` | 1..1 | `U` (direct retrieval; this is the SHLink default) |
| `key` | 1..1 | Decryption key |
| `exp` | 1..1 | **Required.** Expiration timestamp. SHOULD be short-lived for sensitive data. |
| `label` | 0..1 | Human-readable description |
Patient Apps SHALL generate SHLinks with the `U` flag, meaning the link resolves directly to a single encrypted file without requiring a passcode. Since this is the default SHLink behavior, most implementations will already conform.
---
## Retrieval Protocol
With the `U` flag, the SHLink URL resolves directly to a single encrypted file (bypassing the manifest).
### Request
The EHR retrieves the encrypted payload via HTTP GET. The EHR **SHALL** supply a `recipient` query parameter identifying the requesting organization.
```http
GET https://patient-app.example.com/Y9xwkUdtmN9wwoJoN3ffJIhX2UGvCL1JnlPVNL3kDWM
?recipient=Verona+Health+System
```
| Parameter | Cardinality | Description |
|-----------|-------------|-------------|
| `recipient` | 1..1 | Organization name requesting access. Appropriate for display to patient in audit log. |
### Response
```http
HTTP/1.1 200 OK
Content-Type: application/jose
```
Body contains a JWE (JSON Web Encryption) compact serialization string.
### Decryption
Per the SHLink specification, files are encrypted using JWE with:
- `"alg": "dir"` (direct encryption with shared symmetric key)
- `"enc": "A256GCM"` (AES-256-GCM)
- `"cty": "application/fhir+json"` (content type of decrypted payload)
The EHR decrypts using the 32-byte `key` from the SHLink payload (base64url-decoded) to obtain the FHIR Bundle.
**Example JWE structure (compact serialization):**
```
eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIiwiY3R5IjoiYXBwbGljYXRpb24vZmhpcitqc29uIn0
..
<IV>
.
<ciphertext>
.
<authentication tag>
```
The decrypted payload is a FHIR Bundle conforming to the PatientSharedBundle profile.
---
## FHIR Bundle Profile: PatientSharedBundle
The decrypted payload is a FHIR Bundle conforming to this profile.
**Canonical URL:** `https://cms.gov/fhir/StructureDefinition/patient-shared-bundle`
### Structure
```
Bundle (type: collection)
├── Patient (1..1)
├── DocumentReference (1..1) - PatientSharedDocumentReference profile
│ └── content.attachment - embedded PDF (base64)
└── [Additional FHIR resources]* (0..*)
```
### Constraints
| Element | Cardinality | Constraint |
|---------|-------------|------------|
| `type` | 1..1 | Fixed: `collection` |
| `timestamp` | 1..1 | When bundle was assembled |
| `entry` | 2..* | Minimum: Patient + DocumentReference |
| `entry:patient` | 1..1 | Patient resource |
| `entry:documentReference` | 1..1 | Conforms to PatientSharedDocumentReference |
> **Note:** Resources in this Bundle SHOULD NOT include `meta.profile`. Receivers SHALL NOT require `meta.profile` to be present.
### Example
```json
{
"resourceType": "Bundle",
"type": "collection",
"timestamp": "2026-01-30T12:00:00Z",
"entry": [
{
"fullUrl": "urn:uuid:b5e506f4-e14c-4e27-9543-4b8d1e1f3e2a",
"resource": {
"resourceType": "Patient",
"name": [{"given": ["Jessica"], "family": "Argonaut"}],
"birthDate": "1985-03-15",
"gender": "female"
}
},
{
"fullUrl": "urn:uuid:c7a2f8e1-3d4b-5c6a-9e8f-0a1b2c3d4e5f",
"resource": {
"resourceType": "DocumentReference",
"meta": {
"security": [{
"system": "http://terminology.hl7.org/CodeSystem/v3-ObservationValue",
"code": "PATAST",
"display": "patient asserted"
}]
},
"status": "current",
"type": {
"coding": [{
"system": "http://loinc.org",
"code": "60591-5",
"display": "Patient summary Document"
}]
},
"category": [{
"coding": [{
"system": "https://cms.gov/fhir/CodeSystem/patient-shared-category",
"code": "patient-shared",
"display": "Patient-Shared"
}]
}],
"subject": {
"reference": "urn:uuid:b5e506f4-e14c-4e27-9543-4b8d1e1f3e2a"
},
"author": [{
"reference": "urn:uuid:b5e506f4-e14c-4e27-9543-4b8d1e1f3e2a"
}],
"date": "2026-01-30T12:00:00Z",
"description": "Patient-shared health summary",
"content": [{
"attachment": {
"contentType": "application/pdf",
"data": "JVBERi0xLjQKJeLjz9..."
}
}]
}
}
]
}
```
---
## DocumentReference Profile: PatientSharedDocumentReference
**Canonical URL:** `https://cms.gov/fhir/StructureDefinition/patient-shared-document-reference`
**Based on:** [US Core DocumentReference](http://hl7.org/fhir/us/core/StructureDefinition-us-core-documentreference.html)
This profile aligns with the US Core [Writing Clinical Notes](https://build.fhir.org/ig/HL7/US-Core/writing-clinical-notes.html) guidance for patient-asserted content.
### Constraints
| Element | Cardinality | Constraint |
|---------|-------------|------------|
| `meta.security` | 0..* | SHOULD include `PATAST` (patient asserted) from `http://terminology.hl7.org/CodeSystem/v3-ObservationValue` |
| `status` | 1..1 | Fixed: `current` |
| `type` | 1..1 | Fixed: LOINC `60591-5` (Patient summary Document) |
| `category` | 1..* | SHALL include `https://cms.gov/fhir/CodeSystem/patient-shared-category#patient-shared` |
| `subject` | 1..1 | Reference(Patient) in same Bundle |
| `author` | 1..* | SHALL include Reference(Patient) — the patient is the author/sharer |
| `date` | 1..1 | When document was shared |
| `content` | 1..1 | |
| `content.attachment.contentType` | 1..1 | Fixed: `application/pdf` |
| `content.attachment.data` | 1..1 | Base64-encoded PDF |
---
## Terminology
### CodeSystem: PatientSharedCategory
**Canonical URL:** `https://cms.gov/fhir/CodeSystem/patient-shared-category`
| Code | Display | Definition |
|------|---------|------------|
| `patient-shared` | Patient-Shared | Document shared by the patient via patient-mediated exchange |
```json
{
"resourceType": "CodeSystem",
"id": "patient-shared-category",
"url": "https://cms.gov/fhir/CodeSystem/patient-shared-category",
"version": "0.2.0",
"name": "PatientSharedCategory",
"title": "Patient-Shared Document Category",
"status": "draft",
"experimental": true,
"description": "Code indicating a document was shared by the patient via patient-mediated exchange such as SMART Health Links",
"caseSensitive": true,
"content": "complete",
"concept": [
{
"code": "patient-shared",
"display": "Patient-Shared",
"definition": "Document shared by the patient or their authorized representative via patient-mediated exchange"
}
]
}
```
---
## Conformance Requirements
### Patient App (Sender)
**SHALL:**
- Generate SHLink with `flag` = `U`
- Include `exp` (expiration) in SHLink payload
- Serve encrypted payload without requiring authentication
- Return encrypted FHIR Bundle conforming to PatientSharedBundle profile
- Include DocumentReference conforming to PatientSharedDocumentReference profile
- Embed PDF as base64 in `DocumentReference.content.attachment.data`
- Accept `recipient` query parameter on retrieval endpoint
- Audit each SHLink access with recipient and timestamp
**SHOULD:**
- Set short-lived expiration for sensitive data
- Enable patient to view audit log of who accessed their SHLink
- Minimize IP geofencing to enable reasonable international use
- Include Patient resource with sufficient demographics for matching
- Include `meta.security` with `PATAST` on DocumentReference
**MAY:**
- Include additional discrete FHIR resources (medications, conditions, etc.)
### Provider EHR (Receiver)
**SHALL:**
- Scan and decode SHLink QR codes
- Supply `recipient` query parameter identifying requesting organization
- Decrypt payload using key from SHLink
- Parse PatientSharedBundle
- Store the PDF from the DocumentReference
- Display PDF to clinical users
- Indicate patient-shared provenance in clinical UI
**SHALL NOT:**
- Require `meta.profile` to be present on any resource
**SHOULD:**
- Display patient demographics from Bundle for verification
- Support clinician review before filing to chart
**MAY:**
- Parse and display additional FHIR resources from Bundle
- Ingest discrete data into structured EHR fields
---
## Security Considerations
### Encryption
Per the SHLink specification, files are encrypted using JSON Web Encryption (JWE) compact serialization:
| Parameter | Value |
|-----------|-------|
| `alg` | `dir` (direct encryption — key used directly, no key wrapping) |
| `enc` | `A256GCM` (AES-256-GCM authenticated encryption) |
| `cty` | `application/fhir+json` (content type of plaintext) |
The 32-byte symmetric key is embedded in the SHLink payload (base64url-encoded as 43 characters). Security relies on:
1. The key never being transmitted to the server separately
2. The key being embedded in the QR/URL fragment (not logged by servers)
3. Physical control of the QR by the patient
### Expiration
The `exp` field is **required** in this profile. Apps SHOULD set short-lived expirations appropriate to the use case:
| Scenario | Suggested Expiration |
|----------|---------------------|
| In-person visit (QR on phone screen) | 5–15 minutes |
| Printed QR for scheduled appointment | 24–48 hours |
| Ongoing care relationship | Per patient preference |
### Audit
Patient Apps SHALL maintain audit logs of SHLink access including:
- Timestamp
- Recipient organization (from query parameter)
---
## References
- [SMART Health Links Specification (STU1)](https://hl7.org/fhir/uv/smart-health-cards-and-links/STU1/links-specification.html)
- [US Core DocumentReference](http://hl7.org/fhir/us/core/StructureDefinition-us-core-documentreference.html)
- [US Core Writing Clinical Notes](https://build.fhir.org/ig/HL7/US-Core/writing-clinical-notes.html)
- [International Patient Summary (IPS)](http://hl7.org/fhir/uv/ips/)
- [USCDI v3](https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi)