-
Type:
Change Request
-
Resolution: Persuasive with Modification
-
Priority:
Medium
-
FHIR Core (FHIR)
-
DSTU1 [deprecated]
-
FHIR Infrastructure
-
ExtensionDefinition (see StructureDefinition) [deprecated]
-
6.19.4
-
-
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.
- is voted on by
-
BALLOT-187 Negative - David Tao : 2015-Jan-FHIR R1
- Balloted