Interoperability issues are acute not only in heterogeneous environments where diferent standards are used, but also in homogeneous environments where the same standard is used diferently for individual organisations. Interoperability is also important within one organisation and especially arises when transferring systems from one version of the standard to another. This article discusses the compatibility of the various versions of the HL7 FHIR standard, focusing on the current R4 version at the time of writing. It also describes the individual features of earlier versions of the HL7 FHIR standard. The article analyses the principles of forward and backward compatibility and proposes recommendations for how to develop a sustainable and balanced interoperability system.
Resource development is evolutionary. It undergoes several specification reviews and
community connectathons (community testing) and feedback from early implementers. As a result,
each resource is assigned a level of maturity according to the FMM (FHIR Maturity Model) [
Forward compatibility means that content compatible with the old version of the standard is
also compatible with the new version. For normative resources, FHIR seeks to ensure, but does
not guarantee, the compatibility of resources. Backward compatibility means that instances
created against future versions of a specification work with older versions of the specification.
The development of the resource information model is based on the ’80/20’ [
FHIR extensions are a fundamental part of FHIR architecture. Each element expanded according to the needs. Each extension can be repeated an unlimited number of times. With the extension mechanism, it is possible to solve every existing and potential use case. Where extensions allow new elements to be added, profiles regulate the use of resources in a specific user manual. FHIR profiles describe what specific elements, including extensions, must be used, whether they are mandatory and what terminology and additional restrictions must be used. The FHIR profile allows you to describe the exact rules for, say, the transmission of blood pressure data, the admission of an unknown patient to the emergency department or the registration of a death.
The evolution of services requires the provision of support, the creation of new features, which
leads to many versions that need to be maintained [9]. Service versioning typically means
versioning the implementation or an interface of a service [10] [11]. In the context of service
evolution, which regards the integration between customers and providers, the versioning of the
service interface is often addressed, particularly the service interface description. Since the FHIR
standard uses the latest web standards [
The FHIR information model, along with extensions and profiling, allows the creation of the necessary implementation guides for virtually every case in health care. This flexibility has obvious advantages and disadvantages. On the one hand, there is the possibility for rapid adoption in the changing world of health care and the provision of the most suitable information services for healthcare companies. On the other hand, constant change leads to a situation where we encounter a lot of data created on the basis of diferent versions of FHIR standards and profiles and their data difer to one degree or another. The multiplicity of versions raises several questions: • Backward-compatibility ensures that consumers using old services need not be upgraded to use the modified service. That is, when service providers upgrade their services to ofer the latest functionalities, service consumers need not be aware of the changes and can continue to use the services as before. On the other hand, forward-compatibility guarantees that new consumers need not be downgraded to work with an old service. That is, when service consumers deploy a new client application that conforms to the modified Web service interface, it should be able to work with the old Web service as well, without having to downgrade [12]. • How should ’old’ data, i.e. data created according to previous standards, be processed in software that only supports the last valid version of the standard? How should deleted attributes, changed cardinality, expired concepts in terminology, etc. be handled? • How should software be designed so that it can function in an environment where a new standard has been introduced, about which it knows nothing at the time of design? How should the software handle new elements still unknown to it, the disappearance of elements, new concepts in terminology, etc.? • Can software that create data using diferent versions of the standard work in one information space? Do they cause one to another problems with continuous cross-version conversions?
In this paper, forward and backward compatibility design methods and individual properties in the context of the HL7 FHIR standard are compared. In analysis, the SWOT methodology is used. The SWOT methodology evaluates various parameters of the solution: strengths, weaknesses, opportunities and threats.
The FHIR specification thoroughly describes the principles of change management and versioning [20]. Based on this description, the following can be argued: • Versions are forward compatible if the content created with the old standard is also compatible with the new version of the standard. • Versions are not forward compatible if at least one of the requirements is not satisfied. • Backward compatibility means that instances created against future versions of a specification will work with older versions of the specification. • Versions are not backward compatible if at least one of the requirements is not satisfied. • Versions are forward and backward compatible when both forward and backward compatibility conditions apply simultaneously.
Forward compatibility can easily be achieved by the developer of the standard if the principles of the forward-compatible solution are followed. In the new version of the standard for the forward-compatible solution: 1. all elements that existed in the previous version are present;
4. cardinality is weaker, e.g. from mandatory [1..1] becomes optional [0..1]; 5. all values from the previous version are present in the related terminology list.
Consider that in version X we have resource R and in version X+1 the same resource is updated to version R’ with the data structures, as illustrated in Figure 1. The most important factor is the decision of the developer of the standard on whether to support the principle of compatibility or not. If compatibility is supported, it makes sense to develop checklists to use for each modified resource, verifying that all compatibility principles have been implemented. Add new artifacts (resources, elements, operations) Add new optional element in resource Add new artifact to the Implementation Guide Reduce cardinality, incl. an element becomes an optional Depricate artifact Remove artifact (resource, element, operation, profile) Modify artifact name or path Modify element data type (except string to markdown) Modify "Is Modifier" and "Is Summary" flags Modify slicing and aggregation rules Remove search criteria in profiles Change the list of global profiles in Implementation Guide Forward Compatible
Yes Yes Yes Yes Yes No No No No No No No
If the developer of the standard does not proceed from the compatibility principle, the content created by the old standard will not be compatible with the new version by default. In this case, two software, one with the old version and the other with the new version, start creating conflicting content, which leads to the failure of one application or another. This problem is easiest to solve organisationally, requiring the transition of all software to a new version from a certain moment. However, with the abundance of software and varying lengths of the release cycles, this is very problematic, if not impossible.
On the other hand, data that were created with an earlier version and that no longer meet the new standard will remain in the data repository. This leads to the idea that every implementer should support not only one version of the latest standard, but all versions of the standard supported by the data repository keeper. It is widespread practice to support the last two or three versions of the standard and to archive earlier versions by preventing the adoption of data in formats which are too old. 2.3.1. Data conversion Supporting two or three versions of each software significantly increases the price of the software being developed and the associated support price. In addition, archived versions are emerging, i.e. version support that may not be available on new software. Consider that the patient has several diagnoses transmitted to the data repository on an accrual basis using diferent versions of DSTU R2 (1.0), STU R3 (3.0) and R4 (4.0) in force at the time. Consider that the data repository keeper is archiving version DSTU R2, that is, new software no longer needs R2 support. However, the patient diagnoses query returns all resources, including those that were created in archived versions. The sample query illustrated in the following script asks for all patient ’P1’ diagnoses.
GET / f h i r / C o n d i t i o n ? p a t i e n t =P1 The answer is a bundle, where the Profile section specifies the version of the resource, as illustrated in Listing 1.
Body : { " r e s o u r c e T y p e " : " B u n d l e " , " t y p e " : " s e a r c h s e t " , " t o t a l " : 3 , " e n t r y " : [ { " f u l l U r l " : " h t t p s : / / e x a m p l e . com / b a s e / C o n d i t i o n / 2 0 1 " , " r e s o u r c e " : { " r e s o u r c e T y p e " : " C o n d i t i o n " , " i d " : " 2 0 1 " , " meta " : { " l a s t U p d a t e d " : " 2013 −05 −25 T22 : 1 2 : 2 1 Z " " p r o f i l e " : [ " h t t p : / / h l 7 . o r g / f h i r / 1 . 0 /
S t r u c t u r e D e f i n i t i o n / C o n d i t i o n " ] } , . . . } , { " f u l l U r l " : " h t t p s : / / e x a m p l e . com / b a s e / C o n d i t i o n / 3 0 1 " , " r e s o u r c e " : { " r e s o u r c e T y p e " : " C o n d i t i o n " , " i d " : " 3 0 1 " , " meta " : { " l a s t U p d a t e d " : " 2016 −06 −26 T22 : 1 2 : 2 1 Z " " p r o f i l e " : [ " h t t p : / / h l 7 . o r g / f h i r / 3 . 0 /
S t r u c t u r e D e f i n i t i o n / C o n d i t i o n " ] } , . . . } , { " f u l l U r l " : " h t t p s : / / e x a m p l e . com / b a s e / C o n d i t i o n / 4 0 1 " , " r e s o u r c e " : { " r e s o u r c e T y p e " : " C o n d i t i o n " , " i d " : " 4 0 1 " , " meta " : { " l a s t U p d a t e d " : " 2 0 1 9 − 0 9 − 2 9 T22 : 1 2 : 2 1 Z " " p r o f i l e " : [ " h t t p : / / h l 7 . o r g / f h i r / 4 . 0 /
S t r u c t u r e D e f i n i t i o n / C o n d i t i o n " ] } , . . .
} } Listing 1: Patient diagnoses query which returns data generated in three FHIR versions In this situation, all resource entries must be converted from version R2 to a newer version; in our example, preferably to the latest version R4. This conversion requires precise instructions on how to perform said conversion. The following situations must be considered: 1. The element in R2 is removed from the new version – in this case, in the new version, this element must be represented as an extension. 2. The data type of the element changes between the two versions – a formula is drawn up to convert the data and the original element is presented as an extension. 3. The new version of ValueSet has no value from version R2 – a map of the concepts (ConceptMap) must be composed between versions R2 and R4. 4. In the new version, a new mandatory element is added – it is necessary to make a formula for how the value of the new element can be calculated from the data in R2.
The fact that the data in the versions withdrawn from use, as a rule, are associated with completed operations, narrowing the required number of mappings, should be taken into consideration. In a situation where it is not possible to create a formula or mapping table, or where the clinical value may change as a result of this activity, special values such as ’unknown’ or ’data-in-error’ must be added to the list to avoid changing the clinical content. Such conversion can be done either using the FHIR server custom adapter, which would convert R2 resources to R4 based on the described mappings, or by creating a physical entry in the data repository with reference to the newer version profile. Creating such inter-versioning mappings for resources and terminology is a serious analytical task that deserves its own article.
The solution with dynamical transformation is preferred, as it allows you to easily repeat activities without changing data, ensuring the best quality. It is important to mention that the resource conversion between versions is not part of the FHIR specification, has no agreed syntax and is not supported by any FHIR server by default. On the other hand, for large amounts of data, continuous conversion can place a heavy load on the CPU.
The same or other adapters can help make permanent transformations in data. In this case, a new version of the resource with a reference to the new standard is generated in the data repository. In this regard, it is important to proceed from the principle of not changing the original data, including, as a result of the transformation, to create a new version of the resource, with the original version remaining unchanged. An alternative is a combined solution, where for a suficiently long period of time (6-12 months), an dynamical converter is used. After which, in the absence of any claim to clinical content, a single physical conversion from the old standard to the new one is carried out using the same adapter. The converter is then withdrawn from use and the old standard is archived.
For a backward-compatible solution, the old application must be able to process copies of the new version without knowing the changes. Such a situation cannot be guaranteed by the FHIR specification, nor by the local standard developer. Software design and readiness to adopt the new version of the standard play a bigger role. A software developer can develop systems that follow backward compatibility strategies and increase their interoperability capabilities [22]. In the simplest case, the FHIR specification describes a series of actions that end-applications must use to increase backward compatibility when processing [23] a resource generated with the new standard:
5. Respond within the prescribed error codes when addressing an unknown URL
Unfortunately, in reality, few implementers observe these rules due to the technical limitations of the software or the potential clinical risk that arises from ignoring certain elements. Another considerable alternative is the use of narrative. Narrative [24] is a human-readable summary of the resource. In a situation where the oldest software is not able to process a resource created according to a newer standard, it: 1. does not focus on processing the content part and displays only the narrative or; 2. combines the processing of the elements it understands and the displaying of the narrative.
In these cases, the application must be designed to identify the Backward Compatibility problem and display the narrative. The sample query is as follows: GET / O b s e r v a t i o n / e x a m p l e A c c e p t : a p p l i c a t i o n / f h i r + j s o n ; f h i r V e r s i o n = 3 . 0
C o n t e n t − Type : a p p l i c a t i o n / f h i r + j s o n ; f h i r V e r s i o n = 3 . 0 { " r e s o u r c e T y p e " : " O b s e r v a t i o n " , " i d " : " e x a m p l e " , " t e x t " : { " s t a t u s " : " g e n e r a t e d " , " d i v " : " <p><b > i d < / b > : e xa mpl e < / p> <p><b > s t a t u s < / b > : f i n a l < / p> <p><b > code < / b > : Body Weight < / p> <p><b > s u b j e c t < / b > : <a > P a t i e n t / exa mpl e < / a > </ p> and the related visual presentation in any web browser is as follows: id : status : code : ℎ subject : / efective : 28 − 03 − 2016 value: 100 kg
Health Information System records are often subject to commercial and legal requirements for their storage, sometimes up to 100 years, which can lead to a situation in which formalised data is not processed and is not displayed in all applications and devices for the required period of time. In order to ensure this kind of backward compatibility for each FHIR producer, it is reasonable to think about a narrative generation system that takes into account the peculiarities of local medicine, legalisation and jurisdiction and generates a narrative by which resources are received on the FHIR server if the narrative is not predefined by the record creator.
The processing of unknown elements must be considered as a special case. Unknown elements can occur when elements are removed, renamed or added in a newer version of a specification. Some of approaches enforce forward compatibility through extensions [25]. According to the FHIR specification, each element has an extension URL that uniquely identifies said element. An extension URL can be automatically derived in the form: h t t p : / / h l 7 . org / f h i r / [ v e r s i o n ] / S t r u c t u r e D e f i n i t i o n /
e x t e n s i o n −[ Path ]
In this case, the FHIR server could return the elements changed between versions as extensions. The example below demonstrates this approach on the example of an animal patient, where it was possible to determine animal characteristics in the STU3 version.
{ " r e s o u r c e T y p e " : " P a t i e n t " , " i d " : " animal " , " a c t i v e " : true , " name " : [ {
" use " : " u s u a l " , " g i ve n " : [ " Kenzi " ] } ] , " animal " : { " s p e c i e s " : { " coding " : [ { " system " : " h t t p : / / h l 7 . org / f h i r / animal − s p e c i e s " , " code " : " c a n i s l f " , " d i s p l a y " : " Dog " } ] } , " g e n d e r S t a t u s " : { " coding " : [ { " system " : " h t t p : / / h l 7 . org / f h i r / animal − g e n d e r s t a t u s " , " code " : " n e u t e r e d " } ] } } }
Accept : a p p l i c a t i o n / f h i r + j s o n ; f h i r V e r s i o n = 4 . 0
...returns resource elements (Listing 4) as animal-species and animal-genderStatus extensions, since these elements were removed from the standard in R4. { " r e s o u r c e T y p e " : " P a t i e n t " , " i d " : " animal " ,
As you can see from the example, in the FHIR resource of normative content, a developer who creates an application in accordance with this Standard may encounter extensions they may not have considered, which is why well-designed applications that display all unknown extensions ensure better clinical quality and insight into the data.
Although versioning of web servers, in general, is fairly well researched, versioning in the FHIR standard is not covered in the scientific literature. The author considered the design principles of forward and backward compatibility and methods for solving problems in particular cases. Several solutions are aggregated in Table 2. A good standard developer creates implementation guides with both forward and backward compatibility principles in mind. The FHIR specification and current study prescribes a series of forward and backward compatibility rules.
Each implementer should create a checklist with the forward and backward compatibility rules specified in the FHIR specification and upgrade them based on their own deployment experience and that of others. If backward compatibility is dificult to achieve, the developer of the standard should at least ensure that the forward compatibility of the standard. In the author’s opinion, failure to ensure forward compatibility is equivalent with non-versioning or with a situation where there are no versioning principles or design.
The FHIR specification does not solve all of the forward and backward compatibility issues mentioned, and given that at the time of writing the article, the share of normative resources was less than 10% of the total specification, every developer of the standard must take the versioning of the system design very seriously. On the other hand, it is equally important to enlighten educational services software developers about forward and backward compatibility, carry out FHIR Connecthatons in order to increase interoperability between versions and ofer certification and require software developers to comply with it.
The FHIR specification describes quite a few measures that help ensure forward and backward compatibility. The FHIR extensions mechanism helps convert resources between versions if there is appropriate support on the FHIR server. In work proposed, converters allow the content of resources between versions to be transformed dynamically. The narrative ensures the readability of clinical content by a specialist even after decades have passed. Table 3 describes the key aspects that need to be addressed in the field of forward and backward compatibility for each standard developer. This article is the first in its series and discusses the design principles that can be applied by the standard developer in their work. Further research should look at the following: • The syntax describing transformations, which includes both conversion of resource elements and conversion of terminology concepts, is not standardised by FHIR and requires an article of its own. • FHIR data retention logic and endpoint logic of FHIR servers, which handle diferent relics (e.g. R2 and R5) and serve responses using diferent headers, paths and even resources that were valid in the respective version.
I.B. designed the idea and wrote the manuscript with support from G.P. All authors contributed to the final version of the manuscript. G.P. and P.R. supervised the project.
We thank the TEHIK (Health and Welfare Information Systems Centre, Estonia) https://www. tehik.ee/ and the Kodality https://www.kodality.com/ teams who validated the methods deGenerate a narrative based on uniform rules on Complexity of inter-version mappings of rethe FHIR server to provide human-readable out- sources and terminology put When storing resources, store the version of the resource alongside the resource
High server load, complexity and support cost for inter-version, dynamical resource converter between versions
Ir-reversibility of on-demand transformations Maintain forward and backward conversions for Changing of clinical meaning during interthe parts of resources that matter to the appli- version transformation cation Dynamical resource converter between versions On-demand data transformer from older version to current version Store resources in transformed state Store resources in both received and transformed state Host multiple end-points for a variety of purposes scribed in adopting the FHIR standard for the National Health Service of Estonia. This work in the project ’ICT programme’ was supported by the European Union through the European Social Fund. 2022-04-03. [8] HL7, Profiling - fhir v4.0.1., https://www.hl7.org/fhir/profiling.html, 2011. Accessed: 202204-03. [9] M. P. Papazoglou, The challenges of service evolution, in: International Conference on
Advanced Information Systems Engineering, Springer, 2008, pp. 1–15. [10] K. Becker, A. Lopes, D. S. Milojicic, J. Pruyne, S. Singhal, Automatically determining compatibility of evolving services, in: 2008 IEEE International Conference on Web Services, IEEE, 2008, pp. 161–168. [11] D. Frank, L. Lam, L. Fong, R. Fang, M. Khangaonkar, Using an interface proxy to host versioned web services, in: 2008 IEEE International Conference on Services Computing, volume 2, IEEE, 2008, pp. 325–332. [12] C. Armbruster, Design for evolution, https://chrisarmbruster.com/documents/ design-for-evolution-white-paper.pdf, 1999. Accessed: 2022-04-03. [13] P. Kaminski, M. Litoiu, H. Müller, A design technique for evolving web services, in: Proceedings of the 2006 conference of the Center for Advanced Studies on Collaborative research, 2006, pp. 23–es. URL: https://dl.acm.org/doi/abs/10.1145/1188966.1188997, accessed: 2022-04-03. [14] M. Fokaefs, R. Mikhaiel, N. Tsantalis, E. Stroulia, A. Lau, An empirical study on web service evolution, in: 2011 IEEE International Conference on Web Services, IEEE, 2011, pp. 49–56. [15] M. C. Yamashita, Service versioning and compatibility at feature level (2013). [16] M. Yamashita, B. Vollino, K. Becker, R. Galante, Measuring change impact based on usage profiles, in: 2012 IEEE 19th International Conference on Web Services, IEEE, 2012, pp. 226–233. [17] R. Fang, L. Lam, L. Fong, D. Frank, C. Vignola, Y. Chen, N. Du, A version-aware approach for web service directory, in: IEEE International Conference on Web Services (ICWS 2007), IEEE, 2007, pp. 406–413. [18] M. Yamashita, K. Becker, R. Galante, A feature-based versioning approach for assessing service compatibility, Journal of Information and Data Management 3 (2012) 120–120. [19] M. Endrei, M. Gaon, J. Graham, K. Hogg, N. Mulholland, Moving forward with web services backward compatibility, 2006. [20] HL7, Fhir change management and versioning, http://hl7.org/fhir/versions.html, 2011.
Accessed: 2022-04-03. [21] HL7, Fhir rules for inter-version change, http://hl7.org/fhir/versions.html#change, 2011.
Accessed: 2022-04-03. [22] T. Benson, G. Grieve, The fhir api, in: Principles of Health Interoperability, Springer, 2021, pp. 103–121. [23] HL7, Fhir backward compatibility rules, http://hl7.org/fhir/versions.html#change, 2011.
Accessed: 2022-04-03. [24] HL7, Narrative - fhir v4.6.0, https://build.fhir.org/narrative.html, 2011. Accessed: 2022-0403. [25] V. Andrikopoulos, S. Benbernou, M. P. Papazoglou, On the evolution of services, IEEE Transactions on Software Engineering 38 (2011) 609–628.