FHIR Chat · Fixed Values in Logical Models · conformance

Stream: conformance

Topic: Fixed Values in Logical Models


view this post on Zulip Grahame Grieve (Jun 24 2021 at 19:49):

One of the outstanding issues for logical models is how to do fixed values for non-FHIR types. The challenge here is that ElementDefinition.fixed[x] (and ElementDefinition.pattern[x] ) are restricted to FHIR types (as they must be), so if you're defined a complex type, you can't define a fixed value for it.

This is actually a problem for if you want to define a fixed value or a pattern for a BackboneElement on a FHIR resource - so it's not really specific to logical models, it just comes up more often

view this post on Zulip Grahame Grieve (Jun 24 2021 at 19:50):

really, the only idea I have is to define a complex extension that can carry a value for a complex type, reusing the extension internally as necessary.

view this post on Zulip Grahame Grieve (Jun 24 2021 at 19:50):

seeking thoughts from others about this

view this post on Zulip Richard Townley-O'Neill (Jun 24 2021 at 23:53):

Timing is a type of BackboneElement. Does it have the same problem?

view this post on Zulip Ewout Kramer (Jun 25 2021 at 07:55):

Another way this problem surfaces is when trying to define R3 model using an R4 structure definition. Are the types in the [x] the types those from the definining or the defined model? As it is the first, you cannot give example[x] for the R3 types you are defining, since you need to express them in R4. In practice, not a big problem, I admit, but it's still there.

view this post on Zulip Grahame Grieve (Jun 25 2021 at 09:21):

r3 expressing R4 - a bigger problem

view this post on Zulip Ewout Kramer (Jun 25 2021 at 12:10):

yes

view this post on Zulip Chris Moesel (Jun 25 2021 at 20:40):

OK. I'll bite. But first I have a few questions.

As discussed in previous threads, FHIR prohibits fixed[x]/pattern[x] for specializations, so should we assume that this is for R5 and would be accompanied by a change to that table?

I had previously thought that another reason for not allowing fixed[x]/pattern[x] in specializations is that it would usually be pointless. It doesn't make much sense to define a new element and then fix its value since whatever it represents can just be implicit in the definition of what's being specialized (e.g., if there is no room for variation, why create an element for it?). The only use case where it really adds value is if a parent defines an element but then a child fixes its value. BUT... that's a contraint, and I've been told previously that specializations cannot constrain elements from their parent. Which means that the only meaningful use case I can think of is actually invalid. So... am I misunderstanding something here?

view this post on Zulip Grahame Grieve (Jun 25 2021 at 20:55):

possibly you are, because I have no idea why this is relevant. there can be constraints on logical models, and that's what we're taking about


Last updated: Apr 12 2022 at 19:14 UTC