Stream: implementers
Topic: profiling & Binding Strengths
natus (May 18 2017 at 21:14):
Hi,
Reading the documentation here https://www.hl7.org/fhir/terminologies.html#strength
Irrespective of the binding strength, when a StructureDefinition is used to describe local usage, it can bind the element to a different value set in order to be much more precise about exactly which coded values can be used for these elements, and/or increase the strength of the binding.
Does it mean that this situation would be conformant :
1) Defining a profiled Encounter, where class valueSet would be distinct from https://www.hl7.org/fhir/v3/ActEncounterCode/vs.html while Encounter.class is defined as "Extensible"
2) Defining a profiled Patient, where gender would have code in "alien_female" while Patient.gender is "required"
Thanks by advance
Lloyd McKenzie (May 19 2017 at 03:32):
If the binding was extensible, you can bind to a value set that constrains codes out from the base value set and/or which adds new codes that aren't covered by any of the concepts in the original value set. You can also tighten the binding to 'required'. If the binding was required, you can bind to a value set that constrains out codes from the original value set, but can't introduce any new codes.
Chris Moesel (May 31 2017 at 14:40):
I haven't found anything in the spec that clearly indicates _how_ an extensible binding should be extended in a profile. Is the proper approach to create a new value set that contains the codes from the original VS and the new (non-overlapping) codes? Or is there some specific way you're supposed to indicate you are extending the original value set (and original codes are somehow inherited)?
Chris Moesel (May 31 2017 at 14:42):
Also... is it possible to add level 2 codes to an existing code in a value set with an extensible binding? In other words... if I wanted to extend ActEncounterCode and put more specific virtual codes (audio, video, async), is it possible to make them level 2 codes under the existing VR (Virtual) code?
Lloyd McKenzie (May 31 2017 at 15:03):
You just define a new valueset. There isn't a formal way of linking or establishing the relationship of the value sets. Adding child codes wouldn't be allowed in an extensible value set. That would have to be a separate binding (e.g. by slicing coding).
Mark Kramer (May 31 2017 at 15:08):
"Adding child codes wouldn't be allowed in an extensible value set." Why? It seems this would be a very appropriate way to extend a value set. Many code systems define hierarchies.
Lloyd McKenzie (May 31 2017 at 15:12):
Extensible means that if there's a code in the original value set that covers your concept, you must use that code. So if the original value set contains a code for "blue", it's not acceptable for me to send an instance with a code that says "navy blue" or "pale blue" unless I also send the code from the original value set that just says "blue". Thus the only way to introduce the notions of "navy blue" or "pale blue" is with a separate binding - ensuring that the expectation to send the code "blue" is still reflected.
Mark Kramer (May 31 2017 at 15:15):
I don't understand how sliding Coding gets you there. There is nothing to slice in Coding (no arrays). But you could send both "blue" and "navy blue" in a CodeableConcept.
Lloyd McKenzie (May 31 2017 at 15:18):
I meant slice CodeableConcept.coding so you can specify additional bindings
Chris Moesel (May 31 2017 at 17:39):
Unfortunately, Encounter.class is a 0..1 Coding, not a CodeableConcept, so there is no way to apply slicing to allow us to identify more specific types of virtual encounters.
Lloyd McKenzie (May 31 2017 at 20:02):
Then you'll have to use an extension if you want to convey more nuance than the original value set - or argue to have the binding relaxed in a future version.
Grahame Grieve (May 31 2017 at 23:34):
and ask why it is not a CodeableConcept - unusual....
Robert McClure (Jun 04 2017 at 15:46):
@Lloyd McKenzie I want to confirm a couple of items regarding your thinking on this:
1) Extensible means you can can not use a different code that is "a kind of" one of the current codes.
2) Any change from the originally defined value set must be identiffied by a new identifier - a url in the case of FHIR.
3) If you want to send "navy blue" when "blue" is in the original value set with extensible binding, I must create "a new binding." Can you explain what that would mean and how it's different than if you change the value set 'in an extensible-conformant' way - for example, remove two codes and add two new one that are "not a kind of". Again, I assume this 'extensible-conformant' new value set would have a new url but would not "have a new binding."
What I'm not exactly following is the technical details used to identify that these different changes are occurring. This is the sort of thing we need to capture for our binding semantics work (and why you need to attend!)
NB: I want to understand the technical approach for all this before we get into how a computer, or a person can determine when a desired concept "is a kind of" something in the value set already so that to use this new concept they need to follow approach A versus approach B.
Lloyd McKenzie (Jun 04 2017 at 17:36):
1. More specifically, it means you can't satisfy the binding with a code from outside the value set that has an "is-a" relationship with one of the codes inside the value set. It doesn't mean such a code can't be present, only that it can't satisfy the binding
2. Not sure what you mean here. Codings are identified with a combination of system (url) and code. If you send a code outside valueset in an extensible binding, those might be codes from systems already found in the value set or from other code systems.
3. More specifically, if you're dealing with a CodeableConcept - which allows you to send multiple codings, you can define an additional binding by slicing CodeableConcept.coding. If you're dealing with Coding or code, you're up the creek as you can only send one code with those. With CodeableConcept, you can send one coding that complies with the original binding and additional codings that comply with other bindings.
Grahame Grieve (Jun 04 2017 at 19:51):
with regard to (3) - you create a new value set with a new URL (per (2)) - and now you have to change the binding to point to your replacement value set. I'm not sure what you mean by 'new value set but not a new binding'
Grahame Grieve (Jun 04 2017 at 19:52):
often, in this case, as well as changing the value set in the binding, you up the binding strength to required
Lloyd McKenzie (Jun 04 2017 at 23:25):
In 3, if you want a value set that includes "navy blue", then you're going to have to have a binding to the original value set (which must be satisfied in the instance) and a binding to a second value set - which also must be satisfied by the instance. It wouldn't be possible to have an instance that only contained the code "navy blue" and was valid.
Brian Postlethwaite (Jun 05 2017 at 03:11):
Encounter.class is an extensible binding, so you can include additional more refined values in the set.
Lloyd McKenzie (Jun 05 2017 at 03:40):
Extensible doesn't allow for more refined values, only for concepts that don't fit within the valueset at all. If a concept is expressible using the value set at any granularity, the code from the original value set must be used - you can't introduce a narrower one and satisfy the binding.
Lloyd McKenzie (Jun 05 2017 at 03:41):
(If that rule weren't in place, 'extensible' would be no different than 'recommended')
Grahame Grieve (Jun 05 2017 at 03:44):
it would be a little different
Lloyd McKenzie (Jun 05 2017 at 04:00):
Not much. You'd have to argue that the code meant exactly the same thing - which is near-impossible to do across code systems.
Richard Townley-O'Neill (Jun 05 2017 at 05:58):
One way to follow Lloyd's suggestion for a nuanced value, navy-blue rather than blue, is to add an new data element, say colorDetail, with a value set that includes values like navy-blue and sky-blue. Then a resource instance could have color="blue" colorRefined="navy-blue"
Lloyd McKenzie (Jun 05 2017 at 06:49):
If the data type isn't a CodeableConcept, then adding an extension is indeed pretty much your ownly choice.
Last updated: Apr 12 2022 at 19:14 UTC
