Layout Based Visit Forms additions possible?

Day-to-Day Users
1

blankev wrote on Monday, January 04, 2010:

First some explaining info, than the question.

Since this is a product of great potential and as far as I know was developed by Rod, I hope he has enough time to give some response on my problems encountered. (Rod if you do not want/can/don’t have the time to address these observations, is there someone who is willing to respond?)

I will have to make my comments with lots of reservations since I am not a programmer, but after struggling with the LBVForms, I finally think that I can address some  of the problems I was confronted with during my explorations and they seem to be some kind of developer challenges.

1. When activation of Administration => Other => Forms => acitvate “New Form” is realized in OEMR, it gives the option to give them their own Category Name. Default is “category” or none.
2. In Encounters the new Form will be stored under category or all other handmade “New Category” Name.
3. Using “Layout-Based Visit Forms” they will show in Encounters as “Layout Based”.

This “Layout Based” is not stored in its own "form-…."SQL table or any of the existing or new Form_tables.

I tried to trace back the Layout Based forms in the MySql Tables, I think I traced them back to “layout_options” in the MySQL tables.

Now when I go to Patient/Client and start an encounter in the right hand menu the option “category”, “New Optional Category” and “Layout Based” are visible.

And finally the question:

1. Why do the Layout Based Visit Forms do not have their own form_groupname in the MySQL tables?
2. Where in OpenEMR files can the name Layout Based be traced back, so the right hand menu in This Encounter can be changed into some more meaning full Category name or have them included into “category” and create the option to sort in “category”?
3. Is it possible to make it an option to Change the name “Layout Based” into something more meaningful, or to have a proper choice in “This Encounter” frame.

An other flaw in LBVF creation was the Browser tab created during double clicking List does not close. Once the LIST Window is opened, this new window will not be closed as default, nor will it be re-addressed during the make of another new field and if you are not aware of the new open browser window it is hard to continue the use of LIST during creation of the LBVForms.

Thank for your time. I hope I was clear enough to convince anyone interested into some kind of explanation, or programming to make things a bit nicer for stupid USERS like me.

Pimm

2

sunsetsystems wrote on Monday, January 04, 2010:

1: Layout-based visit form definitions are stored in the layout_options table, and there are references to them in the “forms” table.  The data entered from visits are stored in the lbf\_data table, for all LB visit forms.  Yes this is different from other forms.

2/3: I believe you could use language translation (English to English) to change the name “Layout Based” without any programming changes at all.  But it would certainly make sense to add a feature for assigning multiple category names to LB forms.

I don’t understand what you are saying about a LIST window.

Rod 
(http://www.sunsetsystems.com/)

3

blankev wrote on Monday, January 04, 2010:

Ok, first hurdle taken. I changed Layout Based in some Dutch equivalen in the Brady Google translation document, more convenient for my setting. Tnx a lot for this easy advise. Let’s see if all related terms are changed, as might be expected in a working version of OpenEMR.

**Now for the LIST problem:**

In Administration => List => Create relevant options for the Layout Based Form.

Go to Administration => Layout

Create a group and first field. SAVE. With the first FIELD the double Click on LIST works as should. But this new LIST window is not closed after you made some choice from the LIST.

“NOW IF”, you want to add next field in the same session with click on LIST,  you get your own former included names for this fiel, but you are nor redirected to the already opened LIST browser window. It took  me much trial and many more errors till I found the already opened Window of LIST again. For consistency I want to suggest that “once you click on LIST” you are redirected to the LIST window, or you have the choice to Close an already LIST browser window and get the option to reopen the LIST browser window.

I hope this is more explanatory?

Pimm

4

blankev wrote on Monday, January 04, 2010:

I tried this Layout Based Form LIST with the OpenEMR demo versions 3.3 and I think in the past also with 3.2 on the Internet official OEMR demo versions.

When I tried it in my own web based OpenEMR version it works correct. So I don’t know if it is still an issue or not, I can understand that you did not understand my problem. But it is dubious if the demo versions are correct , or something mysterious has invaded the demos……………… ;-))

Pimm

5

blankev wrote on Monday, January 04, 2010:

Sorry for the inconvenience Version 3.3 demo also works as stipulated before………… isterious solution or just ignorance from my side.

6

sunsetsystems wrote on Monday, January 04, 2010:

For some reason the 3.2 demo seems to be broken… no Administration menu.  I was not able to see the problem you describe using the 3.3 development demo.

I will leave you with two thoughts:

1: The Layout Editor saw some important fixes in October of last year.

2: Maybe there’s still a bug that appears under certain conditions.  If you find one, make good notes as to exactly what you did.

Rod 
(http://www.sunsetsystems.com/)

7

blankev wrote on Tuesday, January 05, 2010:

Probably someone changed the Version 3.2 rights of the USER admin pass, but my experience is all should work as before after today automatic installations around 9:00 Brady time.

That is why working Version 3.1 has a built in so the User: admin pass can not be changed. The fact that everything works as before after a reinstall gives the options as full USER with all rights. But change of the Chief of Chiefs makes many parts unusable and could even block entrance completely.

Would be nice if the USER admin pass was blocked for any changes in her/his previledges……… but that’s Developers work.

P.S. A general WARNING could cause even  more mall-ware-minds to make these unwanted changes.

Pimm