Stream: tooling
Topic: Forge: Slicing usign the same type
Diego Bosca (Jul 10 2019 at 14:52):
I've been trying to slice an observation value[x] using the same type (Quantity) to create an alternative. Discriminator is the code of the Quantity.
Problem seems to be that Forge puts a fixed value in the Slice name as soon as I select the type, which cannot be changed. If I introduce a slice of the same type the same fixed value is applied to the Slice name, thus giving me a "duplicate slice name" error. Is this forbidden in FHIR somehow or is just a tool limitation?
Richard Townley-O'Neill (Jul 11 2019 at 03:10):
If you want to place constraints on valueQuantity that depend upon the value of valueQuantity.code, I expect that you have to slice valueQuantity on code.
I do not know if that works.
Diego Bosca (Jul 11 2019 at 08:02):
Thought about that, but then I'm not sure I would be able to define other constraints on each slice
Richard Townley-O'Neill (Jul 12 2019 at 05:28):
In theory, you can slice valueQuantity on code and then say sliceA is: "when code ='a', condition 1 applies" and sliceB is "when code='b' condition 2 applies".
Does that help?
Diego Bosca (Jul 12 2019 at 07:22):
I think I get what you say, but I'm not sure how to put that kind of conditional slices in Forge
Diego Bosca (Jul 13 2019 at 17:19):
I haven't been able to create it in forge, as it won't allow me to change the slicename. This is what I have (with error as they both have same slicename)
<differential> <element id="Observation.value[x]"> <path value="Observation.value[x]"/> <slicing> <discriminator> <type value="value"/> <path value="code"/> </discriminator> <rules value="open"/> </slicing> </element> <element id="Observation.value[x]:valueQuantity"> <path value="Observation.valueQuantity"/> <sliceName value="valueQuantity"/> <type> <code value="Quantity"/> </type> </element> <element id="Observation.value[x]:valueQuantity.code"> <path value="Observation.valueQuantity.code"/> <fixedCode value="kg"/> </element> <element id="Observation.value[x]:valueQuantity"> <path value="Observation.valueQuantity"/> <sliceName value="valueQuantity"/> <type> <code value="Quantity"/> </type> </element> <element id="Observation.value[x]:valueQuantity.code"> <path value="Observation.valueQuantity.code"/> <fixedCode value="g"/> </element> </differential>
If I were to adjust the slicename manually to make them different it would be correct or I need to do something else?
Diego Bosca (Jul 13 2019 at 18:27):
Even if I change it from outside Forge and I open it then it shows the same error, as Forge seems to ignore the slicename in this case and makes both alternatives to have slicename valueQuantity
Richard Townley-O'Neill (Jul 15 2019 at 02:10):
You have defined two slices with the same discriminator value of "Quantity": one at line 13 and one at line 24.
Slices MUST be distinct, and these are not.
Try one slice with discriminator value = "Quantity" and in that slice say that valueQuantity.code can be either "kg" or "g".
Diego Bosca (Jul 15 2019 at 06:48):
but then other constraints such as the minimum/maximum value cannot be different.
They are different alternatives that can be distinguished by the code, so I assumed that the discriminator could just point to that
Richard Townley-O'Neill (Jul 15 2019 at 23:31):
In your example the cardinalities are the same.
If you want different cardinalities for kg and g, make the discriminator more complex, e.g. type and code, and then say that for the slice where type = quantity and code = kg, so an so applies.
Michel Rutten (Jul 16 2019 at 10:11):
Hi @Diego Bosca, Forge automatically renames a polymorphic element (name ending with "[x]") when constrained to a single type, and also assigns/updates the associated slice name. We've received some reports from customers that this behavior prevents modeling some advanced scenario's using slicing. I am going to look into this to see if we can improve the UI to support this.
Diego Bosca (Jul 16 2019 at 10:16):
Great! I think it's needed when defining alternatives from the same type
Michel Rutten (Jul 16 2019 at 15:49):
Indeed. I will solicit some guidance from the core team on how to handle such scenarios.
Last updated: Apr 12 2022 at 19:14 UTC
