Problem is, in the long run it’s unsatisfactory to use a text box where a list is more appropriate. It’s reasonable for a user to notice that a list has inappropriate values for his situation, and to find out where that list is and change it (and setup.php can point this out as a followup configuration step). But it’s not so reasonable to expect a user to know that he could have changed a text box to a list, much less know how to do that. Maybe they’ll figure it out eventually, but by then the site will have a mess of data entry inconsistencies to clean up.
As for the suhosin bug, it certainly needs to be addressed but that’s a whole 'nother matter. We can’t just throw away layout administration because of it, and discarding lists is no answer either.
I think over time it’s reasonable to build up a collection of various SQL files as one-step setups for various localities or types of usage. See sql/ippf_layout.sql for an example of this, where the special layouts, lists and service codes specific to IPPF sites were all put into one place.
My reasoning here is that openemr should be a functional turn key solution from the beginning, which is why we’ve been focusing on the turn-key installation releases. As we make installation easier the sophistication of users will drop dramatically (now more than half of our downloads are for the windows/xampp package). The things that have been sending up red flags to me for awhile have been the required provider box and the unfinished state/country lists. To me, the state/country mechanism is an unfinished project and we are asking the new user to finish it for us. OpenEMR is not even functional unless a user figures out the list/layouts (no documentation) and types in their lists for state/country. Developers have discussed solutions, but this issue has remained unchanged for some time. Simply adding all states will not be enough as openemr will begin getting more international use. To me, this is just unacceptable to have something this minor get in the way of openemr truly being turn-key. The simplest solution in this case is to remove the state/country list function, unless a developer integrates a functional easy to use mechanism here.
The above is just my opinion. I’m not gonna make any changes to the code unless the community overwhelmingly agrees with it.
1) If we add a section to the Users Guide covering critical Lists right up front AND provide an SQL file with the 50 states and or territories as needed that could be optionally loaded by the admin via the pma_bookmark we will cover both issues. Both of those are easy. Same for countries.
2) Thanks for the info on the new patient entry layout, if that’s the way it works then I all for it and we’ll update the docs next round to include that.
3) PhpMyAdmin and Lists … so then how do you add new immunizations to the issues pulldown? Maybe just documentation is needed.
Still doesn’t pass the turn-key test, in my mind at least.
Your suggestion makes me wonder though. How difficult would it be to put an “add” link to the right of the list-box that threw out a pop-up to simply add to the list. Then after they type in their new entry on the pop-up and hit complete on the pop-up it inserts into database and also refreshes/sorts the item in the form (Since this is all done in one page, I think would require a javascript/jquery pop-up to allow direct changing of the viewed list thru DOM and an ajax call to place the item in the list database.). We could give a different UOP to this mechanism; call “editable list” or something so anybody can add to it (and not effect the other list that require more admin security). Then we have our own custom openemr widget. If none of the regular developers can work on this, it would be a good project for a new developer to work on since it doesn’t seem to require a great knowledge of openemr’s insides (Tony, have you gotten any offers for help by developers).
Brady said: Still doesn’t pass the turn-key test, in my mind at least.
I think it does. They have to setup the clinic, users and some other basic things in order to run the software. Adding a few steps to pick you state, etc is not a big deal as long as it’s documented.
I do think that having ADD buttons readily available for end users on lists is a good thing. Most lists are not critical, some are. But that is where we, vendors, can add real value helping the customer go beyond the simple, ordinary tasks.
I have gotten offers, but no commitments. The startup curve is high, I’ve been trying to point developers to areas that are non-invasive, like reporting and QA to start with.
I still think it doesn’t. (sorry, couldn’t help myself)
Turn key means it is functional on login. I’m using the perspective of a single person downloading this thing via one of the one-step install/configure packages(ubuntu or xampp-windows) and logging in. At this point, they will likely want to begin entering real patients info (perhaps just to see how things work etc) along with entering encounters/note to test it out; and right now the only stopping this from being straightforward is the current awkward listing mechanism for the state/country. It’s just sad to think this will cause a proportion of these potential openemr users to then drag/drop openemr to their recycle bin.
Obviously making it a text box isn’t going to be an option here. I’m guessing a widget is then in order, which can then also be used in other similar circumstances.
Proposal (I’m actually afraid to do this, because then I always end up spending the time to develop it) This would be similar to the admin->acl page, but much simpler since only one function.:
1) Create an ajax php listAdd function/file in openemr/library/ajax/, which simply adds an entry to list (if doesn’t yet exist), and then returns the new list sorted.
2) Place a jquery ajax function on the form page, which is linked to a click on the ‘add’ link/button. This function sends a pop-up to collect the new entry and send via ajax to number 1. It then takes the returned data to re-populate the list on the form sheet via the DOM.
3) Create another UOP item called listBoxEdit and only difference from listbox is that it
places and ‘add’ link/button to right of the list.
Allow anybody with edit privileges to the demograph to use this function (hence no admin needed to add states/countries (what does front desk do if somebody drops in their clinic who just flew in from paris, france??)
Then the circle is complete, and we have a cool widget which eliminates all of these state/country problems, and can be used by users for other list in their forms if desired.
Wouldn’t zip code look ups for the U.S and Text/Widgets Boxes for International be simpler? For the US we could use zip codes and pull up City/Town and State information. For everyone else use text boxes or they could setup lists (as in Lists and layouts) if tech-abled.
This could be a globals.php option (zipcodes= true)
For the US this would reduce Data Entry errors.
For International they could use Lists and Layouts to Reduce Data Entry Errors.
Or anyone could uses the Text/Widget boxes to add this data.
I think that the provider field needs to be handled a little bit better. If it is required, do not allow the user to leave the screen until completed. If not Required then fine, leave.
Default to the Text/Widget
Default to no Provider required.
Finally, what happens when we have patients with the same name? Do we still have to search first and then pick or add?
In Puerto Rico (and many other latin countries) two last names are used. A name is set up as follows: First Middle Paternal Maternal. A name could be Juan Pedro Sanchez Rivera. As complex as this may seem and the probabilty of two people having the same name is minimal, I have a site that within the same town three people have exactly the same full name (first, middle and both paternal and maternal).
I believe that when a patient is first created (First and Last Name) we should be listed probable matches. We then have the option of selecting off the list or (somewhere on the screen) select create the patient.
Lookups that rely on outside services are not viable in many. many locations. No internet or very poor internet. So zip code databases won’t meet the need as cool as it would be as a optional feature.
I do think that so kind of "probable duplicate" lookup for patient names, etc would be good but it would have to show at least DOB and perhaps address info for confirmation to be useful.
For version 3.0.1 as it is currently packaged the only solution is documentation for the list issue. For subsequent releases other possibilities can be applied and are endless
I’ll bite. Tomorrow (May 8th) I have some time set aside for OpenEMR development and will take on the AJAX widget-thing-a-ma-bob. It shouldn’t take the whole day (famous last words) and I’ll work on another AJAX feature too, patient name dupe-checking.
HI
I would not have suggested using an external search. In fact it should be more like the drug/prescription lookup where we import the FDA database and use that.
