Automating Healthcare
Solving business problems with savvy automation

HR Requests

Business problem
The human resources department was using Word documents, circulated via e-mail, as the means for managers to place all types of requests. The process provided no real controls, no way to track requests, and was generally confusing. For an organization with thousands of payroll employees, this was unacceptable. We needed a systematic way to handle the transactions between staff and managers and the HR department.

Electronic vs. paper
The first step was an analysis of all HR transactions to determine which ones required a piece of paper. This revealed that requests placed directly by staff, with one exception, require a physical signature on a piece of paper. An on-line request process is irrelevant for these requests.

Employee requests
The best solution was to put all the printable forms onto one, easy-to-use intranet page for employees (shown below). Each of the printable forms has an "info" button, displaying the purpose of the document in a "mouse-over."

[Click the image above to see the full size image]

Address and contact information updates are the only direct staff transaction with HR which do not require a physical signature. We built a very simple process to collect these updates. The first step is verifying the identity of the person being updated, which is done by matching Social Security number against payroll records (shown below).

The current address and contact information, as stored in the Meditech payroll module, is then displayed for editing. The employee edits and submits updated information in a single step (shown below).

Manager requests
Most HR transactions can be grouped into two categories: current employees and prospective employees:

  • For current employees, all HR requests are for a modification of some information about that employee.
  • For new employees, there is a clearly-defined process for posting a position and recruiting candidates.

Recognizing this, we designed a relatively simple initial screen for managers (shown below), which gets them started down the right path for an HR request.

The first step in changing information about a current employee is selecting the correct employee (shown below). This is accomplished with the "standard" intranet worker search (a common module used by all intranet applications). In this case, results are limited to payroll employees.

Having found the correct employee, the manager selects the type of transaction for that employee. Any combination of requests may be selected (shown below). If multiple types of transactions are selected, the different requests are processed sequentially in a single transation. Address and phone changes use the same screens shown above for staff requests.

The first step in modifying the current position for an employee is selecting the position to be modified. All positions (primary and secondary) held by the employee are displayed in a picklist (shown below).

The guidelines for modifying an employee position may be displayed or hidden, at the user's discretion (shown below).

All relevant information about the selected position is displayed for the requestor (shown below). Because it is impossible to anticipate every possible variation in requests, we left the form more or less open-ended, with text boxes where the manager could describe the desired change(s), and category checkboxes at the bottom. This design provides a workable balance between flexibility and structure.

Every request must be approved by a senior manager and by a finance department budget analyst. The requestor must decide whether additional approvals are needed and the identity of any approver. (It is impossible to predict every scenario, so a flexible process works best.) Since some departments have a financial analyst or business manager who needs to be aware of any changes with a financial impact, there is a provision to send a copy of the transaction to anyone selected (shown below).

Finally, a confirmation screen summarizes the transaction for the requestor (shown below).

Secondary jobs
Teaching hospitals, busy with research grants, have a high percentage of employees with multiple part time positions. Adding a secondary position is is a two-step process, with the first step the selection of the department with the secondary job (shown below).

Next a list of all positions in the department is displayed for selection (shown below). The approval process is the same for each type of request, as shown above for status changes.

Any manager can initiate the transfer of any employee — from the manager's department or to the manager's department. The first step is to select the employee to be transferred. If the employee is not currently supervised by the requesting manager, a different screen is displayed with fewer options and some alerts (shown below).

Next the requestor selects the current position from which the employee will transfer (shown below).

Next the manager selects the department into which the employee will be transferred (shown below). The list of departments is limited to those where the requestor is the responsible manager or currently supervises employees (at any level).

Next the requestor selects a vacant position (only vacant positions are displayed) in that department (shown below).

Finally there is a confirmation screen showing the full details of the transfer (shown below).

FMLA Requests
Leave requests are an easy, two-step process. First the basic details are provided (shown below).

Finally a confirmation screen summarizes the request (shown below).

Since an employee may have multiple positions, the first step is to select the position from which the employee is being terminated (shown below).

Next the details of the termination are input (shown below).

Any approvers and reviewers are identified (shown below).

Finally the termination details are confirmed (shown below).

Posting a position
Recruitment is handled with a hosted application, originally called Webhire, now Kenexa Recruiter®.

  • Managers who wish to post a position use the form below to provide the necessary information.
  • The on-line approval process is similar to that shown above for modifying an employee position, with additional approval steps.
  • Once approved, the posting is loaded into Kenexa Recruiter by an automated process, and HR proceeds with recruitment.


  • HR Requests has worked well for everyone. It provides an efficient process for approvals, clear communication with HR, and easy tracking of requests.

Lessons learned

  • We initially thought we should have managers select the category of request, so requests could automatically be routed to the correct person in HR. We quickly realized that managers cannot be expected to understand the nuances of HR internal processes. We send all requests to a single "bucket" for HR to triage and redirect to the appropriate person.
  • Posting a position was, for several years, a two-part process. Managers first completed the intranet request to post, and then had to input the same information into Webhire/Kenexa Recruiter. This was frustrating, and recently we were able to automate the process of loading the posting into Kenexa Recruiter. We probably should have done this initially, but at the time it did not seem feasible.
  • Handling approvals on-line is a "double-edged sword." It is very efficient, but if the approval process is complicated and changes regularly, it can become a time sink for the developer. This has been a problem with HR Requests. If there's a good solution for this, I'd love to hear it!

Posted 6 August 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