Stream: implementers
Topic: Typeahead / Autocomplete Box
Igor Sirkovich (Nov 24 2016 at 18:19):
I'm wondering if it makes sense to use FHIR Search for Typeahead / Autocomplete / Lookup boxes, e.g. fetch list of organizations, practitioners or zip / postal codes matching user's input as soon as a user types into a box each leter. Would FHIR be an overkill / too expensive for this? Some of these lookups are too big to be prefetched and locally stored on a client.
I would also like to learn if anyone has implemented a Typeahead / Autocomplete functionality on a client side with an effcient management of server requests vs local caching and whether anyone has used any open source library, e.g. https://github.com/twitter/typeahead.js/.
Grahame Grieve (Nov 24 2016 at 18:22):
it's been used for this. _summary=text is intended for this.
Grahame Grieve (Nov 24 2016 at 18:22):
I don't know whether any one has used typeahead.js
Igor Sirkovich (Nov 24 2016 at 18:29):
I'm not sure if text would be a good fit for the lookup box, which has very limited length, especially if it's on a mobile device, and wouldn't be able to coommodate a long formatted text. But even more importantly, is the question of efficiency if we need to send an HTTP request to a FHIR server after each letter been typed by a user vs prefetch / caching of a full looup list vs some other machanisms.
Grahame Grieve (Nov 24 2016 at 18:32):
well, there's no much the FHIR spec can do about that. I'll tell you what I do in one context - I cache sets of resources locally to save on latency where I can. But that's a lot more coding. So you pick your poison
Igor Sirkovich (Nov 24 2016 at 18:37):
Thank you @Grahame Grieve. This is why I would like to see how others has done this for their implementations, ideally, tested with a large number of user in production, and find out if there are any best practices or useful libraries available that can help make this more efficient.
Jim Steel (Nov 25 2016 at 06:07):
CSIRO uses typeahead-style interaction in our tools such as Shrimp and Snapper, typically to talk to Ontoserver (but its FHIR, so any terminology server). Works nicely, but it is sensitive to server performance.
Igor Sirkovich (Nov 25 2016 at 06:31):
Thank you @Jim Steel. As it seems CSIRO tools are not open source (I don't see them on GitHub), I will appreciate if you can describe the typeahead design: does it call a FHIR server for each typed character, pre-fetches/caches at a client, uses any open source libraries?
Jim Steel (Nov 25 2016 at 06:38):
Those websites are angular sites, so we use the angular/bootstrap typeahead widget (uib-typeahead), which invokes a javascript function that makes the call to the fhir server
Jim Steel (Nov 25 2016 at 06:41):
uib-typeahead by default sends a request every keystroke, but it has a parameter you can set for how many ms to wait before sending, to avoid interrupting the user typing, or sending too often
Jim Steel (Nov 25 2016 at 06:43):
(actually, snapper is angular. shrimp is not. same principles, though)
Igor Sirkovich (Nov 25 2016 at 07:08):
Thank you so much @Jim Steel! Our first client app is also Angular, so it's very helpful to know that you've had good experience with uib-typeahead. I'm wondering if you performed any stress testing to see how Shrimp's typeahead performance is affected by multiple simultaneous users (or if you experienced this in production). I'm also wondering if Shrimp requests fulll resources, just text & mandatory elements ("_summary=text") or uses "_elements" to limit to a specific set of elements be returned when calling FHIR server after each keystroke.
Jim Steel (Nov 25 2016 at 07:14):
I haven't personally worked on Shrimp (the non-angular one) as much, but multiple users isn't a problem for the client, only for the server, so it depends on the server/s you're hitting. We've done stress testing for our server, and for some definition of fine, its fine. Our web apps very rarely request full resources. We almost always use _elements, as well as count (and sometimes count=0). We do run into performance problems sometimes, but between those tricks, and others like using batch where possible to avoid sending lots of requests, there's generally been a way.
Jim Steel (Nov 25 2016 at 07:15):
We do also try to customise our client request behaviour based on querying the Conformance/CapabilityStatement to see what the server supports. E.g. if the server claims to support batch, we will use it. If it doesn't, we will instead send multiple requests.
Igor Sirkovich (Nov 25 2016 at 07:21):
Thank you Jim! This is incredibly helpful.
Michael Lawley (Nov 26 2016 at 10:30):
@Jim Steel is right - judicous use of _elements is key to making the typeahead performance feel right. It's also very important to ensure that your server is sending compressed responses. FInally, at least in the case of terminology, HTTP caching also helps with load. But of course you need a relatively fast server in the first place. You can play with our ValueSet expansion tool http://ontoserver.csiro.au/vstool/ to get a feel for the relative performance of different servers.
Brian Postlethwaite (Nov 27 2016 at 05:45):
+1 on what's been described above, we've implemented this in our solution also with valueset expansion, but haven't started for the other types yet, but was planning on trying with the _elements option.
Brian Postlethwaite (Nov 27 2016 at 05:46):
Especially the don't request on every keystroke, wait a short time till no more keys are coming, then request.
As while keys are coming in, the search filter is being refined, so performance is improved by asking the server less times.
Last updated: Apr 12 2022 at 19:14 UTC
