Patient PIDs are in the billions and scanned documents make it into the document directory but dont show up in the browser (UI) at all.
Is it that the portion of OpenEMR that reads the files doesn’ t like long numbers?
OEMR 4./SP2
Ubuntu
Apache 2.2
MySQL 5.1
Probably documents.foreign_id is your culprit there, it is a standard integer and limited to 11 digits. It references patient_data.pid and so should have been defined as bigint(20). You should be able to fix that with an ALTER TABLE. Might be some other issues like that though.
We migrated 15k patients in.
once this problem started we took a look via phpMyAdmin. We see that the increment suddenly started jumping in odd amounts. 100k 1million 222 million and so on till it got to 3 billion and it began getting sick.
I don’t know what other issues. Just saying that huge values for pid seem to be not well tested. Also I strongly suggest figuring out why you’re getting the big jumps, as it might be a symptom of a more serious problem.
I’d speculate that an SSN or similar identifier was used at some point to create a patient, and auto increment continued from there… I think that’s happened here once or twice.
After sorting through the original data I found the bad apple. A single test record (John Doe) with a record number of 3,000,000,001. How annoying.
Does it make sense to stop using int(11) and start using bigint() for patient records and associated PIDs. It might make sense for migrating data. If you have only a few hundred, sorting prior to migrating is ok but once you get into the 10s of 1000s or more it gets hard to make sure its clean (ie stuff like this).
Thanks
Still need to find a solution for this. Any input would be of great help.
What we have done in our practice (we have numeric chart numbers) is wrote a script that doesn’t depend on the OEMR auto increment of the pid. The script checks for a pre-existing number then sets pubpid=pid=old_chart_number. Works very well if a staff member does not create a new patient manually.