Stream: fhir/infrastructure-wg
Topic: Is there a difference between value or pattern slicing?
Marco Visser (Oct 24 2019 at 13:16):
When I read the specs at https://www.hl7.org/fhir/profiling.html#discriminator I noticed that when we are doing value slicing or pattern slicing that
then the element definition must use either:
- ElementDefinition.fixed[x], or
- ElementDefinition.pattern[x], or
- if the element has a terminology binding, a required binding with a Value Set that enumerates the list of possible codes in the value set ("extensional definition")
I read that as follows: each ElementDefinition defining the slice must either have a fixed[x] or pattern[x] or binding constraint. If that is the case, what is then the difference between value slicing and pattern slicing?
In the FHIR .NET Api, we only allow the fixed[x] and binding constraint for a value slicing and a pattern[x] constraint for the pattern slicing. But I have the feeling that is not correct. Am I right?
Lloyd McKenzie (Oct 24 2019 at 15:45):
Value must match exactly - no extra elements or extensions. Pattern must match what's specified but is free to have extra elements including extra repetitions. As a result, pattern is usually better.
Chris Moesel (Oct 24 2019 at 16:26):
Note however that the documentation for pattern[x] states:
In general, pattern[x] is not intended for use with primitive types, where is has the same meaning as fixed[x].
So if you're fixing a primitive, fixed[x] is preferred.
Chris Moesel (Oct 24 2019 at 16:28):
As it relates to slicing, it's also helpful to consider that if you're fixing more than one part of a complex type (like code and system in a CodeableConcept or Coding), then using pattern[x] allows you to have a simpler (single) discriminator rather than two discriminators. It also prevents you from needing to use slicing when fixing code/system of a CodeableConcept.
Lloyd McKenzie (Oct 24 2019 at 16:52):
It doesn't quite have the same meaning as 'fixed. A pattern would allow extensions on the primitive. A fixed value would not.
Grahame Grieve (Oct 24 2019 at 17:24):
I feel as though we haven't actually answered the question. I don't know off the top of my head what the validator does, but I agree with this in principle:
we only allow the fixed[x] and binding constraint for a value slicing and a pattern[x] constraint for the pattern slicing
Chris Moesel (Oct 24 2019 at 19:32):
It doesn't quite have the same meaning as 'fixed. A pattern would allow extensions on the primitive. A fixed value would not.
Right -- which is why it probably says "in general". But in practice, I haven't seen too many primitives with a pattern[x]. That said, I think it might be helpful to actually state that meaningful distinction in the spec itself so people understand exactly what they're disallowing when using fixed[x] with a primitive.
Lloyd McKenzie (Oct 24 2019 at 19:39):
I might go so far as to raise a warning when someone slices be value instead of by pattern.
Chris Moesel (Oct 24 2019 at 19:41):
I don't know off the top of my head what the validator does, but I agree with this in principle:
we only allow the fixed[x] and binding constraint for a value slicing and a pattern[x] constraint for the pattern slicing
Section 5.1.0.11 makes it fairly clear that the pattern discriminator type must be accompanied by the pattern[x] construct. In the first table it says:
pattern: The slices have different values in the nominated element, as determined by testing them against the applicable ElementDefinition.pattern[x].
It doesn't state that value corresponds directly (and only) to fixed[x] however. And the following language makes it sound kind of ambiguous:
If the type is value, or pattern, then the element definition must use either:
- ElementDefinition.fixed[x], or
- ElementDefinition.pattern[x], or
- if the element has a terminology binding, a required binding with a Value Set that enumerates the list of possible codes in the value set ("extensional definition")
I think associating value to fixed[x] makes sense (and is most implementable) -- but it would complicate a hypothetical situation in which a set of elements uses pattern[x] to apply expected codes (Coding or CodeableConcept) but the slices should discriminate on the code system only.
Grahame Grieve (Oct 24 2019 at 20:33):
note from the #conformance stream - there's a use case for mixing pattern and binding?
Grahame Grieve (Oct 24 2019 at 20:33):
I'm not actually sure that differentiating pattern and value on the discriminator makes sense - we can delegate that to the slices, and decide that value and pattern are effectively synonyms?
Lloyd McKenzie (Oct 24 2019 at 23:56):
Not sure I understand what you're proposing @Grahame Grieve?
Grahame Grieve (Oct 25 2019 at 00:00):
at present there is no way to mix pattern and value set binding in a single set of slices
Grahame Grieve (Oct 25 2019 at 00:01):
but we also have an anti-pattern here: we say at the start of the slicing whether it's a value or a pattern, and then have value or pattern fields - I can't see how that's useful.
Lloyd McKenzie (Oct 25 2019 at 00:31):
So your proposal is to merge the slicing types (or more specifically to deprecate one, given that it's already normative) and to allow valueset, fixed and pattern to all be used by the same slicing type? I could live with that. (Would still like to spit out warnings or at least "good practice" alerts whenever someone uses 'fixed'.
Grahame Grieve (Oct 25 2019 at 00:42):
I think that something like that would make more sense
Ardon Toonstra (Oct 25 2019 at 11:48):
The proposal sounds ok to me. So wich type is normative, value?
( I believe we described a use case for mixing pattern and valueset binding here: zulip chat )
Lloyd McKenzie (Oct 25 2019 at 13:01):
Both are. We'll have to deprecated one. And if we see it, we'll treat it the same as the other
Ardon Toonstra (Oct 29 2019 at 07:43):
Shall I create a gforge ticket? Or does one already exists?
Grahame Grieve (Oct 29 2019 at 09:12):
I don't think one does
Ardon Toonstra (Nov 12 2019 at 11:46):
Ardon Toonstra (Feb 28 2020 at 14:10):
Here the link to the ticket on Confluence: https://jira.hl7.org/browse/FHIR-25206
@Grahame Grieve , do you know the status of this issue? Wasn't this already discussed with FHIR-I?
Grahame Grieve (Feb 28 2020 at 18:41):
doesn't look like it?
Alexander Zautke (Mar 01 2020 at 12:52):
Could we discuss this issue in one of the next FHIR-I calls? @Ardon Toonstra and I could make sure that everyone relevant for the discussion from Firely is present.
Last updated: Apr 12 2022 at 19:14 UTC
