Limit to number of LBF Fields?

Management and Administration
1

wizard353 wrote on Monday, August 11, 2014:

Is there a limit to the number of possible fields in an LBV form? I haven’t found any mention of such a limit in the documentation.

I’m trying to build a form for a comprehensive ophthalmic exam. It does have quite a number of fields (currently about 202 of them, with ~150 more to be added.) I prefer all of the fields to be on one level – I find that separate groups are annoying to open repeatedly.

I find now that when I add a new field in the middle of the group, that fields near the end of the group disappear entirely, or are corrupted.

For example, I have an entry near the end of the form that is supposed to have 1 label column, and 3 data columns. After adding an unrelated field to the middle of the group, I find that the “3” in the data column has been changed to a 0. I put a 3 into the field, save the form, and it comes back as a 0 again, thus corrupting the general layout of the form. I deleted and regenerated the field with the same specs, and it worked properly until I inserted another field above it in the record, at which point, the 3 changes back to a 0 on its own.

Is there a way to scrub the file of the LBV, to look for possible errors after the deletion of various fields? I wonder if some deleted items are not being fully deleted, and are thereby corrupting new entry.

I noted also that one entire field disappeared, though it was not the last in the form.

Is it possible that I have to allocate more space in the configuration?

Any suggestions will be appreciated.

Dave

2

wizard353 wrote on Monday, August 11, 2014:

Investigating the problem further, I used PHPMyAdmin to look at the entry for the LBV form field in question. I find that the datacols entry is indeed 0, when it should be 3.

I set the value to 3 with PHPMyAdmin, and verified that it was indeed set to 3. I loaded the form with the LBV “Edit Layout” command, which confirmed that the value was 3 upon loading. I just saved the form back without changing anything, and found that the datacols value was reverted to 0, which it should not be.

It would appear that there is a bug in the LBV editing code that has a working array with a too-small dimension. It is setting the datacols and titlecols to 0 if there are too many fields in the form.

Which code does the LBV Form editing?

Thanks,

Dave

3

yehster wrote on Tuesday, August 12, 2014:

You might be running in to a max_input_vars problem.
Suggest you try increasing from the default value of 1000 and see if that allows more elements to be added to your LBF.

max_input_vars integer

How many input variables may be accepted (limit is applied to $_GET, $_POST and $_COOKIE superglobal separately). Use of this directive mitigates the possibility of denial of service attacks which use hash collisions. If there are more input variables than specified by this directive, an E_WARNING is issued, and further input variables are truncated from the request.

http://php.net/manual/en/info.configuration.php#ini.max-input-vars

4

wizard353 wrote on Tuesday, August 12, 2014:

Kevin,

The value was already set to 3000, as recommended by the XAMPP installation instructions. I doubled it to 6000, and increased the memory limit from 128M to 512M for good measure. That fixed the problem. I have now add several more fields, and the values stayed the way they should be.

Is there some way to modify the LBV configuration code to throw an error or warning if it is being asked to do something with an out-of-bounds memory condition?

Thank you very much for your help.

Dave

5

yehster wrote on Wednesday, August 13, 2014:

Is there some way to modify the LBV configuration code to throw an error or warning if it is being asked to do something with an out-of-bounds memory condition?

I don’t know an easy way to do this.

The batch payments module has a similar issue in that when there are more controls in a single form than the “max_input_vars” setting, those additional controls just get ignored on the server side when the form is posted.

If you search your error log, you might find a message related to max_input_vars, but I’m not sure of the best way to report that error. There are lots of other harmless warnings in OpenEMR, and I don’t how to filter this meaningful one from the rest.

6

sunsetsystems wrote on Wednesday, August 13, 2014:

Might work to add a dummy hidden form field at the end of the form and make sure it was received before processing the other data. Would take some work to code and test.

Rod
http://www.sunsetsystems.com/

7

bradymiller wrote on Wednesday, August 13, 2014:

Hi,
Should we recommend making max_input_vars higher than our current recommendation, which is 3000 (for example, 5000 or 6000)?
-brady
OpenEMR

8

blankev wrote on Wednesday, August 13, 2014:

I don’t know if this suggestion/question is relevant. I wonder, why and what is to be registered in this LBV Form request for more.

Is it realistic to make an LBV Form with so many options?

Can we get an example of what Dr Speck is trying to accomplish? Can you give an example of what you try to accomplish with this many groups, fields forms? fsgl should understand some of the issues with this many field LBV Form.

Is there not an option of Choices, Add field etc so the total of variables, groups, and whatever can be reduced to a normal amount of options…? I can’t think of a USER scrolling down a form to make that many choices for a complete registration.

9

sunsetsystems wrote on Thursday, August 14, 2014:

Seems 3000 should be plenty for most. There must be some sort of memory overhead to the limit, otherwise there would be no need for it. Probably global settings, demographics, history and LBF are the biggest potential users of them so it would be good to build some checks into those.

Rod
http://www.sunsetsystems.com/

10

yehster wrote on Thursday, August 14, 2014:

max_input_vars is primarily a security issue not an overhead issue.

http://www.phpclasses.org/blog/post/171-PHP-Vulnerability-May-Halt-Millions-of-Servers.html

I have to admit that I don’t fully understand the implications. However, the higher the max_input_vars setting, the more quickly I believe a hash collision exploit can be found by an attacker.

11

sunsetsystems wrote on Thursday, August 14, 2014:

Interesting. Thanks Kevin. Gotta say, I’m disappointed the PHP folks think that silently ignoring input data is the right way to handle this.

Rod
http://www.sunsetsystems.com/

12

wizard353 wrote on Thursday, August 14, 2014:

Pieter,

A problem that I find is that my patient examinations often take unexpected turns as different findings appear. In ophthalmology, we deal with a rather limited number of subjective complaints – blurry vision, sore eye, red eye, sticky eye, flashing lights, trauma – that’s about all. The blurry vision may turn out to be due to corneal, lenticular, retinal, or optic nerve difficulties, to name but a few.

Previous EMR systems I have worked with require you to have already decided on a diagnosis, and selected the proper exam form before you start to record findings. However, if your exam goes off in an unexpected direction, then you have to re-enter all of your findings into a new, more appropriate form. That duplication of effort is unacceptable to me.

It is my objective to create a comprehensive exam form that will cover 95% or more of the visits I handle. I don’t mind a long form, as I’m the only one who has to enter the data, and OpenEMR is very nice about displaying only entries that have pertinent information entered into them.

I know that the current development efforts in OpenEMR are directed toward MU2 compliance. I don’t know how much development work (if any) is still ongoing with LBV forms.

As I see it, there is currently no way for one LBV form to communicate its data with another LBV form for the current encounter. It would be useful if all of the data fields of a library of LBV forms were contained in a single list, just like the lists that we can create and implement so easily in LBV forms. That way, if I enter “Corrected Vision Right Eye” into one form, then all other forms from the same encounter would show the same information if they included that field.

With this capability, if it were necessary to change forms during an encounter, all corresponding info would already be present in any other forms selected. I suspect that this would also simplify communication of patient data when interfacing with external databases as well, as the “Corrected Vision Right Eye” datum would only be present in one location, and not in several different possible locations.

I’ll have to search the fora for the preferred mechanism for requesting new OpenEMR features. I have a number of ideas that could make LBV forms more useful. Just wish my PHP programming skills were up to doing the mods myself.

Dave

13

blankev wrote on Thursday, August 14, 2014:

I see what you want to accomplish. Still not sure if it can’t be done with the LBV Forms as is.

(My text-book to learn ophthalmology was about 400 pages, so that does not give a good insight in the real ophthalmic problems you encounter. Most probably you also want to include graphis of parts of the eye etc)

There is not much work going on in LBV Forms. Most wishes till now are included, some of them well hidden, but you might have found most of them.

In my efforts to learn LBV Forms, it was a great help to take the info from the Demographic and History forms in Administration Layouts. These Dem and Hist are NOT LBV Forms, but are very similar.

Your first paragraph can be included in a List field with even the ADD option: blurry vision, sore eye, red eye, sticky eye, flashing lights, trauma, Add. Only one label and one or more options to be included.

If this is saved it can be used in another LBV Form. That other form can use the information from other LBV Forms. It can for example use the Name and ID of a person.

Groups within a Form can be hidden or shown as optional.

LBV Forms take information from the Administration -> List and these Lists can hold many options. You can also ADD Lists in the Administration List option.

So it might be usable to open many more LBV Forms with the basics of the First form etc. Please accept in advance my apologize, I could be wrong in my statement here. It has been some time since I worked with the LBV Forms.

A different approach could be the CAMOS forms. In CAMOS you can build a if-this-than that situation. Don’t know how it will show in the Patient summary. In CAMOS it is very important to understand the Pyramid situation on how to go from complaint to diagnose and treatment.