Has anyone tried to do any kind of automated image importing into OpenEMR? If not , is there anything in the future development road map regarding this? We frequently find ourselves trying to import information sets from other systems, which is almost inevitably some kind of digital image file, jpeg, pdf, tiff, etc. , & it would be a tremendous time saver if there was some kind of multi-patient/multi-image upload function. I’ve been looking at the code for image insertion routines in OpenEMR & it doesn’t appear like it could be easily modified to do mass importing for multiple patients.
I have a Perl script that I created back in 2006 for something like this. It was dropped because the newer fax/scan interface suited the need better. Sounds like it may save you some time. I’m happy to pass it on to you if you’ll preserve the GPL license and make your improvements available to the project.
Rod,
I would love to take a look at it, if I can make it work with the current OpenEMR then any improvements we make would most definitely be contributed back to the project community.
Thanks Rod! I’ll try setting it up this week & see what the possibilities are. I may have a project that requires importing 600+ GB of images, should be interesting…
Rod,
This actually worked fairly well just the way it is. The only change I had to make was that I had to change the field type for ‘pubpid’ in the patient_data table from VARCHAR to BIGINT for the queries to work. For some reason, the SQL query results were stripping the first number off the pubpid, I’m almost wondering if this is some sort of bizarre bug in MySQL. Is changing that field type going to cause problems down the road or am I safe using it this way? OpenEMR seems to function just fine so far after the table change, I was just curious if there was some specific reason why pubpid is VARCHAR & pid is BIGINT. In this system the pubpid & pid are actually identical for each patient.
pubpid is an “external” patient identifier and need not be numeric… it’s just whatever the site wants to put there. Sites converting from paper charts will probably put their old chart numbers there.
I don’t know offhand why there would be a problem with VARCHAR and the image loader. That’s something a programmer should look at. Doesn’t seem right to be changing the table’s field type.
Right, we had to import their patient base from existing billing software that’s still in use, & it was easier & less confusing for the staff to assign account numbers the same as the current system. I don’t think it’s necessarily a VARCHAR problem, I think it’s something to do with the Collation setting in the database. I went & tested on a version 2.9.0 that doesn’t have the UTF8 collation setting in the patient_data table, & it worked just fine. Could be a MySQL/UTF bug of some sort to.
For example, on version 2.9.0, if run
SELECT pid from patient_data where pubpid = ‘34481’;
The query comes back with no results, even though in the database entry for that patient both pid & pubpid = 34481
if I run
SELECT pubpid FROM patient_data where pid = ‘34481’;
It returns “4481”. Very strange, I’m almost thinking that it has to be something related to how MySQL handles the UTF8 collation on the tables.
After setting pubpid to be BIGINT, everything works exactly as it should.
I’m not exactly comfortable with changing a field type either but in this case I can’t see any reason why it would do any damage.
At this point I’m wondering if there’s something to add in the SQL query syntax that might prevent it from cutting off the first digit.
I wouldn’t consider changing the field to BIGINT a viable option, since some clinic/facilities use letters in their patient id’s. Instead, need to to find the underlying bug, and fix it. Regarding UTF8/latin1 there is no difference in the encoding of digits, so would be odd for that to be reason for causing issues. What’s your mysql version and os?
-brady
Brady,
It’s MySQL 5.0.51a, running on Ubuntu 8.0.4 LTS 64-bit server. I hadn’t even thought of that before, maybe it’s a MySQL bug related to a 64-bit issue. I agree that changing the pubpid field to BIGINT is probably not a good idea in general, but for this particular office it’s not going to be a problem since all their patient IDs are strictly numerical. I’m going to do some MySQL research this weekend & also try some testing with current CVS of OpenEMR to see if I can replicate the bogus SQL query behavior. That disappearing first digit is quite strange.