コンテンツにスキップ

プロトコル

この日本語ドキュメントについて

これは、SMART Health Cards Frameworkの日本語翻訳です。SMART Health Cardsの仕様を日本語で理解する助けとなることを目的に提供しているものです。最新の情報については、オリジナルのウェブサイトを参照してください。

概要

技術的でない概要について探していますか？

SMART Health Cards public landing pageを見てください。それ以外の場合は、技術仕様を読んでください。

ステータス

テクノロジー企業、研究所、薬局、電子的な健康記録、および免疫情報システムのベンダーからの意見をまとめて作成された最初の安定版のリリースです。

コントリビューション

変更を提案するには、GitHub Issuesを使うか、Pull Requestを送ってください。

はじめに

この実装ガイドでは、「Health Cards」のためのフレームワークを提供します。短期的な目標は、消費者がCOVID-19ワクチンや検査結果を受け取れるようにし、これらの結果を他のパーティに検証可能な方法で提示できるようにすることです。主なユースケースには、職場への復帰や旅行のために特定時点での感染状況を伝えることなどがあります。このアプローチは、免疫状態やその他の健康状態のドキュメントもサポートできるはずです。

私たちはエンドユーザーのプライバシーを保証しなければならず、Health Cardsは組織や管轄区域の境界を超えて機能する必要があるため、国際的な標準と分散型のインフラストラクチャを構築しています。

概念モデル

Figure

  • Issuer（たとえば、研究所、薬局、病院、EHR、公的な健康部門、免疫情報システムなど）は、検証可能な証明書を発行します。
  • Holderは、証明書を保管し、証明書を自由に提示します。
  • Verifierは、Holderから証明書を受け取り、適切に署名されていることを検証します。

設計の目標

  • 関連する医療データをユーザーが受け取って提示するエンド トゥ エンドのワークフローに対応すること
  • オープンスタンダードを使用したワークフローを可能にすること
  • 強力な暗号学的署名に対応すること
  • 特定のユースケースのためにプライバシーを保護するデータ表現を可能にすること

小さくはじめて、大きく考える

私たちは、ヘルスケアの様々な場所で利用できるビルディングブロックを定義することで、Health Cardsを実現します。コアとなるビルディングブロックを活用することで、私たちはデータを意味のあるまとまりに集約し、issuerは署名し、消費者は必要に応じて保管・提示ができるようになります。広範なユースケースとしては、最終的に次のようなものが可能になるかもしれません。

  • 学校や雇用者、旅行のために共有できる、免疫記録を管理する
  • 検証可能な健康履歴のデータを臨床研究で共有する
  • 公衆衛生機関と自主的なデータを共有する
  • 医療提供者とアンケートの回答を共有する

このスコープは広範ですが、私たちに必要な成功の短期的な定義は次のように定められます。

  • COVID-19の状態にフォーカスした「Health Wallet」内の「Health Cards」を提示すること
  • それぞれの役割（issuer、holder、アプリ）は、関連する信頼フレームワークに署名する限り、以下のオープンスタンダードに従うことでどんな組織でも実装できることを保証すること

ユーザーエクスペリエンスとデータフロー

  • ユーザーは、Health CardをIssuerから受け取ります。Health Cardは、ユーザーが以下のいずれかの手段で取得できる、署名されたデータアーティファクトです。
    • issuerは、Health CardをQRコードを含む書類またはPDFで提供する（必要な手段）
    • issuerは、Health Cardを.smart-health-cardファイルとしてダウンロードする手段を提供する（必要な手段）
    • issuer hosts a Health Card for FHIR API access via a compatible Health Wallet application. This workflow includes a SMART on FHIR authorization step with an Issuer, where the user grants read access to any resources that will be present in Health Cards (e.g., Patient, Immunization, Observation, DiagnosticReport) ユーザーにHealth Cards上に提示されるすべてのリソースへの読み取りアクセスを与える
  • ユーザーは、書類またはデジタルデータとしてHealth Cardを保存します。
  • ユーザーは、Health CardをVerifierに提示します。提示方法には、ユーザーの明示的なオプトインと承認があり、場合によっては、QRコードの提示、ファイルの共有、または、デバイス上のSDKの使用（たとえば、verifierからholderへのアプリ間通信のため）が関わる可能性があります。

信頼

Anyone can issue Health Cards, and every verifier can make its own decision about which issuers to trust. A "trust framework" can help verifiers to externalize these decisions and drive toward more consistent practices. The SMART Health Cards IG is designed to operate independent of any trust framework, while allowing trust frameworks to be layered on top. We anticipate such frameworks will emerge to meet different jurisdictional and use case driven requirements. In all cases, verifiers can discover public keys associated with an issuer via /.well-known/jwks.json URLs.

プライバシー

データの最小化

It is an explicit design goal to let the holder only disclose a minimum amount of information to a verifier. The information required to be disclosed is use-case dependent, and -- particularly in a healthcare setting -- it can be difficult for lay people to judge which data elements are necessary to be shared.

The granularity of information disclosure will be at the level of an entire credential (i.e., a user can select "which cards" to share from a Health Wallet, and each card is shared wholesale). The credentials are designed to only include the minimum information necessary for a given use case.

細粒度の共有

Data holders should have full control over the data they choose to share for a particular use-case. Since Health Cards are signed by the issuer and cannot be altered later, it is important to ensure that Health Cards are created with granular sharing in mind. Therefore, issuers SHOULD only combine distinct data elements into a Health Card when a Health Card FHIR profile requires it.

Additionally, Health Card FHIR Profiles SHOULD only include data that need to be conveyed together. (e.g., immunizations for different diseases should be kept separate. Immunizations and lab results should be kept separate.)

将来の検討事項

If we identify optional data elements for a given use case, we might incorporate them into credentials by including a cryptographic hash of their values instead of embedding values directly. Longer term we can provide more granular options using techniques like zero-knowledge proofs, or by allowing a trusted intermediary to summarize results in a just-in-time fashion.

データモデル

This framework defines a general approach to representing demographic and clinical data in FHIR, outlined in Modeling Verifiable Credentials in FHIR. Specific use cases for Health Cards will define specific data profiles.

プロトコルの詳細

暗号学的キーの生成と解決

Health Cards Frameworkでは、以下のキーの種類が使用されます。

  • Elliptic Curve keys using the P-256 curve

Health Cardsへの署名

  • Issuers sign Health Card VCs (Verifiable Credentials) with a signing key (private key)
  • Issuer publish the corresponding public key (public key) at /.well-known/jwks.json
  • Wallets and Verifiers use the public key to verify Issuer signatures on Health Cards

issuerと関連付けられたキーを特定する

Each public key used to verify signatures is represented as a JSON Web Key (see RFC 7517):

  • SHALL have "kty": "EC", "use": "sig", and "alg": "ES256"
  • SHALL have "kid" equal to the base64url-encoded SHA-256 JWK Thumbprint of the key (see RFC7638)
  • SHALL have "crv": "P-256, and "x", "y" equal to the base64url-encoded values for the public Elliptic Curve point coordinates (see RFC7518)
  • SHALL NOT have the Elliptic Curve private key parameter "d"
  • If the issuer has an X.509 certificate for the public key, SHALL have "x5c" equal to an array of one or more base64-encoded (not base64url-encoded) DER representations of the public certificate or certificate chain (see RFC7517). The public key listed in the first certificate in the "x5c" array SHALL match the public key specified by the "crv", "x", and "y" parameters of the same JWK entry. If the issuer has more than one certificate for the same public key (e.g. participation in more than one trust community), then a separate JWK entry is used for each certificate with all JWK parameter values identical except "x5c".

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).

The URL at <<iss value from JWS>> SHALL use the https scheme and SHALL NOT include a trailing /. For example, https://smarthealth.cards/examples/issuer is a valid iss value (https://smarthealth.cards/examples/issuer/ is not).

Signing keys in the .keys[] array can be identified by kid following the requirements above (i.e., by filtering on kty, use, and alg).

For example, the following is a fragment of a jwks.json file with one signing key: 

{
  "keys":[
    {
      "kty": "EC",
      "kid": "_IY9W2kRRFUigDfSB9r8jHgMRrT0w4p5KN93nGThdH8",
      "use": "sig",
      "alg": "ES256",
      "crv": "P-256",
      "x": "7xbC_9ZmFwKqOHpwX6-LnlhIh5SMIuNwl0PW1yVI_sk",
      "y": "7k2fdIRNDHdf93vL76wxdXEPtj_GiMTTyecm7EUUMQo",
    }
  ]
}

証明書

X.509 certificates can be used by issuers to indicate the issuer's participation in a PKI-based trust framework.

If the Verifier supports PKI-based trust frameworks and the Health Card issuer includes the "x5c" parameter in matching JWK entries from the .keys[] array, the Verifier establishes that the issuer is trusted as follows:

  1. Verifier validates the leaf certificate's binding to the Health Card issuer by:
    • matching the <<iss value from JWS>> to the value of a uniformResourceIdentifier entry in the certificate's Subject Alternative Name extension (see RFC5280), and
    • verifying the signature in the Health Card using the public key in the certificate.
  2. Verifier constructs a valid certificate path of unexpired and unrevoked certificates to one of its trusted anchors (see RFC5280).

キーの管理

Issuers SHOULD generate new signing keys at least annually.

When an issuer generates a new key to sign Health Cards, the public key SHALL be added to the issuer's JWK set in its jwks.json file. Retired private keys that are no longer used to sign Health Cards SHALL be destroyed. Older public key entries that are needed to validate previously signed Health Cards SHALL remain in the JWK set for as long as the corresponding Health Cards are clinically relevant. However, if a private signing key is compromised, then the issuer SHALL immediately remove the corresponding public key from the JWK set in its jwks.json file and request revocation of all X.509 certificates bound to that public key.

Issuerが結果を生成する

When the issuer is ready to generate a Health Card, the issuer creates a FHIR payload and packs it into a corresponding Health Card VC (or Health Card Set).

sequenceDiagram participant Holder participant Issuer note over Holder, Issuer: Earlier... Issuer ->> Issuer: Generate Issuer's keys Issuer ->> Issuer: If Health Card data for holder already exist: re-generate VCs note over Issuer, Holder: Data Created Issuer ->> Issuer: Generate FHIR Representation Issuer ->> Issuer: Generate VC Representation Issuer ->> Issuer: Generate JWS Payload and sign note over Issuer, Holder: Later... Issuer ->> Holder: Holder receives Health Card

Health CardsはCompact Serialization JSON Web Signatures（JWS）としてエンコードされる

The VC structure (scaffold) is shown in the following example. The Health Cards framework serializes VCs using the compact JWS serialization, where the payload is a compressed set of JWT claims (see Appendix 3 of RFC7515 for an example using ECDSA P-256 SHA-256, as required by this specification). Specific encoding choices ensure compatibility with standard JWT claims, as described at https://www.w3.org/TR/vc-data-model/#jwt-encoding.

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 RFC 7519). Hence, 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>>", "..."]
      }
    }
  }
}

Health Cardsはサイズが小さい

To ensure that all Health Cards can be represented in QR codes, issuers SHALL ensure that the following constraints apply at the time of issuance:

  • JWS Header
    • header includes alg: "ES256"
    • header includes zip: "DEF"
    • header includes kid equal to the base64url-encoded SHA-256 JWK Thumbprint of the key (see RFC7638)
  • JWS Payload
    • payload is minified (i.e., all optional whitespace is stripped)
    • payload is compressed with the DEFLATE (see RFC1951) algorithm before being signed (note, this should be "raw" DEFLATE compression, omitting any zlib or gz headers)
    • payload .vc.credentialSubject.fhirBundle is created:
      • without Resource.id elements
      • without Resource.meta elements (or if present, .meta.security is included and no other fields are included)
      • without DomainResource.text elements
      • without CodeableConcept.text elements
      • without Coding.display elements
      • with Bundle.entry.fullUrl populated with short resource-scheme URIs (e.g., {"fullUrl": "resource:0"})
      • with Reference.reference populated with short resource-scheme URIs (e.g., {"patient": {"reference": "resource:0"}})

For details about how to embed Health Cards in a QR code, see below.

UserがHealth Cardsを取得する

In this step, the user learns that a new Health Card is available (e.g., by receiving a text message or email notification, or by an in-wallet notification for FHIR-enabled issuers.)

ファイルのダウンロードによる方法

To facilitate this workflow, the issuer can include a link to help the user download the credentials directly, e.g., from a login-protected page in the Issuer's patient portal. The file SHALL be served with a .smart-health-card file extension and SHALL be provided with a MIME type of application/smart-health-card (e.g., web servers SHALL include Content-Type: application/smart-health-card as an HTTP Response containing a Health Card), so the Health Wallet app can be configured to recognize this extension and/or MIME type. Contents should be a JSON object containing an array of Verifiable Credential JWS strings:

{
  "verifiableCredential": [
    "<<Verifiable Credential as JWS>>",
    "<<Verifiable Credential as JWS>>"
  ]
}

QRコードによる方法（印刷またはスキャン）

Alternatively, issuers can make any individual JWS inside a Health Card available embedded in a QR code (for instance, printed on a paper-based vaccination record or after-visit summary document). See details.

Finally, the Health Wallet asks the user if they want to save any/all of the supplied credentials.

FHIR $health-cards-issue Operationによる方法

For a more seamless user experience when FHIR API connections are already in place, results may also be conveyed through a FHIR API $health-cards-issue operation defined here. For issuers that support SMART on FHIR access, the Health Wallet MAY request authorization with SMART on FHIR scopes (e.g., launch/patient patient/Immunization.read for an Immunization use case). This allows the Health Wallet to automatically request issuance of VCs, including requests for periodic updates.

FHIRサポートの検出

A SMART on FHIR Server capable of issuing VCs according to this specification SHALL advertise its support by adding the health-cards capability to its /.well-known/smart-configuration JSON file. For example:

{
  "authorization_endpoint": "https://ehr.example.com/auth/authorize",
  "token_endpoint": "https://ehr.example.com/auth/token",
  "token_endpoint_auth_methods_supported": ["client_secret_basic"],
  "scopes_supported": ["launch", "launch/patient", "patient/*.*", "offline_access"],
  "response_types_supported": ["code", "code id_token", "id_token", "refresh_token"],
  "capabilities": ["health-cards", "launch-standalone", "context-standalone-patient", "client-confidential-symmetric"]
}

$health-cards-issue Operation

A Health Wallet can POST /Patient/:id/$health-cards-issue to a FHIR-enabled issuer to request the generation of a specific type of Health Card. The body of the POST looks like:

{
  "resourceType": "Parameters",
  "parameter": [{
    "name": "credentialType",
    "valueUri": "https://smarthealth.cards#covid19"
  }]
}

The credentialType parameter is required. Multiple credentialType values in one request SHALL be interpreted as a request for the intersection of the requested types (logical AND). For example, a request containing credentialType values https://smarthealth.cards#covid19 and https://smarthealth.cards#immunization is a request for only those cards that are both COVID-19 cards and immunization cards (i.e., only those COVID-19 cards that are about immunizations).

The following parameters are optional; clients MAY include them in a request, and servers MAY ignore them if present.

  • includeIdentityClaim. By default, the issuer will decide which identity claims to include, based on profile-driven guidance. If the Health Wallet wants to fine-tune identity claims in the generated credentials, it can provide an explicit list of one or more includeIdentityClaims, which will limit the claims included in the VC. For example, to request that only name be included:
{
  "resourceType": "Parameters",
  "parameter": [{
    "name": "credentialType",
    "valueUri": "https://smarthealth.cards#covid19"
  }, {
    "name": "includeIdentityClaim",
    "valueString": "Patient.name"
  }]
}
  • _since. By default, the issuer will return Health Cards of any age. If the Health Wallet wants to request only cards pertaining to data since a specific point in time, it can provide a _since parameter with a valueDateTime (which is an ISO8601 string at the level of a year, month, day, or specific time of day using the extended time format; see FHIR dateTime datatype for details). For example, to request only COVID-19 data since March 2021:
{
  "resourceType": "Parameters",
  "parameter": [{
    "name": "credentialType",
    "valueUri": "https://smarthealth.cards#covid19"
  }, {
    "name": "_since",
    "valueDateTime": "2021-03"
  }]
}

The response is a Parameters resource that includes one more more verifiableCredential values like:

{
  "resourceType": "Parameters",
  "parameter":[{
    "name": "verifiableCredential",
    "valueString": "<<Health Card as JWS>>"
  }]
}

If no results are available, a Parameters resource without any parameter is returned:

{
  "resourceType": "Parameters"
}

In the response, an optional repeating resourceLink parameter can capture the link between any number of hosted FHIR resources and their derived representations within the verifiable credential's .credentialSubject.fhirBundle, allowing the health wallet to explicitly understand these correspondences between bundledResource and hostedResource, without baking details about the hosted endpoint into the signed credential. The optional vcIndex value on a resourceLink can be used when a response contains more than one VC, to indicate which VC this resource link applies to. The vcIndex is a zero-based index of a verifiableCredential entry within the top-level parameter array.

{
  "resourceType": "Parameters",
  "parameter": [{
    "name": "verifiableCredential",
    "valueString": "<<Health Card as JWS>>"
  }, {
    "name": "resourceLink",
    "part": [{
        "name": "vcIndex",
        "valueInteger": 0
      }, {
        "name": "bundledResource",
        "valueUri": "resource:2"
      }, {
        "name": "hostedResource",
        "valueUri": "https://fhir.example.org/Immunization/123"
    }]
  }]
}

Health CardsをVerifierに提示する

In this step, the verifier asks the user to share a COVID-19 result. A Health Card containing the result can be conveyed by presenting a QR code; by uploading a file; or by leveraging device-specific APIs. Over time, we will endeavor to standardize presentation workflows including device-specific patterns and web-based exchange.

すべてのHealth CardはQRコードに埋め込める

Each JWS string that appears in the .verifiableCredential[] 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").

Ensuring Health Cards can be presented as QR codes:

  • Allows basic storage and sharing of Health Cards for users without a smartphone
  • Allows smartphone-enabled users to print a usable backup
  • Allows full Health Card contents to be shared with a verifier

The following limitations apply when presenting Health Card as QR codes, rather than engaging in device-based workflows:

  • Does not capture a digital record of a request for presentation
  • Verifier cannot include requirements in-band
  • Verifier cannot include purposes of use in-band
  • Does not capture a digital record of the presentation

Health Card JWSからQRコード（または複数のQRコードセット）を生成する

チャンク化

Commonly, 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.

チャンクをQRコードとしてエンコードする

When printing or displaying a Health Card using QR codes, let "N" be the total number of chunks required, and let "C" be a variable indicating the index of the current chunk. Each chunk of the JWS string value SHALL be represented as a QR with two data segments:

  1. A segment encoded with bytes mode consisting of
    • the fixed string shc:/ (registered as an IANA scheme)
    • plus (only if more than one chunk is required)
      • decimal representation of "C" (e.g., 1 for the first chunk, 2 for the second chunk, and so on)
      • plus the fixed string /
      • plus decimal representation of "N" (e.g., 2 if there are two chunks in total, 3 if there three chunks in total, and so on)
      • plus the fixed string /
  2. A segment encoded with numeric mode consisting of the characters 0-9. Each character "c" of the JWS is converted into a sequence of two digits as by taking Ord(c)-45 and treating the result as a two-digit base ten number. For example, 'X' is encoded as 43, since Ord('X') is 88, and 88-45 is 43. (The constant "45" appears here because it is the ordinal value of -, the lowest-valued character that can appear in a compact JWS. Subtracting 45 from the ordinal values of valid JWS characters produces a range between 00 and 99, ensuring that each character of the JWS can be represented in exactly two base-10 numeric digits.)

(The reason for representing Health Cards using Numeric Mode QRs instead of Binary Mode (Latin-1) QRs is information density: with Numeric Mode, 20% more data can fit in a given QR, vs Binary Mode. This is because the JWS character set conveys only log_2(65) bits per character (~6 bits); binary encoding requires log_2(256) bits per character (8 bits), which means ~2 wasted bits per character.)

For example:

  • a single chunk might produce a QR code like shc:/56762909524320603460292437404460<snipped for brevity>
  • in a longer JWS, the second chunk in a set of three might produce a QR code like shc:/2/3/56762909524320603460292437404460<snipped for brevity>

When reading a QR code, scanning software can recognize a SMART Health Card from the shc:/ prefix. Stripping this prefix and the following <ordinal>/<count>/ and decoding the remaining pairs of numerals yields a JWS.

よくある質問

SMART Health Cardは、身分証明書の形式として利用できますか？

No. SMART Health Cards are designed for use alongside existing forms of identification (e.g., a driver's license in person, or an online ID verification service). A SMART Health Card is a non-forgeable digital artifact analogous to a paper record on official letterhead. Concretely, the problem SMART Health Cards solve is one of provenance: a digitally signed SMART Health Card is a credential that guarantees that a specific issuer generated the record. The duty of verifying that the person presenting a Health Card is the subject of the data within the Health Card (or is authorized to act on behalf of this data subject) falls to the person or system receiving and validating a Health Card.

意思決定ではどの医療データが考慮されるべきですか？

  • The data in Health Cards should focus on communicating "immutable clinical facts".
  • Each use case will define specific data profiles.
  • When Health Cards are used in decision-making, the verifier is responsible for deciding what rules to apply. For example:
    • decision-making rules may change over time as our understanding of the clinical science improves.
    • decision-making rules may be determined or influenced by international, national and local health authorities.
    • decision-making rules may require many inputs, some of which can be supplied by Health Cards and others of which may come from elsewhere (e.g., by asking the user "are you experiencing any symptoms today?").

臨床結果を共有する代わりに「Safe-to-fly Pass」のような結論を共有するにはどうすればいいですか？

Decision-making often results in a narrowly-scoped "Pass" that embodies conclusions like "Person X qualifies for international flight between Country A and Country B, according to Rule Set C". While Health Cards are designed to be long-lived and general-purpose, Passes are highly contextual. We are not attempting to standardize "Passes" in this framework, but Health Cards can provide an important verifiable input for the generation of Passes.

SMART Health Cardsの実装を検証できるテストツールはありますか？

以下のようなHealth Cardアーティファクトの検証に役に立つツールがあります。

Other resources that are helpful for learning about and implementing SMART Health Cards include:

SMART Health Cardsと協調できるソフトウェアライブラリはありますか？

Libraries for SMART Health Cardsというwikiページに、便利なライブラリのおすすめがあります。

Potential Extensions

Standardized presentation workflows

The spec is currently focused on representing Health Cards in a standardized data payload. This allows many simple patterns for sharing, but future work can introduce standardized presentation exchange flows (e.g., OpenID Self-Issued Identity Provider, a.k.a. SIOP)

リファレンス