Stream: IG creation
Topic: IG Publisher error: slice does not repeat
Brian Reinhold (Sep 17 2018 at 21:29):
I keep getting this error "Attempt to a slice an element that does not repeat: Observation.effective[x]/Observation.effective[x] ..."
Well, the element clearly repeats but I cannot figure out the proper syntax (obviously) for the case when one of the slices is a primitive.
Here is my structure definition for the Observation.effective[x]
<!-- Effective: The time stamp -->
<element id="Observation.effective[x]">
<path value="Observation.effective[x]" />
<slicing>
<discriminator>
<type value="type" />
<path value="$this" />
</discriminator>
<rules value="open" />
</slicing>
<definition value="The time or time-period the observed value is asserted as being true. It is a time period if a Measure-Active-Period (duration) attribute is part of the metric measurement sent by the PHD. Otherwise it is the time stamp sent by the PHD or the time of reception by the PHG if the PHD sent no time stamp." />
<min value="1" />
<type>
<code value="dateTime"/>
</type>
<type>
<code value="Period"/>
</type>
</element>
<!-- Time stamp: Instant -->
<element id="Observation.effective[x]:dateTime">
<path value="Observation.effective[x]" />
<sliceName value="dateTime" />
<short value="The time stamp of the measurement" />
<definition value="The time stamp of the measurement when the measurement is taken at an instance in time" />
<comment value="A date and time or period shall always be present but not both." />
<min value="1" />
<type>
<code value="dateTime" />
</type>
<!-- it seems like this should not be here; remove it makes no difference -->
</element>
<element id="Observation.effective[x]:dateTime.effectiveDateTime">
<path value="Observation.effectiveDateTime" />
<min value="1" />
</element>
<!-- Time stamp: Period -->
<element id="Observation.effective[x].effectivePeriod">
<path value="Observation.effectivePeriod" />
<sliceName value="effectivePeriod" />
<short value="The time period of the measurement" />
<definition value="The time period of the measurement when the measurement has a duration. The duration of the measurement is reported in a Measure-Active-Period attribute. The difference between the end and start fields is the value of the Measure-Active-Period." />
<type>
<code value="Period" />
</type>
</element>
<element id="Observation.effective[x]:effectivePeriod.start">
<path value="Observation.effectivePeriod.start" />
<min value="1" />
</element>
<element id="Observation.effective[x]:effectivePeriod.end">
<path value="Observation.effectivePeriod.end" />
<definition value="The end of the period. It will be the value of the Measure-Active-Period plus the start time." />
<min value="1" />
</element>
I have tried so many combinations but either IG publisher hangs or I get the above error. (Some of my combinations were just shots in the dark ... signs of desperation.) Anybody see something obviously wrong? I am pretty sure it is the first slice (the primitive) that is causing the problem.
Lloyd McKenzie (Sep 17 2018 at 21:30):
It may actually be a bug with the IGPublisher. Not sure anyone's tried to do that before, though it should be legal. @Grahame Grieve, thoughts?
Brian Reinhold (Sep 17 2018 at 21:32):
It may actually be a bug with the IGPublisher. Not sure anyone's tried to do that before, though it should be legal. @Grahame Grieve, thoughts?
@Lloyd McKenzie Does my slicing look right? I am concerned about slicing a primitive. Do I have a superfluous element for the effectiveDateTime case?
Just for interest, the slicing is due to the PHD time stamp. The time stamp can be an instant in time (most common) or a Period (such as an exercise session). The latter is very common in fitness PHDs.
Grahame Grieve (Sep 17 2018 at 22:18):
what repeats?
Brian Reinhold (Sep 17 2018 at 22:53):
what repeats?
The publisher states that my slice does NOT repeat. But it does ... I have two slices. One for an instant in time, and another for a period of time.
Rick Geimer (Sep 17 2018 at 23:17):
Maybe I am missing something here, but Observation.effectiveTime[x] has a cardinality of 0..1, so the element itself can't repeat (i.e. you can't have both effectiveDateTime and effectivePeriod in the same Observation instance). Is that what you are trying to do, or are you trying to accomplish something else with your slices?
Brian Reinhold (Sep 17 2018 at 23:19):
Maybe I am missing something here, but Observation.effectiveTime[x] has a cardinality of 0..1, so the element itself can't repeat (i.e. you can't have both an instant in time and a period of time in the same Observation instance). Is that what you are trying to do, or are you trying to accomplish something else with your slices?
@Rick Geimer It's one or the other, never both. I am not quite sure I have set that up correctly. I may need some conditional but I am unsure of the syntax.
Maybe its something like this in the top level effective[x]
<constraint>
<key value="phd-obs-1"/>
<!-- Some time stamp SHALL be present -->
<severity value="error"/>
<human value="Either an effectiveDateTime or effectivePeriod shall be present"/>
<expression value="effectiveDateTime.exists() or effectivePeriod.exists().exists()"/>
</constraint>
I tried this constraint and the IG publisher no longer gave me that error
Lloyd McKenzie (Sep 17 2018 at 23:46):
It's legitimate to slice non-repeating elements
Brian Reinhold (Sep 17 2018 at 23:50):
It's legitimate to slice non-repeating elements
@Lloyd McKenzie Not what I expected but from a comment by Rick I added a constraint that either an effectiveDateTime or an effectivePeriod must exist, (but not both). This stopped the ' no repeat ' error message and the IG Publisher processed my base resource structure definition. Now I am hanging on processing the next resource which 'inherits' the base resource. I am not sure I have done that correctly. I am porting from Forge and the two may reference base resources in different ways.
Lloyd McKenzie (Sep 18 2018 at 00:00):
A constraint should make any difference to how the snapshot generator functions...
Grahame Grieve (Sep 18 2018 at 00:00):
It's legitimate to slice non-repeating elements
Grahame Grieve (Sep 18 2018 at 00:00):
no it's not
Grahame Grieve (Sep 18 2018 at 00:01):
this is docmented here:
Grahame Grieve (Sep 18 2018 at 00:02):
http://build.fhir.org/elementdefinition.html#typesx
Richard Townley-O'Neill (Sep 18 2018 at 00:15):
I don't see the prohibition of slicing a single element stated on that page.
However the page refers to http://build.fhir.org/profiling.html#slicing which includes "... to take an element that may occur more than once (e.g. in a list), and then split the list into a series of sublists, each with different restrictions on the elements in the sublist with associated additional meaning. In FHIR, this operation is known as "Slicing" a list."
Lloyd McKenzie (Sep 18 2018 at 00:35):
This says that you can implicitly slice polymorphic elements by type and don't use the slicing mechanism to do so. I still thought we supported slicing non-repeating elements. E.g. allowing you to say that a non-repeating element needs to follow constraint set X or Y
Michel Rutten (Sep 18 2018 at 06:50):
I wasn't aware that slicing is apparently only allowed for repeating elements... why would cardinality be a limiting factor?
Brian Reinhold (Sep 18 2018 at 08:33):
I wasn't aware that slicing is apparently only allowed for repeating elements... why would cardinality be a limiting factor?
@Michel Rutten You can't slice on a non-repeating element and end up with two entries in a given structure. But I thought you could slice on a choice element. In this case there will be only one choice in the final structure but that choice may be different depending. I tried to do the latter on an Observation.effective[x] element. I know the PoCD IG slices on an Observation.value[x] element with the choice being a valueQuantity or a valueRatio.
I thought this might be done by using <max value="1" /> in the first element. That states there can only be one such entry. In any case putting in the constraint solved the problem. The constraint is also clearer for the implementer because it specifically spells out the condition. In my case there SHALL be an effective[x] and it shall be either a dateTime or a Period but not both.
If I could slice on a non-repeating element I would slice on the Observation.device element and have one entry point to the PHD endpoint and the other entry point to the PHG endpoint. But that I cannot do. So to reference the PHG endpoint I need an extension.
Rob Hausam (Sep 18 2018 at 08:39):
If the current participants in this conversation aren't clear about the rules on this, then that's somewhat concerning. As Lloyd said and Brian agreed, I understood that you can slice polymorphic (choice) elements by type - I've done that and it will validate.
Michel Rutten (Sep 18 2018 at 08:42):
A resource instance is only allowed to specify (at most) a single value for a non-repeating element. However a StructureDefinition can introduce different options, e.g. for a non-repeating choice type element. Technically, I think we could also handle slicing on non-repeating fixed type elements - however I don't think any current tools allow/support that.
Michel Rutten (Sep 18 2018 at 08:42):
e.g. allow slicing on Observation.device
Brian Reinhold (Sep 18 2018 at 08:47):
A resource instance is only allowed to specify (at most) a single value for a non-repeating element. However a StructureDefinition can introduce different options, e.g. for a non-repeating choice type element. Technically, I think we could also handle slicing on non-repeating fixed type elements - however I don't think any current tools allow/support that.
@Michel Rutten I think that's where I made my error in my attempt. I did not properly indicate in my slicing that there was a maximum of only one entry. @Rick Geimer pointed out that there could only be one entry and from my struct definition he did not interpret it as restricting it to only one entry. So I tried a constraint in the first element and that worked. It amazes me the IG publisher could interpret that. The other possible way would be to put <max value="1" /> in the first element. THat seems more straight forward. I am going to give that a whirl and see if it works. It should.
Brian Reinhold (Sep 18 2018 at 08:49):
If the current participants in this conversation aren't clear about the rules on this, then that's somewhat concerning. As Lloyd said and Brian agreed, I understood that you can slice polymorphic (choice) elements by type - I've done that and it will validate.
@Rob Hausam Did you indicate in your slicing that there could only be one entry in the final structure? I think that's where I failed...I did not properly do that. And I am very much of a newbie at writing Structure Definitions by hand so I still have a lot of learning to do.
Michel Rutten (Sep 18 2018 at 08:51):
The cardinality of the slicing introduction element limits the total number of allowed elements. If this equals 0...1, then the sliced element cannot repeat. Cardinality of individual named slices cannot relax this.
Brian Reinhold (Sep 18 2018 at 08:54):
The cardinality of the slicing introduction element limits the total number of allowed elements. If this equals 0...1, then the sliced element cannot repeat. Cardinality of individual named slices cannot relax this.
@Michel Rutten So are you saying that my structure definition slicing should have worked? (its listed above). I did not put a <max value="1" /> in it because that is required and I placed no constraint. It failed. The constraint made it work. I am going to try the <max > alone now without the constraint.
Results:
<max value="1" /> alone works
<constraint> alone (where only one or the other slice is allowed) also works
<constraint> and <max> above together also works
neither <max> or <constraint> causes the slice on a non-repeating element to occur.
So I have to specify in my <differential> that the maximum number of effective[x] entries is one even though it is part of the base definition (usually you don't). Do that or put in the restricting constraint.
Michel Rutten (Sep 18 2018 at 09:04):
Currently, FHIR only defines slicing on repeated elements and choice type elements. I don't think you are allowed to slice non-repeating fixed type elements. However I think that this is not a technical limitation, i.e. seems feasible to implement.
Brian Reinhold (Sep 18 2018 at 09:13):
Currently, FHIR only defines slicing on repeated elements and choice type elements. I don't think you are allowed to slice non-repeating fixed type elements. However I think that this is not a technical limitation, i.e. seems feasible to implement.
@Michel Rutten okay, that's a slight different issue. I was not having a problem trying to slice a non-repeating element but a choice element. One of the choices was a primitive and that's where I got stuck. I see examples of slicing on choices where both choices are non-primitives but I did not know how to reduce it to a case where one was a primitive. One has fewer options in the primitive case.
In the end there is still something funny going one. If I specify '<max value="1" /> it works. But the base structure definition already does this.
Michel Rutten (Sep 18 2018 at 09:20):
I've used Forge to re-create your slice:
<element id="Observation.effective[x]">
<path value="Observation.effective[x]"/>
<slicing>
<discriminator>
<type value="type"/>
<path value="$this"/>
</discriminator>
<rules value="open"/>
</slicing>
<min value="1"/>
</element>
<element id="Observation.effective[x]:effectiveDateTime">
<path value="Observation.effective[x]"/>
<sliceName value="effectiveDateTime"/>
<min value="1"/>
<type>
<code value="dateTime"/>
</type>
</element>
<element id="Observation.effective[x]:effectivePeriod">
<path value="Observation.effective[x]"/>
<sliceName value="effectivePeriod"/>
<type>
<code value="Period"/>
</type>
</element>
<element id="Observation.effective[x]:effectivePeriod.start">
<path value="Observation.effective[x].start"/>
<min value="1"/>
</element>
<element id="Observation.effective[x]:effectivePeriod.end">
<path value="Observation.effective[x].end"/>
<min value="1"/>
</element>
Brian Reinhold (Sep 18 2018 at 09:26):
@Michel Rutten That's what I started with (though I had more descriptive elements like <short ...> and <definition ..>). The only major difference is that I also specified the types in the first element
<type>
<code value="dateTime"/>
</type>
<type>
<code value="Period"/>
</type>
But this gave me the non-repeating error. I need to add (at minimum) a <max value="1" /> element in the first element.
Michel Rutten (Sep 18 2018 at 09:27):
Looks like a bug in the IG Publisher. The type information & cardinality seem redundant, because inherited from the base element as-is.
Brian Reinhold (Sep 18 2018 at 09:31):
Looks like a bug in the IG Publisher. The type information & cardinality seem redundant, because inherited from the base element as-is.
That maybe the case. All my profiles were originally created in Forge. They are the profiles submitted in the IG used in the first ballot with the knowledge they would need to be updated to a later version of FHIR. Now I need even a later version of FHIR (with the Device merge) so I am taking all those old profiles and trying to modify them to work in 3.6.0. It has forced me to learn a lot of detail that I was previously spared....and I have a ways to go!
Grahame Grieve (Sep 18 2018 at 11:16):
we changed the sway we constrain choices types after evening sessions at WGMs over the last 3 meetings, and confirmed it in cologne.
Grahame Grieve (Sep 18 2018 at 11:16):
what's the bug?
Brian Reinhold (Sep 18 2018 at 11:19):
what's the bug?
@Grahame Grieve If there is a bug it is because I need to specify in my initial slicing on a choice element that there is <max value="1" />. That is already defined in the base Observation. Usually you don't have to do that if it is a differential.
Michel Rutten (Sep 18 2018 at 11:20):
Indeed, slicing choice types is clearly defined. The behavior reported by Brian seems like an unrelated issue.
Brian Reinhold (Sep 18 2018 at 11:23):
Indeed, slicing choice types is clearly defined. The behavior reported by Brian seems like an unrelated issue.
@Michel Rutten Not sure if it is unrelated. If I do not do that, I get an error. I don't recall any statement saying I have to specify a max of 1 when slicing a choice (or putting a constraint such that there is only one). Regardless, I would like to know what is technically correct.
Michel Rutten (Sep 18 2018 at 11:27):
In your case, the cardinality constraint on the slicing intro appears to be redundant (not invalid!). But apparently this constraint needs to be specified explicitly nonetheless, in order to work around an issue in the IG Publisher. Once the issue is fixed, you could remove the redundant constraint.
Michel Rutten (Sep 18 2018 at 11:28):
I wouldn't worry too much about including redundant constraints, as they don't change the meaning of the profile.
Lloyd McKenzie (Sep 18 2018 at 15:01):
We have a shortcut for unrolling polymorphic types that doesn't technically use slicing. However, there shouldn't be a rule that prohibits slicing non-repeating elements. For example, I could slice Patient.managingOrganization and say that you can either have a reference + display or identifier + display, but not other combination.
Grahame Grieve (Sep 18 2018 at 20:23):
we specifically made that rule - you can't slice non-repeating elements
Lloyd McKenzie (Sep 18 2018 at 20:25):
Why does that rule exist? Why is it necessary?
Grahame Grieve (Sep 18 2018 at 20:25):
it was a long discussion. You were part of it
Grahame Grieve (Sep 18 2018 at 20:29):
which is to say, do I have to dig all that up?
Lloyd McKenzie (Sep 18 2018 at 20:51):
I remember the discussion about special processing for polymorphic types. I don't recall discussion on saying that slicing doesn't make sense for maxOccurs 1 elements or why doing that is technically hard.
Brian Reinhold (Sep 18 2018 at 21:23):
we specifically made that rule - you can't slice non-repeating elements
choice elements are often non-repeating and those can be sliced. However, when doing so there is an implicit condition that only one of the slices can ever be instantiated at a time. One can't have two value elements in a single Observation!
Brian Reinhold (Sep 19 2018 at 19:32):
I ran into the same problem slicing on a value[x], in this case value[x] could be a dateTime or a Quantity. Again I was able to solve it by specifying in the element where the slice is defined <max value="1" />. I was befuddled for a while because it wasn't working until I noted that I had typed <max value="!" />. Arrg!
Last updated: Apr 12 2022 at 19:14 UTC
