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

A mechanism to retrieve the "most recent" version of a resource

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • R4
    • FHIR Infrastructure
    • ValueSet
    • Hide

      We will define a new 'STU' choice element on the CanonicalResource "versionAlgorithm[x]" with a type of Coding|string

      Definition: Indicates the mechanism used to compare versions to determine which is more current.

      Comment: If set as a string, this is a FHIRPath expression that has two additional context variables passed in - %version1 and %version2 and will return a negative number if version1 is newer, a positive number if version2 and a 0 if the version ordering can't be successfully be determined.

      Rationale: Needed to allow computable resolution of non-versioned references (which are supposed to refer the 'most recent' version)

      Initial set of codes (extensible binding):

      semver: Uses the semantic versioning scheme as defined in rfc???

      integer: versions are integers and ordered numerically

      alpha: Simple alphabetic sort on a case-insensitive and accent-insensitive basis.  (Sorting of different cases or accented versions of a character are indeterminate)

      date: versions are expressed as an ISO date/time syntax (including syntaxes with only portions of a date)

      natural: sorted according to the algorithm defined here: http://www.naturalordersort.org/

       

      Add a 'warning' invariant for R5+ if version is present and this element is not

      Show
      We will define a new 'STU' choice element on the CanonicalResource "versionAlgorithm [x] " with a type of Coding|string Definition: Indicates the mechanism used to compare versions to determine which is more current. Comment: If set as a string, this is a FHIRPath expression that has two additional context variables passed in - %version1 and %version2 and will return a negative number if version1 is newer, a positive number if version2 and a 0 if the version ordering can't be successfully be determined. Rationale: Needed to allow computable resolution of non-versioned references (which are supposed to refer the 'most recent' version) Initial set of codes (extensible binding): semver: Uses the semantic versioning scheme as defined in rfc??? integer: versions are integers and ordered numerically alpha: Simple alphabetic sort on a case-insensitive and accent-insensitive basis.  (Sorting of different cases or accented versions of a character are indeterminate) date: versions are expressed as an ISO date/time syntax (including syntaxes with only portions of a date) natural: sorted according to the algorithm defined here: http://www.naturalordersort.org/   Add a 'warning' invariant for R5+ if version is present and this element is not
    • Bas van den Heuvel/Vadim Peretokin: 40-0-4
    • Enhancement
    • Compatible, substantive
    • R5

    Description

      To add a technical mechanism that supports getting the "most recent" version.

      Use Case: to construct a resource it's often required to retrieve the most recent version of underlying value sets. Some of them are too big to pull them every time when a resource is created. It's better to cache the value set on the "resource generator" side and check if a newer ValueSet is available on the Terminology Server and GET ValueSet only if the newer version has been published.

      E.g.: GET <base>/ValueSet?title=AdministrativeGender&version*:above*=4.0.0

      Attachments

        Activity

          People

            GrahameGrieve Grahame Grieve
            shamil Shamil Nizamov
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: