Dr Bowen created a "loader" which I used to upload my original patient list, and then tried to use as a model to upload the insurance companies and was going to try uploading encounters. It involved mapping the data fields from the existing data csv to the field order in OpenEMR.
I urge CAUTION !
I found that the patient upload resulted in an error message telling me that the values I entered in fields which had a drop-down associated were not recognized. The attempt to load the insurance, even with an exclusive-or limitation, were unreconcilable with the OpenEMR list as editable with Admin - Practice - Insurance. I wound up having to manually create all.
Bottom line - any loader MUST work with whatever is the interacting data updates or there will be sorry consequences down the road.
I think this can be fixed. The issue is that for the drop down lists to function correctly the import tool needs to generate the correct variable in each of the list boxes. The tool that you and I were using was simply uploading the value of the prior data. For "Male" the data being uploaded was "M".
But of course this is not the same to a computer. When the OpenEMR logic tries to pull the gender out of the database it gets "M" which it cannot interpret correctly as "Male" and gives an error message that you have not selected the correct gender.
I know we did not complete the upload tool to allow for this but there would have to a decision tree for each of these lists that would cause the tool to "translate" the incoming data into the correct variable.
Case if:
"M"
set gender = "Male"
Case if:
"F"
set gender ="Female";
While this is easy to solve with the simple case of gender, I don’t think this can be generalized for the other lists.
facility
patient list
referring provider
users
insurance provider
pharmacies
Most of these are going to be very specific to the locale of the clinic. They can be done on a per case basis but only by someone willing to work out the details of the specific filter from the old database to the new database.
The only thing that will make this better is the HHS / HIT idea of "interoperability" where for instance the demographics fields are standardized.
Having these drop down boxes are convenient but make the job of writing filters from one program to another more involved.
I would normally agree completely, except that the specifics I noted above WERE identical data to the dropdown choices. I never did figure out the problem, and it may have been that SOME did not match, so I’ll give benefit of the doubt. But the resulting inability to even ACCESS the Insurance Co data list was pretty severe. That is my only comment.