In This Chapter
The Medical Center of Central Georgia
Independence Blue Cross
Sisters of Mercy Health System
Partners HealthCare
The U.S. health care industry is facing a perfect storm of challenges. The Health Insurance Portability and Accountability Act (HIPAA) and other government regulations require providers to adhere to national standards for electronic records and transactions. Health care providers and payers must cope with many other pressures, including an aging population, a growing number of people without medical insurance, falling government reimbursement rates, and a growing shortage of qualified staff members.
In this difficult environment, health care insurance companies need to manage the relationships with health care providers and consumers. Pharmaceutical companies need to leverage data and best practices successfully across the entire health care system to ensure that they develop medicines to address emerging needs.
At the center of this storm, medical costs are skyrocketing. Controlling health care costs while ensuring quality of care has become a hot issue for this industry. Service management is emerging as an important strategy for meeting these challenges. Addressing problem and change management helps to decrease the down time of critical technology that clinicians and nurses use to treat patients and manage care, for example. The hospitals and insurance companies profiled in this chapter believe that service management helps reduce costs and ensure improved quality of care.
Innovation has become critical to success, so many companies are looking at ways to innovate. In this chapter, we profile four companies' service management efforts:
The Medical Center of Central Georgia is using its service management system software to automate what were traditionally inefficient and/or paper-based business processes, and to manage customer service and change management.
Independence Blue Cross deployed an operations control center to help monitor its systems and predict problems.
Sisters of Mercy Health System transformed its clinical processes. IT supported this initiative by creating a more responsive technology infrastructure.
Finally, Partners HealthCare deployed an innovative service oriented architecture strategy and is using a service catalog to help monitor the performance of its key services.
The Medical Center of Central Georgia, located in Macon, is a full-service acute-care hospital with more than 600 beds, serving about 750,000 residents. It's now the second-largest hospital in Georgia. The hospital system also includes a series of remote health care facilities; wellness centers; health clubs; and home care, home health, and hospice services throughout the city. The Medical Center of Central Georgia's core mission is to provide world-class care to its patients.
The IT department manages all servers, laptops, desktops, printers, scanners, and various applications. Five years ago, Information Services realized that it needed to improve service management and needed to automate many business processes. IT had previously deployed a homegrown system for managing problems, but the system was inadequate to meet the needs of Information Services and the organization. These inadequacies hindered process and workflow management, and eventually led to the need for a more robust system.
Ensuring high quality of care was a key concern. The IT team realized that it needed to change its approach. It began by implementing new service management software and processes and then expanded its vision to address change management. It also streamlined many of its business processes and reduced costs by using the service management software platform to automate and enforce business processes both within and outside IT.
The Medical Center's Technical Support Center (TSC) supports IT as a whole and has been particularly successful with its client services. Client services technicians travel to different locations within the organization to deal with hardware and software issues. Before the service management system was implemented, each time a technician made a repair, he had to go back to the office or rely on a paging system to get the next service ticket. According to Patrice Briley, a lead analyst at the Medical Center, this service request could be in the same area the technician just left. The technician would have to go back to the area and then back to the office.
Now the organization is divided into zones. When a ticket is entered, the system makes logical decisions as to what zones and technician the ticket should be assigned; the routing is automatic. Rather than going back to a central area to get the next assignment or waiting for the TSC to make contact manually, the technician simply receives the next assignment by pager or e-mail. The actual work request is entered into the system, along with the necessary information to allow the system to process automatically. This new process also helps to improve quality of care by enabling the technicians to address problems faster and more efficiently. One big advantage of this approach, says systems analyst Isaac Ramsingh, is that the technicians "can be mobile rather than being tied to a physical computer or depending on an unreliable process to get the information they need. This has improved productivity tremendously."
The same system is used for change control management. Any request for changes to systems is entered into the application. An automatic approval process is then initiated, with the appropriate managers reviewing and approving or denying the request for change as appropriate. Reports from this system also drive committees responsible for managing changes, ensuring that each change is communicated effectively and any possible ill effects are identified. The intent is to thoroughly understand system interactions and proactively manage system changes.
The IT team is using the service management software platform to automate some of the manual, paper-intensive processes that encumbered IT productivity for years. One example is providing security access to systems for new employees. In the past, this task involved a paper-based process that may have involved as many as 10 or 11 system administrators. Now the new system takes the original request and splits it so that a subticket is sent to each system administrator involved, and manages the process of granting access to each of the systems required. New employees, or employees who have had their system access changed, can now sign into a centralized and secure Web page to retrieve all their system access information, like user IDs and passwords, along with documentation for each of their systems.
By leveraging the technology upon which the service management software was built the team has already developed nearly 20 independent applications to automate and manage various diverse processes. This kind of automation enables the company to cut costs, streamline business processes, and ensure adherence to policies and procedures.
Briley and Ramsingh mention several best practices that have emerged over the course of the Medical Center of Central Georgia's service management journey, including the following:
Bring the customer in up front. When you are creating a system, it is important to get the users and business experts involved. This ensures the needs of the users are met and fosters a sense of ownership. This sense of ownership and buy-in results in greater acceptance and a better end product for everyone. According to Briley and Ramsingh, if you don't get the right folks involved at the onset of a project, it can result in a system that is poorly designed and not well accepted.
Communicate. Communication is critical, especially when it comes to patient care. Being informed helps the staff take the necessary steps to ensure quality of care is not compromised. The TSC has become a single point of contact for dispersing information throughout the organization.
Build a knowledge base. As a problem occurs, it is important to document the steps taken toward resolution. The next time the problem occurs, resolution can be reached more quickly. The end result is better customer service.
Independence Blue Cross (IBC) and its subsidiaries are the Philadelphia region's largest health insurers, with more than 3.4 million members. The company offers products and services such as managed care, traditional indemnity, pharmacy benefits management, Medicare, and Medicaid. IBC annually processes more than 32 million claims and responds to more than 6 million customer inquiries. IBC's information technology organization manages hundreds of applications that cover a wide area of business needs, from internal e-mail to external customer-facing systems. These include mission-critical solutions vital to the company's success, in which unscheduled down time is not an option. For example, an outage during the critical enrollment period could greatly hinder an individual's ability to choose an appropriate insurance product.
In 2002, IBC initiated a grass-roots movement to implement the Information Technology Infrastructure Library (ITIL) framework to improve the provisioning and control of IT services such as incident and problem management. Although the objectives were on the right track, the effort failed to gain traction for several reasons. First, it didn't address key issues such as root cause analysis, notifications, and escalation. Also, although IBC had a change management process in place, it was weak in that it was loosely mandated and had no transparency or accountability structure, and its Web-based environment was unpredictable.
Fortunately, a more recent review and overhaul of the process has allowed IBC's Information Technology Team to institutionalize a vastly improved ITIL methodology, adding executive-level support and proactive capabilities. A crucial organizational change was the addition of an Operational Control Center (OCC), which monitors the systems and applications across the enterprise from the customer's point of view, thereby providing substantial business value.
When Nick Robak, senior director of technology services, joined the team in 2005, he quickly saw a critical issue: the staff was handling incidents, but there was lack of accountability for any particular problem. This and other deficiencies in the service management process fueled the organization's effort to gain more control of resources as well as more credibility with the business.
With the assistance of systems integrator Liquid Hub, IBC pored through the hundreds of applications that it manages and assigned severity codes for problem classification. An example of a priority-one application is the one that all agents and brokers use when working with customers. This application provides customers comprehensive information about their policies and how those policies are set up. If that application becomes unavailable during the high-revenue or enrollment seasons, the company can be seriously affected.
After assigning the severity codes, IT identified the precise response mechanism that would be used to resolve each problem. Robak's team ensured that there was a well-defined and broadly communicated problem escalation, notification, and communication process. All details of the process were negotiated with the sponsors and stakeholders over a period of several months. This resulted in consensus by all parties, and allowed the incident and problem management process to be tightly governed by IT. The company quickly began reaping rewards. For example, the average time to repair has decreased by 50 percent.
Additionally, IT implemented a strict change-control process that, along with incident and problem management, has lowered the number of priority-one problems by 50 percent. "Before we focused the team on change management," Robak says, "certain areas of the organization utilized a change management process, while others didn't; we needed consistency." IT instituted a more orderly and enforceable change management policy that includes, for example, submitting change notices before changes can occur.
After IBC implemented these improved incident, problem, and change management processes, it examined how to proactively identify issues before they became problems. As is typical at many large companies, when an incident occurs, everyone from the database person to the network and applications person might be asked to help solve the problem. Needless to say, this process is inefficient and unnecessarily drains resources. The goal was to move away from a purely reactive service desk that only addressed problems as they happened, and move toward the ability to show a holistic picture of service to the end user which includes proactive capabilities. To do this, the team looked at its services from the end-user perspective, gaining an end-to-end view of all the elements that make up a service, each of which could be monitored.
The idea to monitor services from an end-user perspective led to the creation of the OCC, which has a four-part mission:
Proactively monitor the performance of critical business and technology services
Routinely report ongoing operational metrics with a focus on improving them to match changing business priorities
Coordinate performance improvements to resolve more incidents before they affect the consumer
Deliver innovative solutions in process improvement, service quality, and increased systems performance to meet service-level agreements (SLAs)
The OCC is an organization that uses staff members from across Information Technology. Its members include service desk personnel, a Web environment administrator, enterprise monitoring personnel, SLA management and reporting experts, and those with executive dashboard expertise. The goal is that when the problem management staff is notified of an event or an anomaly, they can ask whether this issue is the start of a trend, and collaboration can begin among the members of the OCC to help predict and resolve larger issues.
If the OCC sounds a bit like a network operations center (NOC), which is used to monitor communications networks, that's because in some ways it is. Like a NOC, the OCC is housed in a separate room (with glass windows) where numerous large plasma screens provide a real-time view of activity across the company's systems. Unlike a NOC, however, the OCC monitors the business processes and services from the end-user perspective.
Monitoring and measuring are big parts of what the OCC does. According to Heath Durrans, director of managed infrastructure at LiquidHub, the primary purpose of the OCC is SLA management, which in this case is really business-level management. The goal is to meet customer expectations for service. If a system is failing to meet those service level objectives, the OCC needs to find out why. The OCC wants to know and report how the business is doing this month, and how that compares to its performance last month. It constantly monitors performance against expectations. The OCC might try, for example, to predict that a certain customer-facing application may go down on a certain day because of certain behavior and trends. It tracks both the application and how that application interacts with other applications and the infrastructure. The OCC supports both internal and external applications.
One internal service that the OCC monitors is how consumers get e-mail from the mail archive. How do you determine an acceptable performance level for retrieving e-mail? To answer this question, the team openly asked end users about their expectations for this service. It also mapped out all the hops — transfer between computers — that a message goes through across the entire infrastructure to retrieve an archived item. Then the OCC employed software agents and synthetic transactions to test availability, at the specified SLAs, to the end consumer. These test transactions are developed by IT to gauge how the system will respond under specific conditions.
The OCC has been a huge success. Robak says, "It's one of those projects that happens every couple of years where you see all the lights go on. Showing real evidence of what is going on with these applications and staving off problems before they happen has created a whole lot of support."
IBC has found that its internal and external customers are much happier now. Systems go down less often, and when they do, they're fixed more quickly. The team has identified certain best practices that have helped along the way:
Benchmarking: Robak's team collected a three-month trend on service performance to use in negotiating SLAs. For example, it researched what a normal call response should be and then negotiated around that metric. However, a core OCC tenet is to not accept the norm but instead strive for service-performance excellence.
Negotiating: IT must decide how to best support the business, but at the same time recognize the importance of balancing limited resources to ensure that critical systems remain stable.
Setting priorities: IBC believes in the importance of both a unified ITIL practice that utilizes basic ITIL processes, and senior management endorsement and prioritization of these standards.
Measuring results: IBC believes in gaining transparency in IT operations via clear reporting of operational metrics. These metrics also need to have built-in accountability. IBC knows who is responsible for fixing a particular problem and when that person needs to respond. All of the measurements and trends are provided to senior management on a regular basis.
St. Louis-based Sisters of Mercy Health System (Mercy) operates 19 hospitals, physician practices, outpatient clinics, health plans, and related health and human services in Arkansas, Kansas, Louisiana, Mississippi, Missouri, Oklahoma, and Texas. Mercy is the ninth-largest Catholic health care system in the United States based on net patient service revenue.
Mercy began planning for a more integrated IT platform to serve the business and clinical needs of the health system in 2003. The initiative was motivated by Mercy's need to improve clinical service, quality, and safety while achieving operational efficiency and improving access to quality information. Mercy implemented applications to support enterprise resource planning (ERP) across its organization and to address clinical and revenue functions within its hospitals and physician clinics. Through this deployment, the health system aimed to update processes vital to quality clinical care, such as creating an electronic health record (EHR) for every Mercy patient. The EHR promised to reduce patient registration and scheduling hassles, manage and document all patient care, and aid in patient accounting. The technology infrastructure supporting these new applications demanded high levels of availability and service. Mercy had to establish a more comprehensive, integrated service management approach — and it didn't have a lot of time to complete this task when the applications went live.
Mercy's leaders, including those in the IT division, recognized the stark difference between its current state and the vision of the new deployment. A few clinical services and business processes were automated, and IT provided nearly 100 percent availability for these systems around the clock. Most clinical functions didn't heavily rely on IT infrastructure and service, however. If a doctor ordered something or created a prescription, she would write it out or dictate it.
Mercy's service desk operation needed to become more efficient to address the increased IT load from new clinicians and physicians utilizing the EHR. Additionally, in 2006, consultants examined Mercy's service management performance and found that poor processes and human error were leading to down time and other quality-of-service issues. Changes that weren't well planned or were rushed often resulted in problems. The trouble-ticketing system, which didn't distinguish among different types of problems and requests, was also causing problems: Nonurgent requests were sometimes resolved more quickly than urgent incidents.
Both senior IT and business executives agreed that they needed to strengthen the IT infrastructure and services quickly to support the project with the rock-solid availability it needed to succeed. IT leaders began talking about required uptime, planning for "3 nines" (99.99 percent availability of systems). Even at that high level, those that used Mercy's most important systems would still experience 8 hours and 46 minutes of down time per year. Additionally, it became clear that technology alone would not save the day. Equal focus on creating stronger processes was essential. Mercy needed to adopt service management and processes to ensure success. Mercy's deployment goal was very aggressive. Service desk, asset, incident, problem, change, and release management were all included in the initial six-month design period. The hospital system had many requirements for its service management solution, which had to be modular, flexible, and streamlined across different areas and processes.
Mercy leaders decided on an integrated solution to meet high availability needs. With so much infrastructure and so many applications, the team needed information to flow seamlessly from one process to the next. If an end user created a service request that then became an incident, Mercy wanted data from the request to populate the incident record automatically. If the incident required a change, Mercy wanted the system to feed the incident and change action automatically through the approval and change-authorization process. In case the fix failed, Mercy's IT staff would have clear documentation to identify changes that could have caused the failure.
To meet its six-month deadline, Mercy "wanted to affect cultural change within our IT organization, so we did a big bang," said Will Showalter, chief information officer for Mercy. With strong executive sponsorship, he recruited business-process managers and owners to help evangelize the initiative and organized "synthesis sessions" to let everyone see design and provide input. All managers attended ITIL foundations courses, and the rest of the IT crew participated in a lighter version of ITIL training before they were trained on the new tools and processes.
Michael Zucker, director of process and quality for Mercy's IT division, led the service management effort. He would have liked extra time for testing, of course, but he didn't have that luxury. Mercy's IT staff not only had to be trained in the use a new tool, but also had to adopt a more disciplined approach. With the clock ticking, Zucker knew that the initial live deployment was bound to face some hitches. "We tried to be very proactive in our communication," he says. "Executive sponsors were saying, 'We are going to do it, so accept that — and once you accept that, here's a plan to handle it.'"
Setting expectations became a top priority. Zucker's organization supplied end users and service desk staff information about potential problems and armed the service desk with guidance about how to address those problems.
This strategy helped the team navigate the inevitable bumps of the initial rollout in early 2008. Some IT staff members found the more rigorous service management process a bit cumbersome at first, but they got the message that it was important to "make sure they are thinking about it twice before taking action," Zucker remarks. Still, the time crunch took a toll; the January 2008 live deployment of the new application and processes was rough on many of Mercy's IT teams. But Mercy has been working steadily to smooth out those initial rough edges. "We might not be where we want to be yet, but we are heading in the right direction," says Showalter. "Continual process improvement and a focus on quality will always be with us."
The system now supports both infrastructure and clinical applications, serving as a single system recording work done by any of Mercy's 700 IT people. "Everything is recorded and managed here. It's our vehicle to communicate and make sure the work gets done," Showalter says. The integrated service management dashboard provides a much better reading on the health of systems and services, enabling IT to track more processes and metrics than before.
Currently, Mercy is concentrating on refining the system through better discipline and additional metrics. Mercy already tracks availability at the network level and is working to measure availability at the individual application level. "All the support processes are interrelated, and we can look at them," Zucker says. "If something breaks down, it could be any number of things. Now if a user complains about slowness, we can more easily identify the root of the problem and direct it to the right service group to get it resolved faster."
Better discipline and visibility have helped Mercy improve accuracy, deliver higher availability, and respond more effectively when an issue does arise. Staff members can now distinguish between an incident (which requires immediate attention) and a request (which isn't urgent), and apply different metrics to each.
Mercy's IT division also introduced policies and metrics regarding standard and unplanned changes, and tracks these changes with specific key performance indicators. Improved metrics and tracking help identify processes that aren't compliant. If the metric mandates that all priority-one incidents need to be resolved within eight hours, the tools enable staff to spot any metrics that look suspicious and take remedial action.
Mercy conducts regular broad customer satisfaction surveys across the organization, uses a link from the system that provides feedback and ratings on service for individual incidents, and surveys users about specific incidents. User satisfaction and other key metrics improved in all categories from January 2008 to the same time the following year.
In late 2008, Mercy installed an additional component that can move its asset-tracking functions to a configuration management database (CMDB). Currently, Mercy is adding new service-catalog functionality for different IT services to the CMDB, with 20 IT teams using the catalog management function to define individual service lines and the discrete services that they can provide to end users (and to one another). With this capability, IT staff members and users can view and order services as they would from an Internet-based retailer. Requests for infrastructure services (such as network or voice) and for clinical and business services are logged. The service catalog helps users throughout the organization find the services they need quickly and determine the right team for the job.
Going forward, Mercy's strong, consistent, and ongoing executive commitment will drive continuous improvements. The original implementation team, consisting of both business-process managers and IT personnel, now serves as a process board, discussing, prioritizing, and authorizing process changes. The application itself also helps enforce more discipline in processes and provides metrics that flag areas that are out of compliance.
Given that Mercy Health accomplished its service management transformation in record time, Mercy's IT leaders are often asked how the health system managed to get so much done in such a short time. They attribute its success to a few key factors:
Strong executive sponsorship that established service management as a critical corporate priority
Thorough evaluation and selection of comprehensive solutions that provided the necessary tools up front, as well as the ability to integrate additional components on Mercy's own schedule
Set expectations up front, and established proactive, open, and collaborative processes to facilitate change
Partners HealthCare, a not-for-profit organization, is the largest provider of medical services in Massachusetts. It was founded in 1994 by two of the top hospitals in the country, both in Boston: Brigham and Women's Hospital, and Massachusetts General Hospital. It includes large hospitals, community hospitals, primary care and specialty physicians, the two founding academic medical centers, specialty facilities, community health centers, and other health-related entities. Its goal is to provide "a continuum of coordinated high-quality care."
In 2000, Partners began to implement a service oriented architecture (SOA) strategy to share information in-network and among partners. In this way, patients can get the best possible care regardless of which facility they go to.
As Partners developed its portfolio of services, it realized that it needed a way to manage these services more effectively. Partners started a rudimentary process for vetting service requests, part of which involved arranging the services in a catalog that people could access. At first, the catalog was nothing more than a spreadsheet with information about the services; over time, it became a database that allowed users to request services.
As the services strategy evolved, IT had to provision these services and grant license to use them. This requirement set in motion a whole set of concerns related to use monitoring, performance monitoring, and security assurance. Partners needed to refine its approach to service management. This refinement included developing a monitoring and performance management strategy to ensure that services were meeting SLAs. In addition to monitoring service performance, the team made sure that it had a sound capacity management process in place so that unexpected spikes in service consumption didn't bring down the house.
You can monitor a service at many levels. One of the first things that Partners needed to monitor was whether the consuming application was authorized to use a particular service. The IT team, under the direction of Steve Flammini, chief information officer of the information services group at Partners, implemented a security gateway to examine the credentials of the service call. That way, IT confirmed an authorized user and could attribute a level of use with that consumer.
The team also monitors the performance of the service at any given time and determines whether that performance meets its SLA requirements (if a SLA has been negotiated for the service). Flammini notes that in many cases, his team negotiates a SLA that is purely between the provider and the consumer. No blanket SLA applies to all consumers. IT works with different consumers to analyze their needs. If a specific performance level is required, a cost can be established, the consuming organization agrees, and the performance level can technically be met, the SLA is implemented.
A given application may need to do a medication lookup on a medication formula, for example; that service is a standard service. According to Flammini, you don't want several applications designing their own medication lookups. This service is a core piece of functionality that should be offered in the enterprise as a service. The SLA may be that when the consuming application (such as an electronic record in which prescriptions are written) issues a call to do a drug search, that result needs to be returned within 200 milliseconds. Before the implementation, the team does some load and performance testing, and performs simulations to ensure that the service can really turn this functionality around within that amount of time.
A lot of services used by a lot of applications can mean a lot of negotiation. The team delivers high-performance services that can scale, and in most cases those services are well within the performance window of any application's potential needs. The team can deliver this result because it has a sound underlying architecture and has done ample load testing.
Service performance may be affected by how often a service is consumed, so the team also tracks consumption patterns within the infrastructure. And, when a service doesn't meet its SLA, the team has to do some diagnostic investigation to see whether the service is being overly consumed. If someone applied to consume a service 10,000 times a day but actually calls it 100,000 times a day, that's overconsumption. The team looks at the consumption pattern and the infrastructure to find hot spots.
In some cases, the team sees a much larger jump in usage on a particular service than it thought it would see. According to Flammini, the cause could be a bad design decision, an invocation bug, or explosive uptake in these services for various applications.
One example of a service that's experienced a large uptick in demand is the Enterprise Master Patient Index (EMPI), which was rolled out in 2005. In this identity-driven system, a patient's medical-record number is attached to all of his charts and paperwork. If a patient who's normally treated at one hospital in the network goes to another hospital or provider, that provider can request patient information by using these services. In effect, the EMPI is a unique customer identifier. Virtually all applications across the enterprise — whether they were developed in-house or purchased, and whether they are clinical, administrative, or data warehousing applications — depend on the EMPI as their source of patient information and identity. This service may be called upon tens of millions of times per day.
Partners on the back end must to be prepared to handle the growth. This requires capacity planning. According to Flammini, it sounds like "motherhood and apple pie" to say that you have to sit down with IT and clinical systems leadership to understand how aggressively that organization wants to push out systems and understand their growth projections. However, the IT team needs to understand these plans so they don't get caught in a growth situation they may be unable to handle.
For example, in the case of the EMPI, IT sits down with the consumer to try to understand their consumption patterns. Are they going to have to call the EMPI service a dozen times each time they open a patient record — or just once? Or are they going to continually call upon a service for data, or will they store that data locally to avoid calling repeatedly?
What happens when a problem occurs? Where does the organization turn? Partners has multiple service-provider teams that are experts in certain clinical domains such as medications or the EMPI. Each team has designers, developers, and support people who really understand the inner workings of these services and can work with consumers to resolve issues.
In addition to the specialists, Partners has a group of generalists who support the infrastructure, look at the underlying technology platform, and monitor whether CPU use is out of bounds. This group also looks at various levels of the infrastructure.
Partners has had great success with its SOA strategy, and part of that success has come from learning to manage these services. Although the need for a service management strategy was an outgrowth of a technical requirement, the result is that the company is now using its services in applications that it hadn't even imagined, and the service management strategy is enabling IT to deliver real value to the organization.