Uploaded image for project: 'Other Specification Feedback'
  1. Other Specification Feedback
  2. OTHER-2618

Use of extensions in earlier FHIR releases complicated by SFCU's use of CodeableReference

XMLWordPrintableJSON

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Highest Highest
    • Cross Paradigm Gender Harmony - Sex and Gender Representation (OTHER)
    • 1.0.0-ballot
    • Terminology Infrastructure
    • FHIR Guidance
    • 11.4
    • Hide

      FHIR-I agrees that a solution that can apply to any extension using CodeableReference is preferred to multiple specific backported extensions. The approach is discussed in Zulip thread Backporting CodeableReference . The result of this will be that the FHIR publisher and validator will automatically include into an R4 package the R5 extension with codeableReference changed to the structure finally decided by FHIR-I. That structure is not set as of 2023-08-23 but will be before publication.

      For now, the Backwards Compatibility section of the FHIR design page will say the following, with an addition that shows the final structure choice when that is set.

      Backwards Compatibility for FHIR versions:

      One of the benefits to using extensions in [FHIR R5](https://hl7.org/fhir/R5/) is that they can be easily backported to prior versions. Implementers may use any of the new standard extensions in R5 in prior versions of FHIR. This is further discussed in the [Version Management Policy](https://hl7.org/fhir/r5/versions.html#extensions) of the R5 documentation.

      However, the [patient-sexParameterForClinicalUse](http://hl7.org/fhir/extensions/StructureDefinition-patient-sexParameterForClinicalUse.html), and the [individual-recordedSexOrGender](http://hl7.org/fhir/StructureDefinition/individual-recordedSexOrGender) extensions make use of the CodeableReference datatype, which was added in R5. Further analysis of the implications for backporting this datatype resulted in improvements to the FHIR publisher and validator so that any [FHIR R4](https://hl7.org/fhir/R4B) guide that creates a dependency on one of the R5 extensions will have the agreed upon R4 structure for this datatype inserted into the R4 representation of the extension. In other words the FHIR publisher provides a datatype conversion that is independent of our R5 extensions so that they will work in any R4 implementation.

      Show
      FHIR-I agrees that a solution that can apply to any extension using CodeableReference is preferred to multiple specific backported extensions. The approach is discussed in Zulip thread Backporting CodeableReference . The result of this will be that the FHIR publisher and validator will automatically include into an R4 package the R5 extension with codeableReference changed to the structure finally decided by FHIR-I. That structure is not set as of 2023-08-23 but will be before publication. For now, the Backwards Compatibility section of the FHIR design page will say the following, with an addition that shows the final structure choice when that is set. Backwards Compatibility for FHIR versions: One of the benefits to using extensions in [FHIR R5] ( https://hl7.org/fhir/R5/ ) is that they can be easily backported to prior versions. Implementers may use any of the new standard extensions in R5 in prior versions of FHIR. This is further discussed in the [Version Management Policy] ( https://hl7.org/fhir/r5/versions.html#extensions ) of the R5 documentation. However, the [patient-sexParameterForClinicalUse] ( http://hl7.org/fhir/extensions/StructureDefinition-patient-sexParameterForClinicalUse.html ), and the [individual-recordedSexOrGender] ( http://hl7.org/fhir/StructureDefinition/individual-recordedSexOrGender ) extensions make use of the CodeableReference datatype, which was added in R5. Further analysis of the implications for backporting this datatype resulted in improvements to the FHIR publisher and validator so that any [FHIR R4] ( https://hl7.org/fhir/R4B ) guide that creates a dependency on one of the R5 extensions will have the agreed upon R4 structure for this datatype inserted into the R4 representation of the extension. In other words the FHIR publisher provides a datatype conversion that is independent of our R5 extensions so that they will work in any R4 implementation.
    • Mary Kay M / Christopher G: 9-0-1
    • Enhancement
    • Compatible, substantive

      A slight challenge to using the R5 extensions in R4 is that the CodeableReference datatype (used in the SFCU extension) was introduced in R5. There is a defined mechanism to use it in earlier versions, but you may want to alert readers to this potential challenge.

      Existing Wording:

      One of the benefits to using extensions in R5 is that they can be easily backported to prior versions. Implementers may use any of the new standard extensions in R5 in prior versions of FHIR.

      (Comment 60 - imported by: Lloyd McKenzie)

            Unassigned Unassigned
            Rongparker Ron G. Parker
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: