FHIR R5 Migration: Azure Health Data Services to Self-Hosted Solution

[NC-olemal]

Hi,

I am a consultant working for the Norwegian Medical Products Agency (NOMA), and we are currently analyzing a transition from FHIR R4 to FHIR R5 for one of the services we are developing.

We are currently using the FHIR service under Azure Health Data Services, but this service does not plan to support R5 and will instead go directly to the R6 version (see Azure API for FHIR - R4B and R5? · microsoft/fhir-server). We need to use R5 and are therefore looking at alternatives, one of which is to self-host the FHIR server utilizing FHIR Server for Azure.

I have some questions that would be helpful in making a decision:

1. What is the recommended migration approach for transitioning from Azure Health Data Services to a self-hosted environment FHIR server?
2. What are the ongoing maintenance and support implications of self-hosting versus using the managed service?
3. What additional security measures need to be implemented for self-hosted FHIR servers?

Thanks for any information provided.

[evachen96]

Hi @NC-olemal , thanks for your question! Yes, we don't support R5, and plan to go directly to R6 in the managed service.

Addressing some of the questions:

1. For transitioning from Azure Health Data Services to a self-hosted OSS FHIR server, you would need to set up a new OSS FHIR server and migrate your data from your current server to the new server. You can use the export and import capabilities of the FHIR server to move the data.
   2 and 3. Going to OSS would mean that you are under MIT license and you control the infrastructure, and support won't be provided for OSS as what we provide with managed service.

We have learned that most of the R5 features are backported to R4. We'd love to understand what the driving factor is for needing R5? Thanks!

[NC-olemal]

Hi,

Thanks for the fast answer! I will quote a previous answer from a teammate from 2023 (#3091 (reply in thread)). These points are still valid for R4, this has mostly been fixed in R4B, but this version is not supported by the managed service as far as I can see.

Related to compatibility with IDMP, the main issue is probably related to the reuse of ManufacturedItem-resources. In R4 the Amount is found on ManufacturedItem itself instead of PackagedItem.Package.ContainedItem, which is introduced in R5. This means, that you cannot "put" the same manufactured item (e.g., a pill containing 500 mg Paracetamol) in a box containing 20 pills and a container with 100 pills even though it is the exact same pill in the two packages.

In addition, we have identified the following differences between R4 and R5:

• NutritionProduct: Missing entirely in R4
• PackagedProductDefinition (R4: MedicinalProductPackaged): ContainedItem is missing in R4.
• ManufacturedItemDefinition (R4: MedicinalProductManufactured): See above related to mandatory MedicinalProductManufactured.Quantity.
• AdministrableProductDefinition (R4: MedicinalProductPharmaceutical): Missing ProducedFrom in R4, which can be helpful for e.g., Combination Packages.
• SubstanceDefinition (R4: SubstanceSpecification): R4 only allows for 1 identifier and is missing classification.

It is possible to circumvent the points above through extensions and basic profiles, but it leads to a funky and somewhat non-descript API for the hospitals who will be using our data set, which is not ideal.

[NC-olemal]

It is correct that R4B is not supported? @evachen96

[evachen96]

Hi @NC-olemal - R4B is supported in OSS, but not in the managed server.