This fragment is available on index.html
This publication includes IP covered under the following statements.
Type | Reference | Content |
---|---|---|
web | interact.example.org | address : https://interact.example.org/case-id/521039c3-4bb9-45bd-8271-6001d2f4dea9 |
web | fhir.example.org | address : https://fhir.example.org |
web | smarthealthit.org |
![]() |
web | smarthealthit.org |
IG © 2024+ HL7 International / FHIR Infrastructure
and Boston Children's Hospital
. Package hl7.fhir.uv.smart-health-cards-and-links#1.0.0 based on FHIR 4.0.1
. Generated 2025-07-22
Links: Table of Contents | QA Report | Version History | ![]() |
web | terminology.smarthealth.cards |
credentialValueSet
. Restricts the request by FHIR
content such as "any standardized vaccine code for mpox".
Any ValueSet MAY be used, but consider using ValueSets that are openly accessible in FHIR format to maximize the chance that the issuing server will be able to be recognize them. Examples of such ValueSets can be found at Health Card ValueSets
.
ValueSet-based filters apply to the FHIR Resources within the Health Card
payload at .vc.credentialSubject.fhirBundle.entry[].resource
. For
Immunizations, the Immunization.vaccineCode
is evaluated. For Observations,
the Observation.code
is evaluated. Multiple credentialValueSet
parameters
in one request SHALL be interpreted as a request for credentials with content
from all of the supplied ValueSets (logical AND).
|
web | terminology.smarthealth.cards | https://terminology.smarthealth.cards/ValueSet/immunization-orthopoxvirus-all |
web | fhir.example.org | https://fhir.example.org/Immunization/123 |
web | github.com | Significant API overhaul to reduce scope and simplify dependencies. See PR#64 for details. |
web | w3c.github.io | This document describes how clinical information, modeled in FHIR , can be presented in a form based on W3C Verifiable Credentials (VC). |
web | smarthealth.cards | Example VC payloads |
web | developer.mozilla.org |
Issuers SHALL publish their public keys as JSON Web Key Sets (see RFC7517
), available at <<iss value from JWS>>
+ /.well-known/jwks.json
, with Cross-Origin Resource Sharing (CORS)
enabled, using TLS version 1.2 following the IETF BCP 195
recommendations or TLS version 1.3 (with any configuration).
|
web | www.rfc-editor.org |
Issuers SHALL publish their public keys as JSON Web Key Sets (see RFC7517
), available at <<iss value from JWS>>
+ /.well-known/jwks.json
, with Cross-Origin Resource Sharing (CORS)
enabled, using TLS version 1.2 following the IETF BCP 195
recommendations or TLS version 1.3 (with any configuration).
|
web | terminology.smarthealth.cards |
The type
, and credentialSubject
properties are added to the vc
claim of the JWT. The type
values are defined in Credential Types
; the https://smarthealth.cards#health-card
SHALL be present; other types SHOULD be included when they apply. Verifiers and other entities processing SMART Health Cards SHALL ignore any additional type
elements they do not understand. The issuer
property is represented by the registered JWT iss
claim and the issuanceDate
property is represented by the registered JWT nbf
("not before") claim (encoded as the number of seconds from 1970-01-01T00:00:00Z UTC, as specified by RFC7519
). Hence, the overall JWS payload matches the following structure (before it is minified and compressed
):
|
web | terminology.smarthealth.cards |
SMART Health Card value sets, to further restrict the request by FHIR
content such as "any standardized vaccine code for mpox". See Health Card
ValueSets
.
Valueset-based filters apply to the FHIR Resources within the Health Card
payload at .vc.credentialSubject.fhirBundle.entry[].resource
. For
Immunizations, the Immunization.vaccineCode
is evaluated. For
Observations, the Observation.code
is evaluated.
|
web | github.com |
DEPRECATED
Chunking Larger SMART Health Cards
Deprecation note: As of December 2022, support for chunking has not been widely adopted in production SHC deployments. For SHCs that need to be presented as QRs, we recommend limiting payload size to fit in a single QR (when possible), or else considering SMART Health Links. Commonly, SMART Health Cards will fit in a single V22 QR code. Any JWS longer than 1195 characters SHALL be split into "chunks" of length 1191 or smaller; each chunk SHALL be encoded as a separate QR code of V22 or lower, to ensure ease of scanning. Each chunk SHALL be numerically encoded and prefixed with an ordinal as well as the total number of chunks required to re-assemble the JWS, as described below. The QR code FAQ page details max JWS length restrictions at various error correction levels. To ensure the best user experience when producing and consuming multiple QR codes:
|
web | github.com | For historical reference, past Requests for Comments related to SMART Health Cards can be found on this RFC page in the SMART Health Cards GitHub. |
web | vci.org | An individual receives a SMART Health Card from an issuer. For example, the issuer might be an organization authorized by the Verifiable Clinical Information coalition (VCI) to generate these cards, including pharmacies, hospitals, healthcare providers, medical labs, public health agencies, and more. |
web | smarthealth.cards | See the SMART Health Cards public landing page . |
web | github.com | The Health Cards Dev Tools can be used to validate the various Health Card artifacts. |
web | github.com | The code used to generate the examples present in the spec. |
web | github.com | A Jupyter Notebook walkthrough and demo portals which demonstrate creating, validating and decoding a SMART Health Card as a QR code. |
web | demo-portals.smarthealth.cards | A Jupyter Notebook walkthrough and demo portals which demonstrate creating, validating and decoding a SMART Health Card as a QR code. |
web | github.com | This RFC page in the SMART Health Cards GitHub contains RFCs related to SMART Health Cards. |
web | github.com | The Libraries for SMART Health Cards wiki page includes suggestions about useful libraries. |
web | cheatsheetseries.owasp.org | The issuer private keys must be generated, stored, and protected with great care, same as with PKI keys. The OWASP key management cheat sheet provides guidance on these items. To lower the risk of a key compromise, it is recommended to rotate issuance keys every year. |
web | cheatsheetseries.owasp.org | Anyone with access to the issuer private keys can issue health cards under the issuer’s identity. Make sure these are generated, stored, and protected adequately. The OWASP key management cheat sheet provide guidance on these items. To reduce the risk of insider threats, an issuer should have good audit practices, and log when a health card is issued, and by which employee. |
web | www.nayuki.io |
The first Byte mode segment ( shc:/
) always has 20 header bits and 40 data bits for a total of 60 bits.
1
|
web | www.nayuki.io | The second segment (the numeric encoded QR code) always has 16 header bits and a variable number of data bits depending on the QR code length. 1 |
web | www.qrcode.com | (Table Source) |
web | spec.smarthealth.cards | Each JWS character is encoded into two numeric characters (As described in Encoding Chunks as QR codes ) and each numeric character requires 20/6 bits. 1 |
web | www.nayuki.io | Each JWS character is encoded into two numeric characters (As described in Encoding Chunks as QR codes ) and each numeric character requires 20/6 bits. 1 |
web | www.nayuki.io | Project Nayuki: Optimal text segmentation for QR Codes |
web | www.qrcode.com | QR Code capacities |
web | www.who.int | On March 19th, 2021, the WHO released Interim guidance for developing a Smart Vaccination Certificate . Here are some key distinctions to keep in mind with respect to WHO RC1: |
web | smarthealthit.org | " SMART " in SMART Health Cards refers to the SMART Health IT project , and stands for " Substitutable Medical Applications, Reusable Technologies ". |
web | vci.org | WHO RC1 defines a data model for what should be included in a proof of vaccination. SMART Health Cards provides a similar data model via the SMART Health Cards: Vaccination & Testing Implementation Guide . The SMART IG aligns closely but not perfectly with WHO RC1 recommendations. Improving this alignment where possible is on the roadmap for the Vaccination & Testing Implementation Guide. |
web | smarthealth.cards | The consumer-facing SMART Health Cards site contains information oriented to patients. |
web | www.rfc-editor.org | IETF BCP 195 - Transport Layer Security (TLS) |
web | developer.mozilla.org | Cross-Origin Resource Sharing (CORS) |
web | viewer.tcpdev.org | SMART Health Link: https://viewer.tcpdev.org/shlink.html#shlink:/eyJ1cmwiOiJodHRwczovL3Jhdy5naXRodWJ1c2VyY29udGVudC5jb20vc2Vhbm5vL3NoYy1kZW1vLWRhdGEvbWFpbi9pcHMvSVBTX0lHLWJ1bmRsZS0wMS1lbmMudHh0IiwiZmxhZyI6IkxVIiwia2V5IjoicnhUZ1lsT2FLSlBGdGNFZDBxY2NlTjh3RVU0cDk0U3FBd0lXUWU2dVg3USIsImxhYmVsIjoiRGVtbyBTSEwgZm9yIElQU19JRy1idW5kbGUtMDEifQ |
web | viewer.tcpdev.org | SMART Health Link: https://viewer.tcpdev.org/shlink.html#shlink:/eyJ1cmwiOiJodHRwczovL3Jhdy5naXRodWJ1c2VyY29udGVudC5jb20vc2Vhbm5vL3NoYy1kZW1vLWRhdGEvbWFpbi9jYXJkcy9jYXJpbi1pbnN1cmFuY2UtZXhhbXBsZS9qd3MudHh0IiwiZmxhZyI6IkxVIiwia2V5IjoicnhUZ1lsT2FLSlBGdGNFZDBxY2NlTjh3RVU0cDk0U3FBd0lXUWU2dVg3USIsImxhYmVsIjoiRGVtbyBTSEwgZm9yIGNhcmluLWluc3VyYW5jZS1leGFtcGxlIn0 |
web | smarthealthit.org | Consider presenting the SMART Logo in close approximation with the QR. See the Boston Children's Hospital SMART Logo Page for details |
web | docs.aws.amazon.com |
location
(SHALL be present if no embedded
content is included): URL to the file. This URL SHALL be short-lived and intended for single use. For example, it could be a short-lifetime signed URL to a file hosted in a cloud storage service (see signed URL docs for S3
, Azure
, and GCP
).
|
web | learn.microsoft.com |
location
(SHALL be present if no embedded
content is included): URL to the file. This URL SHALL be short-lived and intended for single use. For example, it could be a short-lifetime signed URL to a file hosted in a cloud storage service (see signed URL docs for S3
, Azure
, and GCP
).
|
web | cloud.google.com |
location
(SHALL be present if no embedded
content is included): URL to the file. This URL SHALL be short-lived and intended for single use. For example, it could be a short-lifetime signed URL to a file hosted in a cloud storage service (see signed URL docs for S3
, Azure
, and GCP
).
|
web | developer.mozilla.org |
When the original QR includes the L
flag for long-term use, the client MAY
periodically poll for changes in the manifest. The server MAY provide a
Retry-After
header on successful manifest responses, indicating the minimum time that the
client SHOULD wait before its next polling request. If manifest requests are
issued too frequently, the server MAY respond with HTTP status 429 Too Many
Requests
and a Retry-After
header indicating the minimum time that a client
SHALL wait before re-issuing a manifest request.
|
CARIN_INS_CD-shl.png ![]() |
health-cards-conceptual.png ![]() |
issuer-generates-results.png ![]() |
qr-stack.png ![]() |
tree-filter.png ![]() |