Stream: implementers
Topic: slicing questions
Sean McIlvenna (May 30 2017 at 16:54):
does anyone know how slicing works when you have multiple "section" elements with varying discriminators? Ex: "code" for one slice and "mode" for another slice? are you supposed to output
- element (slicing, disciminator "code")
- element (section with "code")
- element (slicing, discriminator "mode")
- element (section with "mode")
Grahame Grieve (May 30 2017 at 18:42):
between the sections, or inside the sections?
Sean McIlvenna (May 30 2017 at 20:02):
this is multiple sections, each section has a different discriminator... one having "code" as the discriminator, the other having "mode" as the disciminator. In my example bullets, that is four different <element> entries. The first being the one that describes the discriminator (slice) for "code", the second being the definition of "code", the third being the element that describes the discriminator (slice) for the section with "mode", and the fourth being the element that describes the "mode"
Lloyd McKenzie (May 31 2017 at 14:56):
I don't think you can re-slice within the same profile. Can you define it as a single set of slicing with multiple discriminators?
Sean McIlvenna (May 31 2017 at 15:40):
I'm not sure. This is something that is supported in Trifolia, and something that is done reasonably often with CDA templates. Trying to figure out how to implement the equivalent for Trifolia exports.
Sean McIlvenna (May 31 2017 at 15:41):
Is re-slicing within the same profile not supported by the spec in general, or is it the tooling that doesn't support it?
Sean McIlvenna (May 31 2017 at 15:41):
(the ig publisher, for example)
Lloyd McKenzie (May 31 2017 at 15:47):
When we slice, we slice all repetitions of an element. So re-slicing would essentially accomplish the same as multiple discriminators anyhow. I'm not sure if the spec explicitly prohibits it, but given that it doesn't allow any difference in behavior, it probably should if it doesn't
Grahame Grieve (May 31 2017 at 23:32):
no you can't re-slice. How would discriminators work then? either list all the discriminators, or give up and not list any
Sean McIlvenna (Jun 01 2017 at 15:46):
This is what I was thinking of:
Sean McIlvenna (Jun 01 2017 at 15:46):
<differential>
<element>
<path value="Composition"/>
<min value="1"/>
</element>
<element>
<path value="Composition.section" />
<sliceName value="code_slice" />
<slicing>
<discriminator>
<type value="value"></type>
<path value="code"></path>
</discriminator>
<rules value="open" />
</slicing>
</element>
<element>
<path value="Composition.section.code.coding.code" />
<sliceName value="code_slice" />
<fixedCode value="test1" />
</element>
<element>
<path value="Composition.section" />
<sliceName value="title_slice" />
<slicing>
<discriminator>
<type value="value" />
<path value="title" />
</discriminator>
<rules value="open"></rules>
</slicing>
</element>
<element>
<path value="Composition.section.title" />
<sliceName value="title_slice" />
<fixedString value="my section title" />
</element>
</differential>
Sean McIlvenna (Jun 01 2017 at 15:47):
In this case, two separate slices, with two separate discriminators...
Grahame Grieve (Jun 01 2017 at 21:04):
I don't understand why this is useful; you can't use the discriminator to discriminate, in this case. Might as well just not have any discriminators
Chris Grenz (Jun 02 2017 at 15:21):
@Lloyd McKenzie @Grahame Grieve Agree with your conclusions to Sean. However, concerned about "can't re-slice" within the same profile. Absolutely should not be true, and it's critical for slicing extensions:
Example: Patient.extension is already sliced by url. I create sliceName Patient.extension:researchAuth and then slice that extension by something: Patient.extension:researchAuth/mnResearchAuth. In other words, the only way to slice an extension is by re-slice (since the extension definition itself is the base slice).
Lloyd McKenzie (Jun 02 2017 at 15:24):
Reslicing in a derived profile is fine. But I don't understand the purposes of declaring slicing twice on the same element in the same profile.
Chris Grenz (Jun 02 2017 at 15:25):
Agree, that's not allowed. Maybe I just misunderstood the comment "I don't think you can re-slice within the same profile."
Chris Grenz (Jun 02 2017 at 15:26):
Each element may have only one slicing declaration (and therefore one set of discriminators), and that slicing definition is immutable in "child" profiles.
Lloyd McKenzie (Jun 02 2017 at 15:54):
I agree with that. I was referring to multiple slicing definitions for the same element declared in the same profile.
Sean McIlvenna (Jun 02 2017 at 18:25):
So, you don't think you should be able to say (in one profile), I expect to have a "section" like X, and another "section" like Y?
Grahame Grieve (Jun 02 2017 at 21:57):
you're already saying that in the definition of the slices. The purpose of discriminator is to say 'which fields do you look at to tell all these slices apart easily'
Eric Haas (Jun 03 2017 at 00:28):
What I understand here is that Sean is trying to have list of discriminators say:
- slice the these element based on code here AND THEN
- slice the element based on system there ( not the code) AND THEN
- slice based on some other element over there ( not the code or the system)
The ..* on the discriminator element means AND as in
based on code AND system AND some other element
Shouldn't that still work? since they will all be uniquely defined by the combination?
Lloyd McKenzie (Jun 03 2017 at 01:56):
It's perfectly fine to slice by code, then system, then something else. But you can't slice some things by code and other things by system. If code is the first discriminator, then everything gets sliced by code and only those items with the same code would be sliced by the second discriminator.
Grahame Grieve (Jun 03 2017 at 02:39):
it probably will.
Lloyd McKenzie (Jun 03 2017 at 03:01):
?
Sean McIlvenna (Jun 06 2017 at 19:39):
In this case, I'm not just looking for each element in the instance to be unique, I'm looking for each element to meet specific criteria, and not all elements will have the same set of criteria...
Lloyd McKenzie (Jun 07 2017 at 01:14):
With slicing, your first task is defining the discriminators that determine what rules will apply. Then you add the extra constraints to each combination of discriminators that is of interest
Sean McIlvenna (Jun 07 2017 at 17:10):
Ok. So, I guess you're saying that the list of discriminators doesn't matter as much in my scenario; they are just used to say "look at these things for uniqueness"... Then each separate set of elements following the list of discriminators can have different criteria.
Lloyd McKenzie (Jun 07 2017 at 17:39):
I'm not fully clear on your scenario, but I think so. Discriminators allow you to identify the set of repetitions to which a particular set of constraints should apply.
Brian Reinhold (Jun 09 2017 at 14:46):
Lloyd,
In this case the profile is specifying that the identifier have cardinality [1..*] but one of them shall have a value element which is used in conditional creates. So it seemed like if the element id for this particular instance of the identifier was called conditionalCreateIdentifier, that would be a decent discriminator. Of course an application reading this data is likely not interested in the identifier since its purpose was to help uploads. But in general it would seem that giving an element id a unique name in a profile would be a good way to find those element instances which are part of the profile. Does that make sense?
Lloyd McKenzie (Jun 09 2017 at 14:50):
The discriminator has to be data that will appear in the instance - and you generally won't get ids on elements in the instance - and if you do, they'll be meaningless except as linking tools. Your discriminator should be Identifier.system, Identifier.type or Identifier.use or Identifier.period or some combination of those.
Brian Reinhold (Jun 09 2017 at 14:58):
Oops; that was a mistake; migrated to another site and lost all my typing.
The problem with that is that those parameters are all defined and have to be something specified unless I can create a identifier.system that means nothing except that it identifies (no pun intended) this particular identifier. For example, identifier.system="conditionalCreateIndentifier". Not your average URI
Lloyd McKenzie (Jun 09 2017 at 15:02):
Then define and use an extension
Brian Reinhold (Jun 09 2017 at 16:08):
Bummer. There has got to be a better way ...
Lloyd McKenzie (Jun 10 2017 at 05:01):
You must include a "semanticly meaningful" element in your instance that says "hey, this is what this thing is". If possible, try to use one from the core spec. If not, you'll need an extension. The "id" element is not semanticly meaningful. You can't expect anyone to populate it consistently (in the unlikely event they populate it at all), nor interpret it in any way. Its purpose is to let you point to other elements from inside a resource, to link narrative to discrete data, to allow Provenance to refer to specific elements within a resource, etc. It's a pointer/identifier, not a meaningful label.
Last updated: Apr 12 2022 at 19:14 UTC
