Entry tags:

kaiser patients, kaiser permanente, kaiser privacy, kaiser tech

HealthConnect: Kaiser Swindling Congress
Recently Kaiser has been trying to position itself as the "authority" on the automated medical record, and Kaiser executives have been trying to sell Congress on their amazing HealthConnect system.

The problem is HealthConnect is not a system: it's a fancy new label for a motley collection of old "legacy" applications combined with some new components from a vendor called Epic. The "Epic" modules were originally billed as the Automated Medical Record, but Kaiser was chiefly interested in the billing module, so they settled for a less ambitious project of combining a few Epic modules with the variety of workhorse systems that have been in place for years. It's an act of deception to present this situation to Congress as either a new, cutting edge system (even Epic is based on archaic technology) or a fully integrated system.

Don't take my word on it. Let me quote Kaiser's own 2002 Technical Architectural Patterns for Enterprise Application (the rehabilitation of legacy systems as "assets" to be "exploited"): "The requirement for and proliferation of various integration techniques within KP has resulted in what Gartner terms 'application integration spaghetti'. While individual domains such as membership, sales, and marketing (e-Health) may have a strategy for managing and reusing integration, there has been no enterprise integration planning or documentation." And later... "The current inventory of integration at KP is not documented in one single location." Hmmm, doesn't sound all that unified or cutting edge to me.

Instead, Kaiser has been integrating applications in numerous (and costly) "transition" projects (presumably to be thrown away once an Automated Medical Record actually happens). One proposal for such a transitional project was called Safe Highways (later rolled into the sexier sounding "eStrategy"). The "Safe Highways" document was authored by the CTO for Kaiser's Northern California region.

...the approaches focus on developing "point-to-point" access from the client application to the legacy back-end application. The implication of this organic growth is that each development team has to independently solve the problem of how to access the legacy applications and data. A solution developed for one system is therefore not re-usable by other projects. The effect is that each new subsequent client application development initiative accessing the same legacy system must build its own specialized logic and pathways...The approaches currencly deployed are fragile and require a high degree of maintenance as well as highly skilled and knowledgeable technical staff to be used...changes, no matter how minor, have the potential of producing unpredictable and undesirable effects on client and other legacy applications where dependencies are not carefully planned or monitored...Relying on individual development teams to build point-to-point interfaces to legacy applications in an unplanned and uncoordinated fashion results in consistently high development costs, an increasingly fragile operational environment and unacceptable time-to-market for innovation projects. The problems identified above are widely recognized in the development community...A major challenge in implementing vendor product solutions is the need to integrate the product with existing legacy applications.... In some environments where this kind of lookup feature is not available, users are forced to re-key the demographic information they read from a 3270 screen onto a workstation screen. This is an inefficient and error prone process...Developing APIs for legacy applications is a complex and effort intensive activity. The PARRS API currently used by KPOnline, the Call Center Interactive Voice Response system and Call Center Stargate agents took two and a half years to develop at a cost of over three million dollars. It is a complicated interface to use. Client application developers characterize the development effort using these APIs as “slow and tough”...More importantly, most legacy applications do not have APIs available. Given the time and expense required to develop these APIs, it is not a cost effective strategy to provide all necessary access to business functionality directly through legacy APIs, many of which use different formats and protocols...). Many of the complexities client application developers must tackle are due to the heterogeneity in operating platforms, programming interfaces, access methods, semantics, etc. that are inherent in any legacy environment. Development initiatives in which this kind of complexity is exposed to developers require highly skilled and specialized programming expertise. Even with the appropriate skills available, the development work is challenging.

Problems identified in current environment
* Required application interfaces do not exist
* Implementing functionality at the national level requires building interfaces to multiple legacy (regional) applications
* Existing APIs “slow and tough” to work with – too much effort & technical expertise required
* Existing interfaces highly application dependent
* Existing solutions not readily re-usable or shared
* Many existing interfaces not published
* Landscape of technology interface options creates unnecessary complexity
* Multiple legacy solutions create complex operational environment
* No strategy for managing technology shifts
* Security not managed consistently across layers – unmanaged risk
* Scalability of existing solutions not assured
* Operational environment complex and fragile – systems are difficult to maintain
System availability is difficult to manage and assure

These are the recent words of highly placed Kaiser executives! I could extract many similar quotes, but retyping is tedious. And perhaps it will put Kaiser's strategy in better context if I step away from the technical documentation for a second, and quote from a Kaiser presentation called "Reputation Management." Hmmm, have to find it first, but this is the document where the Kaiser bigwigs explain how to craft a message to appeal to different audiences: no detail is overlooked. Kaiser employees must be educated to avoid referring to buildings (reminds people that Kaiser is a business) and to use "We" as much as possible (to suggest caring and family relationship). It's a rather sinister read.

But back to Kaiser's attempt to deceive Congress. If any person with any Congressional connection at all is paying attention, I beg you to read the quotes above carefully. Don't let Kaiser keep snowing the political powerbrokers with all this "HealthConnect" business. It's a smokescreen. There's nothing behind it but a pile of elderly green screens, a few Epic modules (chiefly the billing system), and various APIs and web service experiments cobbling it all together. Kaiser's just trying to recoup technology expenses with public money: and they don't deserve it because they have wasted *massive* amounts of money over the years. Feel free to ask me to expand on the nature of the waste.

Moreover, let's not forget Kaiser's ultimate goal in systems integration: to profile and sell insurance to "target" populations and to support its own risk management and litigation interests. The public should not be funding its own enslavement!