Tooltip in encounters.php

system · July 29, 2009, 6:16pm

bradymiller wrote on Wednesday, July 29, 2009:

hey,

I’m proposing we remove this. This tooltip bypasses report.php and lists data directly from database, which is really ugly; also is likely taxing performance when the list is long. Plus, you really don’t need to have access to entire note on a listing (I’ve never encountered this behavior in the emr’s I’ve used). If we really want to have this functionality then should collect the data via report.php, but my opinion is that this wouldn’t be worth the effort.

Can I remove it?

-brady

system · July 29, 2009, 7:23pm

drbowen wrote on Wednesday, July 29, 2009:

This "feature" has been causing a severe hit on performance in our practice. Every time we call "encounters.php" there is a substantial delay for the screen coming up. New patients with a just a few encounters are not a problem. The patients who have lots and lots of visits take 40-50 seconds. "Encounters.php" appears to be running 6-8 queries to do its job. The tooltip has to read all the characters in 150,000 pages of text and this ends up taking awhile. Then at the end of the "encounters.php" the routine starts listing all the text again at the bottom of the page.

During the office visit the patient almost invariable rambles back and forth between the problem at hand to asking about their medications causing the practitioner to ramble back and forth between the Problem lists to the "encounters.php" each time taking a performance hit on each return to "encounters.php".

Please get rid of this.

The current "encounters.php" only shows the username of the medical assistant who started the encounter. What we need to know is the username of the practitioner who entered the data into the form for the encounter.

This "encounters.php" definitely needs some tuning up for performance.

Thanks Brady.

Sam Bowen

system · July 29, 2009, 8:20pm

cfapress wrote on Wednesday, July 29, 2009:

I shall make it go away. For good.

Jason

system · July 29, 2009, 9:22pm

sunsetsystems wrote on Wednesday, July 29, 2009:

I’m pretty sure I put that in at the request of a client. Not sure if they still want it. Why don’t you leave the code there, either commented out or disabled by default. Just in case. Thanks.

Rod
www.sunsetsystems.com

system · August 8, 2009, 5:24pm

rayaz wrote on Saturday, August 08, 2009:

Could we please make it user selectable? I really like this feature and use it regularly to refresh my memory without opening the encounter itself which opens the encounter but without any indication about the date of the encounter.

system · August 8, 2009, 7:42pm

bradymiller wrote on Saturday, August 08, 2009:

hey,
If make selectable, would be better to overhaul this thing and not read directly from the database, but have it read from the report.php for each note.
-brady

system · August 9, 2009, 3:26pm

drbowen wrote on Sunday, August 09, 2009:

I repeat this causes a VERY SEVERE impact on performance after you get 6 years of visits and 150,000 encounters in your database.

The date is available in the old encounter. It is in the very far right hand corner of the page. I missed this for several months-years perhaps because I use a small lap top for a lot of my work.

Also it it very quick to go to the Report section first, click the last three reports and take a quick look. i do this all the time myself.

My usual routine before entering the room is check to the last note(s) to see if any tests are outstanding. I review the medication list, the family and social history, and look at all the tests that are recieved since the last visit.

This also gives me the opportunity to ask my clerical staff to get a report faxed over to the office if one is available but not yet received.

Sam Bowen, MD

system · August 13, 2009, 1:12pm

jwallace00 wrote on Thursday, August 13, 2009:

Hey Brady, thanks for the patch to remove those tool tips. We’re seeing a noticeable improvement in load time.

There is still a several second wait from start to finish loading on the page. Right now I think it’s passable but as the years build up, I’m sure the time will increase. I was thinking it would be more efficient to pull 10-20 records at a time and page the results instead of pulling all the records for a given patient to construct a complete history on the initial page.

Thanks again for the help!

system · August 14, 2009, 4:59pm

cfapress wrote on Friday, August 14, 2009:

Jeremy,

Yes, pagination would help speed up the load time considerably. Or, another solution, is to list the 10 most recent records and provide a button to append the next 10, and the next 10, and the next 10… etc.

This could be accomplished with AJAX calls. jQuery has been part of OpenEMR for a while and would make this UI behavior reasonably seamless.

Jason

system · August 14, 2009, 6:32pm

jwallace00 wrote on Friday, August 14, 2009:

Thanks for the suggestion Jason. I think I’ll take a crack at it for our installation.

system · December 20, 2009, 1:23am

mike-h30 wrote on Sunday, December 20, 2009:

Brady,

Where is the patch to remove the tool tip feature? I am currently running 3.0.1 and have not upgraded to 3.1.0 yet, but I do want to remove this feature. I tried swapping in the 3.1.0 version of the file /interface/patient_file/history/encounters.php but that did not work. Am I missing some more updated files?

Thanks.

-Mike

system · December 20, 2009, 1:30am

bradymiller wrote on Sunday, December 20, 2009:

Mike,

this should do it:

-brady
: http://openemr.cvs.sourceforge.net/viewvc/openemr/openemr/interface/patient_file/history/encounters.php?r1=1.40&r2=1.41&view=patch

system · December 20, 2009, 4:21am

mike-h30 wrote on Sunday, December 20, 2009:

How do I insert that code as a patch? Do I manually have to comment out lines of code from my current version (3.0.1) of interface/patient_file/history/encounters.php?

I thought the 3.1.0 version of interface/patient_file/history/encounters.php contained the code changes. However, replacing my 3.0.1 version of interface/patient_file/history/encounters.php with the 3.1.0 version ( from 08/29/09) does not work 100%. After doing so the encounters do not load properly ( only one encounter loads).

system · December 20, 2009, 11:19am

bradymiller wrote on Sunday, December 20, 2009:

hey,

If using linux, save it as file (patchFile) to your openemr directory and try command:

patch interface/patient_file/history/encounters.php < patchFile

This patch should only make the changes to your file that eliminate the tooltip(ensure it says merge was successful),

If using windows, then I’d suggest just manually changing it.

(as an aside, there were lots of changes to this file form 3.0.1 to 3.1.0 so simply copying the new one will not work, as you have already discovered)

-brady

system · December 20, 2009, 11:21am

bradymiller wrote on Sunday, December 20, 2009:

hey,

Also, before you do the patch, make sure you have the original 3.0.1 file back in place.

-brady

system · December 20, 2009, 4:49pm

mike-h30 wrote on Sunday, December 20, 2009:

I am running Linux (SLES10-SP3). The patch failed and created this “reject” file that contained this code. Perhaps I should updgrade to 3.1.0 ?

***************
*** 338,344 ****
                  else continue;

                  /* build the potentially HUGE tooltip used by ttshow */
-                 $title = “”;
                  if ($enc != ‘physical_exam’ && substr($enc,0,3) != ‘LBF’) {
                      $frow = sqlQuery(“select * from form_” . $enc .
                                      " where id = " . $enc);
– 338,347 —
                  else continue;

                  /* build the potentially HUGE tooltip used by ttshow */
+                 $title = “View Encounter”;
+                 /*
+                  * COMMENTED out the tooltip because of poor database performance - JRM
+                  *
                  if ($enc != ‘physical_exam’ && substr($enc,0,3) != ‘LBF’) {
                      $frow = sqlQuery(“select * from form_” . $enc .
                                      " where id = " . $enc);

system · December 20, 2009, 6:40pm

bradymiller wrote on Sunday, December 20, 2009:

hey,

What do you see in the main file at that region now (after the patch)?

Upgrading to 3.1.0 is always a good idea, but disabling tooltips should be doable without it.

-brady

system · December 21, 2009, 4:01pm

mike-h30 wrote on Monday, December 21, 2009:

Brady,

I did not get a chance to check the main file as I immediately reverted back to the original file because after the patch, when I entered a patient chart, no encounters loaded. All that was visible was the frame background color.

system · December 22, 2009, 5:53am

bradymiller wrote on Tuesday, December 22, 2009:

hey,

I’d recommend just making the changes manually from the patch file, since patching isn’t working easily.

-brady

system · December 24, 2009, 7:46pm

mike-h30 wrote on Thursday, December 24, 2009:

Ok, I got it to work by manually editing the file. It turns out the problem was this “echo xl_form_title($enc).” I had to leave it as “echo $enc”. I am not sure when “xl_form_title” came into play.

Anyways, I discovered with the tool tip gone, the encounter load speed has really not improved. A patient with quite a long list of encounters still takes about 8 seconds to load.

Perhaps Jason’s suggestion might be the better solution for improving encounter load speed:

"pagination would help speed up the load time considerably. Or, another solution, is to list the 10 most recent records and provide a button to append the next 10, and the next 10, and the next 10…. etc.

This could be accomplished with AJAX calls. jQuery has been part of OpenEMR for a while and would make this UI behavior reasonably seamless. "

-Mike