I’ve committed my work to CVS for the new “list-box w/ add” feature. Give it a whirl. The files added/changed are:
interface/patient_file/summary/demographics_full.php
library/options.inc.php
library/ajax/addlistitem.php
You’ll need to edit a layout (demographics/history/referral) and make a few list boxes become “list-box w/ add”. I used the Language and User Defined lists for my testing purposes.
Then head into a patient and see if the new feature works for you. I tested it successfully on IE7 and Firefox v3.
Friggin awesome. The only thing I’d suggest is that the “list-box w/ add” gets auto sorted (alphabetized) in form instead of following the “order” entered into lists (just a minor suggestions).
I vote we make these the default for state, country, and language fields.
To keep the new "add" functionality simple I just insert the new value as the last item in the list. The on-screen list is updated with the new item and it becomes the selected item. Sorting the returned list in some other way than what is defined by the list-options could be problematic.
For example, if the default sort order becomes alphabetical then we’re ignoring the sequence defined in the admin interface to the lists. So lists like yes-no become ordered as; no, yes. This is just a trivial example but I hope it gets the point across.
For the list of States, I agree that alphabetical would be MUCH better. And perhaps it’s best all-around too. Let’s discuss it a little.
When the new list-option is saved to the database it could be inserted into the sequence in the proper location as if the list was meant to be ordered alphabetically. Then all other list-options after the newly inserted option would need their sequence numbers changed to reflect their new position after the new option.
I just put it into the form via admin->layout in the CVS demo for other users to check out for state and country. A bug I am noticing is that the widget works perfectly when editing users, but not in the create new user. Do you need to copy your js functions to this page also (if you do, I’d just put your js stuff in a .js file and then call this file after jquery call in each file; then easier to maintain).
Didn’t want to appear greedy which is why I made alphabetizing just a minor suggestion.
Again, I can easily live with what is there now (lists can be sorted by admin via traditional ordering). If somebody decides to implement alphabetization of "lists with edit", I can think of two courses of action.
1) Not listening to the ordering defined in admin->lists. Could just sort alphabetically when start control (library/options.inc.php) and when you add a new one (jquery). You’re right though, we will confuse admin, since the ordering won’t be following the order in their admin->lists. One solution would be placing a toggle with each list (just the new list w/ add) to alphabetize rather than follow the “ordering” to give admin full control.
2) Re-sort the list by alphabet via the ajax function before sending it back. Of course, then admin may have to constantly re-fix ordering, although the default toggle, which is already there can at least default to the most important option during future call.
Both not very ideal, perhaps each list needs the option of sorting by alphabetization; then would be clear.
Yes, very nice. I also noticed that it does not work in the new-patient form.
Here’s another thought. Add two more input fields: ID and Position. List items often need a unique ID that is separate from the display value - for example with states, to support billing properly it is important to use the 2-letter state abbreviation and not the full state name. Position might be a simple numeric value, or a drop-list of the current items (you select the one to insert in front of) with a couple of additional choices like “Alphabetic” and “End”.
Just noticed another bug: In the CVS demo, the patient’s state and country are not displayed in the patient summary page. I guess a bit more work is required in options.inc.php.
Rod,
Agree with ID(would call abbreviation or abbr, and make a shorter textbox to make obvious to user; if leave blank then would make ID equal to ‘title’ field in lists). I wonder if giving ordering options might get confusing for the data entry guy (not the admin). I suppose could default to “add to bottom” or something like that for the clicker that doesn’t think.
-brady
Also, regarding AJAX. Should we be putting acl checks at the top of them to ensure security (or is this overkill). For example see top of :
openemr/library/ajax/adminacl_ajax.php
I’ve said this before, but I’ll say it again. Use of this feature should be sensitive to permissions. If the user is a non-thinker or doesn’t understand what they are doing, they should not be allowed to do it.
A major purpose of a list is to reduce data entry errors. It makes no sense to just transfer those errors into the list itself.
I see this kind of problem with entering new insurance companies, which has been allowed on-the-fly for some time now. Sites end up with tons of duplicated and garbage entries. You just can’t trust the typical data entry clerk to put them in properly.
That would be great, but this will disrupt the workflow of a clinic if there isn’t an ‘admin’ around to add to the list whenever a patient from an unexpected state/country/language shows up. We need to strike a balance with the growing majority of users whom are using this software out of the box.
Out of curiosity, what happens if the user has a state in database that doesn’t exist on the list (does it force changing or list a warning?) in the demo form. We could build into the admin->list a mechanism for admin’s to have option to check all data entries in database for specific list and give simple mechanism to to fix the ones that are incorrect (doesn’t exist or title and ID not matching). So then the admin can modify the lists as see fit, and incorporate these changes into current data. Then could feel good about giving non-thinking clickers (the majority of society) the control to use this function (keep the workflow), knowing that the admin can clean things up.
Using permissions properly, you get to decide who (if anyone) is excluded from using the feature. It will work out of the box for the admin user because admin can do anything.
Items in the database that should match a list entry but do not will produce a warning. Try it out.
Hi
Why not use zipcodes and just totally simplify this. I mean, the widget IS COOL and I do see uses for it but, If we use an opensource zipcode database (and there are several) we can just do away with entering City and State. Enter a zipcode and retrieve the City and State.
We can import the zipcode db when setting up or just include the data set with the default sql file.
For international users we can import international info into the lists.
The choice to use zips or not should be globals.php
Admin user intervention only during setup and updates when required.
Good point about the admin in single user installations. I checked out the fix message, works well if editing; but the reports just display a blank. This means that somebody who upgrades to this and is not using correct state ID’s in patient_data from the lists will get blanks on all their reports (until they place in lists and hand fix them all the erroneous ones). ouch.
I think there would be a place here for an admin-list function that validated the current data set to the lists; It could simply collect all lists referenced in current layout, then query patient_data (or other appropriate places) to ensure is valid. Could list patients along with invalid data entry with a text box and provide a quick ajax button to fix it (avoiding a mass edit of patients data and the suhosin bug since this list could be long). Could also add to the list while doing this and refresh the invalids again. This would avoid above upgrade problem and give the admin a mechanism to quickly fix/tidy bad list entries by clinic workers. This mechanism could also be built upon to avoid the suhosin bug in admin->layouts.
alperezcrespo,
This would be useful regardless of where we go with the widget; build it and they will come. In setup.php install script, there is now a simple mechanism to import multiple database files so would be straightforward to get it into install script; let me know if you need direction to get setup.php to do this.
I’ve created an external INC file that can be used in different files. The new file is <oemr>/library/options_listadd.inc. It’s now being used in the demographics, new_patient, history, and referral pages.
The INC file is a mix of HTML and JS. There are comments at the top to help explain what the file is and the prerequisites for it to be used.
Jason, you have oemr.org wiki access? If not, register there (bottom right) and give me your user name. I’m starting to put developer stuff in the manual section as I do it (ie. phpgacl and phpmyadmin recent migrations); doesn’t have to be pretty, but then doesn’t get lost. Was thinking of putting a short jquery/ajax/widget page showing where we put stuff and keep pointers there to useful things things such as this file and widget. Also, then with a global picture we can figure ways to increase jquery/ajax integration (such as above list data validator and the conversion of layout tool) in an efficient way.
Jason,
I know this is your baby, but worked on this a bit. I won’t commit these changes unless you agree. It basically involved adding an abbreviation field. Did the following:
— Changed input window to:
Enter new item
Title: [text box]
Abbreviation: [text box]
[add button][cancel button]
—Made sure both the Title and abbreviation are unique before inserting into list.
—Validation, ensured not a number first and made ’ and " illegal characters for now. Your \W gave error if spaces in line. For validation, we need to realize that chinese characters are gonna be going into these fields. Perhaps we need a global validation string to start using throughout code at some point to ensure no nasties, but allows foreign characters.
If your ok with this, then I’ll commit it and place a new ‘aco’ around it called ‘listadd’ and put into the ‘adminitration’ group as default. Then we should be a go to safely place this control as default in state, country, language, and race.
If you want I can also send you a patch so you can check it over first. just let me know.
Sounds GREAT! Please let me know when you have it ready to do testing in Windows, and I’ll be happy to verify it works the same using the 3.0.1 with revised files. Please tell me which they are.
