OpenEMR Review at ehr.gplmedicine.org

OpenEMR Development
1

drbowen wrote on Tuesday, May 02, 2006:

I was checking out the posts at openhelth and came on an interesting post by Fred Trotter.  LinuxMedNews has a EHR review.  Fred apparently wrote the reviews and was kinder to our project than he has been in the past in these forums.

http://ehr.gplmedicine.org/index.php/OpenEMR_Review

He makes some very valid criticisms of our installation process that have bugged me for awhile.  I noticed from other installations including XOOPS, PostNuke and other similar PHP MySQL architectures that this problems can and should be ironed out. 

The easiest is to create a notice in the setup routine that the first login password is always "pass" regardless of the user.

A better solution would be to have the initial installer to supply a more secure password.

A slicker solution would be to have a random password generated and notify the installer that this would be the initial password. 

Also, couldn’t have the setup routine create the required files after asking the asking the installer to change the permissions to allow apache to write to the important directories?

Here are a few quotes:
______________

The next screen was filled with very dense instructions. I needed to create two directories and then change the ownership of those directories to the webserver user. It also told me that to use the document storage features that you needed to similarly change the ownership of the documents directory and make some adjustments to the php.ini file. The instructions also refered me to various configuration files and the GACL setup system. At the bottom of the page there is a link to the newly installed system.

I had chosen the superuser account to be called admin. After trying to login with a password of, "admin", "password" the value I entered for the db password, "demo", and "test", I gave up and did a google search for the default password for OpenEMR. Apparently, it is "pass".

After logging in for the first time, I recieved the following error on the main screen.

Warning: Smarty error: problem creating directory "modules/PostCalendar/pntemplates/compiled/%%164/%%1643473877" in /var/www/html/openemr/interface/main/calendar/modules/PostCalendar/pnincludes/Smarty/Smarty.class.php on line 589

Warning: Smarty error: problem writing ‘modules/PostCalendar/pntemplates/compiled/%%164/%%1643473877/default.html.php.’ in /var/www/html/openemr/interface/main/calendar/modules/PostCalendar/pnincludes/Smarty/Smarty.class.php on line 589

I used the following command to change the ownership so that these templates could be created…

chown nobody:nobody openemr/modules/PostCalendar/pntemplates/compiled/

After doing this, the calendar on the main screen came up and the initial installation was complete.

______________

At first blush the OpenEMR was very powerful. The basic database creation and information gathering works quite well, with the notable exception of using a default password, and what is worse, not documenting it (in) the setup procedure. Also, most of the complex configuration is left till after the installation, not by configuring inside the OpenEMR GUI, but rather by editing text files. For what the wizard did cover, however, it was very smooth and clear.

Also, there was an uncaught file permission error on the installation. It is possible to verify that important files have proper permissions, so this sort of error should not occur.

As for security, the creation of a seperate database user for just openemr is excellent. Forcing a strong password for that user is also excellent. Insisting on an default password, however, is not such a good idea. There was no option that I could find to restrict installation to a particular IP address. Overall…

    * Catching Errors - Poor (required me to understand a file permissions error)
    * Ease of installation - Good (lots of configuration was handled without editing text files)
    * Security - OK (Would have been excellent ex(cep)t for the default password and the lack of IP security)
______________

Why does OpenEMR allow us to change the Patient number?

Well, to allow old paper systems to be brought into concurrence with the new EHR.  I use this feature daily in my practice.

Thanks, for the nice and fair review Fred.

Sam Bowen, MD

2

markleeds wrote on Wednesday, May 03, 2006:

I agree with the installation criticisms also.  I guess we are all used to it and put up with it. 

Since I have started using OpenEMR in practice, I find myself only working on things that are directly beneficial to my own practice due to time constraints. 

One practical benefit to fixing the installation would be easier testing.  I sometimes put off doing a fresh install to test the latest changes because I don’t feel like going through the routine.  It should be automated.

One major addition I would like to see would be a pda interface so I can log in with my treo 700w phone.  I hope to find time to at least put together a scaled down interface to parts of the database that would work from a pda browser.  This would have immediate practical use for me because I have internet access on the phone everywhere and I am always on call.

Whoever did the document upload section, it’s great.  I use it all the time now.  Little by little, we are going completely paperless.

3

synseer wrote on Tuesday, May 09, 2006:

Sam,
      I am glad that you thought I was fair. It was and is my intention to call attention to different technical solutions, rather than call attention to a "winner".

      I will be copying over this discussion over to  the review discussion section for openEMR. Everyone seems to want to use thier own forum.

Generally the problem with changing a patient id is that you might have created several pointers to that id. For instance. You might have Thing 1, Thing 2 and Vitals 300 all pointing to Patient id 5. Like so

Thing 1 -> Patient 5
Thing 2 -----^   ^
Vitals 300 ------|

Then if you change the id of patient 5 all of those data points are left hanging. A better way to do this is to map patient ids, which cannot be changed to old system ids.

Thing 1 -> Patient 5 -----> Legacy Patient 4000
Thing 2 -----^   ^
Vitals 300 ------|

This retains the data integrity in OpenEMR but allows it to track other IDs. This is how MirrorMed handles it. I am not sure what FreeMED does.

Regards,
-FT

4

drbowen wrote on Tuesday, May 09, 2006:

"I will be copying over this discussion over to the review discussion section for openEMR. Everyone seems to want to use thier own forum."

I posted here because most of the readers in this forum don’t yet know about your new site.  I in general agree with your review.  I intended to post on ehr.gplmedicine.org separately assuming that it has a different audience.

I have set a script that tranfers my patient IDs out of my billng system to OpenEMR so that PID is the same in both systems. This happens without human interferance so that the PIDs are not changed after initial creation.

I think we might discussing slightly different issues.  I am referring to the ability of assigning a PID to a new patient based on my need to coordinate the two systems.

You’re discussing the ability to change the PID to something else after the initial creation of the patient.  I agree that this is a significant problem.  Fortunately, I am the only one in my office that has the technical expertise to screw up this badly (I think).

I am still dealing with the issue that "the old legacy ideas" are not static but growing in real time.  I think of this as a temporary solution until I can switch over to a new billing engine.

Sam Bowen, MD

5

markleeds wrote on Tuesday, May 09, 2006:

Fred:

Couldn’t updating the pid throughout the database be easily scripted?

You run through every table and do something like:

UPDATE tablename SET pid=newpid WHERE pid=oldpid

6

sunsetsystems wrote on Tuesday, May 09, 2006:

For what it’s worth…

The table of patients in OpenEMR has both a "pid", which is an invariant ID, and a "pubpid" which can be anything chosen by the user.  The pubpid is commonly what is used to store patient IDs from a legacy system such as paper charts.  The pid is what is used to identify the patient internally within OpenEMR, and is not normally assignable by users.

– Rod
www.sunsetsystems.com

7

synseer wrote on Thursday, May 11, 2006:

All,
       I realized what Rod just pointed out and I have already removed any reference to the issue from the review…

-FT