Prescription Size Data Type

anonymous wrote on Wednesday, September 26, 2012:

Our practice has just made the switch over to printed prescriptions and we noticed that some of our prescriptions are omitting the medicine units field (AKA “size”). After some troubleshooting I discovered that anything other than numeric values were being rejected by the database. Turns out the data type for this particular row is set to “float”. This creates a problem for medications such as Percocet 10/325, Norco 10/325, Lortab 10/325 and Lortab 10/500.

I was able to get a desired result by changing the data type to varchar(11) and editing the following functions in /library/classes/Prescription.class.php

    function set_size($size) {
    	$this->size = $size;
    }
    function get_size() {
        return $this->size;
    }
    /*function set_size($size) {
        if (is_numeric($size)) { $this->size = $size; }
    }
    function get_size() {
        return $this->size;
    }*/

This was done on a test server, as I want to be cautious before applying changes on the production end. What are your thoughts on this? Is this a safe fix, or should I be wary of these functions being called elsewhere?

mcaloon wrote on Wednesday, September 26, 2012:

Hey McGillicutty,
    It’s probably a good thing to check where the float was being used elsewhere in the code with any math type calculations. Those would be a problem and you’d need to fix those areas to avoid any exceptions. Better yet, it seems like the appearance of 10/325 may have originally misinterpreted as a mathmetical quotient which it doesn’t appear to be. :slight_smile: Is it actually qty/size? It seems as though we’d want a numeric units column somewhere to track the dispensed amounts for clinical and inventory analysis in future reports. Maybe the fix stores the numeric values and the code that prints does the right thing on the formattin side.  I’m not on my system right now so I haven’t looked over the code yet.

Mac

anonymous wrote on Wednesday, September 26, 2012:

The two separate units represent dosage of each medicine in the tablet. From what I understand, the second number represents the dose of acetaminophen. I believe Lortab is the only one that can be prescribed in two different doses (10/325 and 10/500).

Wouldn’t it make sense for this to be a static value? For instance, if a report of total prescriptions of Lortab 10/325 is calculated, the dosage would not be summed, only the number of unique prescriptions and quantity dispensed. Perhaps I’m being short-sighted though. That’s why I wanted to consult those more familiar with the codebase. :slight_smile:

anonymous wrote on Monday, November 26, 2012:

Finally managed to upgrade to 4.1.1 with the most recent patch and made this change to our production server. I want to revisit this and see if it is agreeable to contribute the change to the main codebase. Any objections?

anonymous wrote on Tuesday, January 22, 2013:

Hi all,

Just enabled the drug inventory to make prescribing more convenient for our doctor and found that there is another “size” value located in the “drugs” table. After switching the data type to varchar(11), I’ve run into a new problem. When adding a new prescription using a template with a dose of 30/300 (Tylenol-Codeine),the size is displayed as 0.1. It seems the the value entered in my template is being treated as a numerical expression, which doesn’t happen when the size is entered manually.

At this point, I feel that I’m getting too ambitious with my lack of coding skills. I’d like to sponsor a fix to this issue. Anyone familiar with the prescription module want to take a crack at it?

bradymiller wrote on Wednesday, January 23, 2013:

Hi mcgillcutty,
I just want to make sure you got some interest in finding a developer to sponsor; if not, then there is a list of Professional OpenEMR Developers that I can point you towards.
-brady
OpenEMR

kodusote wrote on Thursday, February 21, 2013:

Dear mcgillcutty,

We have simply changed the data type for the size field in drug table in the database using PhpMyAdmin without editing the Prescritption class code and we have not had any issues with it.  You may try that until you can afford a Professional Developer to help revise the code.

Kayode