Tuesday, July 31, 2012

Disruptive Innovation in Health IT: A Path to Acceptance (Part 1)

In this next series of posts, I’m going to focus on my experiences with introducing disruptive innovation in health information technology (HIT). I trust you'll find these discussions both enlightening and troubling.

Let’s start with defining the concept of disruptive innovation and its importance to healthcare.

What’s Disruptive Innovation

There are several types of innovation as depicted in figure below:

  • Sustaining innovation delivers gradual improvements like enhancing software processes; it brings about gradual evolution rather than a revolutionary change. It does not create new markets or value networks, but rather only evolves existing ones with better value, allowing the firms within to compete against each other's sustaining improvements. Sustaining innovations may be either "discontinuous" (i.e. “transformational" or "revolutionary") or "continuous", "i.e., "evolutionary.
  • Disruptive innovation (as defined by Clayton M. Christensen) turns the conventional paradigm of the market on its head, not by improving on competitors’ offerings, but by actually reducing functionality. That is, disruptive innovations make products simpler and less costly. This wreaks havoc within many industrial sectors, where, sensing opportunities at the bottom of the market, large companies will frequently choose to ignore it, dismissing it as “not competing in their space.”It helps create a new market and value network, and eventually goes on to disrupt an existing market and value network (over a few years or decades), displacing an earlier technology. They are generally technologically straightforward, consisting of off-the-shelf components put together in a product architecture that is simpler, more convenient and less expensive than prior approaches. They offer a different package of attributes valued only in emerging markets remote from, and unimportant to, the mainstream. 

What’s the Importance of Disruptive Innovation in Healthcare?

Disruptive innovation can play a significant role in solving our healthcare crisis by challenging the status quo.

According to Deloitte Development LLC: “You can feel it happening in the marketplace around us. Retail clinics, medical tourism, technology-enabled self care — disruptive innovations in the U.S. health care system challenge the status quo. These and other new phenomena zero in on unmet needs, leverage new technologies and business models, and deliver enhanced value throughout the health care supply chain. When they work, they change the game.

Make no mistake: the U.S. health care industry is in crisis…Health care delivery is convoluted, expensive, and often deeply dissatisfying to consumers…We believe that a whole host of disruptive innovations, small and large, could end the crisis—but only if the entrenched powers get out of the way and let market forces play out. If the natural process of disruption is allowed to proceed, we’ll be able to build a new system that’s characterized by lower costs, higher quality, and greater convenience than could ever be achieved under the old system…Attempts to use regulation to stave off disruptive attacks are quite common…Unfortunately, regulators are inclined to be...protective of the entrenched professions and institutions in health care…The links between those institutions, federal and state regulators, and insurance companies are strong; they are wielded to preserve the status quo…Government and health care industry leaders need to step forward—to help insurers, regulators,… hospitals, and health professionals work together to facilitate disruption instead of uniting to prevent it. If they do…health care providers will realize the opportunities for growth that come with disruption—because disruption is the fundamental mechanism through which we will build a higher quality, more convenient, and lower cost health care system. If leaders with such vision do indeed step forward, we will all have access to more health care, not less.
In my next post, I discuss my personal experiences of how government regulators and HIT vendors respond to the introduction of disruptive HIT innovations.

Thursday, July 26, 2012

ONC’s Direct Project: In Defense of Simplicity

Over the past year or so, I’ve been deeply involved in various Federal gov’t health IT initiatives, including the Direct Project and Query Health. This is first time, I believe, that the public (private sector “outsiders”) has had access to the inner-workings of the Office of the National Coordinator for Health Information Technology (ONC). While I’ve been delighted with this new level of transparency, I’ve been dismayed by the way the process tends to transform simple ideas and sensible goals—aimed at improving care quality and efficiency—into overwhelmingly complex, convoluted and costly technical specifications and requirements!

One of the reasons for situation is that people often “come to the table” with preconceived notions of what is possible and how do it. These narrow/closed mindsets are either unaware or prone to reject disruptive innovations (i.e., technologies providing simple inexpensive solutions through the “novel combinations of existing off-the-shelf components, applied cleverly to a small, fledgling value network”) in favor of conventional technologies (commodities) that lack those positive qualities. Following is just one example.

A few months ago, Dr. John Loonsk (CMO of CGI Federal) wrote a widely cited article at this link in which he criticizes the Direct Project’s reliance on SMTP (Simple Mail Transfer Protocol)—the simple method for transporting e-mail messages that’s been widely used since the early 1980s. His criticism is based on the fact that SMTP uses a “store and forward” process in which messages are stored locally (in the user's computer) and then sent to the recipient. He claims that SMTP is insufficient and thus should be augmented by types of Web Services, such as SOAP or RESTful methods, which tend to be considerably more complex than SMTP.

In his critique, Dr. Loonsk takes a “closed inside-the-box” view of SMTP-based e-mail. Following are my responses to his key issues. In contrast to his narrow conventional point of view, my replies take an “open outside-the-box” perspective of SMTP’s capabilities that incorporates a novel (disruptive) publish/subscribe (pub/sub) node-to-node desktop architecture (see this link for technical details).

Issue 1: Dr. Loonsk wrote that “the store part of SMTP…introduces new security concerns even with encrypted data.”

My reply: Since when is the encryption of stored files not enough? These days, it is free and easy to encrypt not only individual files, but even entire hard drives (or partitions) can be protected with bit-locker encryption. With this kind encryption of stored files, along with encryption of e-mail in transit (e.g., using PKI), Protected Health Information (PHI) is protected end-to-end (in transit and at rest), which is about as secure as you can get!

In contrast, the Web Services approach can leave PHI exposed at the web server, e.g., when Web Services provide the in-transit encryption and when they transform the PHI format as it passes between disparate EHRs. With the SMTP pub/sub node-to-node architecture, on the other hand, all encryption and PHI transformations are done by the sender prior to transporting the e-mail.

One more thing about XML security: Encryption vulnerabilities. According to an interesting (and technical) blog post by a cryptographic engineer, encrypting XML securely requires extra steps to prevent a "ciphertext" attack that exposes the encrypted XML content. The author concludes: "If your system is online and doesn't have a solid, well-analyzed protection against them, don't pretend that you're doing anything at all to secure your data. I wish I had a funny, pithy way to sum this all up. But honestly, I'm just a little depressed."

Issue 2: Dr. Loonsk wrote that “Because SMTP store and forward infrastructure can only do the push transaction, it is a limited platform standard and a technical dead-end in trying to address other transaction needs…a true U.S. health system all seem to need more [which does] not stop with the data that one provider anticipates another provider will need…[nor] with the assumption that providers will reliably initiate a store and forward SMTP transaction to move the right data to all that need them.”

My reply: The SMTP pub/sub node-to-node architecture actually enables both “pull” transactions whereby the request for the transmission of information is initiated by the receiver, as well as “push” whereby the request for a given transaction is initiated by the sender. To perform a pull transaction, the party who wants to receive the PHI (1st party) e-mails a request for it to the party with whom the PHI resides (2nd party). Upon receipt of the request, the 2nd party responds by sending the requested PHI to the 1st party. Either or both parties can do his manually or have it done programmatically (automatically) by the software. This simple solution resolves the SMTP push-pull issue. Nevertheless, as reported by ONC in 2009, push messaging is crucial because it is "...less complex and will be far more readily available to a broader range of providers than so-called 'pull' technologies.

Issue 3: Dr. Loonsk wrote that, unlike Web Services and REST, the SMTP infrastructure does not support HIE functions such as “unanticipated needs, unanticipated providers, reliable data access from unreliable senders, accumulation of data into longitudinal and population records, accessing registries and data for decision support, accumulating quality reporting data, querying to get more data when needed, a raft of directory services, and with team care, the shared management of care plans, problem lists and other data.”

My reply: The SMTP pub/sub node-to-node architecture actually does support these functions and we’ve demonstrated such capabilities with our software tools using SMTP.

Issue 4: Dr. Loonsk wrote that “One argument for SMTP has been that it is more accessible to small providers. In practice, implementations to date have involved more complexity than predicted and…[rely] on an outside organization – a Health Information Service Provider (HISP) to carry the technical load. If a HISP is necessary, a more robust platform standard like Web services or REST would seem to be just as achievable as SMTP.”

My reply: Unlike Web services or REST, the SMTP pub/sub node-to-node architecture I’ve been describing does NOT rely on a HISP since the desktop e-mail client (MS Outlook in our case) carries the technical load, not the HISP. To comply with the Direct Project requirements, however, we use a HISP for PKI certificate management and provider registries, but the actual e-mails pass right through the HISP from senders (publisher) to their recipients (subscribers).

In conclusion, the view of Dr. Loonsk and many others fail to realize how breakthrough (disruptive) innovations, like our novel SMTP architecture and apps, can accomplish what seems impossible to folks focused conventional technology. Though no doubt well-intentioned arguments by intelligent people, their criticisms do not provide good reason for denigrating the simple, sensible, survivable solution SMTP provides.