Not certain which section to post this in… but here goes.
I note that there are several ways by which custom forms can be created - LBF, NationNotes (which appear to be somehow related to LBFs), formscript and XML. Additionally, there are several sample forms included in the OpenEMR distribution that I could probably adapt to my purposes. One difference that I have noted is that the LBF-based approach appears to store absolutely everything in the lbf_data table, which I would think would get quite awkward when things get larger, whereas the others (formscript?) appear to make their own additional tables.
My questions are these. Is one approach superior to another? Is it simply a matter of what makes it easier for any given user to produce an end-result form? If one solution is better, why is it so? Are some of these approaches currently considered deprecated, and if so why?
I don’t mind investing the effort to make my own forms but I’d at least like to make certain that they’ll hold up through future generations of the program.
LBF gives the most flexibility if you need simple data input / view / report capability. So power users can design their own forms without need for developers. As you correctly noted, lbf_data also constrains wider use of that data in other areas. There is a plug-in provision which requires good developer skills. In that case standard development becomes more attractive. We have also experimented with couple of alternatives to lbf_data.
Wider adoption of this project will depend on its ability to let small/mid size practices tailor the records to their needs. User generated forms will go a long way towards that end. So if you have some funds to commit, there was someone else working on enhancing the LBFs in this thread.
Other approaches are template/framework driven requiring developers. Each has its own pros and cons depending on existing developer skillsets.
MySQL is quite good at indexing big tables, and I’ve not heard any cases of LBF being slow in that regard. It also has some efficiency in that form fields with no data are not stored at all, whereas with “horizontal” tables there is overhead for each field instance, used or not.
Canned reporting tools may have some trouble with the approach, but programming the queries is not difficult or awkward. Just different.