mmurfin87 wrote on Sunday, May 24, 2015:
I’m curious if anyone has done this and what your process was.
I’m currently working on getting patient data imported. I found a script that exports the medware TPS files to CSV, and I’m working on a custom PHP script to parse that CSV and insert the rows into the patient_data table. I’ll share it when I’ve got something working.
teryhill wrote on Sunday, May 24, 2015:
I do conversions from Alta Point and other systems to OpenEmr (haven’t done a Medware yet). I have programs external of OpenEmr that I use to make csv files of the Patient , insurance, cpt, diagnosis, immunizations, medical records and other files. I have also done a conversion from Greenway to OpenEmr.
I use a Database language I am familiar with the do the conversion to the csv files and then use the import functions of phpmyadmin to import the data.
I have also converted (for one Doc) 43,264 document files in to the documents of OpenEmr as pdf’s.
Thanks
Terry
mmurfin87 wrote on Thursday, June 04, 2015:
I have patient demographics importing successfully to OpenEMR using the php script i wrote here: openemr/justimport.php at medware · mmurfin87/openemr · GitHub .
Note I’m using two additional columns in patient_data: ‘suffix’ for data like Sr., Jr., III, etc; and ‘street2’ for capturing the second street info. I figured since the database is already contorting into weird shapes because of the Layouts feature, I might as well add in my fields and not lose the data.
Next I’m going to work on Insurance Companies, and then Billing information like Claims, etc.
Note that I’m using this library for parsing the TPS files: GitHub - ctrl-alt-dev/tps-parse: Parses Clarion TPS files. Also converts to CSV.. Although its got a nice Java API, I’m using the nice command line utility it comes with.
I’ll try to keep updating this as I get more done and make my code prettier as I learn more about OpenEMR.
mmurfin87 wrote on Saturday, June 20, 2015:
I’m working on importing claims data and I have tracked down the affected code and tables.
Claims are held in the ‘claims’ table where some sort of logic based on which fields are empty determines its status in the Billing UI. Tables ‘ar_session’ and ‘ar_activity’ maintain accounting line items for each claim.
It isn’t clear to me yet whether a claim absolutely must be associated with an encounter id yet. I’ll assume it is and generate an encounter for each claim though, even if it has no data.
From the database’s perspective, an encounter is just an id that is managed by the one-field ‘sequences’ table. Generally, there is an entry in the ‘forms’ and ‘form_encounter’ tables for these encounters. Although again it isn’t clear if these are absolutely necessary entries or if there are any other necessary entries needed in other tables. Table ‘issues_ecounter’ also holds the issues entered in the New Patient Encounter form but can be blank.
My plan then is to convert the Medware claims into entries into the ‘claims’ table with line items being converted into the ‘ar_*’ tables and update the ‘sequences’ table with the highest id i create so that future entries won’t clobber my imported data.
Anyone see any issues or have any helpful hints?
Thanks
fsgl wrote on Saturday, June 20, 2015:
Mapping can be very complex but Database Structure should provide good cartography.
It is not possible to bill for service without the creation of an encounter form.
There’s a lot more going on in form_encounter than merely the creation of an id.
A dry run of migrating 1 patient with extensive data to a test copy of OpenEMR will help in avoiding pitfalls.
mdsupport wrote on Monday, June 22, 2015:
If possible, process open claims from original system and let new system process new encounters and related claims. Practice owners will be happy if cash flow is not disrupted.
What was the outcome of this exercise?
Anyone managed to decode the database structure to ease the migration of billing data between other systems and openemr?