PacifiCare Behavioral Health paved the way for streamlining operational workflow and improving information availability through the implementation of a comprehensive, client-server, integrated managed care/clinical application.
As a company, our mission is to deliver effective behavioral healthcare services through a network of provider partners. We use a network of provider groups and individual practitioners to deliver mental health, substance abuse and employee assistance programs (EAP) services. Currently, PacifiCare Behavioral, Inc. has 1.2 million members and is a wholly owned subsidiary of PacifiCare Health Systems (Cypress, California).
Our recent growth created operational challenges, resulting in an increased focus on operational excellence. To enable this vision, we converted our existing IT infrastructure to the client-server paradigm, supporting the following initiatives:
* Reduce administrative costs and improves service, quality and speed by supporting core back office processes and transactions (e.g. claims, eligibility);
* Build a consistent, company wide, integrated database of information;
* Improve customer service by assuring 24 hours a day, 7 day a week access to confidential, accurate enterprise information;
* Replace our existing VMS-base managed care application.
* Transition to the empowered team environment.
Our business requires a high degree of automation to efficiently deliver behavioral health benefits to our customers. One of our primary objectives was to improve operational efficiency and reduce administrative and operational costs. In addition, we needed a system that had the flexibility to meet the needs of a dynamic organization in a changing industry, and support innovative product design and diverse provider reimbursement agreements.
Since we pay many of our providers with modified case,rate risk contracts, we needed the flexibility to prepay the provider and then monitor courses of treatment by submitted encounters. We also wanted an open systems architecture that would allow us to quickly and transparently integrate custom, in-house developed or additional off-the,shelf applications with our core application.
Requirements definition & RFP process
Requirements definition or the `what', was facilitated by extensive process workflow analysis across the company (with external interfaces) using several joint application design (JAD) sessions. The resulting detailed requirements provided the foundation for a comprehensive request for proposal (RFP) which included functionality, context diagrams, data flow diagrams, and specific technical requirements. One of our key selection criteria was the soundness of the client-server architecture in terms of work distribution, performance, support of 24x7 up-time, tool set, etc
The RFP process started with nine companies, with a down-select to five vendors based on quality of inputs and fulfillment of our selection criteria. The remaining five vendors were invited to demonstrate their products and discuss key functional, technical, and organizational traits of their application and company. Our Director of Information Systems was then sent to each of the three finalists' site to review the details of their technical architecture, product and technology vision, and quality of their development and product support organizations.
Build vs buy
Based on application development backlog, plus competing priorities for systems, and the long cycle time to deliver an -in-house developed application, we focused on a commercial off the shelf software (COTS) solution. We wanted an `industry' product that could handle standard business transactions (e.g. claims processing, benefits administration, eligibility and billing) that does not provide competitive advantage,-- but provides the required operational effectiveness and efficiency.
Selection criteria
Before starting the system selection process, we were looking for a solution that provided high levels of productivity and a functional/technical architecture that would form the foundation for the core of our long-term IT strategy. Based on our experience with Windows-based applications, we recognized the advantages of the productivity widgets and workflow that can be optimized in this environment. During the final vendor site reviews, we carefully scrutinized their investments and results in tool research, architectures, and technology review.
Our investment in a new architecture and application meant an equal commitment to the company that was developing it. This made our potential partner's financial viability, senior leadership strength, and product vision an essential component of the evaluation process. A clear and consistent management vision for their product would provide the necessary confidence required to make the product, company, and our partnership successful. We also sought a partner that offered unique incentives for the development team and focused on product ownership by both management and the teams.
The following represents the key technical architecture considerations in choosing a product and vendor: client-server architectural design; productivity based user interface design; supported hardware/software/network topologies; PC resource utilization; performance bench marking for network, client, server; security; extensible (offers functionality or software hooks to add or integrate custom applications); scalable for increased capacity and throughput; an integrated reporting module, and conversion/interface tools. Software development practices included a review of development methodology (structured, object-oriented), quality controls and assurance, rigor of testing strategies and approach, automated development and testing orientation, configuration management. We also concentrated on their product support and release strategies: frequency of releases, hours of operations for support, management strength and staffing levels/skills, number of releases supported, custom VS a generic or vanilla release strategy, escalation policy and service levels, and defect tracking and identification.
Fundamental to our decision was also the `extensible' piece of the system - the need to integrate seamlessly with 'homegrown' applications, such as our Clinical Triage application used for member triage and assessment prior to the provider referral or channeling process. We also required a parameterized setup of the application to 'tailor' the application to our data structures.
System performance
In December of 1995, we went live with Erisco's FACETS 2.2 product on an IBM RS/6000 R24 server (running IBM's HACMP [high availability option]) running Sybase SQL Server V.10. We have a fully redundant RS/6000 for quick recovery. FACETS, with our integrated Clinical Triage application, has performed well with 1.2 million members and 150 total users at 5 U.S. geographic locations. We have had some degradation in both batch processing and online response time with the incremental addition of new membership, but we have been able to maintain our required 24x7 hours of operation. We have been pleased with our ability to quickly add new benefit designs and absorb new membership with the FACETS application. Batch performance issues were addressed quickly with Erisco, IBM and Sybase and are now running within expected batch windows. To improve overall performance using parallel processing we recently added SMP (symmetric multiprocessing) processors.
Conclusions
Our selection criteria and fundamental emphasis on technical architecture proved to be accurate for our company. We have a scaleable IT foundation and functional application that provides a growth platform for our future. Looking down the road, the business model of the future will require us to integrate information with providers and employer groups. This will certainly be enabled through our client-server implementation.
Key technical architecture considerations in choosing a product and vendor.'
* Client-server architectural design
* Productivity based user interface design
* Supported hardware/software/network topologies
* PC resource utilization
* Performance bench marking for network, client, server; security
* Extensible (offers functionality or software hooks to add or integrate custom applications)
* Scalable for increased capacity and throughput
* An integrated reporting module, and conversion/interface tools.
