Visit Category menu issues

avantsys wrote on Tuesday, September 04, 2012:

Hello everyone. We’ve noticed that the visit category menu in the form that a user sees when s/he creates a new encounter for a patient is not edited in the same way as other menus in the OpenEMR system. This causes some problems, for instance:

1. It is not easy to remove categories from the menu in case a certain specialty doesn’t need them (especially without affecting other clinics’ databases).
2. The “Reserved” value is also used in the calendar, as an event category.

I’ll put aside the fact that the term “Reserved” in Greek makes no sense to our clients. What exactly is the reasoning behind using the same term in two entirely different contexts? An event that a doctor plans (lunch, out of office etc) has to do only with whether s/he will be in the office or not, if s/he will be available or not and what type of activity s/he has planned. An encounter with a patient falls - at least for our clients - within the following categories: (a) encounter for which the doctor gets paid by the patient’s insurance or social security, (b) encounter for which the doctor gets paid by the patient, © office visit, (d) out of office visit. These are the four kinds of encounters our clients have, well, encountered in their careers and that’s what they’re asking for.

When we tried to edit the menu in the aforementioned new encounter form, we found out it affected other menus as well, because the items in it were also used elsewhere, in different contexts.

This is a design issue that has to be addressed in future versions. Each kind of object (menu, form, etc) needs to be editable in EXACTLY the same manner all across OpenEMR. The way OpenEMR is designed, editing clinical forms is not straightforward (don’t even get me started on the Graphic Pain Map, for instance, or the Vitals and their completely closed source Flash graph engine).

Konstantinos
AvantSys Informatics

bradymiller wrote on Wednesday, September 05, 2012:

Hi Konstantinos,

Reserved for a provider could mean they have an hour scheduled in clinic for a drug rep etc. I agree the Reserved category in encounters makes little sense.

I agree we should not be using hard-coding of id’s of appt in the encounter screen also, meaning:

<?php
 $cres = sqlStatement("SELECT pc_catid, pc_catname " .
  "FROM openemr_postcalendar_categories ORDER BY pc_catname");
 while ($crow = sqlFetchArray($cres)) {
  $catid = $crow['pc_catid'];
  if ($catid < 9 && $catid != 5) continue;
  echo "       <option value='$catid'";
  if ($viewmode && $crow['pc_catid'] == $result['pc_catid']) echo " selected";
  echo ">" . xl_appt_category($crow['pc_catname']) . "</option>\n";
 }
?>

This would be much neater is instead just collected the categories from that query where the `pc_cattype` is equal to zero (this would not show the Reserved category and instead would show same categories as appt Patient categories). Note the pc_cattype flag is set when editing the appointment categories at Administration->Categories(Type selector where can choose Patient or Provider).

Since you brought it up, any movement on  your open source graphing solution?

-brady

avantsys wrote on Thursday, September 06, 2012:

We’ve implemented it for the LBF forms, but it doesn’t work all that well with Firefox. With Google Chrome, (almost) everything’s A-OK. We haven’t been able to replace the Flash graphs on the Vitals form. It handles graphing in an entirely different manner and it’s a pain.

Konstantinos
AvantSys Informatics

blankev wrote on Thursday, September 06, 2012:

As far as I remember there were two different Developers interested in both graphic options. That is all I can give you as explanation for changing the graphs.

I remember an extensive forum discussion on Growth graphics and changing the different graphs.

Do a search an you might be lucky, it was about three years ago.

blankev wrote on Thursday, September 06, 2012:

It seems that you succeded. Why not send an explanation that we can use to make a WIKI page on Graphic changes and inclusion for specialists?

I am willing to do the copy paste work and might be able to give a reasonable summary…

Let me know, Pimm

avantsys wrote on Thursday, September 06, 2012:

I had uploaded the entire source code we produced for our HTML5 graphing implementation on my own storage space on Rapidshare. I’ll make my own repository and I’ll put it there as well. Don’t hesitate to contact me in private if you want the link for Rapidshare. Be aware that, for the time being, while it is functional, Firefox is not 100% compatible with the HTML5 instructions used for it and we’re still perfecting it.

Konstantinos
AvantSys Informatics