VCI Call Notes

February 24, 2021

Spec Updates

Testing Tools

  • Teams working on some tools
  • Want to have some examples to share by the end of next week in time for the next technical work group meeting
  • Tools for checking payload size (warnings if its too big), checking signatures and shape of data, FHIR resource profile conformance

FHIR Profiling Updates

  • Data Minimization
    • Adding a second set of profiles on top of the initial set to easily check to see if they are creating resources with extra information
    • Branch with those is up, but it hasn't been reviewed by anyone on the team yet. Link will be shared on Zulip soon for others to give feedback on
  • Creating an excel representation of the fields for easier review
    • Expecting to finish this in the next few days and available for the next meeting
  • Please let us (mmasnick@mitre.org :)) know if you are interested in collaborating or reviewing!
  • HL7 Ballot Process
    • Want to get input from the work groups early in the process
    • Some on-going discussion about whether project proposal should be scoped for FHIR IG only or also include SMART Health Cards
      • Public Health Work Group meeting tomorrow
    • Planning to discuss at HL7 Work Group Tomorrow

Q: Will the data minimization profiles ensure that resources are small enough to fit in the QR Code?
A: These profiles are partly driven by that requirement, but its possible they could still be too large and make no gaurantees

Q: HL7 process will be slow. Should we be waiting before implementing this now?
A: No. We want to continue implementing and will use the HL7 process to get more feedback.

Q: Want to have a stable point to work towards. Can we mark the spec as an interim release to work towards to make it clear what we are working towards. Expecting a lot of feedback from the balloting process and we don't want to have make weekly dev updates
A: Think about the HL7 process as a separate process. We want to get to a prototype stage with what we have now

Q: When would be a good time to talk about WHO (I might have this wrong). When the convergence happens when will it and how will that happen. What's the roadmap?
A: Have a smaller group have a tactical discussion about how these multiple initiatives will converge and come together. This group will be one critical mass to show that. VCI's advantage right now is having the right set of players participating in a focused way.

Updates from Manu
Mattr has published a vaccination certificate using W3Cs. Currently being circulated at WHO. Some assumption that HL7 will happen in the background for this. They ar missing the FHIR piece, but have good representation.

Wallet Holder/App Updates

  • One wallet app:
    • able to scan and consume QR codes
    • Can verify QR codes as they come in
    • Basic allow list of issuers
    • Future work along the lines of a broader trust framework or potentially key caching
    • End of next week expecting development version working end to end on the open source sandbox (https://github.com/smart-on-fhir/health-cards-tests)

Broader Q/A and discussions based on chat.fhir

Q: (hard to hear) but curious how location will be used? Can have a location hierarchy (organization, building, floor, etc.) which will blow up payload size. How do we want to handle this (textual representation maybe)?
A: Lets create some examples and post to chat.fhir.org which we can look at discuss and test with some of the tools for bundle splitting/size.

February 10, 2021

Review spec proposal #64

https://github.com/smart-on-fhir/health-cards/pull/64

Were slides being shown available?

Vaccination IG

Vaccination IG update/discussion topics (https://github.com/dvci/vaccine-credential-ig/issues):

  1. We are planning to create "data minimization" profiles as a counterpart to each of the existing profiles. The "DM" profiles will use cardinality to exclude any elements that SHOULD NOT be populated. Issuers will be directed to attempt conforming to the DM profiles first, and fall back to the "allowable" profiles (i.e., the existing profiles) if they can't conform to the DM one for some reason. (#42)
    • We would like feedback from potential Issuers and Verifiers when we get the first draft of these done.
  2. We are planning to clarify the scope of the IG to say that it represents what should be in the bundle inside the health card. This is in contrast to specifying what we expect to come out of FHIR endpoints…this very well may be what happens for some issuers, but we're not dictating that. (#43)
  3. We are planning to add support for PCR and serology lab tests, and if possible additional COVID-related lab tests. (#44)
  4. Timeline: finish #42 along with the other smaller currently open issues in the next 2 weeks, and then start on #44 over the 2 following weeks. Anyone who wants to contribute to the IG to help accelerate this timeline is welcome.
  5. We are also discussing HL7 balloting, which MITRE is planning to take the lead on. More details on this to come.

January 27, 2021

New Participant Perspectives

  • Mobile platform vendor looking at support
  • VC specification, DID specification editor, W3C perspective
  • Covid Credentials Initiative perspective
  • Informatics, clinical perspective

FHIR Profiling Work

Rendered profile available at http://build.fhir.org/ig/dvci/vaccine-credential-ig/branches/main/ (this is from the FHIR CI build; source is at https://github.com/dvci/vaccine-credential-ig)

Basic examples for 2 vaccines. Already received some feedback that got incorporated.

Where we're at now: Would like to beef up and solidify use cases more. Want to be driven by the use cases. Want to have the examples and directions to implementers indicate that the minimum number of elements should be populated when providing the data as a credential. Working on flagging key elements as must support and working through some other minimal issues.

Some tension between data minimization perspective and paylaod size and completeness (e.g., for public health tracking vs proof of immunization)

TODOs for the group:

  • Use GitHub Issues for discussion and giving feedback. Many people working on this and that is the best way to keep everyone in the loop.
  • Review use cases and share feedback

Q. Do we have decisions on VC, formats, serialization, signaturesetc?
A. These are documented in the SMART Health Cards specification

Note: we should try to preempt confusion about layers / IGs here; between the Health Cards IG and the FHIR Data Profiles IG.

  • Details about protocols, credential requests, responses, principles, and overall system architecture belongs in SMART Health Cards;
  • Data profiling decisions belong in the Vaccine Credential IG

Naming suggestion: might call https://github.com/dvci/vaccine-credential-ig the "SMART Health Cards Immunization Data Profile"? Or something else that'll make the connection more discoverable / clear, especially for newcomers – and so we can adopt consistent naming conventions on new projects.

Q. Should we be introducing new Digital Wallet implementers, including companies funded by Department of Homeland Security focused on interop?

(sorry, my editor is flipping out and I think I just deleted content. -JM)

A> cQ./(A.) How can we better define the roles played as part of health cards VCI? Want to be able to point organizations to a spec and make it clear what role they play and how to implement it.

Q. How will the trust network be handled and defined?

A. This is still in discussion, but not being directly tackled by VCI right now. Want to generalize that process so that options are available, but not necessarily define a specific approach or system.

Q. Any consideration on Interop Test Suite. DHS efforts are concerned with this.
A. No. This will be important to have on the roadmap so that organizations can test whether they are interoperable. Currently have some test endpoints here

Q. What is the current interop with existing paper-based credentials?
A. There's early work and discussion on this front; will plan to report back next week.

Q. Are there scenarios where issuers would issue a VC for an immunization that they did not administer (e.g., where they're not a primary source?)

A. We need to account for this. e.g. an immunization registry may provide VCs even though they are not the administrator of the vaccine. Verifiers could decide whether they accept VCs from these sources. Immunization registries could be the best source of truth.

Q. Are we trying to convey conclusions about whether someone has received a full course of immunizations? Or CDS recommendations about when a next dose is due? Or risk evaluations about whether someone is safe to fly?
A. No, we're focused on discrete clinical facts about doses.

January 20, 2021

New Participant Perspectives

  • Immunization Information System
  • Consumer-facing immunization access
  • Augmenting vaccination cards with paper-based records
  • Trust Over IP

Q. Roles and TODOs?

Can we outline the different roles that participants will want to focus on? Issuers, consumer/holder apps, and verifiers?

To start, we've been relatively more focused on issuance and less focused in verification.

Would be good to share notes at https://chat.fhir.org and let folks know what you're working on, so we can build up a better idea of whom to contact with questions on specific topics.

Where are the artifacts? How do I get started?

Could you share the Git? or the health wallet website?

What are thoughts about offline presentation/verification

https://github.com/smart-on-fhir/health-cards/discussions/33 lays out what we have so far (short story: not much; this hasn't been an early focus but we think it's important to tackle and would love help)

How is data profiling coming?

WIP; not much to share since last week, but will work on examples. https://github.com/microsoft-healthcare-madison/health-wallet-demo/blob/master/src/fixtures/vc-covid-immunization.json has one early example.

Can we ensure this approach works for lab results as well as Immunizations?

We're focused on immunizations but the underlying tech is meant to be agnostic. We need to decide whether we'll produce specific lab-related FHIR profiles; certainly this would be helpful for EHR participants.

We might benefit from focus here and not go into detail on test results. Let's make sure that we're covering Immunization records well and not expand scope unneccessarily.

  • A single health card shouldn't mix immunizations and labs
  • A single health card can contain >1 immunization record (e.g. >1 dose of the vaccine)
  • Verifiers should be able to accept data split across >1 health card

MIT / IDEO work on paper based records

  • http://tiny.cc/mitvax

  • Josh would like to follow up to understand how high-densitive info is conveyed (e.g., would we communicate full health card content, or are these summaries?)

When will we have stable or milestone builds for FHIR profiles?

Should we be using FHIR R4 or DSTU2?

Decision: After detailed discussion we've decided to use FHIR R4 or VCI profiles and examples.

Contactless Verification

Using things like NFC, WiFi Channels, etc.

  • VCI itself hasn't focused on this other than QR codes for a paper presentation. VCI wants to focus on one thing or a very small set of things

Q: has there been any effort on accreditation or HIPAA compliance
A: No. Not sure there is a generic helpful answer to this. For HealthCards, IDs do not need to be anchored on the blockchain.

Extended Discussion on paper cards

  • Difficult to revoke paper cards.
    • Could mark that cards are only valid for a certain time
    • Could point to an online resource that could be verified
  • Challenges around dealing with both online and offline systems
    • What happens when data gets updated?
  • Challenge with offline is that it is less lucrative
    • Can't charge per scan, etc.
    • Governments and others will want to know how it is used. Are healthcare workers using it? Where are they using it? Could there be an audit to get this information eventually?
  • In many places they will be used for non-standard access
    • e.g. real id or social security numbers are used for other purposes
  • Biometrics and tamper-proof paper to prevent forging
    • We've now created a new high value asset that has value
    • May have value in other use cases based on the creation of that identity assest alone
    • The value proposition goes beyond the vaccination credential itself
    • There is a double edged sword in expanding what the identity is used for
      • Knowing who the patient is vs knowing that it is the same patient
      • Having a multiple identities can be useful to help separate (e.g. want to know who they are as a patient, but not link to their banking identity)
        • (Sounds like self-soverign identity!)
      • Once something like this is provided to a community it is likely that it will be used for non-standard purposes
    • Holder could be offline and Verifier could be offline or both
      • Defining offline can be tricky. e.g. you could get off a plane in Mexico and your phone is offline
  • Threats to VCI
    • malicious issuer providing credentials and no easy way to revoke and manage
    • Difficult to handle in only paper based solutions
      • Biometric & tamper-proof paper helps, but drives up cost
      • What other ways are there to handle this?
      • Offline verifiers may be able to cache trusted issuers

January 13, 2021

(We'll leave out names / specific companies from these notes, and try to capture technical discussion and decisions.)

New participants include

  • Federal stakeholders looking at consumer data access
  • New VCI participants looking at deploying these technologies in the developing world

From last time…

Action item was for participants to review specs, and come back with 1) questions, and 2) plans for what they might prototype.

  • If you're working on a prototype, email JP so we can add you to the right stream on https://chat.fhir.org.

Open Q&A

Q. Are we using #smart on chat.fhir.org?

A. We might use a smaller "internal" channel if folks are more comfortable. Email JP to make sure you're included.

Q. How is dosage information captured in Health Cards?

A. This is part of our FHIR profiles. We'll start with FHIR US Core Immunizations, but want to understand if there are specific questions on top of those profiles. There are some draft profiles on github at https://github.com/dvci/vaccine-credential-ig (CI Build is at: http://build.fhir.org/ig/dvci/vaccine-credential-ig/branches/main/) but we need to understand requirements better. We want to understand whether there are needs for value sets, extensions, etc. We can add a profiling topic on Zulip for further discussion.

Q. When retrieving a VC via some method other than $HealthWallet.issueVc, how
will the account holder be authorized?

A. The authorization is out of band; e.g., you can send a portal link, where the user first authenticates and then is given the chance to download a VC. Or you can collect a PIN and DOB at vaccination time, and provide a web interface to return the data later when these are supplied. The details are out of band. If you want, you can link to a user's DID (via the did-siop flow), but this isn't a required step.

Q. So it'd be OK to require portal authentication?

A. Yes. If you support SMART on FHIR, you should only have the user sign in once, at app approval time (not a 2nd time when $HealthWallet.issueVc is called). But if you don't support SMART on FHIR, you should set the rules about when/how to do this.

Q. Can we update the spec to say "issuers must support either FHIR API-based issuance, or file download" but can choose to pick just one"?

A. Initially we focused on file downloads because not all users will have access to a FHIR client. Ideally clients would support retrieving Health Cards using both methods, and issuers need to support at least one of these methods.

January 6, 2021

JP Presents a High-level Workflow Slide (end-to-end example)

  • A Vaccine Record Holder (e.g., pharmacy, health system, or registry)

    • maintains records
    • provides a mechanism to issue health cards based on these records (e.g., through a patient portal or other channel)

  • A Digital Health Wallet app (e.g., securely on a personal device)

    • Download Health Cards from the record holder (via file download; API; SMS links; etc)
    • Store Health Cards securely on device
    • Share Health Cards with other apps and serviecs, when consent is given

  • Any 3rd Party Apps can request Health Cards from the Digital Health Wallet

    • Apps can send Health Cards along to a relying party (e.g., a ticket agent or workplace security guard) who inspects the Health Card
    • Alternatively, apps can use an SDK (e.g., Common Pass SDK) to read the Health Cards and generate a summary result ("pass") evalauting whether a specific set of rules is met (e.g, generating a "pass" if the user's Health Cards demonstrate compliance with a specific airline's "OK to Fly" rules)

  • At the end of this flow, Relying Parties make decisions based on the health cards, or based on "passes" created from the health cards. Sometimes this evaluation includes checking the user's real-world identity (e.g., comparing the demographics from a driver's license with the demographics in a health card)

How is identity managed and authenticated?

  • Want it to be designed to work well with existing identity systems
    • Package of FHIR information that contains the clinical and identity information
      • Clinical information would be things like Immunization Records
      • Identity information would be things like a Patient resource

(Thanks for the help! I can't talk and type at the same time ;-))

How can data be combined with a Health Card if the card is "signed and sealed"?

In general, decisions can be made based on multiple sources of input. Like, if a workplace app is going to use health cards to make a decision about who can access a specific facility, it might use Health Cards as an input, and then combine these with other details like an employee id to generate a new verifiable credential (derived from the Health Card, but created independently). This kind of thing can be very practical, but happens downstream of the health card generation/sharing, and can include a "break" in the chain of trust (like, if a 3rd-party app is generating its own pass, relying parties need to trust how that pass is generated).

It's helpful to draw a bright line between what the Health Cards spec allows, and the various ways Health Cards can be used, augmented, or summarized downstream. We never "append" data to a Health Card, but the data from a health card can be used in combination with other data to create new downstream artifacts.

From VCI perspective, the creation of a "pass" (as with the CommonPass SDK) is a practical downstream use of Health Cards, but it's not part of what we're trying to standardize.

What are the boundaries between PHI and PII, and how does this impact design?

The original record holder has (and needs) no relationship with relying parties, no BAAs required, etc. This all flows through a consumer's right of access.

When a relying party uses the CommonPass SDK, what is the flow of trust?

If the relying party trusts CommonPass to generate correct data, then the chain of trust can simply be "Relying Party trust CommonPass directly" – but this is a decision that relying parties can each make for themselves.

The Trust Model

The spec defines a trust model where a relying party that receives a Health Card can ensure that the Health Card has not been tampered with (on its journey from the issuer to the wallet to the relying party). If a specific relying party wants to outsource this job (to an app like CommonPass), that's fine, but that's a decision that each relying party needs to make on its own (and if you make this decision, you lose the ability to validate the "raw data" back to the issuer).

The trust model itself is out of scope for the spec. Apps may act as a black box, which do not need to be trusted or involved in trusting others. Apps may also be involved in creating their own health cards, e.g. to prevent apps (like an airline app) from having to manage health data and would then need to be trusted by any relying party.

^^ Correction: we're trying to make a distinction between a "Health Card" (which has immutable clinical data together with identity claims) vs a "pass" or "summary" (which might be generated by a 3rd party SDK or app, and which inserts a break in the chain of trust). (Is this clear?)

yup thanks! feel free to edit/remove my section

I think the discussion's good to capture; happy to leave it in. Sounds good to me (its helping me learn at least :))

Specific (Hypothetical) Example: Android user booking a flight on Delta Airlines

  • Delta Airlines decides to use CommonPass SDK
  • While booking a flight, user sees a prompt to share COVID-19 lab or immunization data
  • Starting from this prompt, user is guided to download a Health Card into CommonHealth Android app from a local healthcare provider (Note: this only works if the user actually has a relevant
    Health Card available to them from some Vaccine Record Holder    )
  • Health Card is shared on-device into the Delta app, where the CommonPass SDK checks that the data indicates the user meets Delta's policy
  • Based on this CommonPass SDK result, Delta augments the user's boarding pass with a badge + database flag indicating conditions are met
  • For future flights, some of these steps can be skipped, if user agrees to share data for a longer term

Getting a Second COVID Vaccine Dose

Right now if you receive a COVID-19 vaccine you'll get a vaccine card. When the second dose is received would that be provided as a second distinct health card (where you would have two health cards) or would a new health card containing both be issued

  • Relying parties should be robust and be able to handle either approach. i.e. One health card containing multiple immunization records or multiple health cards.

FHIR Immunization resource has a field for indicating whether it is the first or second dose (FHIR R5 changed this field from an integer to string because it is not expected to be computable). This shouldn't be relied on to identify whether an immunization is actually the first or second dose. The date the immunization was administered should be used in this case.

Do providers need to "sign off" on the fact that this is "dose 2"?

We don't need/expect them to. It's fine if they can include this fact, but a relying party should have access to information on both doses/dates, so it's OK if the FHIR Immunization resources don't internally include a dose sequence number.

What does a health system, or other data source, need to do

  • Package up health data, in the form of FHIR resources, into health cards
  • There is no need to set up systems to support verification. Relying parties can verify information without actually reaching back to the health system.
  • It could be useful to have systems in place in the future to help support things like revoking health cards
  • When health data is updated or additional information is generated would a health card be revoked and a new health card be issued or would an additional card be issued?
    • We would like to be able to support all these options
  • Relying party should ask for a specific set of data or types of data to meet their needs based on the business rules that need to be executed.
    • Open questions on how to manage which cards that should be. e.g. what if a user does not consent to sharing a positive COVID-19 test, but allows the others. This is something that app developers need to consider. UX can help here where the protocol might not be able to.
Select a repo