FHIR Chat · Expressing nested paths · shorthand

Stream: shorthand

Topic: Expressing nested paths

Mark Kramer (Mar 23 2020 at 14:35):

An issue came up in the context of populating Questionnaire and Questionnaire responses. These resources involve deeply nested paths and arrays. The current FSH syntax is (admittedly) awkward in cases like this, and gives rise to expressions like this: * item[3].item[0].item[2].text = "Oral hygiene - functional ability during assessment period". In the current grammar, the entire path has to be included in each rule. It's very index-heavy. So, we're exploring better ways to express this, perhaps escaping into YAML, perhaps something like YAML but with FSH-like values, or creating extensions to FSH grammar.
The FSH-SUSHI team would appreciate feedback. Here's the discussion so far: https://github.com/FHIR/sushi/issues/291.

Mark Kramer (Mar 24 2020 at 15:16):

Here's one possible approach. It depends on having leading white space having meaning:
Old way:

Instance: BetsySmithMDSResponse
InstanceOf: PACIOquestionaireResponse
* subject.reference  = "Betsy Smith"
* status = #completed
* item.text =  "Section GG: Functional Abilities and Goals"
* item.linkId = "Section-37"
* item.item.text =  "Self-Care. Code the {patient's/resident's} usual performance at {admission} for each activity using the 6-point scale. If activity was not attempted at {admission}, code the reason. Code the {patient's/resident's} {discharge} goal(s) using the 6 point scale. Use of codes 07, 09, 10, or 88 is permissible to code {discharge} goal(s)."
* item.item.linkId = "Section-37/GG0130"
* item[0].item[0].item[0].text = "Oral hygiene - functional ability during 3D assessment period [CMS Assessment]"
* item[0].item[0].item[0].linkId = "Section-37/GG0130B1"
* item[0].item[0].item[0].answer.valueReference = Reference(BetsySmithMDSOralHygiene)
* item[0].item[0].item[1].text = "Eating - functional ability during 3D assessment period [CMS Assessment]"
* item[0].item[0].item[1].linkId = "Section-37/GG0130A1"
* item[0].item[0].item[1].answer.valueReference = Reference(BetsySmithMDSEating)

Proposal:

Instance: BetsySmithMDSResponse
InstanceOf: PACIOquestionaireResponse
* subject.reference  = "Betsy Smith"
* status = #completed
* item:
    text =  "Section GG: Functional Abilities and Goals"
    linkId = "Section-37"
    item:
        text =  "Self-Care. Code the {patient's/resident's} usual performance at {admission} for each activity using the 6-point scale. If activity was not attempted at {admission}, code the reason. Code the {patient's/resident's} {discharge} goal(s) using the 6 point scale. Use of codes 07, 09, 10, or 88 is permissible to code {discharge} goal(s)."
        linkId = "Section-37/GG0130"
        item:
            text = "Oral hygiene - functional ability during 3D assessment period [CMS Assessment]"
            linkId = "Section-37/GG0130B1"
            answer.valueReference = Reference(BetsySmithMDSOralHygiene)
        item:
            text = "Eating - functional ability during 3D assessment period [CMS Assessment]"
            linkId = "Section-37/GG0130A1"
            answer.valueReference = Reference(BetsySmithMDSEating)

Chris Moesel (Mar 24 2020 at 15:55):

I'd have to look at this some more, but off-hand I feel like parsing would be easier if we at least maintained the * on each line. It's a good hint to the parser that we're on a new rule. Otherwise we're probably giving up some of the other features of FSH that allow authors to format things as they wish (taking advantage of insignificant whitespace).

Vassil Peytchev (Mar 24 2020 at 16:21):

In general, I think, either have white space always being significant (Python), or never have it being significant.

Mark Kramer (Mar 24 2020 at 17:19):

To make white space insignificant, there has to be a mechanism for grouping. If curly brackets are used, it would be something like this:

Instance: BetsySmithMDSResponse
InstanceOf: PACIOquestionaireResponse
* subject.reference  = "Betsy Smith"
* status = #completed
* item {
    * text =  "Section GG: Functional Abilities and Goals"
    * linkId = "Section-37"
    * item {
        * text =  "Self-Care. Code the {patient's/resident's} usual performance at {admission} for each activity using the 6-point scale. If activity was not attempted at {admission}, code the reason. Code the {patient's/resident's} {discharge} goal(s) using the 6 point scale. Use of codes 07, 09, 10, or 88 is permissible to code {discharge} goal(s)."
        * linkId = "Section-37/GG0130"
        * item {
            * text = "Oral hygiene - functional ability during 3D assessment period [CMS Assessment]"
            * linkId = "Section-37/GG0130B1"
            * answer.valueReference = Reference(BetsySmithMDSOralHygiene)
        }
        * item {
            * text = "Eating - functional ability during 3D assessment period [CMS Assessment]"
            * linkId = "Section-37/GG0130A1"
            * answer.valueReference = Reference(BetsySmithMDSEating)
        }
    }
}

This is indented for readability, but the indentation is not meaningful.
PS - I added the * back in for @Chris Moesel

Jose Costa Teixeira (Mar 24 2020 at 17:23):

1. could we benefit from aliases here?

Jose Costa Teixeira (Mar 24 2020 at 17:23):

2. personally I prefer an indented syntax

Chris Moesel (Mar 24 2020 at 17:31):

Ha. I was about to say "Personally, I prefer the syntax with some kind of delimeters (e.g., { } or some other symbol(s)) if you're going to nest." So, I guess it's pretty subjective.

Jose Costa Teixeira (Mar 24 2020 at 17:32):

yes, i 'm Pascal / Python flavour, with a twist of YAML, so obviously it's a preference

Chris Moesel (Mar 24 2020 at 17:32):

I'm not sure exactly what you are proposing w/ aiases @Jose Costa Teixeira, but on the GitHub issue I floated an example of how this would be done using "inline" references: https://github.com/FHIR/sushi/issues/291#issuecomment-602604604

Jose Costa Teixeira (Mar 24 2020 at 17:32):

what about aliases? if we are going to repeat * item[0].item[0].item[0] many times, we may call it something

Jose Costa Teixeira (Mar 24 2020 at 17:33):

à la yaml ;)

John Moehrke (Mar 24 2020 at 17:46):

as you do that.. you head away from one of the nice parts of shorthand, that being more git friendly. And you head into the complexity of json/xm that you are saving us from. If we head that direction, then it seems we should just stick with StructureDefinition

Jose Costa Teixeira (Mar 24 2020 at 17:47):

that gives me an idea.
Could we embed a fhirpath inside shorthand? for these edge cases (without changing the syntax)

Chris Moesel (Mar 24 2020 at 18:09):

@John Moehrke -- when we first looked at using YAML (back in December), we came to a similar conclusion at the time: it didn't seem to be different enough from the status quo to justify the investment. I guess now we're trying to see what we've learned since then and if there is a more intelligent approach that could keep the strengths of FSH while mitigating some of the weaknesses (mainly being verbosity and repetition in this case).

Chris Moesel (Mar 24 2020 at 18:09):

But I think it's wise for you to remind us to keep the original goals of FSH in mind. So thank you!

Last updated: Apr 12 2022 at 19:14 UTC