Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-43749

Update Policy Doesn't Make Sense

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive
    • Icon: Medium Medium
    • FHIR Extensions Pack (FHIR)
    • 1.0.0
    • FHIR Mgmt Group
    • STU
    • Home Page
    • Update Policy
    • Hide
      • the whole specification would have to be made normative and then certain sections could be marked as draft/trial
      • the extensions will never be normative as a whole
      • these are not breaking changes to our breaking change rules; while we can have a longer term discussion about how we describe what's going on, the rules that we made are not breaking changes; references to extensions are version neutral
      • the update policy we made is necessary and required
      • we will discuss making  some extensions explicitly normative
      • how to manage that procedurally will need to be discussed with TSC
      • note that we are going to take up the question of making some things explicitly normative
      Show
      the whole specification would have to be made normative and then certain sections could be marked as draft/trial the extensions will never be normative as a whole these are not breaking changes to our breaking change rules; while we can have a longer term discussion about how we describe what's going on, the rules that we made are not breaking changes; references to extensions are version neutral the update policy we made is necessary and required we will discuss making  some extensions explicitly normative how to manage that procedurally will need to be discussed with TSC note that we are going to take up the question of making some things explicitly normative
    • e Vote / e Vote: 5-0-1

    Description

      The update policy should follow the standard FHIR approach to maturity and breaking changes. Instead of creating new rules about no breaking changes for active and some draft extensions, a better more consistent approach would be to make certain extensions explicitly normative. Apply the FMM and status values as intended and don't create exceptions. Instead of making breaking changes to our rules about breaking changes, we should be applying the rules that exist, because they exist for a purpose. 

      Attachments

        Activity

          People

            Unassigned Unassigned
            Mark_Kramer Mark Kramer
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: