Stream: implementers
Topic: search & retrieve subset of elements
natus (Aug 22 2017 at 07:05):
Hi,
I d'like to be able to only retrieve one element or two elements of a resource. For example
"give me the names of the patient having 30 years old".
For now, the spec looks only able to answer :
"give me all the elements of the patient having 30 years old".
Is this possible to extend the spec in order to allow fetching a subset of the element of a resource ?
The main advantage is to get only the information needed, and decreasing drastically the network load.
Thanks
natus (Aug 22 2017 at 07:19):
This would also decrease the backend database IO, because fetching less data in the tables. All this would lead to mutch better performances in special cases, and extend the FHIR uses cases
Vadim Peretokin (Aug 22 2017 at 07:27):
@natus check this out: http://hl7.org/fhir/search.html#elements
natus (Aug 22 2017 at 08:41):
@Vadim Peretokin thanks, this is exactly what I was looking for.
Eric Haas (Aug 23 2017 at 00:56):
Have you looked at GraphQL in the developmental build? http://build.fhir.org/graphql.html
David Hay (Aug 23 2017 at 05:40):
and Grahames server has an implementation of GraphQL that I added to clinFHIR - https://fhirblog.com/2017/08/17/graphql/
If anyone else has an implementation I'd be delighted to add it as well!
Grahame Grieve (Aug 23 2017 at 06:22):
HAPI servers should have one once they're next upgraded
David Hay (Aug 23 2017 at 08:39):
Hurrah! (btw - is there an entry in the CapabilityStatement that indicates this?)
Richard Ettema (Aug 23 2017 at 14:09):
FYI - Touchstone now has support for GraphQL testing with some initial TestScripts deployed for Connectathon 16.
Touchstone_GraphQL.jpg
natus (Sep 29 2017 at 23:42):
hi
The subset method is still very verbose
http://fhirtest.uhn.ca/baseDstu3/Patient?_elements=id&_count=1
{
"fullUrl": "http://fhirtest.uhn.ca/baseDstu3/Patient/32754",
"resource": {
"resourceType": "Patient",
"id": "32754",
"meta": {
"versionId": "7",
"lastUpdated": "2017-09-28T07:54:35.154-04:00",
"tag": [
{
"system": "http://projectcrucible.org",
"code": "testdata"
},
{
"system": "http://example.org/codes/tags",
"code": "entered-by-hand",
"display": "Patient File entered by hand"
},
{
"system": "http://hl7.org/fhir/v3/ObservationValue",
"code": "SUBSETTED",
"display": "Resource encoded in summary mode"
}
]
}
},
"search": {
"mode": "match"
}
}
Any chance to introduce a _compact verb resulting:
http://fhirtest.uhn.ca/baseDstu3/Patient?_elements=id&_count=1&_compact=true
{
"id": "32754",
}
This would allow many new uses cases that are not very efficient right now.
GraphQL looks like a good workaround, but maybe to much complicated
Eric Haas (Sep 29 2017 at 23:47):
GraphQL sounds like the answer to me.
Ewout Kramer (Oct 02 2017 at 15:07):
I wonder if we would serialize all the Meta.tag data too....... @Brian Postlethwaite ?
Brian Postlethwaite (Oct 02 2017 at 19:28):
We do now (after that last change i put in recently)
And i don't think removing the meta is a good idea, should really always be there regardless.
Last updated: Apr 12 2022 at 19:14 UTC
