Stream: terminology
Topic: Using multiple codes with CodeableConcept Datatype
Paul Denning (Apr 27 2021 at 19:35):
See US Core http://build.fhir.org/ig/HL7/US-Core/conformance-expectations.html#using-multiple-codes-with-codeableconcept-datatype
It talks about using multiple codes within a CodeableConcept?
It talks about "alternate codes" called "translations", but its not clear to me which item of the coding array is "standard" (aka "primary" or not "alternate"). Presumably code.coding[0] is the primary code, and others are "translations", but that is not explicit as far as I can tell. Apparently the "primary" code is from a required or extensible value set, and alternate or translations would not be in that value set. But what if the value set includes multiple code systems where a code for the same concept exists in two or more of the code systems; if the value set has 2 code systems, either code (or both?) can be "primary". US Core says "These translations may be equivalent or narrower in meaning" to the standard concept (primary) code. If the value set contains 2 codes (e.g.,CVX and SNOMED), how would you know which one is narrower in meaning from another? Why can't a "translation" or alternate code have a broader meaning that the primary code? For COVID-19 vaccines, CVX is narrower than SNOMED. 207 is Moderna and 208 is Pfizer, but both are mRNA. SNOMED 1119349007 is for mRNA, so it could represent either Moderna or Pfizer. If SNOMED is not specified in the value set (which uses CVX), what is wrong with having code.coding[0] be CVX and code.coding[1] be a broader SNOMED code?
Given this:
"vaccineCode": {
"coding": [
{
"code": "207",
"system": "http://hl7.org/fhir/sid/cvx"
},
{
"code": "XM5JC5",
"system": "http://id.who.int/icd11/mms"
},
{
"code": "1119349007",
"system": "http://snomed.info/sct"
}
]
}
Can you tell which codes are in the value set and which are not?
Is it still called a translation if it is in the value set?
Lloyd McKenzie (Apr 27 2021 at 19:47):
There is no notion of 'primary' - the code you're looking for could appear anywhere in the list. (And it's non-conformant to insist that 'your' code appear in a particular place in the order.) A given instance could comply with numerous profiles, each of which might require a coding from a particular value set to be present. Some profiles might require that codings from multiple value sets be present. To validate, you need to check all the codings to see if any of them are valid within the value set(s) you happen to care about.
Lloyd McKenzie (Apr 27 2021 at 19:48):
There is an ability to flag one of the codings as "user-specified" - i.e. the specific code the user picked from the user interface (if that happened at all). Other than that, there's no mechanism to determine what codes are broader vs. narrower other than the receiving system's knowledge of the codes in question.
Paul Denning (Apr 27 2021 at 19:55):
Thanks for the clarifications.
So if CVX is "required" binding strength, the coding above would be valid because it contains the 207 CVX code, and the ICD11 and SNOMED are ok even though they are conceptually broader and not in the required value set?
Grahame Grieve (Apr 27 2021 at 19:56):
yes. And the question of broader vs narrower is explicitly dealt with:
Each coding (also referred to as a 'translation') is a representation of the concept as described above and may have slightly different granularity due to the differences in the definitions of the underlying codes
Lloyd McKenzie (Apr 27 2021 at 20:28):
There can actually be a pretty broad difference in granularity. Having one coding that says "antibiotic" and one that says "APO Amoxicillin 10 mg tablets, batch 1234" is completely fair game.
Max Masnick (Apr 29 2021 at 21:09):
One thing we're looking at now is including vaccine manufacturer along with the CVX code. The CVX code identifies the vaccine product, but not necessarily the manufacturer (though it does implicitly for the COVID vaccines currently).
Some possible code systems, like GTIN, would identify both the vaccine product and manufacturer. It sounds like including both CVX and GTIN in vaccineCode makes sense based on the above.
But for CVX, the manufacturer counterpart is MVX, which literally just identifies the manufacturer (MVX#MOD = Moderna). Does this also make sense as part of the vaccineCode?
(Immunization.manufacturer is another option, but this is a reference rather than a CodeableConcept, and it seems strange to give up the benefits of terminology validation since we have a code system for manufacturer.)
/cc @Paul Denning @Neelima Karipineni
Lloyd McKenzie (Apr 29 2021 at 21:15):
Sounds like Immuniation.manufacturer should change to CodeableReference in R5. In R4, you could use an extension. Vaccine manufacturer codes definitely don't belong in Immunization.vaccineCode.
Rob Hausam (Apr 29 2021 at 21:19):
I agree with Lloyd on that. I looked at MVX again when I updated CVX in tx.fhir.org - and MVX is pretty clearly an identifier system rather than a code system (although in the past both of them have typically tended to be lumped together in the "code system" bin).
Lloyd McKenzie (Apr 29 2021 at 21:24):
In that case, it could go into Reference.identifier
Max Masnick (Apr 29 2021 at 21:24):
I thought about using an extension, but that uses up a lot of our very limited payload to fit inside a QR code:
"extension":[{"url":"code","valueCodeableConcept":{"coding":[{"system":"http://hl7.org/fhir/sid/mvx","code":"MOD"}]}}]
vs
{"system":"http://hl7.org/fhir/sid/mvx","code":"MOD"}
Max Masnick (Apr 29 2021 at 21:25):
@Neelima Karipineni identified Reference.identifier as an option, but then we lose terminology validation, right?
Max Masnick (Apr 29 2021 at 21:26):
Lloyd McKenzie said:
Sounds like Immuniation.manufacturer should change to CodeableReference in R5. In R4, you could use an extension. Vaccine manufacturer codes definitely don't belong in Immunization.vaccineCode.
What's the mechanism for suggesting this change? Jira issue against FHIR Core, R5? If so I can log an issue.
Rob Hausam (Apr 29 2021 at 21:27):
I agree with Lloyd that Reference.identifier would be a better choice - and avoids the extension overhead issue. I agree that identifier systems probably aren't being validated - that may be something that we will need have addressed.
Max Masnick (Apr 29 2021 at 21:28):
Ok, we will go with Reference.identifier until R5. Thank you both!!!
Lloyd McKenzie (Apr 29 2021 at 21:49):
Actually, it would make sense in R5 too - if we're dealing with an identifier system rather than a code system. Though the fact that the list of 'allowed' identifiers will probably be published like a CodeSystem might make CodeableReference make sense in R5. In any case, submit a change request and the group can talk about it.
Robert McClure (Apr 29 2021 at 22:02):
Folks MVX is actually a controlled list of "scoping identifiers." I think we do want it verified. I'd suggest we treat this as a code system since I suspect it is not really instance identifiers because multiple manufacturing instances are all scoped by the same MVX code. So, would you still want to use .identifier?
Grahame Grieve (Apr 29 2021 at 22:37):
MVX is pretty clearly an identifier system rather than a code system
technically, this is a case of what ISO 701 calls an 'appelation' - there is one instance of each concept, and it may be treated as either an identifier system or a code system. In this case, I think it should be a code system
Grahame Grieve (Apr 29 2021 at 22:41):
This brings up something I meant to talk about before. Given that much of the overhead of a FHIR resource is URIs, I've thought before that for a QR code, we could define a special JSON variant where we use something like @cvx in place of the full URL, and that we have a single QR Code IG that defines a list of special URL tokens like that.
@sct | @loinc | @ucum | @cvx | @rxnorm | @fhir-sd-[X} | @v2-[x] | @v3[X} | @tho-c-[X} |
I've thought about this specifically for QR Codes since you really are space limited; An alternative is not to use JSON, but something specifically denser. But maybe json + url tokens is dense enough?
Rob Hausam (Apr 29 2021 at 22:52):
I can see some argument for this. Common usage and precedent certainly could be a reason to move it to or keep it in the code system bucket. And the practical reason of validating it using the current machinery also could push it that way. Are those your reasons, or are there others?
Grahame Grieve (Apr 29 2021 at 22:53):
year - practicality. Also vaccine + manufacturer behaves quite a lot like another pattern: modality + body part. These are sometimes pre-coordinate and sometimes in separate elements.
Josh Mandel (Apr 29 2021 at 23:42):
With DEFLATE-compressed JSON (or DEFLATE-compressed CBOR), repeated URLs that share a common base compress quite well, but lots of unique text does poorly. It's helpful to run some tests to develop intuition. If we really want these contextual expansions, JSON-LD has a built-in mechanism (but this kind of thing gets complex quickly)
Max Masnick (Apr 30 2021 at 00:35):
So if MVX is considered a code system, what are the implications for sticking it in Immunization.manufacturer vs. in Immunization.vaccineCode?
Max Masnick (Apr 30 2021 at 00:54):
For the purposes of the SMART Health Card Vaccination use case, the concept of a "vaccine" is defined by what information is necessary for a Verifier of the SMART Health Card to determine if the person receiving a specific vaccine is considered vaccinated. In other words, the data identifying the vaccine has to be specific enough to distinguish two vaccines that would potentially be treated differently by Verifiers.
This data definitely will need to include more than just "mRNA vaccine for COVID" -- this is not sufficient because the Pfizer and Moderna vaccines have different timelines for the 2nd dose, and boosters will also come into question. Verifiers will need to know this info because they might accept two Pfizer doses spaced by 21 days, but not two Moderna doses spaced by 21 days.
Right now CVX indicates manufacturer implicitly, but this may not always be the case: in the future, multiple manufacturers will make the "COVID-19, mRNA, LNP-S, PF, 100 mcg/ 0.5 mL dose" vaccine (CVX 207) since Moderna is allowing others to use their IP. This is how other vaccines work with CVX -- see the influenza CVX for example. But if for some reason a specific manufacturer's vaccine is shown to be ineffective, Verifiers will want to be able to take this into consideration. So manufacturer is explicitly part of our concept of "vaccine" for our use case.
Given all this, and that ideally MVX should be treated as a code system, does Reference.identifier still make the most sense?
Re: extensions, in addition to the payload size concerns, I think we want to avoid extensions if possible because they increase complexity for implementers (especially those new to FHIR, which we expect will be a number of our implementers).
Lloyd McKenzie (Apr 30 2021 at 01:01):
Reference.identifier is semantically correct. CodeableReference will be better in R5
Rob Hausam (Apr 30 2021 at 11:45):
Yes, agree - I think that's still the answer.
Craig Newman (Apr 30 2021 at 13:15):
If someone creates a Jira ticket to make .manufacturer a CodeableReference for R5, I'll add it to the agenda for the PUbic Health WG Immunization call on May 21st (http://www.hl7.org/concalls/CallDetails.cfm?concall=54996). We'll be talking about other manufacturer related changes and all are welcome to come and discuss.
Paul Denning (Apr 30 2021 at 14:24):
https://jira.hl7.org/browse/FHIR-32031 created
Craig Newman (Apr 30 2021 at 17:42):
Thank you. I added it to the agenda for May.
Robert McClure (Apr 30 2021 at 22:23):
I'm fine with this approach, and making MVX a code system.
Rob Hausam (May 01 2021 at 04:08):
I'll work on adding support for MVX as a code system on tx.fhir.org.
Carol Macumber (May 06 2021 at 17:15):
@Rob Hausam was this support for MVX added? I don't see it in the list of terminologies supported when I do http://tx.fhir.org/r4/metadata?mode=terminology, If not, can you comment as to when you think it might be added?
Rob Hausam (May 06 2021 at 21:46):
It's not there yet. I can probably get to it by tomorrow for my part. Then once that's done, Grahame will need to push it to the tx.fhir.org server.
Paul Denning (May 07 2021 at 13:55):
Grahame Grieve said:
This brings up something I meant to talk about before. Given that much of the overhead of a FHIR resource is URIs, I've thought before that for a QR code, we could define a special JSON variant where we use something like @cvx in place of the full URL, and that we have a single QR Code IG that defines a list of special URL tokens like that.
@sct | @loinc | @ucum | @cvx | @rxnorm | @fhir-sd-[X} | @v2-[x] | @v3[X} | @tho-c-[X} |I've thought about this specifically for QR Codes since you really are space limited; An alternative is not to use JSON, but something specifically denser. But maybe json + url tokens is dense enough?
That would be especially nice if we add AIR https://www.humanservices.gov.au/organisations/health-professionals/enablers/air-vaccine-code-formats as considered here (PR here )
and even nicer if @air could be a tiny url (but I guess if the actual URL for @air or @sct etc is in an IG and not in the QR code FHIR bundle a tiny url is not needed)
Rob Hausam (Jun 01 2021 at 05:16):
The MVX code system (CodeSystem resource) has been added to the packages repository. It now needs to be loaded by Grahame on tx.fhir.org (that should happen soon).
Carol Macumber (Jun 14 2021 at 20:51):
@Rob Hausam I don't see MVX listed here http://tx.fhir.org/r4/metadata?mode=terminology? Am i looking in the wrong place?
Rob Hausam (Jun 14 2021 at 23:21):
No, you're looking in the right place, @Carol Macumber. There is a step between getting the content committed to repository (which has been done) and when it is loaded and becomes available in tx.fhir.org, which at preseent I don't have control over (and I can't do anything further with it to make that happen or speed it up).
Grahame Grieve (Jun 14 2021 at 23:48):
published
Rob Hausam (Jun 17 2021 at 12:18):
@Carol Macumber Confirming that MVX is now available as a code system on tx.fhir.org.
Jay Lyle (Oct 20 2021 at 17:16):
Grahame Grieve said:
a special JSON variant where we use something like @cvx in place of the full URL
Any more thought on this? Looks a lot like JSON-LD, which could be useful for a variety of things.
Grahame Grieve (Oct 20 2021 at 17:55):
if you're interested in json-ld you should have a look at what the RDF group is doing, but json-ld raises many challenging issues that are outside the scope of a spec.
Grahame Grieve (Oct 20 2021 at 17:55):
but no, doing something like @cvx didn't get any traction
Last updated: Apr 12 2022 at 19:14 UTC
