Skip to main content
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 for the exact, machine-readable shapes. 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:
The flag determines how a receiver fetches the file. See Retrieve a 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). 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. Resources in the bundle do not carry meta.profile. The KTC specification says resources in this bundle should not include it, and that receivers must not require it. Match an entry to the profiles below by validating its content, not by reading meta.profile. Resources may carry meta.tag values that record processing haau3 applied to a record; receivers can safely ignore them.

KTC Patient-Shared Bundle profile

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).

KTC Patient-Shared DocumentReference profile

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.

Example: Patient-Shared Bundle

A complete example instance (also available as JSON).

haau3 Patient Story Observation

The profile for patient self-reported care-experience preferences.

Bundle profile

KTC Patient-Shared Bundle StructureDefinition.

All IG artifacts

Every profile, value set, and example in the haau3 IG.