SHIFT PATTERNS

Scheduling work shifts is one of the most common and underestimated problems of modern organizations. It’s a vexing problem that can torpedo a system’s effectiveness. These are lessons learned from a recent project that needed a scheduling solution in order to be considered a success.

A department’s workload determines the shift patterns that it can adopt. Any scheduling decisions need to start with a clear understanding of the workload.

The workload needs to be converted into a number. This is the number of staff members that are needed to perform the workload. A level workload is easier to schedule than a seasonal or variable workload.

AREAS OF CONCERN

Scheduling difficulties always occur around holidays. After holidays the second most common area of concern is absences. The two remaining areas of concern are events that disrupt the staff from meeting the workload. These are training and breaks. Team training can be especially challenging. Breaks that occur due to staff fatigue will occur frequently in environments that have two or three shifts.

A significant difference exists between anticipated and unanticipated events. For example, many problems associated with training can be avoided by furnishing advance notice to the concerned staff. People generally dislike workplace surprises and they will appreciate any advance notice. Notification must be significant however. Being notified one, two, or three days is frequently inadequate. These notices are especially inadequate if the days span a weekend. Staff members will usually perceive this type of notice as last-minute maneuvers instead of advance notice.

HEALTHCARE-SPECIFIC CONCERNS

Horror stories abound about wrong limbs being amputated or procedures being performed on the wrong patients. When these cases of mistaken limbs or mistaken identities are investigated, a contributing factor is frequently miscommunication, or missed communication, between physicians or nurses who work in different shifts. The handover from one shift to the next is typically transmitted through written notes. Verbal information happens too infrequently, too randomly, and too incompletely to be considered unreliable.

The problem is exacerbated by two things. First is the mental and physical condition of the incoming shift worker. And second is the number and type of the incoming shift worker. Second- and third-shifts are usually populated with the more junior staff members. Among doctors these would be the new residents. Among nurses these would be the recent graduates. This situation means that the organization has less experience and less training at night. It’s a fair statement to make that from 5 pm to 7 am, most organizations have less of everything: less experienced and less trained workers and fewer of them at that. Conversely, it’s also fair to state that patients face more risk between those hours.

What can be done about this? Not much realistically. Statistics show that mortality rates are much higher during these hours. Patients can do their part by speaking up but too often patients are unable or unwilling to do that.

IMPLEMENTATION

After shift patterns have been created, the next step may either have the most problems or none at all. These extremes—problem-ridden or smooth sailing—will depend upon the terms and conditions of employment and the current state of labor relations. At many organizations, the terms and conditions of employment were written by people who are unfamiliar with the nuances of second- and third-shift conditions. Lawyers may work late into their evenings but I don’t know of any who work at 24 x 7 law firms. At many organizations, the current state of relations between management and rank-and-file dictates the ease or even possibility of implementing shift pattern problems. One can be repeatedly frustrated by these two issues. For example, common definitions may prevent any agreement. Days and weeks tend to have different connotations for second- and third-shift workers. Fortunately, or unfortunately, the prevalence of part-time workers sidesteps these two issues.

GENUINE CONSIDERATION LEADS TO EFFECTIVE SOLUTIONS

With all these said, the most important factor in solving shift-related problems is consideration. Shift patterns affect people’s lives. Genuine consideration for the impact that abrupt or excessive changes make to people’s lives goes a long way in creating suitable shift patterns.

LESSONS FROM CONDUCTING A SECURITY GAP ANALYSIS

There are many reasons for ensuring that you have a secure information system. It becomes a question of how instead of why. How do you create and maintain a secure system?

I participated in my first security gap analysis project in 2006, blogged it that year, lost that blog, and found my notes again. It was an eye-opening experience especially since it was conducted in one of the largest hospitals—whether public or private—in the country. It serves the second most populous county in the U.S. According to 2006 US Census Bureau estimates, the county had 5.3 million residents—larger than the populations of 29 individual U.S. states or the combined populations of the six smallest US states.

There are many reasons for ensuring that you have a secure information system. It becomes a question of how instead of why. How do you create and maintain a secure system? Starting with what you have, the first step is to create a baseline—a model of your expectations about the security of your information system. If your business belongs to one of several industries that are governed by laws and regulations then you should start with the security requirements of those same laws and regulations.

A hospital, for instance, would be directly governed by the Health Insurance Portability & Accountability Act (HIPAA). It is also subject to other regulations like the eDiscovery rules but we will keep it simple by focusing on HIPAA alone.

The second step is to categorize the sensitivity of your data, identify its source, its location within the system, how its accessed, and who can access it.

Sensitive data can take the form of intellectual property. For a hospital, sensitive data is frequently legally protected. An example is the X-ray images of a patient.

Armed with this information, you can begin your gap analysis. Before this discussion goes further, it must be understood that gap analysis is an ongoing process. The environment is constantly changing. Your information system is constantly changing with it and, naturally, your security gaps are changing as well.

Comparing your actual practices with security requirements will identify the gaps in your system. Once identified, the gaps can be prioritized (by severity, for instance). Then a plan can be created for eliminating (or at least minimizing) those vulnerabilities.

Gap analysis is a specialized form of risk analysis. Risk analysis recognizes the fact that risks are everywhere and that you have limited resources to deal with them. The goal of risk analysis, therefore, is to learn how to deploy your resources in the most effective manner to eliminate or minimize the worst or most likely threats.

It is best to approach gap analysis as a project and like any project, senior management must support it. Security gap analysis must be conducted on a regular basis. It must be thorough and objective. The degree of thoroughness will establish the scope of the analysis. Will the project include physical as well as electronic security? Will it be limited to customer-facing applications?

Objectivity requires a fresh set of eyes. It wouldn’t make sense for an accountant to audit himself. It makes a lot of sense therefore to hire an outside firm to lead the project.

These are the lessons I learned when we conducted a security gap analysis at one of the largest hospitals—whether public or private—in the country.

Our presence was announced with a bang! When you stage a systems break-in, attack the system like a team of hackers would. A team attack is just as likely to happen in real life as a solitary attempt would. The ease and speed of our break-in convinced the hospital’s administration of the risks it faced.

Your project team should have members from different disciplines. I came away convinced that if the core team could only have two groups then the two should be your IT and your HR departments. Why HR? It’s because people will be the primary source of vulnerabilities.

Hospitals are very politicized organizations. In addition to having senior management’s blessing, we created a RACI matrix that was jointly accepted by all department heads.

RACI stands for Responsible-Accountable-Consulted-Informed. A RACI matrix will identify the authority and responsibility of all roles involved in the project. We had determined that our scope was going to be limited to electronic security and to customer-facing applications only. Due to the size of the hospital and the number of applications it ran, our gap analysis focused on the two most heavily implemented applications: lab and accounting.

This was the first gap analysis conducted on this hospital and the spotlight was on it. (And did it ever need it!)

WE ANALYZED THE GAP IN FIVE AREAS

FIRST AREA

AAA – Authorization, Access, and Accounting on an enterprise level. This included single sign-on, a primary aspect of federated identity. Our goal was to standardize the security infrastructure. We discovered numerous instances where Nurse-A could log in at Station-1, stay logged in while logging in again as herself at Station-2, and be granted a different access level.

All current authentication processes were reviewed. Possible vendor solutions were evaluated. A general implementation plan was developed.

SECOND AREA

Awareness. How security-conscious are the employees? Did they know about the different security levels of information?

1. Unclassified
   
2. Classified
   
3. Confidential
   
4. Restricted
   
5. Secret
   
6. Top Secret

Our goal was to heighten the security awareness of workers throughout the organization. Make it clear that this is everyone’s responsibility and request for their cooperation. A regular familiarization course was developed and all employees have to attend it every six months. A hotline was also established.

THIRD AREA

Incident Notification & Response. The security awareness course and the hotline are just two of the responsibilities of a new IT-based group. Our goal was to create a first-response team and proactive overseer of enterprise security. They did not make policy; instead they implemented it. At the same time, they tracked actual user practices, compared it to best practices, and submitted progress reports to the Chief Security Officer (a position that was newly created).

FOURTH AREA

Technical Security. We conducted a comprehensive review of the existing security framework. The framework covered firewalls, DMZs, intrusion detection & prevention tools, and the like. Security logs were audited. Patch management was taken seriously. Password policies were enacted. Our goal was to optimize the hospital’s technical security. These efforts were primarily focused at the hospital’s data center. Technical security briefly touched on Disaster Recovery but DR was going to be a separate project.

FIFTH AREA

Best Practices. Our objective was to train users to work using best practices. This was easier said than done since this was change management and most of the staff were lifers, i.e., employees of long tenure. We had to start over several times. In the end, we learned that the best way to coax them to accept change was to first listen to them. This is the area where our business analysts really proved their worth!

CONCLUSION

Several areas above, e.g., Technical Security and Best Practices, were longer and more difficult than expected. The entire project took eight months—two months past schedule and 40% over budget! The core project team consisted of three full-time members. I was one of them.

Would I consider it successful? Yes. We achieved the project's goals. Were the customers happy? The end-users were. Management was not. From the beginning, we articulated to senior management that they had an unrealistic schedule especially because they were ripping out an old application software system. Delays cost money.

At the project onset, they practiced an all too familiar but ill-advised tactic. They asked us for a "realistic" budget. We were outside consultants. Specifically we were the subcontractors of a (politically-connected) contractor. We used parametric and bottom-up estimates, got the agreement from our contractor, and we jointly submitted it to hospital management.

I remember the incident vividly. We were in the office of the hospital administrator. He glanced at it, asked us a few questions, crossed out our figure, deducted 30%, and wrote that down and signed off beside his scribbled amount. Furthermore, he slashed a month of our projected schedule.