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: 
{
  "url": "https://haau3.com/api/shl/d/NkXSIk-jfAINlAP41k8LShDGcHd6dfLgXYZUj53Gkps",
  "flag": "U",
  "key": "rxTgYlOaKJPFtcEd0qcceN8wEU4p94SqAwIWQe6uX7Q",
  "label": "Health summary"
}
FieldDescription
urlWhere to retrieve the content.
keyBase64url-encoded 256-bit key used to decrypt the retrieved file.
flagOptional flags: L (long-term), P (passcode), U (direct file).
labelShort human-readable description of the share.
expOptional expiration (epoch seconds).
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.
EntryCardinalityProfile
Patient1..1US Core Patient
DocumentReference0..*KTC Patient-Shared DocumentReference
Condition0..*US Core Condition (Problems & Health Concerns)
MedicationRequest0..*US Core MedicationRequest
AllergyIntolerance0..*US Core AllergyIntolerance
Immunization0..*US Core Immunization
Observation (lab)0..*US Core Laboratory Result Observation
Observation (vital signs)0..*US Core Vital Signs
Patient Story Observation0..*haau3 Patient Story Observation
Questionnaire / QuestionnaireResponse0..*haau3 Questionnaire / QuestionnaireResponse

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.