An Uphill Climb: Applying Military Intelligence To Manage Data At Intermountain

This was originally posted on www.healthsystemcio.com

[Below is the latest in a blog series in which Dale Sanders explores the “combination of fate, luck, planning and preparation that rolls together and creates a career.” Click to read Part 1 and Part 2]

My search for the leading healthcare organizations in computer-aided decision-making that met the time-critical and life-critical requirements didn’t last very long. There was only one clear leader in the published literature at that time — Intermountain Healthcare in Salt Lake City.

In 1993, I reached out to Intermountain for a meeting, starting with Al Pryor, who was the de facto CMIO. I couldn’t discuss the details of SEDA — not even its name — because the project was classified, but I could share that I was working on decision support tools for the Pentagon and was hoping to learn from Intermountain’s work in healthcare. Two other informatics leaders from Intermountain were in the discussions: Reed Gardner and Peter Haug, who demonstrated several decision support applications, including the ARDS ventilator weaning protocol and the antibiotic assistant. Later, with Peter’s assistance, we dug into the deepest pockets of the software code that was running the decision support tools on Intermountain’s HELP EMR.

Intermountain’s tools were complex, highly effective, and very useful. But they were also a sad reflection of the industry; they weren’t widely used and were inaccessible beyond the walls of Intermountain’s flagship hospital and region. I began to think that if Intermountain was the best in the industry, then rest of the industry must be in a poorer state of computerized maturity than I realized. Further research quickly confirmed that healthcare was, in fact, abysmally behind in its exploitation of computers to improve care.

I borrowed some ideas and concepts from Intermountain’s tools and took them back to the SEDA drawing table, but the poor state of healthcare computerization and decision support kept gnawing at me. I went back to my bosses at TRW and explained healthcare’s state of computerization affairs and suggested that we investigate it as a potential line of business, although it fell outside of TRW’s typical space and defense technology focus. We ended up creating a very successful line of business, doing work for clients such as Kaiser Permanente, The Cleveland Clinic, Veteran’s Affairs, the National Institute for Health, Loma Linda Hospital, and the Centers for Disease Control. Eventually we sold the business to a company called BDM, who in turn sold it to SAIC, and I left TRW to start a small software development and consulting business called Information Technology International (ITI).

We grew ITI into a 50-employee company, doing software development and data warehousing for a number of clients including Intel, Motorola, Britain’s National Health System, and the New Mexico Women, Infant and Children’s Program. But despite the success of this business, I didn’t believe I understood healthcare well enough to be a great vendor and consultant. I decided that the best way to deeply learn and understand healthcare was to become embedded in it — as an employee, not a vendor.

After two years I divested my portion of ITI and in 1997, applied for a position as a data architect at Intermountain Healthcare, willingly taking a 40 percent pay cut that I perceived as an investment in my career — like an expensive, real-world MBA. My goal was to stay in healthcare for three years, learn from the experience, and then return to the vendor and consulting space.

But after three years, I still couldn’t wrap my head around the details of the healthcare industry. I still didn’t understand it well enough to consult or build software. It was the most complicated, nonsensical practice-filled industry I’d ever been exposed to, and that was saying quite a lot given that I had worked in the US military industrial complex. My three-year commitment had now turned into 17 years, and I still don’t understand all the details of the industry.

At Intermountain, I applied the general lessons of software engineering, data management, decision support, and data warehousing that I had learned in the military as best I could to the specifics of healthcare. Eventually I succeeded, leading the design and development of Intermountain’s enterprise data warehouse, working closely with Brent James and David Burton on their visionary and transformative approach to optimizing healthcare delivery. The Intermountain EDW is still operating and has adapted quick nicely 16 years after it was initially deployed, having won at least five national awards along the way. It is a role model technology asset in a role model culture of care — a perfect combination for success. I also served as the Regional Director of Medical Informatics for their flagship and largest region, which gave me an invaluable opportunity to work closely with physicians and nurses in care delivery while learning the details of Intermountain’s homegrown EMR — the HELP system.

The transition into Intermountain and healthcare was not easy for me, culturally. In fact — and some will be surprised to hear this — my eight years at Intermountain were the most stressful years of my professional career. In part it was my fault because my insistent and impatient personality couldn’t tolerate the nonsense that existed in the industry. Both the processes and the technology were poor, and there seemed to be no great urgency to change that situation. The notion that you could deliver a poor quality product and achieve financial success as a result made no sense to me.

Generally speaking, Intermountain’s executive leaders, as well as the physicians and nurses, appreciated my style and commitment to making their jobs better through the IT resources that I controlled, notably the EDW and HELP. The employees who worked directly for me were consistently among the most satisfied in the company. But despite success in these areas, I ruffled a lot of feathers in Intermountain’s medical informatics culture by constantly criticizing our techniques and strategies for developing internal software. Looking back, I realize I could have been more diplomatic and patient, and yet I’m also somewhat vindicated by the accuracy of those criticisms.

Overall, my experience and association with Intermountain was invaluable, to say the least. I’ve been around the industry long enough now to understand just how far ahead Intermountain was in its approach to healthcare — at least 25 years ahead at one time. The gap is now smaller, as more organizations have finally realized that Intermountain was delivering “accountable care” decades before the federal government defined it. It is the best healthcare system in the US, and I am very hopeful that their recent decision to partner with Cerner will lead to the development of a true next generation EMR — one that delivers personalized medicine and the Triple Aim at the point of care.

And so concludes this chapter in the odd twists of fate that led my career to the healthcare industry.

From Nuclear Warfare To Healthcare, Part 2: Thawing Cold War Leads To A Career Change

This was originally posted at www.healthsystemcio.com.

[Below is the latest in a blog series in which Dale Sanders explores the “combination of fate, luck, planning and preparation that rolls together and creates a career.” Click here for Part 1.]

In the mid and late 1980s, we (members of the US Air Force Strategic Air Command battle staff) were seeing evidence in national intelligence reports that the Soviet Union’s Strategic Rocket Forces were having difficulty maintaining their nuclear weapons systems in fully-capable status. What we didn’t fully appreciate at the time was the root cause — the Soviet logistics supply chain was failing because the inefficiencies of the totalitarian-communist political-economic model were crumbling.

My team and I supported the first Reagan-Gorbachev summit in Geneva, providing a secure, nuclear EMP-protected voice conferencing system via satellite from President Reagan’s location in Geneva to the Pentagon’s National Military Command Center, NORAD, and the SAC Command Post. This nuclear survivable voice conferencing system — named Early Pentagon Connectivity (EPC) — was a direct request from Reagan. He did not fully trust the Soviets, even the congenial Gorbachev, and was deeply concerned that, while in Geneva, the Soviets might be tempted to launch a limited nuclear “bolt out of the blue” attack on the US.

The electromagnetic pulse (EMP) that accompanies a nuclear detonation tends to destroy the fragile electronics of solid-state computer and communications systems. For this reason, the US has spent hundreds of billions of dollars retrofitting and reengineering around EMP. One of the more concerning US military scenarios is the “nuclear hostage” scenario in which a limited, surprise nuclear attack from an enemy generates a large EMP, destroying the ability for the President and National Command Authorities to communicate with US forces, and thus enabling the attacker to hold the US hostage and emit further destruction.

It sounds like a bizarrely unlikely scenario, but for the better part of 50 years, the likelihood was not so low. Reagan, who was born and raised in a period of world history that was characterized by wars and near-crippling surprise attacks, was particularly concerned about this scenario.

Our tiger team of 12 worked for three months, seven days a week, 14 hours a day to finish EPC before the Summit. A satellite-based, secure, EMP-protected voice conferencing system had never before been designed or attempted. We weren’t sure it could be done, but we tried and managed to succeed. (The Secretary of Defense wrote each of us a personal thank you note.)

At the Summit, there was no hint of Reagan’s premeditated sense of paranoia. Gorbachev arrived early and unannounced at Reagan’s cottage, catching Reagan somewhat unprepared. It didn’t matter; the informality led to humor. The warmth that Reagan extended to Gorbachev was immediately returned. With their four-handed handshake combined with a growing understanding that the logistics infrastructure of the Soviet army was rapidly coming apart at the seams, it was clear that the Cold War was all but over, minus a few pen strokes.  By the way, I didn't see this handshake until I saw it on TV, like everyone else.  I was monitoring the summit and the EPC circuit from an airborne command post.

For me, it also became clear that the seriousness and responsibility of US nuclear operations that attracted me to the Air Force were also going to mellow. It was time to make a change.

In 1989, I resigned from active duty in the Air Force (while remaining in the reserves) to work for TRW, a large and well-respected space and defense contractor with whom I had worked extensively, particularly with its optical reconnaissance, signals intelligence, and communications satellites. TRW hired me for my experience as a member of the SAC battle staff and knowledge of the Air Force’s nuclear intercontinental ballistic missiles — Peacekeeper and Minuteman.

At one time, TRW was a major prime contractor for the National Security Agency, the Central Intelligence Agency, and owned the world’s largest consumer credit reporting system, now called Experian. TRW probably managed 80 percent of the world’s information in the 1990s.

While I was in the Air Force, we practiced nuclear warfare regularly — at least daily. The realistic nature of these exercises never lost their intensity. They were always disturbing, always chilling, and always creepy. We had 20 minutes to make decisions in which we discussed casualties in the tens and hundreds of millions lives.

During these exercises, under enormous pressure and time constraints, I saw enormous variability in the diagnosis and reaction to the scenarios. We had incredibly complicated decision support technology for fusing data together into a comprehensive picture of what was happening and to who and where, but we lacked any sophisticated technology for guiding the decision. We were surrounded by computers, technology, and essentially an unlimited budget, but our decision making tool was a five-ring binder called the Presidential Black Book, developed by Secretary of Defense Harold Brown in President Carter’s administration. The Black Book was approximately 100 pages of very simply described scenarios and attack options. We joked under our breath about the senior US decision makers who were predictably prone to choose “MAO 4, no withholds,” (Major Attack Option 4) which meant launching everything we had-- withholding no targets from attack-- military, industrial, or civilian — everything would go.

At TRW, I approached my bosses, Ron Gault and Bob Bloss, with a proposal to develop a computerized decision support tool that would (1) replace the antiquated and oversimplified Black Book with a computer-aided decision support tool that could more quickly analyze intelligence and sensor data, algorithmically diagnose the situation, and suggest response options that were directly traceable to US policy and military strategy, rather than the personal biases of the decision making officers and civilian leadership; (2) reduce the likelihood of reacting to a false-positive attack or failing to react to a false negative attack; and (3) address the completely new profile of potential nuclear enemies in a post-Soviet environment.

It’s worth pausing here to note the patterns in decision making that overlap with healthcare. Assessment, diagnosis, identifying and managing false positives and false negatives, response and treatment, monitoring outcomes, and repeating the cycle as necessary until the desired outcome is achieved.

In this period of Eric Snowden and NSA spying on our allies, some might be surprised to learn that our nuclear weapons software targeting programs also included the option to target our allies that posses nuclear weapons-- even if those weapons are stockpiled US warheads-- in case those foreign nuclear weapons come under the influence of a terrorist group or other unpredictable command.

My bosses at TRW approved the request to investigate the concept for a nuclear warfare decision support system. We approached the Pentagon for their support and funding and received approval. We called the project the Strategic Execution Decision Aid (SEDA). In short, it was a real-time, computerized decision support tool to be used in the pre-attack phase of a nuclear war in which the length of the decision making time frame was anywhere from 4 minutes to 23 minutes, depending on the location, source, type of weapon, and mode of delivery associated with the attack. SEDA was, simply, a real-time enterprise data warehouse, overlaid with very complex profiling and predictive algorithms for the analysis and visualization of data.

While developing the concept of operations and requirements for SEDA, I researched all industries and their use cases for real-time, time critical, life critical, computerized decision support. This research took me to the railway and mass transit industry, nuclear power plants, air traffic control, embedded flight control systems on civilian and military aircraft and finally healthcare. I was supremely confident in my naïve assumption that healthcare, with the efficiency of private sector economic motives, not hampered by the stodgy and ego-driven culture of decision making in the US military, would be my best source of lessons learned and techniques for designing and developing SEDA.  My confidence was misplaced but my curiosity and passion for healthcare decision support were kindled.