In early 1996, Oxford Health Plans, a major HMO in the northeastern United States, executed a vision for a new approach to managed health care--a concept based on creating virtual companies that could provide lower-cost, higher-quality specialty care for patients. This concept represented a breakthrough in the health care industry. At its heart was an advanced system capable of supporting thousands of doctors, contractors, and patients with high volumes of claims data. Oxford engaged our company--an integrator focused on mission-critical systems for the Fortune 500--to design, develop, and deploy this transaction-processing VLDB. To overcome the technical challenges associated with this system--high-volume claims information, thousands of users, complex business rules, and stringent security requirements for Web deployment of medical data--we used a well-defined architecture, a robust VLDB deployment approach, and a unique technology framework.
Over the past several years, Oxford has experienced meteoric growth, expanding its revenues to billions of dollars and its membership by almost two million members. In early 1996, Steve Wiggins, Oxford's founder, proposed a new business model that addresses this rapid growth and solves several key problems in specialty health care. Oxford Health formed a subsidiary business under the name Oxford Specialty Management (OSM) to commercialize this concept.
Historically, specialty care patients--that is, those requiring care from specialty providers--have been treated like all other patients, even by managed health care providers. However, with specialty care, the problems of traditional care become more pronounced: Patients do not always have access to high-quality specialists; when specialists have been identified, the teams required to manage the most difficult cases struggle to share the information in a way that provides a cohesive care regimen; and payors have little control over the cost of care because of the lack of standardization in the way care is delivered.
The OSM model is simple: When members require specialty care, they are assigned to an established team of specialists--oncologists, orthopedic surgeons, anesthesiologists, physical therapists, psychologists, and so on--that is designed to provide all the care required for the particular condition. These specialists are linked in a "virtual company" that carefully monitors the patient's progress over the Web. For example, after a visit with a patient, the specialist providing the care enters notes regarding the patient's condition into a browser-based interface. These notes are then made available to the entire care team over an intranet, ensuring high-quality, coordinated care.
Under OSM, a variety of care "pathways," or diagnostic options, can be used to treat specific conditions. OSM assigns a patient to a pathway--say, an ultrasound examination--based on the virtual specialty company's preferences. Subsequently, payors can access the Web-based care database to track patient progress along the care pathway as well as monitor care outcomes and payment milestones. This unique functionality provides several key, differentiated advantages, including greater autonomy and discretion for health care providers, improved focus on patient outcomes, and reduced overall medical costs.
Although the OSM concept is simple in theory, the IT execution is significantly more complex; a robust information system is required to make these virtual specialty companies a viable reality. OSM also needed a powerful processing capability to manage the complex claims processing involved in specialty health care agreements. Although the business would start from ground zero, it was expected to scale quickly as the market signed on to this unique concept.
Unfortunately, even as Oxford was contemplating development of the OSM model, it was simultaneously beginning to experience scalability difficulties with its existing core claims-processing system, Pulse. The Pulse system, which is based on a classic two-tier architecture, was designed for hundreds of users, not thousands of them; the system simply couldn't scale to meet the demands of such rapid growth.
Besides its scalability limitations, Pulse also suffered from operational constraints that were not adequately addressed when the system was designed. In Oxford's early days, insufficient consideration was given to the tough data conversion and data quality issues that arise as a business becomes more complex. Furthermore, the Oracle7-based applications were built on Oracle's dedicated-server model, which instantiates a new server OS process for each additional user ("dedicated" to that user exclusively). As concurrent user counts grow, the server begins to choke on the hundreds or thousands of dedicated server processes. As a result, when the data grew into multiple terabytes in size and the processing of batch claims began to bottleneck, Oxford was forced into a continual search for bigger and better hardware that could be easily integrated with its rigid, two-tier system--an unenviable, virtually impossible task.
The Oxford situation exemplifies the importance of looking at more than just the VLDB characteristics of a system. Although the VLDB itself may work fine, it will be of little use if the underlying operational framework--systems maintenance, communications infrastructure, and hardware flexibility--cannot support the operational requirements. The lack of a proper design that accommodates scalability and flexibility can bring even the most powerful system to its knees.
With OSM, Oxford had the foresight to plan an IT architecture that could manage the explosive growth that is often associated with a promising new business venture. To ensure that the system could scale to handle thousands of concurrent users, tens of thousands of transactions every day, and hundreds of gigabytes of data--as well as to take advantage of a perceived competitive window of opportunity of only nine months--we designed the OSM system to include Enterprise Information Manager (EI*Manager), a Web-enabled, application deployment environment that leverages a centrally controlled repository of business applets. This approach enables the rapid deployment of complex, mission-critical applications that deliver enterprisewide data access to thousands of users.
To quick-start the project, we worked with the OSM team to define the critical success factors. These discrete business drivers brought the vision of Steve Wiggins to the level where it could be concretely built into an information system. When the business needs were clearly understood, we drafted an architectural road map. This map described more than the traditional process, object, and data models generally detailed in an architecture. In fact, those three models, while important, were just the tip of the iceberg.
A complete "actionable architecture" for a mission-critical system has to address more than scalability; it must also consider key operational layers such as systems management, security, communications, and hardware/software fault tolerance and backup. If it doesn't, as the business scales, the operational and infrastructure issues can bring the entire system to a screeching halt. This complete architecture approach was particularly critical in OSM's case, where Web-based communication and security issues play such important roles. A high-level, logical view of the OSM system is shown in Figure 1.
Another important goal in designing a VLDB architecture is to identify and minimize key business and architectural risks. Given the short timeframe we had to develop the OSM system, we opted to pursue an iterative development approach, reviewing key iterations with OSM's business staff at each stage to ensure a proper connection between IT and business direction.
As you would expect from such a complex project, the OSM development team had to overcome a series of challenges, most of which are broadly applicable to VLDB projects as a whole.
Scalability. As the claim stream grows, Oxford expects to be assigning hundreds of new member cases per day that will quickly create hundreds of gigabytes of data. OSM estimates that tens of thousands transactions will commit per day against the Oracle database; this data will originate from thousands of users across the United States. Some of the users will be doctors and some will be payors; eventually, Oxford may even roll some OSM information out to members as well, greatly increasing the scope of the challenge. Oxford and OSM are also planning a data mining process in which ordinary claims will be passed through the OSM system to identify prospective case treatment opportunities. This case prospecting will cause the system processing requirements to grow exponentially.
To provide the future processing power and storage anticipated for this system, we elected to implement a multitier system: a traditional three-tier system (database, transaction processor, and user interface) with additional layers for the business logic. This architecture will allow Oxford to upgrade its hardware and quickly modify the OSM business logic for its worldwide user base as the treatment paths change. For the middleware layer, BEA's Tuxedo TP monitoring package was our product of choice. Tuxedo provides robust load balancing and application partitioning, greatly enhancing the system's flexibility and scalability.
Oracle was an automatic choice of database because it was already an Oxford standard. Oracle had proven its scalability in previous engagements; however, to ensure robust processing, storage, and retrieval, we spent a considerable amount of time tuning the workload. For example, we defined a fixed set of transactions that could be executed and then optimized the application logically and physically. As the data store grows, OSM will continue to modify, refine, and optimize the database and its underlying data models to maintain the required levels of performance.
Customized applications. Claims relating to a specialty care path--such as a hip replacement, high-risk birth, or cataract surgery--are filtered out of the streams of claims. When a patient has been identified as a candidate for specialty care, OSM assigns the member to a virtual specialty company and designates certain procedures. This functionality had to be developed immediately. At the time, Java and ActiveX were in their infancy. As a result, the OSM team elected to focus on a quick solution: a Visual Basic two-tier application. Over time, this application will be migrated to a browser-based interface (more on this later).
OSM also had to solve the problem of customizing the application for each group of users and achieving robust security for the Web-based distribution of medical information. Three groups of users are likely to use the OSM application: providers (the specialist doctors), payors (OSM and eventually other payors), and patients. Initially, OSM focused on giving an application to the providers and the payors; both sets of users need access to the same data. However, the users require different interfaces and different levels of detail from the same data--the specialists need detailed clinical updates from the other members in their care team, and the payors need cursory outcome information and detailed financial information on the case. As a result, OSM needed to produce two applications. The challenge was to find a way to develop an application that was sufficiently intelligent to provide one set of functionality and screens to some users and another set to other users.
EI*Manager had been developed with this type of need in mind; it creates custom "applets" for each group of users by storing customized business logic and transactions, predefined queries, user interfaces, and security levels. As a result, complete sets of business rules and interfaces can be assigned to classes of users. EI*Manager applets may also share logic, transactions, and interfaces, which substantially reduced the development cost for OSM's various applications.
Security. Security was another important architectural challenge. Several forms of security have been refined over the past few years to meet the needs of emerging Web-based electronic commerce. Traditional security systems provide basic security for most of the links between a database and the users. Security starts with database-level security, whether at field level, record level, or table level. The link to the users is secured through various encryption methods. User access to the data streams is controlled through levels of passwords. The combination of database, communication, and interface security combine to provide fairly robust data security.
However, when the information is medical in nature, another layer of security is required. With OSM's application, the challenge was to find a way to separate the data accesses so that users with two different roles--for example, as a doctor and payor--would not be able to access inappropriate data. EI*Manager was again a help here because it includes an extended metadata layer that encapsulates business applets. This metadata layer provides an interpretation buffer that prevents users from directly accessing the data. EI*Manager's applets also include role-based security as a standard feature. Role-based security is a high-level security technique that segments off portions of the data from classes of users through the use of restrictive SQL where clauses. Finally, the EI*Manager architecture provides a physical level of security by preventing the end user from directly connecting to the system where the data is stored; all user workloads are submitted from a remote, physically separate system.
In the end, OSM implemented traditional as well as role-based security. These multiple layers of physical, communication, user, and role security provide a robust implementation for the secure access of sensitive medical information across the Web.
Figure 2 summarizes the infrastructure implemented to provide OSM with a scalable, customized, secure interface. This architecture provides for tremendous flexibility in the design of user interfaces. As we explained earlier, OSM initially opted to use a Visual Basic interface for the case assignment module. But because of the large number of potential users for the core virtual specialist company reservation, we began to look into Java, which at the time was considered a cutting-edge technology. The end result was a Java and HTML-based interface that includes graphing capabilities, physician note interfaces, and financial reporting modules. This interface lets specialists track a patient's progress through various care nodes, add notes for each patient visit to keep other specialist team members informed, and quickly highlight the remaining steps that must be completed to receive payment. Eventually, OSM will deploy this interface exclusively.
Rapid development was a key requirement for the OSM system; it had to be implemented before any other competitors could match its functionality. The work of defining the business-critical success factors began in July 1996; by September 1996, system and infrastructure design were complete, and development of the specialty case filter, case assignment pathway, Oracle database structures, Tuxedo middleware layers, EI*Manager applets, and Web front-ends had begun. By May 1997--11 months after the project began--the OSM was ready to roll out. Since then, Oxford has enrolled more than 100 virtual companies in the OSM program. OSM expects this base of virtual companies to grow quickly; the number of claims will grow exponentially as well. The OSM system will be critical in reducing administrative and care costs while providing high levels of care.
To summarize, there are several lessons in the OSM experience. First, an architecture is critical for the operational systems that underlie a VLDB. Plan carefully up front--the large data stores may operate properly, but data acquisition, conversion, and reporting issues can eventually bring the system to its knees. Second, OSM presented an unproven data model with evolving, dynamic requirements; workloads, data volumes, and data types had to be modeled and discussed. If your environment is similar to OSM's, an iterative development methodology with stringent prototyping steps is critical for successful system deployment. Third, if security is a key concern for you as it is in the medical world, you must address it during the architectural phase. Early consideration allows for the implementation of multiple levels of security. And fourth, in this case as well as many others, standards are far from "standardized" and data quality is a substantial concern. By addressing these concerns early, you can quickly deploy a highly scalable system with robust architectural underpinnings.
Larry Tanning is president and CEO of Tanning Technology Inc. Larry spearheads
solutions across a broad range of industry categories and is a frequent speaker at industry
conferences and events across the globe. You can reach him at ltanning@tanning.com.
Allan Edwards is senior project manager at Tanning Technology. He has more than 15 years
of large database systems experience and was previously an applications and systems manager at
MIT's Laboratory for Nuclear Science. At Oracle, Allan was a member of the alpha and beta rollout
teams for Oracle7. You can reach him at age@tanning.com.