Stream: implementers
Topic: Slicing
Jonny Rylands (Mar 10 2016 at 17:19):
Is it legal (or does it even make sense) to constrain sub elements of the "setup" slice when slicing in profiles?
Jonny Rylands (Mar 10 2016 at 17:25):
By "setup" slice I mean the "slicing entry" as per https://www.hl7.org/fhir/profiling.html#discriminator.
Josh Mandel (Mar 10 2016 at 17:26):
I think it doesn't make sense. (But my understanding of slicing is... limited.)
Jonny Rylands (Mar 10 2016 at 17:27):
OK cool - I guess I was thinking you may want to apply certain restrictions to all of the slices (and any elements added outside the slices (if Open or OpenAtEnd)).
Jonny Rylands (Mar 10 2016 at 17:28):
However it would make it complicated to apply (and calculate) the restrictions if this were the case. So I hope the answer is no!
Lloyd McKenzie (Mar 10 2016 at 23:12):
You can definitely constrain sub-elements of the setup slice. For example, you can say "the only kinds of telecoms allowed are phone numbers" and then slice to say that there must be one home number and can be up to two work numbers.
Lloyd McKenzie (Mar 10 2016 at 23:12):
(Now whether Forge allows that or not, I have no idea :))
Jonny Rylands (Mar 10 2016 at 23:20):
@Lloyd McKenzie OK, Forge doesn't allow you to do that. Once you've sliced an element, you can only modify elements of the slices, and not the setup slice.
Lloyd McKenzie (Mar 10 2016 at 23:21):
Raise the issue on the "conformance" stream so they can add it to their to-do list
Jonny Rylands (Mar 10 2016 at 23:29):
This does make for some pretty tricky validation logic though!
Jonny Rylands (Mar 10 2016 at 23:30):
(raised)
Michel Rutten (Mar 11 2016 at 11:29):
@Lloyd McKenzie thank you for pointing this out.
In Forge, the element treeview represents slice constraints as child nodes of the sliced element. The original child elements of a sliced element are hidden in the treeview. The UI clearly expresses the relationship between the sliced element and the associated slices, however it also prevents the user from constraining the original child elements.
If the spec indeed allows this, then Forge should support it too. However I'm afraid that displaying both the original child elements as well slices will clutter the UI and is likely to confuse the user. Alternatively, displaying slices as following siblings (like they are defined in StructureDefinition) would require quite invasive and time-consuming changes in the application, and frankly that is not a feasible option at the moment. Some kind of toggle button that controls the visibility of the original child nodes might work, but I'm not fully convinced. I'll add an issue to our tracker and ponder on the UI.
Chris Grenz (Mar 25 2016 at 18:26):
When slicing an element, the discriminators determine (select) which slice definition applies to each instance of the element. The definition is based on the fixed[x] value of each discriminator element OR (I think) a binding for the element. See http://hl7-fhir.github.io/profiling.html#discriminator paragraph 3.
This means that all other parts of the element definition are validation criteria for the slice. In other words, a failure of a constraint on that element would NOT simply disqualify the instance as a member of the slice but would rather make the entire resource instance invalid.
Is this correct?
Chris Grenz (Mar 25 2016 at 18:30):
I ask this for 2 reasons:
1. Clarify whether binding is a valid way to discriminate (I've heard both yes and no at various times).
2. Clarify that constraint and all the other parts of elementdefinition really are not useful in slice discrimination.
We're running into all kinds of situations where a more sophisticated slicing discriminator would be valuable...
Chris Grenz (Mar 25 2016 at 18:34):
Especially min/max for range segmentation
Lloyd McKenzie (Mar 25 2016 at 19:01):
Slicing doesn't require declaration of a computable discriminator - you can provide a description instead. And if you do that, anything goes. But validation becomes much more expensive. As well, the discriminator can be @profile, which allows you to do all sorts of things
Chris Grenz (Mar 25 2016 at 19:02):
Is that clear in the section I referenced? Shouldn't there be some line between "standard computable" and "wild west"?
Lloyd McKenzie (Mar 25 2016 at 19:12):
The deliniation is "descriminator" vs. "description"
Lloyd McKenzie (Mar 25 2016 at 19:14):
We don't talk too much about slicing without discriminators because that's not something we necessarily want to encourage, but we probably should beef up the description of when and why you might have slicing that doesn't list discriminators
Chris Grenz (Mar 25 2016 at 19:16):
So if it's "discriminator" then it MUST be fixed[x] or bound (assuming not @type/@profile).
Lloyd McKenzie (Mar 25 2016 at 19:36):
If you have a discriminatory, you can slice by element fixed value, type (for a polymorphic element) and/or by profile. You can only enforce bindings within profile.
Grahame Grieve (Mar 25 2016 at 21:59):
Chris: Lloyd has made this difficult, I think. Yes, you can slice by fixed value, or required binding. And yes, errors outside the discriminator are validation errors, not slice mismatches
Lloyd McKenzie (Mar 25 2016 at 23:19):
How can you slice by required binding without using profile or description?
Chris Grenz (Mar 29 2016 at 15:56):
Sounds like there's some...ambiguity.
Chris Grenz (Mar 29 2016 at 16:00):
I'm assuming limiting the parts of elementdefinition used for slice selection is to simplify implementation, yes? @profile pretty much adds all that complexity back in though... I'm going to propose that all parts of the element definition for a discriminator element within a named slice be part of the selection, not validation. In other words, failure of any aspect of the discriminator element of a named slice simply means "this is not the slice you're looking for". This enables much more rich slicing. Thoughts?
Chris Grenz (Mar 29 2016 at 16:00):
@Grahame Grieve @Ewout Kramer @Lloyd McKenzie
Chris Grenz (Mar 29 2016 at 16:00):
@Michel Rutten
Chris Grenz (Mar 29 2016 at 16:06):
Separate topic - now that name isn't for recursive things, does name need to be unique within the whole structure definition, or just within siblings?
Consider when a complex extension is used in multiple places in a SD. If my complex extension has 3 sub-elements: type, code, and reference (these are all named slices of extension in this case), these names will appear in the SD in multiple places IF the SD further constrains them in some way.
I think uniqueness is already broken...
Michel Rutten (Mar 29 2016 at 16:08):
@Chris Grenz I remember that my collaegue Martijn Harthoorn has struggled with this last year. IIRC, having to validate the full element in order to determine the associated slice introduces all kinds of ambiguity and nasty recursive matching challenges. So in order for slicing to be implementable, he strongly suggests to limit the discriminator to a primitive value that is easy to match. This ensures that you can find the associated slice _before_ trying to validate the element.
Chris Grenz (Mar 29 2016 at 16:09):
That's fine IF we don't bother with @profile as a valid disciminator...
Chris Grenz (Mar 29 2016 at 16:09):
Adding that in brings the devil's details with it!
Michel Rutten (Mar 29 2016 at 16:10):
you can match on profile url, that's a primitive value
Chris Grenz (Mar 29 2016 at 16:11):
Only if you *only* consider meta.profile values which requires pre-coordination and tagging of all resources.
Chris Grenz (Mar 29 2016 at 16:11):
What about maxValue[x] and minValue[x] - that should be OK, no?
Michel Rutten (Mar 29 2016 at 16:11):
Ah so you are referring to resources that implicitly conform to a certain profile?
Chris Grenz (Mar 29 2016 at 16:12):
Right...we're currently implementing profile evaluation at a server level. Basically, search by (previously not evaluated) profile.
Chris Grenz (Mar 29 2016 at 16:13):
Without this, new profiles are of limited value...
Michel Rutten (Mar 29 2016 at 16:13):
So matching a slice would require to find a matching profile on the fly? That seems very costly... how do you determine which candidate profiles you are going to try and match? All profiles that exist on the server?
Michel Rutten (Mar 29 2016 at 16:13):
I don't think Martijn is going to like this ;p
Chris Grenz (Mar 29 2016 at 16:14):
No...just the profile(s) used to discriminate.
Chris Grenz (Mar 29 2016 at 16:16):
We're using ElasticSearch which makes much of the profile validation relatively fast/cheap (fixed, range, binding). Most of the constraints appear on the base HL7 defined profile, so those are always validated and don't need to be re-evaluated. This leaves only new constraints to consider on a per-resource basis (and we try to limit/discourage these).
Chris Grenz (Mar 29 2016 at 16:17):
So, when I am onboarding my Cardiology dept and they define a new profile for cardiology-lab-observation with a limited binding on Observation.code, this can effectively be served by a search for code:in=cardiology-lab-vs
Chris Grenz (Mar 29 2016 at 16:17):
and _profile=Enterprise-Lab-Profile (to cover anything else fancy about labs).
Michel Rutten (Mar 29 2016 at 16:33):
Hmm, interesting. Don't you think this behavior is specific to your implementation? As in general, matching resources to profiles is a costly operation. So I am not sure if the FHIR standard should define this automagical profile matching as mandatory functionality...
Chris Grenz (Mar 29 2016 at 16:34):
No, I think this could be an option. The "depth" of profile validation may be something to call out in conformance though.
Chris Grenz (Mar 29 2016 at 16:35):
Many implementation (esp facades) won't be able to do this efficiently enough to be practical.
Michel Rutten (Mar 29 2016 at 16:36):
Agreed, it would be useful to express support for this advanced behavior via a Conformance resource.
Chris Grenz (Mar 29 2016 at 16:36):
I'm interested in Martijn's work - where he found issues
Michel Rutten (Mar 29 2016 at 16:37):
I'm looking forward to discussing your proposal with Martijn Harthoorn ;p
Chris Grenz (Mar 29 2016 at 16:37):
We're pretty early in the process - mostly converting profiles into search criteria today.
Michel Rutten (Mar 29 2016 at 16:39):
I think Martijn tried to implement a very generic solution that could deal with any kind of profile / nested slicing construction etc - and gave up trying, as the possibilities seemed dizzying...
Lloyd McKenzie (Mar 29 2016 at 18:06):
The benefit with profile is we already need to have code that tests whether a given instance is valid against a profile. It's expensive code to run (and is a pain to write), but it has to exist. And given that profile can do whatever's needed, it's hard to justify adding in another means of doing the same thing. As well, if implementers are concerned about performance, they can mandate the declaration of particular profile ids in the instances and thus avoid the performance issues. There'd be no similarly easy out if we opened up discriminator further.
Grahame Grieve (Mar 29 2016 at 19:28):
firstly, name uniqueness, you might be right. I'll have to look at that to see whether I have any problems with uniqueness and navigation
Grahame Grieve (Mar 29 2016 at 19:29):
slicing, agree that slicing by profile is much more complex. It only really works if the profile itself is simple. otherwise, you might as well not define a discriminator
Chris Grenz (Mar 31 2016 at 15:11):
@Michel Rutten I've been mentally reviewing the options for slice selection and keep coming back to the necessity to evaluate every constraint (scalar or xpath/fluentpath) during validation regardless of whether it's used for selection or validation. Is slice selection somehow more complex?
Lloyd McKenzie (Mar 31 2016 at 15:20):
If the discriminator is declared, you just need to look at the discriminator to figure out what slice it is. Then you test the constraints for that particular slice. But you can ignore the constraints for all of the other slices.
Michel Rutten (Mar 31 2016 at 15:20):
@Chris Grenz I informed my colleague Martijn about this discussion topic. He's very busy atm, but hopefully he can find some time to chip in. From what I understand, the challenge is that in order to validate a slice in a resource instance, you need to match it to a slice definition in the profile - but in this case, matching requires validation. This introduces a recursive dependency. Martijn can probably explain the issue in greater detail.
Chris Grenz (Mar 31 2016 at 15:21):
@Lloyd McKenzie I'm considering challenging how it's currently working and trying to discern the complexities of what I'm proposing.
Michel Rutten (Mar 31 2016 at 15:21):
uh oh...
Chris Grenz (Mar 31 2016 at 15:22):
I'm just running into may use cases where fixed discriminator slices aren't adequate. And there's no way to use extensions to get around this...
Chris Grenz (Mar 31 2016 at 15:23):
Big ones are range slicing and ordinal position slicing
Chris Grenz (Mar 31 2016 at 15:24):
And (even more!) slicing by binding/valueset
Michel Rutten (Mar 31 2016 at 15:26):
Interesting. Ordinal position slicing would seem so basic that you'd expect it would be covered by the standard. Maybe FHIR should define some rules for this specific case.
Chris Grenz (Mar 31 2016 at 15:27):
Right? :)
Michel Rutten (Mar 31 2016 at 15:27):
The other use cases don't seem too exotic either.
Lloyd McKenzie (Mar 31 2016 at 15:27):
In those places where a fixed discriminator can't work, you can slice by profile, which then requires testing the instance against each profile or looking for the profile. The former is expensive, the latter requires agreement of the submitter. But it should meet your needs in either case, with the possible exception or slicing by position which you've already proposed.
Chris Grenz (Mar 31 2016 at 15:30):
Hmm...so create a type profile and use @profile to put all parts of elementdefinition into play...
Chris Grenz (Mar 31 2016 at 15:30):
ug...ok
Chris Grenz (Mar 31 2016 at 15:31):
makes so much of the semantics external to the SD itself....but makes some things re-useable
Chris Grenz (Mar 31 2016 at 15:32):
and implementer penetration is going to be, umm.... low? =)
Michel Rutten (Mar 31 2016 at 15:36):
Range slicing is also an interesting case. Maybe the discriminator could accept a FHIRPath expression? In it's most simple form this is an element path, but it would also allow for complex multi-field expressions. Just thinking out loud here.
Michel Rutten (Mar 31 2016 at 15:37):
Assuming that all the popular FHIR API libraries will (eventually) provide FHIR path support, this seems feasible.
Chris Grenz (Mar 31 2016 at 15:40):
I would like to keep a line between scalar evaluation and expression evaluation - the former being possible during stream parsing and the latter not so much.
Chris Grenz (Mar 31 2016 at 15:41):
Smart parsing of profiles though could retain that line...
Chris Grenz (Mar 31 2016 at 15:42):
@Lloyd McKenzie So a discriminator of @type doesn't require looking at type.profile, just type.code where @profile looks at both?
Lloyd McKenzie (Mar 31 2016 at 17:29):
@profile incidentally ends up looking at both. And yes, penetration will be "low" - but that's ok. We'd like most uses of slicing to be straight-forward. The more complex edge-case stuff ought to be less common.
Chris Grenz (Apr 22 2016 at 19:51):
Assume a create a profile of CodeableConcept where I slice coding into LOINC and SNOMED by system. I then use that type in an Encounter profile to add these slicings to Encounter.type:
<element>
<path value="Encounter.type" />
<type>
<code value="CodeableConcept" />
<profile value="http://.../my-codeableconcept" />
</type>
I then (in my Encounter profile) slice type into "Practice Type" and "Institution Type". Do each of these slices now including coding slicings (for LOINC and SNOMED)?
Grahame Grieve (Apr 22 2016 at 19:51):
yes
Chris Grenz (Apr 22 2016 at 19:52):
And would a snapshot be expected to include them?
Chris Grenz (May 03 2016 at 22:05):
Is there a way to slice a BackboneElement (e.g. Patient.contact) by @profile? For instance, slice Patient.contact by relationship in a valueset. Since backbone element don't have their own SDs, there's no way to create a profile for just contact, correct?
Grahame Grieve (May 03 2016 at 22:06):
yes you have to enter the profile at the root of the resource, but you don't need yo say anything about the elements other than Patient.contact
Chris Grenz (May 03 2016 at 22:15):
So the contact tag will be evaluated for conformance against a whole Patient profile? That's...confusing....
Chris Grenz (May 03 2016 at 22:16):
But not unusable....
Keith Boone (May 17 2016 at 08:21):
I'm trying to slice something by type, but cannot seem to get it to work on observation. Anyone here have any words of wisdom. The error I'm getting is: Attempt to a slice an element that does not repeat: Observation.value[x]/null from http://hl7.org/fhir/StructureDefinition/CodeableConcept but my use of value[x] only includes Quantity | string.
Chris Grenz (May 17 2016 at 13:24):
Keith - what tool are you using?
Keith Boone (May 17 2016 at 13:47):
Using the spreadsheet.
Eric Haas (May 18 2016 at 03:57):
@Keith Boone "Attempt to a slice an element that does not repeat" is not possible. Slicing is done on element that may occur more than once. You define the type as valueQuantity.
Lloyd McKenzie (May 18 2016 at 13:27):
@Eric Haas That's not true actually. You can also slice when an element has a choice of types.
Eric Haas (May 18 2016 at 13:43):
Ah yes ... my mistake.
Chris Grenz (May 18 2016 at 14:08):
This is a "2 ways to do something" situation. Why would we not just use the type named element for this? It's very ambiguous.
Grahame Grieve (May 18 2016 at 18:06):
might not have a single type?
Chris Grenz (May 18 2016 at 18:08):
Yes, I suppose you could create slices for multiple types...huh.
Pranitha Sruthi (Nov 27 2017 at 13:02):
Hi all, what if I have to slice the element 'identifier' and do not know the total number of slices? Thank you
Lloyd McKenzie (Nov 27 2017 at 14:33):
Just define the slices you care about. Others can define additional slices and it's fine if there is space that remains unsliced.
Pranitha Sruthi (Nov 28 2017 at 06:02):
@Lloyd McKenzie I did not understand. Can you elaborate?
Ardon Toonstra (Nov 28 2017 at 10:42):
@Pranitha Sruthi just slice the identifier element as many times af you can / want to specifiy this element. Leave the slicing.orderd on 'open' or 'openAtEnd' so it is possible to add additional identifiers you don't specify in your profile.
Pranitha Sruthi (Nov 28 2017 at 10:45):
@Ardon Toonstra Ok thank you
Ramandeep Dhanoa (Oct 17 2019 at 17:04):
HI @Lloyd McKenzie I am trying to understand how to do slices in the spreadsheet. To understand this, I am using practitioner profile example, having multiple identifiers for practitioner (provider number, license number) and trying to show then as slices. I want to slice it on Practitioner.identifier.type (whose fixed code values are 'PN','LN'). Please let me know Capture.PNG
Lloyd McKenzie (Oct 17 2019 at 17:21):
You need to declare a discriminator on the first repetition column (discriminator column) which should be type.@pattern. Your patterns need to be in the pattern column, not the value column. And you need to put a name in the profile name for your two subsequent identifier repetitions to name your slices
Ramandeep Dhanoa (Oct 17 2019 at 17:34):
Perfect! Works now :) Thanks Lloyd. However, I don't understand the role of 'Profile Name' column here, since we have mentioned in Discriminator column how to distinguish the slices (pattern column has the appropriate code to differentiate between slices)..
Ramandeep Dhanoa (Oct 17 2019 at 17:50):
Also, what will be the 'Discriminator' if I want to slice it for example on practitioner.identifier.use (which has 'code' type)? just trying to understand different discriminator types..
Lloyd McKenzie (Oct 17 2019 at 17:54):
Every slice needs to have a name. That name is used to establish a unique id for the slicing element and descendant elements. It can also be referenced in child profiles if re-slicing the element.
Lloyd McKenzie (Oct 17 2019 at 17:55):
If you're slicing on code, you generally slice by value, not pattern, so just strip off the ".@pattern" from the end. (Slicing by value is the default.)
Ramandeep Dhanoa (Oct 17 2019 at 18:03):
Thanks @Lloyd McKenzie makes perfect sense!
Lloyd McKenzie (Oct 17 2019 at 22:32):
Slicing often doesn't, so that's awesome :)
Ramandeep Dhanoa (Oct 25 2019 at 17:56):
Hey @Lloyd McKenzie I am trying to have a contained resource (consent) in immunization profile, can you let me know how to do that in spreadsheet?
Lloyd McKenzie (Oct 25 2019 at 18:01):
Look at the example in the https://github.com/fhir/sample-ig. Also, the first page of the spread points to a wiki page that provides some documentation
Ramandeep Dhanoa (Oct 25 2019 at 19:11):
umm, I am still unsure how to do document another resource as 'Contained' in the profile. If consent is contained in immunization profile, what will be the element name, for example immunization.consent. (I couldn't find an example in IG documentation and also in IG sample..) Also what should be the value in 'Type' column, since it's another resource will it be something like this Contained(Consent)?? am I missing something?
Lloyd McKenzie (Oct 25 2019 at 20:13):
In the referencing element, populate the 'aggregation' property with 'contained.
Lloyd McKenzie (Oct 25 2019 at 20:14):
Type would be Reference(Consent)
Ramandeep Dhanoa (Oct 25 2019 at 20:43):
How do I reflect contained aggregation property? I have attached the snapshot as well. My apologies if it's too basic, but I am hearing this aggregation property for the first time.. Capture.PNG
Lloyd McKenzie (Oct 25 2019 at 22:10):
Ah. Aggregations in spreadsheet is actually pretty advanced. Instructions for everything are here: https://wiki.hl7.org/w/index.php?title=FHIR_Spreadsheet_Authoring#Element_Definition_Columns
Lloyd McKenzie (Oct 25 2019 at 22:10):
so in this case, it would be Reference(Consent) <contained>
Ramandeep Dhanoa (Oct 25 2019 at 22:47):
Okay Thanks! and Element will be like 'Consent.Identifier' and not Immunization.Consent.identifier, right?
Lloyd McKenzie (Oct 25 2019 at 22:48):
Right
Ramandeep Dhanoa (Oct 25 2019 at 22:49):
There's still something wrong, it breaks my profile Capture.PNG
Ramandeep Dhanoa (Oct 25 2019 at 22:51):
Capture.PNG Am I missing something? Problem is publisher doesn't tell me the error message, it doesn't even fail (it just breaks the profile),,
Ramandeep Dhanoa (Oct 25 2019 at 22:58):
do you have a working example spreadsheet for the contained resource in a profile?
Lloyd McKenzie (Oct 26 2019 at 03:27):
Why are you defining things that aren't references as a reference? I'm surprised that your publisher is publishing at all...
Lloyd McKenzie (Oct 26 2019 at 03:27):
You're going to have one profile for Immunization and a different profile for Consent
Lloyd McKenzie (Oct 26 2019 at 03:28):
The element in your Immunization profile will be of type Reference(Consent) {http://.....yourconsentprofile} <contained>, pointing to your Consent profile
Lloyd McKenzie (Oct 26 2019 at 03:28):
One profile can only ever contain elements from a single resource.
Ramandeep Dhanoa (Oct 28 2019 at 17:01):
the reason I was thinking the resource (Consent) will be contained and will be in the same profile (Immunization) is because immunization profile doesn't have any element which will be referencing to Consent and there is no enough information about consent.. That makes sense there will be 2 profiles, however It's still confusing for me which element in immunization profile will be referencing to Consent profile ('Element' column)?
Lloyd McKenzie (Oct 28 2019 at 17:09):
Every resource needs its own profile. You can't have a contained resource unless the containing resource points to the contained resource or vice versa. And if you want to enforce a profile on the contained resource, the container needs to point to contained
Aleksi Aho (Nov 01 2019 at 06:34):
Hello, I have question about slicing. I would like to have two slices in meta.profile. In the first slice I have fixed value for profile, and for the second slice I would like to be "open". I mean no fixed values or no bindings etc. Is this possible to do?
Lloyd McKenzie (Nov 01 2019 at 12:58):
What you actually want @Aleksi Aho is to have "open" slicing (which is the default) and declare a single slice with a fixed value. You can then declare a 'default' slice that applies to everything else, or you can have no additional slices, in which case the rules for all other profile repetitions are just the rules you've set for the element as a whole
Aleksi Aho (Nov 04 2019 at 16:43):
Okay. How should I use discriminator, or what should be discriminator? I keep getting message that my element match more than one slice when I'm trying to save resource against the profile.
Lloyd McKenzie (Nov 04 2019 at 16:47):
$this, I believe
Ramandeep Dhanoa (Nov 12 2019 at 19:27):
HI @Lloyd McKenzie I am doing slicing on Provenance.agent to indicate who are the author, custodian, etc.. For some reason it's not liking my slices and profile not showing up. Can you please have a look and let me know if you see any error. Pattern column has these values:
{"coding":[{"system":"http://terminology.hl7.org/CodeSystem/provenance-participant-type", "code":"author"}]}
{"coding":[{"system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type", "code": "informant"}]}
Capture.PNG
Lloyd McKenzie (Nov 12 2019 at 19:45):
Nothing looks obviously wrong. What error messages are you getting?
Ramandeep Dhanoa (Nov 12 2019 at 20:03):
it doesn't state any explicit error, it just doesn't show anything.
Capture.PNG
It's so weird when i remove the slice, it displays fine...
Lloyd McKenzie (Nov 12 2019 at 21:03):
Are you checking the validation.html? Anything in the console log during the build process?
Ramandeep Dhanoa (Nov 12 2019 at 21:45):
Yes, checked I don't see anything, except I see one message related to this profile (which I am unsure of.. java code not generated for this profile) It appears even if I dont' have slicing in the profile, so I am not sure if it's related..
Capture.PNG
It's weird coz I have added slices the same way in other profiles and they render fine. Will you be able to look at the spreadsheet?
Lloyd McKenzie (Nov 12 2019 at 22:40):
And qa.html is clean?
Ramandeep Dhanoa (Nov 13 2019 at 22:55):
Hey @Lloyd McKenzie is there any version update I have to do on my end, I am getting version error while publishing:
Capture.PNG
Ramandeep Dhanoa (Nov 13 2019 at 22:58):
Also I have deleted the slicing profile to make sure that's not causing any problem..
Lloyd McKenzie (Nov 13 2019 at 22:59):
That sounds like you're not using the latest & greatest IG publisher. You need one from the last 1.5 weeks - and in practice you want the one that was published today.
Ramandeep Dhanoa (Nov 13 2019 at 23:22):
Thanks that resolves it!
Ramandeep Dhanoa (Nov 14 2019 at 21:51):
For the slicing issue I mentioned before, I see this error in StructureDefinition-prov-profile-validation.html file:
{% raw %}<table class="grid">
<tr><td><b>Level</b></td><td><b>Type</b></td><td><b>Location</b></td><td><b>Message</b></td></tr>
<tr><td>error</td><td>invariant</td><td>StructureDefinition/prov-profile: StructureDefinition.differential</td><td>sdf-8a: In any differential, all the elements must start with the StructureDefinition's specified type for non-logical models, or with the same type name for logical models [((%resource.kind = 'logical') or element.first().path.startsWith(%resource.type)) and (element.tail().empty() or element.tail().all(path.startsWith(%resource.differential.element.first().path.replaceMatches('\\..*', '') & '.')))]</td><td></td></tr>
<tr><td>warning</td><td>invariant</td><td>StructureDefinition/prov-profile: StructureDefinition</td><td>sdf-0: Name should be usable as an identifier for the module by machine processing applications such as code generation [name.matches('A-Z{0,254}')]</td><td></td></tr>
</table>
{% %}
Ramandeep Dhanoa (Nov 14 2019 at 23:18):
hmm so confused, it seems to give an error now in IG Publisher:
Capture.PNG
Ramandeep Dhanoa (Nov 14 2019 at 23:19):
any idea what's this related to @Lloyd McKenzie ?
Lloyd McKenzie (Nov 14 2019 at 23:21):
As an example, if you're creating a profile on Observation, every element in your profile must start with "Observation." (unless it's the root element, in which case it can be just "Observation".)
Ramandeep Dhanoa (Nov 14 2019 at 23:26):
uhhh found the root cause - spelling error Provence. Thanks @Lloyd McKenzie :)
Ramandeep Dhanoa (Dec 12 2019 at 23:16):
Hi @Lloyd McKenzie we need to have different addresses in our patient profile (for example - home, work, temp, old, etc - which is basically denoted by address.use element). Will this has to be achieved through slicing or is it possible to not slice address and just repeat the address multiple times (I am just trying to understand the slicing concept)..
Lloyd McKenzie (Dec 12 2019 at 23:22):
In the instance, you just repeat the address multiple times declaring the desired type for each repetition. If you're trying to define what's allowed and you have different requirements for each type (e.g. must be one work, old addresses must specify end date, etc.) then slicing allows you to define different expectations for addresses with different types. If you don't have different rules, just leave address as 0..* and allow all the types and let implementers send what they have.
Ramandeep Dhanoa (Dec 12 2019 at 23:47):
Thanks for the clarification!
Ramandeep Dhanoa (Dec 19 2019 at 01:02):
Hi @Lloyd McKenzie can a slice be marked as 'must-support'?
Richard Townley-O'Neill (Dec 19 2019 at 01:22):
Yes.
We do it in https://github.com/AuDigitalHealth/ci-fhir-stu3/blob/master/output/SharedMedicinesList/StructureDefinition-composition-sml-prac-1.xml from https://github.com/AuDigitalHealth/ci-fhir-stu3/tree/master/output/SharedMedicinesList
Ramandeep Dhanoa (Dec 19 2019 at 19:15):
Thanks!
Liam (Jan 08 2020 at 11:54):
Hi,
I am new to FHIR and having difficulty in understanding slicing.
What is difference between Slicing and applying constraints.
Basically its same thing.
Is my understanding correct?
Thanks
John Moehrke (Jan 08 2020 at 15:45):
slicing is important where in a Resource there is an element which is a list of various kinds of data. slicing allows you in one profile (StructureDefinition) to indicate that you are requiring a variety of things. Such as, in this Resource blah element you must specify atleast ONE of these, and up-to-TWO of these, and none of these. where these are all variations of list elements. among other functionality...
slicing is powerful, but hard to grasp initially.
Lloyd McKenzie (Jan 08 2020 at 16:15):
Slicing is a type of constraint, but it's a constraint where different rules apply to different repetitions - typically based on some difference between the repetitions. So, for example, if you slice Patient.name by use, you could have one set of constraints on names with a use of 'official' and a different set of constraints on names with a use of 'usual'. It might be possible to express all of your slicing rules using the 'constraint' mechanism, but some of them would get incredibly complex and very hard to read/understand. Once you know what slicing is, reading slicing in a resource table is pretty straight-forward.
Ramandeep Dhanoa (Jan 08 2020 at 18:39):
Hi @Lloyd McKenzie we have 3 different source systems with specific business requirements and constraints on current (home), mailing and old address. We are trying to have these 3 slices, but wondering how to slice it and on which address element (either its Address.use or Address.type?) slicing needs to be done.
Current address – Address.use >home
Old address – Address.use >old
Mailing address – use may not be appropriate here, since use can be home, work, temp, etc…
Lloyd McKenzie (Jan 08 2020 at 19:09):
Sounds like you may need to slice by both. Are home and old both expected to be physical addresses?
Ramandeep Dhanoa (Jan 08 2020 at 19:12):
Is it possible to slice by use and type? Home is expected to be physical address whereas old may be physical or not..
Lloyd McKenzie (Jan 08 2020 at 19:43):
Yes, you can have multiple discriminators when you slice.
Lloyd McKenzie (Jan 08 2020 at 19:44):
If old can be mailing, does that take precedence over mailing?
Ramandeep Dhanoa (Jan 08 2020 at 21:05):
If old can be mailing, does that take precedence over mailing? Nope (For 'old' slice there is a possibility that source systems might not indicate if address is postal or physical, they just sit in Address history).
When you say multiple discriminators, will it be something like sub-slicing or Re-slicing?
Lloyd McKenzie (Jan 08 2020 at 23:06):
No. re-slicing is when a derived profile slices something that was already sliced. Multiple discriminators just means that when you declare slicing on the root element, you list multiple discriminators rather than just one.
Liam (Jan 09 2020 at 04:29):
Thanks @Lloyd McKenzie and @John Moehrke
One more thing by seeing actual FHIR Resource (Data not the structure definition) is there any option to know whether slicing has been done or not ?
Lloyd McKenzie (Jan 09 2020 at 04:40):
In a resource instance, there's no such thing a slicing. Slicing is about the rules, not the content. I might have rules that say "There must be one home phone number and no more than 5 addresses", and use slicing to define those rules. But in the instance, I'll just have a Patient with a certain number of telecom instances - and that Patient will either comply with the rules or not.
PS (Jan 10 2020 at 09:25):
Hi,
Suppose the extension of Observation is sliced to add two more elements(One with URL and ValueReference and other with URL and ValueString).
The mapping is one to many.
My question is even after extension is sliced can we add more elements in the extension other than tha above two?
Thanks
Lloyd McKenzie (Jan 10 2020 at 15:50):
You're not really adding more elements. The 'extension' element is already there. In your profile, you're using slicing to set expectations around the cardinality or other constraints of extension repetitions that happen to have particular URLs. So long as the slicing was 'open', subsequent profiles are free to define additional slices. (And in general, slicing should generally be 'open')
PS (Jan 13 2020 at 04:47):
In the profile, Yes we can add if it is 'open' . But while adding in the data it shouldn't be allowed right ?
Lloyd McKenzie (Jan 13 2020 at 05:04):
I'm not understanding the question
PS (Jan 13 2020 at 05:09):
Hi,
Suppose the extension of Observation is sliced to add two more elements(One with URL and ValueReference and other with URL and ValueString).
The mapping is one to many.
My question is even after extension is sliced can we add more elements in the extension other than the above two?Thanks
@Lloyd McKenzie
I asked this question with reference to the actual FHIR JSON(not the profile).
It might sound silly but wanted to clarify.
Lloyd McKenzie (Jan 13 2020 at 07:52):
If slicing of an element is 'open', then any derived profile is free to add additional slices.
Ramandeep Dhanoa (Jan 13 2020 at 21:43):
Hey @Lloyd McKenzie If I am slicing address on 2 address elements i.e. use and type, does that mean for all the address slices there is a need to specify value for both - Address.use and Address.type? for example - 'Work' slice Address.use is work however I don't want to specify any specific value for Address.type (since it can be postal or physical or both), is that okay to leave it blank?
Lloyd McKenzie (Jan 13 2020 at 22:13):
Common practice is to specify either a value or a value set for both. I'm not sure what happens if you leave one of the discriminators unconstrained. @Grahame Grieve - is that allowed?
Grahame Grieve (Jan 13 2020 at 22:20):
it's ok to say nothing about one of the discriminators as long as the other values provide distinctness
Ramandeep Dhanoa (Jan 13 2020 at 22:29):
Thanks!
Ramandeep Dhanoa (Jan 14 2020 at 19:48):
Hey Lloyd, in the address slice we are trying to bind address.type to physical and both. It's not rendering properly:
Bindings tab:
Capture.PNG
physical-both is the tab name in spreadsheet, where I am specifying the value-sets
Capture1.PNG
Am I missing something?
Lloyd McKenzie (Jan 14 2020 at 21:28):
Code lists in the spreadsheet are probably not well supported right now and are eventually likely to be deprecated. You really should be authoring a proper ValueSet instance and CodeSystem instance.
PS (Jan 16 2020 at 04:38):
I was dealing with one of the Observation Structure Definition in which I came across below thing :
"id" : "Observation.extension",
"path" : "Observation.extension",
"slicing" : {
"discriminator" : [
{
"type" : "value",
"path" : "url"
}
]
Can someone help me out on what does here "type" and "url" means.
Thanks
Lloyd McKenzie (Jan 16 2020 at 04:42):
It means that extension is being sliced by the value of the URL element. I.e. you know what the rules for the extension are because each extension has a fixed URL value.
Katarina (May 19 2020 at 12:52):
Hi,
I do slicing by type.coding.system(Value). Is this different to slicing by type.coding.code(Value) and then slice again type.coding by system(Value)?
Lloyd McKenzie (May 19 2020 at 15:25):
Normally if slicing by code, you'll have to use both system and value as a discriminator. However, it's easier (and slightly better) to slice with a discriminator with type 'pattern' and a path of type.coding or even a path of type.
Kailash (Aug 03 2020 at 15:29):
For an example take Organization.type(STU3), which has example binding to HL7 valueset and i want to use my custom value set instead, so I has sliced Organization.type based on the value of coding.system and bind my custom value set to one of the slice. In this case, Is the constraints (Custom value set) defined for a slice overrule the constraints defined on sliced element(HL7 value Set)?or has higher precedence?
Lloyd McKenzie (Aug 03 2020 at 19:31):
If it's an example binding, it's simplest to just declare your own binding and override the example one. (You can do that for either example or preferred bindings.) For required or extensible bindings, you can also override, but the newly bound value set must comply with the base binding)
Kailash (Aug 04 2020 at 02:19):
Thanks, but question is about precedence, what if there is conflict between constraints on sliced element and slice ?
take same example, i want to use two diff value sets, one on Organization.type(sliced element) and another on Organization.type:slicename(slice). Does this mean that the value set bind with Organization.type will be applicable to none slice repetitions(if open at end) and binding to slice will be applicable to slice repetition only? and in this case slice constraints(binding) will ignore sliced element constraints(binding).
Lloyd McKenzie (Aug 04 2020 at 03:08):
You can't slice Organization.type - you can only slice Organization.type.coding. The binding on type says "one of these codings must/should/may adhere to this value set" (depending on the strength of the binding. Bindings on your slices just make assertions about additional codings.
Lloyd McKenzie (Aug 04 2020 at 03:09):
If you define mandatory slices and also have a required or extensible binding on the overall CodeableConcept, the instance must have Codings that match all of the requirements.
Kailash (Aug 04 2020 at 06:55):
means, every repeat(whether it is part of slice or not) should confirmed base element(element which is sliced) constraints.
Lloyd McKenzie (Aug 04 2020 at 15:39):
I don't understand that sentence. The binding on a CodeableConcept says that one Coding needs to meet the binding. And defining slices generally also means that one Coding needs to meet the slice binding.
sandhya kodimala (Oct 20 2020 at 12:17):
I am trying to slice an element based on its value. I am unable to find any examples how to do slicing in Java. Does anyone did slicing using java FHIR API? Thanks in advance.
Vassil Peytchev (Oct 20 2020 at 14:42):
If this is a question about the HAPI FHIR server, you may get a quicker answer on the #hapi channel...
Shahim Essaid (Nov 11 2020 at 18:19):
I'm struggling with some slicing issues in a profile but before I create too much noise here I'd like confirm one aspect first. I'm also reading through few threads here before asking for more help but a yes/no answer to the following will probably resolve some issues. I'm also assuming it's okay to add my question to this thread. I'll move this to a new thread if that helps.
Let's say I'm slicing Observation.component, can I have two slicings on it in the same profile?
The first slicing's discriminator is code.coding.system AND code.coding.code. Two slices. First max 1 and the other max *. The valueCodableConcept is bound in these slices to a ValueSet
The second slicing's discriminator is also code.coding.system AND code.coding.code with max 2 but it adds a third type discriminator for value[x] being CodableConcept in one slice and Quantity in another. In this slicing, the code.coding.system AND code.coding.code have the same fixed values in the two slices but the difference is the types in the two slices.
This is still WIP but if you'd rather see what I'm trying to do, you can take a look at these GitHub links although parts of it are still incomplete and/or commented out:
and the WIP PR is here (feel free to comment on the PR or code lines):
https://github.com/phenopackets/core-ig/pull/9
Thanks!
Lloyd McKenzie (Nov 11 2020 at 18:22):
A single element in FHIR can only have one set of discriminators defined and all slices must be distinct based on that one set of discriminators
Shahim Essaid (Nov 11 2020 at 18:24):
I'm assuming this is per profile. Correct? In other words, a child profile can override the slicing in that case? If that's how it works, is all slicing info from the base profile erased?
Lloyd McKenzie (Nov 11 2020 at 18:26):
Per path within a profile. If you have a repeating element that is itself sliced, you could have different discriminators on a sub-element within each parent slice. E.g. if you sliced Observation.component, you could have different discriminator sets on Observation.component.code.coding within each component slice.
Shahim Essaid (Nov 11 2020 at 18:27):
@Lloyd McKenzie thanks for the tips! I'm still digesting all this and will probably have few follow up questions later.
Lloyd McKenzie (Nov 11 2020 at 18:27):
That's what the chat is here for :)
Shahim Essaid (Nov 11 2020 at 18:31):
Does this also mean that each slice needs to address all the paths in the set of discriminator paths? If not, what happens with the other discriminator paths if a slice doesn't need them to be unique?
Shahim Essaid (Nov 11 2020 at 18:39):
One more question and then I'll do my homework before asking again :)
If a path in a discriminator needs to be used both by value or by type in the different slices, does this mean that there should be two entries for that path in the slicing discriminators, once by value and once by type, or is that sort of discrimination not possible?
Lloyd McKenzie (Nov 11 2020 at 18:44):
It's fine if not all of the discriminators have a value. What matters is that all slices are unique based on the discriminators
Nathan Davis (Nov 19 2020 at 16:36):
I'm getting a slicing error (attempting to slice an element that does not repeat) on the following code snippet . What am I missing? I've used the same slicing for similar elements in other profiles and it works.
<element id="Observation:HeartRate.device">
<path value="Observation.device"/>
<slicing id="1">
<discriminator>
<type value="profile"/>
<path value="device.reference.resolve"/>
</discriminator>
<ordered value="false"/>
<rules value="open"/>
</slicing>
<min value="0"/>
<max value="*"/>
<mustSupport value="true"/>
</element>
<element id="Observation:HeartRate.device:genDevice">
<path value="Observation.device"/>
<sliceName value="Device"/>
<type>
<code value="Reference"/>
<targetProfile value="http://hl7.org/fhir/StructureDefinition/Device"/>
</type>
<mustSupport value="true"/>
</element>
<element id="Observation:HeartRate.device:BPDevice">
<path value="Observation.device"/>
<sliceName value="BPDevice"/>
<type>
<code value="Reference"/>
<targetProfile value="http://hl7.org/fhir/us/vitals/StructureDefinition/BPDevice"/>
</type>
<mustSupport value="true"/>
</element>
Lloyd McKenzie (Nov 19 2020 at 16:39):
Observation.device does not repeat and is not polymorphic (doesn't have multiple data types). Because of that, slicing is not supported. (We've talked about introducing it, but that adds a lot of complexity to the validator, which is already extremely complex, so it's not something we'll undertake lightly or soon.
Nathan Davis (Nov 19 2020 at 16:45):
@Lloyd McKenzie Thank you.
Emmeli Gross (Jan 08 2021 at 10:33):
Hi! I have done a slice on Provenance.reason and I need some advise:
The case is as follows:
We want to use two different ValueSets in Provenance.reason (Provenance.reason is a CodableConcept).
One ValueSet contains "reasons for nullification" and should be used if the Provenance.activity is some variant of "nullification" of the resource the Provenance is targeting . The other ValueSet contains "reasons for change" should be used if the Provenance.activity is a revision of the targeting resource.
One of the ValueSets contain codes from more than one CodeSystem.
To be able to provide different ValueSets for for different scenarios I need to do a slice, right? (Or is there some other pattern?)
Now to may main concern:
What should I do with the "discriminator" for the slice? Do you think that we should provide a discriminator for a scenario like the one described above?
If we should provide a discriminator, what should it be? One idea is to use the coding.system attribute, but what should I enter here in that case? The ValueSet URI? Then, aren't we misusing the "coding.system"? Any other suggestions?
Thanks!
Lloyd McKenzie (Jan 08 2021 at 14:26):
Slices allow for multiple simultaneous sets of constraints - for different repetitions. If you want to define different rules for an element for a different circumstance, you either need to define distinct profiles (one profile per condition) or define an invariant that makes the assertion of the value set binding contingent on the value of another element.
Last updated: Apr 12 2022 at 19:14 UTC
