Stream: inferno
Topic: No Encounter references found from the prior searches
Matthew Dugal (Sep 01 2020 at 21:33):
I am having an issue with Encounter Tests not finding encounter references in resources. This is in the program edition online version. The reported message is "No Encounter references found from the prior searches".
I know that at least two types of resources have encounters - conditions and medicationrequest.
{
"resource": {
"resourceType": "Condition", [...]
}, [...]
"encounter": {
"reference": "Encounter/200007-Encounter-10001"
}
}
}
and
{
"resource": {
"resourceType": "MedicationRequest", [...]
}, [...]
"encounter": {
"reference": "Encounter/200007-Encounter-10001"
},
},
Any advice on what the issue might be or how to debug this?
Yunwei Wang (Sep 01 2020 at 23:42):
@Matthew Dugal This github issue explained how Encounter reference works: https://github.com/onc-healthit/inferno-program/issues/153
Matthew Dugal (Sep 02 2020 at 13:44):
This is helpful. Thank you!
Robert Scanlon (Sep 02 2020 at 14:02):
I believe that mixing US Core Encounter references and base FHIR Encounter references in US Core like this was unintentional and is fixed in the upcoming US Core Errata release. But in the meantime you should add at least one Encounter reference in a spot that expects US Core Encounters (as described in the above ticket).
Matthew Dugal (Sep 02 2020 at 18:46):
I added encounter to the DocumentReference.context (as mentioned in the github issue) and still no luck getting my encounters recognized.
{
"resource": {
"resourceType": "DocumentReference", [...]
}, [...]
"context": {
"encounter": [ {
"reference": "Encounter/200007-Encounter-10001"
}
],
[...]
Any ideas?
Robert Scanlon (Sep 02 2020 at 19:04):
Strange! In our test data it appears that a reference in DocumentReference.context.encounter is a reference that is used in the Encounter tests later. Did you 'Rerun All Tests'? Or just the skipped ones?
Matthew Dugal (Sep 02 2020 at 19:10):
It's a new test altogether navigating to the home page and starting over. We do have at least one document reference test not passing. Maybe it's using that particular one?
Matthew Dugal (Sep 02 2020 at 19:12):
Do you know if it is all test cases or just specific ones?
Matthew Dugal (Sep 02 2020 at 23:29):
Ok. DocumentReference test _definitely_ sees my encounter. I see it requesting the encounter resource in test #14 "USCDR-14: Every reference within DocumentReference resources can be read."
But Encounter Tests still shows "No Encounter references found from the prior searches".
Is github the best place to report an issue?
Robert Scanlon (Sep 03 2020 at 00:32):
Right, if it attempts to resolve that resource within USCDR-14, then we know that it has been sent to Inferno and it should be saved for additional checks later. It's a long shot, but you just confirm that reference isn't mistakenly in some other spot (other than context.encounter). If that isn't the case, then a github issue would be great and we can track it there. Thanks!
John Moehrke (Sep 03 2020 at 11:44):
is this test a basic existence test? Or is it hampered by security token that has been scoped to only DocumentReference and thus not the Encounter?
Robert Scanlon (Sep 03 2020 at 13:11):
A precondition of this test is a bearer token with sufficient scope to read any references that are provided, and the test should fail if the server returns anything other than OK and content that we expect. This issue is something separate though and has to do with whether or not a client can expect a reference to conform to a US Core Profile, or just the base FHIR specification. For non-USCDI, US Core resource references (e.g. Encounter), the way we structured the tests is to collect all US Core Encounter references in the USCDI US Core tests (which are always run first) and provide those references as an input to a dedicated US Core Encounter test which then performs a read and validates them against the US Core Encounter profile. For some reason that collection appears to not be working as intended in this case, so the US Core Encounter test isn't receiving any references to read and validate as an input.
John Moehrke (Sep 03 2020 at 13:16):
well, Postel's Law would be a good thing to follow, it is considered the key to the success of the Internet and core Internet protocols... so one should never expect to get well behaved data. This does not mean you can process it as well as well behaved data, but it does mean that you must try hard to process it successfully and when it is so badly formatted, fail gracefully. Thus the test tools should always go to the edge of the conformance and beyond.
Robert Scanlon (Sep 03 2020 at 13:21):
What do you mean by 'to the edge of the conformance and beyond'?
John Moehrke (Sep 03 2020 at 13:32):
See Postel's Law -- https://en.wikipedia.org/wiki/Robustness_principle
Robert Scanlon (Sep 03 2020 at 13:34):
We've applied this to our test design in that we often will fail earlier steps if we receive bad data, but try really hard to move on and execute later tests if possible instead of just stopping the tests (that's harder than you'd think). But you will still fail overall until the system has demonstrated it is capable of sending 100% valid (and complete by our definition) data. Whether or not this happens when deployed, and using real data, is out of scope of our testing.
Matthew Dugal (Sep 03 2020 at 23:05):
Robert Scanlon said:
For some reason that collection appears to not be working as intended in this case, so the US Core Encounter test isn't receiving any references to read and validate as an input.
Any guesses? Or suggestion on how to debug?
Stephen MacVicar (Sep 04 2020 at 14:03):
If you're using the version at inferno.healthit.gov, I can take a look next week if you send me a link to a failing run.
Matthew Dugal (Sep 09 2020 at 14:23):
Stephen MacVicar
Thank you for the offer. I did get pivoted to a new task but I am hearing from the team that encounters are populating and passing. So either something you or the team did resolved this issue. Thank you and everyone for your help!
Fred Harmon (Sep 25 2020 at 14:36):
I'm having this same issue when running inferno locally. I see it for both Practitioner and Encounter. In my example, I have a Condition that in a previous search or read returns references to both a Practitioner and an Encounter. When I run either of those tests that expect to use previously found references it tells me that it can't find any from previous searches.
Does anyone know if this is still an issue or if there was a resolution?
Robert Scanlon (Sep 25 2020 at 15:28):
Not yet, though we were able to reproduce the issue at the Connectathon. I'll take a look.
Robert Scanlon (Sep 25 2020 at 17:53):
We found the problem and identified a fix, we'll have it in there for the next release. There was a bug that occurred for non-USCDI US Core references, if they were located within an array in the resource, that caused us to not save them for the later tests. US Core DocumentReference.context.encounter is constrained down to 0..1, from 0..* in the base spec, which obscured the bug.
Fred Harmon (Sep 25 2020 at 18:34):
Awesome. I'll watch for the next release and try it out. Thanks @Robert Scanlon .
Robert Scanlon (Oct 15 2020 at 16:33):
@Fred Harmon -- our most recent release should fix this issue. Could you give it a try when you have a chance?
Last updated: Apr 12 2022 at 19:14 UTC
