FHIR Chat · Default Slices · conformance

Stream: conformance

Topic: Default Slices

Chris Grenz (Sep 27 2016 at 13:08):

@Michel Rutten and I were discussing slicing and the topic of default slices came up. During profiling, there are times when you'd like to constrain all instances that don't conform to any existing slices. Generally for me this is when there is no good way to fix the other slices or they are too numerous to enumerate. Opened GF#12198 on this. Has anyone else experienced this?

Michel Rutten (Sep 27 2016 at 13:22):

One of the challenges we face is how to present a default slice in a user interface in a comprehensible and intuitive way. In Forge, the default children of a sliced element are hidden and instead the actual slices are presented as child nodes. If we'd want to support the proposed default slicing contstraints, Forge would have to show the (currently hidden) child elements, as well as any actual slices. However this would clutter the UI and probably confuse the end user. As of yet, I haven't come up with a user friendly and intuitive visualisation. Suggestions are welcome.

Chris Grenz (Sep 27 2016 at 13:28):

I would present it as a sibling to the named slices as (default)

Chris Grenz (Sep 27 2016 at 13:29):

What you're calling "default children" isn't actually default but rather the unsliced children, correct?

Michel Rutten (Sep 27 2016 at 13:41):

Yes, I am referring to the ordinary child elements of the unsliced child element, e.g. the child elements of "Patient.Identifier". I like you're suggestion of a "[default]" slice, that would be clear to the user. I'd have to do some UI work, as the regular children would then be pushed down one level and I'd have to dynamically update all the associated UI and ViewModel bindings. But it's possible.

Chris Grenz (Sep 27 2016 at 13:44):

So there are 2 things here: the (all) element which is not sliced - what we have today. And a (default) slice for all instances that are not "in" the existing slices:

Patient
  identifier (discriminator: system)
    (all)  <--- We have this today - the unsliced elements
      system (min:1)
    (ssn)
      system (fixed: http://.../ssn)
    (mrn)
      system (fixed: http://.../mrn)
    (default)  <--- This is the new thing, everything that is not an ssn or mrn.

Michel Rutten (Sep 27 2016 at 13:49):

Ah, so these default constraints would be separate from/in addition to the regular child elements?

Chris Grenz (Sep 27 2016 at 13:50):

They would apply to everything *not* already constrained by existing slices

Michel Rutten (Sep 27 2016 at 13:51):

So then Forge would have to display virtual child nodes for both "[all]" and "[default]" slice constraints?

Chris Grenz (Sep 27 2016 at 13:52):

Only if needed...but yes. Forge already needs the (all)

Chris Grenz (Sep 27 2016 at 13:53):

I'm no UI guy, but I'd probably use some visual aid to distinguish between a parent/child relationship (Patient->identifier) and an element/slice relationship (identifier->ssn). Maybe just a different color/style for the branch lines or something...

Michel Rutten (Sep 27 2016 at 14:22):

Indeed, concrete slices are already indicated by a special icon (currently a sliced pie chart). So this would discern the slices from the virtual "[all]" and "[default]" nodes.

Michel Rutten (Sep 27 2016 at 14:24):

I could easily bind visibility of the virtual nodes to a global toggle, so the user could selectively show/hide these elements. This would allow for a "basic" vs. "advanced" view. Just as the user can currently toggle visibility of the inherited common resource elements such as meta.

Grahame Grieve (Sep 27 2016 at 15:03):

I'm not sure I understand the use case; you want elements that don't match a slice to be constrained, but differently to the rules that apply to all slices?

Chris Grenz (Sep 30 2016 at 14:25):

Yes. Mostly for labeling/definition reasons, but potentially other constraints as well.

Chris Grenz (Sep 30 2016 at 14:25):

There are many cases where we'd like the set of slices to be complete and need an "other" bucket.

Grahame Grieve (Sep 30 2016 at 18:26):

I'm not entirely sure that would go with further slicing. It's kind of a lot easier to understand if it's final

Last updated: Apr 12 2022 at 19:14 UTC