Stream: IG creation
Topic: Binding to 'top level' of a Slice?
John Carter (Apr 19 2018 at 04:51):
In this profile, http://hl7.org.au/fhir/pd2018Mar/StructureDefinition-au-pd-healthcareservice.html, specifically the 'type' and 'specialty' attributes, there is a value set binding notice attached to the container of the slice, I believe inherited from the base resource. I think this is a problem, since if I actually wanted to attach one of those codes to an instance of this profile, there's no way for me to do it... thhere's no defined slice, no datatype or cardinality for me to put stuff in. Grahame has said that he vaguely remembers discussion of this question and suggested I ask here to see if @Lloyd McKenzie or anyone can shed light. Is there a purpose to keep some kind of binding attached to a slice container, or is this a bug?
Lloyd McKenzie (Apr 19 2018 at 05:45):
So, there are legitimate reasons to specify a binding on both the slicing element and the slices. The binding on the slicing element would establish an overall binding and bindings declared on the slices would constrain that binding in certain situations. However, the binding declared on slices must always constrain the binding on the slicing element (at least if it's a required or extensible binding). That's happening here because we're going from a preferred binding to a required binding - so for elements that match the HealthcareService.specialty:snomedrole slice, the SNOMED required binding is in effect and for elements that don't match that slice, the preferred c80-practice-codes binding remains in effect.
I don't really understand the statement "if I wanted to attach one of those codes to an instance of this profile, there's no way for me to do it". What is it there's no way to do?
John Carter (Apr 19 2018 at 06:17):
I don't really understand the statement "if I wanted to attach one of those codes to an instance of this profile, there's no way for me to do it". What is it there's no way to do?
Thanks @Lloyd McKenzie you've clarified for me. What I thought I couldn't do was populate a sliced element without following directions given by one of the defined slices, but you are saying that's fine. So a complete interpretation for the CodeableConcepts that work in this case is (in descending order of strength): If you attach any SNOMED concepts, they must come from the named value set. If you attach any other concepts, they should come from the other named value set, but at the end of the day you could use any coded value at all if you really want to. If that's correct, then it makes sense from a business point of view.
For what it's worth, I was unable to figure this out from the documentation on slices. That's not necessarily an indictment of the technical correctness of the docs, but may be a useful bit of feedback about the quality of reader we have to cater to.
Richard Townley-O'Neill (Apr 19 2018 at 06:24):
@Michel Rutten
Why does Forge not allow you to see or edit the properties of a top level slice?
I can use Forge to constrain a slicing element and then slice it and constrain the slices. But to then revise the constraints on the slicing element I have to edit the source code.
Michel Rutten (Apr 19 2018 at 10:01):
Hi @Richard Townley-O'Neill, actually this is a legacy from the original Forge for DSTU1. Originally, FHIR didn't have a notion of default slice constraints. It took a while for the FHIR community to realize the need and provide a clear definition of the desired behavior. For a while now, I've been thinking about a way to support this in the Forge UI. Currently, when an element is sliced, Forge hides the regular child elements, and instead shows the associated slice elements as children. Of course, Forge could easily display both as children, but I'm worried that this would be confusing to (most) end users, as the distinction may not be clear. So I'm still pondering on how to present this in the UI in a clear way.
Lloyd McKenzie (Apr 19 2018 at 14:30):
@John Carter If slicing was "closed", then every instance repetition would have to match one of the slices. However so long as things are open, you're allowed to have repetitions that don't match any of the defined slices.
Richard Townley-O'Neill (Apr 20 2018 at 01:39):
@Michel Rutten
Thanks.
The slice icon (circle with a wedge) identifies the root of each slice. That is subtle, but might be enough to visually distinguish slice defininitions from the children of the sliced element.
Last updated: Apr 12 2022 at 19:14 UTC
