> ## Documentation Index
> Fetch the complete documentation index at: https://docs.haau3.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Bundle & artifact reference
> What's inside a haau3 SMART Health Link: the encrypted transport, the FHIR bundle, and the document references, with links to the FHIR Implementation Guide.
A haau3 SMART Health Link (SHL) carries a patient's curated health summary in two layers: an
**encrypted transport** (what the QR code and `shlink:` URI encode) and, once decrypted, a
**FHIR bundle** built to explicit profiles. This page walks through both layers and links to
the [haau3 FHIR Implementation Guide](https://fhir.haau3.com/index.html) for the exact,
machine-readable shapes.
## The SMART Health Link payload
Scanning the QR code (or decoding the `shlink:/…` URI) yields a small JSON payload that tells a
receiver where and how to fetch the data:
```json theme={null}
{
"url": "https://haau3.com/api/shl/d/NkXSIk-jfAINlAP41k8LShDGcHd6dfLgXYZUj53Gkps",
"flag": "U",
"key": "rxTgYlOaKJPFtcEd0qcceN8wEU4p94SqAwIWQe6uX7Q",
"label": "Health summary"
}
```
| Field | Description |
| ------- | ------------------------------------------------------------------- |
| `url` | Where to retrieve the content. |
| `key` | Base64url-encoded 256-bit key used to decrypt the retrieved file. |
| `flag` | Optional flags: `L` (long-term), `P` (passcode), `U` (direct file). |
| `label` | Short human-readable description of the share. |
| `exp` | Optional expiration (epoch seconds). |
The `flag` determines how a receiver fetches the file. See
[Retrieve a SMART Health Link](/app/provider-integration/retrieve-smart-health-link). The
retrieved file is a **JWE** (compact serialization) encrypted with **AES-256-GCM**; its
protected header declares `cty: application/fhir+json`. Decrypt it with `key` to get the FHIR
bundle below.
## The FHIR bundle
The decrypted payload is a FHIR **`Bundle`** that conforms to the **KTC Patient-Shared Bundle**
profile (aligned with the [KTC specification](https://ktc-spec.github.io/#fhir-bundle-profile-patientsharedbundle)).
The profile requires:
* `type` fixed to **`collection`**.
* `timestamp` present (when the bundle was assembled).
* At least two entries: exactly one **Patient**, plus one or more content entries.
* Every `entry.fullUrl` populated (FHIR R4 requires this for collection bundles).
Entries are sliced by resource profile so a receiver can locate each kind of content without
scanning. The slicing is **open**, so additional US Core content beyond the named slices is
allowed.
| Entry | Cardinality | Profile |
| ------------------------------------- | ----------- | ---------------------------------------------- |
| Patient | 1..1 | US Core Patient |
| DocumentReference | 0..\* | KTC Patient-Shared DocumentReference |
| Condition | 0..\* | US Core Condition (Problems & Health Concerns) |
| MedicationRequest | 0..\* | US Core MedicationRequest |
| AllergyIntolerance | 0..\* | US Core AllergyIntolerance |
| Immunization | 0..\* | US Core Immunization |
| Observation (lab) | 0..\* | US Core Laboratory Result Observation |
| Observation (vital signs) | 0..\* | US Core Vital Signs |
| Patient Story Observation | 0..\* | haau3 Patient Story Observation |
| Questionnaire / QuestionnaireResponse | 0..\* | haau3 Questionnaire / QuestionnaireResponse |
Full StructureDefinition, element constraints, and slicing in the FHIR IG.
## Document references (PDFs)
Human-readable summaries (a rendered health summary, and the patient's own "Patient Story")
travel as **`DocumentReference`** entries conforming to the **KTC Patient-Shared
DocumentReference** profile. The profile requires:
* `content.attachment.contentType` fixed to **`application/pdf`**, with the PDF base64-encoded
in `content.attachment.data`.
* A `category` of CMS `patient-shared` (`https://cms.gov/fhir/CodeSystem/patient-shared-category`).
* A `type` from the KTC Patient-Shared Document Type value set, which allows two LOINC codes: a
**patient summary** document (`60591-5`) or a **patient note** for the Patient Story
(`51855-5`).
* The patient as a required `author`, so the receiver can see the data is patient-asserted.
* For patient-asserted content such as the Patient Story, a `PATAST` security label
(`http://terminology.hl7.org/CodeSystem/v3-ObservationValue`).
Full StructureDefinition for the embedded PDF document references.
## Profiles & examples in the FHIR IG
The Implementation Guide has the exact shapes, value sets, and worked examples.
A complete example instance (also available as
[JSON](https://fhir.haau3.com/Bundle-ktc-patient-shared-bundle.json)).
The profile for patient self-reported care-experience preferences.
KTC Patient-Shared Bundle StructureDefinition.
Every profile, value set, and example in the haau3 IG.