The Health Plan of San Mateo (HPSM) first began working with the "e" portion of the e3000 approximately 6 months ago.

It began with my desire to simplify some of the IS Operational aspects of our environment. As a California Medi-Cal HMO with a duty to report consistent and accurate data to the Department of Health Services of California, HPSM has fairly large number of different jobs that are set up to report various slices of claims data based on fiscal year parameters. These jobs are all run on a monthly basis to reflect changes in our claims data. Since it is our standard practice to retain seven years of historical data on our systems, each job essentially runs up to seven times each month (based on the request of our CFO). With approximately 50 jobs (and rising), up to 350 job streams may be requested during an end-of-month cycle!

Since all of these reports were using JOBBER as the input screen, all parameter input was not validated at stream time, and it caused problems when even one parameter was incorrectly entered.

Enter STREAMX. STREAMX allowed fully validated stream-time parameters and even reusable STREAMX modules. Jobs were rewritten to use STREAMX in place of JOBBER and STREAMX modules were created to further simplify parameter entry. [Note: STREAMX is part of Security/3000 from Vesoft.]

Enter Apache. We installed the Apache webserver on our e3000.

Enter Perl. With invaluable assistance from Robelle, HPSM received the kickstart necessary to launch e3000 administration using Perl and Apache. We successfully created reusable Pperl modules that allowed for extremely easy integration within our existing environment.

The end result of all this activity was about 20 (or so) different web pages that allowed the majority of the end-of-month jobs to be streamed with just a few mouse-clicks, and with the jobs having fully accurate parameters. We have one web page that has the ability to STREAM up to 49 jobs. This would take just a few seconds. Doing this manually would require between one and two minutes per job and introduce the potential for inaccurately entered parameters.

How has Robelle's Qedit for Windows assisted in all this?

It has been, in a word, a beautiful linchpin. This is because Qedit for Windows speeds up development time by allowing users to edit both POSIX, MPE and PC files within an integrated GUI environment. In the above scenario, the STREAMX jobs were MPE-based, while the PERL scripts were POSIX-based.

In August 2000, we implemented ReflectionWeb. In September, we implemented a full Virtual Private Network at the Health Plan. Both methods of remote access allow for authenticated, secure and encrypted access! With ReflectionWeb, we can access the e3000 using Internet Explorer (and Java); but with our VPN, we can now also access all of our protected systems (behind our Firewall and DMZ) that also have web interfaces. Qedit for Windows works onsite and remotely (through our VPN) and allows for much quicker viewing and troubleshooting of reports and $stdlists.

Again, all remote access is secure, authenticated and encrypted. This is very important for HMO's because of the new HIPAA regulations regarding security and privacy.

We are always looking for ways to further automate things, and we have done quite a bit using Visual Basic and Reflection1. We're now looking at Qedit's QSL to see how it might fit into our framework. No development thus far, but it is in our future. Qedit for Windows truly simplifies our work and provides a great GUI editing environment for files from any source--MPE, POSIX or PC-LAN. This next year, I will make a solid effort to migrate the one or two remaining staff who are mired on the HP3000, to switch to Qedit for Windows.

Eben

eben_yong@hpsm.org
December 18, 2000