Once the question has been answered, we try to have fun. All work and no play…
The Demo’s are great places to experiment. The 4.1.1 Demo is better than the others, if there is a question about which table to use, because one does not have to deal with the drop down menu. Simply add a sample piece of datum and then look to see where it lands.
In the event that you are unaware, this DIY Wiki article may be helpful, especially in matters relating to Billing.
David,
The transition from another EHR, without professional support, requires a great deal of patience and perseverance; but the greater the effort, the greater the sense of accomplishment.
We, as practicing physicians, bring to this project a valuable perspective that our colleagues in IT don’t have. Therefore, if we are undaunted enough to contribute codes that had been informed by our clinical experience, this would make OpenEMR vastly superior and uniquely priceless to the larger medical community.
For the record, since I’m not live yet I have found it most convenient to simply set up a localhost copy of OEMR on my laptop. I can do all my experimenting on that and, since I’ve become quite proficient at making and restoring from backups, I can do all the experimenting I like without having to deal with internet access and speed issues (I live where it’s warm, do most of my stuff on my laptop and frequently mess around in the evenings on my lounge chair in the front yard, where internet access is sometimes marginal). Also, this limits the amount of things, tables and data I have to look at to the changes that I personally have made and I don’t have to get bogged down looking at others’ contributions unless I want to (although it’s sometimes helpful to understand that not everyone does things the same way). In fact, as I consider this to be an ongoing project with no realistic limitations I’ll probably maintain two separate databases, one working and the other experimental, even after I go live. That way I’ll be able to experiment to my heart’s content without the chance of corrupting my precious data.
BTW, I did notice that on one particular (I think older, 4.1.1?) demo I was unable to view the database tables even when logged in as admin. That severely limited its utility to me.
As a side note, patience and perseverance have been the name of the game. My personal paranoia is such that I don’t want to be held hostage to any particular company for “support” for a system after it’s installed. I view the rather considerable time investment I’ve made in understanding HTML, PHP, MySQL and OEMR not only as a fairly geeky hobby and/or waste of time but also as my hedge against continuing annual support charges. After all, I’ve now become a reasonably competent, although limited, systems and database administrator and have learned how to create and fill my own tables and insert them into the OEMR system (as an ENT I find much of the Primary Care stuff not relevant to my practice) so as to bend the system to my will. I’ve personally set up the network in my office (including even stringing the ethernet cable and crimping on the connectors). There’s no reason why I can’t be my own support if I know and understand every aspect of how the system works (particularly if I can ask questions in this forum).
Getting back on topic here. Do you have any idea what type of database software Medisoft uses? and what is the general database structure (table names and how they are related)? In my particular conversion from POM to OEMR I discovered that POM used an older version of Pervasive SQL (which was similar although not identical to MySQL) and that of the hundred or so tables within the database only seven or so were important enough to be relevant to the conversion (contained patient data, referring physician data, encounter data, billing data, payment data, accounts-receivable data and so forth). From there, I had to experiment with different SQL select statements, most of which involved INNER JOINS (and a few LEFT JOINS), to couple the data in the various tables (for example, coupling a patient id number to an encounter to a service to a date to a fee to a diagnosis to a bill to a payment to a residual balance…) so I could extract the data I needed either directly to the relevant table in OEMR or to a temporary table from which it could be accessed later. I have no doubt that there are more efficient ways to do this but my way is working for me (so far).
If the above doesn’t look somewhat familiar you’ll need to do some research on the internet. Try googling “mysql tutorial” or “mysql select syntax” or whatever and do some basic reading. I’ve had pretty good luck with www.w3schools.com and www.mysqltutorial.org but there are others as well. A good MySQL reference text could be helpful as well but I do much of my work on the fly and it’s inconvenient to be dragging large texts around. Furthermore, the top few google hits will usually point you in the right direction a lot quicker than trying to find the right entry in a large text’s index. It’s pretty daunting at first but before long you’ll have at least a basic knowledge base skeleton upon which you can hang additional little tidbits. Then it begins to become a little more fun.
I might add a few other things. At least when you’re experimenting you will save a lot of time if you can pare down the data in the Medisoft tables. Otherwise you’ll likely have hundreds of thousands of entries, the vast majority of which are closed accounts and will not necessarily need to be imported (but nevertheless still slow things down). As such, a simple line such as “DELETE FROM [tablename] WHERE [date] < ‘2011-01-01’” will get rid of the old data. Obviously, you’ll need to select an appropriate cut-off date and make certain that anything less than the date in question has been zeroed out and is no longer relevant. DO NOT DO THIS TO YOUR ORIGINAL TABLES - YOU WILL LOSE YOU DATA! It’s best to export all the data first (or selectively export the data) and then fiddle with it later outside the realm of whatever database is holding your Medisoft data.
PhpMyAdmin works in the 4.1.1 Demo but it does not in 4.1.2 nor in 4.1.3. With it being erratic, a test copy had to be used to work out the kinks in the .sql files of the Eye forms.
Just got done perusing through some of the EHR reviews at the American Academy of Ophthalmology website. Most of the comments about the industry leader bemoans the exorbitant costs and the non-support. Help from our former software vendor was condescending at best and contemptuous at worst. Nothing worse than being charged a pound of flesh and being treated rudely. Burned that bridge and glad that I did.
Amen to that, and my guess is that there are a lot more Opthalmologists around than ENTs, so if logic follows there are probably even fewer and worse options available for us.
Altius, Citius, Fortius (awaiting Sochi) Arma virumque cano… Gallia est omnis divisa in tres partes… Panem et circenses.
and my personal favorite - Semper ubi sub ubi (try your hand at that one)
(I try hard to forget this stuff but evidently it’s tattooed to the inside of my eyelids)
It is obvious that you had more fun learning Latin.
Caesar and his boys were forever breaking camp and pitching camp, doing little in between (sort of like Boy Scout trips). Come to find out, much later in life, that the good Sisters of the Presentation taught us the sanitized version of the Commentaries.