Jan 2015 Ballot Comment #192

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • DSTU1 [deprecated]
    • FHIR Infrastructure
    • ExtensionDefinition (see StructureDefinition) [deprecated]
    • 6.19.4
    • Hide

      To minimize complexity for implementers, HL7 will not elevate widely adopted extensions (defined by HL7 or other organizations) to be content defined in a core resource in future versions of the resource unless there is widespread endorsement of such a migration from the implementer community. This policy ensures that widespread adoption of an extension does not result in a forced migration to a core element. + add that extensions labeled as 'draft' may be moved in either direction, but that some extensions may be finalised as norrmative after which they won't be moved

      Show
      To minimize complexity for implementers, HL7 will not elevate widely adopted extensions (defined by HL7 or other organizations) to be content defined in a core resource in future versions of the resource unless there is widespread endorsement of such a migration from the implementer community. This policy ensures that widespread adoption of an extension does not result in a forced migration to a core element. + add that extensions labeled as 'draft' may be moved in either direction, but that some extensions may be finalised as norrmative after which they won't be moved
    • James Agnew / Grahame Grieve: 4-0-0
    • Enhancement
    • Non-substantive
    • DSTU1 [deprecated]

      Existing Wording
      To minimize complexity for implementers, HL7 will not elevate content defined in an HL7-approved extension to be content defined in a core resource in future versions of the resource once that resource is normative

      The domain committees will work to elevate the extensions into HL7 published extensions or, if adopted by a broad enough portion of the implementer community, the into the base resource structure itself.

      Proposed Wording
      To minimize complexity for implementers, HL7 will tend not to elevate content defined in an HL7-approved extension to be content defined in a core resource in future versions of the resource once that resource is normative, except in the case of broad adoption (see below).\\...
      The domain committees will work to elevate the extensions into HL7 published extensions or, if adopted by a broad enough portion of the implementer community, into the base resource structure itself.

      Comments
      The first sentence is a promise not necessary to make. Once a resource is normative, can't it still be updated in the future? Every other HL7 standard undergoes changes. So if in the future it makes sense to elevate content from an extension to the core (e.g., because that content has now become part of the "80% rule"), why rule that out? It is good to consider upgrades and migration and minimizing complexity, but shouldn't the main criterion for core resource content be that it is really the right content for the core, as the core evolves? In fact the sentence later in the section allows for elevation of extensions into the base resource, so the first sentence is contradicted by the latter.R[4]C

      Grahame's Comments
      clarify what extensions might go into core. But these rules relate to backwards compatibility, and aren't going to lightly change

      Disposition Comment
      The rule is in place because we want to commit to implementers that we will not unnecessarily force changes to existing implementations. If there's already a standard extension for a particular concept and 80% of implementers are uing that extension, we won't want to make them change just because the element now meets some magical criteria.

            Assignee:
            Unassigned
            Reporter:
            david_tao
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: