Stream: implementers
Topic: SearchParameters
nicola (RIO/SS) (Mar 17 2016 at 13:27):
What is the source and role of some strange search parameters like this?
{
"fullUrl": "http://hl7.org/fhir/SearchParameter/familymemberhistory-daf-FamilyMemberHistory-relationship",
"resource": {
"resourceType": "SearchParameter",
"id": "familymemberhistory-daf-FamilyMemberHistory-relationship",
"url": "http://hl7.org/fhir/SearchParameter/familymemberhistory-daf-FamilyMemberHistory-relationship",
"name": "relationship",
"code": "relationship",
"base": "FamilyMemberHistory",
"type": "token",
"description": "Search for family history of members based on relationship",
"xpathUsage": "normal"
}
They have some name clashes with other parameters :(
Lloyd McKenzie (Mar 17 2016 at 14:26):
Name clashes are certainly possible in general, though for content published as part of the HL7 standard, we'd try to avoid collisions for parameters that might appear on the same resource
nicola (RIO/SS) (Mar 17 2016 at 15:15):
That's the case of collision on the same resource type. I could send you file with all collisions. May be we need some tests for consistency?
Lloyd McKenzie (Mar 17 2016 at 17:34):
Please raise it as a change request
Grahame Grieve (Mar 17 2016 at 18:17):
actually, we have several clashes with DAF, because DAF defined search parameters that subsequently got elevated in the spec, but not removed from DAF. @Brett Marquard do we have any plans in that regard? can I just remove them?
Brett Marquard (Mar 21 2016 at 23:30):
DAF plans to split the conformance in 2 -- one for patient access (constrained) and one for research access (very liberal). Will be added later this week
Nathan Hood (Sep 13 2019 at 17:30):
I am trying to do a search in Firely by meta.LastUpdated and I can't seem to figure out the syntax of setting up the parameters... The search section in the .NET docs is blank http://docs.simplifier.net/search.html
If there is anyone that can assist I would appreciate it greatly
Thank you.
Ward Weistra (Sep 15 2019 at 15:57):
Hi Nathan, Firely is a company creating multiple products like the open source .NET FHIR API, Vonk FHIR server, Simplifier.net FHIR collaboration platform and the FHIR Profile editor Forge :)
Likely you're searching in Vonk? The search documentation should be standard FHIR behaviour and is documented at https://www.hl7.org/fhir/search.html#lastUpdated. Does that work for you?
cc @Alexander Zautke
Nathan Hood (Sep 16 2019 at 15:17):
I'm using their HL7.Fhir.R4 package in .NET. Firely doesn't use the "?_lastUpdated=" for searching (as far as I can tell) it has it's own query system using search parameters of which lastUpdated is not a valid one. I couldn't find a way to search using the FHIR syntax at the end of last week, but I'll try again.
Brian Postlethwaite (Sep 16 2019 at 16:30):
That's just a convenience class to search with, and you can just add the "_lastUpdated" as a value in it. underneath it still creates URLs like you've shown.
Nathan Hood (Sep 16 2019 at 16:37):
I think I figured out a solution, I was able to get the search I needed done with the syntax :
var diagnosticReports = fhirClient.Search<DiagnosticReport>(new[] {"_lastUpdated=gt2019-09-13"});
I was making it harder than it needed to be :)
Joyce Zhou (Nov 19 2020 at 15:08):
For SearchParameters, what is meant to be the difference between search and code? Though in examples all name and codes are exactly the same, which one is the one that's actually used to define "what does user use in order to search for this field"?
Yunwei Wang (Nov 19 2020 at 15:35):
name is a computer friendly name, code is used in search query. Here is an example from us core ig
{
...
"resourceType": "SearchParameter",
"id": "us-core-allergyintolerance-clinical-status",
"name": "USCoreAllergyintoleranceClinicalStatus",
"code": "clinical-status",
...
}
The search query looks like
[base]/AllergyIntolerance?clinical-status=xxx
Joyce Zhou (Nov 20 2020 at 15:54):
Thanks! And that's a great example!
Katie Wheatley (Jan 12 2021 at 18:28):
Hello, I have created custom search parameter against CarePlan and I would like to run an _include statement against it. However, I am receiving an error in the returned OperationOutcome from the Vonk server as below:-
"issue": [
{
"severity": "warning",
"code": "not-supported",
"details": {
"coding": [
{
"system": "http://hl7.org/fhir/dotnet-api-operation-outcome",
"code": "5003"
}
],
"text": "Parameter 'author-inc' is not supported the resourcetype 'CarePlan'"
}
}
]
This is my RESTful query:
GET https://vonk.fire.ly/R4/CarePlan?subject:Patient.identifier=9912003889&_include=CarePlan:author-inc:Practitioner.
Please could anyone from the community advise on mistakes that I am making and how I can take steps to rectify them?
I attach the custom SearchParameter that I have created to execute this query. CarePlan-AuthorInc-SearchParameter.xml
Lloyd McKenzie (Jan 12 2021 at 18:44):
In general, custom code is required to get a server to support a custom search parameter. Have you made the needed customizations to the server?
Paul Lynch (Jan 12 2021 at 19:27):
I don't know about Vonk, but in HAPI FHIR you can just post a new SearchParameter and then re-index. (That might not be the case with Vonk.)
Lloyd McKenzie (Jan 12 2021 at 20:08):
Whether that works depends on the definition of the SearchParameter
Lloyd McKenzie (Jan 12 2021 at 20:08):
Does that work for composite search parameters in HAPI?
Katie Wheatley (Jan 13 2021 at 10:35):
Lloyd McKenzie said:
In general, custom code is required to get a server to support a custom search parameter. Have you made the needed customizations to the server?
Please could you outline here the server customisations which would be required. Many thanks.
René Spronk (Jan 13 2021 at 11:02):
See https://docs.fire.ly/firelyserver/features/customsearchparameters.html for Vonk SearchParameter support. Just make sure to POST SearchParameter to the /administration/ endpoint, and to reindex (as documented on that page).
Katie Wheatley (Jan 14 2021 at 09:16):
René Spronk said:
See https://docs.fire.ly/firelyserver/features/customsearchparameters.html for Vonk SearchParameter support. Just make sure to POST SearchParameter to the /administration/ endpoint, and to reindex (as documented on that page).
I have followed the instructions in the documentation, but on execution I only received the following error code: Error: connect ETIMEDOUT 40.68.2.109:443. Please could you advise on my next steps @René Spronk
René Spronk (Jan 14 2021 at 10:07):
Let's ask a Vonk expert (which I'm not): @Mirjam Baltus ?
Katie Wheatley (Jan 14 2021 at 10:42):
René Spronk said:
Let's ask a Vonk expert (which I'm not): Mirjam Baltus ?
Thanks, I would really appreciate your input @Mirjam Baltus
Mirjam Baltus (Jan 14 2021 at 11:10):
@Katie Wheatley Are you trying this on the public Vonk server, or your own local copy? If the first, it seems there is a problem reaching the administration endpoint on that, so that's probably causing your error. I've tried your search parameter on my own local Vonk, and it works perfectly.
Mirjam Baltus (Jan 14 2021 at 11:26):
@Katie Wheatley I've looked at the public server again, and can see that you have posted your SearchParameter to the regular repository, instead of to '/administration/SearchParameter'. On the regular data repository, Vonk will only store the resource, and not use it. So that is why you did not get any results. Not being able to reach the /administration endpoint was a typo on my behalf; it does work fine.
Katie Wheatley (Jan 14 2021 at 11:51):
Mirjam Baltus said:
Katie Wheatley Are you trying this on the public Vonk server, or your own local copy? If the first, it seems there is a problem reaching the administration endpoint on that, so that's probably causing your error. I've tried your search parameter on my own local Vonk, and it works perfectly.
@Mirjam Baltus Brilliant, I will try again.
Katie Wheatley (Jan 14 2021 at 23:31):
Katie Wheatley said:
Mirjam Baltus said:
Katie Wheatley Are you trying this on the public Vonk server, or your own local copy? If the first, it seems there is a problem reaching the administration endpoint on that, so that's probably causing your error. I've tried your search parameter on my own local Vonk, and it works perfectly.
Mirjam Baltus Brilliant, I will try again.
@Mirjam Baltus Unfortunately, although I did successfully post my new SearchParameter to the Vonk administration endoint e.g. https://vonk.fire.ly/administration, the documentation mentioned above states that I needed to rebuild the search index for specific searchparameters, once a new one is added. When I attempted to execute POST https://vonk.fire.ly/R4/administration/reindex/searchparameters, Vonk returned code 403, indicating that I am not permitted to perform the reindex. I've tried to run a RESTful query using my new SearchParameter, but Vonk still doesn't recognise the new SearchParameter and returns OperationOutcome.issue
"issue": [
{
"severity": "warning",
"code": "not-supported",
"details": {
"coding": [
{
"system": "http://hl7.org/fhir/dotnet-api-operation-outcome",
"code": "5003"
}
],
"text": "Parameter 'author-inc' is not supported the resourcetype 'CarePlan'"
Could you assist me further in resolving this?
Lloyd McKenzie (Jan 15 2021 at 02:03):
@Ward Weistra
Mirjam Baltus (Jan 15 2021 at 07:48):
@Katie Wheatley I do see that you've posted the SearchParameter to the administration endpoint. It is on the STU3 part of it, and also does not give any errors when you do a GET https://vonk.fire.ly/CarePlan?author-inc=xyz. If you need it on R4, you need to post to https://vonk.fire.ly/administration/r4/SearchParameter - please use a different URL, for example with '-R4' attached to it, since it now already exists with the current url on the R3 division.
It is correct that the reindex is not allowed on the public endpoint, to prevent someone from accidentally reindexing the whole database, which might cause performance issues for others. The search parameter will work, but only for new or newly updated resources. If you run a local copy, you would be able to do a reindex.
Katie Wheatley (Jan 15 2021 at 09:27):
Mirjam Baltus said:
Katie Wheatley I do see that you've posted the SearchParameter to the administration endpoint. It is on the STU3 part of it, and also does not give any errors when you do a
GET https://vonk.fire.ly/CarePlan?author-inc=xyz. If you need it on R4, you need to post to https://vonk.fire.ly/administration/r4/SearchParameter - please use a different URL, for example with '-R4' attached to it, since it now already exists with the current url on the R3 division.It is correct that the reindex is not allowed on the public endpoint, to prevent someone from accidentally reindexing the whole database, which might cause performance issues for others. The search parameter will work, but only for new or newly updated resources. If you run a local copy, you would be able to do a reindex.
Thanks @Mirjam Baltus, I have now successfully run my query.
Julius Severin (Jan 15 2021 at 12:45):
I am currently working on search on FHIR. While writing testcases I noticed that there is no reason-reference parameter for MedicationRequests.
The testcase I originally wanted to write was to get all MedicationRequests that had Hypertension as a reason.
This led me to the thought if there was any ResourceType that has reasonReference as a field that should not have reason-reference as a parameter.
==> Are there maybe fields that should always result in the same search parameters? (encounter, reason-reference, patient)?
Lloyd McKenzie (Jan 15 2021 at 16:44):
We don't have strong rules about what search parameters must exist in most cases. I do agree that a reason-reference search parameter would be appropriate. Can you submit a change request?
Last updated: Apr 12 2022 at 19:14 UTC
