Dangerous Bug! In LBF forms

OpenEMR Development
#1

Hi all, Today we found a dangerous bug which is related to the LBF’s. This was found in 500 so I am unsure if this was fixed in 501. I think this is the right place to post this, but here goes:

In modifying an LBF a user created a column called ‘date’. Then, in deleting the column after deciding it wasn’t wanted it deleted the date column in the history_data table. Unfortunately, the date column is used in several queries and it shut down use of OpenEMR.

Two things:
As a fix I recreated a date column. In my copy on my localhost, date can be NULL. This seems to work. Does anyone see potential issues by keeping the values NULL?

In the LBF’s there should be some data entry validation that 1) prevents the elimination of a column or 2) naming a column after an existing column. mySQL doesn’t allow it, but we shouldn’t even be able to get to the point where mySQL is throwing an error. Maybe we can just make it impossible to delete a column?

Thoughts?

#2

Hm, interesting situation; definitely an issue we should addresss. My initial guess is we should not allow certain fields to be deleted. I’ll have a better idea after I jump into the code and do some testing.

#3

Hi Robert, you’re right. This is a little complained about but important flaw in LBF’s for our core base forms. Namely, there are many places in code where certain patient_data columns are hard coded, patient finder comes to mind. The problem mostly is that most users don’t realize that the ID column in LBF editor is the actual column name in patient data table. So if they change the label to something else they may think they also need to change the ID as well. This will cause the existing table column to be renamed causing who knows what issues down the road.
Solution may be to make our default LBF forms items ID, read only and not allow deletes on any item in form that has a read only ID. They may still change the Label’s to their liking.
Hope this helps.

#4

Personally, I think the LBF creation process can be confusing and prone for errors. If anything, the instructions could be improved as well. I don’t really have a well thought out solution, but maybe this is something we can discuss in the community. I have a few ideas such as a GUI interface and better form validation. Maybe we can start a thread that is dedicated to improving this tool?

#5

Our LBF feature is such a powerful feature, but yes, the UI could use some TLC

#6

I’d be very wary of messing with many, many user’s beloved LBF! It is the quickest way to allow non programmers an option to created practice specific encounter forms. Nothing wrong with improving U.I but first doing some validation updating is prudent and would address the issue at hand. Mainly restricting table modification to our core default forms i.e Demographics, Insurance, History and Transactions. Adding to these forms is not a problem but we get in trouble allowing changes to table columns of these expected core fields.
I did the last major update to LBF so, somebody else can take this on.

#7

I am assuming that this bug was never fixed. (I just learned that the hard way).
Can we write a warning such that people don’t rename fields in forms they are using to see patients in a production server?

Something like:
“Warning, to avoid loss of data, once you start using a form in actual patients DO NOT modify the fields in a given form.”

Sandra

#8

hi @gutiersa, it’s def important to get it fixed and then wouldn’t need a warning, will start an issue to see if one of the LBF experts can pick it up.

1 Like
#9

As pointed out below, simple and brute approach is to allow only addition of fields and setting existing fields to unused/hide for any layout record that does not start with LB*. If we must permit a backdoor edit, trigger if off a form property that must be added manually - e.g. allowFullEdit=true.

* By using ‘list’ to define layout, the developer created compound key - never a good design choice.

#10

Actually, I found my data, it is still there, in the tables. I think it is a matter of remapping the form.

My problem later on, will be that my hash are going to be ******-up.

Don’t know how to handle that

#11

To be honest, I think that once the document/progress note is signed, The form should not be what is used to call back the image.
For example, the complete signed progress note ought to be one field. Say:

{<S: this is the documented information><O: blahblahblah><A/p: yada yada yada>codes:xxxxxx<singed by dr so and so, on 5/3/2021 14:00:00>}

Including all the html tags. At this point the note ought to be unlinked from the form. In other words the form is a tool to generate a document. Upon completion the info which belongs in the note is considered an html document.

I believe this is how the EHR from my previous employer worked. Or something similar. Of course, the document would need a way to get addendums added on at the end.
In fact, once you have one way of printing to screen the signed progress note, then you can use it for all progress notes.

Sandra

#12

I figured it out, I had changed the “field_id” of my form in layout_options table.
I did that when I renamed the field because I noticed I had an error (I labeled it O, but it was my subjective section). Perhaps if the field_id gets locked, similar to the form_id? Alternatively, the field_id can be tied to a numeric fid that cannot be changed.

The good news is that data is not lost, but this is still a problem.

1 Like
#13

thanks to @sunsetsystems, the code now prevents renaming sensitive fields

1 Like
#14

This is excellent.
Just to document things appropriately, for when I finally get to update the wiki, administrators will be able to rename an LBF field ID if they wish, without unmapping the data?

NB: the mapping starts with table layout_group_properties

I am sorry, that I cannot read the code as well as I wish.

#15

Regarding the user interface for LBF, here is my $0.02:

  1. I would love to see a button that allows me to copy a field such that I can duplicate it without having to do all the button clicking. (by this I mean creating a field one at a time)
  2. I would love it if when creating a new form the initial group was already created, with some default field.
  3. If some data types already have spacing needs, then add those needs automatically, and don’t ask the user to input them, because some of us are clueless about it.
  4. Allow me to duplicate a form. For example, in pain management and in psychiatry, there is the use of patient questionnaires. If I create one questionnaire, then allow me to save it as a template and use that template to create the others.
  5. Once I create the LBF questionnaires, I would like to create a form in the patient portal which includes two LBF. Currently this does not work. It would be a nice feature or fix.

If anyone is willing to work on the code on this, let me know and I will put more thought into this. I can add images of how I created some of the questionnaires. Furthermore, some are pretty standard such as the PH9 and I would like to add it as a contribution, but don’t know how.

Sorry if I am asking too much, but this is my way of documenting my experience with OpenEMR.

1 Like
#16

all this does is prevent renaming of these specified fields in the layout gui, so not even an admin can do it through that screen

1 Like