Stream: shorthand
Topic: Bug: No element found at path
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.
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
Patrick Werner (Nov 11 2021 at 10:11):
if i switch the order of these slices the error goes away
Patrick Werner (Nov 11 2021 at 10:11):
there is no ordered slicing applied anywhere
Patrick Werner (Nov 11 2021 at 10:11):
I prepared a test project: https://github.com/patrick-werner/testDerivedAddress
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
Yannick Börner (Nov 11 2021 at 11:32):
+1 for looking into this, as it has been affecting me as well.
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.
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!
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
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 beAddress.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 beAddress.line.value
- 21: id is
Element.id
but should beAddress.period.id
- 22: id is
Element.extension
but should beAddress.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.
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.
Patrick Werner (Nov 14 2021 at 12:55):
Thanks for the analysis @Chris Moesel
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)
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
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?
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)
Patrick Werner (Nov 15 2021 at 17:18):
And i am getting theses errors on a snapshotted package with correct ids
Chris Moesel (Nov 15 2021 at 18:21):
OK, thanks. Then I'll take a look at this again.
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.
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.
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.
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 )
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?
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 ;-)
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.
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.
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
Patrick Werner (Dec 02 2021 at 11:00):
Was the issue with the location of the .fhir folder also fixed?
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