Stream: shorthand
Topic: fixed[x] vs pattern[x]
Chris Moesel (Mar 04 2020 at 14:23):
Currently, FSH supports only one symbol for "fixing" values: =. SUSHI determines whether to use fixed[x] or pattern[x] based on the type that is being fixed. In short, complex types use pattern[x] and simple types use fixed[x]. For example (within a Patient profile):
* active = true // uses fixedCode since active is a simple type * maritalStatus = V3MARITALSTATUS#M // uses patternCodeableConcept since maritalStatus is a complex type
We assume that perhaps authors may want more control over whether fixed[x] or pattern[x] is used. Should FSH consider using different symbols to specify the author's intent? If so, consider this proposal:
=indicates to usepattern[x]:=indicates to usefixed[x]
We chose to keep = for pattern[x] as it is the most backward compatible for common use cases -- and is often the preferred choice. Even for simple types, many people prefer pattern since it allows for extensions (whereas fixed[x] does not).
This means that the way the previous example is output to StructureDefinition would change. Now it would be:
* active = true // uses patternCode since = was used * maritalStatus = V3MARITALSTATUS#M // uses patternCodeableConcept since = was used
To get the same behavior as SUSHI does today, you would need to do:
* active := true // uses fixedCode since := was used * maritalStatus = V3MARITALSTATUS#M // uses patternCodeableConcept since = was used
Thoughts?
Grahame Grieve (Mar 04 2020 at 19:22):
We assume that perhaps authors may want more control over whether fixed[x] or pattern[x] is used.
yes definitely
Chris Moesel (Mar 05 2020 at 20:16):
Well, no one has said they hate the idea or the syntax, so... for now, we'll plan on the approach above.
Keith Boone (Mar 05 2020 at 22:54):
+1
Chris Moesel (Mar 11 2020 at 14:48):
After kicking this around some more, we decided that = vs := was a little too nuanced (in the syntax) -- and didn't carry over well to instance rules (since pattern doesn't really make sense there). Instead, we're going to go with an (exactly) qualifier to indicate when something should use fixed[x] rather than pattern[x]. E.g.:
* active = true (exactly) // use fixedBoolean * maritalStatus = V3MARITALSTATUS#M (exactly) // use fixedCodeableConcept
This follows a syntax similar to how binding strengths are defined.
David Hay (Mar 11 2020 at 19:40):
instead of (exactly) how about (fixed) ?
Chris Moesel (Mar 11 2020 at 20:14):
@David Hay -- we considered that, but so far we have used the term "fixed" a bit more loosely than the strict FHIR definition of fixed[x]. E.g., we talk about "fixing" a code, but we really mean by applying a pattern[x] to it. If we use keyword (fixed) we might need to come up w/ another way of talking about the general situation of specifying a value that must match. Perhaps we should do that anyway -- I don't know. I think we were also thinking that while fixed might mean something very specific to the StructureDefinition experts, exactly might capture the intended meaning better for non-SD-experts authoring or reviewing FSH definitions.
Chris Moesel (Mar 11 2020 at 20:15):
But we're certainly open to more discussion about it -- and if we go to ballot w/ (exactly) you can of course submit a comment to make sure it gets discussed!
Last updated: Apr 12 2022 at 19:14 UTC
