Clarify interaction of constraints on CodeableReference and its sub-paths

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Unresolved
    • Priority: Medium

      The CodeableReference type indicates that "the value set binding actually applies to the concept element" and "the list of valid target types for the CodeableReference resource applies to the Reference."

      The specification does not explicitly prohibit:

      • Putting bindings directly on the CodeableConcept.concept element
      • Restricting target types directly on the CodeableConcept.reference element

      Assuming those cases are valid, then the specification should clarify some points:

      • Is applying bindings or constraining types on the top-level CodeableReference the preferred approach? If so, how strong is that preference? Should these only be applied to lower-level properties in "exceptional" circumstances?
      • Is it valid to have bindings on CodeableReference and CodeableReference.concept at the same time?
        • If it is valid, how should implementers handle cases where those bindings are different?
        • If it is not valid, then this should be made explicit via an invariant.
      • Is it valid to constraint the `targetType` on CodeableReference and CodeableReference.reference at the same time?
        • If it is valid, how should implementers handle cases where the subset of types is different on each element?
        • If it is not valid, then this should be made explicit via an invariant.

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

              Created:
              Updated: