Support for FHIR versions is unclear - N-Term #56

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • STU3
    • FHIR Infrastructure
    • CapabilityStatement (Conformance)
    • CapabilityStatement.
    • Hide

      *A single endpoint can support multiple FHIR versions, but the "metadata" endpoint will return only one CapabilityStatement/Conformance instance based on the version requested. Thus each CapabilityStatement is specific to 1 fhirVersion.

      • We should make the descriptions consistent to mean that this is the version of the FHIR specification that the system described by this capabilitystatement supports or has to support (if the statement represents requirements).
      • There is no default value and it should always be present.
      • We do not set rules on how a server is deployed or what the endpoint url looks like - so we do not set rules on whether the version number is part of the url.
      • Expected behavior for references across versions is presently undefined - we will mention this at the Resource type page.
      • Clarifications on how to work with versions on the REST endpoint can be found at the page "versioning.html" in the specification. Add a reference to this from the fhirVersion usage notes.
      • Also add a reference to the $versions operation from the fhirVersion usage notes
      • Will add a "non-core" extension to support cross-referencing version endpoints when multi-version support is handled via different endpoints. Can look at migrating this to a core extension (or core element) in R5
      Show
      *A single endpoint can support multiple FHIR versions, but the "metadata" endpoint will return only one CapabilityStatement/Conformance instance based on the version requested. Thus each CapabilityStatement is specific to 1 fhirVersion. We should make the descriptions consistent to mean that this is the version of the FHIR specification that the system described by this capabilitystatement supports or has to support (if the statement represents requirements). There is no default value and it should always be present. We do not set rules on how a server is deployed or what the endpoint url looks like - so we do not set rules on whether the version number is part of the url. Expected behavior for references across versions is presently undefined - we will mention this at the Resource type page. Clarifications on how to work with versions on the REST endpoint can be found at the page "versioning.html" in the specification. Add a reference to this from the fhirVersion usage notes. Also add a reference to the $versions operation from the fhirVersion usage notes Will add a "non-core" extension to support cross-referencing version endpoints when multi-version support is handled via different endpoints. Can look at migrating this to a core extension (or core element) in R5
    • Grahame Grieve/Christiaan Knaap: 35-0-1
    • Enhancement
    • Non-substantive
    • STU3

      Comment:

      Capability statement contains a property fhirVersion (1..1) with the description "FHIR Version the system uses." This seems to imply that the server supports a single FHIR version.

      The definition is "The version of the FHIR specification on which this capability statement is based." This seems to leave the door open for the server supporting multiple versions, but does not answer how it decides which version to use in generating the Statement.

      The existence of a $versions operation makes it clear that the server may support multiple versions.

      Suggestions:

      1. Harmonize Description and Definition for CapabilityStatement.fhirVersion.

      2. Clarify how a value is selected for CapabilityStatement.fhirVersion. Is is only the default? It seems desireable to understand this information for other versions.

      3. Clarify how a client addresses a resource for conformance and operation. Does the server simply test against all known versions? Or does it require a version-specific path?

      4. Clarify whether it is possible for, e.g., a V4 Condition to reference a V3 Observation? Or to assert such a relationship in a profile?

      5. Clarify the effects of these decisions on a server federating content from other servers.

      Summary:

      Support for FHIR versions is unclear

            Assignee:
            Unassigned
            Reporter:
            Jay Lyle
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: