A couple of weeks ago I wrote about the upcoming changes in FHIR R6 and how any future migration from R4 to R6 will require a lot of work, discussion and alignment with your data providers and consumers.
It sparked a number of comments and interest on LinkedIn. You can read that post here.
To illustrate the changes, let’s take a look at the ServiceRequest resource – one of the more commonly used resource types in FHIR.
Changes to ServiceRequest in R6
1. Status changes
The “revoked” and “completed” codes were removed from the status element and an additional “ended” code was added.
I’ve worked on projects where the “revoked” code was used to indicate a cancelled order. These projects would need to be changed to accommodate the status removals in R6. A possibly solution would be to use the new “ended” code and to populate the new statusReason element to identify it as a cancelled order.
Once the changes were made, consuming applications would need to be notified and prepared to handle the changes. A synchronized body of work that would be challenging to manage.
2. Intent changes
Similar to status, a number or codes were removed from intent with no new codes added and no corresponding “intentReason” element available to assist with the change. While I’ve never had cause to use the removed codes from ServiceRequest.intent or seen them used in a real world project, if you relied on these codes in your application their absence would be difficult to work around. It doesn’t help that the terminology binding for intent is required, making the use of custom codes impossible.
3. OrderDetail structural changes
Of all the changes to ServiceRequest this one most clearly illustrates the improvements coming in R6. What was once a list of CodeableConcepts has been changed to a larger BackBone element that contains a CodeableReference alongside a list of key / value parameter pairs. It’s far more comprehensive and allows for richer data to be captured.
In terms of impact and application code changes, these would be significant but superficial. The location of elements would change but not the content.
4. AsNeeded expanded into two elements
This is another improvement that would require application changes. The ServiceRequest.asNeeded element in R4 can store one of two data types (boolean or CodeableConcept). In R6 these two data types have been separated out into two elements allowing both values to be stored for the same resource. Conversion would be a straight forward mapping based on the data type.
5. PatientInstruction structural changes
This element was converted from a simple string into a list of multi-type elements that can contain markdown or references. I’ve never had cause to use the ServiceRequest.patientInstruction element but this enhancement would be manageable by converting existing strings into markdown data types.
6. Location & Reason changes
LocationCode and ReasonCode have been removed and the corresponding reference elements renamed to “location” and “reason” as CodeableReference data types. This makes use of the new CodeableReference introduced in R5 that combines a CodeableConcept with a Reference. It’s a cleaner implementation and removes the need for two elements in a number of places.
In all cases where CodeableReferences have been introduced application changes would be required to manage the new data type. Individually these would be trivial changes but there will likely be a lot of them in a lot of different resource types.
Conclusion
I use ServiceRequest as an example. Most resource types have similar changes to a greater or lesser degree. The message here is that migrating to R6 – when or if the time comes – will be challenging. It won’t be enough to make code changes inside your own applications, you’ll also have to work to bring along your data providers and data consumers.
I don’t see this working without running two APIs (R4 and R6) at the same time, allowing for external applications to update over time. Which of course raises a big question mark if you’re reliant on commercial or managed FHIR server providers.
Will they be able to run two API versions simultaneously?
Is that even on their radar?
Here are the full list of changes in R6: https://build.fhir.org/diff.html
As a counter to my post (and potential scaremongering), you should also read Mark Scrimshire’s response here.
---