Stream: implementers
Topic: sub-slices
Sean McIlvenna (Apr 29 2016 at 00:03):
How would you go about creating a profile that defines a slice within a slice
Sean McIlvenna (Apr 29 2016 at 00:04):
For example, if I had two types of extensions on my resource, and each of those extensions could have two different extensions?
(extreme example, I'm aware, but it's along the same lines of what I'm thinking about)
Chris Grenz (Apr 29 2016 at 00:04):
Re-slicing is described here: http://hl7-fhir.github.io/profiling.html#reslicing
Chris Grenz (Apr 29 2016 at 00:05):
Do you mean an extension within an extension (path="Patient.extension.extension") or slicing an extension?
Sean McIlvenna (Apr 29 2016 at 00:06):
an extension on an extension
Chris Grenz (Apr 29 2016 at 00:07):
If the "outer" extension have a value[x], then you would extend that (path="Patient.extension.value[x].extension") If not, you have a complex extension (path="Patient.extension.extension"). I'm working on examples for all these now.
Chris Grenz (Apr 29 2016 at 00:08):
My drafts are here: https://github.com/chrisgrenz/FHIR-Primer/wiki
Chris Grenz (Apr 29 2016 at 00:08):
Hopefully we'll have better examples within the spec shortly.
Chris Grenz (Apr 29 2016 at 00:09):
Disclaimer - these haven't been checked by anyone else yet!
Sean McIlvenna (Apr 29 2016 at 04:09):
I took a look at your github page. Looks like your complex extension example is very close to what I'm talking about. However, I'm wondering about an even more complex scenario where extensions are used, but there is a similar pattern on non-extension elements. In the scenario for extensions, separate profiles are used that describe each extension. But, what about a scenario where you have two slices (types) of Composition.section, and each slice/type of Composition.section can have a different Composition.section.content (for example). In this case, we aren't dealing with extensions, so they are not separate profiles. This hierarchy of requirements would have to be represented in a single profile. Any ideas?
Sean McIlvenna (Apr 29 2016 at 04:13):
If I were to represent this in print form, I might say:
SHALL contain Composition
--SHALL contain section, such that it <-- slice
----SHOULD contain content, such that it <-- sub-slice
------SHALL contain ...
----MAY contain content, such that it <-- sub-slice
--SHALL contain section, such that it <-- slice
----SHALL contain content, such that it <-- sub-slice
------SHALL contain ...
Sean McIlvenna (Apr 29 2016 at 04:13):
ugh... it removed my spacing
Sean McIlvenna (Apr 29 2016 at 04:14):
I think this is a realistic scenario when trying to represent C-CDA in FHIR profiles (as well as many other common implementation guide requirements)
Grahame Grieve (Apr 29 2016 at 08:29):
Sean, it just sounds like nested slices to me, and is a simple use case. but perhaps I've missed something...
Grahame Grieve (Apr 29 2016 at 08:29):
btw, if you want <pre> content, you can use 3 ` characters:
Grahame Grieve (Apr 29 2016 at 08:29):
this was started by 3 `
Sean McIlvenna (Apr 29 2016 at 13:24):
cool. didn't realize you could do that
Sean McIlvenna (Apr 29 2016 at 13:24):
yes, nested slices sounds right to me
Sean McIlvenna (Apr 29 2016 at 13:24):
do we have examples?
Sean McIlvenna (Apr 29 2016 at 13:24):
must have missed them...
Grahame Grieve (Apr 29 2016 at 14:08):
I haven't done any examples because I didn't particularly think it was necessary, and also becuase they'd be very verbose
Grahame Grieve (Apr 29 2016 at 14:08):
you could slice, say, Observation.component, and then within each slice, you could slice the reference range.
Sean McIlvenna (Apr 29 2016 at 14:33):
can you craft one example for me to following?
Sean McIlvenna (Apr 29 2016 at 14:33):
even pseudo-example?
Chris Grenz (Apr 29 2016 at 14:47):
Here's an example of an Encounter profile with a sliced type and a slicing within the first slice of coding:
Chris Grenz (Apr 29 2016 at 14:47):
<differential>
<element>
<path value="Encounter.type" />
<slicing>
<discriminator value="text" />
<rules value="open" />
</slicing>
</element>
<element>
<path value="Encounter.type.coding" />
<name value="sliceTextA.coding" />
<slicing>
<discriminator value="system" />
<rules value="open" />
</slicing>
</element>
<element>
<path value="Encounter.type.coding.system" />
<name value="sliceTextA.LOINC.system" />
<min value="1" />
<fixedUri value="http://loinc.org" />
</element>
<element>
<path value="Encounter.type.coding.system" />
<name value="sliceTextA.SNOMED.system" />
<min value="1" />
<fixedUri value="http://snomed.info/sct" />
</element>
<element>
<path value="Encounter.type.text" />
<name value="sliceTextA.text" />
<min value="1" />
<fixedString value="TextA" />
</element>
<element>
<path value="Encounter.type.text" />
<name value="sliceTextB.text" />
<min value="1" />
<fixedString value="TextB" />
</element>
</differential>
Sean McIlvenna (Apr 29 2016 at 14:51):
so is it a true statement that the name of the sub-slice is used to distinguish the parent slice that it belongs to?
Sean McIlvenna (Apr 29 2016 at 14:51):
ex: name = "parentSlice.childSlice"
Chris Grenz (Apr 29 2016 at 14:51):
That's how I interpret it...there's some discussion around that point I think
Chris Grenz (Apr 29 2016 at 15:23):
Also, some servers will choke on this differential because is doesn't provide all the implied paths (e.g. path:"Encounter.type.coding", name:"sliceTextA.LOINC")
Grahame Grieve (Apr 29 2016 at 15:33):
There's no connection between the names of the slices and the names a nested element sliced inside a slice on that element
Grahame Grieve (Apr 29 2016 at 15:34):
if you are re-slicing a slice in a derived profile, then there's rules. But nested slices are entirely separete
Grahame Grieve (Apr 29 2016 at 15:35):
except that names are unique within a profile, so I slice a, and then I slice a(1).b.c and a(2).b.c, then the slices on c must all have different names, even though they are defined independently within each slice
Sean McIlvenna (Apr 29 2016 at 17:39):
so if there is no connection between the slice names, how could you know that slice a.b.c belongs to slice a(1).b
Chris Grenz (Apr 29 2016 at 21:07):
and yet another reason for http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9843&start=0
Chris Grenz (Apr 29 2016 at 21:15):
Basically (I think) @Grahame Grieve is asserting that each element (at any nesting level) is sliced independently, and there's a cartesian product kind of combination that would then have to be limited by constraint. If you slice Element A sliced into A1 and A2 and then slice A.B into B1 and B2 and then slice A.B.C into C1 and C2, you'd have 3^3 combinations (A.B.C, A.B.C1, A.B.C2, A.B1.C, A.B1.C1,...,A1.B.C, A1.B.C1,...,A2.B2.C2)
Chris Grenz (Apr 29 2016 at 21:18):
This is pretty untenable I think...
Chris Grenz (Apr 29 2016 at 21:19):
@Lloyd McKenzie was this your understanding too?
Chris Grenz (Apr 29 2016 at 21:24):
Consider this scenario:
In a profile (my-patient) I slice Patient.identifer by @profile into MRN and SSN. The SSN Identifier profile includes an extension for issuingMethod.
In this scenario, how do I set something on issuingMethod.valueCodeableConcept.text? Use an element with:
a) name: "SSN.issuingMethod.valueCodeableConcept.text"
b) name: "issuingMethod.valueCodeableConcept.text" - is this legal? issuingMethod appears only in the type profile for SSN.
Chris Grenz (Apr 29 2016 at 21:35):
Effectively, without name:"sliceA.sliceB.C", slicing anything inside of an extension is ... hard?
Grahame Grieve (Apr 30 2016 at 02:50):
I don't see why it's untenable
Grahame Grieve (Apr 30 2016 at 02:52):
what is true is that the slice id is not in the path, so there' s a duality in the structure, in that something is implicit in the sturcture not explicit in the path (that's Chris's task). So I see how that's annoying but I don't see why that makes any genuine difference here - you slice the lower level like you slice anything else
Lloyd McKenzie (Apr 30 2016 at 06:33):
@Chris Grenz I don't see the alternative.
Chris Grenz (May 01 2016 at 01:27):
The alternative is composing names as in my example (name:"SliceAName.SliceBName").
Chris Grenz (May 01 2016 at 01:38):
Maybe "untenable" is a bit strong...what it prevents is specialization of slices (such as my identifier example) where you might want to require an extension on one slice but not another.
Grahame Grieve (May 01 2016 at 03:25):
I think you're just commenting about the pathing issue, not the way things actually work
Sean McIlvenna (May 01 2016 at 23:44):
agree with @Chris Grenz's last comment. this is the exact scenario I'm talking about and I just don't see how to implement it
Sean McIlvenna (May 01 2016 at 23:44):
"where you might want to require something on one slice, but not another"
Sean McIlvenna (May 01 2016 at 23:44):
definitely need a concrete example of sub-slices
Sean McIlvenna (May 01 2016 at 23:45):
otherwise I'm going to have to implement it the best way I see, which is to use path'd names (ex: "SliceA.SliceB"), until I get a clear understanding of how to handle this
Sean McIlvenna (May 01 2016 at 23:46):
I'd also argue that the flattened hierarchy of elements on a profile is making this much more difficult than it needs to be
Sean McIlvenna (May 01 2016 at 23:46):
if ElementDefinition could contain "children:ElementDefinition", then I think we would save a great deal of implementation logic trying to figure out where things belong
Grahame Grieve (May 02 2016 at 02:27):
well that last idea is definitely just moving the issue around
Grahame Grieve (May 02 2016 at 02:29):
if I'm going to write an example, it needs to be a useful real world example. Where's an example of where you slice something inside a slice differently per slice?
Chris Grenz (May 02 2016 at 14:38):
Real world I've got: slicing Patient.identifier by system and then requiring a particular extension in one slice but not another.
Chris Grenz (May 02 2016 at 14:39):
This is possible now only by slicing by @profile with type profiles for each identifier slice...
Sean McIlvenna (May 02 2016 at 14:56):
Yah. I'd agree with that real-world scenario.
Sean McIlvenna (May 02 2016 at 14:58):
Another could be having a patient with two slices for contact, where one slice has a sub-slice for address of X, and another slice has address of Y
Sean McIlvenna (May 02 2016 at 15:01):
another could be a MedicationAdministration that has two slices for dosage, where one dosage has a slice for site to be from X value set, and the other has a slice for site to be from Y value set
Grahame Grieve (May 02 2016 at 18:26):
I'll work on them tonight
Sean McIlvenna (May 03 2016 at 16:43):
Hi @Grahame Grieve , any update on this?
Grahame Grieve (May 03 2016 at 16:44):
sorry, I didn't get to it - the character thing distracted me. I'll do it this afternoon.
Sean McIlvenna (May 03 2016 at 20:06):
thanks @Grahame Grieve I look forward to seeing it (from the edge of my seat LOL)
Sean McIlvenna (May 04 2016 at 14:17):
Hi @Grahame Grieve , any update on this? :)
Grahame Grieve (May 04 2016 at 14:37):
sigh. just too mcuh going on....
Chris Grenz (May 04 2016 at 15:19):
@Grahame Grieve Give me a hint and I'll take a shot - you can just verify.
Sean McIlvenna (May 05 2016 at 14:40):
Hi @Grahame Grieve , can you give @Chris Grenz and I hint (as he says)? I'm going to have to implement a solution here, but would prefer to have at least a "generally correct" implementation, so that I don't have to completely re-write this logic later
Chris Grenz (May 07 2016 at 20:52):
@Sean McIlvenna Here's my attempt following a discussion with @Grahame Grieve . He'll have to verify when he gets a moment (HL7 working group meeting in progress this week).
https://github.com/chrisgrenz/FHIR-Primer/wiki/Slice-within-Slice-DSTU2
Vadim Peretokin (Apr 18 2017 at 09:58):
I need to slice my complex extension, ie reslice. https://www.hl7.org/fhir/profiling.html says I should call my slices originalSlice/newSlice per https://www.hl7.org/fhir/profiling.html:
there's a need to reference both the name of the original slice from Profile B as well as to define a name for the slice defined within Profile C. This is done by separating the names using "/"
But eld-16 limits sliceName to exclude forward slashes: ^[a-zA-Z0-9\\-\\_]+$
Who is incorrect here, the profiling page or the constraint?
Michel Rutten (Apr 18 2017 at 10:16):
I think that the profiling page is correct, reslice name separator is defined as a forward slash. So I guess the eld-16 invariant needs to be updated.
Lloyd McKenzie (Apr 18 2017 at 15:39):
Ouch. Please submit a change request. @Grahame Grieve - is this something we need to get out in the technical correction?
Grahame Grieve (Apr 18 2017 at 20:58):
yes
Grahame Grieve (Apr 19 2017 at 03:00):
Last updated: Apr 12 2022 at 19:14 UTC
