Stream: conformance
Topic: Profiling CodeableConcept
Richard Kavanagh (Mar 18 2016 at 13:10):
We are using Forge to profile a CodeableConcept - we don't want the "coding" part just the text part. When we exclude the coding part in Forge (e.g. Binding Strength, Description, Value Set Reference etc) it looks like Forge puts them back in again - inheriting the values from the base resource. Is this intended, how would we remove them in our profile. It would seem overkill to have to go down the route of creating a datatype profile to do this,
Michel Rutten (Mar 18 2016 at 13:33):
Hi Richard, I am not completely clear how to reproduce the issue. Could you please outline the steps you've taken?
Michel Rutten (Mar 18 2016 at 13:34):
I've created a profile on CodeableConcept and constrained Code to max=0, this seems to work fine.
Grahame Grieve (Mar 18 2016 at 18:15):
Richard, I think this is a methodological problem with binding. We've had it in the core, and there's a task to do something about it, but i'm not sure where that is
Michel Rutten (Mar 18 2016 at 18:31):
I remember an earlier discussion about this topic. In Forge, clearing a property will suppress the node in the differential component. According to the current specification, the resource then implicitly inherits the associated value from the base resource. So you cannot express that you want to override an existing value in the base profile with an empty value in the derived profile. This is a limitation of the current implementation. Technically it is possible to emit an empty node, but if I recall correctly, the FHIR specification disallows this. Also I'd have to think hard about how to expose this option on every (!) element and property without cluttering the UI.
Grahame Grieve (Mar 18 2016 at 18:35):
yes you can't do this in any valid way right now
Michel Rutten (Mar 18 2016 at 18:45):
Touching on this, lately I've thought about how to properly deal with properties and child elements of elements that have been constrained with max = 0. Forge currently keeps all existing (custom) constraints and emits them to the serialized XML, even if the element or any ascending element has been removed by constraining the max cardinality to 0. It is possible to change the implementation and automatically clear all constraints on a removed element and below, however with this approach the user could (accidently) delete a lot of constraints that may exist on a complex element. So after some discussion, in light of data safety, we've decided to maintain the current approach and require the user to explicitly clear any (custom) constraints.
[EDIT] This way, any constraints on a removed element or below will also show up when rendering the StructureDefinition resource, e.g. on http://simplifier.net or using the build tool.
Last updated: Apr 12 2022 at 19:14 UTC
