Stream: argonaut
Topic: Race extension
Nick George (May 13 2019 at 18:01):
Question about the Patient Race/ethnicity extensions: Why do these use repeated Codings with bound systems, as opposed to repeated Codes with bound systems (as seems to be more common in the main spec). http://hl7.org/fhir/us/core/StructureDefinition-us-core-race.html
Is there a meaningful difference between a coding with a bound system and a code with a bound system?
Nick George (May 13 2019 at 18:22):
I guess coding can have other metadata like veresion. is that the main reason?
Lloyd McKenzie (May 13 2019 at 18:26):
I'm not aware of any place we have repeated 'code' elements, but if that were to exist, all repetitions would have to be tied to the same value set. With repeated codings, the sender can identify the code and the system - and thus can extract codes from the desired code system from among repetitions pointing to other code systems. Coding is the data type that allows identification of the system and thus is what typically gets used.
Nick George (May 13 2019 at 18:35):
yeah but it has a required binding on the coding, so all of the codes would have to have the same code system anyway
Nick George (May 13 2019 at 18:36):
(that's sort of my point - if the system is bound to the same system for all the codings, why not have codes instead of codings)
Lloyd McKenzie (May 13 2019 at 18:37):
Ah, I see. Yeah, that's rather weird. The only way that would make sense is if they were drawing from multiple code systems and there were overlaps in the codes between the code system in the value set they wanted to draw from. @Brett Marquard @Eric Haas Thoughts on why Coding was chosen instead of code or CodeableConcept?
Brett Marquard (May 13 2019 at 19:14):
pretty sure the inclusion of nullFlavor pushed us to coding. The repeat of the 'categories' in both is because folks can be in multiple categories
Eric Haas (May 13 2019 at 19:15):
I think it is also to align with CCDA
Lloyd McKenzie (May 13 2019 at 19:46):
You don't need to go to coding just because you draw from multiple code systems. What matters is that you can infer the system from the code within the value set.
Lloyd McKenzie (May 13 2019 at 19:46):
Aligning with CCDA shouldn't be a driver in the choice of data type...
Nick George (May 13 2019 at 22:06):
I'd have a similar question if it were a CodeableConcept... My understanding is that the point there is to allow for multiple codings from multiple different systems. So if there's a required binding to a single valueset, why not have repeated coding?
Lloyd McKenzie (May 13 2019 at 22:08):
If there's a required binding on a CodeableConcept, that says that one of the codings needs to match the binding - but the others are free to point to any other codes.
Nick George (May 13 2019 at 22:09):
oh interesting
Nick George (May 13 2019 at 22:11):
that almost seems more like a slicing on the codeableconcept
Lloyd McKenzie (May 13 2019 at 22:14):
It's a shortcut to slicing the CodeableConcept and declaring a 1..1 slice with a required binding
Nick George (May 13 2019 at 22:50):
yeah except with no slicename, which makes it a little tougher to refer to
Nick George (May 31 2019 at 21:09):
reviving this thread - does a repeated Coding with a required binding mean ALL codes in that fields are from that binding, or AT LEAST ONE?
Nick George (May 31 2019 at 21:10):
for context, looking at http://hl7.org/fhir/us/core/STU2/StructureDefinition-us-core-race.html here
Rob Hausam (May 31 2019 at 21:22):
It's as Lloyd said - at least one of the Codings in the CodeableConcept must be from the value set that is bound to the element (with the required binding), as documented here.
Nick George (May 31 2019 at 21:22):
that's for CodeableConcepts, no?
Nick George (May 31 2019 at 21:23):
here we're talking about 0..* Coding
Rob Hausam (May 31 2019 at 21:23):
yes
Nick George (May 31 2019 at 21:23):
which is a lot like a codeable concept, but not one
Rob Hausam (May 31 2019 at 21:23):
oh, sorry - I didn't look at the reference directly
Nick George (May 31 2019 at 21:24):
having repeated Coding with a bound system feels weird to me, like it should be either 0..* Code, or 0..1 CodeableConcept
Nick George (May 31 2019 at 21:26):
because if it were 0..* Code with a required binding, it would mean "All codes should be from this valueset", and if it were 0..1 CodeableConcept with a required binding, it would say, "At least one should be from this valueset". I don't know how to interepret a repeated Coding with a required binding
Rob Hausam (May 31 2019 at 21:28):
What I see is that valueCoding in both cases is 1..1, but the encompassing 'extension' cardinalities are either 0..5 or 0..* - in both of those cases each instance of valueCoding must have a code from the bound value set (no exceptions).
Nick George (May 31 2019 at 21:29):
ah good point. In that case, why not use Code?
Nick George (May 31 2019 at 21:30):
(with a required binding)
Rob Hausam (May 31 2019 at 21:33):
Yeah, that's a good question for the extension author(s). The data type would be 'code' - I'm not seeing any reason to use 'Coding' here - 'code' would be simpler and likely clearer.
Nick George (May 31 2019 at 21:34):
do you know who/where would be an appropriate place to raise that?
Rob Hausam (May 31 2019 at 21:34):
Well, I assume probably it would be on this stream. @Eric Haas @Brett Marquard?
Rob Hausam (May 31 2019 at 21:41):
Actually, now that I think about it a bit more, since these are external (not FHIR defined) code systems with non human readable codes there could be value in using Coding since you can also include the display string. That may be the reason, and probably is a legitimate consideration.
Nick George (May 31 2019 at 21:44):
wouldn't you define the display string on the valueset-level? in other words once per code instead of once per code-use
Nick George (May 31 2019 at 21:45):
the race valueset already defines some display info https://build.fhir.org/ig/HL7/US-Core-R4/ValueSet-omb-race-category.html
Nick George (May 31 2019 at 21:46):
(that's the R4 version but it's the same in the published STU3)
Rob Hausam (May 31 2019 at 21:52):
The display string is typically defined by the code system. It is defined once per code, but it can be carried in each Coding instance. It can also be specified in the value set (for enumerated, i.e. extensional, value set definitions), but if it's already defined in the code system you wouldn't normally do that and would just use the display string that the code system provides.
Nick George (May 31 2019 at 21:58):
yeah, so I'm not sure why we'd need Coding here to carry an extra display string since we have it on the race valueset itself
Rob Hausam (May 31 2019 at 22:00):
Right. You don't need it. The question is do you (or does somebody) want it (in the instances)?
Lloyd McKenzie (May 31 2019 at 23:29):
I think the usecase is that some implementations may need to send additional codes conveying more detail - from varying code systems. However, apparently there's zero use for original text (which I personally find surprising).
Grahame Grieve (May 31 2019 at 23:32):
you should be a smell a regulatory agenda at play here
Nick George (May 31 2019 at 23:35):
Not sure I follow Lloyd, how does that work if the binding is required?
Lloyd McKenzie (May 31 2019 at 23:40):
One of the Codings must meet the binding. The others don't have to. Though I suspect we don't explicitly address this case in the spec. Feel free to submit a change request
Nick George (May 31 2019 at 23:42):
hmm, that doesn't quite make sense to me - because then the validation would have to "cross" extension lines - within a single extension with uri "ombCategory", there is only a single Coding, and that Single coding has a required binding
Nick George (May 31 2019 at 23:42):
for what you're describing, shouldn't it be a single CodeableConcept?
Nick George (May 31 2019 at 23:42):
that way the "at least one coding with this binding" applies to a single extension, as opposed to applying across many extensions
Nick George (May 31 2019 at 23:49):
it would sort of make sense if the required binding were on a 0..* Coding, although I'd still argue that a codeableconcept might be clearer. But I feel like having a required binding on a 1..1 Coding pretty strongly implies that that Coding has to have that binding
Lloyd McKenzie (May 31 2019 at 23:57):
The binding isn't on the Coding. It's on the element - which has a type of 0..* Coding. The binding is satisfied for the element so long as one of the Codings match.
Nick George (May 31 2019 at 23:58):
hmm, not sure we're looking at the same thing. I'm talking about Extension.extension:ombcategory.valueCoding
Nick George (May 31 2019 at 23:58):
http://hl7.org/fhir/us/core/STU2/StructureDefinition-us-core-race.json.html
Nick George (May 31 2019 at 23:59):
which has 1..1 Coding, and a required binding
Nick George (Jun 01 2019 at 00:01):
it's the extension that has 0..* cardinality, so you'd have to apply the binding to the extension element, which would also be pretty odd.
Eric Haas (Jun 01 2019 at 00:07):
Codeable Concept does not work here. Here is a tracker were I explain it ( once a agiain ) It is heavily tied to US Regs and alignment with CCDA and this extension has been carefully crafted to meet that.
I am concerned with what Lloyd is suggesting since there is no wiggle room on the bindings - every coding repeat needs to be from the valueset.
Nick George (Jun 01 2019 at 00:09):
That would make much more sense to me in terms of what the current Structure Definition says, since it's 1..1 with a required binding, that seems to me to imply that every coding would be from the valueset. But in that case, why not use Code?
Eric Haas (Jun 01 2019 at 00:10):
I forget but I think either regulatory requirement or ccda alignment
Nick George (Jun 01 2019 at 00:16):
fair enough, thanks. I'd be curious to know why Coding was chosen over Code, if there's any documentation/tracker items I could read
Grahame Grieve (Jun 01 2019 at 01:12):
t's on the element - which has a type of 0..* Coding. The binding is satisfied for the element so long as one of the Codings match
I disagree with this. We make that statement about CodeableConcept - where the binding is on the CodeableConcept, not the Coding. We do not make any other similar statement, where constraints on a 0..* element need only be met by one of the elements
Lloyd McKenzie (Jun 01 2019 at 04:49):
@Grahame Grieve I agree we don't make that statement. However, if you have a 0..* Coding element that has a binding, it'd be super-foolish to say that the binding has to apply to all of the repetitions.
Lloyd McKenzie (Jun 01 2019 at 04:50):
@Nick George I misunderstood the situation. Obviously you're right - the cardinality on valueCoding would have to be 1..1, and thus the binding would inevitably apply to all of them. I'm not really sure what the point is of the multiple occurrences on the extension. Perhaps so you can declare more than one?
Grahame Grieve (Jun 01 2019 at 04:57):
if you have a 0..* Coding element that has a binding, it'd be super-foolish to say that the binding has to apply to all of the repetitions.
unless that was exactly what you wanted, as in this case. I think you should just restrict yourself to saying 'this is an idea with very limited utility' and perhaps 'I don't like the regulatory analysis that lead to this requirement' though of course you and I have no grounds for an opinion on this one. (but if you really want, you should read Eric's analysis first)
Lloyd McKenzie (Jun 01 2019 at 19:08):
Criticism accepted. In this case, the cardinality is actually 1..1 rather than 0... However, it's probably worth evaluating the intention of other places in the resoruces where we have 0.. Coding with a required or extensible binding. The places where this occurs are as follows:
AuditEvent.subtype
AuditEvent.source.type
AuditEvent.entity.securityLabel
Consent.provision.securityLabel
Consent.provision.purpose
Consent.provision.class
ImagingStudy.modality
StructureDefinition.keyword
We also have the following locations which don't have a fixed or extensible binding in the core spec, but where such a binding could be asserted in a profile:
Contract.term.securityLabel.category
Contract.term.securityLabel.control
Questionnaire.code
Questionnaire.item.code
So, the question is: What behavior should apply for these elements? All codings must come from the bound value set, or "at least one" must come from the bound value set?
John Moehrke (Jun 01 2019 at 20:21):
Hmm, I feel I am being picked on given that the majority of these are mine. Did something change that I didn't know about and adjust the model?
Mostly mine are Extensible bindings, meaning nothing more than we want the values in the valueset to be used if they apply. I don't see why that is not clear. If the vocabulary value applies, it should be used... if it does not then use other codes as you want to. How is this a problem?
For Required binding, I see this slightly more problematic.
John Moehrke (Jun 01 2019 at 20:25):
I have always read the Extensible as something NOT testable at the recipient side. How can a recipient know that the meaning the sender intended did NOT fall into one of the Extensible vocabulary values. SO I have always seen Extensible as a recommendation on the sender.
Required could be seen more strictly at the recipient.
Lloyd McKenzie (Jun 01 2019 at 20:47):
@John Moehrke Not picking on or criticizing - but certainly wanting to understand intent. Specifically, is the desire that repetitions represent multiple items all of which must share the binding, or is the intention that repetitions represent different encodings of the same item and only one needs to satisfy the binding?
John Moehrke (Jun 01 2019 at 22:32):
I was not seriously worried about being picked on.... Can't say that we thought about repetition at all. As I indicated before, the binding is just a desire for use of the vocabulary in the valueset, specifically to avoid creativity at defining a new vocabulary value that has the meaning already given to a vocabulary value.
Lloyd McKenzie (Jun 01 2019 at 22:44):
Extensible is more than just "a desire". It's mandating. If someone is communicating a concept that your code covers, there's no choice but to use the code you've chosen. Can you go through your elements and think about whether translations are appropriate and/or whether multiple non-translation codes are appropriate.
Nick George (Jun 28 2019 at 22:18):
I filed https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=22781 about this, specifically back to the Argonaut extension http://hl7.org/fhir/us/core/STU3/StructureDefinition-us-core-race.html
Nick George (Jun 28 2019 at 22:21):
It's certainly possible and in fact probable I'm missing some subtlety, but my understanding would be to say Codings should only have bindings within codeableconcepts, and for "free radical" fields with bound system it should be Code not Coding
Nick George (Jun 28 2019 at 22:21):
am I missing something with that?
Nick George (Jun 28 2019 at 22:22):
framed like that, I'm not sure if it matters if it's 0..1 or 1..1 or 0..*, either way, if it's a known and _required_ binding, why not use Code?
Eric Haas (Jun 28 2019 at 23:31):
I’ll discuss on the Argo R4 call. There is a lot going on with these extensions and I’ll try dig up the history. This is not an error it was done with intent and I really think it is tied into CCDA US realm header.
Grahame Grieve (Jul 05 2019 at 22:33):
@Nick George I generally agree with what you say but the race extension appears to live in one of the corners where a free Coding is appropriate
Nick George (Jul 16 2019 at 20:18):
@Grahame Grieve any insight into why?
Eric Haas (Jul 16 2019 at 20:43):
@Brett Marquard and I were the primary ones who created these extensions. And looking back it was to align with CCDA's US Realm Header.
e.g.
<!-- CDC Race and Ethnicity code set contains the five minimum
race and ethnicity categories defined by OMB Standards -->
<raceCode code="2106-3" displayName="White" codeSystem="2.16.840.1.113883.6.238" codeSystemName="Race & Ethnicity - CDC" />
It seemed to make sense at the time, even though in hindsight it may have been overkill and I frankly don't think changing it now is worth the implementer headaches of having to map between versions.
Yunwei Wang (Jul 18 2019 at 15:55):
IMO, using coding increase the human readability. Comparing these two extensions,
{
"url": "ombCategory",
"valueCode": "2106-3"
},
and
{
"url": "ombCategory",
"valueCoding": {
"system": "urn:oid:2.16.840.1.113883.6.238",
"code": "2106-3",
"display": "White"
}
},
Apparently, the 2nd one is more human readable.
Nick George (Jul 18 2019 at 16:47):
well, codes with bound valuesets are very common throughout the spec, so it wouldn't be a strange thing to have here, readability-wise
Lloyd McKenzie (Jul 18 2019 at 17:21):
In general, if you're going to use code, the code itself should be readable and understandable by a developer. (That's why the gender codes are "male", "female" rather than "01", "02" or something like that.) It's not a hard and fast rule, but it's certainly a good practice.
Yunwei Wang (Jul 18 2019 at 18:42):
another reason for using Coding vs Code, I assume everyone knows, is that to avoid code collision/conflict.
Lloyd McKenzie (Jul 18 2019 at 19:29):
If you're using 'code', then the binding must be fixed and the value set must be one where there are no code collisions.
Last updated: Apr 12 2022 at 19:14 UTC
