Hi all,
Hope somebody can help me with this major problem.
I am trying to implement OpenEMR for my Neurology Practice in Australia. It needs a fair bit of modification to the Demographics layout given the requirements we have here although some elements are similar. I have installed OpenEMR about 10 times now and have everytime messed up the code once I amend the Demographics section. After reading about ‘NOT DELETING"’ any values from the layouts, I ended up making most of then not-required items such as License/ID, SSN, External ID unusable. I created a nice layout of what I needed and mostly after multiple reinstalls and re-configs the table appeared to have a good appearance. However I have some difficulties which are completely stalling my use or even the basic configuration of OpenEMR until somebody finds a better solution to the hardcoded field items in the Demographics section which now appears to be least customizable.
I tried selectively exporting patient_data table and importing it back after re-installs; while this might restore the custom fields I created, the demographics form that loads loses all the formatting and the fields I had created. How can I restore the layout without reverting back to the default install config?
I am re-installing it the Nth time now and hopefully someone will help me fix this process.
I can upload a snapshot of what fields I need with my basic layout.
Fields not used in Demographics should be changed into unused and DO NOT DELETE these fields! It can have serious problems when deleted.
You can add as many fields you like.
The “External ID” is a very important column with a confusing name. It’s the ID that gets displayed pretty much everywhere in the system on every patient list/report. It’s the field that search uses when you hit “ID” in the left nav quick search.
That column is central to many features in OpenEMR. I suggest that you change the name to “Medical Record Number” or something like that if “External ID” bothers you that much, but it’s too important of a column to be flagged as unused unless you really understand the implications.
To save your customizations from the layout editor between installations, you need to export the values of interest from the “layout” MySQL table.
This can be accomplished by using PHPMyAdmin (Administration > Other > Database) or other external database tool. (Personally I would do it with MySQL Workbench). Basically you want to “output” the rows for “DEM” into a usable format. Then when you do a new install, you could delete the default values that come with the new database and reload the values.
You could also do a mysqldump of the whole “layout” table from the customized version, then reload that dumpfile on a fresh install.
Thanks Kevin and Pieter for your advice. I finally managed to have a stable version of the Demographics layout after I ensured that I did not delete any ‘required’ fields. I have made backup copies of the layout_options and patient_data tables and have backedup my OpenEMR folder so that if I ever had to recreate it, then the layout will be preserved.
I encountered a funny problem though while editing the ''Stats’section. Changing Label and Data Columns never updated the database since the values were never written. I have seen this happen more than once.
I had to manually edit the values to 1 and 3 to have everything start in a new row and this worked. Is there a bug with the 'form somewhere that doesnt input all the changes in the Label and Data columns into the layout_options table??
I understand that attempts are being made to make this 'Demographics’section more customizable. I hope that it will be accomplished soon since the whole thing that makes OpenEMR standout is it’s customization option compared to other solutions out there in the market. Unfortunately we don’t even have anything like ZH Healthcare that can customize it to Australian users and certainly there will be a big following here since the Medicare rebates, insurance claims, billing are very similar to the US version.
Schedule a time for the service, document the service, bill for the service and record the payment.
Any decent EHR should do all 4 without breaking a sweat. That having been said, OpenEMR is very versatile and should meet the needs of most physicians anywhere in the world.
To distinguish between a local idiosyncrasy and a bug, experiment in the Demo’s. In instances where a code change is required, experimentation on a test copy rather than the production copy will lessen frustration. Backup can never be overstressed.
The LBV form has its own logic and requirements, therefore trial and error is required to render it “obedient”. Its great strength and weakness is the ease of modification. So adaptable that users may overdo it causing immense problems in the Patient Summary and elsewhere.
Kevin made a very important point about the External ID column. I changed that column in the 4.1.2 Demo to Unused (just to see the effects for myself), wrecking havoc with all patients, not merely the one that I created. Even trying to rectify the matter in the Layout Editor and in the tables did nothing to remedy the situation. Fortunately the Demo reset and all the mischief was magically mitigated.