SMART Health Cards: Vaccination & Testing Implementation Guide
0.5.0-rc - ci-build

SMART Health Cards: Vaccination &amp; Testing Implementation Guide, published by This is not an authorized publication; it is the continuous build for version 0.5.0-rc). This version is based on the current content of and changes regularly. See the Directory of published versions


NOTE This implementation guide is under active development on GitHub, and may change without notice. Please comment on or create an issue on GitHub if you have questions, comments, or suggestions. Contributions are welcome!


This FHIR Implementation Guide (IG):

  1. Describes the clinical information necessary to create a SMART Health Card identifying vaccination and laboratory testing status for infectious diseases such as COVID-19. In particular, it describes the content of the subject of a SMART Health Card in which the card types include, and/or, and optionally
  2. Describes a minimal set of patient information (name and contact information) that is also included in the SMART Health Card.

The goal of this IG is to constrain resources for use specifically in SMART Health Cards. This applies to the contents of both digital and paper Health Cards, including Health Cards produced via a Health Card-specific FHIR endpoint like [base]/Patient/:id/$health-cards-issue. This IG is not applicable to general-purpose FHIR endpoints like [base]/Patient/:id/Immunization, nor is it meant to describe the canonical representation of clinical data in electronic health record systems; these are governed by other IGs like US Core.

Note that this IG is not directly related to the SMART App Launch Framework. The name comes from SMART Health IT, who also developed the SMART Health Card framework that this IG supports. SMART App Launch and SMART Health Cards are designed to work well together (the former being one of multiple methods for issuing the latter), but they don’t have a hard dependency with each other.


The primary actors are:

  1. Issuers who produce the FHIR resources described in this IG. These may be the entities responsible for giving vaccinations or reporting laboratory results, including health systems, pharmacies, clinical labs, and doctors offices.
  2. Holders who receive a SMART Health Card from an Issuer (which contains the FHIR resources described in this IG), and may display it to a Verifier.
  3. Verifiers who read and analyze the FHIR resources described in this IG.

Issuers and Verifiers are considered “implementers” of this IG.

Use cases

Our primary focus is on the use case of representing the minimal set of clinical data necessary to represent COVID-19 vaccination status and laboratory testing for verification purposes in a SMART Health Card.

Due to the size constraints of the SMART Health Card payload, a “data minimization” profile is provided to supplement each of the “allowable data” profiles. Please see the Data minimization section for details.

Use case 1: vaccination credentials

To represent patient and clinical data related to a vaccination, the VaccinationCredentialBundle SHALL be used to wrap resources conforming to these profiles:

Profile: Allowable Data Profile: Data Minimization Purpose Required in bundle?
VaccinationCredentialPatient VaccinationCredentialPatientDM Identify the patient Exactly 1 required
VaccinationCredentialImmunization (COVID-19 with CVX) VaccinationCredentialImmunizationDM Describe a vaccination 1 or more required
VaccinationCredentialVaccineReactionObservation VaccinationCredentialVaccineReactionObservationDM Describe an adverse reaction to a vaccination Optional (experimental)
Bundle: VaccinationCredentialBundle Bundle: VaccinationCredentialBundleDM Bundle for wrapping the above resources n/a

Examples using these profiles:

Scenario 1: A patient receives two doses of the Moderna COVID-19 vaccine. The first dose was administered on January 1, 2021, and the second dose on January 29, 2021. See an example of a FHIR Bundle representing this.

Scenario 2: A patient receives two doses of the Pfizer-BioNTech COVID-19 vaccine. The first dose was administered on January 1, 2021, and the second dose on January 29, 2021. See an example of a FHIR Bundle representing this.

Use case 2: laboratory test result credentials

To represent patient and laboratory test result information, Covid19LaboratoryBundle or InfectiousDiseaseLaboratoryBundle SHALL be used to wrap resources conforming to these profiles:

VaccinationCredentialPatient VaccinationCredentialPatientDM Identify the patient Required
Covid19LaboratoryResultObservation Covid19LaboratoryResultObservationDM Identify the lab test and result Required
Bundles: Covid19LaboratoryBundle, InfectiousDiseaseLaboratoryBundle Bundles: Covid19LaboratoryBundleDM, InfectiousDiseaseLaboratoryBundleDM Bundle for wrapping the above resources n/a

An example using these profiles:

Scenario 3: A patient is tested for SARS-CoV-2 (COVID19) antigen via rapid immunoassay on February 17, 2021 with result detectable. See an example of a FHIR Bundle representing this.

A laboratory results profile specific to COVID-19 is provided to limit the code to a value set describing COVID-19-specific tests. Additional disease-specific profiles may be added in the future. To represent a disease without a specific set of profiles, implementers SHALL use InfectiousDiseaseLaboratoryResultObservation and InfectiousDiseaseLaboratoryResultObservationDM, which can be used with InfectiousDiseaseLaboratoryBundle.

Approach to constraints in profiles

The IG is currently focused on coordinating implementers’ representations of relevant clinical data, rather than evaluating risk or applying decision rules based on these clinical data. For example, this IG does not include information about which vaccine products are considered effective, or which dosing protocols are appropriate for a given product. The rationale for focusing on “conveying a clinical history” rather than “evaluating risk or making decisions” is:

  1. Risk evaluation algorithms are likely to evolve faster than IG constraints can be updated.

    For example, constraining the VaccinationCredentialImmunization profile to require specific vaccineCode values (e.g., only CVX#207 and CVX#208 for the current Moderna and Pfizer-BioNTech vaccines) could pose a problem if a new vaccine receives emergency authorization: recipients of the new vaccination would have non-conforming Immunization resources due to the constraints on vaccineCode until the IG could be updated and published.

  2. Risk evaluation algorithms may be actor- or context-dependent.

    For example, some parties may only consider FDA-approved or EUA vaccines to be acceptable, while others may accept vaccines approved in other countries.

    Embedding stringent validation criteria in our FHIR profiles may make it impossible for implementers with less stringent criteria to use this IG.

  3. More constrained profiles for risk evaluation can be created based on the profiles in this IG, but it’s not possible to remove constraints in a child profile.

  4. Cardinality constraints are applied to specific data elements in Allowable Data profiles when their inclusion (1) is does not support our use case and could harm patients; or (2) is contrary to our key design principles. For example, Patient.identifier is not allowed in resources conforming to VaccinationCredentialPatient as this may include a MRN or SSN, which would introduce a significant privacy risk for patients.

Approach to terminology bindings

Value set bindings for MustSupport elements are required, meaning that resources MUST use a code specified in the bound value set. This is to ensure implementers know which code systems can be expected to appear in a given element.

In general, the value sets used in these required bindings are as broad as possible. For example, in the VaccineProductCVX value set, all codes from the CVX code system are included (as opposed to defining a value set with just COVID-related CVX codes, for example).

In cases where disease-specific value sets exist, this IG may provide profiles with bindings to these restricted value sets (e.g., Covid19LaboratoryResultObservation) to help implementers identify the preferred subset of codes for that disease. However, in these cases, this IG will also provide generic equivalents to these profiles with broad value sets (e.g., InfectiousDiseaseLaboratoryResultObservation). Implementers MAY fall back to the generic version such profiles if the code they need is not part of the disease-specific value sets.

Identity assurance

The VaccinationCredentialPatient and Covid19LaboratoryBundle/InfectiousDiseaseLaboratoryBundle profiles include a mechanism for indicating level of identity assurance of the patient. This uses the IdentityAssuranceLevel value set in this format:

"meta": {
  "security": [{"system": "", "code": "IAL1.2"}]

Issuers SHALL populate these elements if identity assurance information is available.

Compatibility with IIS

Resources representing a vaccination and associated data should be able to be directly populated with data from IIS implementations using the HL7 v2.5.1 Implementation Guide for Immunization Messaging, Release 1.5.

Contact information

This FHIR Implementation Guide was developed as part of the Vaccination Credential Initiative. Please direct questions or comments to

MITRE: Approved for Public Release. Distribution Unlimited. Case Number 21-0225