Demographics Improvement, User Interface

OpenEMR Development
1

deschel wrote on Monday, July 30, 2012:

We are trying to come up for a design of the user interface for the demographic project.

My initial plan was to use as much of the existing framework as possible-i.e. use Administration->Layouts->Demographics to define how items are displayed.

However, this does not support multiple tables within one layout (ex. for the demographics layout, all data is from one table, patient_data).

We came up with a way to address this - each tab in the demographic display would represent a different table.  If the table has a one to many relationship with patient, then we would just display a repeating list (but still use the format defined in Layouts->Demographics.)  Then add a button for “Add” to add another many record.

However, we have a problem doing this when it comes to having the one to many tables for first name and last name.  It would not be practical or appropriate for us to put these in their own tab.  They need to be in the “Who” tab.  However, if we
have them in the who tab as a list, it will mess up the Layout defined in “Layouts->Demographics”.

How important is it to keep “Layouts->Demographics”?  Any ideas how we can address this issue and still keep the current display system?

David Eschelbacher MD

2

deschel wrote on Monday, July 30, 2012:

BRADY’S RESPONSE:

Very important to not “lose” functionality (ie. get rid of things like layouts->demographics unless replace it with another mechanism that allows the same amount of flexibility/customization) and ensure the upgrade stream is not broken.

There are times where I have actually spent more time ensuring functionality is kept and the upgrade process is smooth than the time it took to code the actual feature.

Although I still don’t have a very clear idea of how your going to reach your goal, my instincts are telling me that you are going to go way over budget here; but I’d suggest asking the pros in the conference call what their thoughts on the man hours to accomplish your goals.

-brady

3

deschel wrote on Monday, July 30, 2012:

Reading the posts on the User Forum under the thread “New/Search-Summary -> Patient problem” really concerns me.

Link to thread: 
http://sourceforge.net/projects/openemr/forums/forum/202505/topic/5408069

“Administration->Layouts” does not just change the layouts, but it changes the database tables. 

If so, then the word “Layouts” is misleading. 

Additionally, giving the “Layouts” section the power to change the database tables is dangerous. 

Every GUI that I have seen for database systems, separates the screens that change layouts from the screens that change the database.  Imagine what would happen if someone creates a report with crystal reports that changes the database.  This would be crazy!

I feel strongly that there should be a separation between changing the layout and changing the database.

The tools to change the database should stay in “Administration->Other->Database”.  To make the layout screen more user friendly, you can add a link in the layout screen to the database modification screen.

Can we please remove the ability for users to make database changes from “Administration->Layouts”? 

I think the above thread is a good illustration for the reason why this separation should be made.  Someone should be able to delete the field from the layout without deleting it from the database.  Intuitively, deleting from the “Layouts” screen should change the layout and not the database.  However, the layout screen is not intuitive, and it deletes it from the database. 

Sorry to offend, but this is completely outrageous. 

The layout customization should just effect the layout, not the database.  If someone does not want to use a field, they can just delete it from the layout.  The field should still exist in the database after this deletion (there is really no need to delete the table field) and the user should be able to add the field back later if they change their mind. 

This would alleviate the risk of users messing up the database by modifying the layout.  And, also eliminate the need to back up the database prior to layout changes.

I feel that this separation is very important:

“Administration->Other->Database” for database changes.

“Administration->Layouts” for layout changes.

David Eschelbacher MD

4

deschel wrote on Monday, July 30, 2012:

You are going to force me to work with the existing framework, which I am not crazy about! 

To re-do the interface while keeping the same customization functionality is too work intensive for me at this point.

Therefore, I will keep the current interface and improve it to support more sophisticated tables and relationships.

To keep the customization functionality and make it compatible with my new table structure, I will probably have to do the following changes to “Administration->Layouts”:

(1)
Disable the ability to make database changes via the layouts engine.  Layouts should be for layouts.

(2) 
Add another display column to the web page called “Table”, so that people can specify/see the source table the data that is displayed is coming from.   This should have been part of the initial design.

For example, I think that it is crazy that for layout called “Demographics” there is nothing that specifies that the source table is “patient_data”.

I also think it is crazy that any one can type anything into “ID”.  What happens if there is no column name that corresponds to “ID”?  Why even allow this?  If “ID” should correspond to a table field, you need to only allow the person to select the table field.

(3) 
Change the name of the display column called “ID” to represent what it really is: “Table Field Name”.  (Unless I am wrong about what “ID” actually represents.  Please let me know either way, if I am right or wrong.) 

By doing changes 1 & 2, one “Group” will support displaying data from multiple tables. And, these tables will be clear to the user.

(4) 
Since “Table” and “Table Field Name” have to refer to already existing tables, they should be drop down menus, rather than text boxes.

(5) 
Add another functionality called “SubGroup”, so that one to many table relationships can be supported and their display can be customized. 

The subgroup will represent the table with the many relationship. 

The subgroup would be displayed as a repeater within the group, in order to display a list.

(6) 
The subgroup would be referenced in the group by adding a selection under data type called “Subgroup”. 

If subgroup is selected then “Table Field” will be made blank, ?or be changed to a drop down menu of subroups? 

(7) 
Subgroups should probably be listed on the same webpage as groups. 

Should they be listed just below the group that they apply to or at the very bottom of the page?

I expect a strong reaction to my suggestions. 

I feel that they are well thought out and necessary.  However, I do expect resistance to change and improvement.

Unfortunately, I feel that to be able to use my Demographic Table Improvements, these changes are the only way to do it.  The only other way would be to throw out using layouts to display demographics.

If you disagree with my changes, give me a better route with strong justification and rationale.

David Eschelbacher MD

5

deschel wrote on Monday, July 30, 2012:

BRADY’S RESPONSE:

Please feel free to move this discussion (and copy/paste whatever you want from my emails) to sourceforge, since there are other players that should be involved.

I don’t think you are going to get much traction in removing the Layouts engine (or not allowing new database entries from
it).

About 2-3 years ago, I did a rather large code walk-thru to internationalize the code and I also initially became frustrated with
the layouts engine, however, after spending the time to learn the ins and outs of it, I realized how powerful it is; especially for
international users and multi-lingual clinics.

Many of the posts on sourceforge from users give the appearance that this feature is being used rather frequently to customize things.

Note that it sends data to the patient_data, history_data, transactions, employer data, facility_user_ids (note this is actually a vertical table) and lbf_data (also a vertical table) tables; the decision of where to go is decided in the codebase; to get an appreciation for the module, will be important to look through the code a bit.

Regarding your plan, lets see if can get it discussed on sourceforge, because is important to also have others weigh in (especially Rod, since he is the father of the layouts engine).

It still seems like it will require a much larger amount of man hours than you have budgeted to integrate your demographic database changes with the current codebase and layouts engine. I am very curious to hear others thoughts on this.

-brady

6

sunsetsystems wrote on Monday, July 30, 2012:

I agree that the layouts administration tool should not have the ability to alter the database schema.  This is one reason that the lbf_data table exists.  Also I’ve seen too many cases of people accidentally deleting a field and breaking things as a result.  However the person who added that feature may have a different opinion, perhaps they’d like to chime in here.

Similarly, instead of having the tool working directly with tables, I think a better growth path is to have it work with a thoughtfully-designed underlying PHP object model.  I suspect this would provide the opportunity to add a great deal of flexibility and to give the administrator a much nicer tool to work with.  They shouldn’t have to care about the physical database structure.

Rod
www.sunsetsystems.com

7

deschel wrote on Monday, July 30, 2012:

I’m surprised about your agreement with removing the ability to alter the database schema.  The way Brady was talking, I was expecting you to be adamantly against this.

Please elaborate further about :  “have it work with a thoughtfully-designed underlying PHP object model.”

I’m not sure I understand what you mean when you say this.  Also, please provide examples if possible.

-david

8

mcaloon wrote on Monday, July 30, 2012:

Rod,.
    The idea of an underlying php model is a good one. At a high level, the model probably has a meta-data component that feeds a query and rendering component. A user might pick objects from the meta layer,
which would have some query capability (TBD) :slight_smile: then a rendering phase. Ideally, we could leverage code from the existing. LBF implementation …

Mac

9

sunsetsystems wrote on Monday, July 30, 2012:

David, I don’t have much more to offer right now as this is an analysis-and-design effort that I don’t currently have backing for.  But a PHP object model would be the answer to the question “what are the ‘things’ that OpenEMR users care about and what should their attributes and methods be?”.  This may or may not correspond closely to the database schema, but in any case should provide a layer of abstraction to the database.

For example there might be a “Form” class.  Instantiating that class with arguments “Vitals” and objects representing a patient and visit passed to the constructor might give you a new instance of a Vitals form.  The caller/user should have no interest in the fact that the patient_data, form_encounter, forms, form_vitals, lbf_data, layout_options, list_options or other tables are involved.  There should probably be methods to enumerate and give more information about the form’s attributes.  I’m not saying that is the right model, just throwing it out there as an example.

Rod
www.sunsetsystems.com

10

sunsetsystems wrote on Monday, July 30, 2012:

Just to clarify: the object model I’m talking about would not do any user interfacing, but would give UI code the information that it needs.

Rod
www.sunsetsystems.com

11

bradymiller wrote on Tuesday, July 31, 2012:

Hi,

Looking through the code, it looks like cfapress added the feature to drop database columns when removing it whom is no longer active in the project. Sounds like David is on the right track. An additional thought is to create a table patient_data_custom (a vertical table), which can hold new elements that are created in the demographics layout (then no need to create/remove database columns in patient_data when customizing this) and avoid the confusion of needing to add and remove sql columns. Note the Layout->Facility Specific User Information works in this fashion.

-brady
OpenEMR