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.
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.
https://github.com/smart-on-fhir/health-cards/pull/64
Were slides being shown available?
Vaccination IG update/discussion topics (https://github.com/dvci/vaccine-credential-ig/issues):
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:
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.
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.
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.
Could you share the Git? or the health wallet website?
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)
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.
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.
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?)
Decision: After detailed discussion we've decided to use FHIR R4 or VCI profiles and examples.
Using things like NFC, WiFi Channels, etc.
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.
(We'll leave out names / specific companies from these notes, and try to capture technical discussion and decisions.)
Action item was for participants to review specs, and come back with 1) questions, and 2) plans for what they might prototype.
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.
A Vaccine Record Holder (e.g., pharmacy, health system, or registry)
A Digital Health Wallet app (e.g., securely on a personal device)
Any 3rd Party Apps can request Health Cards from the Digital Health Wallet
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)
(Thanks for the help! I can't talk and type at the same time ;-))
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.
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.
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 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 :))
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
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.
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.