Stream: conformance
Topic: Constraining extensions
Grahame Grieve (Jul 27 2017 at 07:25):
I have a profile where I've walked int a bunch of datatypes. i want to turn off extensions for them - how do I do that in Forge?
Michel Rutten (Jul 27 2017 at 07:51):
Hi @Grahame Grieve, you can't... :/ Currently, Forge generates the extension slice entry for you. But the slicing component is not visible in the UI and you cannot customize it. We're aware of the limitation, but haven't given this much priority as users haven't asked for it.
Grahame Grieve (Jul 27 2017 at 08:07):
.. but... how could they not?
Grahame Grieve (Jul 27 2017 at 08:07):
;-)
Michel Rutten (Jul 27 2017 at 08:13):
I remember Lloyd asking for this about a year ago, always trying to stretch the limits... ;p
Eventually I'd like Forge to support this, but it is currently not high on our TODO list.
As always, we may reconsider based on popular demand.
Michel Rutten (Jul 27 2017 at 08:22):
I assume you only need acccess to the extension slicing component and cardinality, as the remaining properties are not likely to be constrained? Design-wise, I've been thinking to integrate controls for these key extension properties into the UI of the parent element. So e.g. if you click on Patient.identifier, the element properties window would also provide access to the slicing and cardinality properties of the Patient.identifier.extension child element, e.g. tucked away at the bottom. This way, Forge could support advanced scenario's without cluttering the UI all too much. Do you think that would work?
Grahame Grieve (Jul 27 2017 at 08:38):
what I want to do is simply say 'no extensions here'
Grahame Grieve (Jul 27 2017 at 08:39):
it should be routine for everyone for implementation profiles - turning extensions off everywhere unless you specifically use them
Grahame Grieve (Jul 27 2017 at 08:39):
I think your design proposal is ok
Michel Rutten (Jul 27 2017 at 08:58):
Agreed, thank you for the feedback.
Because of this limitation in Forge, users can not follow best practices and close extension slices. Do you consider this a big problem for FHIR? If so, maybe we should reconsider priorities.
Grahame Grieve (Jul 27 2017 at 11:06):
well, I think it's an issue. take, for example, this:
Grahame Grieve (Jul 27 2017 at 11:08):
hmm. I'll have to do a bit of work before I can post what I wanted to get you to look at ....
Grahame Grieve (Jul 27 2017 at 11:25):
here: http://build.fhir.org/ig/grahamegrieve/medicalert/StructureDefinition-Member.html#template
Grahame Grieve (Jul 27 2017 at 11:25):
see all the extension elements all over the place - a big mess....
Michel Rutten (Jul 27 2017 at 11:31):
You're generating example resource templates from the profile? I can see the noisy extension elements. And these would disappear if the profile explicitly closes the extension slice?
Grahame Grieve (Jul 27 2017 at 11:31):
sets max = 0
Grahame Grieve (Jul 27 2017 at 11:31):
yes. (actually that wouldn't disappear right now, but I'm working on that)
Michel Rutten (Jul 27 2017 at 11:32):
OK get it
Michel Rutten (Jul 27 2017 at 11:33):
I'll discuss this with our team. I think this will have to wait until after september WGM, as we're now focusing on some UI improvements.
Grahame Grieve (Jul 27 2017 at 11:34):
ok thanks
Lloyd McKenzie (Jul 27 2017 at 15:48):
I think saying "no extensions here" is a poor design choice. It's much better to just say "these are the supported extensions". But prohibiting extensions you don't support creates unnecessary interoperability barriers. I agree there will be some cases where this is necessary, but it shouldn't be common - and definitely shouldn't be encouraged
Lloyd McKenzie (Jul 27 2017 at 15:49):
That's true for all elements - constraining elements to max=0 should be a last resort
Grahame Grieve (Jul 27 2017 at 20:33):
if i'm creating a profile that describes what my system gives you to read and I'm not using extensions - which is by for the more common in all circumstance - then that's exactly what the profile should so: you won't find extensions here
Lloyd McKenzie (Jul 28 2017 at 03:58):
I think that's a very complicated way of doing it. You'd have to declare non-support for extensions, modifier extensions, id and every other element on Element eveywhere. Super-verbose and super-annoying. Much cleaner - and just as expressive - to just have a profile that lists everything you do support and mark those as "must-support". Anything that's not marked as must-support is something you shouldn't expect to receive.
Grahame Grieve (Jul 28 2017 at 05:06):
it's a question of who it's verbose and annoying for
Lloyd McKenzie (Jul 28 2017 at 06:17):
I would expect it would be verbose for both author and consumer. It would tripple the size of most profiles to do that - exclude every element you don't support and every child element you don't support. I can't think of anyone it would be easier for unless you wanted a validator to always raise an error if a system omitted something other than what it said it supported. (You could still raise a warning if elements were present where mustSupport = false)
Grahame Grieve (Jul 28 2017 at 07:05):
well, we could enhance the validator to make warnings like that.
Lloyd McKenzie (Jul 28 2017 at 08:30):
I actually already have :) They're "hints" at the moment. They trigger if validation is happening against a profile that contains any mustSupport=true elements.
Eric Haas (Jul 29 2017 at 19:12):
I think I understand this stream - you are discussing is whether every element (including extensions ) should be explicitly defined as either "in" in Lloyds case or "out" in Grahame's. I assume when profiling that If I don't say anything about an element ( i.e., - an extension) it is 'undefined' and the profile user can choose to use these unspecified elements or not. So is neither in or out. Why would you put constraints on things you may not have gathered any requirements about and may never be able to get that information? Both way seem overly prescriptive and verbose to me.
Lloyd McKenzie (Jul 29 2017 at 19:16):
Marking "mustSupport=true" on the elements you support isn't terribly verbose.
Eric Haas (Jul 29 2017 at 20:02):
You are right, I got a little carried away.
Grahame Grieve (Jul 29 2017 at 21:21):
in my case, I am describing the data produced by a system. There's no uncertainty here; no, maybe it might be useful. I know exactly what is and isn't going to be produced, and I'm communicating that
Lloyd McKenzie (Jul 30 2017 at 03:37):
But the same information is conveyed by saying "this is what I support" (i.e. mustSupport = true). Setting cardinality on everything you don't support to 0 is way overkill. (And hard to do and super-verbose)
Chris Grenz (Aug 22 2017 at 22:33):
Late to the party, but thought I'd chime in. We've done the max:0 thing frequently as a matter of contract specificity. "We will never send extensions here, and the absence of extensions here should not be interpreted as null or no data". This allows us to a) provide guarantees to our clients and b) prevent potential security issues as our system may not send extensions in these areas (they are removed so the resource is conformant).
Travis Stenerson (Aug 24 2017 at 14:33):
Quick question. Does anyone have an example of a profile structure definition that has a complex extension with extensions that are constrained to a specific valueset? I'm trying to make the structure def and I'm getting Snapshot for http://...profile does not contain differential element with id: AllergyIntolerance.extension:allergyintolerance-substanceexposurerisk.extension.valueCodeableConcept
Thanks
Igor Sirkovich (Aug 24 2017 at 14:54):
Profile: http://hl7.org/fhir/us/core/StructureDefinition-us-core-patient.html
Extension: http://hl7.org/fhir/us/core/StructureDefinition-us-core-race.html
Travis Stenerson (Aug 24 2017 at 15:12):
Thanks Igor, but this isn't what I meant. In this case the extensions on the extensions are required bound to valuesets. I mean the situation where the parent profile is constraining the extension's child extension to a specific valueset. I hope I'm describing this properly.
Michel Rutten (Aug 25 2017 at 08:48):
Hi @Travis Stenerson, I've created an example profile that specifies a custom binding on a child element of a complex extension:
https://simplifier.net/share/MichelR/1
Travis Stenerson (Aug 25 2017 at 14:30):
@Michel Rutten Ah yes this is exactly what I was looking for Michel. Thank you.
Michel Rutten (Aug 25 2017 at 14:32):
No problem. This is quite advanced. Fortunately there's tooling available and you don't have to author such profiles manually... (btw I created the example in Forge)
Last updated: Apr 12 2022 at 19:14 UTC
