Stream: implementers
Topic: search fields
Günter Zöchbauer (Sep 15 2016 at 09:38):
In the profile specialty is defined as
"path": "Practitioner.practitionerRole.specialty",
In the conformance response from the server (http://fhirtest.uhn.ca/baseDstu2)
it is defined as
"searchParam": [
...
{
"name": "specialty",
"type": "token",
"documentation": "The specialty that the referral is for"
},
without the full path.
Isn't there some possibility that there is more than one specialty inside some any of the complex properties?
Brian Postlethwaite (Sep 16 2016 at 22:15):
Not sure why that would be.
The spec clearly has the path defined.
http://hl7.org/fhir/practitioner.html#search
And even with the right description
Günter Zöchbauer (Sep 19 2016 at 11:05):
@Brian Postlethwaite missed your message previously
It seems https://www.hl7.org/fhir/searchparameter-definitions.html#SearchParameter.xpath would provide that information.
Any idea why this is not included?
Brian Postlethwaite (Sep 19 2016 at 11:48):
That would be a question for the HAPI folk @James Agnew any suggestions on what's going on here?
James Agnew (Sep 28 2016 at 21:24):
Hi @Günter Zöchbauer , @Brian Postlethwaite , the answer is fairly simple.. The conformance statement is generated from code (ie. it comes from server code and not from the spec) and the code that generates it doesn't include the path.
It wouldn't be too hard to add the path. Contributions welcome. :)
Günter Zöchbauer (Sep 29 2016 at 08:18):
@James Agnew
The conformance statement is generated from code
thanks for the info, it's helpful to know that the path is currently just missing.
Contributions welcome. :)
I'm not into Java so I'll pass here for now (sorry). I hope to find some time to investigate the project eventually and perhaps contribute.
Paul Knapp (Oct 03 2016 at 06:39):
Do we have style suggestions for defining resource search parameters for elements which are of type Resource and therefore may be referred to now using a reference (reference) or an identifier (token)? Should we take a reference-first stance such that:
resource ...
foo 0..1 Reference(FooResource)
Search Parameters (name datatype element description):
foo reference resource.foo "Search by reference"
fooIdentifier token resource.foo "Search by Identifier"
Grahame Grieve (Oct 03 2016 at 06:41):
I'd rather you just define a reference type, and we resolve whatever we want to do as part of the reference search parameter type
Grahame Grieve (Oct 03 2016 at 06:50):
because it's the same for every single reference search parameter
Paul Knapp (Oct 03 2016 at 06:56):
Currently I am just including the reference search.
Then it would be:
GET [base]/Resource?foo=abc (resolve against reference or identifier.value) or
GET [base]/Resource?foo=Resource/abc (resolve against reference only) or
GET [base]/Resource?foo=[system]|[value] (resolve against identifier only)
Probably need to include | for identifier searches to resolve amgibuity - will the reference argument validation permit | ?
Grahame Grieve (Oct 03 2016 at 07:01):
I think that's a workable approach - we'd need to update the documentation for it, though. Does anyone have any other opinion about this?
Paul Knapp (Oct 03 2016 at 08:51):
Also, INFORMATION: Resource.foo: Search parameter 'Resource.foo' had no found values in an example - isn't working - this message is resported even when there are instances of the element in examples (eg. required elements).
Brian Postlethwaite (Oct 03 2016 at 11:34):
Wondering what to do with sorting on those fields too, if at all.
Paul Knapp (Oct 03 2016 at 11:52):
If you need to I'd sort on reference then on identifier (system,value).
Last updated: Apr 12 2022 at 19:14 UTC
