Question around usage of hapi-fhir-jpaserver-searchparam to validate search criteria

Robert Savannah

unread,

Apr 5, 2021, 5:17:13 PM4/5/21

to HAPI FHIR

Good afternoon, all.

My team is looking into whether we can use the SearchParamMatcher out of the box to validate whether a given set of client subscription criteria matches a given FHIR resource. For example, we have a client that wishes to receive a change notification in the event that a new Appointment was created or an existing Appointment was updated for a specific location. In accordance with FHIR spec, the FHIR resource defines the `Location` type of the `participant.actor` array with the `system|value` identifier as opposed to populating the `reference` property (“Location/123456”). In following a few online sources, my understanding (perhaps misunderstanding) is that searching by `location:identifier=systemUri|value` is a valid, but I’m finding that FHIRPathEngine class explicitly looks for the `reference` property to be populated. Since it’s not in our case, the search params extracted from the given FHIR Appointment does not include the participant.actor location (nor patient, nor practitioner).

I have uploaded a sample to the HAPI FHIR “sandbox”. Using the token search `identifier`, the expected Appointment is returned. Using `location:identifier` returns an empty bundle.

We’re using the built-in search param definitions of the R4 matcher in version 5.1.0 of the hapi-fhir libs. Is there something else that I should be doing? Is the `location:identifier` not supported at this time?

My apologies for the lengthy post/questions and thank you very much for your time and help.

--Robert Savannah

James Agnew

unread,

Apr 5, 2021, 5:32:28 PM4/5/21

to Robert Savannah, HAPI FHIR

Theoretically the first query would be possible to execute that way - Unfortunately this isn't something we've documented though. You'd certainly have to make sure to supply it with all of the dependencies it needs. I'd recommend upgrading to the latest version of the library if you can, quite a few bugs have been fixed in this module over the last few releases.

The second query would not though- We don't currently support searching on Reference.identifier out of the box. Actually I suppose technically you could create your own custom SearchParameter that redefines the location SP but uses a path that includes the .identifier part of the reference. I think this would work, although I'm not 100% sure...

Sorry for the vague answer...

Cheers,

James

--
You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/448a21a8-2ce3-4432-99a0-12e26af087c5n%40googlegroups.com.

Robert Savannah

unread,

Apr 5, 2021, 6:32:59 PM4/5/21

to HAPI FHIR

Hi James.

Thank you for the quick reply and for the confirmation that searching by `location:identifier` is not currently supported out of the box.

From what I can tell, if we were to supply our own RuntimeSearchParam to support searching by `location:identifier`, that definition would need to be supplied by whatever we instantiate as the `ISearchParamProvider` to override any of the built-in SPs .. is my understanding correct? Is there any form of “search for all appointments for this location” that is supported out of the box aside from `”reference”: “Location/1234566”` and `location=1234566`?