Stream: IG creation
Topic: Slicing vital signs bp
Richard Townley-O'Neill (Feb 27 2020 at 05:29):
This is in STU3.
We have profiled the vital signs bp profile. We want to add slices for SNOMED CT to code, component:SystolicBP.code and component:DiastolicBP.code.
Richard Townley-O'Neill (Feb 27 2020 at 05:33):
When I have added a slice to component:SystolicBP.code.coding and component.DiastolicBP.code.coding, the validator rejects my examples with the errors:
Richard Townley-O'Neill (Feb 27 2020 at 05:34):
Error in discriminator at Observation.component:SystolicBP.code.coding: found a sliced element while resolving the fixed value for one of the slices
and
Error in discriminator at Observation.component:DiastolicBP.code.coding: found a sliced element while resolving the fixed value for one of the slices
Richard Townley-O'Neill (Feb 27 2020 at 05:35):
But it does not have any trouble with the new slice on code.coding.
Strange.
Richard Townley-O'Neill (Feb 27 2020 at 05:37):
The validator will accept my example if the profile makes all 4 instances of component.code.coding.code 1..1.
I think that all elements in the discriminator should be required in slice definitions, so I am surprised that slicing works with code.coding optional.
Richard Townley-O'Neill (Feb 27 2020 at 05:42):
tl:dr: Why does the validator treat differently additional slices to Observation.code.coding and Observation.component.code.coding, in a profile derived from Vital SIgns BP?
Richard Townley-O'Neill (Feb 27 2020 at 05:47):
The profile behind this is NCDHC Blood Pressure(BP) Vital Sign Observation Profile.
It uses the solution mentioned above: it makes all 4 instances of component.code.coding.code 1..1. And also makes the instances of code.coding.code 1..1.
Richard Townley-O'Neill (Feb 28 2020 at 00:04):
@Lloyd McKenzie @Grahame Grieve
Why does the validator treat differently additional slices to Observation.code.coding and Observation.component.code.coding, in a profile derived from Vital SIgns BP?
Grahame Grieve (Feb 28 2020 at 01:15):
because you have sliced the component on the code
Lloyd McKenzie (Feb 28 2020 at 01:15):
Submit a change request re: whether all elements in a slice discriminator path should be at least minOccurs=1
Grahame Grieve (Feb 28 2020 at 01:17):
they don't all have to be, they just have to be distinct
Grahame Grieve (Feb 28 2020 at 01:17):
the problem here is that the base profile doesn't slice on component.code, it slices on component.code.coding.code
Lloyd McKenzie (Feb 28 2020 at 01:17):
But in the discriminator, why would it make sense to list something with a fixed value that's optional
Grahame Grieve (Feb 28 2020 at 01:19):
it you have more than one path, you might have slices where one element fully differentiates and another is not used when that happens, but for some slices, the first element has a non-differentiating value and the second element is populated and differentiating. Address often works like this on use + type
Richard Townley-O'Neill (Feb 28 2020 at 01:21):
It now makes sense to me that components of the discriminator can be optional.
Richard Townley-O'Neill (Feb 28 2020 at 01:26):
OK. The slicing that is breaking is the slicing of component, not of component.coding.
Thanks.
Richard Townley-O'Neill (Feb 28 2020 at 01:30):
Can the error message be improved to clarify that the problem is with component and not component.coding?
Lloyd McKenzie (Feb 28 2020 at 01:38):
My point is that if I set a fixed value for use in a single slice and it's a discriminator, it should be 1..1.
Lloyd McKenzie (Feb 28 2020 at 03:16):
So @Richard Townley-O'Neill can you submit a change request with respect to that bit?
Grahame Grieve (Feb 28 2020 at 03:20):
with respect to what?
Grahame Grieve (Feb 28 2020 at 03:20):
I'm not sure I can improve the error message
Grahame Grieve (Feb 28 2020 at 03:20):
the underlying issue is more serious - what does it mean to try and do what is being done here? it seems reasonable to add a slice, but what is the impact on the other slicing?
Lloyd McKenzie (Feb 28 2020 at 03:22):
That if you're setting a fixed value in a particular slice to satisfy a discriminator, elements from the base of the slice to the fixed value element need to be minOccurs of 1+.
Grahame Grieve (Feb 28 2020 at 03:25):
I don't know what this means:
elements from the base of the slice to the fixed value element
Lloyd McKenzie (Feb 28 2020 at 03:28):
If you're slicing on Observation.code by coding.code and coding.system, then a slice that declares fixed values for coding.code and coding.system better also declare minOccurs of 1 on Observation.code.coding, Observation.code.coding.code and Observation.code.coding.system
Lloyd McKenzie (Feb 28 2020 at 03:29):
It's not sensible to have a slice where you're declaring fixed values for elements where the slice would match if the elements were omitted entirely.
Grahame Grieve (Feb 28 2020 at 03:31):
well, I don't entirely agree. That was my point above. It's certainly sensible that code.coding would be 1+ but it's not necessary for both code and system to have values
Richard Townley-O'Neill (Feb 28 2020 at 03:31):
Observation.code is 1..1, do you mean
slicing on Observation.code.coding. by code and system, then a slice that declares fixed values for coding.code and coding.system better also declare minOccurs of 1 on Observation.code.coding,
Lloyd McKenzie (Feb 28 2020 at 03:55):
It's totally fine if they don't both have values. But if they do have values, they should be 1..x
Lloyd McKenzie (Feb 28 2020 at 03:56):
So, for example, you could have a slice where coding is 1..x and system is 1..1 and has a fixed system; you could have a slice where coding is 1..x and code is 1..1 and has a fixe code; you could have a slice where coding is 0..0 and no fixed values at all.
Lloyd McKenzie (Feb 28 2020 at 03:57):
But you can't have a slice where coding is 0..x and system is 0..1 and code is 0..1 and code and system have fixed values. (Which the validator is totally happy with at the moment.)
Richard Townley-O'Neill (Feb 28 2020 at 04:11):
I previously expected that optional elements in the discriminator would break slicing. But, now I think of the lack of an element as just another "value".
Richard Townley-O'Neill (Feb 28 2020 at 04:11):
Lloyd McKenzie said:
But you can't have a slice where coding is 0..x and system is 0..1 and code is 0..1 and code and system have fixed values. (Which the validator is totally happy with at the moment.)
I do not follow why optional and fixed value needs to be a problem. Defining a slice with an optional element claims that the slice includes instances without the element. If that element has a fixed value, it means that the only choices are no value or the fixed value.
Lloyd McKenzie (Feb 28 2020 at 04:29):
In what situation would it make sense to say "This slice matches if the value corresponds to the fixed value or if it's absent"? That's going to be exceptionally rare. And having designers do it by accident is going to be exceptionally common. So I'd much rather have the rule and in the exceptionally rare case, have to define two slices with identical constraints for the fixed value and no value cases.
Richard Townley-O'Neill (Feb 28 2020 at 04:55):
I agree that is is confusing.
I had not thought of the fact that mistaken use will be more common than informed use, but I agree, it will be.
Richard Townley-O'Neill (Feb 28 2020 at 04:58):
So a rule would be
In a slice, at lest one part of the discriminator will have a value
Lloyd McKenzie (Feb 28 2020 at 05:00):
No, it's valid for one slice to be one where none of the discriminators have a value. My rule is that an element that is part of a value-based discriminator has a fixed value, then that element and all elements along the path from the slice root have to be mandatory (minOccurs=1+)
Richard Townley-O'Neill (Feb 28 2020 at 05:01):
What happens if it is part of a pattern-based discriminator?
Lloyd McKenzie (Feb 28 2020 at 05:17):
Pattern-based would presumably require min=1 for nodes between the slice and the pattern too, though because they can use pattern, there wouldn't typically be many nodes (if any) where that would be relevant
Last updated: Apr 12 2022 at 19:14 UTC
