Stream: terminology
Topic: Extensible bindings when data type = Coding
Lloyd McKenzie (Jul 16 2018 at 23:36):
Per https://chat.fhir.org/#narrow/stream/4-implementers/subject/Use.20of.20Meta.2Etag.20vs.20Request.2Eintent, we're looking at making the binding for Resource.meta.tag "extensible" instead of "example" - on the grounds that we really want people to use the specific codes we've defined (shortly to be 2 codes) for the purposes we've defined. However, the notion of "extensible" gets a bit more complicated when the data type is Coding. If an element is CodeableConcept and the binding is extensible, then it's not a problem to send a code from the extensible value set plus a more nuanced code from your local space if need be. However, if the data type is 'Coding', then that means that if your concept is covered by the bound value set, you have no choice but to use only the code from the extensible value set and can't use one of your own. That's not ideal. But changing the data type for tags to CodeableConcept isn't ideal either. Opinions?
Grahame Grieve (Jul 16 2018 at 23:53):
it means you have to be careful which concepts you define in the extensible value set
Lloyd McKenzie (Jul 17 2018 at 00:25):
I'm not sure how "be careful" eliminates the possibility of some implementer somewhere wanting more nuance/fine-grained expression?
Richard Townley-O'Neill (Jul 17 2018 at 04:47):
Use an extension to capture local codings, as that is a local need.
Lloyd McKenzie (Jul 17 2018 at 13:39):
That works. :)
Robert McClure (Jul 17 2018 at 16:55):
@Richard Townley-O'Neill and @Lloyd McKenzie Help me understand how the use of extensions to modify an 'extensible' binding is intended to impact use of the original (non-extended) expansion set. From what you've just said it seems implementers can just use an extension to the resource and bind to a new value set with different values and ignore the original value set. And the new value set can have codes that have a nuanced different meaning then the original expansion members so the implementer never has to send the original codes if they don't want to. Is that correct?
Lloyd McKenzie (Jul 17 2018 at 21:05):
We would define an extension on Coding that allows conveying translations. So you could send a coding (that would need to be valid against the extensible binding) but could send additional codings as translations that conveyed more nuance.
Grahame Grieve (Jul 17 2018 at 21:16):
it's not clear to me why this is a problem. Let's stick to the case in hand, and say that we define a tag for 'authoritative', and bind to it extensibly.
Grahame Grieve (Jul 17 2018 at 21:16):
and then some user has some tag 'authoritative because boss says so' or something.
Grahame Grieve (Jul 17 2018 at 21:16):
why is it wrong to have two tags, one for each?
Lloyd McKenzie (Jul 17 2018 at 21:31):
Extensible says "if a code from the value set applies, you must send that code and not some other". In CodeableConcept.coding, the codings are translations, so it's fine to send other codes too. In tag, other codings aren't considered translations, which, unless we provide guidance to the contrary, means that the "extensible" requirement is evaluated on each coding independently.
Grahame Grieve (Jul 17 2018 at 21:38):
I think that this is a different thing; what you're trying to do is different to an classic extensible binding in some subtle but important ways
Lloyd McKenzie (Jul 17 2018 at 21:55):
Not sure. I'm not sure I want someone sending "authoritative because boss says so" and not sending HL7's "authoritative" code - which is what extensible is for.
Grahame Grieve (Jul 17 2018 at 22:17):
so we're saying that we want to say to use the authoritative code in one of the codings it if applies. i don't see that we have any reason to say 'and don't use a more specific code' and I don't see why we want to apply this rule to all codings either
Grahame Grieve (Jul 17 2018 at 22:21):
in fact, I think the frame of reference is wrong; we have a hammer, so things are going to be a nail. but actually, we don't want to say anything about the binding, we want to say something about the meaning... this is one of a few places in the infrastructure this happens - big wide open use cases, and some very specific rules about particular codes for particular meanings
Lloyd McKenzie (Jul 17 2018 at 22:27):
The problem seems rather nail-like... It's a Coding. It has a binding. We want to say "if you're trying to say something like this, you must use our codes, but you're free to say whatever other sorts of coded things you like that aren't covered by our codes using whatever code systems you like". That's exactly what Extensible does, so I don't see how this is different - and I think using a different mechanism is going to cause confusion and non-conformance.
Richard Townley-O'Neill (Jul 18 2018 at 02:14):
If I want to send codes for both 'authorised' and 'authorised because boss says so' in a CodeableConcept element I could send it as two codings in the one element, or as two instances of the element. Is the difference important? Do implementers pay attention to the difference?
In a Coding element I would send two instances of the element. Or one element with an extension on Coding.
From what Lloyd says, if the Coding element has an extensible binding it is prohibited to send the two codes ('authorised' and 'authorised by boss says so') as two instances of the element.
Why is this a good approach to extensibe on coding? Is this because there is no structural relationship between the codes?
Lloyd McKenzie (Jul 18 2018 at 03:55):
Typically CodeableConcepts have a maxOccurs of 1. If it can repeat, then each repetition is considered to be a separate concept - and each repetition must independently adhere to the binding.
Lloyd McKenzie (Jul 18 2018 at 03:56):
If we follow the same logic with repeating Codings - that each repetition must adhere to the binding, then the only way to convey a more granular concept than allowed with the extensible binding would be with an extension.
Grahame Grieve (Jul 18 2018 at 03:58):
which isn't actually what we want in this case
Michael Lawley (Jul 19 2018 at 05:30):
The binding is to a ValueSet definition rather than a ValueSet expansion, right? Then make sure the ValueSet definition says include.filter.code is-a 'authorised' and not include.filter.code = 'authorised' or include.concept = 'authorised' (forgive my pseudo-code)
Last updated: Apr 12 2022 at 19:14 UTC
