Difference between revisions of "Smart Health Card"

Latest revision as of 15:16, 2 September 2025

Full Title or Meme

A (usually virtual) Smart Card containing at least some Identity and some Health Information, typically vaccination data,

The Smart Health Card is one of a series of SMART health specifications initiated by Boston Children's Hospital often with Harvard and other Boston hospitals.

Context

• What are SMART Health Cards? The (SHC) Web Site from Boston Children's Hospital.
• The primary context is the Kantara Health Care Profile.
• There is a commercial effort in Microsoft as part of VCI to take ownership of this term for the VCI that they belong to using DIDs. The SHC is structured like a Verifiable Credential using FHIR formatted data from HL7 EHRs, but there is no ability to give patients control of the data that is released from the SHC.

Design Goals

1. Support end-to-end workflow where users receive and present relevant healthcare data
2. Enable workflow with open standards
3. Support strong cryptographic signatures
4. Enable privacy preserving data presentations for specific use cases

Use Cases

• Authentication and Information Sharing occurs when a Relying Party scans or downloads the card and checks the user name and birthdate against other ID, like a driver's license.
• Apple iOS 15 can capture and share the Smart Health Card.
• Verifiable Health Records support for Apple EHR vendors describes that the SHC is included in the health app rather than in the wallet.

Included Token

The last couple of weeks have been big for SMART Health Cards and Links. They're now a formal HL7 standard and were featured in the CMS pledge as a requirement for patient-facing apps. Granted, it's not a perfect solution, but putting governance in the patient's hands and allowing sharing in the same way we share Google Docs makes a lot of sense to me. While Epic has a similar feature (Share Everywhere), as I understand it, it's limited to human (practitioner) viewing of the chart, requiring manual copying/pasting or exporting/importing which renders it next to useless on the interoperability front.

From my reading of the spec, not only do SMART Health Links contain structured data using the FHIR standard for EHR ingestion, they can also include a SMART Access Token, the same token returned from a classic SMART on FHIR app launch, allowing the receiving EHR to query and fetch what it needs directly from the source EHR.

With this in mind, I can imagine a flow with no patient portals: I finish my appointment at Provider A, they email me a summary along with a QR code, I rock up to my appointment at Provider B, present the QR code at check-in and then the Provider B EHR grabs the token and selectively pulls my records from Provider A with all the power of FHIR queries and without the hassle of patient matching. I'm not sure if this is the flow they envisioned, as details are sparse (and there are questions around security and PIN protection, etc.) but it sounds promising for a standard I haven't heard much about since COVID vaccine cards.

HL7 Spec: https://hl7.org/fhir/uv/smart-health-cards-and-links/

CMS Pledge: https://www.cms.gov/health-tech-ecosystem/early-adopters/kill-the-clipboard

COVID vaccine cards: https://www.thecommonsproject.org/newsroom/newsroom-press-release-the-commons-project-foundation-collaborates-with-google-to-introduce-smart-health-cards-for-android

Technical Details

• 2025-08-07 its now an official HL7 spec.
• Smart Health Card Technical Specs
• Github for smart health cards
• Github for smart health cards dev tools

The overall JWS payload matches the following structure (before it is minified and compressed):

{
 "iss": "<<Issuer URL>>",
 "nbf": 1591037940,
 "vc": {
   "type": [
     "https://smarthealth.cards#health-card",
     "<<Additional Types>>",
   ],
   "credentialSubject": {
     "fhirVersion": "<<FHIR Version, e.g. '4.0.1'>>",
     "fhirBundle":{
       "resourceType": "Bundle",
       "type": "collection",
       "entry": ["<<FHIR Resource>>", "<<FHIR Resource>>", "..."]
     }
   }
 }
}

Embedding in QR codes

• The Smart Health Card is typically embedded in a JWS (Signed JOSE) format with a header, payload and signature block for verification. While it can be transported in many media, the commonly used method is in a QR code displayed on paper in stored as a photo in a smart phone.
• Each JWS string that appears in the Verifiable Credential of a .smart-health-card file can be embedded in one or more QR codes. We aim to ensure that printed (or electronically displayed) codes are usable at physical dimensions of 40mmx40mm. This constraint allows us to use QR codes up to Version 22, at 105x105 modules. When embedding a JWS string in QR codes, the JWS string SHALL be encoded as Numerical Mode QR codes consisting of the digits 0-9 (see Encoding Chunks as QR codes).
• On iPhones the default behavior of scanning a QR Smart Health Card is to ask to store the VC in the Apple Wallet.
• WARNING the size recommended above can be scanned by modern (in 2021) smart phone with a high resolution camera, but cannot be resolved by most PC cameras or less expensive smart phones.

References

• Smart Health Card Example in typescript on Windows