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

Specify version semantics above the resource level

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive with Modification
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • R5
    • FHIR Infrastructure
    • STU
    • Conformance Module
    • Hide

      The challenge is that there will be a lot of canonical artifacts that won't be defined in the context of an IG, nor be defined with references from a Library. Even for those that are, it won't always be obvious to someone seeing the artifact downstream which IG or Library it was defined in the context of to be able to go look up the versioning scheme. Finally, for IGs, if you do know the IG it was defined in the context of, you can use the package mechanism to figure out the newest version without even needing this mechanism. This mechanism is really for those situations where context can't be used to infer the versioning mechanism.

      No one's in love with having this attribute where it is, and the solution isn't perfect. However, it makes the problem 'better' and it's the best we've been able to come up with that can actually work for all artifacts.

      We will add a "Note to implementers" on canonical resource acknowledging that this mechanism we have for defining version comparison algorithm is inelegant and feels somewhat clunky, but that it was the best we could find that would work in all circumstances. We welcome alternative proposals that could be used to address the problem that would be less onerous.

      Show
      The challenge is that there will be a lot of canonical artifacts that won't be defined in the context of an IG, nor be defined with references from a Library. Even for those that are, it won't always be obvious to someone seeing the artifact downstream which IG or Library it was defined in the context of to be able to go look up the versioning scheme. Finally, for IGs, if you do know the IG it was defined in the context of, you can use the package mechanism to figure out the newest version without even needing this mechanism. This mechanism is really for those situations where context can't be used to infer the versioning mechanism. No one's in love with having this attribute where it is, and the solution isn't perfect. However, it makes the problem 'better' and it's the best we've been able to come up with that can actually work for all artifacts. We will add a "Note to implementers" on canonical resource acknowledging that this mechanism we have for defining version comparison algorithm is inelegant and feels somewhat clunky, but that it was the best we could find that would work in all circumstances. We welcome alternative proposals that could be used to address the problem that would be less onerous.
    • Bryn Rhodes/Gino Canessa: 17-0-3
    • Clarification
    • Non-substantive
    • R5

    Description

      The versionAlgorithm element introduced in CanonicalResource is specified at the wrong level, since the version algorithm applies to all versions of a given canonical. It also more usefully (and typically) applies to groups of resources, rather than to a specific canonical resource.

      Suggest defining this element on ImplementationGuide, and as an extension with a context of Library, so that it could be applied to an asset collection.

      Attachments

        Activity

          People

            Unassigned Unassigned
            bryn.rhodes Bryn Rhodes
            Bryn Rhodes
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: