Stream: implementers
Topic: Searching [base]/[type] with no parameters
Ken Sinn (Feb 13 2019 at 17:59):
Hi all,
Quick question on searching FHIR resources. I recall that a search against http://[base]/[type] with no parameters would retrieve all [type] resources, and this is conformant with FHIR. Additionally, the HAPI sandbox also supports this behaviour. I cannot find this documented in the FHIR pages, either at https://www.hl7.org/fhir/http.html or https://www.hl7.org/fhir/search.html, so I might just be blind.
Are there any recommendations against allowing users to query against http:[base]/[type], and based on their OAuth2 token, returning only those resources that they have authorization to view (typically, those resources where the user is the the patient).
Lloyd McKenzie (Feb 13 2019 at 19:14):
It's definitely allowed to not include any filters, but agree this doesn't appear to be explicitly called out. Can you submit a change request for us to do this?
Lloyd McKenzie (Feb 13 2019 at 19:17):
The expectation is that a system will always filter to what data a user is allowed to see regardless of what filters they specify. So if a patient is only allowed to see their own Observations, then a query against the Observation endpoint would only include Observations that have them as a subject. However, typically you'd still want to include additional parameters to not be overwhelmed with data. (And access permissions might well give a patient access to other patient's data - e.g. a parent to their dependent children as allowed by institution policy and/or the child's consent.
Ken Sinn (Feb 14 2019 at 16:36):
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=20392 created.
Michael Donnelly (Feb 25 2019 at 21:25):
It should be a server's option whether to return all data or an OperationOutcome. Servers may have cases - including ones less broad than this - where they'll decline to respond to searches that aren't sufficiently constrained.
Grahame Grieve (Feb 25 2019 at 23:28):
we can define the correct interpretation. It's always the server's option to say 'no, too wide'
Last updated: Apr 12 2022 at 19:14 UTC
