Stream: implementers
Topic: Plan for complex queries support
Behrad Sadoughian (May 10 2016 at 21:03):
I wonder what the plan of FHIR for complex queries is.
Currently we have:
1) standard queries as per https://www.hl7.org/fhir/search.html but as it does not support OR, (), sub-queries etc, it can work for very simple resource retrievals only
2) _filter as per https://www.hl7.org/fhir/search_filter.html which seems promising however it is not completely documented, HAPI doesn't support it and the maturity is still N/A.
3) fluentPath http://hl7.org/fhir/2016May/fluentpath.html which aligns with HL7 CQL.
4) Advanced search as per 2.1.1.7 in https://www.hl7.org/fhir/search.html. This is actual a custom interface and needs client and server setup the parameters so cannot be used as a P&P standard. for that reason I can't call it a standard.
Which one is going to be the FHIR complex query protocol of choice?
PS> (example for complex queries: Show me all patients having Dr A as care provider, having at least 2 diagnosis coded as X and born between D1 and D2)
Chris Grenz (May 11 2016 at 02:27):
@Behrad Sadoughian See this thread for a discussion that would satisfy your example: https://chat.fhir.org/#narrow/stream/implementers/subject/_has.20parameter.20proposal
Behrad Sadoughian (May 11 2016 at 03:30):
Thanks. That's interesting however my example is just one example. There are many complex queries and I wonder which approach is going to be the strategic protocol development choice.
Grahame Grieve (May 11 2016 at 10:40):
(1) - see 2
(2) - please explain how _filter is not completely documented. Maturity is FMM 1. I should document that. As far as support in servers other than mine, I cannot say
(3) I am sure that fluent path will not be part of the standard search interface. But you can define parameters that are defined by fluent path expressions - that's how my server works now
Grahame Grieve (May 11 2016 at 10:41):
(4) advanved search is your extensibility point
Grahame Grieve (May 11 2016 at 10:42):
we do not think that we have solved query requirements yet. It was on the slate for STU 3, but it has missed the boat now.
Peter Bernhardt (May 11 2016 at 15:53):
My concern is that to the extent the formal specification adds complexity, it decreases interoperability in inverse proportion.
Ewout Kramer (May 11 2016 at 16:18):
Peter, yes, I also expect the number of servers implementing this kind of search will be low, so in practice you couldn't count on it when writing a client...
Bryn Rhodes (May 12 2016 at 22:17):
Agreed, there are so many use cases for complex query, and various ways of meeting that. The CQL specification in particular focuses on enabling complex queries to be expressed in a way that supports translation to simpler queries through a data access layer, such as FHIR, or a B-Tree style index API.
Ewout Kramer (May 12 2016 at 23:15):
Hi Bryn, never looked at it that way... so you made that work? Translate CQL into separate FHIR REST calls?
Bryn Rhodes (May 13 2016 at 07:32):
Yes, that's what we got working at the connect-a-thon Saturday. Going to host a HAPI server that has it plugged in for more testing, but it's basically functional.
Ewout Kramer (May 13 2016 at 18:36):
Cool.
Last updated: Apr 12 2022 at 19:14 UTC
