Limit ElementDefnition.min to 0 or 1

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: High
    • FHIR Core (FHIR)
    • R5
    • FHIR Infrastructure
    • ElementDefinition
    • 2.31.2.1
    • Hide

      We will add a constraint on StructureDefinition requiring that min is either 0 or 1 (and max is either 1 or *) when defining a new resource.  (We can't define it as a general constraint on ElementDefinition because other cardinalities are possible when profiling.)

      Show
      We will add a constraint on StructureDefinition requiring that min is either 0 or 1 (and max is either 1 or *) when defining a new resource.  (We can't define it as a general constraint on ElementDefinition because other cardinalities are possible when profiling.)
    • Grahame Grieve/Vadim Peretokin: 8-0-0
    • Clarification
    • Non-substantive

      Issue FHIR-9283 is resolved by not allowing 2..* as cardinality for an element because the tooling would not support that.

      Besides that it is usually a better idea to explicitly model the two items that you would expect then. E..g.

      not endpoint 2..*

      but source 1..1 and target 1..*

      However, currently ElementDefinition.min has no restrictions other than unsignedInt. So specifying 2 as the min cardinality is perfectly valid.

      For the tooling: investigate what tooling actually would break on this.

      For modelling: discuss how desirable the use of min cardinality > 1 is.

      If just 0 or 1 is neccessary for any of the two reasons, it should be made explicit as a constraint on ElementDefinition.min.

            Assignee:
            Unassigned
            Reporter:
            cpk
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: