How do i search Practitioners in a department/organization e.g prov,dep,gov on FHIR server. i want to display only practitioners from a particular organization.
Tried this "GET [base]/Practitioner?Organization=Organization/{_id}" and did not return any results.
You can only search a resource based on information in that resource, and more specifically, using search parameters defined for the resource. Practitioner doesn't capture any information about 'organization' and doesn't have a search parameter called "Organization". (Side point - search parameter names are almost always lower-case.)
Practitioner represents a professional independent of who they work for or what role they're acting in. The PractitionerRole resource is what you need. It represents the combination of "who?" (practitioner), "on-behalf-of whom?" (organization), and "wearing which hat?" (code). Not all aspects will be present/relevant in all instances, but in your case you'd have both organization and practitioner.
Related
I am developing an API in a microservice for Invoice entity that takes in input a list of Purchase Order Item (i.e. PO Item) identifiers for ex. PO# + productIdentifier together can be used to identify a POItem uniquely. The response of the API is the invoiced quantity of each PO Item.
Input Model -
input GetInvoicedQuantityForPOItemsRequest {
poItemIdentifierList : POItemIdentifierList
}
Structures
list POItemIdentifierList {
member : POItemIdentifier
}
structure POItemIdentifier {
purchaseOrderNumber : String,
productIdentifier : Long
}
Invoiced Quantity of a POItem = SUM of Quantity of Invoice Items created from that PO Item.
Note : A single PO can be used to create multiple Invoices. An Invoice can be created from multiple POs.
I am quite new to REST and so far we have been using RPC endpoints in our legacy service. But now i am building a new service where i am defining endpoints in REST format (for ex. CreateInvoice has been changed to POST /invoice) and I need some suggestions from Stack Overflow community what would be the right approach for defining the REST endpoint of this API or should we keep it in RPC format itself.
RPC endpoint for this API in legacy system : POST /getInvoicedQuantityForPOItems
Our first attempt on REST for this is : POST /invoice/items/invoicedQuantityForPOItems. But this URI does not look like a Noun it is a Verb.
this URI does not look like a Noun it is a Verb.
REST doesn't care what spelling conventions you use for your resource identifiers.
Example: this URI works exactly the same way that every other URI on the web works, even though "it looks like a verb"
https://www.merriam-webster.com/dictionary/post
The explanation is that, in HTTP, the semantics of the request are not determined by parsing the identifier, but instead by parsing the method token (GET, POST, PUT, etc).
So the machines just don't care about the spelling of the identifier (besides purely mechanical concerns, like making sure it satisfies the RFC 3986 production rules).
URI are identifiers of resources. Resources are generalizations of documents. Therefore, human beings are likely to be happier if your identifier looks like the name of a document, rather than the name of an action.
Where it gets tricky: HTTP is an application protocol whose application domain is the transfer of files over a network. The methods in HTTP are about retrieving documents and metadata (GET/HEAD) or are about modifying documents (PATCH/POST/PUT). The notion of a function, or a parameterized query, doesn't really exist in HTTP.
The usual compromise is to make the parameters part of the identifier for a document, then use a GET request to fetch the current representation of that document. On the server, you parse the identifier to obtain the arguments you need to generate the current representation of the document.
So the identifier for this might look something like
/invoicedQuantityForPOItems?purchaseOrder=12345&productIdentifiers=567,890
An application/x-www-form-urlencoded representation of key value pairs embedded in the query part of the URI is a common spelling convention on the web, primarily because that's how HTML forms work with GET actions. Other identifier conventions can certainly work, though you'll probably be happier in the long term if you stick to a convention that is easily described by a URI template.
I'm using the Google Places API endpoint "findplacefromtext" and tried a search similar to the example.
https://maps.googleapis.com/maps/api/place/findplacefromtext/json?input=mongolian%20grill&inputtype=textquery&fields=photos,formatted_address,name,opening_hours,rating&locationbias=circle:2000#47.6918452,-122.2226413&key=YOUR_API_KEY
However, when you use this it only ever returns one result. There is a cafe near me that's called "Cream" but when you pass that as the "input" parameter it returns shops that have a category of "Ice Cream". I thought it should only search the name of the business.... If I can't find the place by name does it search the category type as a fall back? When I execute the same search in Google Maps it returns the same data but I get multiple results and I can see the place I am trying to retrieve 3rd on the search result list.
Is it possible to make it return more than one result? The documentation doesn't mention anything about this.
I believe what you need is the Text Search request. The Find Place request is meant for exact addresses.
The Google Places API Text Search Service is a web service that
returns information about a set of places based on a string — for
example "pizza in New York" or "shoe stores near Ottawa" or "123 Main
Street". The service responds with a list of places matching the text
string and any location bias that has been set.
The service is especially useful for making ambiguous address queries
in an automated system, and non-address components of the string may
match businesses as well as addresses. Examples of ambiguous address
queries are incomplete addresses, poorly formatted addresses, or a
request that includes non-address components such as business names.
Taken from https://developers.google.com/maps/documentation/places/web-service/search#TextSearchRequests
This question here basically asks the same question:
Restrict Google Places Autocomplete to return addresses only
But doesn't get the right answer.
If we look at the official documentation examples they have an option to selected address type. However, on it, we can see that it will allow us to selected just streets:
Is there a way to make Places Autocomplete select real addresses only?
Since this question is quite old, the search result is now somehow different but the fact that address type returns street addresses remains the same.
And to clarify things here, the API is working as intended when it returns street addresses.
types=address seems to be quite vague and what you need to do is to be more specific if you don't want street address to be included.
Here's a table for reference on the different types of restrictions for autocomplete from the Place Types Documentation.
Table 3: Type collections supported in Place Autocomplete requests
The supported types are:
geocode instructs the Place Autocomplete service to return only geocoding results, rather than business results. Generally, you use this request to disambiguate results where the location specified may be indeterminate.
address instructs the Place Autocomplete service to return only geocoding results with a precise address. Generally, you use this request when you know the user will be looking for a fully specified address.
establishment instructs the Place Autocomplete service to return only business results.
(regions) type collection instructs the Places service to return any result matching the following types:
locality
sublocality
postal_code
country
administrative_area_level_1
administrative_area_level_2
(cities) type collection instructs the Places service to return results that match locality or administrative_area_level_3.
To further prove this, I tried using the official documentation example for testing.
I tried searching real street address with both types=address and types=geocode and they return street addresses as expected.
With address type:
With geocode type:
Then I tried the types=establishment and it did not return any street addresses.
With establishment type:
You can use any other types value apart from types=establishment like the (cities) and (regions). As long as you are specific in your restrictions, things will be working fine. You can just put some toggle on your app to change restrictions just like on the official docs example so that your end user could freely choose the restrictions. But it still depends on your use case.
Hope this helps.
FHIR stu3
tried this:
http://fhirtest.uhn.ca/baseDstu3/PlanDefinition/20630?_revinclude=ActivityDefinition
based on the example from :
http://build.fhir.org/search.html#include
but it returned 400 Bad Request
thanks
There are 4 issues with your syntax:
_revinclude is a parameter for the search operation. Searches use the "type" endpoint (i.e. [base]/[resource]). Your format is for a read ([base]/[resource]/[id]). Reads only return a single resource, not a bundle and they don't take most parameters (you can do _format, but that's about it)
_revinclude needs to identify both the resource and the search parameter. E.g. ActivityDefinition:plandefinition, not just ActivityDefinition
The reference in the resources isn't from ActivityDefinition to PlanDefinition, but from PlanDefinition to ActivityDefinition. So you don't actually need a reverse-include. A simple _include is what you need given that your focus is already PlanDefinition
There's no standard search parameter on PlanDefinition to search based on ActivityDefinitions - and both _include and _revinclude are based on search parameters (because that's what servers index).
Because of the 4th issue, you're not going to be able to execute this test against any of the public test servers - unless you make special arrangements, they only support core search criteria. However, on your own system, you're free to define your own search criteria. If you were to do that, you ought to be able to make the query work using the following url:
[base]/PlanDefinition?_id=20630&_include=activitydefinition
(Assuming that you've named your custom search criteria having a path of PlanDefinition.activity.activityDefinition as having a name of "activitydefinition")
Is it possible with a FHIR search procedure to search for TWO resource types and sort them according to the date? I'd like a list of Observation and QuestionnareResponses, in a single response, returning the newest 10 regardless of resource type.
Searching for one would be:
http://apps.ehelselab.com/baseDstu2/Observation?_sort:desc=date
Any query using the standard "search" capability is always against exactly one resource type. You can include referencing and referenced resources, but filtering and sorting are always done against the "base" resource for the search. To do what you're interested in doing, you have a few options:
define a custom query using the OperationDefinition mechanism (only works if you've got a direct relationship between client and server systems so you can ensure all participants support the operation
Use a "Batch" to execute queries against both, then interpolate the results as you page through both result sets
You can do a query just on the "base", however there isn't presently a way to constrain the types of resources returned - you'd need a custom search criteria
You might be able to use the _filter mechanism - I haven't dived into it very deeply. But I suspect that it also uses the "single target resource type" approach.
The best bet is probably #3. If you submit a request to add a search criteria to "Resource" allowing constraining the resource type, that would probably let you do what you wanted.