Stream: shorthand
Topic: Reference Keyword
Nick Freiter (Jun 03 2020 at 14:50):
Hey all, we are trying to make a decision about the syntax of FSH going forward, and we are hoping to get some feedback.
In FSH, the Reference keyword is used in situations where we are handling
elements of type Reference. As an example, on an Observation profile we may constrain subject as:
* subject only Reference(Patient | Group)
this is different from a non-reference type constraint such as:
* value[x] only Quantity or CodeableConcept
We have had requests to unite these two syntaxes, and eliminate the Reference keyword, so that the first example would be expressed as:
* subject only Patient or Group
The Reference keyword is not strictly necessary since SUSHI can infer it is a reference by looking at subject's type.
We're seeking feedback on this. Should FHIR Shorthand:
- Require the
Referencekeyword, which makes the FSH more verbose, but also explicitly expresses the intent; or - Remove the
Referencekeyword, which makes the FSH more succinct, but obscures the fact that it is a reference.
Note that this discussion also pertains to canonical types and a potential Canonical keyword.
Jose Costa Teixeira (Jun 03 2020 at 15:17):
So using option 1:
Extension: ...
* value[x] only CodeableConcept or Reference
* valueReference only Reference(BeNlPatient | BeFr-Patient | BeNlOrganization | BeFrOrganization)
and 2:
Extension: ...
* value[x] only CodeableConcept or Reference
* valueReference only BeNlPatient or BeFrPatient or BeNlOrganization or BeFrOrganization
?
Chris Moesel (Jun 03 2020 at 15:36):
Yes, I think that covers the basic idea well. Good example.
Chris Moesel (Jun 03 2020 at 15:38):
Note also that an even shorter variant would be allowed (combining the two lines into one):
Option 1:
Extension: ...
* value[x] only CodeableConcept or Reference(BeNlPatient | BeFr-Patient | BeNlOrganization | BeFrOrganization)
Option 2:
Extension: ...
* value[x] only CodeableConcept or BeNlPatient or BeFrPatient or BeNlOrganization or BeFrOrganization
Jean Duteau (Jun 03 2020 at 15:44):
Is there a problem with Bundle.entry (and potentially other cases) where it is an actual type that is specified?
Jose Costa Teixeira (Jun 03 2020 at 15:51):
(i updated my example to have 2 sibling profiles, not parent-child - I assume that is supported but it's off topic anyway).
Chris Moesel (Jun 03 2020 at 15:52):
@Jean Duteau - I don't think so... Bundle.entry.resource and contained (both of which use inline resources instead of references) would still be done the same way as now (without a Reference keyword). The only place where there could be ambiguity is if you had a choice that allowed Reference and inlined resources (like Patient, not data types) at the same time. But I don't think that ever happens.
Jose Costa Teixeira (Jun 03 2020 at 15:53):
Option 2:
```
Extension: ...
* value[x] only CodeableConcept or BePatient or BeOrganization
```
this makes me feel that option 1 is clearer. (And I would prefer "or" instead of pipes)?
Chris Moesel (Jun 03 2020 at 15:56):
@Jose Costa Teixeira -- I updated my replies to match your updated example. And yes, option 1 is clearer at the expense of being more verbose (and requiring the author to explicitly state things that can be implied). That's the tradeoff! Within option 1, we could have the option to switch | to or... we have a ballot comment on that.
Jose Costa Teixeira (Jun 03 2020 at 15:58):
Not for being verbose but for being explicit, I'd vote for option 1
Richard Kavanagh (Jun 03 2020 at 16:29):
+1 for Option #1
Mark Kramer (Jun 03 2020 at 17:22):
@Richard Kavanagh @Jose Costa Teixeira Note that Option #1 mixes "or" and "|", both meaning "or". Is that confusing? (We got multiple votes asking us to choose one or the other)
Jean Duteau (Jun 03 2020 at 17:37):
I think I agree with Option #1 - it is more explicit that these are references than types. Although I can tell that BePatient is a profile and probably a profile on Patient, if the name of the profile wasn't that explicit, it would be hard to know whether this is a profile on a datatype or a profile on a Object, i.e. a Reference.
Chris Moesel (Jun 03 2020 at 18:05):
I think @Jose Costa Teixeira already expressed a preference for switching | to or:
And I would prefer "or" instead of pipes
Richard Kavanagh (Jun 03 2020 at 19:32):
It's the brackets in Option #1 that swings it for me. The use of "or" and "|" does not bother me, though I can understand the desirevfor consistency
Keith Boone (Jun 06 2020 at 16:24):
I can live with either, but would honestly prefer option 2. My rational is that Reference is noise, and SUSHI fails to adequately report the error when you say * field only Xyz instead of * field only Reference(Xyz). So, if we go with option 1, please clean up the error reporting when somebody forgets to use Reference() appropriately. It will at least make it easier for someone to fix the problem.
Eric Haas (Jun 06 2020 at 18:51):
option 2
Gino Canessa (Jun 06 2020 at 19:12):
For my (one? relatively late to the party on this :-) cent, I'd vote option 1.
- I think it's important to be explicit in the actual data type being used
- I worry about overloading the resource types (e.g., sometimes Patient means Patient, sometimes it means Reference(Patient))
- Right now you can imply it's a reference, but there may be additional possibilities in the future
Last updated: Apr 12 2022 at 19:14 UTC
