Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-28619

Allow slicing of a non-repeating element to define a choice

    XMLWordPrintableJSON

    Details

    • Type: Change Request
    • Status: Resolved - No Change (View Workflow)
    • Priority: Medium
    • Resolution: Not Persuasive
    • Specification:
      FHIR Core (FHIR)
    • Raised in Version:
      R4
    • Work Group:
      FHIR Infrastructure
    • Related Page(s):
      ElementDefinition
    • Resolution Description:
      Hide

      Document explicitly that, for non-repeating elements, slicing is only presently supported by type (and then only for polymorphic elements).  Also note that most use-cases for slicing non-repeating elements can be handled by invariants, or in the case of CodeableConcept by slicing the coding element.

      It is a considerable amount of work to extend the tooling around snapshot generation and validation to support slicing on non-repeating elements, so we'll only reconsider this rule if there are a number of convincing use-cases brought forward that can't reasonably be met by another technical solution.

      Show
      Document explicitly that, for non-repeating elements, slicing is only presently supported by type (and then only for polymorphic elements).  Also note that most use-cases for slicing non-repeating elements can be handled by invariants, or in the case of CodeableConcept by slicing the coding element. It is a considerable amount of work to extend the tooling around snapshot generation and validation to support slicing on non-repeating elements, so we'll only reconsider this rule if there are a number of convincing use-cases brought forward that can't reasonably be met by another technical solution.
    • Resolution Vote:
      Grahame Grieve/Rick Geimer: 17-0-0

      Description

      It would be very useful if the slicing mechanism was available for use with non-repeating (cardinality 0..1 or 1..1) elements in order to define choice(s) of constraints.  These constraints could include different (multiple) value set binding (but of course would not be limited to that and would allow increasing cardinality restrictions or any other applicable constraints).  It should be noted that a non-repeating (max cardinality = 1) element is simply the degenerate case of a repeating element with only a single repeat - so the existing slicing machinery should already be applicable, if the restriction(s) that currently prohibit its use in this context were removed.

      Apparently that the only place in the current specification where this is explicitly discussed and prohibited is in ElementDefinition.slicing here where it states that "Slicing can be used in any resource that has cardinality .. on the base resource, or any resource with a choice of types".  There does not appear to be a specific technical reason why this restriction is required.

      [It is noted that there is discussion and plans underway for providing the capability for multiple value set bindings on an element - and this is one way that could be accomplished largely using currently existing machinery.] 

      Slicing on 0..1 elements is currently being used in the published IPS IG, but with the more recent IG Publisher versions there are some remaining validation issues in the examples.  

      See the Zulip discussion on [Slicing non-repeating elements to define a choice](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Slicing.20non-repeating.20elements.20to.20define.20a.20choice).

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              rhausam Robert Hausam
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Vote Date: