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…
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.
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.
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
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.