The Current Landscape of Ophthalmology Electronic Medical/Health Records (EMR/EHR) Software's and How it Relates to Our Company.

EMR's have been in existence for quite some time now. There are literally hundreds of Electronic Medical/Health Records (EMR/EHR) software packages available for all types of medical specialties. While there are several Electronic Medical Records software packages out there that work very well for many types of specialties, the Ophthalmology Specialty has unfortunately been left behind. The main reason EMR/EHR developers have not adequately targeted the Ophthalmology Specialty is simple; Ophthalmology medical documentation is radically different and far more complex than most medical specialties. Ophthalmology documentation as you probably already know requires up to hundreds more numerical values, requires complex optical mathematical formulas, requires imaging and data values from numerous diagnostic machines and procedures, requires surgery documentation & the list goes on and on.

In a competitive Electronic Medical/Health Records (EMR/EHR) vendor environment, most Electronic Medical/Health Records (EMR/EHR) software vendors have opted to create Electronic Medical/Health Records (EMR/EHR) software that can be used for multiple medical specialties. The reason for this philosophy is simply that they desire to capture multiple markets, and do not want to be limited to a certain specialty. While this philosophy and business decision seems to be practical & good for business, it limits the opportunity for the Electronic Medical/Health Records (EMR/EHR) software to streamline & enhance the software experience for the end user. Electronic Medical/Health Records (EMR/EHR) Software (designed to accommodate multiple medical specialties) are generally template driven, and in some cases allow or even require the end-user to design the template. It seems like a good idea at first, but one look at the end result proves a serious flaw in the design... It's efficiency is limited, and it is generic in nature. More time was spent by the developer(s) creating a software that was flexible than creating a software that enhanced efficiency, streamlined office procedures, and presented the collected data in a manner that enhanced the overall user experience & enhanced the quality of patient care. Electronic Medical/Health Records (EMR/EHR) vendors recognize this problem, and market their software assuring  Return on Investment (ROI), along with the promise of efficiency after a "slight" learning curve. On rare occasion an honest sales person will promise efficiency after behavior modification, and the implementation of procedural change. Every EMR/EHR software vendor will promise ROI & efficiency, but not every EMR/EHR software vendor delivers. Many Ophthalmologists have resulted to staying after-hours inputting data as the software is too inefficient to use in real time. In many cases, Ophthalmologists have ripped their EMR/EHR out of their practice and reverted back to paper, leaving a bad taste of EMR in the mouths of hundreds of hopeful practices.

Another flaw in it's design is more of a technical issue, but is still something you should consider. The data is stored using risky & inefficient storage methods, which can slow the performance of the software significantly and expose you to data corruption and/or loss of data. In some extreme cases, simply updating the software to a new version can render all your previous medical records useless! Also, because every Doctor has the ability to modify the structure of the software, every Doctor literally has a different software. Because of this, the EMR/EHR company's technical support is less familiar with the software as each practice has it's own version of it. We have heard reports of practice's using a template EMR/EHR recommending to new users of the template type system to not customize it as it is simply not worth the aggravations and the risk. For more technical details about this please see Appendix #1 below.

Streamlined & efficient processes are just not feasible in a template driven software. Creating a streamlined, efficient process that enhances the user experience & patient care requires a complete understanding of the task at hand, requires an enormous amount of computer logic for each individual field or control, and requires a data structure that is simple and efficient. This level of sophistication is not feasible in a template driven software because it was designed to accommodate, not designed to enhance. The Ophthalmology specialty is unique in the sense that a template driven software is not only inefficient and poor for user experience & patient care, it does not work well because it's too different from the other specialties, and requires a significant amount of resources & redevelopment to change the template to fit Ophthalmology. Ophthalmology requires more than a Generic EMR. Ophthalmology is a specialty that does not look, feel, or operate like any other specialty. It is completely different, and requires a different approach.

There are several Ophthalmic specific EMR's out there, but with them you run into different problems. They either are overcomplicated, oversimplified, based on shaky technology, or web based. In a world of extremes, other Ophthalmic specific EMRs fit right in. They either are so complicated that using it is mind-boggling and you never stop training on it if you don't trash it, or they are oversimplified, and not able to capture the data needed and leave you without good features found on the complicated ones. Several are now Web based, leaving you susceptible to internet connectivity related outages, performance issues, inefficiency, lack of features, and data ownership concerns. At any moment these web based software providers can lock you out of the system, changes and updates can be performed without your authorization, and because your data hosted on their servers, the server performance will be dependant on the activity of other organizations thousands of miles away! Also, make no mistake these web based service providers will data mine YOUR data, and sell it to other companies without you ever receiving any compensation for your hard work. HIPAA does not protect you from anonymous data collection.

Many Ophthalmic specific EMR's were developed by the Ophthalmologist themselves! Understandably frustrated with the lack of viable EMR/EHR options, more than a handful of Ophthalmologists in their spare time have created respectable looking EMR/EHR software packages using unconventional "development" tools such as Microsoft Word®, Filemaker Pro®, and Microsoft Infopath®. While these can be powerful tools for accomplishing certain kinds of tasks, "tool maxing" an EMR/EHR in our opinion is a disaster waiting to happen. These tools are not fully based on Enterprise level relational databases, and can expose you to lack of sophisticated reporting, potential data corruption, and loss of data. Furthermore, converting it to another EMR/EHR in the event you change to a different EMR/EHR would be an absolute nightmare. Converting is difficult enough with relational databases, converting thousands of XML or Word files would take the difficulty to a whole new level. You should not trust the storage of your Patient's medical records to a platform not designed for this purpose. Some of these EMR/EHR vendors claim to use SQL relational databases or equivalent technologies, but in reality it is only a half-truth. They are storing the XML or Word files within the SQL database, then claiming they use SQL. This makes reports & graphs spanning across multiple visits overly complex, inefficient, and in some cases unfeasible. This will limit your ability to overview a patient's entire visit history & limit your ability to trend using data collected from your EMR.

EyeMD EMR is the answer to all of these problems. EyeMD EMR is designed with only 1 medical specialty in mind, and was fully designed by professional developers using fast and reliable client/server technology designed for this purpose. EyeMD EMR is designed just for Ophthalmology, and can never be tweaked for anything else. It is so in tune with Ophthalmology procedures, that you will feel like you made it. Mainly because someone like you helped create it. EyeMD EMR was designed in direct collaboration with a practicing Ophthalmologist within the real-world environment of their practice. Our developers moved their offices into the Ophthalmologist's practice, and created the entire software onsite. They had direct and hands on experience with every diagnostic machine available to Ophthalmology, and had uninhibited communication with every employee in their office. The result is literally an amazing, streamlined, functional EMR software, and we guarantee that you will agree after viewing a demonstration.

Appendix #1

Template driven Electronic Medical/Health Records (EMR/EHR) software are dynamic, and the structure of the data saved requires constant change. Relational Databases are not designed to constantly change, and must be modified by a Developer to add or modify table fields. To work around this technical limitation, Electronic Medical/Health Records (EMR/EHR) software vendors are using relational databases in ways most members of the technical community consider to be risky & inefficient. To simplify the practice, think of an excel spreadsheet. Column A is a "Field Identifier", and Column B is the "Field Data". Basically, the table becomes a "super table", and bloats the database significantly. Instead of 1 record with 35 fields, you have 35 records with 1 field each. So if a typical medical record contains 300 data fields; instead of lets say 6-10 records in a normal database, you will have 300 records, a 5,000% increase in the amount of records. Imagine having 300 paper charts instead of having 6 paper charts. Imagine the staff you would need. This method of storing data is inefficient and drains the computer's resources significantly, and is the main reason why many of these Electronic Medical/Health Records (EMR/EHR) software's require the fastest computers available, and still are slow. To counter this effect during a demonstration, the demo databases have very little data in them, fooling you in believing the software is fast. Only when you have installed the software and have 3 months of data in it will you realize it's slow, but by then it's too late and you are "stuck with it". Also, if something where to happen to the field identifier (through a software version change for instance), you would instantly lose all of the data in the entire database. Needless to say, backups are even more crucial in these environments.