Immunizaton Dosage

mdsupport wrote on Monday, September 30, 2013:

Current design of Immunizations functionality supports only integer dosage (field amount_administered). When clinicians enter 0.5 mL in the online form, application rounds it up to 1 mL which is a major error. Worse yet, if the amount is 0.25 mL (e.g. children’s dose for a flu shot), the entry is rounded down and no amount is shown.

Obvious workaround to address this problem is to use units smaller than mL and set up full integer as dosage. This can cause issues with some interfaces that do not handle unit conversions well. If you wish to avoid these issues, set up database to support fractional dosage numbers. The SQL needed to enable this functionality is :

– Caution : This backup table should be in addition to full backup –
ALTER TABLE openemr.immunizations
ADD amount_administered_int INT(11) AFTER amount_administered;
UPDATE immunizations SET amount_administered_int = amount_administered;
ALTER TABLE openemr.immunizations
CHANGE amount_administered amount_administered FLOAT;

You can fix historical data or update manually:
UPDATE immunizations SET amount_administered=0.5 WHERE cvx_code=141 AND amount_administered =1;

– After all testing, clean up prior entries
ALTER TABLE openemr.immunizations
DROP COLUMN amount_administered_int;

bradymiller wrote on Tuesday, October 01, 2013:

Hi,
Wouldn’t it be best to just convert it to a VARCHAR to allow entering in dosages of multicomponent vaccines (the same thing should be done for dosages in the prescriptions table).
-brady
OpenEMR

mdsupport wrote on Tuesday, October 01, 2013:

As a general design guideline it is best to follow HL7 definitions and layout. Immunization record is proxy for HL7 VXU message. ‘Administered amount’ is a standard HL7 field expected in RXA. If we made it a description, there is no telling what my clinicians will input. Besides, most registries expect it to a number and many require it to be in mL - ignoring the next ‘Administered units’ fields due to conversion issues. Not sure how current field definition have worked for the community.

yehster wrote on Tuesday, October 01, 2013:

http://www.nyc.gov/html/doh/downloads/pdf/cir/cir-hl7-web-service-integration-guide.pdf
“Administered amount” for the RXA segment is different than the “dosage/strength” of a multi-component vaccine. It corresponds to the quantity in the syringe/delivery device.

Each component of a multi-component vaccine would have a separate OBX segment.

MD Support, are you actively working on HL7 export for immunizations?

mdsupport wrote on Tuesday, October 01, 2013:

Standard HL7 export for immunizations validated OK. So not planning for any changes unless the other side forces it.

cmswest wrote on Tuesday, September 09, 2014:

hi md support, have you generated a vxu message from openemr?

thanks

please ignore request as i found the vxu msg under reports->clients->Get HL7

kkrgr8 wrote on Wednesday, September 10, 2014:

Hi,
I personally believe to convert it to a Float to allow entering in dosages of vaccines in decimal points.

Thanks

bradymiller wrote on Thursday, September 11, 2014:

Hi,

To change this for amount administered, somebody will need to change in database.sql file and in the 4_1_2-to-4_1_3_upgrade.sql scripts (these are in the sql directory). This appears to make sense considering amount administered is not the actual doses of multicomponent vaccines, but instead just the total amount.

-brady
OpenEMR

bradymiller wrote on Thursday, September 11, 2014:

Quick question,

After you did the “ALTER … CHANGE amount_administered amount_administered FLOAT;”, did you notice any issues in the data in amount_administered?

-brady

mdsupport wrote on Thursday, September 11, 2014:

I don’t think we found any problem with int to float conversion. We did preserve old values in a temporary column - haven’t dropped the column yet.

mdsupport wrote on Thursday, September 11, 2014:

Apart from ALTER, are you planning to include SQL statements fixing the values?
Data in amount_administered column should be treated like corrupt data and fixed based on other rules. Since we had limited number of cvx_codes, fix was easy. For general release, a better fix may be extracting the values submitted to mySQL from logs and updating the float field. We did not explore that approach.

bradymiller wrote on Friday, September 12, 2014:

Hi,

Never thought of taking it that far. Just having somebody place changes in above sql files would be a start though.

-brady
OpenEMR

cmswest wrote on Friday, September 12, 2014:

here’s my stab at it, although maybe i’m too ambitious in the upgrade file?

mdsupport wrote on Saturday, September 13, 2014:

The update statement was originally included as an sample. Every installation will have to figure out how/if they want to fix historical data.

Since nobody has complained so far, either users don’t know or don’t care. So Brady’s approach may be better.

Thanks Stephen for creating the patch.

bradymiller wrote on Saturday, September 13, 2014:

Hi,

Just committed code written by Stephen to fix this:

-brady
OpenEMR