Multiple prescriptions per page -- checked in

tekknogenius wrote on Thursday, August 03, 2006:

I just checked in some changes:
1. Added ability to add multiple prescriptions per page and revamped the prescription printout in general. I left the old format there, in the event anyone still wanted to use that.
2. Added ability to automatically add the prescription to the medication list
3. Added the hour to the event display (was currently only showing the minute)

I think that was all I changed…here are the affected files…

<openemr root>/sql/database.sql
<openemr root>/sql/2_8_1-to-2_8_2_upgrade.sql
<openemr root>/controllers/C_Prescription.class.php
<openemr root>/libarary/classes/Prescription.class.php
<openemr root>/templates/prescription/general_edit.html
<openemr root>/templates/prescription/general_list.html
<openemr root>/interface/pic/Rx.png
<openemr root>/interface/patient_file/summary/add_edit_issue.php
<openemr root>/interface/main/calendar/modules/PostCalendar/pntemplates/default/views/week/default.html
<openemr root>/interface/main/calendar/modules/PostCalendar/pntemplates/default/views/day/default.html

markleeds wrote on Saturday, August 05, 2006:

I was looking into the workings of the existing prescription interface in hopes of adding a CAMOS embedded function to insert into the prescriptions table.  This would give me the ability to enter prescriptions via CAMOS and still use the new format for printing prescriptions.  I came across something that is disturbing.

I noticed that some fields in the prescriptions table are INT values.  Particularly form, unit, route, interval, and substitute.  I initially assumed that these were foreign keys relating this table to one or more other tables containing these values.

It turns out that these values are hard coded into Prescription.class.php.  The problem I see is that even if a user does regular database backups, if someone in the future maliciously or accidentally changes the values in this file, when the user upgrades, there will be potentially serious alterations to patient prescription data.  Of course, by keeping a backup of the old version of OpenEMR, this can be fixed.  Still, foreign keys should point to other tables, not arrays in php files.

I am not going to mess with it, but I thought I should bring it up so either it can be fixed or at least we can all agree never to touch these arrays.

This could lead to problems such as printing records for a legal case and finding that all of your levothyroxine prescriptions are suddenly in mg instead of mcg throughout every patient file.

I don’t store my prescriptions this way, but I’m sure that some users do use the old prescription interface.

sunsetsystems wrote on Saturday, August 05, 2006:

I don’t much care for the way that was done either, but I think we can live with it for a while.  Obviously it would be very bad to modify the existing array entries, but it should be OK to add new ones as needed.

As long as the code interface is properly encapsulated, you can use it while leaving the door open to improving the database schema later.

Rod
www.sunsetsystems.com

tekknogenius wrote on Sunday, August 06, 2006:

Unfortunately, alot of OpenEMR has non-standard programming practices. I, for one, would prefer to keep more data in the database. There isn’t at the moment a “lookup” table, which would take care of a bunch of this kind of stuff. It would also make multilingual support much easier.

Any way, I first wanted to get the change in OpenEMR, because my wife had been asking for it for a long while. In a later addition I’ll create the lookup table and begin changing the code accordingly.

Here’s my ideafor the lookup table and translation table to go along with it

openemr_lookups
  id
  type
  code

opener_lookups_xl
  openemr_lookup_id
  language
  meaning

andres_paglayan wrote on Monday, August 07, 2006:

Hey,
there’s already a translation table and a function that does translate,
check the documentation under interface/language/lang.info.html

tekknogenius wrote on Monday, August 07, 2006:

This was just an example. I have not made any changes yet. I’ll do my best to incorporate any changes into existing functionality so as not to duplicate any work for myself.