CIGNA is one of the largest health insurers in the United States, along with Aetna and United Healthcare. Including related businesses, such as dental plans, specialty medical management programs, and pharmacy benefits management, the Philadelphia-based company covers about 13 million health plan consumers.

In the insurance industry, Web services platforms are now allowing many companies to reinvent the way they use their sales channels, interact with customers, and market their products. CIGNA is one of the more aggressive firms in the employee benefits and insurance sectors using Web portals to improve its customer service.

CIGNA is offering its 16 million health and retirement plan customers Web-based portals utilizing Yahoo! Enterprise Solutions technology. CIGNA's use of portal technology, as opposed to a Web-generated customer service interface, gives its customers a higher degree of personalization and information. Unlike the generic customer service Web interfaces that customers are used to, the CIGNA/Yahoo! portal helps the company's health plan consumers manage their claims, see their own information, set preferences, and even order prescriptions using their myCIGNA.com portal page.

Eric Consolazio is senior vice president in charge of the CIGNA HealthCare information systems unit. Previously, Consolazio created and led CIGNA's eCommerce practice, which develops and implements corporate-wide strategy and technologies for e-enabling employee benefits. Before joining CIGNA in 1999, Consolazio was employed by accounting and consulting giant PricewaterhouseCoopers in New York, where he was responsible for systems integration and e-commerce within the firm's eastern region insurance practice. His responsibilities included practice development, architecture design, and systems implementation. Consolazio has also been a featured speaker at numerous industry events and has authored numerous white papers on e-commerce.

Consolazio believes that, while debate still rages about how Web services should be defined, the technology is rapidly evolving into a powerful business tool.

If you ask fifteen different people what Web services are, you'll get twenty different answers, including those who like to define Web services almost on an atomic level. For a number of reasons, we don't define it that way. For us, a Web service is something that has tangible business value. If it doesn't fulfill some type of business function, then we really don't call it a Web service.

We began implementing Web services with the rollout of the consumer portal in July 2002. Prior to then, we had been building applications, primarily for consumer self-service and for what we call provider self-service—doctors—for the last few years.

The project was begun late in December of 2001, so we were able to deliver the portal within approximately seven months. But the underpinnings of that portal were built on applications we had been building for the last two years.

For Consolazio, Web services offer the promise of a simplified way to handle a variety of different kinds of portal users: physicians, consumers, and employers.

The reason we went with Web services was that different constituents—doctors, for example—needed to see the exact same information about a health plan that the consumer himself would see. In other cases, however, they would not. In initially building self-service, we developed online "member self-service'' to serve up a person's eligibility and benefits information. In certain cases, what we wanted to do was serve up that same eligibility information for the physician.

When we were developing the portal, we wanted to be able to customize and personalize it to a person's tastes. A person may, or may not, want to see her claims, but would want to see her eligibility.

We took that monolithic application and broke it up. We basically created Java-based, XML-based Web services, and broke some up into an eligibility service, a benefits service, and a claim service. We have other services, as well. We feed those, via XML, into the portal desktop. So we were able to mix and match, as it were. We were able to customize and, ultimately, personalize information by breaking these components down into more discrete business functions and feeding them, in a standard way, through XML to the desktop.

We adopted Web services out of necessity, because, without doing so, we would have had to do redundant development. We could have actually served up different information about one person to different people, which is what we didn't want to do. We didn't want a consumer to see different information than the doctor would, if they're talking about the same thing. We wanted them to see apples-to-apples, because the consumer interfaces with the doctor. We wanted to make sure they were on the same wavelength. We didn't want to give them differing information or differing details.

Consolazio's goal was to create an all-in-one information delivery environment.

We were able then to get some synergy. Instead of having three individual, discrete projects, we basically had one integrated project where we took requirements, based on constituents, and then mixed and matched the components.

That's easier wished than done, however.

There's a lot of effort that goes into building the portal, and there's a lot of effort that goes into custom tailoring and securing the information for each of these constituents, be they doctors, consumers, or employers. But it made our life much, much easier. We were able to use these services and not have to build interfaces over and over again to back-end systems, some of which are mainframe systems, some of which are distributed systems. We tapped into virtually dozens of different sources of information to come up with the basic portal screen for a consumer. So that makes it very easy for us, but more importantly, it makes it very easy for consumers, as well. They can size, move, add, or delete from an inventory of functions that we've given to them in the portal.

In a move designed to simplify portal development and management, and to give users access to a wider range of information options, CIGNA decided to partner with Yahoo!.

We actually utilize Web services provided by Yahoo!. We can, through XML feeds, bring Yahoo! News, health tips, and other information into the portal in a very standardized fashion—all of it is via standard XML feeds. To the consumer, it's one desktop. In actuality, however, it's virtually constructed from many, many different locations—from legacy systems on our back-end and different third-party sources.

CIGNA was moving toward a self-service environment before the portal became part of its infrastructure. Part of Consolazio's challenge was to efficiently integrate existing applications into the new Web services-based portal.

We built some very good Web applications. But if you wanted to find out, for example, your medical benefits, you would come to the Web page and move into an application called Medical Self-Service. But if you wanted to find out about your pharmacy benefits, you would be moved to your pharmacy page. Only then could you could look at your pharmacy benefits.

It was really a collection of different stove-piped applications, which, three or four years ago, was pretty good stuff. But as we went forward, interviewed customers, found out their preferences, and did usability studies, we discovered that it was very cumbersome for them. They had to have multiple passwords, they had to drive through different applications—it really wasn't usable. And, regardless of how we tuned the look, feel, and navigation of the Web site, it didn't have all the information in one place.

We implemented this portal as a framework for the existing applications, then built a second generation of applications behind it. So, in the case of the medical self-service application, while we leveraged the components behind it, it was virtually rebuilt. We decomposed it into different Web services that we set up into this portal. Now people come in and log in once. Once they log in, they can go to different pages by clicking on different tasks, without having to worry about multiple passwords. When they actually dive down into the page, a whole summary of information is in front of them—the key information that they need at their fingertips: pharmacy information, dental information, medical information for all their CIGNA products. In addition, their retirement information is one click away.

In essence, what we wanted to be able to do was to have all the user's critical information located on one page. We wanted to have one place from which our constituents could navigate with a single click to get where they wanted to go, and be able to get summary information—the quick hits, such as their last five claims—right there, front and center.

Yahoo! PortalBuilder software lies at the heart of myCIGNA.com. Consolazio says he was attracted to the technology by its extensive supply of information content, which CIGNA could use to inform and educate portal users.

What differentiated Yahoo! was that it was able to give us a number of different services. It was able to provide content via an XML feed that fed right into the portal with no work on our part. Additionally, PortalBuilder allows users to access myCIGNA.com directly from their existing My Yahoo! page. Users can actually place a specific icon on their My Yahoo! page so that they can click through to myCIGNA.com.

Given the amount of highly sensitive personal content that resides on myCIGNA.com, security was a top priority for Consolazio and his team.

The portal's security aspect is handled by Netegrity SiteMinder. The product is a software platform of shared services that includes single sign-on, authentication management (who you are), and entitlement management (what you are allowed to do on the site).

CIGNA is using IBM's WebSphere for application server duties.

IBM has a whole suite of products that wrap around WebSphere. We basically use the core WebSphere product. They have lots of bells and whistles they're willing to sell to you, but we don't use a lot of them.

For its Web server, CIGNA selected Sun Microsystems.

We utilize the Sun Solaris operating system and the directory service—iPlanet (now SunOne) Directory Server—where we keep a lot of our security information.

The system ties together in a neat bundle.

We have WebSphere, from which we access the Web services and also drive back to the individual transaction systems. We have the portal, which pools together all the information that's fed by XML, either from the application server, or from various places across the globe. We have Netegrity on top of it, which provides the security.

In light of the fact that CIGNA assembled its portal environment from various vendors, Consolazio doesn't see a company, or group of companies, dominating the Web services market.

We haven't seen anybody yet who's really dominated in Web services. The way we define Web services is really according to business function. We think that, until these technology vendors have functions that add business value for a specific industry, we won't see a company that really dominates. It might be that you'll see different players dominate different niches.

Consolazio says he wasn't afraid to be an early Web services adopter, although he admits that it helps to have a tech-savvy partner that's experienced in Web services integration issues to guide the design and implementation processes.

There are a lot of things that we did, and have done, that we believe no one else has done. The partnership of Yahoo!, the personalization and customization, the use of Web services—-this is all pretty new stuff.

We wanted to make sure we partnered with substantial companies. So, with Yahoo!, we were able to leverage some good collateral.

I also think you can make Web services very, very complicated. The more complicated you make it, the worse it gets, relating to scale, performance, maintenance, and reliability. We could have devised very elaborate architectures to accommodate a very atomic view of what Web services are, but we decided to stick with a design architecture that was very straightforward, very scalable, and that dealt with very high volumes and performance.

The sobering factor for us is that we literally service millions of people. Necessity drives us away from architectural purity to something that is more realistic, easily implemented, and more scalable.

Consolazio believes that Web services are best implemented in phases, rather than as radical overhauls of existing processes and environments.

We started with our Web site and moved backward, rather than tearing our entire infrastructure apart and implementing, in one fell swoop, some gigantic vision of Web services across the enterprise.

The myCIGNA.com portal was merely a first step toward creating a Web services-driven enterprise, says Consolazio.

We're going to start leveraging Web services across the enterprise for different purposes. Going forward, we're looking at creating different partnerships. We want to be able to provide Web services directly to employers' desktops through trusted security, so that employers can take a service from our Web site and put it on their own site. This is the sort of thing we're exploring.

We're also exploring the possibility of utilizing Web services for more touchpoints. Can we, for example, utilize XML and provide interactive voice response (IVR) to our call center? Initial results coming back tell us it can be done, but we have a very established infrastructure already, so the cost benefit of doing that is under question. But these are the types of things we're looking at. The real question, however, is whether there's a demand for these kinds of services, as well as if they're technically feasible.

It's difficult to get a precise grasp on just how much money Web services can save an enterprise, says Consolazio.

I will tell you, we have gained productivity, but we haven't really quantified the specific benefits for Web services. It's just an approach by which we're building business value.

On the other hand, Consolazio notes that the ability to reuse components provides a powerful incentive for using Web service.

We're able to reuse the same components in different ways. We're able to take eligibility information, for example, and put it on a consumer's desktop, or a doctor's desktop. The key is being able to define these components so that you're able not only to reuse them, but to build them in such a way that your Web site's users can personalize and customize their experience. That's the real value of Web services. There's a big, beautiful world out there as to how these services can customize, personalize, and add value on an individual level.

A successful Web services implementation, says Consolazio, hinges on two factors: people and organization.

Put your best people on it, and have your development effort organized and mobilized. These elements are as important as the technology that you use.

Our e-commerce capability is really funneled through a singular center of excellence that serves the entire enterprise. Without that, we would have just built divisional solutions. We wouldn't have an integrated Web site, and we wouldn't be leveraging the portal or Web services the way we are.