Stream: implementers
Topic: Reverse Chaining Question (Plan-Net)
Saul Kravitz (Nov 25 2020 at 20:52):
There are three profiles: Network (a profile of Organization), OrganizatonAffiliation, and Location.
Network
^
| 0..*
|
OrganizationAffiliation (role = pharmacy)
| 0..*
|
v
Location (type=pharmacy, address.postCode=20854)
id = N
I'm trying to construct a search for all pharmacy locations that are part of network N in zipcode 20854 using reverse chaining.
The challenge: The query uses two reverse chaining (_has) relationships:
1) OrganizationAffiliation:location:network = N. The Organization affiliation that refers to Location using its location search parameter refers to Network N.
2) OrganizationAffiliation:location:role = pharmacy. The OrganizationAffiliation that refers to location has its role = pharmacy.
My read of the terse documentation on reverse chaining is that the two _has relationships are independent.
So, it is possible that there could be two OrganizationAffiliation instances, one with role=pharmacy and network=M (not N), and one with role=provider and network=N, and the location would be included.
Two questions:
1) is that understanding correct?
2) Is there any way to place two requirements on a single OrganizationAffiliation instance in one query using reverse chaining?
Michele Mottini (Nov 25 2020 at 21:13):
I doubt many (any?) servers will implement reverse chaining, maybe you are better off doing multiple searches
Saul Kravitz (Nov 25 2020 at 21:50):
@Michele Mottini it is required by Plan-Net, and supported by the servers that have attended the connectathons (HAPI, IBM, etc). Your point is well taken, but I'd like to have a correct recommendation for implementers built into our RI, and currently I'm not sure that is the case.
Paul Church (Nov 25 2020 at 21:57):
That understanding is correct, you can't do this in one query. At best you can do OrganizationAffiliation?network=N&role=pharmacy to get the intermediate list of IDs, and then Location?_has:OrganizationAffiliation:location:_id=[intermediate list of IDs]
Michele Mottini (Nov 25 2020 at 22:14):
I stand corrected!
Saul Kravitz (Nov 30 2020 at 16:03):
@Grahame Grieve -- the inability to do this type of join will result in a much less efficient implementation of this query. By inefficient, I mean the client code will be much more complicated, AND significantly more data will be requested from the server.
Is this a bug or a feature of the FHIR API?
Lloyd McKenzie (Nov 30 2020 at 18:40):
It's a feature. The more complexity we add to RESTful search, the less likely implementers are to support it. I believe _filter could work for your use-case, but it's not widely implemented
Saul Kravitz (Nov 30 2020 at 20:21):
@Lloyd McKenzie -- so you are suggesting that the _filter include all of the constraints on the OrganizationAffiliation, thus ensuring they are all satisfied on a single instance? thx
Lloyd McKenzie (Nov 30 2020 at 20:27):
Filter gives you the power of brackets. You can also have sub-filters on particular nodes. I'm not an expert with the syntax though. (And I'm not sure if @Grahame Grieve's reference implementation of _filter has full _reverseInclude support.)
Grahame Grieve (Dec 02 2020 at 03:41):
_filter generally hasn't been implemented on the grounds that it's needless complexity and load on the server. The counter argument that it's lack is more of a load on the server hasn't really sunk in yet.
At least HAPI now supports it. But in your context, will your users support it?
Saul Kravitz (Dec 02 2020 at 22:58):
Agreed that _filter is a hail-mary pass.
I'm not even sure that it CAN work for this query. For example, is this well-formed?
https://davinci-plan-net-ri.logicahealth.org/fhir/Location?_has:OrganizationAffiliation:location:_filter=(network re Organization/plannet-network-HPID010000 and role=pharmacy)
HAPI is not happy with this. "Unknown parameter name: OrganizationAffiliation:_filter""
Michele Mottini (Dec 02 2020 at 23:01):
I don't think that's the way _filter works, it is ../Location?_filter=( complex expression )
Lloyd McKenzie (Dec 02 2020 at 23:57):
I think you'd have to do this: OrganizationAffiliation?_filter=(role=pharmacy and location[type=pharmacy and address.postalCode=20854])&_include=OrganizationAffiliation.organization
Saul Kravitz (Dec 04 2020 at 19:55):
First of all, thanks for continuing the discussion.
Two issues:
1) the location[fielda eq valueb and fieldb eq valueb] makes HAPI sad. But that type of syntax to apply the location constraints to a single location would be necessary to avoid the same problem stated above.
2) you've flipped the search to be on OrgAffiliation, and including locations, but this would be casting a much wider net than applying the filter on Locations that satisfy the geographic constraint AND the OrganizationAffiliation (network, type, specialty) constraint. Many of the returned locations wouldn't meet the geographic constraint.
I think it is more efficient to perform the original query:
https://davinci-plan-net-ri.logicahealth.org/fhir/Location?_has:OrganizationAffiliation:location:network=Organization/plannet-network-HPID010000&_has:OrganizationAffiliation:location:role=pharmacy&_revinclude=OrganizationAffiliation:location&address-postalcode:contains=06040,06074,06043,06118,06041
And then do some client side filtering of the locations to eliminate those locations for whom an appropriate OrganizationAffilation that satisfies the network and type constraint can't be found.
René Spronk (Dec 05 2020 at 13:15):
_(rev)include doesn't allow for any conditions .. (address-postal:contains..). Only _has supports such a feature.
Last updated: Apr 12 2022 at 19:14 UTC
