Custom fields in patient demographics do not update

Management and Administration
#1

Hi there,

First, Many thanks for the program and all your hard work. I have used it for two+ years in a veterinary practice (lots of work went into customizing it, but it works for our furry, feathery and scaly patients). I could always solve any problems with documentation and forum but now I have not found any solution for this one:

I added fields in the demographic screen with the layout editor. Until version 4.x it went without problem. But since I upgraded to 5.0 the custom fields are added to the patient_data table ok, and shown in the layout. However, I can type in what I want, it never gets saved in the added fields (the standard fields work ok). When I manually type in values in the database fields with phpmyadmin (the fields are there) the data is accepted. No errors. But the data is never displayed in the patient demo screen.
I have reinstalled two times, but to no avail. Always the same problem. No idea where to look. Can anyone help?
I use Linux Mint 18.3 and OpenEMR 5.0.3. Latest patch does not help.

#2

hi @roland ,

I figured OpenEMR was likely being used in the veterinary practice settings and it’s really cool to hear it is getting real use. This would be a great success story entry if you’re interested(just let us know and we’ll get this going):
http://www.open-emr.org/wiki/index.php/OpenEMR_Success_Stories

Regarding the layout problems, are you able to reproduce this issue on the following demo? :
(the Main Demo)
http://www.open-emr.org/wiki/index.php/OpenEMR_Demo

-brady

#3

Hi Brady,

thanks for the fast reply. I’ll be happy to share the story when it is ready. Right now I am still using it as a double, it is not introduced yet into the clinic, but I want to do that in february next year, after adding 1.dental forms (from cats and dogs to camels etc) 2.getting the Veterinary Nomenclature codes to work (we don’t like ICD9/10 although we have plenty of ICD jokes pinned on the walls) 3. finetuning the Guardian/Location concept (most of our Guardians have 1 or 2 patients, but some have 100+ at different locations), and 4. some work on the Insurance claims since these are a little different…
So still some work to do. This issue has kept me busy for 1.5 days, but I can’t solve it, I am no developer…
I’ll try to reproduce it on your demo
thanks
-roland

#4

Hi Brady,

yes I could reproduce the problem, but I cannot see into the database if and where the custom fields were added. I added three extra fields in the employer Tab, these do not display any data I typed in, tried twice to enter data but it stays empty. And i added a custom field in the Stats tab, that works ok. I am lost because in the earlier versions this did not happen.

#5

Hi Roland,

Couldn’t able to reproduce the issue in demo instance. We used the demo instance link shared by Brady. https://six.openemr.io/openemr/interface/login/login.php?site=default
We tested by creating three fields in Employer tab. We can able to edit/save the content.
Fields which we have used are test_field1,test_field2,test_field3 in Employer tab.
You can examine the database by getting into Administration->Other->Database
Can you please check again and if you again found the issue, can you please pen down the steps or share the screenshot to analyze further.

Thanks,
ViSolve

#6

Hi Visolve,

thanks for your time. Yes, I did it again (blush), I can reproduce the error, I also used the demo link shared by Brady. When I tried it the first phpmyadmin was disabled so I couldn’t check the database. But now it works: here is what I did and found:

  • I created 4 new fields with the layout-editor.
  • After refreshing the patient demographics screen I get: Internal error: Attempt to change patient data with pid = ‘’ when current pid is ‘1’ for id ‘’
  • All fields are created in the patient_data table ok, but only 2 of them work as expected.
  • The ones named “testfield_x” work allright, the field “em_hou_descript” and “em_hou_hazards” do not; they do not update when I type in a value, the value is not saved in patient_data. Then I typed in a value directly in the patient_data table through phpmyadmin, in the “em_hou_descript field” but it is not shown in the patient record. I have attached a screenshot.

Maybe there is a naming convention for new fields that I am unaware of. I used two underscores, but there are many fields in the patient_data table that use more than one underscore, so that can’t be the problem. The length of the name maybe? I don’t know. Or maybe new employer fields cannot start with em_ ??
Please let me know.
We use this in a veterinary clinic where we like to think of the farmer/stable owner/herdsman as the “employer” of the milk giving/riding/transporting animal patients. Therefore we have added many custom fields to the employer tab to describe the state of the animal housing/sanitation/“employment”, so if possible we’d like to keep the naming of all our extra fields.
Can you locate the problem?
Sorry for the lenghty answer
Thanks,
Roland

Screenshot from 2017-09-04 12-54-14
Screenshot from 2017-09-04 12-54-141920×1200 372 KB

#7

O,and maybe it’s good to know that we did not have this problem in 4.2.2
R

#8

@roland,

YES, we could locate the problem. Thanks for this lengthy message, that helped.

In general adding a field in Dempgraphics layout will create a new coloum in patient_data table. But, while saving the data, the fileds prefixed with “em_” will be saved in separate table employer_data and not in patient_data. This is how the current code works in OpenEMR.
Hence the values for the field names that you created with “em_” are not saved in patient_data table. These values are posted to employer_data table.

Thanks,
ViSolve

#9

Hi Visolve,
Thanks, I already suspected it was a naming problem. However; if you prefix a new field with “em_” the field is created in the patients_data table, but then the demographics form tries to write data entered to the employer table, and not the patient_data table.
That’s why it didn’t work. We were trying to update from 4.2.2 to 5.0 and in the process renamed some fields from "em*** " to "em_*** " for better readability… So just renaming the fields to something else solved the problem. :smile:
Thanks for pointing that out. Once the 5.0 runs reliably we’ll introduce it into the vet clinic.

Roland

#10

Glad you got this working :slightly_smiling_face:

Thanks,
ViSolve OpenEMR Support Team