by Martijn Harthoorn
In the Simplifier team we think a lot about Profiles. We try to think of the places where they will be used and how they will be used. I will share with you one recent discussion we had about versioning of profiles.
The discussion started after a comment in the FHIR community from Lloyd McKenzie of the FHIR core team that a lot of profiles have references to other profiles (profiled references), that when updated, cause cascading updates. Let’s explore this. Assume we are working with a profile on Patient for our Hospital X. Let’s give the first published version of this profile the following canonical URI:
http://hospitalx/Patient-V1 (and lets abbreviate it to P1)
Now let’s assume we also have DiagnosticReports in our hospital, so we create a profile for those, and we give it this canonical URI:
http://hospitalx/DiagnosticReport-V1. (abbreviating it to D1)
As you might know a DiagnosticReport references a Patient. It’s not unlikely to assume here that we want our DiagnosticReports to only refer to Patient resources from our own hospital. For that FHIR allows you to profile the reference to Patient: a constrained reference. In your profile you tell that whatever patient your diagnostic report is about, that patient has be conformant to a Patient profile with the given canonical URI. In our case, the profile on DiagnosticReport (D1) will have a reference to Patient constrained to only allow P1.
This might seem a logical thing to do, but it turns out that it can be quite a burden on the authors of these profiles. If you publish a new version of your Patient profile (let’s call it P2), your existing diagnostic report profiles (D1) won’t allow referencing it because they have the reference definition constrained to only accept references to patients profiled on P1.
If you would update the DiagnosticReport profile, references to Patients of the P1 profile are not allowed either.
In some situations, this can cascade to an update of 50 profiles with a breaking change.
To be more precise: the problem that profile authors face is that they have to update the canonical URI in all profiles with a constrained reference. It also means that they want to be able to republish their profiles at once as a batch. You don’t want to have your other profiles reference an older version.
For these two steps, changing the references and republishing, it is possible to build tooling that can do most of the work automatically. We’re working hard on getting such capability within Simplifier for you.
But our discussion brought two other interesting versioning challenges to light.
The first challenge concerns authoring and deployment collaboration. Let’s say that the central administration of our hospital X upgrades their patient profile. But the lab creates their own DiagnosticReport profiles, and these DiagnosticReport profiles (of course) constrain the reference to Patient to only allow patients from within the hospital. Again D1 references P1. Now after the upgrade of the central administration for Patient from P1 to P2, the lab won’t be able to accept new P2 patients that are sent from within their own hospital, unless they upgraded their servers at the exact same time. This might be a good thing, because a breaking change is a breaking change for a reason. Note here that a breaking change is the only reason to change your canonical URI. But our presumption is that in a lot of cases, the profiled reference is not a matter of exact conformity. The lab doesn’t care about the all the exact fields of the patient. The only reason why the Patient reference was profiled, was to be sure they would not send or receive Patient data from outside the hospital. For example: they possibly only cared that the Patients they receive all have an identity given out by the central administration. For this likely scenario, a canonical URL change creates a huge unnecessary burden that might trigger a very expensive cascade of downstream updates in profiles.
There are solutions here. For example: the hospital could start of with a profile “Patient Zero” (P0) that only has the hospital identity field. Then, have the ‘real’ profiles (P1 and P2) be derived profiles from “Patient zero”. This is not very obvious and of course requires a forward thinking profile author that had the smarts to take this step as his first action of business. It won’t be easy fix afterwards.
The second challenge that surfaced in our discussion is about our own tool Simplifier.net and possibly any FHIR registry. Once you have published one of your profiles in Simplifier, you have assigned it a unique canonical URI, you marked it as [Active] and by that you made a promise to your profile consumers that you won’t introduce any breaking changes for that profile. But of course at some point you are going to have to change something. Whether or not you are introducing a small update or a breaking change, you would like to continue working with that same profile. In the case of your Simplifier project, you don’t want to lose your version history, issue tracking and activity log. However you also don’t want to change the status of your published resource from “active” back to “draft”. Currently, you will have to create a new resource and work from there. That’s something we realized we have to change as creators of the tool.
For now our plan for the future is to allow creating draft versions of a resource even after it’s been published, instead of making you create a new resource. This will also require registering a canonical URI for each published version of your resource instead of how it is now: just once, which is automatically the latest version.
Your feedback here is appreciated as always. There is a feedback button on the top of the page in Simplifier.net. Our support team always reads it and responds to it.
Happy new year and happy profiling to everyone.