Stream: Da+Vinci+PDex+Plan-Net
Topic: Search Criteria - Pharmacy network
Bapi Behera (Sep 15 2020 at 16:13):
Search parameter name is case sensitive. What is the standard naming convention for the the search parameters? Please suggest.
Here is an example:
-
https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/SearchParameter-healthcareservice-service-type.html
Search parameter name : **Plannet_sp_healthcareservice_type
** -
In base FHIR, the search parameter name is: service-type
https://www.hl7.org/fhir/healthcareservice.html -
in the CapabilityStatement, the parameter name is : service-type
https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/CapabilityStatement-davinci-pdex-plan-net.html#healthcareservice
@Saul Kravitz @Pat Taylor
@Kate Dech @Mona O @Annette Kuball
Kate Dech (Sep 16 2020 at 17:54):
This is more than just asking about the case sensitivity. Do we need to use the DaVinci (or CARIN for Blue Button) search parameter names that are in the IG...that appear to be much longer names than base FHIR, but to the same expression. And since chaining and reverse chaining is on the searchparameter name, would it also have to be represented there?
as a basic search parameter...
GET [base]/HealthcareService?specialty=[value]…
becomes ...
GET [base]/HealthcareService?Plannet_sp_healthcareservice_specialty=[value]
as a chained parameter...
GET [base]/Location?_hasHealthcareService:location:specialty=[value]...
becomes...
GET [base]/Location?_hasHealthcareService:Plannet_sp_healthcareservice_location:Plannet_sp_healthcareservice_specialty=[value]
OR can we use the base FHIR search parameter names? That's what I see in the reference implementation.
Saul Kravitz (Sep 17 2020 at 16:18):
The search parameter codes in Plan-Net have not changed . The code is how the search parameter is referred to in a query.
The search parameter names have changed (Plannet_sp_healthcareservice_coverage_area), but you don't refer to these in a query.
You can play with these on our reference implementation which has the plan-net search parameters installed on a HAPI server.
One thing that has changed, which probably unnecessary, but not impactful is the search parameter ID:
- base resource: "derivedFrom" : "http://hl7.org/fhir/SearchParameter/HealthcareService-coverage-area",
- plannet: "id" : "healthcareservice-coverage-area",
Kate Dech (Sep 17 2020 at 17:44):
Thanks Saul!
Kate Dech (Sep 17 2020 at 20:26):
Another question. The Capability Statement only lists address as a search parameter. In base FHIR, there are variation - address-city, address-state. I see in the reference implementation, address-city is used. Should that be included in the capability statement in plan-network or do you have access to any of the base resource search parameters automatically? We would like to use address-city, address-state, address-zip so it can be specified (looking in the city of Saint Paul, exclude address lines for Saint Paul Ave.)
Saul Kravitz (Sep 17 2020 at 20:50):
The Reference implementation was built before we shrank the search interface down significantly. If it is using search parameters that are not SHALL in the capability statement, it is an error in the Reference Implementation. I think on the HAPI server, the search parameters of the base resource are probably available by default, but that is a happy implementation coincidence. As a server, you only SHALL support the search Parameters that are included in the capability statement, and as a client it would be wise to stick to those.
BTW: as per the connectathon discussion, we discovered some basic search parameters (_id, _lastUpdated, and probably _profile) that will (probably) be added to the capability statement.
@Dave Hill
Kate Dech (Sep 17 2020 at 21:23):
Can I request that the other address parameters be considered to add to the capability statement in the future? Location based searches using just address means you have to search all elements within Location.address. Not optimal performance; especially when there are built in parameters to limit to specific parts of the address.
Saul Kravitz (Sep 21 2020 at 22:17):
@Robert Dieterle
Saul Kravitz (Sep 21 2020 at 22:19):
address search parameter does support the exact and contains modifier. So searching with contains lets you search against a zip or a city.
Kate Dech (Sep 22 2020 at 18:13):
Can you elaborate? It's my understanding that in the Location 'address' search parameter searches any part of the Address structure; whereas address-city, address-state, address-postalcode, address-country were more specific to these specific element in Address. How would you use Location.address and specify that it is for a City Name rather than a street/address line name?
Saul Kravitz (Sep 22 2020 at 20:14):
Your understanding is correct.
Kate Dech (Sep 22 2020 at 20:41):
So can I use 'address-city' as a search parameter to limit a search to just city even if only 'address' is a search parameter on Location in the CapabilityStatement. Based on your earlier response I thought no, I could only use 'address.'
Saul Kravitz (Sep 22 2020 at 21:29):
No, you can't. YOu could search for address:contains=Rockville, and pick up the addresses where address.city = Rockville, but you'd also pick up the addresses where the street name includes Rockville.
Saul Kravitz (Oct 01 2020 at 15:05):
We are planning to add back in the city, state and zip search parameters.
Kate Dech (Oct 02 2020 at 18:15):
Excellent news Saul. Is this an immediate change or something off in the future (after 1/1)?
Saul Kravitz (Oct 02 2020 at 18:37):
I expect it to be included in the (soon to be published, but I can't give a date) 1.0 release
Bapi Behera (Oct 06 2020 at 15:36):
Saul Kravitz said:
I expect it to be included in the (soon to be published, but I can't give a date) 1.0 release
Saul - We need the Capability statement update to add the below search paramenters. Can it be updated as a part of document update? Shall we create a Jira ticket?
address-city
address-country
address-postalcode
address-state
Kate Dech (Oct 06 2020 at 16:04):
And to be clear, we are looking at the Location Resource...we need address-city, address-state, and address-postalcode on that resource. I think implementers may need to see that this is available as a search parameters sooner rather than later.
Kate Dech (Oct 08 2020 at 15:03):
I see it there now in v0.1.4!!!
Bapi Behera (Oct 08 2020 at 15:33):
Saul Kravitz said:
I expect it to be included in the (soon to be published, but I can't give a date) 1.0 release
Thanks Saul for adding the discreate address elements. This is very helpful.
Saul Kravitz (Oct 08 2020 at 22:02):
Thanks for your constructive input.
Last updated: Apr 12 2022 at 19:14 UTC
