Stream: IG creation
Topic: Binding vs Slicing one coded field for multiple value sets
Jean Duteau (Apr 27 2020 at 19:16):
I have a coded field and I want to specify two different bindings - one to be used for different Codings. Is the best way to do this to slice the coded field and bind the Codings to the value sets?
Rob Hausam (Apr 27 2020 at 19:30):
@Jean Duteau I think you should be able to do this at the element level rather than having to do it on the Coding (which I don't think you want to do to preserve the flexibility of the CodeableConcept). We're doing quite a few of these in the IPS IG, and it seems to work pretty well. Here's an example on AllergyIntolerance.code. I think it may be similar to what you are wanting to do.
Jean Duteau (Apr 27 2020 at 19:37):
Okay, I thought I'd have to go into the Coding, but your example shows I can keep it at the element level. I'll follow that example. Thanks yet again Rob!
Lloyd McKenzie (Apr 27 2020 at 20:47):
Does that pass the validator? You're slicing something that doesn't repeat and isn't polymorphic...
Lloyd McKenzie (Apr 27 2020 at 20:47):
(@Grahame Grieve )
Rob Hausam (Apr 27 2020 at 20:54):
Yes, what we're doing with it in IPS does pass the validator just fine (even if it's just blindly ignoring what we're doing). It at least is rendered pretty nicely by the publisher. We've had this discussion before, and I'm pretty sure I can locate some documentation on it (at least in Zulip, if not elsewhere).
Grahame Grieve (Apr 28 2020 at 00:12):
I don't understand that slicing at all
Lloyd McKenzie (Apr 28 2020 at 02:40):
Is it valid based on our rules? And if not, any clue why the validator isn't blowing up?
Grahame Grieve (Apr 28 2020 at 02:40):
it's technically valid, I just think it's (a) semantically wrong and (b) non-sensical
Jean Duteau (Apr 28 2020 at 02:41):
Okay, then do you have a better answer for my original question?
Grahame Grieve (Apr 28 2020 at 02:42):
yes you slice the coding, and bind the two codings differently
Jean Duteau (Apr 28 2020 at 02:42):
ok, so my original idea. :)
Lloyd McKenzie (Apr 28 2020 at 02:44):
I think the biggest problem is that the same repetition in an instance shouldn't be able to be valid against multiple slices - the validator ought to yell about that for any instance example that has both codings with the current model. @Rob Hausam - have you tested that?
Grahame Grieve (Apr 28 2020 at 02:48):
looking again, the root element is 0..1 so it shouldn't be able to be sliced
Rob Hausam (Apr 28 2020 at 03:08):
OK, I don't mind being "wrong" about this, but if so it would be good to have a clear explanation of why that is really the case. Can we flesh out the details beyond just "(a) semantically wrong and (b) non-sensical"? I don't think either of those are actually (or at least not necessarily) true. If slicing the Coding is "better", let's clearly explain how that works and why that is. I (and we in IPS) have a reason why we have arrived at this slicing and have felt that it is useful. And, whatever we think about it, the validator currently doesn't generate any warnings or errors from it, including on instance validation. We do have a few "This element does not match any known slice defined in the profile ..." qa information messages (some or all of which may be related to this slicing, but that's not absolutely clear at the moment) - but that is all. We have had some discussion previously (on Zulip or otherwise) that has at least raised the question of whether slicing a non-repeating, non-polymorphic is legitimate. It's pretty clear that wasn't the original idea with slicing, but it doesn't seem nearly so clear if it is expressly prohibited (or whether it should be). So let's discuss it further.
Lloyd McKenzie (Apr 28 2020 at 03:17):
Slicing is allowed in two places - if an element repeats (in which case the slices define the behavior allowed for different types of repetitions) or if an element is polymorphic (e.g. value[x]), in which case it sets the rules for different types. (With polymorphic slicing you must slice by type.) Slicing for non-repeating elements isn't currently supported. I would actually be happy to see slicing supported on non-repeating elements where each slice would represent an 'alternative' set of rules for what the content was allowed to be - some things get sort of miserable to nail down using invariants.) However, even in that case, multiple slices on the element wouldn't meet your objective - because slices must all be mutually exclusive - a given part of an instance can't ever match multiple slices - if that happens, it's an error. So if you want to allow (or even require) two different types of codings to be present for a single concept, you can't slice with bindings at the concept level - because that would say that an instance with a coding valid against binding 1 isn't allowed if there's a coding valid against binding 2. (Why the validator didn't yell confuses/concerns me). The level you need to disambiguate is at the level where the repetitions exist. There it's fine to have mutually exclusive rules, because for each coding the rules are indeed mutually exclusive.
Grahame Grieve (Apr 28 2020 at 03:25):
I don't follow why the value set doesn't just include the two sets of codes
Grahame Grieve (Apr 28 2020 at 03:26):
it's not the validator that would be concerned about this, it's the snapshot generator that I'm surprised it works
Rob Hausam (Apr 28 2020 at 03:27):
@Lloyd McKenzie I'm not quite sure if we've fully tested that. Our slices of this type use required bindings and are all (I'm pretty much certain) mutually exclusive, so I don't think we have run into a situation where a particular instance would be valid against multiple slices of a non-repeating non-polymorphic element. So I am not certain of the answer to that question. We can certainly test that. But we also need to think clearly about the implications (pro and con, for either the sender or the receiver) if it was possible for an instance to match (validate with) more than one slice when only a single instance is allowed.
I just read your response above while writing this. It seems that we do have "slicing supported on non-repeating elements where each slice would represent an 'alternative' set of rules for what the content was allowed to be" at least to some degree - whether that's by accident or design (but I have a hard time imagining it's purely by accident - maybe it's an unanticipated consequence of some decisions that have been made). One thing I think we should do is drill a little farther into the idea that "a given part of an instance can't ever match multiple slices" - I'm not sure if it really is (or should be) quite as black and white as that sounds. I'm not sure exactly if "you want to allow (or even require) two different types of codings to be present for a single concept" actually is related to what we're talking about here.
Rob Hausam (Apr 28 2020 at 03:30):
@Grahame Grieve The short answer is that we want the two sets of codes to be separately distinguishable and visible, but allow both (or however many there are) to be used. We expressly wanted to not mix them in a single value set for that reason. The main use is for calling out the GPS codes separately, while at the same time not mandating their use. Of course there may be some other ways to do it, and maybe some that we will think are better for what we are trying to achieve - but this basically seems like it does pretty much what we want.
Grahame Grieve (Apr 28 2020 at 03:33):
well, this is how I understand it:
- we prefer you to use snomed
- you can use just the GPS
- or you can use the Absent | unknown value set
- or you can use some other kind of absent | unknown set
- or you can use anything you want, really
Grahame Grieve (Apr 28 2020 at 03:33):
That's what you've said, I think
Rob Hausam (Apr 28 2020 at 04:03):
What you've described is not the exact set of options for every case, but it captures the general idea. We're sort of trying to be all things to all people to some degree - with the obvious downsides that tends to entail. I will say that the absent/unknown value set doesn't fit your description, of course - it's for a specific use, and is obviously not there to be used as a general alternative (like the GPS). But that aside, even though this isn't the ideal place to be, the alternatives seem worse. It would be great to be able to specify the terminologies without allowing the optionality (i.e. just tell everyone what codes they need to use for everything) - but I think all of us agree generally and I expect would agree for this specifically that we can't do that. So what we are trying to do in general is offer choices and suggest preferences where we can, and make it clear what those choices are. If we develop and implement another mechanism for allowing multiple binding declarations for an element (which we've discussed) then I'm sure we will use that - but until then I don't think I'm (yet) convinced that this isn't what we should do. But I'm open to hearing suggestions for different and better approaches - and for why this approach is "wrong".
Jean Duteau (Apr 28 2020 at 04:06):
for my problem, I'm mandating two Codings, each from a different value set, and then allowing for other translations as well.
Grahame Grieve (Apr 28 2020 at 04:15):
at least you have a simpler case
Rob Hausam (Apr 28 2020 at 04:15):
Well, I agree that is different from what we are doing, and in that case I agree that you do want to slice at the Coding level (I didn't quite pick up before that you were mandating the two Codings simultaneously, and of course that makes a difference). And using open slicing also will allow the other translation Codings.
Sarah Gaunt (Dec 17 2020 at 21:20):
I think I have pretty much the same situation as your case @Jean Duteau - wondering where you ended up with this?
This is what I've done - is this legal/allowed/sensible?
Sarah Gaunt (Dec 17 2020 at 21:21):
(BTW, we may end up grouping the value sets (or just using another value set) at some point, which might be better, but for now they are what I could find and are separate).
Sarah Gaunt (Dec 17 2020 at 21:22):
And looking at that the coding should probably be 1..1 not 1..*
Jean Duteau (Dec 17 2020 at 21:25):
that's pretty much what I did - sliced on the codings and then specified a different bindings for each slice
Eric Haas (Mar 03 2021 at 02:58):
@Jean Duteau or @Sarah Gaunt which IGs are these?
Jean Duteau (Mar 03 2021 at 05:48):
unfortunately, not a public viewable IG. sorry. but I'm pretty sure Sarah's guides still have that slicing. Look at her NHSN guides.
Rob Hausam (Mar 04 2021 at 04:11):
Previously @Jean Duteau explained that his use case for multiple slices with different value set bindings on CodeableConcept.coding was because he is mandating two Codings, with each from a different value set. That doesn't appear to be the case with what @Sarah Gaunt is doing, as neither of the two slices shown in the image are required. I'm wondering if some of you who are using this approach of multiple slices and value set bindings on CodeableConcept.coding would care to comment on what terminology behavior you intended it to achieve (and have achieved)? I'm asking because we considered this again on our IPS (International Patient Summary) call today, and it didn't seem like it was going to achieve what we were looking for. That's particularly true if we would try to use it with our Absent and Unknown Data codes, as if one of those codes was chosen then we would want to disallow the use of any of the other slices, as when multiple codes are sent in a CodeableConcept instance they must all have in general the same meaning. That probably could be done, but would likely require an invariant and would be a bit messy and tricky. So, again, it would be good to compare what we are looking at with what others are doing and considering.
Lloyd McKenzie (Mar 04 2021 at 04:17):
Multiple non-required slices allows you to set expectations for "must-support" of multiple code-systems, without glomming them all into a single value set (which isn't good practice). It can also create improved visibility into the fact that there can be multiple Codings and that multiple code systems are supported.
I wouldn't be super-fussed about someone sending an absent/unknown code in one repetition and something else in a different repetition. That's non-sensical and is really no different from sending multiple Codings representing completely different conditions, different drugs, etc. It's not the job of IGs to prevent nonsense, merely to make clear what sort of behavior applications need to support.
Lloyd McKenzie (Mar 04 2021 at 04:18):
Multiple Codings could also be used if you wanted to enforce different rules for different value sets. E.g. whether display names are required for certain ones, or even whether version must be declared for certain ones.
Lloyd McKenzie (Mar 04 2021 at 04:18):
(That said, I haven't run into anyone who's done that other than mandating 'display' for the default slice - and that wouldn't require multiple Coding slices for different value sets.)
Rob Hausam (Mar 04 2021 at 04:42):
That's a reasonable point about the absent/unknown (and other) codes in the Coding repetitions. We did all of this previously using the multiple slices at the (non-repeating) CodeableConcept element level, which I still think works and is logical and presents it visually in a nice way. But since that is disallowed we're looking at what we want to choose for our preferred alternative approach.
Sarah Gaunt (Mar 04 2021 at 04:50):
This is in an IG going to ballot in May. The only reason I considered doing this was because I found those two value sets and they work for the use case and I didn't know any other way of allowing two value sets other than doing some kind of slice. I'm actually not sure if we are going to create a new value set (though I think it's likely that we will). If/when we do that, we'll scrap the above slicing. If there's a better way/best practice, I'd be totally open to changing it.
Sarah Gaunt (Mar 04 2021 at 04:54):
ODH has done something similar here with two value sets (I helped them do this, so if it's wrong, I need to help them fix it!): image.png
Lloyd McKenzie (Mar 04 2021 at 04:57):
Your alternative would be defining a value set that includes both of the other value sets
Sarah Gaunt (Mar 04 2021 at 04:57):
In the above case, it's slightly different - the idea is that you could have a code from each of the value sets - like a translation.
Lloyd McKenzie (Mar 04 2021 at 04:58):
Sure. You could do that anyway if the binding was at the top level. But visually your approach certainly makes that clearer
Sarah Gaunt (Mar 04 2021 at 04:58):
Lloyd McKenzie said:
Your alternative would be defining a value set that includes both of the other value sets
Yes - that would work for the meds use case, but it wouldn't work for the ODH use case where they want the two separate value sets and they also want to allow both at the same time.
Sarah Gaunt (Mar 04 2021 at 04:58):
Ok, good. Sounds as though we are ok with doing it this way. Thanks!
Last updated: Apr 12 2022 at 19:14 UTC
