FHIR version R4 to R4B

[reubenelder]

Hi,

We are using the OSS version on FHIR version 4 (sql server). However we are wanting to upgrade to R4B. I understand that there is no way to upgrade to R5 (which is completely understandable with the resource changes etc.) however I was wondering if there is way of upgrading an existing R4 database to R4B. I've experimented a little and, although my initial attempts failed due to the new search parameters being created without statuses, if I run a full initialization again they are populated correctly and the server runs.

I am wondering if this will lead to further trouble down the track. Is this supported in any way? Has anyone achieved this?

Thanks for any advice

AB#104402

[PTaladay]

How were you going about creating the new search parameters? I want to make sure we aren't missing an upgrade path here. Are these search parameters ones that were previously unsupported in R4, but are now in R4B?

[reubenelder]

Thanks for your reply. When switching to R4B the startup automatically adds the search parameters for the new R4B resources (such as ClinicalUseDefinitions). However the search parameter insert doesn't add a status or other details and this causes a SearchParameterNotSupportedException exception to throw in the SqlServerSearchParameterStatusDataStore.GetSearchParameterStatuses.
I reproduced this locally by starting a R4 instance and let it create the database and then using the same database on R4B. However if in the SqlServerFhirModel.Initialize method I force the InitializeSearchParameterStatuses to run, startup completes successfully (in this instance I did it by modifying the code).

[EXPEkesheth]

Thanks @reubenelder for reporting the issue. Have added this bug in backlog to evaluate the work needed. Given FHIR R5 version is released, once we start looking into R5 adoption, we will be considering removing R4B support from OSS.

[PTaladay]

Thanks @reubenelder. There was a change made to only run the flat file load for search parameters if the database has no search parameters and it will create the statuses at that time. In your case, since the database is already created it won't run that initialization from the flat file. Definitely a bug, as this would happen moving from one schema to another that has new search parameters that did not exist before.

[reubenelder]

thanks @PTaladay - really appreciate that. Is there anyway I can track progress on this?

@EXPEkesheth I'm very concerned to hear that R4B might be removed from OSS. I know with our project we will need to support R4/R4B for quite a long time and many in our region will not be switching to R5 anytime soon (for our country my understanding is most govt orgs will stay on R4/R4B). How and when would this decision be made?

[PTaladay]

@reubenelder. I spoke with @EXPEkesheth on this to explain this is a higher priority bug than how it first appears since this would apply to any schema change where there are newly supported search parameters. Considering I have made the most recent changes in that area I will likely get assigned the bug. Once I see where it gets assigned within our iteration wise I will update here and include the bug #.

Regarding any deprecation of R4B, we would still keep it within OSS as we have active customers using STU3. I believe what Ketki meant was that with the fact that R5 is released, any bugs related to R4B specifically would be of lower priority, unless the bug is agnostic to the schema being used. Considering this bug is not R4B specific, I would not be concerned about it.

[reubenelder]

thanks @PTaladay for the clarification - good to hear R4B isn't going anywhere. And thanks for logging and sorting that bug. Much appreciated.

[reubenelder]

Hi @PTaladay , any update on timing for this fix? thanks, Reuben

[PTaladay]

Hi @reubenelder, I need to double check. I had been getting distracted with our managed pipeline deployments. I thought I got this done, but I will check locally to see if it still repros.

[PTaladay]

@reubenelder , I'm in the process of fixing the issue. The bug number for this is 106114. I can repro the issue and believe I have it narrowed down, just trying to figure out the best way to fix it.