Question
· Apr 11

Call for FHIR experts: R5 vs R4

Hi Community,

Starting a FHIR repository project with IRIS for Health, what are the pros and cons to use R5 instead of R4 ?
What is the effort to migrate from R4 to R5 the FHIR repo ?
What are the risks or disadvantages to use R5 ?

Thanks

Discussion (3)2
Log in or sign up to continue

I got an interesting answer from chat.fhir.org

Lloyd McKenzie says : 

R5 has a bunch of fixes and enhancements and is 'closer' to what the normative/locked down versions of each of the resources is likely to be. So, all things being equal, R5 is a better bet. However, the amount of implementation support for R5 is considerably less than for R4 and some jurisdictions may opt to not support R5 at all. (E.g. the U.S.) Therefore consider who you're going to need to share with.

The migration effort really depends on what you're implementing. Some resources (e.g. Patient, Observation, etc.) have changed very little - and the changes that did occur may not impact your application because you don't use those elements. Other resources have changed more radically. The amount of effort involved also depends on how your software is architected. You can see lists of changes and maps between R4 and R5 in the R5 spec on each resource page.

Finally, 'repository' is not the same as 'interface'. It's perfectly possible to expose both an R4 and an R5 API on the same internal data store. Typically you'll have to map between your internal storage representation and your FHIR API regardless of what version you support, so two interfaces just means two sets of maps.

Remember FHIR is a very immature 'standard'.
If you jump on the bandwagon, you must be prepared to be agile.
You talk about R5, but R6 is well on its way and, since they actually are STU4, 5, 6 and so on, there is no FHIR 1.0
Some standard bodies opt for stability like Nictiz in the Netherlands, where most of the official specifications are still based on STU3.
Opting for implementation of an immature standard ,one must be prepared for (extreme) agility, otherwise we are all ending op with in-operability because of different incompatible implementations.