Stream: argonaut
Topic: Extensions & Profiles
Richard Kavanagh (Aug 30 2019 at 11:41):
As a non-US person I am curious to understand how extensions are used in Argonaut/US Core. Are organisations permitted to further extend the profiles to meet any "local" needs? If so, then clearly they would need a new profile to introduce the extensions, does that happen in the US?
Michele Mottini (Aug 30 2019 at 13:05):
We added a bunch of extensions to our implementation to render data we have and that does not map to existing FHIR elements or standard extensions - not much anyone can do to stop us! And no - you definitely do not need a profile to do that
Lloyd McKenzie (Aug 30 2019 at 13:14):
The requirement when using extensions is that the extension definitions must be available to all systems you send the instance to and that the definition must either be discoverable or they must have awareness of where to find it. The simplest way to do that is to put your extension definition in a registry and make the registry location the canonical URL of the extension. However, you can also host it yourself (and use your location as a canonical URL) or find some other way to ensure anyone who sees the instance can find out what the extension means.
Lloyd McKenzie (Aug 30 2019 at 13:15):
Technically, defining the extension is, itself, creating a profile. You do not need to define a profile that references the extension though unless you're wanting to: a) validate that instances contain/are using the extension appropriately (e.g. in the right place); b) wanting to set expectations for conformance within a community the profile targets.
Richard Kavanagh (Aug 30 2019 at 13:28):
So if you had took US-Core-Patient and added an extension is it still fair to say it is US-Core-Patient? As such and other profiles that reference US-Core-Patient are those references still valid.
To be clear, I'm not challenging US Core just trying to understand so similar rules can be considered elsewhere.
Lloyd McKenzie (Aug 30 2019 at 13:31):
If the instance is valid against US-Core-Patient, then you're conformant against that profile. It's fine to send 200 extra extensions (and even modifier extensions). The only time you can't send extensions or modifier extensions is if the profile has explicitly constrained them out - which is generally a bad practice for interoperability profiles to do. (It is legitimate for system profiles to constrain out modifiers if they're going to treat the presence of modifiers as an error. If they do that, then they just want you to suppress the records where modifiers exist.)
Richard Kavanagh (Aug 30 2019 at 13:34):
Thanks @Lloyd McKenzie that answers my question. I assumed that all extensions had to be explicitly stated in a resource profile, but if that's not the case then it makes perfect sense.
Lloyd McKenzie (Aug 30 2019 at 13:40):
In the base resource, extensions are supported pretty much anywhere. When you profile, what you're really doing is calling out constraints on, setting expectations around the use of, and/or creating awareness of specific extensions. However, you only limit the inclusion of extensions if you "close" the slicing of extension or set a max cardinality of the extension element. Both of those things are really bad practice for extension, but can be justified for modifier extension if you really need to shut down modifiers in a particular space.
Lloyd McKenzie (Aug 30 2019 at 13:41):
Just be aware that modifiers are a safety valve and that it's better for systems to expose modifiers than it is for them to pretend they're regular extensions. If you constrain out modifiers make it clear that you don't want the instances at all.
Richard Kavanagh (Aug 30 2019 at 14:57):
@Lloyd McKenzie thanks for the clarification
Last updated: Apr 12 2022 at 19:14 UTC
