Stream: smart/health-cards
Topic: FHIR IG vaccineCode changes?
Max Masnick (Sep 21 2021 at 14:08):
Following up on the ongoing discussion of the difficulty of supporting GTIN as a Verifier (due to the lack of a central list of valid GTINs), and more mature COVID-19 vaccine code support in some of the code systems we use, I want to open a discussion on the following proposed changes that would in theory be part of STU1 ballot reconciliation (making FHIR-33475 from @Isaac Vetter persuasive with mod):
- Creation of a value set that includes codes for identifying COVID-19 vaccines that are sufficiently granular for Verifiers to determine whether the proper dose series was followed, AND have a centrally maintained list of codes that is freely accessible to Verifiers. Currently I believe this includes CVX and AIR, and could potentially include SNOMED as well depending on how "freely accessible" is defined and what codes are in SNOMED GPS. If other code systems meet these criteria, they should be included as well.
- Issuers SHALL include at least one code from #1 for all COVID-19 SHCs. (There is a generic CVX code that could be used as a fallback if a more specific code doesn't exist, and if SNOMED is included in #1 then that has generic codes too.)
- Verifiers SHALL support interpretation of all codes in #1 that map to vaccines they support in any code system. (So if a Verifier reads CVX#207 for the Moderna vaccine, they would also be expected to read AIR and SNOMED codes that mean "Moderna vaccine".)
/cc @Grahame Grieve re: GTIN
Max Masnick (Sep 21 2021 at 14:23):
I'm interested in feedback on whether or not we should support "supplemental codes" or expect Issuers to only use codes in the value set described above for https://smarthealth.cards#covid19 cards. Some thoughts on this:
- There was some discussion of asking for SNOMED GPS codes that mirror the granularity/scope of CVX's COVID codes. These could be included in the value set described above. If we did this, should we still include the country-specific SNOMED edition codes as part of the value set, only allow these as supplemental codes, or not allow them at all?
- The CVX/AIR/SNOMED(?) value set would likely be implemented as a required binding in a slice in a separate COVID-19-specific profile of Immunization. We would still have the generic profile as well, and Issuers could fall back to this if needed (mirroring our approach to lab tests).
- I think we want to keep the value set bindings for
vaccineCodeasrequiredbecause wallet and verifier apps need to be able to know the full universe of codes they may encounter.
Max Masnick (Sep 21 2021 at 14:24):
This topic will likely be first on the agenda for our Oct 5th conference call
Grahame Grieve (Sep 21 2021 at 14:38):
In general, I think that this makes sense. Not sure I'd include AIR on the list though. A code system should only get on the list if it's unencumbered, and there's evidence it's not country specific
Grahame Grieve (Sep 21 2021 at 14:39):
but requiring an extra code is more bytes than allowing display :wink:
Max Masnick (Sep 21 2021 at 14:42):
SARS-COV-2 (COVID-19) vaccine, mRNA, spike protein, LNP, preservative free, 100 mcg or 50 mcg dose
...seems like that may not compress quite as well as a code system URI :grinning:
Max Masnick (Sep 21 2021 at 14:43):
But in all seriousness, we should look at the utility of allowing display...do you remember where you posted about this already?
Josh Mandel (Sep 21 2021 at 15:25):
Creation of a value set that includes codes for identifying COVID-19 vaccines that are sufficiently granular for Verifiers to determine whether the proper dose series was followed, AND have a centrally maintained list of codes that is freely accessible to Verifiers.
@Max Masnick I think you're saying that any vocab that met these conditions would be added to our valueset. From an interop perspective: why do we need to include so many? Why not pick one (either an existing one, or or own) instead of accreting synonyms?
Max Masnick (Sep 21 2021 at 15:47):
@Josh Mandel my main goal here was describing why we would pick just CVX and maybe SNOMED (assuming AIR drops out per above), but I agree that we don't necessarily want to keep adding additional code systems that start to meet these criteria.
My main concern with using only CVX is that as far as I know there's not a process for requesting new codes. So I think we would at least need one other code system that supports this and has permissive licensing (e.g., SNOMED GPS).
I think the main arguments against defining our own code system are that we don't have the infrastructure in place to manage regular updates (and CVX/SNOMED do already), and defining a new code system creates implementer burden. So if we did this, the benefits would need to outweigh the burden, and we'd need to figure out how to handle issuing new codes. There may be other concerns I'm missing here too -- I'm not a terminology expert.
Max Masnick (Sep 21 2021 at 15:50):
Another option would be to use CVX + define our own code system to be used in case a vaccine is missing from CVX (even temporarily). We could then provide mappings from our code system back to CVX. This addresses the implementer burden argument (most are already using CVX as far as I know), and the regular update argument (only needed if implementers identify a code missing from CVX).
Max Masnick (Sep 21 2021 at 15:52):
Max Masnick said:
Another option would be to use CVX + define our own code system to be used in case a vaccine is missing from CVX (even temporarily). We could then provide mappings from our code system back to CVX. This addresses the implementer burden argument (most are already using CVX as far as I know), and the regular update argument (only needed if implementers identify a code missing from CVX).
Another benefit to this approach is it becomes much clearer for Issuers which code system to use. I believe the best practice is to not have synonyms in the same value set, which this would support (we could even deprecate our custom codes if a CVX becomes available).
Max Masnick (Sep 21 2021 at 15:53):
Anyway, lots of options here, which is why I wanted to start this discussion now. We'll work on putting together a menu of options for the Oct 5 call, so please continue to add comments to this thread.
Grahame Grieve (Sep 21 2021 at 16:01):
we should look at the utility of allowing display...do you remember where you posted about this already?
Right, I assumed that was part of the input into this topic. requiring a CVX or SCT code and mandating that they are understood would avoid the need for allowing display, but can a rule like that stick? I suspect not.
Grahame Grieve (Sep 21 2021 at 16:14):
SARS-COV-2 (COVID-19) vaccine, mRNA, spike protein, LNP, preservative free, 100 mcg or 50 mcg dose
Need a consumer suitable display term - business to be taken up elsewhere
Josh Mandel (Sep 21 2021 at 17:07):
Another benefit to this approach is it becomes much clearer for Issuers which code system to use. I believe the best practice is to not have synonyms in the same value set, which this would support (we could even deprecate our custom codes if a CVX becomes available).
I agree @Max Masnick ; I think this is worth exploring. (Also, we might just see if CVX can publish a policy for requesting changes. which would settle the first question; in practice, they've been quite responsive, so this would just be documenting their practices.)
Pascal Pfiffner (Sep 21 2021 at 18:38):
I like this plan a lot!
Peter Jordan (Sep 21 2021 at 23:57):
Grahame Grieve said:
SARS-COV-2 (COVID-19) vaccine, mRNA, spike protein, LNP, preservative free, 100 mcg or 50 mcg dose
Need a consumer suitable display term - business to be taken up elsewhere
By the Vocabulary Work Group?
Looking beyond the next 6 months, I think it might be prudent to add ICD-11 support (but definitely not AIR).
Grahame Grieve (Sep 22 2021 at 01:30):
By the Vocabulary Work Group?
Depends on the coding system.
Grahame Grieve (Sep 22 2021 at 07:48):
see https://chat.fhir.org/#narrow/stream/179173-australia/topic/Smart.20health.20Cards - In Australia, we'll be publishing consumer friendly display codes, using the value set described there. (where 'we' is the first implementer to go live; hopefully, that'll turn into established policy, but that's yet to be discussed)
Max Masnick (Sep 22 2021 at 08:45):
see https://chat.fhir.org/#narrow/stream/179173-australia/topic/Smart.20health.20Cards - In Australia, we'll be publishing consumer friendly display codes, using the value set described there. (where 'we' is the first implementer to go live; hopefully, that'll turn into established policy, but that's yet to be discussed)
The Australia implementation is using CVX codes, and populating display.
Max Masnick (Sep 22 2021 at 08:52):
One of the problems with CVX is that the human-readable value we would want for display isn't defined in a consistent place.
For the newer (500-series) CVX codes, it's embedded in the "short description" like:
COVID-19 IV Non-US Vaccine (CoronaVac, Sinovac)
In other cases it's in the table found here but not in the canonical list of CVX codes (or the computable version).
@Grahame Grieve how is the Australia implementation standardizing on display values? Is this part of the value set you're maintaining?
Max Masnick (Sep 22 2021 at 08:55):
Also, we might just see if CVX can publish a policy for requesting changes. which would settle the first question; in practice, they've been quite responsive, so this would just be documenting their practices.)
It looks like they just added a new CVX for Pfizer 5-12 years old (219)
Max Masnick (Sep 22 2021 at 09:03):
@Peter Jordan re: display names for CVX, I was commenting on this earlier in this thread ↑
Max Masnick (Sep 22 2021 at 09:07):
One issue with embedding display in SHCs: these can change over time -- we saw this when Moderna and Pfizer introduced their tradenames (Spikevax and Comirnaty).
Peter Jordan (Sep 22 2021 at 09:19):
Other new CVX Codes are 217 (for 12 yrs and older) and 218 (5-11 years)); although, like 219 (2-4 years), they are noted as 'potential'.
Grahame Grieve (Sep 22 2021 at 09:58):
how is the Australia implementation standardizing on display values? Is this part of the value set you're maintaining?
yes, for now, I'm maintaining it until there's a better place for it to live (if that happens)
Max Masnick (Sep 22 2021 at 09:59):
@Grahame Grieve would you be opposed to the IG using your value set in some capacity?
Max Masnick (Sep 22 2021 at 09:59):
(Either pointing to it in the narrative as the source of human-readable versions of CVX codes, and/or as part of a binding?)
Grahame Grieve (Sep 22 2021 at 10:00):
One issue with embedding display in SHCs: these can change over time -- we saw this when Moderna and Pfizer introduced their tradenames
And Astrazeneca too! And yes, that's a true but it's not the name it had when you had it, so there's more than one way to look at it. But it would ease our concerns a wee bit if there was an official set of 'consumer friendly names' maintained by CVX. But probably just a wee bit; we need to have the display values from the smart codes be codes that police and bouncers etc immediately recognise as valid vaccines here in Australia. Otherwise the whole process will be a disaster in practice
Grahame Grieve (Sep 22 2021 at 10:01):
would you be opposed to the IG using your value set in some capacity?
not opposed, no, but the consumer friendly names we'll choose will be based on Australian vernacular usage, and not necessarily suitable for other countries
Grahame Grieve (Sep 22 2021 at 10:02):
suggest to fork the value set and choose US friendly names in the DM profile.
Max Masnick (Sep 22 2021 at 10:02):
not opposed, no, but the consumer friendly names we'll choose will be based on Australian vernacular usage, and not necessarily suitable for other countries
Interesting...is there a supported model for i18n of display names in FHIR?
Max Masnick (Sep 22 2021 at 10:03):
It would be great if, hypothetically, we could maintain one canonical value set that could be translated as needed
Grahame Grieve (Sep 22 2021 at 10:04):
well, yes and we could do that. I'm about to have nap. Later, I'll post an example of what that could look like
Max Masnick (Sep 22 2021 at 10:05):
Ok, thanks! :zzz:
Max Masnick (Sep 22 2021 at 10:09):
But probably just a wee bit; we need to have the display values from the smart codes be codes that police and bouncers etc immediately recognise as valid vaccines here in Australia. Otherwise the whole process will be a disaster in practice
The Commons Project's Verifier app handles translation of CVX codes into human-readable strings. I recognize that supporting all the code systems currently allowed in an IG is a problem for a Verifier app, but if we downsize the terminology and provide the display values as part of a value set, it would at least be a lot easier.
Max Masnick (Sep 22 2021 at 10:10):
i18n is another reason why embedding display in the SHC may not make sense -- if Verifiers are going to have to support look-ups to deal with translations from int'l SHCs anyway, they might as well just do it all the time.
Grahame Grieve (Sep 22 2021 at 10:42):
the spec can make whatever rules it likes, but if the implementations don't support it, it doesn't matter.
Grahame Grieve (Sep 22 2021 at 10:42):
Commons Project's Verifier app handles translation of CVX codes into human-readable strings
Really? where? I'm not seeing it
Max Masnick (Sep 22 2021 at 10:49):
https://thecommonsproject.org/smart-health-card-verifier is the app I'm talking about. You can download it and scan Josh's SHC from https://github.com/jmandel/my-health-data/blob/master/my-data/smart-health-card-jmandel.png. It displays "Moderna" for his vaccines even though the FHIR Bundle just has the CVX code
{
"resourceType": "Immunization",
"status": "completed",
"vaccineCode": {
"coding": [
{
"system": "http://hl7.org/fhir/sid/cvx",
"code": "207"
}
]
},
"patient": {
"reference": "resource:0"
},
"occurrenceDateTime": "2021-04-18",
"lotNumber": "UNKNOWN",
"performer": [
{
"actor": {
"display": "Walgreens 06130"
}
}
]
}
}
Grahame Grieve (Sep 22 2021 at 10:53):
interesting. when I scan my card, I get nothing.
Grahame Grieve (Sep 22 2021 at 10:54):
where does it get the display from?
Grahame Grieve (Sep 22 2021 at 10:54):
Max Masnick (Sep 22 2021 at 10:55):
Weird...let me investigate
Grahame Grieve (Sep 22 2021 at 10:57):
that'll be because it's AIR codes in that one.
Grahame Grieve (Sep 22 2021 at 11:11):
@Max Masnick asked:
is there a supported model for i18n of display names in FHIR?
Grahame Grieve (Sep 22 2021 at 11:11):
so here's what that would look like:
Grahame Grieve (Sep 22 2021 at 11:12):
{
"resourceType": "ValueSet",
"id": "shc-covid-cvx",
"language" : "en",
"url": "http://healthintersections.com.au/fhir/ValueSet/shc-covid-cvx",
"version": "4.0.1",
"name": "ShcCovidCvxCodesAustralia",
"title": "CVX Covid Codes for use in Australian Smart Health Cards",
"status": "draft",
"date": "2021-09-22",
"publisher": "Health Intersections",
"contact": [
{
"name": "Grahame Grieve",
"telecom": [
{
"system": "email",
"value": "grahame@healthintersections.com.au"
}
]
}
],
"description": "A list of CVX codes with recommended consumer suitable displays for use in Australian Smart Health Cards",
"jurisdiction": [
{
"coding": [
{
"system": "urn:iso:std:iso:3166",
"code": "AU"
}
]
}
],
"copyright": "Creative Commons 0",
"compose": {
"include": [
{
"system": "http://hl7.org/fhir/sid/cvx",
"concept": [
{
"code": "210",
"display": "COVID-19 vaccine, vector-nr, rS-ChAdOx1, PF, 0.5 mL",
"designation" : [{
"language" : "en-AU",
"use" : {
"system" : "http://example.org/fhir/CodeSystem/designation-use",
"use" : "consumer-friendly"
},
"value" : "AstraZeneca (Vaxzevria)"
}]
},
{
"code": "208",
"display": "COVID-19, mRNA, LNP-S, PF, 30 mcg/0.3 mL dose",
"designation" : [{
"language" : "en-AU",
"use" : {
"system" : "http://example.org/fhir/CodeSystem/designation-use",
"use" : "consumer-friendly"
},
"value" : "Pfizer (Comirnaty)"
}, {
"language" : "en-US",
"use" : {
"system" : "http://example.org/fhir/CodeSystem/designation-use",
"use" : "consumer-friendly"
},
"value" : "Pfizer/Covid"
}, {
"language" : "en-NZ",
"use" : {
"system" : "http://example.org/fhir/CodeSystem/designation-use",
"use" : "consumer-friendly"
},
"value" : "Pfizer-BioNTech COVID-19 Vaccine"
}]
},
{
"code": "207",
"display": "COVID-19, mRNA, LNP-S, PF, 100 mcg or 50 mcg dose",
"designation" : [{
"language" : "en-AU",
"use" : {
"system" : "http://example.org/fhir/CodeSystem/designation-use",
"use" : "consumer-friendly"
},
"value" : "Moderna (Spikevax)"
}, {
"language" : "en-US",
"use" : {
"system" : "http://example.org/fhir/CodeSystem/designation-use",
"use" : "consumer-friendly"
},
"value" : "Pfizer/Moderna"
}]
}
]
}
]
}
}
Grahame Grieve (Sep 22 2021 at 11:12):
so far, that has only english. The base language of the resource is english, so the unadorned display is in english. In addition, the codes all have an Australian consumer friendly display, and also some example UK and NZ terms.
adding other languages etc is a linear extension of this idea
John Moehrke (Sep 22 2021 at 11:46):
There is a general need for vocabulary display strings for non clinicians. For example the subject of the medical data, the patient. These display strings need just as much translation as the clinician display string.
Josh Mandel (Sep 22 2021 at 12:56):
Packing strings into these payloads we're going to limit our capacity very quickly. Even if we do provide an official set of consumer-facing display names (which I think is a nice idea), I'm concerned about packing these names into our instance data, given the space constraints (and competing pressures like including additional vaccines, relevant durable labs, and probably more to come over time).
If the vocabulary is licensed appropriately, any verifier app can easily maintain an up-to-date set of names (and in a multitude of languages, character sets, etc) and layer them on to the UI in context.
(And context matters -- like, "Moderna" is an ok name if I'm presenting a list of covid vaccines in March 2021, but with brand names, or as Moderna produces new vaccines for other conditions, not so much.)
Max Masnick (Sep 22 2021 at 13:17):
I think "don't populate display" can be a stronger recommendation if we have that value set with display names.
Grahame Grieve (Sep 22 2021 at 14:44):
If the vocabulary is licensed appropriately, any verifier app can easily maintain an up-to-date set of names (and in a multitude of languages, character sets, etc) and layer them on to the UI in context.
That's a huge if, and also, I think you and I use the word 'easily' differently. Particularly since it isn't happening now
Josh Mandel (Sep 22 2021 at 14:49):
Licensing: it's the thing most worth pushing on, because we already have examples (e.g., CVX) that meet this bar.
Grahame Grieve (Sep 22 2021 at 14:51):
well, we can use CVX codes, but not CVX displays. That's a show stopper for use in Australia. Period
Josh Mandel (Sep 22 2021 at 14:51):
Today we have apps that layer their own names onto concepts from CVX -- e..g https://thecommonsproject.org/smart-health-card-verifier
Grahame Grieve (Sep 22 2021 at 14:51):
where does it get them from? just make them up?
Josh Mandel (Sep 22 2021 at 14:51):
If we want to publish a set of "recommended display names" to make this easier, we can.
Josh Mandel (Sep 22 2021 at 14:51):
It's a small set today, at least.
Josh Mandel (Sep 22 2021 at 14:52):
It's also worth saying that many verification scenarios don't require displaying this granularity of data.
Grahame Grieve (Sep 22 2021 at 14:52):
really? I'm not following. When doesn't it need to be displayed?
Josh Mandel (Sep 22 2021 at 14:52):
Just a "two valid doses according to jurisdictional rules", or even "::checkmark".
Josh Mandel (Sep 22 2021 at 14:53):
Like, verifiers don't need to surface raw data; they can also compute and display conclusions.
Josh Mandel (Sep 22 2021 at 14:53):
I'm not saying one is better than the other; just emphasizing there's a wide design space.
Max Masnick (Sep 22 2021 at 14:54):
Ideally humans (e.g., event staff) are not manually interpreting the data in SHCs. There's a lot more risk of a human making a mistake than a computer.
Grahame Grieve (Sep 22 2021 at 14:54):
there certainly is. But if consumers are seeing a description of their vaccination in Apple or Android that doesn't match what they were told or see elsewhere, then that's a show stopper. At least for me
Grahame Grieve (Sep 22 2021 at 14:54):
@Max Masnick somebody has to look at it and decide.
Grahame Grieve (Sep 22 2021 at 14:55):
Look and see the right name and two doses of pfizer - tick. Look and see two doses of "COVID-19, mRNA, LNP-S, PF, 30 mcg/0.3 mL dose" - not tick.
Max Masnick (Sep 22 2021 at 14:55):
Why does a person have to look at it? Can't a person just scan the QR code, and then read the output of the Verifier app that says :check: or :red_circle: ?
Grahame Grieve (Sep 22 2021 at 14:56):
maybe. but the churn comes when they look at it in apple or android and see something else. I can see I'm not getting anywhere here. That's obviously a show stopper to me for the whole use of the spec at all, but you guys just don't seem to understand
Max Masnick (Sep 22 2021 at 14:56):
With all the possible vaccines + different schedules depending on the vaccine + boosters, I don't think it's realistic for non-clinical people to be interpreting whether someone is "fully vaccinated".
Josh Mandel (Sep 22 2021 at 14:57):
So, the needs of consumer records apps and verifiers are a bit different. They might even prefer different display names, etc. Packing names into instance data doesn't solve this issue, and we really don't have a lot of fights bytes to spare.
Josh Mandel (Sep 22 2021 at 14:57):
Grahame, I want to understand what your deep concerns are here with the approach of publishing display names out of band, and potentially a set of different display names for different purposes.
Josh Mandel (Sep 22 2021 at 14:57):
There's one issue I hear which is the pragmatic one of can we really do it. Let's assume we could. What next?
Max Masnick (Sep 22 2021 at 14:59):
I agree it's important to have consistent display of friendly versions of codes for Holders ("wallet apps").
Grahame Grieve (Sep 22 2021 at 14:59):
Australian rules: you need a vaccination certificate that says you have two doses of astrazeneca or pfizer. Consumer, looking in the apple health app: "I have two doses of COVID-19, mRNA, LNP-S, PF, 30 mcg/0.3 mL dose". Guess the government has no idea what it's doing again. An the government , looking ahead... it says, 'we'll never use a spec that stops us from lining up thos ducks so that people know what's going on.'
Grahame Grieve (Sep 22 2021 at 14:59):
I don't care whether it's solved in band or out of band, really. But I don't think that I've heard a realistic story for how it's solved out of band
Josh Mandel (Sep 22 2021 at 15:00):
Our spec allows this -- wallet apps can show what they like
Josh Mandel (Sep 22 2021 at 15:00):
Publishing a list of recommended names in a public JSON file is not a technically hard thing, and apps can use it.
Grahame Grieve (Sep 22 2021 at 15:00):
well, I might as well stop being interested then. Because unless the displays are meaningfully consistent, we're wasting our time
Max Masnick (Sep 22 2021 at 15:00):
And even if you populate display a given wallet app may ignore it. So I don't think populating display really solves the problem Grahame is describing
Josh Mandel (Sep 22 2021 at 15:01):
Correct; displays may vary with context
Josh Mandel (Sep 22 2021 at 15:01):
That's why we're focused on the codes -- those tell the story of what product was injected.
Max Masnick (Sep 22 2021 at 15:01):
What if an Issuer uses English but the patient doesn't speak English? Then the wallet should be able to display in their native language, right?
Grahame Grieve (Sep 22 2021 at 15:01):
not the names of the immunizations. Other things, absolutely.
Josh Mandel (Sep 22 2021 at 15:02):
Trade names may vary by country, right?
Grahame Grieve (Sep 22 2021 at 15:03):
I'm trying to explain, and failing, why control over the user experience is critical to the choice of adopting the specification. Right now, there seems to be no prospect of any semblence of control
Grahame Grieve (Sep 22 2021 at 15:03):
indeed. they do vary by country.
Josh Mandel (Sep 22 2021 at 15:03):
Whose control?
Josh Mandel (Sep 22 2021 at 15:03):
You can't control whether an US based issuer embeds an Australian trade name in a display field
Josh Mandel (Sep 22 2021 at 15:03):
But you can interpret and translate the code.
Max Masnick (Sep 22 2021 at 15:04):
You also can't control how the wallet apps are going to display SHCs, regardless of what we put in the spec or what the Issuer puts in display.
Grahame Grieve (Sep 22 2021 at 15:05):
but i can't. How can I be clearer about this. The users encounter a set of applications. Some written by developers we control, and others written by developers we don't. And the second set matter because that's the consumer apps
Josh Mandel (Sep 22 2021 at 15:05):
Why would you want to control the behavior of every consumer app?
Grahame Grieve (Sep 22 2021 at 15:06):
what? I don't want to control their behaviour, I just want them to render the code comprehensibly
Josh Mandel (Sep 22 2021 at 15:06):
To be clear, we see some jurisdictions building their own verifier apps, for user within the jurisdiction. That works fine.
Grahame Grieve (Sep 22 2021 at 15:06):
I'm wasting my breath here. You're just not listening
Josh Mandel (Sep 22 2021 at 15:07):
But if different jurisdictions prefer different trade names, and the consumer only gets one SHC, you can't force the consumer wallets to do the right thing because there's no single right thing
Josh Mandel (Sep 22 2021 at 15:07):
I'm trying hard to listen
Josh Mandel (Sep 22 2021 at 15:07):
I'm not understanding though, for sure.
Josh Mandel (Sep 22 2021 at 15:08):
Let's schedule a call to talk through this?
Grahame Grieve (Sep 22 2021 at 15:10):
there's no coherent user experience unless the set of applications that the typical consumer encounters describe the codes coherently. There needs to be a story about how that can happen in the spec. My preferred solution is "provide the correct consumer friendly display for the jurisdiction" and make the rule that 'international apps default to using the provided display unless they know better' (and if one isn't provided, then use look up).
Grahame Grieve (Sep 22 2021 at 15:11):
there might be other solutions. But the response 'it's not a problem that matters' isn't workable from my pov
Max Masnick (Sep 22 2021 at 15:15):
@Grahame Grieve it seems like if we standardize on CVX (or CVX + a small number of other codes), and then point to a value set that includes int'l translations in the spec, we would be closer to this than we are now?
Josh Mandel (Sep 22 2021 at 15:15):
So, adding guidance for consumer apps makes sense, sure. Most such apps are scoped internationally, and for these we could say "use the consumer friendly display names published at _______ unless you know better".
Josh Mandel (Sep 22 2021 at 15:15):
Over time we could augment those with translations, etc.
Grahame Grieve (Sep 22 2021 at 15:16):
closer, yes. I have three concerns about that approach:
- is it maintainable?
- how does that work for something other covid vaccinations (harder problem)
- what conformance langauge in the spec?
Josh Mandel (Sep 22 2021 at 15:16):
Maintainable; I don't know. It's an ongoing commitment, but I think it's manageable.
Neelima Karipineni (Sep 22 2021 at 15:17):
In our reference implementations, we are using the CDC tradename at https://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=tradename if available as it is much more consumer friendly. If not available, we're using the CVX Short Description.
For CVX 218 -
tradename - 'Pfizer-BioNTech COVID-19 Vaccine (EUA labeled) COMIRNATY (BLA labeled)'
short description - 'COVID-19, mRNA, LNP-S, PF, 10 mcg/0.2 mL dose, tris-sucrose'
Josh Mandel (Sep 22 2021 at 15:17):
Other vaccines: same question, scaled up. I think a community effort is totally feasible.
Josh Mandel (Sep 22 2021 at 15:18):
Conformance language: "SHALL use... Unless you know better" seems silly, so I'm thinking "SHOULD use, unless you know better"
Josh Mandel (Sep 22 2021 at 15:19):
There's a fair amount of room for "knowing better" though, when it comes to decisions on brand names, manufacturers, etc.
Josh Mandel (Sep 22 2021 at 15:19):
As @Neelima Karipineni's assessment makes clear
Max Masnick (Sep 22 2021 at 15:22):
In the FHIR IG, we have language like:
If an Issuer has a good faith belief that resolving a validation error against a primary (DM) profile would reduce utility for Holders or Verifiers, they MAY instead validate against the less constrained fallback (AD) profile instead.
Grahame Grieve (Sep 22 2021 at 15:23):
well, that would solve the issue if we got alignment to that. The value set above shows how to represent that knowledge; what would be needed would be an agreement about (a) how to maintain it and (b) that international consumer applications would honour it
Max Masnick (Sep 22 2021 at 15:30):
There's definitely some thought that will need to go into how to maintain it. I think getting a minimal viable version up for COVID CVXs is pretty easy, and keeping that up-to-date won't be too much of a lift.
Once we start adding language/jurisdiction-specific translations it will be more difficult. How do we ensure translation quality? What if multiple stakeholders in the same jurisdiction want different things? Etc. etc.
Grahame Grieve (Sep 22 2021 at 15:31):
defer to HL7 affiliate if there is one. Otherwise... refer to HL7 execs for building relationships. I can do that with many countries, and have many levers to pull
Pascal Pfiffner (Sep 22 2021 at 16:04):
If the vocabulary is licensed appropriately, any verifier app can easily maintain an up-to-date set of names (and in a multitude of languages, character sets, etc) and layer them on to the UI in context.
As Grahame said, _huge if_. This is hard even for us; as soon as licensing is not world wide using lookup tables becomes incredibly complex. For this reason, if we can make sure that licenses are friendly (like CVX or SNOMED GPS) _then_ I agree, an up-to-date list can be maintained by Wallets and Verifiers.
Pascal Pfiffner (Sep 22 2021 at 16:08):
As for the display discussion: an app can always display both, what's in the payload and one taken from the lookup table, which can be localized, more up to date, ...
Pascal Pfiffner (Sep 22 2021 at 16:09):
Translations also come with legal baggage, depending on who did the translation.
Max Masnick (Sep 22 2021 at 16:09):
For this reason, if we can make sure that licenses are friendly (like CVX or SNOMED GPS) _then_ I agree, an up-to-date list can be maintained by Wallets and Verifiers.
Yet another reason to simplify/strengthen the terminology requirements
Grahame Grieve (Sep 22 2021 at 16:11):
what's the license on CVX?
Max Masnick (Sep 22 2021 at 16:12):
As far as I know it's in the US public domain. I don't know if this differs by country. We can ask.
Pascal Pfiffner (Sep 22 2021 at 16:15):
I can't find the particular license right now, but it was free to use worldwide, not sure about the requirements right now. I can find out, too.
Max Masnick (Sep 22 2021 at 16:16):
I just emailed JP...I believe he's in touch with people who could answer
Grahame Grieve (Sep 22 2021 at 16:34):
anyway, we can publish my value set riffing on it above as CC0
Peter Jordan (Sep 22 2021 at 20:22):
Do we have any examples of consumer-friendly terms from countries who have implemented COVID-19 vaccine credential apps (e.g. NHS)? I'd like to think that we could agree on a common prefix, e.g. "COVID-19 vaccine" that even an Australian nightclub bouncer might understand and then add product/manufacturer names. If you look at this collection of COVID-19 vaccine codes from around the world, this might be the most feasible approach...
https://terminz.azurewebsites.net/fhir/ValueSet/covid-19-vaccines/$expand
Neelima Karipineni (Sep 22 2021 at 20:54):
All of this info can be derived from existing CDC IIS standards assets. I don't think we need to be maintaining a separate set. There are caveats (CDC took awhile to add the non-US codes, not all non-US codes have tradenames) but I don't think we could necessarily do a better. It might be helpful to add the vaccine groups as a concept map somewhere.
To add to example above for CVX 218 -
tradename - 'Pfizer-BioNTech COVID-19 Vaccine (EUA labeled) COMIRNATY (BLA labeled)'
short description - 'COVID-19, mRNA, LNP-S, PF, 10 mcg/0.2 mL dose, tris-sucrose'
vaccine group - 'COVID-19'
if provided, manufacturer code - PFR, display - 'Pfizer, Inc'
Grahame Grieve (Sep 22 2021 at 21:03):
I don't think that it's a general model for a consumer friendly name, as soon as a single manufacturer provides more than one variant (a la pfizer already)
Ricky Bloomfield (Sep 22 2021 at 23:42):
I'm jumping into this (lively!) discussion a bit late (thanks to @Pascal Pfiffner for alerting me to it!). This has, indeed, been a struggle for us. I imagine if we're struggling with it, just about anyone else would as well.
I totally see @Grahame Grieve's point that the only way to ensure absolute consistency in display names across a variety of apps is to use the display name that comes with the record. But as has been pointed out, we can't force any app to do this, and some display names are downright hostile to patients because they were designed for use by providers.
In the Health app, for example, we currently have a hierarchy of Category -> Concept -> Record. We've curated custom, user-friendly "Concept" names such as "COVID-19 Vaccine" or "Flu Vaccine." Within the "COVID-19 Vaccine" Concept room (which is what we call them) you'll find all of the COVID vaccines that we've mapped to that concept via its CVX code. We're currently using the "Sole Proprietary Name" for these COVID vaccines since those seem to be the most user-friendly.
From our POV, having a curated set of (localized?) COVID-19 vaccine names with a permissive license would mostly solve the problem. Apps would gravitate towards using it and you would likely achieve consistency over time simply because it's 1) freely available and 2) high quality (assuming it's actually high quality). The million dollar question is how we actually get to this Nirvana? Perhaps we need to create our own open terminology and call it ERTH (Entire Reference Terminology for Health)? ;)
Grahame Grieve (Sep 22 2021 at 23:50):
We’re not taking on a general terminology for this, that’s for sure. No matter how tempting it is for this problem. But we can do a value set that solves this particular problem - i18ned consumer friendly terms for common covid vaccine codes. Logically, it would be a value set next to the vci registry json file, and some group of editors curate the PRs for jurisdictions (I’d be happy to volunteer to admin it at first), with shared responsibility between HL7 and VCI. That’s a location that the clients already trust, and that we could reference from the specification in a “SHOULD” conformance requirement
Grahame Grieve (Sep 22 2021 at 23:50):
But thinking that through did make me wonder about i18n needs for the vci registry?
Ricky Bloomfield (Sep 23 2021 at 00:16):
Sounds like a good plan to me!
Max Masnick (Sep 23 2021 at 17:00):
We are talking to CDC to make sure we're not missing anything re: CVX, but assuming they don't throw up any flags it sounds like...
1) We have general agreement to move forward with a proposal to (1) publish a CVX value set with localized display names; and (2) add a SHOULD conformance requirement to the spec.smarthealth.cards that anytime an SHC is displayed it should be using these display names.
A maintenance/governance plan should be part of this proposal, and can be based on what Grahame said above on this.
2) In a separate-but-related parallel path, we will propose changes to the FHIR IG that reduce the scope of SHALL-support code systems for vaccineCode to only CVX and possibly a small number of other equivalently granular and permissively licensed code systems. The first discussion about this will likely be in Public Health's Q4 session today, and will continue in our upcoming ballot reconciliation calls.
I believe that all of the above can apply to vaccines for all diseases, but the value set will likely only include robust localization for COVID for the foreseeable future.
I wrote the above in definitive-sounding language, but this is really a question to to make sure I got this all correct...if not please propose edits accordingly. Thank you!
Grahame Grieve (Sep 23 2021 at 17:02):
that works for me
Josh Mandel (Sep 23 2021 at 18:29):
Agreed, this is a great plan.
Max Masnick (Sep 23 2021 at 20:53):
We just discussed this on the PHWG Q4 call.
The additions of non-US vaccine CVX codes was a one-off for CDC and it took a lot of time, so they likely can't keep that up to date without somehow getting support from the community.
Everyone agrees that having a small number (one ideally, or two if needed) terminologies that meet the needs for SHCs is critical. We are going to pursue CVX, SNOMED GPS, and ICD-11 as the possible options for this.
Grahame Grieve (Sep 23 2021 at 20:54):
That implies that our community build ValueSet will include consumer friendly displays for those code systems as well
Grahame Grieve (Sep 23 2021 at 20:55):
and ideally, concept maps between them. At least for vaccine codes, it should be possible to get solid maps
Max Masnick (Sep 23 2021 at 20:55):
Yes
Nathan Bunker (Oct 08 2021 at 20:30):
Quick update from some internal discussions here at the American Immunization Registry Association on code sets. We are very supportive of trying to find a good common Interational code set that we can use. We are trying to do our own research on ICD-11 and Snomed to see how well these codesets might work, in comparison to what we have in CVX right now. (Because we know CVX, and not because we think it should be the primary standard.)
The only wrinkle in all this, is that our community wants to use VCI beyond Covid. So we are looking at how all vaccine codes will be represented in an international set. We know that Covid is getting all the attention, and we should focus on supporting that first, but there is a larger need for credentials for all immunizations to support school entry, international travel, employment, etc. In our community we are pushing the adoption of VCI, not as just a Covid-specific solution, but as a general solution that will help meet public health goals we've had for decades.
So we are going to look and give our feedback first on Covid and then secondarily what would be the benefit/drawbacks when we expand beyond this. Hopefully I'll have updates for the group on what we find out in the next week after a little investigation and comparison.
Josh Mandel (Nov 30 2021 at 18:46):
@Max Masnick pragmatically, apps and services would really benefit from an up-to-date ValueSet that includes CVX codes from https://www.cdc.gov/vaccines/programs/iis/COVID-19-related-codes.html with helpful properties like "Sale Proprietary Name" (the closest we have to a friendly name so far). Baking this into an IG means it'll get outdated quickly; have you thought about pragmatic ways to publish this kind of artifact somewhere outside the IG and keep updated?
Josh Mandel (Nov 30 2021 at 18:50):
(Like, if we don't have a planned answer for this I'll maybe just publish a GH repo with a FHIR-ified version of the CVX ValueSet including additional properties for these columns...)
Grahame Grieve (Nov 30 2021 at 19:37):
we already talked about VCI curating a value set with consumer friendly names for different languages - this is just the US friendly consumer name.
Grahame Grieve (Nov 30 2021 at 19:37):
proposal was to do it next to the VCI directory
Max Masnick (Nov 30 2021 at 19:41):
Yes, we want to have a ValueSet for this defined outside the IG (so it can be updated easily)
Josh Mandel (Nov 30 2021 at 19:41):
That's fine; I'm trying to figure out whether someone is actively doing this yet, or if just getting started is the best thing.
Max Masnick (Nov 30 2021 at 19:41):
I'll defer to @Grahame Grieve and @Josh Mandel on the best mechanism for doing this
Max Masnick (Nov 30 2021 at 19:42):
MITRE can work on the content once we know where it goes.
I can also update the IG to point to this value set as soon as it's stood up
Grahame Grieve (Nov 30 2021 at 19:42):
I wrote a candidate - in this stream somewhere previously, but it's not being managed yet
Max Masnick (Nov 30 2021 at 19:43):
For a ValueSet like this that's presumably living on GitHub -- what do we do in the profile for the value set binding on vaccineCode?
Grahame Grieve (Nov 30 2021 at 19:44):
Grahame Grieve (Nov 30 2021 at 19:45):
I think that the answer is to provide a static copy of it as an example binding, and point to the source of truth for implementers to decide how to manage it
Max Masnick (Nov 30 2021 at 19:47):
@Josh Mandel do you want to create a repo (or file within an existing repo) for this?
And are you ok with us working on populating it, or did you want the first crack at it?
Josh Mandel (Nov 30 2021 at 20:21):
I think a repository in the VCI org makes sense; I don't have permissions to create repositories there, but if you give me permissions I can create one :smile:
Josh Mandel (Nov 30 2021 at 20:22):
And I'd be happy if MITRE plans to work on populating this; just want to make sure it is on someone's radar and that you can share an estimate of when a draft might be available.
Grahame Grieve (Nov 30 2021 at 20:46):
I'm happy to populate it if I get write access
Max Masnick (Nov 30 2021 at 21:48):
@Josh Mandel I appear to have the ability to create the repo. What should we name it? /cc @Reece Adamson
Grahame Grieve (Nov 30 2021 at 21:52):
what's the scope going to be? terminology assets that support SHC implemnetations? or just covid?
Max Masnick (Nov 30 2021 at 21:53):
I think it should be aspirationally scoped to any infectious disease (mirroring the FHIR IG), but practically will be COVID-only in the near term
Max Masnick (Nov 30 2021 at 21:54):
@Nathan Bunker said they may have some interest in this as well
Grahame Grieve (Nov 30 2021 at 21:56):
well, the full name would be "Terminology Assets that support SHC implementations for infectious disease" then?
But I think that in practice, it's going to be all SHC terminology assets. Say we decide later to create a different repo for some other application of SHCs... are client applications that make use of the repo going to be able to decide which repo to use, and use it?
Max Masnick (Nov 30 2021 at 21:58):
It's possible that there will be other SHC use cases that none of us are involved in that have their own terminology assets
Grahame Grieve (Nov 30 2021 at 21:59):
but that will be about authority not scope of focus
Max Masnick (Nov 30 2021 at 22:05):
Ok for the sake of simplicity I went with https://github.com/dvci/shc-terminology.
Max Masnick (Nov 30 2021 at 22:05):
@Grahame Grieve and @Josh Mandel, you should have invites to get write access
Max Masnick (Nov 30 2021 at 22:07):
It's licensed as CC0. I imagine this is fine for CVX as it's in the public domain, but not sure how this will work for other code systems that are not as permissively licensed (like SNOMED).
Grahame Grieve (Nov 30 2021 at 22:11):
I added a draft value set to get us going
Grahame Grieve (Nov 30 2021 at 22:12):
in terms of license, what we usually say is that the license on the value set etc as a whole is CC0, but there may be additional IP encumberments on some of the details, and we note those explicit in the copyright statement, or vocab has defined an extension for being more specific on value set includes
Josh Mandel (Nov 30 2021 at 23:12):
Thanks Grahame and Max -- this is a great start. I added https://github.com/dvci/shc-terminology/issues/1 about aligning wiht the "Sale Proprietary Name" values from CDC as a starting point in USA.
Nathan Bunker (Dec 01 2021 at 19:14):
Confirmed. I have some interest in helping with this as well, although don't necessarily need direct write access. We have an interest in the vaccination codes for all vaccines, not just covid. We are working to get some initial mappings together between CVX, Snomed, and ICD-11. It will be start, and something that can generate feedback from others. We also have a process for updating CVX codes, we could look to see if we can extend this to automatically propose updates as CVX codes are released. That might be helpful long term.
Grahame Grieve (Dec 02 2021 at 00:46):
we can add a mapping to that repository. Here's a template to get you going:
Grahame Grieve (Dec 02 2021 at 00:47):
Max Masnick (Dec 02 2021 at 14:56):
@Nathan Bunker what’s your GitHub username? No reason you can’t have write access to the repo.
Max Masnick (Dec 02 2021 at 14:56):
At some point we will presumably institute a code review process before merges go in, but at this point I think we just want to populate as rapidly as folks have time for.
Nathan Bunker (Dec 02 2021 at 15:01):
Sounds good. Here is my GitHub id: nathanbunker
Max Masnick (Dec 02 2021 at 23:35):
@Nathan Bunker look for a GitHub invite in your email please!
Grahame Grieve (Dec 04 2021 at 21:28):
Josh and I have already been doing PR review
Last updated: Apr 12 2022 at 19:14 UTC
