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...!

:-)

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

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.

Leadership Path: Milestones of Coincidence

Knowing how to make an optimal leadership decision when the perfect decision is elusive or impossible has always been a struggle for me.  I've written about the role of pure motives in these decisions, which was a major philosophical breakthrough for me, but there's another vital sign indicator that I'm on on the right decision and leadership path, even when it feels like that path is ladened with trouble.

My family's Aunt Harriet "Pat" Manuel wrote this to me in my high school graduation card. I didn't 'get it' back then, but I learned to get it as I grew older-- the incredible truth and amazing beauty of it:

"There are meaningless coincidences in life and there are meaningful coincidences in life. Your heart will know the difference if you listen to it. The meaningful coincidences are God's milestones, telling you that you are on the right path. Watch for those milestones. Be worried when you don't see them; be at peace when you do see them, and stay on that path." 

I shared her wisdom in a business email yesterday for the first time ever.

When I'm troubled by a difficult decision that I'm about to make, or that I did make, and unsure about the decision's validity, I keep my mind open to the presence or absence of these meaningful coincidences.

Evaluating a Clinical Analytics and Data Warehousing Solution

The healthcare analytics market is a crowded and chaotic one, with many vendors lining up to claim they can help providers use their data to improve care and lower costs.  Making a wrong decision at this time in the market will paint you into a decision corner that could last 4-5 years, at least, while the market rapidly moves past your organization towards accountable care and quality-based payment models.  You cannot afford the time to recover from a bad decision.  So how do you cut through the noise to find a solution that makes the most sense for your organization?  This blog is designed to help you with that decision. 

General Criteria for Assessing a Healthcare Analytics Vendor

Embarking on an assessment with the knowledge of key, general criteria can help you determine whether a vendor has the philosophy, experience and viability that can lead to a successful outcome for your organization. By evaluating vendors according to the following, you can narrow down the list considerably.

Completeness of Vision

What lessons does the vendor bring from the past healthcare analytics market and how have they adjusted their current strategy and products accordingly?  Can they bring lessons from other industries that are more advanced in their adoption of analytics? What is the vendor’s understanding of the present market and industry requirements? What is their vision of the future for healthcare analytics? Look for vendors who can clearly outline how they have evolved to meet—and anticipate—industry needs. 

Culture and Values of Senior Leadership

It’s no cliché, but rather the precise truth: the overall culture of a company starts at the top.  Get to know the senior leadership of the vendors you are evaluating.  Insist on meeting several members of their executive team.  Simply put, do the culture and values of a vendor’s senior leadership align with yours? When interacting with individual members of the vendor’s team, ask yourself, “Would I be excited to hire this person into our company?”  If the answer is consistently no, find another vendor. More than technology is required to leverage analytics to drive real, sustainable change. Cultural transformation will be required throughout your organization. If your culture and values don’t mesh with that of your vendor, you will encounter significant roadblocks to success.

Specific Experience & Ability to Execute

Nothing is more important than the vendor's specific, related experience to the problem you are trying to solve, and their track record.  The HealthCare.gov web site fiasco is a classic example of a vendor who had general experience building web sites, but not specific experience of the type required by the project. Make sure the vendor has a track record for delivering value and satifaction to their clients, on projects that look and feel precisely like yours. What do KLAS, Gartner, Chilmark, and the Advisory Board have to say about this vendor? Find at least three, preferably five, referenced accounts.  Do not accept referenced accounts that are pre-screened and selected by the vendor—every client of the vendor should be open to serve as a reference.  Do the vendors you are considering have solid referenced accounts that are similar in size and demographics to your company? Ask these references very simply: How satisfied are you with the vendor’s products, services, and overall value? Would you hire them again?

Technology Adaptability and Supportability

The reality is, in today’s connected world, all businesses, including healthcare, move at the speed that their sofotware can adapt-- either fast or slow-- to new processes and business models.  Therefore, the underlying engineering and architecture of that software is critically imporant.  You must peel back the covers of the vendor’s products and evaluate their software engineering for modern design patterns like object oriented programming, service oriented architectures, loose coupling, late binding, and balanced granularity of software services.  Glossing over this assessment is akin to buying a multimillion dollar office building without assessing the modularity of the walls and soundness of the foundation, plumbing, and electrical systems. How fast can the system adapt to the market and your unique needs for differentiation? Data standards, vocabularies and analytics use cases are changing rapidly in the healthcare industry, literally everday, with no signs of slowing down. Find a vendor whose software engineering can keep up.  Analytic agility is critical.  Executives in your organization can’t wait weeks and months anymore for a new report to inform a critical decision. The industry is changing too fast.

Total Cost of Ownership

The best solution in the world is of no value if it’s not affordable.  To assess affordability, you must understand the total cost of the vendor’s solution. Measuring Total Cost of Ownership (TCO) is easy—add up the three-year labor costs, licensing fees (including third party), support fees, and hardware costs associated with a vendor’s solution. Many old-school analytics vendors require a significant upfront investment with no guarantee of value for two years or more.  Your TCO over three years should be evenly distributed, not front-end loaded, and your contract should be structured with escape clauses if the vendor’s solution cannot prove value in the first year. In today’s market, clients should expect initial value from analytics vendors in less than six months, preferably three.  If a vendor cannot or will not commit in their contract to this timeframe for delivering value, look for another vendor.

Company Viability

The key question here is: Will the vendor be around in nine years (the average life span of a significant IT investment)?  If not, can you live without them? Take advantage of evaluations by neutral third-party analysts like Gartner, Chilmark, KLAS and The Advisory Board. What are these analysts saying about the vendor’s prospects in the market?  Is the vendor in solid financial shape?  What’s their monthly burn rate vs. income? How many days cash-on-hand do they maintain?  What’s their sales pipeline look like? Does the vendor’s executive leadership team have a track record for jumping from one company to another or do they have a track record of longevity and success?  How much is the vendor spending on sales staff in comparison to engineering and product development staff?  The best products are supported by a very lean sales staff—great products sell themselves.

Technology and Cultural Change

Technology is vital to the success of an analytics initiative, but it is only one part of the solution.  The meaningful use of analytics is one of the most difficult things for organizations to achieve, culturally.  A successful analtyics implementation establishes the technology as well as the sustainable cultural changes required to turn the insights from data into improvements in patient care and reductions in cost. 

Technology

When evaluating a vendor’s technology, be sure to look at the following:

Data Modeling and Analytic Logic

Different vendors’ analytics solutions feature different data models. Which data model they use can have a significant effect on the cost, scalability and—especially-- the adaptability of your analytics solution to support new use cases. Rapidly adaptable and very flexible, a bus architecture is the best data-modeling option for healthcare. Most vendors utilize a healthcare-specific enterprise data model at the heart of their solution, but these enteprise data models are difficult to load and map initially, and slow to evolve subsequently, when faced with new use cases and source system data content. Over-modeling data is the single most significant contributor to data warehouse and analytics failure in healthcare.  My advice is simple:  Stop modeling your data and start relating it.  Relating data is what analytics is all about.  These enterprise data models come in three basic flavors, so be aware of them. They are:  (1) Dimensional star schema; (2) Comprehensive, enterprise data model; and (3) I2B2.

In addition to the issue of data modeling, the analytic logic associated with the content of data marts and reporting is critically important.  To learn more about the role of data modeling and “binding” data to business and clinical logic in healthcare analytics, read this white paper: The Late Binding Data Warehouse.

Master Reference/Master Data Management

The ability to incorporate data from new and disparate sources into your analytics solution requires significant expertise in master data management. What is the vendor’s strategy for managing unique patient and provider identifiers? How does the vendor accommodate international, national, regional and local master data types and naming conventions? Do they support mappings to RxNorm, LOINC, SNOMED, ICD, CPT and HCPCs?  How tightly does the vendor bind your data to the vocabularies that change regularly?  The tighter the binding, the less flexible the analtyic design will be to accomodating changes in the vocabulary and analytic use cases based on those vocabularies.

Metadata Repository

An effective metadata repository is the single most important tool for the widespread utilization and democratization of data in an organization.  Look for a vendor that provides a tightly integrated, affordable, simple repository with their overall analytics solution.  The most valuable content in a metadata repository is not computable—the most valuable content is subjective data that comes from the data stewards and analysts who have interacted most with the data. Look for vendors that have the ability to maintain this subjective data through a wiki-style, wisdom of crowds contribution model. A web-searchable metadata repository should provide information such as the source of the data, how often it is updated, examples of the data, natural language descriptions of the physical data tables and columns, any known data quality issues, and the contact information for the associated data steward. The ability to quickly establish the origins and lineage of data in a data warehouse is also a critical component to an effective repository.   Analytic vendors tend to operate in one of two extremes: (1) They either oversell very complicated and expensive metadata repositories that require an overwhelming level of support and maintenance in return for a declining return on investment; or (2) They offer no solution for metadata management, which is disasterous to a long term analytic strategy.  Find a vendor that offers a simple, low cost, pragamatic solution between these extremes.

Managing “White Space” Data

Does your analytics solution offer a data collection alternative to the proliferation of desktop spreadsheets and databases that contain analytically important data? 

White space data is the data that is collected and stored in desktop spreadsheets and databases that it is not being collected and managed in primary source systems, especially EMRs, or it is being collected in clinical notes and must be manually abstracted for reporting and analysis.  This desktop data fills in the missing “white space” of analytic information that is important to the organization.  For example, these desktop data sets are commonly found in support of Joint Commission reporting, internal KPIs, finance analytics, and clinical researchers.  It is not unusual for healthcare organizations to have hundreds of these desktop data sources that are critically important to the analytic success of the organization.  However, because the data resides on desktop computers and shared drives, it cannot be integrated with other mission critical analytic data that is being stored in the Enterprise Data Warehouse from the primary source systems.  Data synergy suffers as a result.  White space data also poses information security risks.  Analytics vendors must provide a tool for attracting the management of white space data into the content of the EDW.  Look for a white space data management tool that is web based, as easy to use as a spreadsheet or desktop database for the collection of data, and makes is easy for end users to convert and upload their existing desktop data sets.  Also, look for a security model in the EDW that allows for the isolation and stewardship of these white space data sets.

Visualization Layer

The best analytics solutions include a bundled visualization tool, and this tool should be affordable and extensible if licensed for the entire organization.  However, the analytics visualization layer is very volatile.  The leading visualization solution today will not be the leader tomorrow.  Therefore, look for an analytics vendor that can quickly and easily decouple the underlying data model and data content in the data warehouse from the visualiztion layer, and swap the visualization tool with a better alternative when necessary. Also realize that a single visualization tool will not solve all of your organization’s needs.  Data analysts will want to use a variety of tools to access and manipulate data in the enterprise data warehouse.  The underlying data models in the data warehouse must be capable of supporting multiple visualization tools at the same time. Ask vendors if their data model is decoupled from the visualization tool. Does the data model support multiple visualization tools and delivery of data content?

Security

As always in healthcare IT, the privacy and security of patient data are paramount. Here are some important questions to ask a potential analytics vendor about security:

·       Are there fewer than 20 roles in the initial deployment?  Contrary to popular belief, more roles can actually lead to lower security and will definitely lead to higher overhead adminisrative support costs.

·       Does the solution employ database-level security, visualization-layer security or some combination of both?  The vendor’s solution should support both.

·       What is the vendor’s model for protecting patient identifiable (protected health information (PHI)) data and the more sensitive subsets of PHI that are typically defined at the local State-level, such as mental health data, HIV data, and genomic/familial data?

·       What type of tools and reports are available for managing security and auditing access to patient identifiable data?

ETL

A robust ETL process—how analytics technology extracts data from source systems, applies the required transformations and writes data into the target database—is fundamental to the success of your chosen solution. Ask vendors to demonstrate how their ETL measures up in terms of reliability, supportability and reuse.  At present, Microsoft’s ETL tool—SQL Server Integration Services (SSIS)—is by far the most cost effective ETL tool in the market, offering the highest value per dollar.

Performance and Utilization Metrics

As you implement and continue to use an analytics solution, you will need to generate metrics about who is using the system, how are they using it, and how well the system operates. Can the vendors’ solution track basic data about the environment, such as user access patterns, query response times, data access patterns, volumes of data and data objects? This kind of information will be essential to you as you refine and organize the data content and analytics services you provide from the data warehouse.

Hardware and Software Infrastructure

Does the vendor use Oracle, Microsoft or IBM for its hardware and software infrastructure? These three are the only viable options in today’s healthcare market and data ecosystem.  Hadoop and its associated open source tools is not an appropriate  analytic and data warehousing infrastructure option at this time in healthcare (accept for gene sequencing). Microsoft is the most integrated, affordable and easiest to manage of these technology platforms and now makes up 70% of all new sales in the analytics and data warehousing market, across all industries, far outpacing Oracle in new sales, it’s closest competitor.  Rumors about  Microsoft’s ability to scale up to large, multi-terabyte data warehouses are totally unfounded.  Microsoft’s parallel data warehouse platform can scale to the petabyte level, far beyond the largest data warehouse needs in the healthcare provider space.  Ask any data engineer that has worked extensively on either Microsoft or Oracle, “Which platform is the easiest to use and most efficient for delivering quick, adaptable analytics solutions?”  Their answer will almost certainly be Microsoft.

Cultural Change Management

As mentioned previously, technology is important—but it is only a part of the equation in creating a successful analytics program. A vendor’s solution must also include processes and real-world experience for helping your manage sustainable change in your organization, driven by analytics.  Nothing is more politically or culturally disruptive than the spotlight of analytics, not even the deployment of an EMR.  You want a vendor that has been there, in the trenches of cultural transformation driven by the enlightment of data.

The Healthcare Analytics Adoption Model

The model outlines eight levels of analytics adoption an organization passes through as it gains sophistication in using its data to drive improvement.  Like a course curriculum for college studies, following this model with discipline will lead to the successful adoption of  analytics in your organization, culturally and technically.  Use this model for evaluating vendors’ capabilities in each level—have the vendor demonstrate their products and services for each level. The model also provides a roadmap for your organization to measure your progress of analytics adoption.  Ask yourself, “How fast do we want to achieve the highest levels of adoption in this model?” With the right analytics vendor as a partner, organizations can achieve Level 5 within 18 months of implementing and following the model, and some organizations can make it in 12 months. Level 7 is easily achievable within 24-30 months.

This model provides a standard to help you move beyond a patchwork of point solutions to a robust, data-driven health delivery system capable of tailoring care while optimizing efficiency and cost. Does a vendor’s solution support each level in the model?  Ask them to prove it.

The details behind this model, including a self-inspection guide, can be found at: Healthcare Analytics Adoption Model

Conclusion

Healthcare is at the threshold of the next revolution in data management—being able to analyze and make informed decisions based on the data that organizations have been collecting and sharing. This is a critical time to set your organization on a pathway for data-driven improvement. The criteria outlined in this paper will help you choose an analytics partner with the expertise, processes and technology to help you achieve this objective.

On Leadership and Appreciation

I overheard a conversation in the airport the other day that was unusually profound.  It was between two men, one older and one younger by probably 20 years or more.  The older man looked and sounded like a member of the clergy-- or maybe a liberal arts professor.  The younger man was expressing concerns about not being fully appreciated at work.

Paraphrased, here's what the older fellow advised to the younger fellow about being under-appreciated:

"Don't settle for being unappreciated.  Find a better job.  You can do better.  Also keep in mind that humans, especially Americans, appreciate absence more than they appreciate presence.  Take away water, oxygen, money, shelter, health... a life... or a good employee... and you'll see a different level of appreciation in that absence.  We give posthumous medals and throw parties and parades when people die to show we appreciate them, but what good does that do?  You should keep looking for a job and the company of people who appreciate you, but realize that for most humans, we appreciate absence more than presence."

Throughout my career, it's not unusual for me to be labeled as being too effusive in my compliments and expressions of appreciation to employees, and thus lacking sincerity-- that my compliments and appreciation are so frequent and over the top, they must be fake.  Nothing could be further from the truth, so I stick to the behavior despite the occasional label.  I'd rather risk the label of being a fake, and face the Pearly Gates with the sin of being too appreciative, rather than being too little.  The Pearly Gates understand the sincerity.

Appreciate the presence.

:-)