Friday, March 21, 2014

What the @#$%& is Actionable Data?

"Actionable data" is a term that has been tossed around for YEARS, right?  How many times have you heard this?

"The key to analytics success is providing actionable data."

OK... but what does that mean, really?  Here I am, a data warehouse and analytics design guy... how can I measure whether the systems I design are producing actionable data?

Dr. John Kenagy and I were talking this morning in preparation for an upcoming webinar and he mentioned actionable data a few times in the discussion, so we paused to ask ourselves, what does that really mean?

Here's our algorithm for Actionable Data:

Actionable Data = Pr x Tf x Et

Where:
  1. Pr: Personal. The data must be personal, appropriate to the role, and workflow specific
  2. Tf:  Timely and fresh. The data must be timely, fresh, and high quality... no stale or bruised data fruit.
  3. Et: The person to whom the data is presented for action must be educated and trained about how to act in response to that data.
One of the key moments of awareness for me in this discussion was the Et variable.  If I'm a data warehouse and analytics design expert, it's not enough for me to provide personalized and timely data.  I can do that easily enough, technically.  I have to ensure that the organization that I'm supporting with the data warehouse and analytics solution is taking it upon themselves to educate and train their employees-- the consumers of the data-- on how to interpret the data and what action to take in response to the data.  

If I don't ensure that the organization is taking this holistic approach to Actionable Data, it's in the interests of my livelihood and success to push that agenda, otherwise, the technology that I leave behind will not realize the value that it should.

Analytics and Data Warehouse Engineers: Take action to ensure you provide actionable data.




Wednesday, February 19, 2014

End of the Healthcare Cold War?

I was in the US military and defense industry for 15 years, including the end of the Cold War. It took the military-industrial complex 20 years to grasp that end and change significantly to address the new world of dispersed, limited, and intervention-based warfare.  I'm seeing the exact same pattern in healthcare reform. 

We've reached the end of the healthcare Cold War... everybody knows it... but the healthcare-industrial complex keeps wringing its hands, talking about change, but actually changing very little. 

Is it going to take 20 years and a generational turnover of corporate, government, and healthcare leadership to finally turn the corner?  Will we still be fighting the Healthcare Cold War in 2024?  2034? 

Monday, February 3, 2014

Great Healthcare IT Vendors: Top Ten Essential Behaviors

This was originally posted on www.healthsystemcio.com, August 2011.

A few weeks ago, a noteworthy healthcare consulting firm asked for input they could pass on to vendors that would help those vendors understand the relationship imperatives critical to a healthcare CIO, right now, in today’s market.
After giving this topic a few days of background thought, I concluded two things:  (1)  At least 60% of the imperative relationship advice that I give today applies at any time in history; and (2)  My current Cerner account representative, Lisbeth Fabiny, was a great source of reference.  I found myself asking, “Why do I value Liz’s support so much?  What does she do that makes her feel so valuable?”
It is worth noting, that I have nothing to gain by offering meaningless compliments to Liz or by association, Cerner.  Cerner and Liz will both tell you that I can be very demanding and uncompromising in my expectations and criticisms of products, services, and expenses. But, it’s also important and proper for me to praise the positive, not just complain about the negative and in that vein, Liz is a role model for vendor support and customer relations – the best I’ve ever had in my 30-year career.
Here are the Top 10:
1.       Help Me Compete:  Help me build my “Annual Report for Information Technology” as if my IT organization were a separate, standalone business that could be outsourced.
2.       Help Me Hire:  The market for healthcare IT employees has never been more competitive.  If you know I’m having a hard time recruiting for a critical position that is important to the success of your product in my organization, help me find a great match.
3.       Help Me Measure:  The Age of Analytics in healthcare is just beginning.  Our industry is way behind in the proper use of data to drive costs down and quality up.  Help me address my short term analytic needs, but do so within the scope of a longer term strategy.
4.       Help Me Save: Simplify your licensing, billing and contract administration.  Make it as easy as possible for me to manage my expenses with you, and especially make it easy to predict and budget for increases in prices due to inflation, increased number of users, transactions, etc.  When you give me a new contract to sign, put a face sheet on it that summarizes the key issues and terms – don’t make me read 15 pages of legal jargon.  Likewise, if you know of a creative way for me to reduce licensing fees, try to be motivated by our long term relationship instead of your immediate potential loss of commission.   You will win more of my business, easily.
5.       Help Me Listen: Be proactive in extracting the ROI and value from your products.  Help me look good and thus make your product look good, too.  If you know that I’m under-utilizing your products or have them configured improperly in some way, pester me until I fix it.  I’m busy and juggle lots of priorities. Be the squeaky wheel until I listen.
6.       Help Me Expand: Annual conferences and blogs are not enough for me to keep up with everything going on in healthcare right now.  Help me build close relationships with a limited number (3-4) of peers or mentors who have a similar organization, product mix, and profile so we can learn from one another.  Force us to meet and hold a conference call every once in awhile.  Facilitate the meetings. Help us reuse strategies, policies, and technology as much as possible.
7.       Help Me Plan: Help me build my strategic roadmap by overlaying the needs and culture of my organization with your products and the future outlook of the industry.  Look ahead for me and pester me until I build that roadmap with you.  I am particularly concerned about the growing sophistication of cyber attacks.  And I’m also concerned that I’m not leveraging mobile computing as well as I could. Push me on these two issues, please.
8.       Help Me Migrate: Help me build the cheapest, safest, quickest path to ACO and ICD-10 adoption for my company and critical partners in the insurance industry.
9.       Help Me Prove:  Help me build the cheapest, safest, quickest path to Meaningful Use qualification for my company, and don’t charge me anything extra, because this is something you should have done for every customer a long time ago.  The Meaningful Use legislation forced it but, like HIPAA, we should have been doing this all along.
10.   Help Me Evolve:  ACOs are coming; one way or another.  Even if they are nebulous right now, we know that there are certain characteristics that will survive.  In particular, you better have a product strategy for both engaging patients in greater accountability for their own care and the changes in the revenue cycle required for managing the risk of bundled payments.

Friday, January 31, 2014

The Data Warehouse is an Internal Small Business

You can force the adoption of a transaction system -- like an EMR, an email system, a time & attendance system, et al -- on end users, but you can't force the adoption of an Enterprise Data Warehouse (EDW) or analytics system. The uptake of analytics and an EDW is largely voluntary. End users-- customers-- will turn their back on your EDW if it's not operated by pleasant people, if it's not easy to use, and if it doesn't meet the needs of those customers.

The executive sponsor and the EDW team need to have the mindset of a small business. You need to market the data content and the analytics products of the EDW. You need to assign customer service and customer account representatives. You need to educate end users about how to use data to improve their roles in the organization. You need to increase the data literacy of the organization. Imagine building a Home Depot in a community that didn't have anyone who knew how to use a hammer, saw, or screwdriver? There's a reason Home Depot provides free classes on home remodeling and repair--it generates business. If your organization doesn't know how to be data driven, you better teach them if you hope to be successful as an Enterprise Data Warehouse team. You need to have a user friendly, attractive internal web site that advertises your EDW products and services, exposes your metadata, and creates an interactive site where users of the EDW can collaborate and provide feedback to the EDW team.

One of the most common chronic diseases that detracts from the ROI of the EDW is a passive, "If you build it, they will come" attitude. Worse yet, the attitude that is driven by misplaced paranoia, territoriality and protectionism of the data in the EDW-- organizations spend the money to build an EDW then create a giant bureaucratic pain in the neck to get access and utilize the data contents.

Everything that applies to the success of a small business, applies to the success of an EDW.  If you want to be successful with analytics and an EDW in your organization, you must have a small business mentality.

Flex your entrepreneurial muscles...!

:-)

Saturday, January 11, 2014

Ten Years from Notes to Reality

What notes are we scribbling down today that will come true in ten years?

I was cleaning out my old files this morning-- New Year ritual-- and came across a folder labeled "Career Chapter 4: HDWA Conference, Baylor".  HDWA stands for the Healthcare Data Warehousing Association (www.hdwa.org and the same LinkedIn Group).  In 2004, Baylor hosted our second annual conference, after Presbyterian Health hosted the first in 2003.  The 'Career Chapter 4' was referring to the steps in my career up to that point: (1) Air Force; (2) TRW; (3) Start up of Information Technology International; and (4) Healthcare.

In 2004, I was winding down my role at Intermountain Healthcare as the Chief Architect for the Enterprise Data Warehouse and Regional Director of Medical Informatics at LDS Hospital; and preparing for the transition to Northwestern University as one of two CIOs-- partnered with Tim Zoph-- at the medical center.

Inside the folder was the agenda for that HDWA conference and these handwritten notes in the images below.  I remember sitting alone at breakfast in the hotel, preparing my comments for the conference, scribbling these notes down with a sense of internal urgency-- "We can't keep reinventing the healthcare analytics wheel."

A note of thanks goes to my friends, Jim McPhail at Baylor, for hosting the conference that year; and Susan McFarland for doing all the work to organize and keep HDWA running for these many years.  Susan worked for me at Intermountain.

With the formation and momentum of Health Catalyst, (www.healthcatalyst.com) we are making these scribbled notes come true.  It's a stark reminder to me that the evolution of dreams and aspirations can wander for many years before they emerge as reality. Patience, preparation, steady persistence and luck play major roles.

Let's scribble down some more notes, shall we?

In gratitude,
:-)
Dale




Tuesday, December 17, 2013

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.

Friday, December 6, 2013

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.

SpaceX Inspirations

SpaceX launched a two-astronaut crew yesterday, on a mission to dock with the International Space Station. It was the first human spaceflig...