Defining a Rational Healthcare Value Network

A value network is a marketing concept that describes the social and technical resources (supply chain) within and between businesses. They account for the overall worth of products and services, including the collection of upstream suppliers, downstream channels to market, and ancillary services that support a common business model within an industry. The kind of value network that the healthcare system needs focuses on bringing increased value to healthcare patient (consumer) and reward providers for delivering high-value care.

Such a value network has four primary interacting components, as depicted in figure above. These components enable cyclical data flows—affected by drivers and impediments—that increase care value to the patient:

1. The green box refers to three types of data required to build the information and knowledge people need for increasing value across the supply chain. The education data refers to formal and informal ways that people share their knowledge, ideas, and experiences. Research data, on the other hand, is used in controlled clinical trials, outcomes and performance studies, various types of biosurveillance (e.g., post-market drug and device, public health), preferred clinical guideline development, and other types of research. Technology data refers to the date collected by EHRs and other health IT (HIT) tools, as well as streamed through durable medical equipment.


2. The five blue boxes refer the transformation of the data using a variety of HIT tools and clinical processes that promote the kinds of knowledge and understanding that fosters more effective and efficient care (services and products). They include (a) use of evidence-based guidelines, personalized care plans, decision support tools, and communication networks; (b) methods of information sharing and care coordination; and (c) patient empowerment. Each activity (process) in the blue boxes supports value by requiring quality handoffs and continuous measurement, assessment, feedback and acceptance at each breakpoint (the gap between each activity) to ensure value creation via continuous quality improvement (CQI).


3. The red box on the bottom refers to the technological, psychological, economic, and regulatory factors that promote or inhibit value to patient by influencing (driving or impeding) the blue box processes. Some of the key influences are listed in the box.


4. The purple box represents good patient outcomes; it is the desired result of using the data, tools and processes to increase value to the patient. The curved purple arrow pointing to the Data Types box indicates the need to provide data about the process, influences and outcomes of care across the entire supply chain via continuous feedback loops. The blue box activities and their related influences that help achieve the goal of higher quality at lower cost are reinforced; those that do not are modified or eliminated.

Leveraging health IT to promote value through CQI is a strategy that focuses on (a) learning from our past, current and futures practices to determine what results in the best outcomes at reasonable cost and (b) transforming this knowledge into high-value healthcare. This solution fosters greater care quality and affordability through (a) use of appropriate evidence-based guidelines and lessons learned; (b) implementation of personalized care plans and decision support tools; (c) information sharing among collaborative teams in social and technology networks; (d) informed decision-making; and (e) fostering patient compliance and responsible behavioral choices.

This CQI solution does not strive for zero defects (no errors of omission and commission) because perfection assumes infinite resources and knowledge, both of which are unrealistic. Instead, it is based on the Michael Porter’s value chain model, which assumes defects (errors) will occur and, therefore, we had better accept some reasonable level of tolerance, reconcile mistakes and poor outcomes, and strive to ensure ever-better outcomes at reasonable cost for a given condition.

Ensuring patient access to high-quality healthcare at reasonable cost through the value-driven CQI solution requires adherence to these critical process transformations:

• Supporting value for each primary activity through quality handoffs (the transfer of information, as well as authority and responsibility, during transitions in care across the continuum) along with ongoing measurement, assessment, feedback, and acceptance at each breakpoint (the gap between each primary activity).
• Assuring that all infrastructure or support activities (a) promote a seamless support relationship that benefits the primary activities, (b) avoid impeding the primary activities, and (c) follow CQI rules for each component across the entire healthcare spectrum.
• Operating with awareness of current healthcare system shortcomings that focuses on areas with quality improvement is warranted.
• Addressing the problems associated with defining quality in real time versus retrospective analysis, for both individual patient and aggregate data.
• Focusing on root cause identification to determine the factors preventing clinical outcome and cost improvement, instead of playing a “blame game,” which only exacerbates the problem.

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  technologies that provide 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 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 (1^st party) e-mails a request for it to the party with whom the PHI resides (2^nd party). Upon receipt of the request, the 2^nd party responds by sending the requested PHI to the 1^st 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 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.

Data->Information->Knowledge: Formula for improving healthcare

As a clinician, health IT architect and computational model-builder, I’ve been focused for the past three decades on how to use health IT to transform data into information and information into knowledge, in a way that improve care value. I’ve come to realize that highly effective and efficient care delivery (including prevention, assessment of risk, and the diagnosis oand treatment of health problems) depends on useful, valid clinical knowledge providing evidence-based decision support.

This knowledge can help continually improve care outcomes though methods and tools such as patient-centeredcognitive support, computerized clinical decision systems, and evidence-based clinical practice guidelines/pathways. These things are necessary if we want bridge the knowledge gap.

 In any case, gaining this crucial knowledge depends on creating, continually evolving and disseminating useful, actionable, valid information and presenting it in a way that avoids overloading the clinician and patient.

 And generating such valuable information requires adequate amounts and diversities of valid and reliable data. Some of these requisite data can come from today’s "Big Data" stores, which are typically insurance claims (administrative) data. While such claims data have usefulness, they are grossly inadequate when it comes to creating the kinds of information and emerging the kinds of clinical knowledge necessary to improve care quality and cost in any truly meaningful way.