EMR and the Retinal Physician

Our practice was an early adopter of EMR. This is what we learned from that experience.

EMR and the Retinal Physician

Our practice was an early adopter of EMR. This is what we learned from that experience.


Electronic medical records (EMR) and its applications for the retinal physician is not a new topic and has been discussed in various contexts. For example, Paul E. Tornambe, MD, has developed his own software, "The Retina Record," and has written and spoken on the transition to EMR from the perspective of a single subspecialty practice. Maurice B. Landers III, MD, addressed the topic at the Academy Subspecialty Day 2004 from the vantage point of a university setting. Because a retina specialist's experience with EMR is most likely affected by the details of the setting, providing the different context informing what follows may be worthwhile.


Our retina service has 4 subspecialists in a larger group of 54 physicians, optometrists, and physicians' associates. Our group encompasses both ophthalmology and otolaryngology. Both specialties employ EMR, but the products chosen by the 2 specialties differ. We share a common billing software product distinct from either of the clinical EMR packages. We practice in 10 locations covering a circular geographic area with a radius of roughly 30 miles.

Our group began exploring EMR in 1997. At that time, our approach was to have "pioneer" physicians test a system before wider adoption. However, this model for introducing EMR to the larger group did not work well. Those physicians reluctant to change always outnumbered the pioneers, thus the larger conversion to EMR did not occur with the first product that we tested.

We realized more success when the group first made the philosophical commitment to EMR, followed by set timetables for groupwide conversion. Extensive preparatory training of the technicians and physicians using the product confined to a "test" area (where an application can be tested without contaminating actual patient files) was important for the successful introduction of the system. No manual was available for this training, but most likely would have been helpful.

David J. Browning, MD, PhD, practices at Charlotte Eye, Ear, Nose, and Throat Associates in North Carolina. He can be reached via e-mail at: Charlotte Eye, Ear, Nose, and Throat Associates' clinical research department, Southeast Clinical Research Associates (SCRA), owns 6.4% of the outstanding stock in Medflow. Dr. Browning is one of 38 partners in SCRA.

The EMR system we presently use is the fourth product we tried. The first was a generic product called Xscribe. The second was a generic EMR product from Medinformatix (Los Angeles, Calif). The third was an ophthalmology-specific program called Medformix (Crowell Systems, Charlotte, NC) used by a smaller group of 4 ophthalmologists who merged with our group and converted from their EMR product to the one in use by our larger absorbing group. The product currently in use by our ophthalmology department (and for the last 3 years) is Ophthalmicsuite (Medflow, Charlotte, NC). Medflow specifically designs EMR systems for ophthalmology practices.


We realized that, in our multiple-specialty practice, generic EMR products did not adapt well. This was especially true for ophthalmology. The set of screens needed, the large degree of quantitative rather than verbal data obtained in an ophthalmic examination, and the graphical nature of much of the input made generic systems of limited usefulness in an ophthalmic context. We found that a product designed from the outset for ophthalmology was an easier sell to the doctors in the practice who did not want to abandon paper records in the first place. Not only are generic EMRs ill suited for ophthalmology, they are especially poorly suited for practices that house retinal specialists, who use images more intensively than general ophthalmologists.

In our early experiences with EMR, we had multiple screens through which scrolling was required (sequential screens model, Figure 1). This design feature was not popular with most of our users. A better screen paradigm was developed by Medflow in which a single master screen acts as a hub with radiating spokes linking to other program areas by a single keystroke (Figure 2). A screen shot of the hub is shown in Figure 3. This model is preferred by the majority our ophthalmologists, although some expert users of the sequential screens model did not find it to be a problem.

Figure 1. Schematic of an EMR organized as sequential screens (more screens exist for visual fields, images, flow sheets, discussions, scanned material).

Converting Can Be Challenging

A challenge when converting from paper charts to EMR is choosing how much of the paper chart to scan for storage within the EMR. Our physicians' preferences varied from desiring little of the old chart to desiring the entire old chart. The latter choice is expensive, and the best compromise seems in retrospect to be selective scanning of important records such as initial examination notes, operative notes, and baseline test output (visual fields and ocular images).

A large investment of time is necessary at the beginning to build the pick lists for the examination sections and the inventory of discussions that appear at the end of the note. Many ophthalmologists object to the boilerplate discussions that appear at the end of the note, but they serve several purposes. First, they encapsulate repetitively performed discussions. It is efficient to press 1 button to document that a complex, but highly rehearsed, conversation regarding surgical risks and benefits has been held. Moreover, commonly reviewed sequences of information, such as dietary and vitamin recommendations in cases of dry macular degeneration, lend themselves well to this feature of EMR. Specific additions can be free typed at the end of standard discussions that apply to particular patients, such as variation in dietary advice in the case of a patient taking warfarin, or modification of vitamin use in a current or past smoker.

We found that determining how physicians sign-off on completed records was an important detail. There are 2 ways our physicians have chosen to manage this function: Either the physician signs off at the conclusion of the face-to-face encounter or he can sign off later, perhaps at the end of the clinic session. The discipline of having the encounter completed when the patient leaves is an advantage of the first method. On the other hand, complex cases that benefit from further reflection may be better managed with a delayed sign-off. The sign-off screen for the Medflow EMR system has improved slowly, from upgrade to upgrade. Within the sign-off screen, buttons and pick lists exist, allowing the user to modify, before sign-off, errors detected in the examination as recorded initially.

Security Often at the Expense of User Ease

Security concerns in the use of EMR conflict directly with ease of usage. Open screens revert to a locked home screen after a user-defined interval of time without active data entry. There are many sites within the system where passwords are required for access. Only certain users can access all sites, and there are hierarchies of accessibility definable by the network administrator. However, these are facts of life when digitally managing sensitive data, and are not specific to EMR.

When technicians work for multiple physicians, they must enter EMR under the authority of a particular physician. If they subsequently address the concerns of a patient tied to a different physician (eg, answering a phone call directed to physician B while working in the system under the name of physician A), they are trained to sign out of the first physician's authority, and sign in under the correctly associated physician with that patient, but they often do not bother to do so, especially as there is no penalty that they incur by forging ahead under the first physician's name. This implies that the task flows to the wrong physician for sign-off, and requires that the wrong physician must transfer the piece of work to the correct physician for sign-off. A bigger problem of this sort arises if the technician is signed in under physician A, but works up a patient for physician B. When physician B sees the patient to complete his part of the encounter, his examination is not compatible and is not automatically merged with the technician work-up done under physician A. It requires an information technologist to merge the work, a slow process all too commonly required in a multiple-physician office under the Medflow package.

Figure 2. Example of an EMR organized as a hub with spokes.

Customization Important in Multispecialty Practice

Ours is a multispecialty practice, so that different screens have been designed for each subspecialty. The exam screens for pediatric ophthalmology, neuro-ophthalmology, cornea and refractive surgery, and retina are all different. Because of this, clinical support staff tend to become expert in one set of screens and pick lists, and less skilled in others. Inevitably, as technical staff are shifted from one clinic to another due to illness and vacation, the discrepant skills become an obstacle to the smooth functioning of the clinic.

Even within the retina service, there is considerable variability in practice style. Some retina specialists prefer clicking of entries from drop down pick lists, whereas others prefer free typing by scribes in an entry area on the exam screen. The Discussions generated for different diagnoses differ for each specialist, as are the descriptive terms that appear in the pick lists. The Medflow product accommodates this customization easily. All menus, pick lists, operative note categories, drug lists, and the like are customizable by the particular user within the practice. As a beta site for Medflow, and an early retina practice to use the product, many of the catalog of options available from the company arise from the Charlotte Eye, Ear, Nose, and Throat Associates experience, but each new user is free to build an entirely fresh set if desired.


To follow are some of the good things about EMR and the areas that could be improved upon (some of this information is specific to the Medflow product):

Pro: Portability enhances efficiency. The most successful aspect of our experience has been the constant availability of all records at all locations. Before EMR, we had frequent problems in seeing patients without a chart. This probably occurred in 10-20% of encounters for the retina specialists. The patient would be at location A, but the paper chart would be at location B. EMR solved this problem.

Pro: Drawing component is user friendly. The drawing component of the retina EMR package is important. The Medflow drawing program that we use is mouse-based with drop-in symbols and typical paint features very similar to the standard paint program found in Windows based PCs. The fundus drawing is easily modifiable to achieve criteria that may be required for extended ophthalmoscopy coding.

Pro: Discussions are easily modified by each user. As new developments occur in the field, these Discussions are continually updated. For example, I recently deleted reference to radial optic neurotomy in my Discussion relating to central retinal vein occlusion.

Pro: Faxmaker module is quick and efficient. The Faxmaker allows immediate faxing of the office exam note to a referring physician before the patient leaves the office.

Con: Image importation is not ideal. Retinal physicians employ imaging, electrophysiology, and other ancillary studies for a higher percentage of their patients than do many general ophthalmologists. Fluorescein and indocyanine green angiograms, ultrasound biomicroscopy, optical coherence tomography (OCT), fundus microperimetry, and macular and global ERGs must be efficiently imported into EMR and accessed conveniently. The designs of the generic EMRs we tested did not recognize this. In the Medflow product, a better result was obtained, but it is still not ideal. Fundus photographs, OCT images, and visual fields are exportable to EMR, but the solution is not as simple as a user would like. The photographer in our practice exports a subset of the total images to the EMR. The expense associated with storage makes saving the complete original set impractical. The complete set resides on the storage system of the fundus camera, or on the hard drive of the OCT machine or visual field machine with only a sample stored in the EMR. A high degree of training and communication is required between clinician and photographer in choosing which images to archive on EMR.

Figure 3. Screen shot of the single screen retinal examination hub. The buttons throughout perform as spokes that take one to various functions (reviewing images, drawing, checking scanned records).

Con: Longitudinal analysis of OCT data is currently not possible. This, in my opinion, is a major difficulty yet to be solved. Presently, thumbnails of OCT images from different dates appear on a screen and can be enlarged for detailed viewing, but a graphical display of OCT indices over time such as central subfield mean thickness or total macular volume has not been reliably provided. An early version of such a feature appears in the OCT module of Medflow, but it does not have a reliable feature for inserting interventions such as laser treatments, surgeries, or intravitreal injections, and it does not reliably work in the present version of the program.

Con: Installing upgrades can be difficult. At intervals of 4-6 months, a software upgrade is installed, and over the next several weeks annoying side effects of the upgrade have to be repaired. The more sarcastic members of the department have given these program changes the moniker of downgrades as a result, although the net result after the transitional weeks is indeed in the direction of progress. As examples, an upgrade may inadvertently change the default size of an image, or a standard field, such as blood pressure, may no longer appear on the archived version of the clinic encounter, and may need to be reinstalled.

Con: Keystroke response is slow. A continuing concern has been the slowness of the EMR response to a keystroke. Our Information Technology consultants advise us that this is a problem with both hardware and software components. Medflow is working on programming efficiencies, but progress is slow. Because of the multiple screens and security gates traversed with each patient encounter, small delays build into significant time wasted in the course of a day with 40-60 patient encounters.


Our practice has used the clinical part of the EMR system until recently, and is beginning to use the practice portions of the package. The coding and billing components of the Medflow program appear to have the potential to render more uniform the coding practices of our 4 retina doctors, which currently are quite disparate. Thus, we are beginning to dispense with paper superbills.

The patient-tracker module in the EMR, which allows progress of the patient through registration, technician workup, imaging, doctor's examination, surgical counseling and post-physician testing and checkout works well, and offers useful tools for analyzing patient flow and technician efficiency. We are using this to evaluate our clinic logistics more objectively, and to diagnose where our bottlenecks are, in hopes of reducing the rate of complaints regarding the length of retina clinic appointments.

In principle, EMR offers the potential for records searchability on fields. For retina specialists with an interest in clinical research, this is a tool not available with paper records. The true usefulness of the system depends in some degree on consistency in terminology and coding across the retina specialists using the system. For instance, if some of the retina specialists code Coats Disease as 362.12 and others as 362.83 plus 362.81, the potential to miss cases based on differing coding patterns exists. However, by coming up with rather broad lists of possible codes, missed cases become less of a problem, at the expense of producing more case records to review that may not be true Coats Disease cases.


Additional considerations that should be taken into account when implementing EMR into a practice include the following:

Interaction with other products. EMR systems must be able to communicate with other software and hardware, in our case simply because none of the EMR systems that we have tried can do everything that we want. For example, we use a product called NotifyMD to manage our messaging to the physicians. Technicians and nurses take messages in response to medication refill requests, phone check-ins after intraocular injections, and various queries from patients on labs, follow-up, or evolution in symptoms. If the technician thinks the issue falls within his competence to address, a management decision is made and recorded on the message. Each day, the physicians read these and either sign off if they agree with the management, make the needed change if they do not, or make the disposition if the issue was deferred to the physician to handle in the first place. Presumably, the phone note module within Medflow will eventually be improved and will meet our requirements. In the interim, the EMR system must allow integration with such valuable niche products covering functions not managed by the EMR. Likewise, EMR usefulness increases in direct proportion to its interactivity with multiple ophthalmic devices such as automated refractors, visual field machines, and cameras. From the perspective of the physician, the less proprietary that products are, and the more interchangeable that they are, the better. Naturally, these goals often conflict with the marketing programs of the various EMR companies and ophthalmic device companies.

Reliability. A well designed back-up plan for all data on a regular and frequent basis is necessary. We store back-ups of data on and off site. Once in 3 years we have required the use of our back-up data to rebuild a usable system when a crucial component broke. We were forced to use paper for several hours during this outage. We have a dedicated information technology staff who constantly monitor system performance. In general, the system has been reliable.

Economics. At the outset, it was the hope of our practice that EMR would reduce our overhead, but this has not been the reality. Whereas the expenses associated with storing paper records and salary expenses of medical records personnel have been eliminated, the costs for servers, T1 lines, storage devices, and information technology support staff have at least equaled the saved expenses, and probably have exceeded them. That is, conversion to EMR, at least in a large, multispecialty group with multiple locations, will probably add to your overhead — not reduce it. In our view, even if we have a higher overhead, the switch has been one we would do again, as we eliminated the problem of lost charts and seeing patients for whom we lacked the necessary medical data.


The transition to EMR for a retina practice is probably getting easier with time simply because it is occurring more often. The pitfalls have largely been identified, but it still requires patience and goodwill among the physicians making the switch. The reasons to switch to EMR are twofold: Patient care is improved and the momentum of the profession in that direction is inexorable. A practice will have to do it sooner or later. Perhaps an economic argument to support a switch will eventually develop, but that does not currently seem to be the case. Most likely, the many sources of EMR will be winnowed to a smaller set of better products. From our experience, specialty-specific EMR may be most attractive for retina physicians for the near future. When you decide to make the switch, I recommend that you visit some predecessors and watch how they use their product. By seeing how EMR is used in real situations, you will benefit with tips on practices to adopt and practices to avoid. RP