Usability = Adoptability: What if Facebook and Amazon Built an EMR?

Below are screen mock-ups based on Facebook's and Amazon's user interfaces.  Borrowing ideas from them is comfortable because they parallel healthcare processes quite nicely, but also because the user interfaces on today's EMRs are abominable, and adoption rates are terrible (without financial coercion) as a result.  People flock to Facebook and Amazon by the millions, without financial incentives.  Why?  Because:

Total Value of Software Applications = Functional Value x Usability

If either Functional Value or Usability drop to zero, the overall value of the application drops to zero as well.  EMRs might be functional, but they are not user friendly, so their Total Value to healthcare is very low.

In Facebook, we have a perfect framework for longitudinal documentation, collaboration, messaging, and scheduling between a patient and members of their entire care team, including family and friends.  We also have a framework for easily integrating data from other sources to enhance the value to the patient's healthcare-- there's no equivalent of HL7 interchange going on in Facebook.  It references data located in other sources and systems. Can you imagine Facebook surviving if it required itself to house all the data that it presents?  Facebook takes great advantage of referencing and pointing to data in the source systems to build rich content.

In Amazon, we have a perfect and familiar metaphor for ordering tests and procedures; tracking them; assessing their costs; rating them and seeing how other clinicians rated those orderables and referrals; and adjusting orders based on the behaviors and ratings of other clinicians, etc.

Here are the screen shots.  Let's start building these, eh?  Think Mark Zuckerman or Jeff Bezos would help? :-)

Biggest IT Trend in 2011: Business Units Absorb More IT?

This prediction-- that business and clinical units will absorb more IT functions and thus further the decentralization of IT-- was presented to me for reaction, based upon an on-line discussion forum on Tech Republic.  Below is an excerpt from the discussion.

Prediction:  “The biggest trend of 2011 will be the continued decline of the traditional centralized IT department.”   

Reaction: I only partially agree with this.  I’ve seen this cycle before and a totally decentralized IT function does not serve a company effectively when systems and applications must be managed and integrated across business units, especially at the workflow and data content levels of integration.  The easiest aspect of IT to distribute to the business units is specific configuration of the application, such as unit-level or personalized preferences, that does not affect enterprise workflow or data content.  I’m a strong advocate of designating Super Users in the business and clinical units who are empowered and trusted with greater than average access rights to the applications and systems; in essence, functioning as deputy members of the centralized IT team.

Prediction:  “More companies will continue to align their IT professionals with individual business units rather than in a central services group.”  

Reaction: I’ve aligned my centralized IT teams with business units in this fashion for many years by creating a culture and a sense of customer service from IT to the business units, so that day-to-day, my Analysts get their marching orders from their customers, not through me.  Likewise, I’ve used joint performance evaluations to reinforce this relationship.  In some cases, commonly in larger organizations, I’ve done the same thing with Desktop Support so that my Technicians are assigned specific customer areas—as shown successful with local policeman who are assigned to neighborhoods-- rather than the old-school first-in-first out assignment of problems in response to phone calls.

Prediction:  “The demand for corporate-savvy IT professionals who can serve as business analysts and project managers will continue to grow.” 

Reaction: Agree, but not necessarily suggesting that this demand will outpace the need for technology specialists.  Cloud computing has so far not diminished the need for locally qualified engineers and technicians in the data center, the Help Desk, and desktop support.  The biggest problem with the recent growth in Analysts is the assumption that these Analysts can succeed with a limited IT background or limited IT technical knowledge.  There’s nothing worse than a Project Manager or Analyst who is technically incompetent.  They mismanage projects and expectations, don’t understand the implications of their decisions, and cannot effectively perform meaningful options assessments.

Prediction:  Meanwhile, many of the technical roles in IT — from server administrators to help desk technicians to network engineers to software developers — will get outsourced to companies that specialize in those areas.   

Reaction: This would be true if the costs to outsource were affordable, but in most cases, they are not yet.  More likely than full outsourcing, I see modestly capable technical teams in small-to-medium size businesses, augmented by advisors and experts from companies who provide that type of outsourced service, on an as needed basis, usually through hourly contracts or block time purchase agreements.

Prediction:  “In return for giving up some control, these organizations will get 24/7/365 service and a fleet of IT professionals with more specialized skills at their disposal. This doesn’t mean that there will be a net loss of IT jobs in the market, but many of the jobs will shift from individual companies to service providers that work for lots of different companies.”  

Reaction:  Not true, until: (1) The cost outsourcing drops significantly; (2) Outsourcing companies can define a more effective way of structuring Service Level Agreements that protect their service levels guarantees, but yet give the customer the ability to interact with systems at a low level, especially data content and application integration, and hold the outsourcing company accountable for performance, in the same fashion as they would an employee in their own data center.  Complete dependence on an outsourcing company, who hosts your data and your applications, immediately places customers in a position of subordinate negotiating power because, at the end of the day, the vendor holds the cards if they hold your data and applications.

In Conclusion

Generally speaking, the attraction is greatest to a distributed IT function, with direct assignments to the business units, when: (1)  The CIO and centralized IT function are culturally more inclined towards technology than business processes; (2) The other C-level executives, such as the COO and CFO, are power hungry and want full control of the IT assets needed to achieve their mission; or (3) The CIO, despite having an inclination towards the business instead of the technology, has failed in some way to meet the needs and expectations of the business units.  In this last case, the business units will quite often find that they are no better, and sometimes worse, at meeting their own needs than was the central IT group, and the cycle towards centralization will return.

Moving at the Speed of Software

Your company, regardless of industry, is now controlled by software.

People are still the underlying foundation of any company, but the best people can be no better than the software they use to perform their jobs.  You can only move and adapt as fast as your software can move and adapt.  Likewise, if you are building bricks and mortar facilities, they too must be adaptable to the changes in business models that are being driven by the Speed of Software.  In other words, heavy investments in bricks and mortar can inhibit the ability of a company or industry from leveraging the benefits of delivering their products and services through rapidly adaptable software.  I was touring a healthcare organization recently that is building a beautiful new "Cardiology Services Tower" in anticipation of the aging baby boomers and their needs.  The thought that kept running through my mind as I reviewed the plans:  You are building an enormously expensive structure here that will last at least 40-years, but is based upon the old way delivering healthcare, including the relatively new and already outdated notion that a hospital should be a 5-star resort.

The future of all industries is defined by software, not bricks and mortar.  Don't buy software that can't adapt, and don't build buildings that paint you into a corner and that can't leverage the Speed of Software.

The Importance of Disease Registries

This article underscores the importance of using disease registries for proactive management of chronic disease. These registries are not the same concept as traditional disease registries used for reporting to government and public health authorities. These are disease registries which are integral to the day-to-day workflow of patient care and functional use of the EMR. Registries such as this are still woefully under-utilized in healthcare, and should be a standard functional element in EMRs, but yet are a common concept in other industries such as telecom and retail which maintain customer relationship registries based on demographics, buying habits, etc. Disease registries are the first step in creating a standard, data-driven definition for a particular disease, and then proactively managing patients who meet that definition. You can't manage or measure what you haven't defined.

"DENVER – An intensive population management program that matches heart disease patients to personal nurses and clinical pharmacy specialists is able to save lives, reduce hospital visits and drive down costs, according to a new study from Kaiser Permanente Colorado."

Heart Disease Management at Kaiser Permanente Colorado

True Healthcare Reform

I will trust that true healthcare reform has arrived, when doctors stop wearing stethoscopes like a policeman wears a pistol... At the ready, all the time, just in case a violent heartbeat breaks out or a congested lung tries to hold up a 7-11.

That was a friendly jab at my physician friends...like they jab me for wearing a pocket protector.

;-)

Evidence-Based Medicine’s Giant Leap

Cerner and the British Medical Journal (BMJ) have teamed to provide evidence-based medicine (EBM) embedded in the electronic medical record in a manner that is as exciting and encouraging a development in healthcare IT as anything I’ve ever seen — I repeat, as exciting as anything I’ve ever seen. Coming from a noted cynic and critic of healthcare IT, this flash of optimism is a significant change in the wind.

I was attracted to healthcare by the huge greenfield opportunity to apply the lessons I learned in military command centers (the Universe loves irony) about embedded computerized decision support. I’ve been searching for a sustainable piece of grass in that green field ever since.

One of the factoids I enjoy throwing around is the length of time that elapsed before US healthcare providers widely adopted and routinely practiced EBM for the treatment of community-acquired pneumonia —17 years. The Mean Time To Improvement (MTTI) in healthcare is abysmal, but not because clinicians are unwilling to change, rather because the clinicians don’t always know how to change or whether they should change at all.

The BMJ methodology provides clinicians with a trustworthy and convincing source of evidence upon which to justify a change in clinical behavior; and the integration of the BMJ knowledge into Cerner’s EMR gives clinicians an easy avenue for practicing that change in a fashion that can drive the MTTI in healthcare from decades to days. That’s not a dramatic overstatement — this collaborative effort between Cerner and BMJ, and what I hope will be similar efforts in the future, can radically lower the MTTI in healthcare.

As I mentioned in previous blogs, one of my major challenges in this relatively new position as CIO is to squeeze more value — measurable and perceived — from the Cayman Islands’ substantial investment in Cerner’s products. At the same time, we are undertaking a new care delivery model here that looks and feels very similar to the concepts evolving in the United States under an Accountable Care Organization (ACO) and Medical Home.

Among other commitments, our new model (known as CayHealth) is contractually committed to practice and measure EBM. The challenge, of course, is to enable EBM, that is, make it as easy as possible for clinicians to practice true EBM and then measure that practice somehow. This marriage of BMJ’s EBM content with Cerner’s Millennium application suite is an opportunity to do both — derive more value from the Cayman Islands’ Cerner investment, as well as support the imperatives of CayHealth.

Historically, there have been several barriers that were too high for EBM to hurdle:

• Governing the definition and content of EBM
• Updating, maintaining, and disseminating EBM to clinicians in a timely fashion
• Efficiently integrating EBM into the clinicians’ workflow
• Achieving all the above while making EBM affordable

The Cerner-BMJ collaboration knocks every one of these hurdles to the ground.

BMJ’s methodology for defining and maintaining a clinical practice as “evidence based” is Gibraltar solid. Likewise, the clinical content that is developed and governed is not based exclusively upon BMJ articles — BMJ knowledge engineers are collecting evidence from 110 of the premier medical journals across the globe. Their “Grading of Recommendations, Assessment, Development and Evaluations” (GRADE) working group is insightfully well-conceived as a means of removing as much subjectivity as possible from the governance process for declaring a fact to be “evidence.” As I studied in preparation to write this blog, my admiration for what BMJ has managed to organize and achieve kept growing.

While the governance and management of EBM is an enormous achievement for BMJ, all of their work would likely sit on the shelves of dusty Web pages, as is the case with many other sources of EBM in the world today, were it not for their collaboration with Cerner.

Knowledge engineering always suffers from this “And a Miracle Occurs” cloud between the knowledge management system and the computer systems supporting the decision maker. Converting human knowledge into a computable decision-support system for use by another human being is the Achilles Heel of knowledge-based systems, especially in the complex world of healthcare. To highlight only two of numerous examples, rules-based systems are too fragile and Bayesian neural networks too challenging to build and train to support the entire healthcare industry.

Cerner and BMJ found a way to convert the human knowledge derived from scouring 110 medical journals into a format that Cerner can import into Millennium and present to the clinician. This will enable the right decisions at the point of care — the EBM decisions. When you see the presentation of BMJ’s knowledge in Cerner, you’ll probably say the same thing I said — “Is that all there is?” — feeling somewhat underwhelmed. Then, however, you’ll realize, “That’s all we need.”

If you are a Cerner customer and you’re not looking into this collaboration with BMJ, I encourage you to do so. As CIOs and healthcare leaders, we need to nurture and encourage these types of developments in the market.

If you are aware of other similar collaborations between clinical knowledge engineers and EMR vendors to co-develop EBM of this type, please share.

Here are a few reference links for more details:

• BMJ and Cerner Action Sets: http://group.bmj.com/products/evidence-centre/cerner/
• The BMJ Methodology:http://clinicalevidence.bmj.com/ceweb/about/put_together.jsp
• GRADE Scoring of Evidence: http://clinicalevidence.bmj.com/ceweb/about/about-grade.jsp
• Updating and Maintaining Evidence:http://clinicalevidence.bmj.com/ceweb/about/updating-process.jsp

Don't Be Strangled By Process-Improvement Black Belts

In ITIL, we healthcare CIOs are acting in predictable fashion by following the “Most Popular Practice” as opposed to the “Best Practice.” Before we pull the trigger on yet another silver bullet savior of process, I urge all of us to look closely at the contribution of burdensome process in the woes of Toyota…and GE…and Motorola. Try though we might to fix the problems of healthcare IT with rigorous process-- most recently ITIL-- we’re only putting lipstick on a pig.

Fat processes like ITIL will only make matters worse for us until we fix the core issues: (1) Stop buying poorly designed software systems and insist on something better from vendors; and (2) Hire and mentor engineers, computer scientists, mathematicians, and musicians into healthcare IT and stop microwaving nurses, doctors, registrars, and technicians into overnight software developers and IT professionals.

Background
Those of you who know me, know that I’ve admired Toyota for many years, particularly their philosophies of leadership, employee relations with management, Lean manufacturing and the Toyota Production System. My faith in Toyota is taking a beating as I watch it struggle with one recall after another, even though, I’m betting, the problems with runaway acceleration will more likely be associated with driver error than faulty design. We’ll see what the Failure Modes and Effects Analysis (FMEA) team at NASA has to say when they release their report in the next few weeks.

Even so, there’s no getting around the fact that Toyota is losing its edge in quality and innovation—they’ve been out-Toyota’d by Hyundai and Kia. In fact, at the rate they’re going, Toyota is going to be out-Toyota’d by Ford. The root cause of Toyota’s problems is, of course, a tangled web of roots, but I see a common thread that crosses the fabric of other companies across 30 years—and the common thread is Process Overkill.

In the Air Force, I was one of Motorola’s biggest customers for their new products, notably spread spectrum and CDMA networking (but many other radio-based systems as well). I was around when Six Sigma was a Motorola baby — that was in the early 1980s when quality and reliability were more important to the military than product agility and innovation. I thought Six Sigma was the coolest thing around. Everyone thought Six Sigma was awesome … including Motorola … they burned Six Sigma into their hiring, organizational structure, and the DNA of the company.

Then they started believing their own press or, as my granddad would say, started drinking their own bathwater. Fast forward to the mid-1990s, when it wasn’t enough to produce reliable products anymore … you had to produce reliable and innovative products, faster than ever before. Mean Time Between Failure (MTBF) was replaced by Mean Time to Improvement (MTTI) (that’s a Sanders Theory and phrase…so don’t bother to Google it). Six Sigma bogged Motorola down like a Mississippi mud walk, and they still can’t get it off their feet. Motorola might be able to produce a fairly reliable product, but you couldn’t possibly describe Motorola as innovative. They’ve been strangled by the Black Belts of Six Sigma.

Jump to the late 1990s and early 2000s … cut and paste the exact same story at Motorola, then do a global replace with “GE” and “DMAIC”. Jack Welch was to GE what Steve Jobs is to Apple, and without either leader the company identity is completely different. Nevertheless, the weight of DMAIC on GE has them stuck in the mud walk of innovation, too — Jack Welch or not. Drive the time machine ahead to 2009 and do the same cut and paste, but this time insert “Toyota” and “Lean” into the story. Lean’s gone Fat at Toyota and their arteries are ready for a CABG.

In love with their own success and thirst for their own bathwater, Toyota over-applied Lean concepts, creating a bureaucratic environment that squeezed innovation to death (only the Chevy Citation was uglier than the current Toyota Camry), and cultured apathy in their design teams and production lines. Toyota might be salvageable, however, because their leadership still exudes humility and accountability. It’s going to be interesting to watch.

Do you believe for one second that Google’s search engine was the product of a DMAIC session? Or Apple uses Six Sigma or Lean Gone Fat in their product development? You could argue that a dose of better process would have prevented the worm in Apple’s recent 4G antenna problems, but the 4G, iPad, and iPod are the most innovative, best quality products to be produced in the US since the Apollo space program. It’s amazing to me that the 4G antenna problem is the only problem they’ve had in a string of pioneering, revolutionary products. Take away Apple and Google, and the only claim to major, society-wide impact and innovation we can claim in the U.S. since the late 1960s are hedge funds and credit debt derivatives.

The best processes are worthless in the hands of the wrong people. Does a good change-control process in the hands of a bonehead make a genius of that bone? No. Even worse, Processes Gone Wild — such as ITIL, Lean, Six Sigma, and DMAIC — are a disaster in the hands of great people. Good people trump everything. EVERYTHING. But the best people … the most innovative people … will not stick around if constantly force-fed ITIL, Lean, Six Sigma, or DMAIC. They’ll go to work for Apple and Google. The force-fed people and organizations left behind will end up as so much foie grais.

Sip from the cup of ITIL Kool-Aid, don’t gulp it.