Stream: Da+Vinci+PDex+Plan-Net
Topic: Question on Provider Directory Location API
Saul Kravitz (Feb 03 2021 at 18:25):
Picking up conversation started https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Question.20on.20Provider.20Directory.20.20Location.20API.2E
Question from @Nagarjuna Sanivarapu :
@Mark Scrimshire , @Suma Addagadde
When Payer Implementing FHIR, sourcing data from two different vendors(as native FHIR API'S) for Provider and Pharmacy directory, what is the best way to determine and route the "Location" resource request to specific vendor when third party app doesn't pass "_has:OrganizationAffiliation:location:role=pharmacy or hosp" in the request. Can we enforce "has:OrganizationAffiliation:location:role" as required search parameter in our capability statement for third party app?
Saul Kravitz (Feb 03 2021 at 18:30):
Just clarifying your question. You have a Plan-Net endpoint that is simply a front-end for two vendor FHIR Endpoints, one for Pharmacy and one for non-pharmacy Providers. I think your question is if a query is received <plan-net-base>/Location/_id=<>. or <plan-net-base>/Location?<something>, how can you know which of the vendor endpoint should respond to the query. Did I get it right?
Your suggestion is to route Location queries that have an associated pharmacy (or hospital) Organization Affiliation to the Pharmacy endpoint, and the others to the non-Pharmacy endpoint. Right?
Nagarjuna Sanivarapu (Feb 03 2021 at 18:51):
Thanks Saul. Yes that is correct, will the plan be deviating from IG and create compatibility issues with 3rd party?
Saul Kravitz (Feb 03 2021 at 19:10):
Your proposal won't work. Querying a location by _id or any of its other search parameters without any reverse chaining constraint is required and expected. Clients have an expectation that your implementation supports the SHALL capabilities in the IG, and when you deviate from that you will break clients. For example, an expected use case is a client that has cached the directory content will return to check if the lastUpdated date on an instance has changed.
I don't know how to address this challenge. Perhaps others on this stream have ideas.
Perhaps you could pass the query to both vendor endpoints and merge the results?
@Robert Dieterle @Mark Scrimshire @Viet Nguyen
Suma Addagadde (Feb 03 2021 at 23:36):
Thanks Saul for the response. Just to clarify, we are certainly supporting the SHALL capabilities in the IG. in addition, we are making the _has:OrganizationAffiliation:location:role search criteria as mandatory to help us distinguish pharmacy and provider directory requests. It is similar to having 2 different endpoints for Provider and Pharmacy directory requests. We are facing the challenge of having to consolidate responses from 2 vendors and also support FHIR pagination. This ability to have seperate requests for Provider and Pharmacy will greaty simplify our implementation. Appreciate any guidance on this.
Saul Kravitz (Feb 03 2021 at 23:44):
making the _has:OrganizationAffiliation:location:role search criteria as mandatory
Not all Location queries to the Pharmacy info will have this qualifier. So I would say that all Location queries having this qualifier should probably go to the pharmacy vendor. But queries lacking this qualifier may also need to go to pharmacy vendor.
Suma Addagadde (Feb 05 2021 at 03:11):
Thanks Saul
Last updated: Apr 12 2022 at 19:14 UTC
