FHIR Chat · Bug: No element found at path · shorthand

Stream: shorthand

Topic: Bug: No element found at path


view this post on Zulip Patrick Werner (Nov 11 2021 at 10:10):

We are currently having a weird issue. If we are using the german address profile: https://simplifier.net/basisprofil-de-r4/addressdebasis in profile which slices address we are getting some: No element found at path address[Postfach].type for CardRule in ISiKPatient, skipping rule errors.

view this post on Zulip Patrick Werner (Nov 11 2021 at 10:11):

address part of profile:

* address contains
    Strassenanschrift 0..* MS and
    Postfach 0..* MS
* address[Strassenanschrift] only AddressDeBasis
  * ^patternAddress.type = #both
  * type 1.. MS
* address[Postfach] only AddressDeBasis
  * ^patternAddress.type = #postal
  * type 1.. M

view this post on Zulip Patrick Werner (Nov 11 2021 at 10:11):

if i switch the order of these slices the error goes away

view this post on Zulip Patrick Werner (Nov 11 2021 at 10:11):

there is no ordered slicing applied anywhere

view this post on Zulip Patrick Werner (Nov 11 2021 at 10:11):

I prepared a test project: https://github.com/patrick-werner/testDerivedAddress

view this post on Zulip Patrick Werner (Nov 11 2021 at 10:12):

Happy to create an issue for this, just wanted to check if this isn't a bug, or if you are already aware of this

view this post on Zulip Yannick Börner (Nov 11 2021 at 11:32):

+1 for looking into this, as it has been affecting me as well.

view this post on Zulip Chris Moesel (Nov 12 2021 at 15:54):

I'll take a look at this later today. I thought I could fit it in quickly before a meeting, but just realized that since it depends on a Simplifier IG, I'll need to populate the snapshots in my cache. I've been meaning to try out the new Firely terminal capability for doing this, so I'll give that a try when I have a chunk of time bigger than the seven minutes I currently have before my next meeting.

view this post on Zulip Chris Moesel (Nov 12 2021 at 21:52):

OK. I've been able to reproduce this. Very odd indeed. I'll debug into it to see if I can figure out what is going on. Thanks for reporting it!

view this post on Zulip Chris Moesel (Nov 12 2021 at 22:23):

@Patrick Werner -- This strange behavior is due to incorrect element ids in the address-de-basis definition that is pulled in from the de.basisprofil.r4 dependency. Here is a listing of all the ids and paths in the snapshot elements for address-de-basis:

 0    ID: Address                                  PATH: Address
 1    ID: Element.id                               PATH: Address.id
 2    ID:                                          PATH: Address.extension
 3    ID: Address.extension:Stadtteil              PATH: Address.extension
 4    ID: Address.use                              PATH: Address.use
 5    ID: Address.type                             PATH: Address.type
 6    ID: Address.text                             PATH: Address.text
 7    ID: Address.line                             PATH: Address.line
 8    ID: Element.id                               PATH: Address.line.id
 9    ID:                                          PATH: Address.line.extension
10    ID: Address.line.extension:Strasse           PATH: Address.line.extension
11    ID: Address.line.extension:Hausnummer        PATH: Address.line.extension
12    ID: Address.line.extension:Adresszusatz      PATH: Address.line.extension
13    ID: Address.line.extension:Postfach          PATH: Address.line.extension
14    ID: string.value                             PATH: Address.line.value
15    ID: Address.city                             PATH: Address.city
16    ID: Address.district                         PATH: Address.district
17    ID: Address.state                            PATH: Address.state
18    ID: Address.postalCode                       PATH: Address.postalCode
19    ID: Address.country                          PATH: Address.country
20    ID: Address.period                           PATH: Address.period
21    ID: Element.id                               PATH: Address.period.id
22    ID: Element.extension                        PATH: Address.period.extension
23    ID: Address.period.start                     PATH: Address.period.start
24    ID: Address.period.end                       PATH: Address.period.end

view this post on Zulip Chris Moesel (Nov 12 2021 at 22:29):

Note the problems at the following indices from the table above:

  • 1: id is Element.id but should be Address.id
  • 2: id is missing but should be Address.extension
  • 9: id is missing but should be Address.line.extension
  • 14: id is string.value but should be Address.line.value
  • 21: id is Element.id but should be Address.period.id
  • 22: id is Element.extension but should be Address.period.extension

If you look at address-de-basis's differential elements, they all have the correct ids -- so this seems to be a bug in the snapshot generation algorithm used by Firely terminal. I used fhir bake -p de.basisprofil.r4 to generate the snapshots into my FHIR cache.

view this post on Zulip Chris Moesel (Nov 12 2021 at 22:35):

SUSHI uses the ids from the Address profile definition to generate the nested address elements in your Patient profile. Since the address profile ids are wrong, so are the generated ids in the Patient profile -- which then causes issues w/ SUSHI's ability to find the elements again when it needs to.

The correct solution to this problem would require the address-de-basis snapshot element ids to be fixed. Once that's done, it should work well within SUSHI. While we could potentially fix the ids on import in SUSHI, I'm not sure that would be a fool-proof procedure, and honestly, it would just be covering up a problem that needs to be addressed anyway.

view this post on Zulip Patrick Werner (Nov 14 2021 at 12:55):

Thanks for the analysis @Chris Moesel

view this post on Zulip Patrick Werner (Nov 14 2021 at 13:05):

Yes bake in firely terminal isn't working correctly at the moment. Thats why i used a snapshotted package downloaded from simplifier (which doesn't include missing ids as far as i checked)

view this post on Zulip Patrick Werner (Nov 14 2021 at 13:09):

i pushed the snapshotted package to the repo as well: https://github.com/patrick-werner/testDerivedAddress/blob/master/de.basisprofil.r4-1.1.0.tgz

view this post on Zulip Chris Moesel (Nov 15 2021 at 16:24):

@Patrick Werner -- are you still getting those errors with the corrected (downloaded) package? Or did using the package w/ correct snapshots fix the issue for you?

view this post on Zulip Patrick Werner (Nov 15 2021 at 17:18):

i actually never used bake, but went with the spapshotted package from Simplifier (i also added this to the repo)

view this post on Zulip Patrick Werner (Nov 15 2021 at 17:18):

And i am getting theses errors on a snapshotted package with correct ids

view this post on Zulip Chris Moesel (Nov 15 2021 at 18:21):

OK, thanks. Then I'll take a look at this again.

view this post on Zulip Chris Moesel (Nov 16 2021 at 19:21):

@Patrick Werner -- I've found the bug and logged it here. I have a local fix that appears to be working, but I need to run it through regression before submitting a PR for it.

view this post on Zulip Ewout Kramer (Nov 17 2021 at 09:42):

The correct solution to this problem would require the address-de-basis snapshot element ids to be fixed. Once that's done, it should work well within SUSHI.

I am trying to figure out which snapshot generator has created the ones on address-de-basis. If that's SImplifier, I expect bake to do exactly the same thing. If they differ, that would be really interesting. As far as I know the id-generation algo hasn't been changed the last 18 monts at least, but we'll take a look.

view this post on Zulip Patrick Werner (Nov 17 2021 at 10:13):

Hi @Ewout Kramer , snapshots WITH ids were coming from Simplifier, the one with missing IDs comes from fhir bake.

view this post on Zulip Patrick Werner (Nov 17 2021 at 10:13):

Both using different versions of the .net API (already confirmed the issue with @Alexander Zautke and @Yannick Börner )

view this post on Zulip Patrick Werner (Nov 17 2021 at 10:14):

Chris Moesel said:

Patrick Werner -- I've found the bug and logged it here. I have a local fix that appears to be working, but I need to run it through regression before submitting a PR for it.

Thank you!
Would it be easier for you if i directly create issues?

view this post on Zulip Ewout Kramer (Nov 17 2021 at 10:50):

HI Patrick, thanks - not necessary for this one anymore as Alex and Yannick are on it, and you caught my attention now too ;-)

view this post on Zulip Chris Moesel (Nov 17 2021 at 14:02):

@Patrick Werner -- when we release SUSHI updates, we like to point to GitHub issues that it resolves. So we will typically create issues for anything reported on Zulip (if it is a real bug). If you create the issue yourself, that does help a little -- but honestly, it's not hard for us to do it either. So no big deal either way.

view this post on Zulip Alexander Zautke (Nov 17 2021 at 14:52):

We found the issue in Firely Terminal. Will be fixed in the next release, most likely this week.

view this post on Zulip Martijn Harthoorn (Dec 02 2021 at 09:00):

It has been posted on other channels, but a fix has been released for this issue (beta) for Firely Terminal
https://www.nuget.org/packages/Firely.Terminal/2.5.0-beta-2

view this post on Zulip Patrick Werner (Dec 02 2021 at 11:00):

Was the issue with the location of the .fhir folder also fixed?

view this post on Zulip Alexander Zautke (Dec 02 2021 at 11:03):

Fixed in latest beta release (2.5.0-beta-2)


Last updated: Apr 12 2022 at 19:14 UTC