meddev wrote on Monday, April 01, 2013:
I’ve read about LBF forms that does not really fit our needs.
I’ve found the /contrib/forms and /interface/forms directories and info on the Forms API http://open-emr.org/wiki/index.php/The_Forms_API but I’m not clear on how to actually use a form in /contrib/forms. Is it a manual process of coping the files to the /interface/forms?
Do you have to register the form someplace?
Are there docs on how to do this anywhere?
bgregg wrote on Monday, April 01, 2013:
meddev,
Absolutely correct on the process, only missing a few steps:
#1 - Copy desired forms from /contrib/forms, then move those to /interface/forms/
#2 - Pull up OpenEMR and go to Administration > Other > Forms
#3 - Scroll to the bottom area titled Unregister, and click Register the forms you moved
#4 - Enable, Assign Category, then click Update
Brad Gregg
MI-Squared
sunsetsystems wrote on Tuesday, April 02, 2013:
In case you’re not aware, custom client- or server-side code can be written as plug-ins for layout based forms to make them more flexible than you might think. See sites/default/LBF/ for some examples.
meddev wrote on Tuesday, April 02, 2013:
Thanks Brad, that was exactly what I needed to get the contrib forms working.
Thanks Rod, I did not see those plug-ins, I looked at the samples but I don’t see where those plugins can be tied
to LBF form. Are there any docs are could you give me a brief rundown?
I created a new LBF form and expected to see maybe a data type of plugin but did not. Is this some type of manual process also?
sunsetsystems wrote on Tuesday, April 02, 2013:
The plugin is a PHP script named <formname>.plugin.php and should reside in the LBF directory of the site-specific directory (e.g. sites/default/LBF). If it exists there then it will be automatically invoked when the form is used.
There’s no documentation yet but I think looking at the example sites/default/LBF/LBFgcac.plugin.php will show a programmer pretty nicely what needs to be done. And of course I can answer questions.
meddev wrote on Tuesday, April 02, 2013:
I must be missing something.
I took a look at the scripts in sites/default/LBF and they seem simple, but not sure how they tie to a form? In your example there should be a form named LBFgcac someplace that would invoke the script correct? I do not find that form name in the places I looked. Or does LBFgcac need to be created someplace to use the script?
sunsetsystems wrote on Tuesday, April 02, 2013:
The LBFgcac form is rather complex but you can find the SQL to load it in sql/ippf_layout.sql. I don’t recommend loading it; was rather just referring you to its plugin as a coding example.
Anyway the plugin is tied to the form via its script filename and the names of the functions in that file.
meddev wrote on Tuesday, April 02, 2013:
Ok, I think I understand. The install process consists of manual step of loading the proper data to the tables: list_options, layout_options, codes, globals, etc using the .sql file. Then the new form appears under forms for use?
I’m guessing there are no installed forms that use these types of plugins?
mdsupport wrote on Tuesday, April 02, 2013:
Rod, do you have any ideas on handling changes to the layout of LBFs over time? Since there is no versioning, changes to the existing layout alter display / prints of past records.
Storing LBF data in Couchdb will be an ideal solution…
tmccormi wrote on Tuesday, April 02, 2013:
I don’t know anything about couchdb, please explain how just using couchdb instead of mysql would change this issue? Does couchdb have built in record level version management in which it save both the record and the scheme version?
Tony
www.mi-squared.com / @MI2_OpenEMR
oemr.org / @OEMR_org
sunsetsystems wrote on Tuesday, April 02, 2013:
Ok, I think I understand. The install process consists of manual step of loading the proper data to the tables: list_options, layout_options, codes, globals, etc using the .sql file. Then the new form appears under forms for use? I’m guessing there are no installed forms that use these types of plugins?
That’s all correct. But don’t run the ippf_layout.sql because it will load a bunch of other stuff that you don’t want.
Rod, do you have any ideas on handling changes to the layout of LBFs over time? Since there is no versioning, changes to the existing layout alter display / prints of past records.
You might maintain the layouts as SQL files like the one you just looked at, then you could use a version control system like git or subversion for those as well as the associated plugins.
mdsupport wrote on Tuesday, April 02, 2013:
Tony, couchdb needs to supplement the current setup after an encounter is signed off. Since couchdb does not expect ‘layout’ or schema, it will accept data from LBF as :
[label value] : [data value1] ...[data value n]
If the layout is changed 2 months later and that item (label - data pair) is deleted, in couchdb we will continue to see the entry as found at the time of create / modify. We can think of several mySQL based solutions to handle such situations - Rod already suggested one. But that is added coding complexity.
BTW, this issue is not unique to LBF but with other forms, at least the developer can consider the implications of the changes. With LBF, because of ease of use, ‘admins’ are tempted to make radical changes without considering the full implications. At the same time, for insurance, malpractice and pure historical reasons our physicians are looking for encounter to be equivalent of a page from the old charts that remained unchanged after they signed off.
meddev wrote on Wednesday, April 03, 2013:
Rod and All: thanks for the input, helps a lot.
Is anyone working on any type of WYSIWYG editor for forms or does anything like that exist? I’ve done quite a bit
of work in this area and could have something working fairly quickly if it’s not already in the works. Could possibly address the versioning issue with forms as well.
tmccormi wrote on Wednesday, April 03, 2013:
No one (to my knowledge) is working on a WYSIWYG forms tool. I’ve seen a few that I like out there, but none in the that were open source. It would be a really good thing…. 
Tony
www.mi-squared.com / @MI2_OpenEMR
oemr.org / @OEMR_org
sunsetsystems wrote on Wednesday, April 03, 2013:
WYSIWYG for forms would be very nice, as long as the tools used are GPL-compatible and it’s otherwise consistent with OpenEMR philosophy. What sort of approach did you have in mind?
meddev wrote on Wednesday, April 03, 2013:
All this WYSIWYG code is my own and I’d have no problem with releasing it under GPL. The editor allows you to drag and drop objects from a palette of types. The types initially would be the same as those now supported by LBF forms. The editor creates a file that is used by a run-time to display the form and interact with the user, save changes, etc. I’ll need to review the LBF forms code more but I think it’s doable on the surface. The positioning of the objects is all relative within the DIV container so you can build some nice looking forms.
We will be converting one client to OpenEMR from our custom EMR and having this tool would help since we use that code in the existing product. I also have several other clients that will more than likely be converted this year so it makes some sense. As I have time and after I get further into OpenEMR I’ll strip out our code and setup a simple demo.
sunsetsystems wrote on Wednesday, April 03, 2013:
You might search the code for “layout_options” and “options.inc.php” to get a feel for the extent of impact of those changes.
juggernautsei wrote on Wednesday, April 03, 2013:
Rod,
Where does one find the layout_options?
sunsetsystems wrote on Wednesday, April 03, 2013:
layout_options is the table in the database that contains the layout definition details. library/options.inc.php is a PHP module that contains several common functions that work with layouts. Chances are very good that any code relating to layouts references one of these.