all-types can't be normative when resource names may change - 2018-Jan Core #204

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Not Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • STU3
    • FHIR Infrastructure
    • OperationDefinition
    • Datatypes
    • Hide
      • Leave them as normative but add additional text that explains to implementers that these changes are handled by versions of code systems and what the consequences of that are for forwards/backwards compatibility of their code.
      • Consider giving each version of this valueset a different canonical url.
      Show
      Leave them as normative but add additional text that explains to implementers that these changes are handled by versions of code systems and what the consequences of that are for forwards/backwards compatibility of their code. Consider giving each version of this valueset a different canonical url.
    • Lloyd McKenzie/Grahame Grieve: 39-0-1
    • Correction
    • Non-substantive
    • STU3

      Comment:

      The value set "valueset-all-types" should not be taken normative because future breaking changes - such as renaming of an immature resource - are possible. An example of a breaking change is the current renaming of BodySite to BodyStructure.

      Summary:

      all-types can't be normative when resource names may change

            Assignee:
            Unassigned
            Reporter:
            Mark Kramer
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: