WebChart serves up Kaiser patients

NResources to access a demo of WebChart.)

What tools did they use?

Technically, Kaiser has built a textbook three-tier architecture. It has a Java-applet front end running both in Java-enabled browsers and on Java NCs (network computers). It runs via TCP/IP and LAN connections to a CORBA-enabled middleware layer (HTTP Java server and server-side Java applications) running on a quad-Pentium NT server, which in turn talks TCP/IP to a back end data repository residing on distributed mainframes.

As the middle layer, Kaiser chose BlackWidow/Visigenic ORB. The developers used jdbcKona to access an SQLServer database, which is used to store user preferences and code-translation tables. The CORBA servers retrieve data from several mainframe dataservers, splice the information together, perform any necessary code substitutions, then pass the appropriate data on to the client.

Shaw says Kaiser chose the Visigenic ORB because it “provided us with support for failover, load balancing and an infrastructure for registering and discovering services — all of which we did not have to write.” He adds that “there were also several other groups within Kaiser that needed the same clinical data we needed, and it made sense to create servers that others could access in an open-standards way to get the data in the normalized form a client would want it.”

The team developed in JDK 1.0.2, and continued doing so even after JDK 1.1 was introduced, because with such a non-standardized client environment the developers needed to assume the lowest common denominator in terms of browser support. As of this writing, they were beginning to migrate to JDK 1.1. With the exception of the 3270 emulator, which was purchased from WebConnect, most of WebChart was developed in Symantec Café 1.5, the predecessor to Symantec’s Visual Café. Shaw still speaks fondly of Café, noting that despite the youthful bugginess that plagued first-generation tools like Café, BlackWidow and MIGrid, they were all very usable. Although he uses Visual Café today, Shaw contends that Café’s no-frills, lightweight quality gave it certain advantages over the larger, more ungainly packages offered today like Visual Café or JBuilder.

Challenges during development and deployment Working with first-generation tools wasn’t the only difficulty the team faced.

“We experienced all of the now well-documented challenges of developing in Java,” said Shaw. “For example: repainting problems with the AWT, the intrusive nature of the garbage collector, the different z-ordering of different JVMs, the idiosyncrasies of the many Netscape, IE and HotJava JVMs.

“We lived writing once and debugging everywhere. We suffered through the poor, but improving, performance of the JVMs and the challenges of debugging a multithreaded front end.”

Kaiser developers also ran into the problem of Java’s poor support for printing, and so used a workaround that involved creating a HTML file on-the-fly for the data they wanted printed and displaying the HTML in a separate window that users could then print using the browser. They chose not to “write” the file to the server’s hard disk, but instead kept the file in a hashtable on the server and removed it when it was no longer needed.

Kaiser also grappled with an organizational challenge, although it had technical ramifications. The Kaiser regions are semi-autonomous, and some of the major data repositories are housed offsite, either in Walnut Creek or Corona, California. The latter are maintained by mainframe engineers in the Southern California region, who have no stake in WebChart’s success. Thus, throughout the project, the development team was limited to a black-box understanding of the structure of much of the data — Shaw and his team could only hope that the references they were given were accurate and complete.

Furthermore, the engineers who were used to maintaining traditional networks would forget about the TCP/IP connection WebChart used. So when the mainframes were brought down for maintenance in Southern California, they would occasionally fail to note that the TCP/IP listener had died. When WebChart began failing in Northern California, there would be a flurry of phone calls to get the listener turned back on.

The Fremont Pilot

As part of an experiment in designing more efficient business practices, Kaiser built a new clinic in Fremont, California, which became known as the Fremont Pilot. Hendler and Peredy realized that the Fremont Pilot would make a very good test case for WebChart. So in mid-1997, Kaiser installed 50 Java NCs at the new clinic and pointed them at WebChart. Hendler reported that the application was a hit.

The staff found it easy to use and they appreciated the new features. The biggest problem was finding time to teach them how to use it. Doctors and nurses who had become proficient at the less-intuitive 3270 system were resistant to learning yet another system. But those who did quickly became its promoters, particularly once they realized that there was a 3270 emulator included just in case they wanted to use the old system.

Success jinxed by bad timing

This deployment of WebChart in Fremont showed its developers both the strengths of the application as well as some weaknesses in terms of performance and features. Unfortunately, the developers were unable to address these issues because just as they were coming to light, WebChart lost its funding.

In mid-1997, the national Kaiser Permanente organization brought in a new CIO who discovered that every region was engaged in its own development projects with very little inter-regional coordination. So a moratorium was called on all regional projects (including WebChart), and the national organization focused on developing a single company-wide solution.

Hendler agreed that it probably was a good idea to put a halt on some of these projects, but complained that the national organization didn’t investigate the successes of the regional projects well enough, and never even considered a Web-based solution. Instead, the company opted for what he called an archaic and expensive client-server system.

“They’re just not ready to think of the Internet as a viable option,” he said.

Meanwhile, WebChart still functions and is gradually gaining more users today. But for the most part, it has languished for the past year inside Kaiser without resources for development or expansion. Ironically, outside of Kaiser, WebChart has been gaining a lot more attention.

In late 1997, Hendler met a man from the Sun Microsystems medical systems development group, and told him about their project. Before he knew it, Hendler was speaking at JavaOne. Since then, Hendler has traveled around the world twice, and back and forth across the U.S. more times than he can count, spreading the word about WebChart.

And the acclaim has taken Hendler somewhat by surprise.

“We thought that what we had done was so obvious that everyone was doing it already,” he said.

They’d been thinking about and working with multitier, distributed object architectures, Java business object middleware, and Web-distributed, thin-client front ends for over a year, and truly believed that this was the most logical and maintainable system possible. But when they popped their heads out of their cubicles to look around, they realized that they were way out on the cutting edge.

As Hendler eagerly explained, they had to solve the problem of getting data from a multitude of sources, in a multitude of media into a single system and then distribute it to a wide variety of desktops throughout a very large company, without incurring the costs typically associated with a huge client-server development project. Not only did Java/CORBA solve all these problems, but Java/CORBA development is cheap, fast, scalable and works over the Internet.

Future development in Java

Both Hendler and Shaw are sold on the benefits of developing in Java. Hendler has begun working part-time at Chiron Informatics, a medical technology company in Alameda, California, and is splitting his time between there and his clinical work for Kaiser.

Shaw has taken some of the WebChart code and design and repurposed it for new initiatives in the Kaiser information systems world. Although he doesn’t tell people that Java is a painless solution, he does argue that it is the best solution.

“Java and the Web are so empowering,” said Shaw. “These days, practically anything that you would want to interface with has a Java API. Furthermore, the fact that there are so many independently developed systems accessible via HTTP allowed us to use Java as the glue for packaging systems together.

“For example, it was trivial for us to link WebChart with Kaiser’s online clinical reference, OpenConnect’s Java 3270 emulator and a Web-based medical imaging system, and offer all these systems as a single package. It does not stop here.

“We are now looking at interfacing with a Java applet for displaying EKGs and also a decision-support server to embed hot links in documents like our radiology reports. We are still riding the wave.”