Customize demographics fields

Day-to-Day Users
#1

Hi Folks-
Just posted to the wiki a modernization and expansion of a trick last published in the forum (though never before in the wiki) in 2013.
A lot of people have asked over the years how to add a custom field to Demographics and it’s pretty easy. And if you do it right you can store the data in the database and it can be made a searchable column in the Patient Finder.
Have fun!

  • Harley

https://www.open-emr.org/wiki/index.php/HOWTO:_Customize_A_Demographics_User_Defined_Field

2 Likes
#2

Wiki should advise users against using any genericxxx fields. These were probably introduced before this layout had the ability to maintain fields as columns of patient_data table. Now that any new column can be added/maintained dynamically, it is good practice to assign meaningful names to all custom fields rather than using genericxxx columns with altered descriptions.

Hopefully a future edition will simply drop these columns for all new installations. Also an upgrade should drop these columns if they are empty.

#3

@mdsupport, are you certain there is nowhere in the codebase that relies on those genericxxx columns existing? I agree would be better if they weren’t there, but removing those preset columns could create great havoc if they are necessary somewhere.

#4

There are very few layout columns that are required in code. I believe those are only in our patient create.
In newer versions of OpenEMR there are reserved layout columns that can’t be deleted in the layout builder.
The problem is and always has been when dealing with patient data table is legacy data. otherwise that table would’ve been split apart into relationships a long time ago.
Not saying it’s not possible that we require an extensive upgrade mechanism.
If you’re like me I don’t like table columns that don’t servie specific purpose.

1 Like
#5
  1. Last time I looked a couple of genericxxx fields were in one or two scripts - something that can be fixed easily.
  2. Dropping columns can be conditional - if all records have blanks.
  3. More importantly if these columns are made redundant by feature to create custom columns as needed, we should eliminate them from future installations. That will limit these columns to legacy installations only.
  4. In a large record such as patient_data, keeping these increases record size issues - specially for innodb engine - without adding any value.

Anyway, did not mean to hijack @htuck’s post. Sorry.

#6

Hi @mdsupport
That’s ok, all this is good stuff to discuss. And if it ends up that those fields can’t be used after all, I’ll simply delete the wiki page!

My experience coding in Commodore Basic and VB5 :slight_smile: does help me understand a lot of dev-oriented issues but I tend to look at things from the medically trained user’s point of view. User- defined fields that can be used as these are are a VERY common need to make an OpenEMR instance serve a practice’s peculiar needs so I hope they don’t disappear without being replaced by something that provides the same user- accessible capabilities.
Best- HT

1 Like
#7

Concerning number three I’m pretty sure I’ve done my share of resolving the undesirable aspects of OpenEMR.
I think that remark was unnecessary but that’s just me

#8

Hope revision to #3 makes the intent clearer. Touchy :wink: