Stream: implementers
Topic: Candidate breaking change - make canonical a complex type
Lloyd McKenzie (Apr 23 2018 at 20:53):
On the FHIR-I call today, we agreed to take GF#15879 here for discussion. The proposal is to make the "canonical" data type complex so that in addition to a URL, it's possible to have a 'display'. The use-case is that lots of resources point to protocols, questionnaires and other things that have canonical URLs. Resolution of the URL to find a name isn't always practical. In messaging/document environments, resolution might not be possible. In other environments, security policies might prohibit resolution. And in all cases, it's a performance imposition. This is NOT a small change tooling-wise. (Changing to use canonical in preparation for the ballot was already painful.) Doing this would mean that the infrastructure portion of FHIR would have to return to ballot in the Sept. cycle, though we had already planned for that as a possibility.
We would like to hear from a broader set of implementers: Do you have a need for "display" when dealing with references to protocols, questionnaires, value sets, profiles, templates, implementation guides, etc. or are you comfortable with needing to resolve the references in order to determine a name.
Peter Jordan (Apr 23 2018 at 21:20):
I'd support this change - I never understood why "canonical" was implemented as a simple data type in the first place.
Grahame Grieve (Apr 23 2018 at 22:11):
In the FHIR tooling, i resolve all canonicals on the fly. I'm sympathetic to the problem, but the change process is deeply problematic. Changing this stuff burns so many weeks of my time, and not just my time.
Grahame Grieve (Apr 23 2018 at 22:13):
it's pretty concerning that it's only coming up now. We've been using URL for a long time
Lloyd McKenzie (Apr 23 2018 at 23:07):
The problem manifests most strongly in those places that were previously Reference that were only recently updated. Most places that were only URLs were places where looking up was likely to happen all the time anyhow. But canonical is now (appropriately) appearing in places where you often don't want to resolve.
Lloyd McKenzie (Apr 23 2018 at 23:08):
I'm very sympathetic to the amount of work involved here. But we're about to lock this as normative, and I think if we don't fix this now, we're going to be kicking ourselves for a long time.
Elliot Silver (Apr 23 2018 at 23:24):
Can it be resolved by leaving canonical as is, and defining a standard extension for "canonical display name"?
Lloyd McKenzie (Apr 24 2018 at 00:54):
That's an option. However, it creates a challenge if we expect it to be present most of the time. If we had identified this as a change after normative, then we'd have no choice but to take that approach. This time we do have a choice. My main concern is that the implementers most likely to need display are the "simple" implementers - who are the ones least likely to see an extension.
Brian Postlethwaite (Apr 24 2018 at 02:59):
When updating the dotnet client to the latest R4 build I found that it was a pretty even mix of places where the uri was changed to a canonical, and also reference to canonical.
So painful either way, just a shame that we had all this pain to put the first one in without the other at the same time.
Lloyd McKenzie (Apr 24 2018 at 03:16):
The impact didn't become clear to me until updating IGs - which of course happened after the original change had been propagated :(
Last updated: Apr 12 2022 at 19:14 UTC
