Stream: hapi
Topic: Unusual SearchNarrowingInterceptor behavior.
James Fadeley (Oct 04 2020 at 21:30):
So I'm tracking what maybe a bug inside of SearchNarrowingInterceptor. Correct me if I'm wrong or have overlooked something.
As behavior goes, a call to a @Search endpoint hits SearchNarrowingInterceptor before the AuthorizationInterceptor. There, an AuthorizedList is assembled of compartments. Like...
for (IdType patientId : patientIds) {
cascadingList.addCompartment(patientId.getValue());
}
This appends a fresh parameter onto the request, like http://X/fhir/ExplanationOfBenefit would suddenly become http://X/fhir/ExplanationOfBenefit?patient=Patient/998,Patient/999, just as the documentation says.
Thereafter, the thread visits AuthorizationInterceptor. There I couldn't get...
.allow().read().resourcesOfType(ExplanationOfBenefits.class).inCompartment("Patient", patientIds);
...to work. Basically, the request was stopped before the search was executed. Based on input from @Jens Villadsen, I've set up my own IAuthRuleTester.matchesOutput() to use a custom IAuthRuleTester to verify post-search compartmental values of the outgoing resources.
.allow().read().resourcesOfType(ExplanationOfBenefit.class).withAnyId().withTester(myTester);
That approach works great but this struck me as weird, and I did further digging. All along, I've been sending multiple compartmental parameters as a list, either in my manual request or from what the SearchNarrowingInterceptor provides, ie patient=Patient/998,Patient/999. When I tried the approach with just a single value, it works just fine using the ".inCompartment" approach. So it seems something about giving a list of compartment values to SearchNarrowingInterceptor doesn't get past the ".inCompartment" rule?
P.S., the Provider endpoint is setup to accept multiple values for the compartmental value:
@Search
public Bundle searchExplanationOfBenefitBySearchParameters(
@OptionalParam(name=ExplanationOfBenefit.SP_PATIENT) StringAndListParam patientParam,
James Fadeley (Oct 05 2020 at 17:35):
After some discussion and reading with colleagues, it maybe a situation where HAPI can return multiple patients but that's against FHIR specifications?
Jens Villadsen (Oct 05 2020 at 17:48):
Nop - that is entirely legal
Jens Villadsen (Oct 06 2020 at 12:17):
@James Fadeley I would suspect that you should build up the chain with allow() .... inCompartment("Patient", patientId).andThen() for each patientID in the list
Jens Villadsen (Oct 06 2020 at 12:17):
There's nothing in the spec that stops you from returning multiple patients AFAIK
René Spronk (Oct 06 2020 at 13:19):
There's nothing against that from a pure FHIR perspective. You may wish to apply some access control rules to filter the result set, but what filters to apply, and when to apply them, depends on a specific context.
James Fadeley (Oct 06 2020 at 13:45):
Jens Villadsen said:
James Fadeley I would suspect that you should build up the chain with allow() .... inCompartment("Patient", patientId).andThen() for each patientID in the list
Hmmm. I was trying to use the collection method with
Collection <IdType> patientIds = new ArrayList<IdType>();
...and then spooling through, adding each IdType and giving that to the inCompartment chain. It didn't seem to allow the search through when I thought it should. I could try individuals, but shouldn't the Collection approach work?
James Fadeley (Oct 06 2020 at 14:04):
I ask because the length of the IdTypes list will vary. So either adding a collection or looping through the list is what I'll need.
Jens Villadsen (Oct 06 2020 at 14:25):
hmmm ... had forgotten that inCompartnent can take a list - so both approaches should be valid
Jens Villadsen (Oct 06 2020 at 14:26):
maybe @James Agnew can weigh in on this
James Fadeley (Oct 26 2020 at 21:01):
Any updates on this?
James Fadeley (Oct 26 2020 at 21:26):
To explain a TL;DR, I think the Search Narrowing providing a list of Patient ids, (id patient=Patient/100,Patient/101) is getting stopped by InCompartment in Authorization Interceptor because it thinks there's no match.
James Fadeley (Jan 11 2021 at 19:00):
Ummm, any news? Luck?
Victor Saad (Aug 26 2021 at 04:25):
I have implemented the SearchNarrowingInterceptor, AuthorizationInterceptor & ConsentInterceptor in my project as per the limited documentation available.
In the SearchNarrowingInterceptor, I am creating an AuthorizedList with one compartment for the patient that is sending the request to limit his access to records related to his patient Id only. So when I search for any other patient ID he gets an access denied message.
In the scenario when I am logged in as Patient 0987654321 and try to search for a Patient 1234567890 using the below URL:
http://baseurl/Patient?_id=1234567890
the SearchNarrowingInterceptor in the background is adding both patient IDs to the values Array of the _id param and since this is not acceptable I am getting the below error message
HTTP 400 Bad Request
Response Body
{
"resourceType": "OperationOutcome",
"issue": [ {
"severity": "error",
"code": "processing",
"diagnostics": "Multiple values detected for non-repeatable parameter '_id'. This server is not configured to allow multiple (AND/OR) values for this param."
} ]
}
How can I restrict the _id values to the one in the search request only, or is this a bug?
Last updated: Apr 12 2022 at 19:14 UTC
