Stream: shorthand
Topic: Caret Rules Overwrite Array Elements
Joe Paquette (Jul 09 2021 at 20:00):
I want to add some extensions into a profile's StructureDefinition.extension array. The parent is a FHIR resource (AllergyIntolerance) that has multiple extensions, a couple of which are not automatically filtered out by Sushi. I didn't realize this until I discovered improper extensions in the generated StructureDefinition. See https://fshschool.org/FSHOnline/#/share/2TM3CMb.
I didn't see anything in the FSH Language Reference, but is there a syntax that would allow the addition of array elements rather than direct assignment by array index resulting in invalid overwrites?
My work-around is to figure out the number of extension elements existing from the parent and then set the initial array index to 1+ that. I was hoping to not have to do that.
Chris Moesel (Jul 09 2021 at 20:53):
Hey @Joe Paquette! There are a few tricky things at play here...
One tricky bit is that some extensions from a parent should be propagated to the child and others should not. Unfortunately, there is not a programatic way of doing it right now, so SUSHI just has some special case code that looks for extensions that should not be inherited. This basic issue is being tracked here: https://jira.hl7.org/browse/FHIR-27535. All this to say, it's difficult as an author to even know how many extensions will get propagated to the child (in order to know the right indices of each).
So... authors ought not be overwriting existing extensions on the SD -- but it's difficult to figure out how not to do that. Of course, if it was valid to overwrite extensions then we run into the issue that SUSHI does not provide a way to "clear" an element value completed, so you end up "merging" values into existing extensions instead of overwriting them. That's not good either.
I can think of a couple of potential approaches to the problem. One very specific solution would be to special-case ^extension so it always appends to the existing array instead of starting at 0. Another, more general, solution would be to introduce a syntax that indicates that an item should be appended to the end of the list. For example ^extension[/] or ^extension[>], etc. We could also potentially redefine [+] so that if it is the first occurrence of an indexer on that path, it appends to the end of the array (instead of always meaning 0 on its first use).
Thoughts?
Chris Moesel (Jul 09 2021 at 21:07):
@Joe Paquette -- Oh! I forgot about this lifehack!
* ^extension[https://fhir.example.com/dp/StructureDefinition/dp-api].valueCode = #external-api
* ^extension[https://fhir.example.com/dp/StructureDefinition/dp-api-supported-profile].valueUrl = "http://hl7.org/fhir/us/core/StructureDefinition/us-core-allergyintolerance"
* ^extension[https://fhir.example.com/dp/StructureDefinition/dp-api-interaction].valueCode = #READ
* ^extension[https://fhir.example.com/dp/StructureDefinition/dp-api-interaction][+].valueCode = #SEARCH
In an Instance (or in caret rules), if you do extension[{url|id|name}] and SUSHI can resolve that extension, then it will append the extension to the end of the extension array (properly setting the extension URL). For multiples of the same extension, add an indexer after.
See: https://fshschool.org/FSHOnline/#/share/36o4QQp
Joe Paquette (Jul 12 2021 at 12:26):
Thanks @Chris Moesel ! Works perfectly! I was hoping there was some "secret sauce" that would solve this! After seeing your "lifehack", I went back into the language reference and found it at http://build.fhir.org/ig/HL7/fhir-shorthand/reference.html#extension-paths. Not sure how I missed it (guess it was too close to the weekend... :beer: ).
As for your idea ( ^extension[/] or ^extension[>]), this would be a good feature enhancement for any array assignments. I am also using the StructureDefinition.keyword for some specific use cases, and keyword is an array. While I have not seen it used in any StructureDefinitions we are dealing with, you never know. I'll add a feature request in the Sushi project.
Joe Paquette (Jul 12 2021 at 12:58):
I added https://github.com/FHIR/sushi/issues/875 for the above feature request.
Martin Höcker (Jul 12 2021 at 22:40):
We could also potentially redefine [+] so that if it is the first occurrence of an indexer on that path, it appends to the end of the array (instead of always meaning 0 on its first use).
Ahhh! Thank you pointing this out, @Chris Moesel I had ran into almost the exact same issue as @Joe Paquette (placing Extensions into StructureDefinitions). I erroneously thought that [+] would always append to an Array.
Personally, I would be in favor of redefining [+] to always mean "append" (also on first use). It would feel less surprising to me than the current implementation, but of course, it's a matter of opinion. I would not be in favor of another symbol to mean "append only". Instead, if [+] is redefined, then authors who want to refer to the 1st element have to explicitly state so using [0], which seems more readable to me.
Mark Kramer (Jul 13 2021 at 14:43):
I agree, @Martin Höcker . [+] should mean "next element" which would always mean "append"
Chris Moesel (Jul 13 2021 at 15:05):
I think we need to be careful about defining it though. There is a difference between [+] always meaning append and [+] meaning append if no previous indexer was specified. E.g., in an array of length 5, if you use array[2] and then array[+], then the plus is either 3 or 5 depending on if + is _always_ append or if it is "next element" (and next element is append when no previous element was specified).
Last updated: Apr 12 2022 at 19:14 UTC
