Stream: conformance
Topic: Can a derived profile insert new named slices?
Michel Rutten (Jun 04 2018 at 17:07):
I am trying to fix some reported Forge issues and need a bit of clarification on new named slices in derived profiles.
A derived profile can introduce new named slices to an existing slice group.
By default, the new slices are appended to the existing named slices in the base profile.
Example 1:
Base profile:
- Patient.identifier
- Patient.identifier:foo
- Patient.identifier:bar
Derived profile differential:
- Patient.identifier:baz
=> Derived profile snapshot:
- Patient.identifier
- Patient.identifier:foo
- Patient.identifier:bar
- Patient.identifier:baz <= Append new named slice after all existing named slices
I am wondering if FHIR also allows a derived profile to _insert_ new named slices into an existing (ordered) slice group?
Example 2, with same base profile:
Derived profile differential:
- Patient.identifier:baz
- Patient.identifier:foo
=> Derived profile snapshot:
- Patient.identifier
- Patient.identifier:baz <= Insert new named slice before "foo" ?
- Patient.identifier:foo
- Patient.identifier:bar
This would require the snapshot generator to perform some kind of "peek ahead",
which seems quite complicated to implement reliably and without breaking any existing behavior (if possible at all...?).
So first I'd like to verify whether FHIR even allows this.
I guess this also depends on the exact definition of an ordered slice group.
http://hl7.org/fhir/elementdefinition-definitions.html#ElementDefinition.slicing.ordered
"If the matching elements have to occur in the same order as defined in the profile."
Assuming the slice group in the base profile above is ordered, what is the correct interpretation?
Interpretation 1:
If an instance contains a "foo" slice, it cannot not be preceded by any other slice (i.e. must be the very first slice).
If an instance contains a "bar" slice, it can only be preceded by a "foo" slice (i.e. must be first or second slice).
=> other named slices may only occur after any "foo" and/or "bar" slices.
=> a derived profile is only allowed to append new named slices, not insert them.
Interpretation 2:
If an instance contains both "foo" and "bar" slices, then "foo" must preceed "bar" (not necessarily immediate neighbours)
=> other named slices may occur before, in between or after "foo" and "bar".
=> a derived profile is allowed to introduce new named slices in any position.
Questions:
- What is the correct interpretation of an "ordered" slice?
- Does FHIR allow derived profiles to _insert_ new named slices (such as in Example 2)?
Grahame Grieve (Jun 04 2018 at 18:20):
have you seen build\tests\resources\snapshot-generation-tests.xml ?
Grahame Grieve (Jun 04 2018 at 18:23):
it doesn't include that, so we can say with confidence that it's not tested behaviour
Grahame Grieve (Jun 04 2018 at 18:24):
certainly if the slice is ordered, you cannot insert
Grahame Grieve (Jun 04 2018 at 18:24):
if the slicing is not ordered, I don't see what the need for inseertion is
Michel Rutten (Jun 05 2018 at 09:18):
certainly if the slice is ordered, you cannot insert
That answers my question. Thanks Grahame.
Rob Hausam (Jun 05 2018 at 19:26):
Just for clarity here, we have both (1) if the slice is ordered, you cannot insert and (2) if the slicing is not ordered there is no need or use for insertion (my slight paraphrase). So, basically it would make sense to disallow insertion and to allow append and handle them the same whether the slicing is ordered or unordered, correct?
Michel Rutten (Jun 06 2018 at 09:52):
Hi @Rob Hausam, indeed, I drew the same conclusion.
Michel Rutten (Jun 06 2018 at 09:53):
This also ensures that the logic is actually implementable, which is kinda nice.
Rob Hausam (Jun 06 2018 at 14:44):
yes
Last updated: Apr 12 2022 at 19:14 UTC
