zhhealthcare wrote on Friday, October 28, 2011:
Currently all forms created in the LBF route goes into the same table. We have changed this in our version of OpenEMR so that each from created under LBF creates a new table much like the xml generated forms.
We were wondering if this would be something that is acceptable to the community so that we can contribute the code.
Thanks and regard
Shameem
sunsetsystems wrote on Friday, October 28, 2011:
Shameem, what is the purpose/advantage of doing that?
zhhealthcare wrote on Friday, October 28, 2011:
Rod
More manageable. Some doctors have several forms with a lot of fields. managing it and querying info is a nightmare.
Shameem
tmccormi wrote on Friday, October 28, 2011:
I believe that would be a great enhancement. It provides a more intuitive developer experience for enhancements, I think.
I have some changes the merge the LBF and standard forms menus so that the can share one pick list and be sorted together. What I have works. But I think the LBF forms should be integrated into the Admon->Forms so they can be handled by the same model, allowing for ‘enable/disable’ and sorting. Then the Pt Reports display order could follow the Dr’s preferred form priority/sequence.
Tony
www.mi-squared.com / @tonymi2
oemr.org / @OEMR_org
sunsetsystems wrote on Friday, October 28, 2011:
Regarding the single table, I guess I need an example of how it’s a nightmare. Perhaps I could offer a suggestion or two, seeing as how I did give it some serious thought before designing it that way. 
zhhealthcare wrote on Friday, October 28, 2011:
As a corollory to that, we also have made a couple of enhancements in the forms page where you can a) sort the forms in the way the doctors want to see it, and b) we can choose if we want to have one form entered only once in an encounter or more. In other words, there is only one fee sheet per encounter, a similar concept with any other forms also.
We would like to contribute these as well.
Regards
Shameem
zhhealthcare wrote on Friday, October 28, 2011:
I am not able to articulate it more than what I have, probably Tony would do it in much better way. My experience has been that there ends up being 100s of field in one table. This is not manageable.
Is there any benefit for keeping it in one table?
Regards
Shameem
sunsetsystems wrote on Friday, October 28, 2011:
The advantage of one table are that it’s simpler and easier to work with in all respects: database management, programming and user interface. It only has 3 columns, not hundreds. So I’m just confused at this point which is why I think an example would be helpful.
I like the user interface changes that you are describing, it will be great if you can put that up on github for review.
Thanks,
bradymiller wrote on Friday, October 28, 2011:
Hi,
As Shameem eludes to, would be better to get the technical concerns here (performance issues etc.); looking at the involved tables, appears the indexes should avoid performance issue no matter the number of entries, but I could be wrong.
Offhand, the benefit to one table is the simplicity of it, especially in regards to upgrading and functions that manage the forms. Note, that Tony’s thoughts above on features can be done with the current database footprint intact (ie. the “What you see” does not need to be the same as “What it is stored as”).
Above are just my quick thoughts; after hearing what the technical issues are, others, including myself, will be able to give a much better opinion as to whether this makes sense or not.
-brady