Stream: javascript
Topic: survey.js
Grahame Grieve (Aug 04 2020 at 06:49):
Is it worth working with something like survey.js to add support for FHIR Questionnaires somehow?
David Winters (Aug 04 2020 at 12:24):
Hey @Grahame Grieve , I started a library for converting FHIR Questionnaires / SDC for use with survey.js. Right now support is limited to the features I need for the application I'm working on (alcohol screening), but there's no reason that it couldn't be extended.
Grahame Grieve (Aug 04 2020 at 12:25):
is producing a questionnaire response on your agenda?
Grahame Grieve (Aug 04 2020 at 12:25):
@Tim Blake fyi
David Winters (Aug 04 2020 at 12:27):
There's a companion SMART app that uses the library; in that app a QR is generated once the survey is completed. Again, very focused on my application, but you can find a working demo here. Chrome is highly recommended for the demo.
Abbie Watson (Aug 06 2020 at 16:33):
Ooof. Beware the wild-west of Javascript form libraries and the quicksand. 101 developers re-inventing the same wheel because they don't know better, and 10x more developers thinking "geeze, this library looks well used; they must know what they're doing" and following into the quicksand.
By and large, all these form libraries overly optimize for one particular usecase involving ad-hoc auto-generated forms from a relational database; failing to understand that the effort and entropy needed to define the edge cases to their autogenerated approach is the same amount of effort and entropy needed to build the form out from scratch using raw components. All these libraries do is introduce a double abstraction.
So, on the one hand, yes... work with survey.js because interoperability and it's javascript. Survey.js will be able to consume FHIR resources fairly easily. So, submitting pull requests and adding FHIR Questionnaire support won't be overly difficult. It's inevitable that these libraries are going to begin supporting FHIR Questionnaire. So don't try to stop it.
On the other hand, no... because almost every Javascript form library is introducing double-abstractions, making it more difficult to reason through code. It also winds up introducing more dependencies; more traffic on the wire; slower load times; increased hosting costs; etc.
So be careful of the quicksand!!!! It can derail a project by months; if not sabotage it altogether.
I speak from personal experience, having been burned multiple times trying to integrate FHIR Questionnaire with various libraries... Autoforms, Uniform, and various others. I speak from having projects collapse and having lost a job at UC Santa Cruz (which I really liked) because we had an architect try to push the use of Autoforms and make a generalized approach with the intent of reinventing clinical trials.
Abbie Watson (Aug 06 2020 at 16:40):
My $0.02 on which Javascript form/survey libraries to invest time in would be whatever is as close to bare metal as possible. No widgets. No MVC model. No user interface. No lifecycle management.
Keep it as minimalist as possible, focusing on validation, conditional logic, and saving forms. All it should do is upgrade the HTML <form> tag with FHIR. Then leave everything else to the underlying templating library.... Angular, React, Handlebars, Vue, etc.
For what it's worth, after 5+ years of screwing up with Javascript form libraries + FHIR Questionnaire, I've settled on Formik for the Node on FHIR stack for the foreseeable future:
David Winters (Aug 10 2020 at 11:08):
Thanks for the perspective @Abigail Watson . I wouldn't say SurveyJS suffers from many or any of the drawbacks you mention, of course I've only used it for exactly one application so take that for what it is. It sounds like you'd agree that we need more tools (not less) for working with FHIR Questionnaires. LForms is great but it did not (at the time I investigated) support async execution of CQL expressions, which I really needed for my application. I settled on SurveyJS because of a number of perceived benefits/strengths:
- Supports many front-end frameworks (React, Vue, Angular, etc).
- SurveyJS "Questionnaires" defined entirely in JSON.
- Mapping between SurveyJS and FHIR Questionnaire is pretty straightforward; see here.
- Supports arbitrary async callbacks; all I had to do was plug in my CQL expression evaluator.
So SurveyJS worked for me and I'm hoping others may find it useful as well; I'd love to see the simple converter I wrote get expanded out so that more Questionnaire and SDC capabilities get implemented. But your advice to carefully examine a technology before jumping in headfirst is very wise and well-said. For instance, LForms supports more of SDC out of the box and so is potentially a better starting point for many people. Regarding Formik, can you point to some examples for how it can be used with FHIR?
Abbie Watson (Aug 16 2020 at 19:11):
To be fair, much of my gripe is with jQuery and Bootstrap. The design paradigms of jQuery/Bootstrap vs React vs Angular are just so different that, in my experience, it causes maintenance headaches later down the road. Things that are easy to implement are difficult to maintain, and things easy to maintain are difficult to implement.
I'm putting together a small demo of the Formik example using Questionnaire. It's a recent addition to our stack, based on a gnarly refactor this past year. Should have it put together in the next few weeks; hopefully by Connectathon 25.
Brian Postlethwaite (Aug 26 2020 at 22:01):
I'm looking forward to seeing it.
Michael Lawley (Jan 06 2021 at 22:53):
@Abigail Watson how did this go?
One of our main desires is for a Questionnaire solution that works well with bindings to large ValueSets (e.g., will use ValueSet/$expand?filter= as the basis of a type-ahead widget)
Brian Postlethwaite (Jan 24 2022 at 22:58):
(The lhcforms and Telstra Health renderers both do that for the autocomplete item control type)
Last updated: Apr 12 2022 at 19:14 UTC
