There is need to have FHIR servers supporting multiple FHIR versions of resources. FHIR resources can be exchanged via means other than a FHIR server or API - including in files or wrapped as payloads in other protocols. Although a resource can include metadata that refres to a profile or profiles that might have a FHIR version number in their URL/strings or in actual structure definition resource content, this is a convoluted way to get to the FHIR version of a resource. This would enable a FHIR client to consume resources coming from various sources that support different FHIR versions (as long as the resources are compatible or can be transformed in a lossless manner).

This request is to have an (non-required) attribute to FHIR resources in the metadata of a DomainResource or Resource - for instance Meta.FHIRVersion - which is the FHIR specification version number to which this resource conforms.

A FHIR client would be able to determine the version of a FHIR resource in a straight forward manner and enable them to consume compatible data or to disregard incompatible data. It would enable compatibility between clients / servers using resources that have reached normative status without having to use the exact same FHIR version. It would also ease the migration to newer releases of the FHIR specification over time.

Note that this is similar to how CDA templates are designed - each template has a unique version ID and they can be used with other templates (document level, section level, enrty level) as needed rather than requiring/limiting all templates only of a particular release to be used together.