Automating Healthcare
Solving business problems with savvy automation

System Access — Use It or Lose It

Business problem
SarbOx, HIPAA, or TJX — take your pick. Doesn't matter whether it's fear of regulators or fear of fallout from a security breach or both — every business needs tight control of all system access. The hardest part is ensuring that access, once granted, is removed promptly when workers

  • leave,
  • change job roles, or
  • don't use the account.

"Elvis has left the building"
We need two separate and distinct sets of processes to track terminations of employees and non-employees:

  • For employees, we use termination data from the payroll system (Who works here?).
  • For non-employees, we create "positions" to give managers a familiar paradigm. Like employees, each position is assigned to a department and account code, has a supervisor, and there is no limit on the number of positions for any individual.

Unlike regular employees, non-employee positions have an expiration date of no more than one year in the future, forcing the non-employee's supervisor to renew the position annually. Without renewal, the position automatically expires — the equivalent of a termination.

When an employee is terminated, or a non-employee's final position (if they have more than one) expires, all system accounts for that worker are flagged in our homegrown user access application. The network account is automatically inactivated by a daily, scripted process, and all relevant system administrators are automatically notified to cancel accounts.

Musical chairs
Any organization has a certain amount of worker "churn" as staff are promoted, demoted or transferred. New responsibilities may require different system access, so every job change must be reviewed by the user access team.

User rights in major systems are grouped into generic job roles to minimize individually-customized rights. An automated process sends a daily e-mail to the user access team, listing any job changes in the past 24 hours, and system rights are modified as necessary.

Use it or lose it
If a system account is really needed, it will be used regularly. If it isn't used, it is simply one more vector for attack on the system, and should be inactivated. This principle is really just as important as closing accounts for terminated workers, but is not always given the same attention.

Now that we had data about last login for each account (System Access — Who Has What?), we could implement a security policy inactivating any system account that has not been used for 90 days. The only exception is the network login, which is left active as long as there is any active system account.

On the 23rd of each month, an automated process sends e-mails advising of any accounts that will be closed during the following calendar month.

  • To supervisor of anyone with unused account(s), a list of all unused accounts for supervised workers; and,
  • To worker with unused account(s), a list of any unused account(s).

If the account is no longer needed, no action is required by either supervisor or worker. If the account is still needed, the worker simply needs to use the account at least once prior to the date listed in the e-mail

Sample e-mail to worker with unused account

From: Intranet
Sent: Tuesday, August 23, 2005 7:20 AM
To: Smith, John
Subject: Account cancellation warnings, user notice


NOTICE: System account cancellation(s)

PLEASE DO NOT REPLY TO THIS MESSAGE. Read below for further information.

After reviewing this information if you have any questions or concerns, please contact the IT Help Desk at 781.555.5555 (x5555).

To ensure proper system security, all system accounts that are not used for 90 days are automatically canceled. The following account(s) will be canceled after the date(s) shown, because the accounts are not being used. If there is still a need for the account(s), cancellation can be avoided by using the account prior to the date shown. This should only occur if there is still a valid need for the account.

SMITH,JOHN    Title: Physician

System  Username  Deactivation date
------  --------  -----------------
PACS    jsmith3   Sep 11 2005
Last Logon: Jun 13 2005 3:01PM

This process has worked beautifully for several years. We no longer have unused accounts cluttering our domain controllers and clinical systems. There have been only a few complaints, none of them serious enough to make us reconsider this policy.

Lessons learned

  • With solid data about accounts and usage, it is possible to have tight control over accounts, using fairly simple automated processes.
  • Managers will support good security measures if they are clearly explained and there are no surprises along the way.

Posted 19 March 2008


Custom Applications
ADT Event Alerts
Clinical Operations

Integrated Clerkship

On-call Schedules
People Profiles
Chronic Disease

Security Badge Requests
Charge Capture
Mental Health Treatment
      Plan Tracking

Earned Time Calculator

Supervisory Tree
E-mail Distribution Lists
User Access Requests
HR Requests
Employee Health &

Interpreter Dispatching
Generic Patient Registry
Conference Room

Tuition Reimbursement
Equipment Rental
Code Cart Tracking
Nursing Audits

Show me the data
Growing a Data

Building a Data Portal
Reporting on Full Auto

Intranet Design
Driving With Databases
Speeding with Static

Transparent Security
      and Permissions

Redesigning the

Who works here?
Organizational buckets
System access: Who
      has what?

System access: Use
      it or lose it

Integrating Security

Integrating Provider

Creating A Supervisory

Data Quality Dashboard


RSS Feed