Stream: implementers
Topic: Constraints
Richard Kavanagh (Jun 08 2016 at 06:31):
When using the ElementDefintion.Condition within an element within a StructureDefinition. Does the ID of the condition need to reference a constraint defined on the same element, or can it use an id defined elsewhere within the same StructureDefinition
Grahame Grieve (Jun 08 2016 at 08:11):
the idea is that it's defined elsewhere. It's an advisory - hey, look at this constraint. You would generally expect to look at the constraints on the element itself
Richard Kavanagh (Jun 08 2016 at 16:54):
OK so the fact that Forge only allows you to enter a constraint that is defined on that element may not be ideal then.
Michel Rutten (Jun 09 2016 at 07:43):
In Forge, the Conditions.Id property is bound to a drop-down list of constraint ID's that are in scope, i.e. from constraints defined on the current element and/or on any of the ascending elements, up to the root element. I thought this was the correct implementation, but if not (?), then I'm open for suggestions on how to improve this.
Lloyd McKenzie (Jun 09 2016 at 13:06):
@Michel Rutten I think that behavior is correct
Michel Rutten (Jun 10 2016 at 08:42):
@Lloyd McKenzie thank you for the clarification!
Katie Wheatley (Jun 14 2016 at 14:21):
In Observation.component.referenceRange, the FHIR DSTU2 resource does not give child elements of low, high, meaning, age, text as is given in Observation.referenceRange for the master test. How would a referenceRange low and high value be shown in a FHIR profile for a component test? Can anyone give me a link to a profile example where this is shown, if it is possible please?
Michel Rutten (Jun 14 2016 at 14:49):
@Katie Wheatley The ElementDefinition of Observation.component.referenceRange includes a nameReference to "referenceRange". This expresses that the Observation.component.referenceRange element contains the same child elements as the Observation.referenceRange element. For example, an Observation
resource can contain a SimpleQuantity value for Observation.component.referenceRange.low and an Observation profile can express constraints on that element.
Note that Forge does not support name references yet, i.e. the implied child elements are not expanded. This still needs to be implemented (note to self).
Michel Rutten (Jun 14 2016 at 14:52):
Also see for example Questionnaire.group.question.group, which is recursively defined via a name reference to Questionnaire.group.
Katie Wheatley (Jun 14 2016 at 14:56):
Thanks for letting me know that, Michel. Do you have a timescale for the addition of the child elements to the component reference range element in Forge?
Michel Rutten (Jun 14 2016 at 15:26):
@Katie Wheatley Coincidentally, this topic came up during a recent team discussion, so we are definitely aware that the application needs improvement in this area. The possible recursive nature of some name references make this a bit of a challenge to implement. I need to spend some more time thinking about UI design and application logic.
Katie Wheatley (Jun 14 2016 at 15:29):
Thanks for your feedback. It is something needed in Forge.
Michel Rutten (Jun 14 2016 at 15:29):
Currently I'm focusing on some other areas that desperately need improvement, but I'll try and implement this as soon as I have time.
Michel Rutten (Jun 14 2016 at 15:31):
Thank you for your feedback! We try to adapt our roadmap based on customer demand, so it's always very useful to know what limitations users are struggling with the most.
Grahame Grieve (Jun 14 2016 at 23:11):
@Michel Rutten : "possible recursive nature of some name references " - can you clarify?
Michel Rutten (Jun 15 2016 at 07:40):
@Grahame Grieve I was referring to e.g. the Questionnaire.group component that recursively contains another group.
Michel Rutten (Jun 15 2016 at 07:40):
If Forge would expand these elements in a naive way, then the application would hang forever...
Grahame Grieve (Jun 15 2016 at 07:51):
ah ok thanks
Last updated: Apr 12 2022 at 19:14 UTC
