While the form builder is nice, my concentration would be to integrate the form rendering and disposal which is all json based and could pretty closely follow current template workflow. i.e shouldn’t be too difficult to integrate.
I especially like the ability to overlay input/elements on top of pdfs, images and is a completely javascript project licensed under MIT. Also a very mature, highly rated project.
The builder is customizable for additions specific to openemr where users can use a builder we embed or numerous online sources to build forms. The key here being, forms are transportable as json objects.
My wheels are already spinning on how this can be integrated however, I thought I’d put this out there so perhaps someone could burst my bubble!
The tool looks fine… and it would make developing, and managing, forms a lot easier.
Caveat… your previous suggestion that you see the direction of portal being an API backend for a frontend somewhere else (paraphrased, with possible errors.) would be more ‘important’ to me, if you asked (and you did not)
That way, the forms, etc, would be in the domain of another, possibly, many frontend platforms.
Whatever direction you take - keep at it. Your work in invaluable…
Hi @censon Simon,
Thanks for the encouragement.
I have to put considerable thought into what’s next for portal. For now though, all of us administrators priority is ONC testing. Once done, we’ll get together to make a plan that makes sense to fit into OpenEMRs future lifecycle. That’s one of the reasons it is important to think through when we bring in additional dependencies such as the Formio.js project or developing our own(I haven’t yet dismissed this idea).
From all the feedback I’ve received on the portal over the last 5 years, the number one feature of import is patient documents with appointment and secure mail closely behind.
While the current way we build forms for the portal is not too bad and can serve most use cases, I’m finding that folks like mental health and pain management require far more capabilities such as long adaptive type questionnaires. Also forms need to be better managed on disposal besides simply charting to documents. Such as recording form data in a way that would make collected data better available for analytics and possibly CDR. So documents is high priority IMO.
Awhile back, my thoughts for the portal was it would eventually be replaced with apps interfacing through API. I now don’t think we replace but still develop the API.
I have also thought about making the portal a custom module however, I now think we’ll add better support for other custom modules to interface with portal instead. Generally using strategic event dispatching. I’ve heard rumors of some doing this now.
In the end I’m hoping I get other developers to help out so we can do another major portal release when we release v7.0.0 as our ONC/MU3 release. I may be able to get the form builder in for v6.1.0 in a few weeks. To this end, I plan on doing a campaign for sponsor money so I can hire some additional developers to help see this through.