Add invariants to OperationDefinition

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • DSTU2
    • FHIR Infrastructure
    • STU
    • OperationDefinition
    • Hide
      • Rename OperationDefinition.type to OperationDefinition.resource
      • Add OperationDefinition.type (type boolean, 1..1)
      • Add overload : Backbone [0..*] with child elements 'parameterName' of type string [1..*] and 'comment' : of type string [0..1].

        This will allow the author to suggest overloads based on the named parameters (as comma-separated lists) defined in the OperationDefinition.
      Show
      Rename OperationDefinition.type to OperationDefinition.resource Add OperationDefinition.type (type boolean, 1..1) Add overload : Backbone [0..*] with child elements 'parameterName' of type string [1..*] and 'comment' : of type string [0..1] . This will allow the author to suggest overloads based on the named parameters (as comma-separated lists) defined in the OperationDefinition.
    • Grahame Grieve/Chris Grenz: 10-0-2
    • Enhancement
    • Non-compatible
    • DSTU2

      There are quite a few operations already where there are co-dependencies between what parameters can be present. For example, specify a business id, a resource reference or resource content but not more than one of those. It would be nice if this could be expressed in a computable way. One thing that would be useful to expose in the computational mechanism is the context of how the operation is invoked - at the instance level, the type level or at the base level as many co-dependencies will care about that.

            Assignee:
            Unassigned
            Reporter:
            Lloyd McKenzie
            Lloyd McKenzie, Melva Peters
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: