Timeouts for Clinical Applications

I've recently been asked to describe our approach to security timeouts for clinical applications. Maintaining confidentiality of healthcare data is a balance between ease of use and bullet proof security. In an ultimately secure configuration, all logins would require hardware tokens, timeouts would be under a minute, and no remote access would be available. Clearly, such restrictions would be very secure, but so hard to use that patient care may suffer. As an analogy, I tell my staff that the most secure library would never allow its books to be checked out.

What have we done? Virtually all our applications are web-based and we've set a 20 minute timeout for all the web applications we create. Additionally, we have a 20 minute timeout on our SSLVPN for remote access, and a 20 minute timeout for Citrix access. In our experience, 20 minute timeouts enable clinicians to login, check results, talk to patients, complete a note, write prescriptions, and keep the office running without requiring a frustrating number of logins each day.

The one area where we've used a different approach is the fast paced Emergency Department.

The ED is a challenging computing environment - dozens of users are sharing relatively few machines for just a few minutes at a time. Interruptions are common and although we reinforce the importance of logging off, a security model cannot rely on people remembering to do that. The computer must determine whether the authenticated user is still present and if not, it must restrict access to private data.

Ideally, the computer would use physical detection such as face recognition or signals from an RFID chip on (or in) the user. However, widespread implementation of these systems is complex and expensive, so in most cases the computer must try to infer user presence from available data.

The ED Dashboard is a web based application that uses javascript to detect mouse movement and typing. If three minutes go by without the user moving the mouse or typing a key it will assume they have left and close the browser's window, hiding all PHI. To avoid closing the window on a user who is still working, there is an indicator that shows the countdown and slowly blinks when 30 seconds remain. As the time approaches zero, the blinking becomes faster and more frenetic in an attempt to catch the eye of the user, if they are still present. A simple twitch of the mouse is all that's needed -- that resets the timer back to three minutes. If the user does not respond in the allotted time, the system initiates a log off sequence that first saves their work before closing the window.

For the current application and use, three minutes strikes the right balance-- if the user is actively working on the computer, the timer will invisibly reset as a side-effect of their work. If they are sitting and reading a note or talking, then wiggling the mouse once every few minutes is a minor imposition.

New functionality, such as clinical documentation and mobile computing are changing the way people use these systems, and requires re-evaluation of this setup. We are also looking at biometric login capabilities to make secure login much easier and therefore the lessen the inconvenience of timing out.

In addition to all these timeout features, we have a comprehensive access auditing system. Auditing is an often overlooked but important adjunct to timeouts. A decade ago, we began with a manual review of access made by users each month. When then implemented an automated report. We added IP location information to the report and started tracking accesses from unusual locations. Our next steps are to continue to add more systems into the audit and to enhance the sophistication of the automation. Our ultimate goal is to run nightly heuristics on log information, cross walk that data with the Active Directory logs, network logs and historical patterns to identify any accesses that look questionable for manual review.