cfapress wrote on Monday, June 08, 2009:
My head is about to explode. The level of obfuscation in the PHP code surrounding patient documents is horrendous. It’s taken me about 90 minutes to get this unique-ID problem sorted out.
Here’s what I’m trying to do. Our Agency is beginning to scan thousands of old patient charts as PDF files. I thought this would be a great opportunity to merge this paper data with OpenEMR records. All of the patient’s are already in OpenEMR so it should be pretty easy to automate.
I have a simple mechanism that lets a human-user match the PDF document to an OpenEMR record.
The hard part is attaching that document to a patient in the OpenEMR database.
Yeah, it should be simple. And it would be except for the fact the ‘id’ column in the ‘documents’ table does not auto-increment. In fact, the value of that field is based upon the value of the ‘id’ column in the table ‘sequences’. WTF?!
Now get this… Other tables are using the same column for their unique ID in their own tables. I see similar code around Notes, Insurance Company, and Addresses. There must be a few others. Wow.
I’m not sure how this method for coming up with a unique ID value came about but I’d love to have a discussion with whomever came up with it. I’m having a hard time rationalizing the purpose of such a complex system for creating a unique ID.
Anyway, enough ranting.
Just in case anyone else runs into a problem like this here is the solution that I’m using:
1) Increment the value in the ‘id’ column of the ‘sequences’ table
2) Assign that new ID value to the document being imported
This way, I’m not breaking the use of the ‘sequences’ ID uniqueness.
Very messy. Yuck!
Jason