Add mmrv example

[jmandel]

No description provided.

[jmandel]

My thinking is that we want to make it easy for apps to ask questions like "please share a varicella immunization record," and let health wallets identify any matches based on the types array (regardless of whether someone received varicella vaccine as a solo product or part of a combination product).

Is this worthwhile? Or should we not worry so much about reflecting this logic as set intersections on our types array, and assume that wallets will more deeply inspect/evaluate the fhir bundles @p2-apple ?

[p2-apple]

That was exactly my thinking as well. So the question is whether we achieve this goal with one mmr type or with 3 individual types.

In case of the the combined type, if somebody got e.g. a solo rubella shot, an app requesting mmr because they’re interested in measles vaccination could get a solo rubella vaccination, which is of no interest in this scenario.

If we created 3 individual types above scenario would be alleviated. I’m not sure we’d be backing us into a corner because if one truly wanted to only get MMR vaccinations (the combination) then specifying all 3 individual types should solve for that case.

So I’m thinking individual types may get us closer to the stated goal?

[jmandel]

Aha, now I understand your point -- thanks. I was stuck in the mode of seeing "MMRV" as "two vaccines in one" but of course it's four vaccines in one. So my example of "breaking this down into parts" was incomplete, and I should be breaking it into four constituent parts. I agree, and will update the examples and guidance accordingly.

[jmandel]

So, reading more carefully at https://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=vg the issue is that CDC considers "MMR" to be a base-level "vaccine group"; there is no "vaccine group" defined for the individual components, presumably because there are not any standalone vaccines available for measles, mumps, or rubella (at least, not in the USA).

So the question is whether we want to adopt CDC's notion of "vaccine groups" at all (which is... valuable for grouping together, say, the various different influenza vaccines into a single "flu" group, or the various COVID-19 vaccines into a single "covid19" group) or whether we'd want to roll our own in order to do a "complete breakdown".

[jmandel]

One thing we could say is that we always advertise "vaccine groups" in the top-level type array, but we recognize that (say) a historic record of a "measles-only" vaccine would be assigned to a group of "MMR", simply because that's how CDC's groups have been constructed.

The benefit: we externalize the work of defining and maintaining these codes. Developers have to review/learn what CDC's groups are, but the overall set is pretty small.

The cost: the semantics of labeling and requesting a "measles only" record in this way are strange (but it's an obscure case).

[p2-apple]

Yeah, good points. I’m thinking MMR not given as a combo is somewhat rare enough (e.g. Japan stopped using the combo a few years ago to study the effects, not sure it’s been re-introduced since) that I’d agree modeling after the CVX groups as a first step is ok. If we never introduce individual types then a receiving party just has to check that what they get back when asking for MMR indeed contains what they expect, and we would call out that “MMR” may also return just single shots.

[jmandel]

OK -- and probably MMRV shouldn't be our first / only example here ;-)

[arztnh]

I have been watching this conversation and I just have not had time to provide a thoughtful response. But the short of it is that using CDC vaccine series is probably the lowest level of granularity you need to go (the individual component, BTW, are referred to as an antigen - so, Measles within MMR). While MMR is technically a combo vaccine it is so well established and entrenched that it became a vaccine series - in the US we don't typically track its antigen components but just MMR (thought it is possible for one of its components to be contraindicated for a particular patient, but the individual vaccines are not common). Other combo vaccine co-exist and the challenge of immunization evaluation and forecasting software is to deal with all this. You can read more explanation on our wiki: https://cdsframework.atlassian.net/wiki/spaces/ICE/overview Sorry I can't explain further. Just no time right now. Noam

…

----- Noam H. Arzt, PhD, FAMIA, FHIMSS         President, HLN Consulting, LLC 858/538-2220 | ***@***.*** | @noamarzt | @hlnconsulting | http://www.hln.com/ On 8/13/2021 12:32 PM, Josh Mandel wrote: OK -- and probably MMRV shouldn't be our first / only example here ;-) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#173 (comment)", "url": "#173 (comment)", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[Mturman3]

As an implementer, CVX groups is the most viable path forward. We've already introduced this abstraction into our SHC server as a way to simplify configuration based on provided types. If/when we extend to other immunization use cases, being able to associate a type to an applicable CVX group code is our preferred pattern.

[jdkizer9]

It looks like the "performer" and "lotNumber" elements didn't make it into the JWS payload or QR code

[jmandel]

Thanks for catching this -- may be an issue with the underlying configuration in the Ruby library, or the way I'm invoking it here. I can investigate but probably good if the mitre team can address dvci/health_cards#84 first (there may be an issue with how "allowed properties" are inherited by HealthCare subclasses, or with how I have supplied these).

[nkarip]

Good catch @jdkizer9. I think this has to be fixed in the Ruby library itself, but we can put in a temporary fix in the examples script.

[nkarip]

Other than the "measles only" case, in which a developer would need to know to ask for MMR, there's also the pneumonia case, in which the developer would need to know to ask for both PneumoPPV and PnuemoPCV groups. Same with tetanus - need to ask for Td, DTAP and Tdap. The 1:many case is not uncommon.

IPS has a value set of SCT codes for Immunization.protocolApplied.targetDisease that is a list of antigens (as @arztnh described) rather than vaccine product groups, http://hl7.org/fhir/uv/ips/ValueSet-targetDiseases-uv-ips.html. It has not yet been updated with COVID-19, but this is essentially what it would look like to use disease instead of CDC vaccine group.

Issues -

1. SCT is licensed while the CDC vaccine groups are openly available, or we'd have to create and be responsible for maintaining our own code system for this.
2. The CDC vaccine groups also provide a mapping from VG-to-CVX code. This is useful both in the US and territories that use CVX, but also as the basis for crosswalk to other vaccine product code systems. With a custom code system, someone would need to maintain this mapping.

[nkarip]

Along same lines, is there a benefit in having this degree of categorization in the VC types, or can we reasonably expect verifiers to be able to determine the contents by inspecting the fhir bundle vaccine codes? Someone has to be responsible for mapping vaccine codes to either target disease or vaccine group. I think we've been mostly leaning toward having verifiers be responsible for this interpretation over requiring issuers to do it.

[p2-apple]

The VC types come into play when an app or service wants access to some vaccination (or other) information. I think it’s beneficial if an app can ask somewhat specifically which vaccine info they’d like to have. This way the user is only presented with relevant records to choose to share and doesn’t feel like the app or service wants to gobble up data. An airline app for example has good reason to ask about your COVID vaccines but doesn’t need and probably doesn’t want your MMR info.

But agree, that means we’ll basically have to create a coding system for target diseases or vaccine groups or at least bind to one that’s universally usable.

[nkarip]

Got it, thanks for the info @p2-apple. As you say, an app is unlikely to request MMR individually, that most likely would be requested as part a complete vaccination record for back-to-school type scenarios. Can we make the case that COVID-19 is a special case and just use immunization as the vc type for non-pandemic diseases?

Other consideration here is that we are using the covid19 vc type for lab tests as well as immunizations. If we want to keep it consistent, then the vaccine groups would not be applicable to lab tests. Would have to use target disease. The mapping becomes a much bigger job as well. We provide value sets for COVID lab test codes in COVID specific profiles, so it's a bit easier to assign the vc type, but we do not do so for the generic infectious disease lab test profiles. If this granularity of vc type is going to be optional (only immunization and not lab result cards), we should provide some spec guidance on when it is expected to be used and how to interpret if it's not provided.

[jmandel]

The alternative here is to define more sophisticated "request" semantics where, for example, a requester asks a wallet things like: "hey, do you have any SMART Health Cards containing...

• ... Observation.code from ValueSet https://vci.example.org/vs/covid19-labs?"
• ... Immunization.vaccineCode from ValueSet https://vci.example.org/vs/covid19-vaccines?"

This requires more FHIR-specific knowledge from wallets (e.g., introspecting resources, managing ValueSets) and is less likely to work with general-purpose wallets in the future (where matching based on a flat list of types is more tractable).

Guiding issuers toward populating a "simple" list of types is helpful for specific high-value use cases, and I think "show me proof of vaccination X" falls in that category for pretty much any "X". For labs, it may be more case-by-case (obviously COVID-19 labs are in this category).

[masnick]

It seems like the most common use cases for requesting vaccinations will be:

1. COVID only
2. Full immunization history
3. Multiple vaccines for an arbitrary set of diseases for international travel requirements (which practically could be better satisfied with 2️⃣ as the UX will be better than separate SHCs for each disease, or needing to get a single bespoke SHC issued for a specific set of diseases)

For 2️⃣ and 3️⃣, would it include each disease in type if separate https://smarthealth.cards#some-disease subtypes are defined for a large number of diseases? This could be unwieldy for implementers and would be redundant with the contents of the FHIR bundle. I also agree with Neelima's comments above about Verifiers being able to use the FHIR bundle contents rather than needing a disease-specific subtype for immunizations, and on the complexity in comprehensively mapping specific vaccines to diseases in the spec.

I also agree with the above comments on the difficulty of creating comprehensive sub-types of https://smarthealth.cards#laboratory.

Given this, I like the idea of not creating disease/lab-specific subtypes unless there is an overwhelmingly compelling use case (e.g., global pandemic).

For less common use cases, I think the approach Josh suggests using request semantics to make it possible to get a specific subset of https://smarthealth.cards#immunization or https://smarthealth.cards#laboratory makes sense. I think this will also scale better than highly granular subtypes for new SHC types that may come in the future.

[jmandel]

The only organizations that can help us answer this question are the ones who provide wallets supporting automated negotiation. The details of this negotiation need to make sense for those organizations. @p2-apple I wonder if you could comment on this or @jdkizer9 ?

My expectation is that most wallets would not want to go deep on evaluating fhir bundle contents when resolving requests to share a card, but I could be wrong.

[p2-apple]

We already have the "problem" that we have to trust the issuers using the correct credentialTypes given the contents of the bundle. This today works fine, given the narrow use-case for SHCs out there in the wild. I do see this as a source of error as the use-cases widen, though.

On the FHIR inspection question: for privacy reasons we always allow the user to see all contents of the SHCs they're about to share, which requires parsing of the FHIR content, and I would assume any Wallet would want to do that (I'm generalizing; because we store this data in Health we process the FHIR bundle anyway). So I feel defining a small set of queryable properties shouldn't put unreasonable burden on Wallet developers. I don't think this should go deep (e.g. no combinations like Observation.code == http://system.com|X and Observation.valueQuantity >= 4.5 or even more dedicated querying), but only returning SHCs that have at least one resource with a given code seems reasonable to me. But we'd want to call out which queries are supported at the SHC spec level.

[jmandel]

In this context: how to deal with the (very common) case where issuers can pick among many different vocabularies for coding a result (especially internationally), and we don't constrain them in our profiles? Does the Verifier need to write ? code=cxc|207,CVX|208,snomed|000|... with every possible code they care about?

Or do we wind up surfacing our "types"' within the FHIR payloads as categories or something like that? Even if we're querying the FHIR contents, we still need something our query can grab hold of. Tags, extensions, categories, standard codes, or whatever.

I think the base question here ("how does a Health Card identify what it's about, unambiguously and consistently") still applies . We could ask each profile to document its conventions, but then how do we impose consistent processing expectations at the base spec level? Pre-specify a limited number of fields that wallets need to be able to query? Pre-specify a tiny fhirpath subset that wallets need to support? I'm struggling a bit to understand how this plays out.