Identifying unintended consequences is the first step towards remediating them. It is important to have the capacity to detect unintended consequences as they emerge, and not just retrospectively.

In Module II we suggested a set of usage metrics and a user survey that can be administered periodically to assess the users' experience and satisfaction with the EHR. These tools are designed for periodic retrospective assessment, but they are not likely to be as useful for rapid detection of emergent unintended consequences.

An "Issues Log" is a tool for identifying emergent unintended consequences. The Log can take many forms and vary widely in its level of sophistication. A basic Log is simply a repository for collecting information about problems related to the implementation and use of the EHR. The Log should not be just a repository for software glitches or malfunctions, or even a log of incidents or "near misses" (where problems with EHR-disrupted patient care could have resulted in patient harm). These items should certainly be recorded in the Log, but it should be more expansive and include reports of more subtle issues that could conceivably lead to problems in the future. For example:

"A physician complains that the templated clinical notes generated in the EHR are bloated and virtually unreadable because they are filled with auto generated text and text copied and pasted from other sources"

OR

"Nurses report that since installation of the EHR they have less opportunity to talk with physicians about how patients are responding to medications."

Capturing issues like these that could potentially be hazardous will help address them at an early stage before they become serious problems.

There are a several considerations involved in creating and maintaining an Issues Log:

1. Who maintains the log? This might be a vice president of the hospital, an associate chief medical officer, the office manager at a medical practice, the chief quality officer, the risk management department, or others. The important thing is that the designated person has the authority to act on the information. For it to be complete and helpful, the log must be unbiased — not censored or filtered (even unintentionally) in favor or against the institution, the vendor, those implementing the EHR, or by one user group in the institution or practice. It's also important to avoid assuming that problems noted in the log typically result from "user errors," rather than design problems, unintended consequences, or other factors.
2. Who reports problems to the log? Encourage all end users (doctors, nurses, pharmacists, technicians) and IT staff to report problems encountered when setting up or using the EHR. More reports are better than fewer reports. You can always reject a frivolous report, but you can't act on a report you've never received. Collect all issues, problems, and unexpected situations from all sources. All problems — even problems that are clearly "user errors" — have consequences. If confidentiality or anonymity will increase the number of people reporting, then be sure to offer it and strictly abide by your offer.
3. How is information collected for the log? This depends on the size and resources of your organization. In smaller organizations the most effective means to collect reports may be through face-to-face conversations or an anonymous suggestion box. Larger organizations may have the resources to support a dedicated help desk or an anonymous web-based reporting system.
4. What information is collected in the log? The Issues Log should include a detailed description of the issue as well as information about potential risks that the issue poses or incidents that have occurred as a result of the issue. The Issues Log can also include information about the issue and corrective actions that should be taken.