Unattributed Code Systems

Copyright Fragment

This fragment is available on index.html

This publication includes IP covered under the following statements.

Copyright and Registered Trademark Uses

External References

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 | CC0 | Propose a change
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:
  • Producers of QR codes SHOULD balance the sizes of chunks. For example, if a JWS is 1200 characters long, producers should create two ~600 character chunks rather than a 1191 character chunk and a 9 character chunk.
  • Consumers of QR codes SHOULD allow for scanning the multiple QR codes in any order. Once the full set is scanned, the JWS can be assembled and validated.
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.

Internal Images

CARIN_INS_CD-shl.png
CARIN_INS_CD-shl.png
health-cards-conceptual.png
health-cards-conceptual.png
issuer-generates-results.png
issuer-generates-results.png
qr-stack.png
qr-stack.png
tree-filter.png
tree-filter.png