Can someone please explain the functionality of _revInclude in fhir with an example?
This is what i understood,
if we have an encounter resource we can have a location and that location will have a organization resource referenced in partOf property. if we send a request ....Encounter?_id=1234&_include=Encounter:location&_revinclude=Location:Partof then the returned bundle will conatin the enounter resource, its corresponding location resource and the organization resource that the location belongs to.Is this correct?
_revinclude causes a search response to include resources that have a relationship to the primary resources in the search response to also be included. Your example wouldn't quite work because your _revinclude isn't talking about a reference to the primary resource (Encounter in your example). To work, you'd have to use _revinclude:iterate. The second consideration is syntax. There's an additional challenge with your _revinclude in that the syntax must be [Resource]:[search-param-name]. The Resource is the resource you want returned and the search-param-name is the search parameter by which that resource points to the primary resource (or with 'iternate', any other included resource). The search parameter name in Location that you need is partof, not Partof. And capitalization matters - at least for some servers
This should work:
[base]/Encounter?_id=1234&include=Encounter:location&_revinclude:iterate=Location:partof
Related
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.
I am pondering about schema design with regard to explicit vs implicit relation when to...
for example:
in an imaginary schema with 2 custom types author and post, each with several properties, A post type can reference an author in 1 of 2 ways:
explicit: having an Autor type property
implicit: having a scalar value that indirectly points to the author
when designing a shema. what should be my compass in this kind of desicion making?
thanks in advance
There's absolutely no value to the client in only returning the ID of a related resource when you could just expose a field that would return the entire resource. Exposing only the ID will mean the client will have to make subsequent requests to your service to fetch the related resources, instead of being able to fetch the entire data graph in one request.
In the context of other services, like a REST API, it might make sense to only return the ID or URL of a related resource. This is because in those cases, the payload is of a fixed size, so returning every related resource by default can quickly and unnecessarily bloat a response. In GraphQL, however, request payloads are client-driven so this is not a concern -- the client will always get exactly what it asks for. If the client needs only the author's ID, they may still fetch just that field through the author field -- while allowing a more complete Author object to be fetched in other requests or by other clients.
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.
It appears that the ParseFile does not have an ACL, or put another way, once the URL of the ParseFile gets out in the wild, the file is available to anybody who can make a GET http request.
I hope I'm missing something in the documentation, because this does not sound like a great idea. As best as I can understand it, this means that the URL is "protected" only by the ACL of the ParseObject that holds the reference to the ParseFile.
Perhaps it's relevant to know that I'm reading/using the .NET+Xamarin bits.
I think you've summed it up best yourself:
"protected" only by the ACL of the ParseObject that holds the reference to the ParseFile
If someone does happen to know your url for that particular file then kudos to them, because they are uniquely created, just like objectId's:
.. containing the name of the file, which is the original file name prefixed with a unique identifier in order to prevent name collisions. This means you can save files with the same name, and the files will not overwrite one another...
So in other words, the last path component will always be unique:
tfss-db295fb2-8a8b-49f3-aad3-dd911142f64f-airlines.txt
Even if you re-upload a new airlines.txt document:
tfss-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-airlines.txt
To summarize ACL:
An ACL, or Access Control List can be added to any Parse.Object to restrict access to only a subset of users of your application.
So according to Parse, it's purposes are intended for the object itself, not specific parameters of that object. As of now, they do not support say, setting a specific read/write ACL on the objects 'Title' column or 'Email' column or a specific column type, the ACL's are object or User dependent.
For those that are interested in reading more about Parses ACLs can see their resource here: http://blog.parse.com/learn/engineering/parse-security-i-are-you-the-key-master/