FHIR Chat · Slices and relative indexes · shorthand

Stream: shorthand

Topic: Slices and relative indexes


view this post on Zulip David Pyke (Dec 14 2021 at 17:02):

In the latest sushi, if I have two entries (e.g., us-core-practitioner identifiers) and one is a slice and the second uses relative indexing, the indexed on overwrites the slice named one.
e.g.,

* identifier[NPI].value = "9941339108"
* identifier[+].system = "http://www.acme.org/practitioners"
* identifier[=].value = "25456"

view this post on Zulip David Pyke (Dec 14 2021 at 17:02):

will show only the second identifier

view this post on Zulip David Pyke (Dec 14 2021 at 17:02):

if I use normal indexing, then both show up.

view this post on Zulip David Pyke (Dec 14 2021 at 17:03):

Is that intentional?

view this post on Zulip John Moehrke (Dec 14 2021 at 17:03):

I hope not

view this post on Zulip David Pyke (Dec 14 2021 at 17:04):

I think someone else will be carving the roast fish at the Who Feast

view this post on Zulip Chris Moesel (Dec 14 2021 at 18:21):

I think this is how it has always worked, but you said "in the latest SUSHI" -- so I just want to be sure: was this working differently in a prior version of SUSHI?

Currently, when SUSHI sees a [+] without any prior [+] or specific index (e.g., [1]), it assumes [0]. It doesn't take prior slice instances into account. I'm not saying this is how it should work, but I think this is how it does work right now.

The spec says this:

In soft indexing, [+] is used to increment the last referenced index by 1, and [=] is used to reference the same index that was last referenced. When an array is empty, [+] refers to the first element ([0]). FSH also allows for soft and numerical indices to be mixed.

In your case, there technically isn't any "last referenced index", and the array is not empty, so... there is some room for interpretation (which is probably not great). I think we've recently discussed the idea that if [+] is used w/ no prior [+] or [n], it appends to the end of the array. That would probably help here. Or we could say that [+] increments after the last referenced index _or slice_. We'd need to think about the implications of each approach.

For now, you would need to explicitly set the first index after the slice and then you could use [+] after that:

* identifier[NPI].value = "9941339108"
* identifier[1].system = "http://www.acme.org/practitioners"
* identifier[=].value = "25456"
* identifier[+].system = "http://www.foo.org/practitioners"
* identifier[=].value = "36567"

view this post on Zulip David Pyke (Dec 14 2021 at 18:36):

It would be good if the slices were counted as part of the indexing order and then we can use it the way that seems to make sense to me. But at least now I know that it's failing successfully now.

view this post on Zulip David Pyke (Dec 14 2021 at 19:00):

Alternately, an error message telling me that there's no first index and sushi is wiping out my slice entry would be good.

view this post on Zulip John Moehrke (Dec 14 2021 at 22:11):

im with Dave. Either these slice instances are an implied [+]; or there should be an error.

view this post on Zulip John Moehrke (Dec 14 2021 at 22:12):

I do recall this working that way at some point, but I don't recall it working that way a few months ago.

view this post on Zulip Chris Moesel (Dec 14 2021 at 22:16):

Yeah, I think that being aware of (and compensating for) previous slices makes sense. We'll just have to see how hard that is to implement!

view this post on Zulip Chris Moesel (Dec 14 2021 at 22:25):

SUSHI#983


Last updated: Apr 12 2022 at 19:14 UTC