Multi-column lists

OpenEMR Development
1

wizard353 wrote on Monday, August 19, 2013:

I’m new to OpenEMR, but I’ve been programming since 1971, so I hope there isn’t already a way to do this that I may have missed. I really like the ability to easily create and implement custom lists, but they can deliver only a single column of output data.

It seems it would be handy to have custom lists with multiple result columns, e. g., for patients’ employers, so the employer’s name, address, city, state, zip, phone number, and Worker’s compensation carrier could all be filled in just by selecting the employer’s name, rather than typing the same info repeatedly for all 500 of my GE employees.

Could functionality like this be added to OpenEMR?

Thanks,

David D. Speck MD

2

blankev wrote on Monday, August 19, 2013:

David,

if I get your question correct, the way to go is LBV-Forms. In LBV you can have many columns I did a try and delivered a form with 10 Columns. Label and Field.

I am in the trial and error phase, but the WIKI-page on LBV-Forms is nice for guidance. If you did find how to implement your goals, please give your efforts in writing so it can be included in the WIKI pages.

For easy New Implementers the WIKI needs more specifics than is included now.

3

fsgl wrote on Monday, August 19, 2013:

An alternative is to create a second Employer group for General Electric, Layouts-> Demographics, and use Static Texts for each of the Fields.

4

deschel wrote on Monday, August 19, 2013:

I am working on a project that addresses this and many other issues – Demographics Improvement Project.

My project overhauls the demographics table. Basically, converting one table to . I will be normalizing a lot of the tables, creating one to many and many to many relationships.

Go to the following link for an overview:
https://sourceforge.net/p/openemr/discussion/202506/thread/02d39134/

My project and design has evolved a little since that post, but that post gives you an idea.

Addresses, Employers, Businesses, Secondary contacts will be stored in separate tables also sharing tables for shared info.

For example, one street address will be stored only once. Linked to by a business (like a physician office or home health agency), person, employer, secondary contact, referral source, etc. Basically once an address is added, it can be selected by multiple patients, businesses, etc. If you pull up an address, you can look at all the entities that use it.

I am currently working on the interface. Basically, you start typing in the address and it does a live search for addresses that match. If no addresses match, then you add the address. Typing in the street number narrows the search quickly. So, if the address is already in the database, you can find it with a few keystrokes, and select it from a short list.

This type of functionality will be used for multiple types of data, not just addresses.

For example, all people (patients, secondary contacts, etc) will be stored in the same table, just like all businesses will be in the same table. If a person is a secondary contact, and you want to add them as a patient, start typing name, live search finds it, and you select from list.

Database tables are finished.
Conversion scripts 80% finished.
Interface design about 60% finished.

I’m hoping to have working demo of interface with live search in next couple of months, and maybe project finished in 4-6 month time range.

I consider this a major upgrade that will address a lot of problems, and that no commercial emr does either.

I’m working on it mostly myself at this time.

I would love some help if you or anyone else is interested.

David Eschelbahcer, MD

It is the demographic