BACKGROUND: Patient portals are becoming increasingly common, but the safety of patient messages and eVisits has not been well studied. Unlike patient-to-nurse telephonic communication, patient messages and eVisits involve an asynchronous process that could be hazardous if patients were using it for time-sensitive symptoms such as chest pain or dyspnea. METHODS: We retrospectively analyzed 7322 messages (6430 secure messages and 892 eVisits). To assess the overall risk associated with the messages, we looked for deaths within 30 days of the message and hospitalizations and emergency department (ED) visits within 7 days following the message. We also examined message content for symptoms of chest pain, breathing concerns, and other symptoms associated with high risk. RESULTS: Two deaths occurred within 30 days of a patient-generated message, but were not related to the message. There were six hospitalizations related to a previous secure message (0.09% of secure messages), and two hospitalizations related to a previous eVisit (0.22% of eVisits). High-risk symptoms were present in 3.5% of messages but a subject line search to identify these high-risk messages had a sensitivity of only 15% and a positive predictive value of 29%. CONCLUSIONS: Patients use portal messages 3.5% of the time for potentially high-risk symptoms of chest pain, breathing concerns, abdominal pain, palpitations, lightheadedness, and vomiting. Death, hospitalization, or an ED visit was an infrequent outcome following a secure message or eVisit. Screening the message subject line for high-risk symptoms was not successful in identifying high-risk message content.

The results of an empirical study of software error detection using self checks and N-version voting are presented. Working independently, each of 24 programmers first prepared a set of self checks using just the requirements specification of an aerospace application, and then each added self checks to an existing implementation of that specification. The modified programs were executed to measure the error-detection performance of the checks and to compare this with error detection using simple voting among multiple versions. The analysis of the checks revealed that there are great differences in the ability of individual programmers to design effective checks. It was found that some checks that might have been effective failed to detect an error because they were badly placed, and there were numerous instances of checks signaling nonexistent errors. In general, specification-based checks alone were not as effective as specification-based checks combined with code-based checks. Self checks made it possible to identify faults that had not been detected previously by voting 28 versions of the program over a million randomly generated inputs. This appeared to result from the fact that the self checks could examine the internal state of the executing program, whereas voting examines only final results of computations. If internal states had to be identical in N-version voting systems, then there would be no reason to write multiple versions.>