EHR and data management

The Next Frontier in Electronic Health Records

Should you import test results into your EHR system? The answer is tricky.

JOHN WARREN, O.D. Racine, Wis.
JOHN McDANIEL, O.D. Waukesha, Wis.

With the incredible increase in technology in eye care, managing ocular images and information represents a significant challenge.

In the past, instruments, such as visual field analyzers and topographers, printed the results of exams, and you or your staff filed the printouts in the patient's paper medical record. This is "static" or "flat" data; data you can view, but not manipulate as you can with new instruments that have analysis software, which unleashes the power of these instruments.

As more practices set up local area networks (LANs, or those computer networks that cover a small geographic area, such as an office), it became practical to view the results of tests in any location (i.e. the exam room) containing a computer monitor.

This arrangement allows on-demand viewing of the data. Also, through the use of software built into the diagnostic instruments, or "native software," the system may allow such functionality as sequential data analysis, trend analysis and progression analysis in addition to advanced contact-lens fitting with some topography systems. This approach yields "dynamic" or "live" data.

Integrating data into EHR

How to best integrate data from electronic health records (EHR) and electronic instruments is an ongoing issue for healthcare providers, no matter what type of EHR system you use. If you choose to continue with only static data available, you can load individual exam results and reports into the EHR, either by electronic data transfer or manual keystrokes.

The issue becomes more complicated with dynamic data, however, because the EHR system doesn't contain the software to allows for real-time analysis and manipulation of exam data. If you want to retain all the functions and features of your advanced electronic instrumentation that yields dynamic data, you'll need to view and analyze the output within the native software created specifically for the device.

This situation doesn't necessarily limit your ability to view test results through only the device itself, however. Many electronic instruments now have "remote viewer" software solutions that allow you to view and manipulate the output at computer workstations other than the station that operates the instrument.

Computerized Corneal Topography (CCT) data provides a good example of the issues involved in data integration with EHR systems. While you can display the majority of the information you gather at the initial exam on a static report, these data are even more useful when combined with later exam data to measure changes through time. You may find these changes desirable (LASIK or Ortho-K outcomes or recovery from corneal warpage) or undesirable (corneal warpage by an inverted soft contact lens or improperly fit or warped rigid lens). By using the native software to create a difference map, which compares the second exam to the first, you can calculate and display the actual change.

The EHR system can print static results of each exam, but it doesn't contain the native software necessary to create dynamic data. With EHR, therefore, you can visually compare reports. While you can appreciate the presence or lack of change through this visual comparison, you won't be able to understand the magnitude and exact locations of the change without the dynamic data presented in a difference map.

The clinical advantage of having live data becomes quite obvious for instruments, such as corneal topographers, visual field analyzers, scanning laser ophthalmoscopes (OCT, GDx, HRT III or RTA) and an OPTOS system or other fundus camera — all of which offer functionality, such as stereo viewing, progression analysis and/or image annotation and measurement.

When to import

When an instrument lacks native software that can perform change analysis or advanced data manipulation (design of contact lenses from topography, for example) or doesn't support electronic data output, importing the output from these devices into the EHR may be the best clinical option. In these cases, static and live data are identical, so you lose no functionality when importing data to EHR.

The combination autorefractor/topographer system that doesn't offer change analysis software or robust contact-lens design software is a good example of a device, in which you should output data into the EHR. This device is capable of producing only a "snapshot" of the patient's condition. This doesn't minimize the utility of the device, but it limits the future applications of the electronic output. In other words, the live and static data are essentially identical, making the decision to import the output into the EHR reasonable.

Currently, no set of universally accepted "best practices" for the clinical management, utilization and storage of these types of data exists. (For the authors' proposed best practices, see "Best Practices for Data Storage by Category," above.) Once a set of best practices exists, building better office systems and software/hardware systems will be productive. For too long, eyecare providers and manufacturers have "made things fit" into a system, rather than designing a system to fit the needs of patients and providers.

Data storage methods

Most electronic examination devices either store data on a local hard drive in a self-contained manner, or they export data to another computer and remove the exam data from the device.

In the instances in which devices retain data, the data may or may not be available to other computers on the LAN — this depends on the device's functionality. From the information technology (IT) management perspective, it's typically simple to install devices in which output is limited because you don't have to concern yourself with the connectivity between the device and the office's computer system. With this simple system, however, utilization of the data — other than physically at the device with static reporting/printout — is greatly restricted.

When you store data outside the device itself, access to the data and manipulation/exam is much more feasible than devices that have limited output. These devices may require more installation and/or configuration work than devices in which output is limited, but the return on investment is immediate and can be dramatic. An example: Once finished performing a test with a "networked" diagnostic device in the exam room, you can view dynamic results with the patient at another computer monitor — freeing the device for more tests.

Regardless of data location, whether it be local to the device or on a neighboring or networked computer, you must back up data on a regular basis.

Data categories

Just as the devices available for ocular examination and analysis vary greatly, so do the resulting data types. By categorizing data by type, you can determine best practices for the storage, display and potential manipulation of the data.

I am proposing the following data categories:

Numerical and/or Text data only:
► These originate from devices, such as autorefractors, lensometers, keratometers. etc.
► You may sequentially analyze this data for change through time, patient demographics, etc.
► Comparison to normative databases is very limited for this data type (though theoretically plausible).

Numerical and/or Graphical data:
► This data originates from devices, such as visual field analyzers, scanning laser ophthalmoscopes, topographers, etc.
► Sequential analysis, filtering, manipulation (especially graphical data) are critical in the utilization of this data.
► Analysis frequently requires "native" software applications to accurately interpret and analyze the data.
► You may or may not need to reprocess data for each analysis performed.
► You frequently perform comparisons to normative databases.

Purely Graphical/Image data:
► Fundus photography, digital slit-lamp image capture and external ocular photography are examples of this type of data.
► Qualitative comparison to previous examination is possible, quantitative analysis isn't typically possible.
► You don't compare data to normative databases.

Data access

When you import and store data in an EHR, the EHR displays and analyzes it only. Access occurs via the EHR's interface only.

When you don't import or store data in the EHR, the native software's interface analyzes and displays it. The native software's interface may or may not contain a link from the patient record in the EHR directly to the patient's information.

As EHR standards become uniform, EHR interfaces are likely to develop a means by which you can access the native environments data and data analysis outputs from within the EHR interface in a more seamless fashion. OM