Wednesday, August 08, 2012

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

In this fourth post of the series (see this link to start from beginning), I discuss my eye-opening experience volunteering for the technical workgroup of ONC’s (Office of the National Coordinator for Health IT) Query Health initiative. I’ve been averaging several hours a week working with the group since Sept 2011, have been openly critical of their technical approach, and have presented prototypes of our disruptive innovation for their consideration.

In November, a month after joining ONC’s Query Health Technical Workgroup (TWG), I introduced our first prototype for Query Health. It consists of a pair of desktop spreadsheet-based programs (apps) that enable a requestor (the entity who wants certain patient data from providers’ EHRs) to create an SQL database query (a specialized language for updating, deleting, and requesting information from databases). This disruptive innovation is then able send that query, via a Direct Project e-mail attachment, to recipients who use a corresponding app behind their firewall to extract the data the requestor wants (i.e., the data “payload”) from the EHR (i.e., the “source database”). The recipients then send the payload, via Direct Project e-mail, back to the requestor. Although the prototype works, it was rejected by TWG members because it required that the requestor app know the schema (i.e., structure) of the source database before the SQL query could be run.

To address that issue, we began working on a second prototype a few months later, which was completed in March 2012. This new prototype is very different from the first because it uses Excel PowerPivot software to consume standardized CCR/CCD XML files (CCR defined, CCD defined that are generated by EHRs. This disruptive technology then calculates the results. In a typical query, these results consist of a few numbers (which could be a challenge to compute):
  • The denominator indicating the target population, i.e., the total number of patients in the EHR database meeting certain criteria (e.g., patients in a certain age range with a diabetes diagnosis, who take medication for it, and have been hospitalized in at least one time in an acute inpatient hospital or ED within a certain time period OR had at least two outpatient or non-acute inpatient encounters during that time period)
  • The numerator indicating the number of patients in the target population for whom a specific event occurred during a certain period of time (e.g., having an hemoglobin A1c lab result greater than 9 percent)
  • And possibly exemptions and exclusions indicating the number of patients in the target population that have not been included due to certain predefined reasons.

Our solution performs the query, calculates the numbers, and is able to return the results to the requestor via Direct e-mail.

We wrote about our prototypes on the Query Health wiki at this link and included videos and links to downloads.

During a subsequent TWG meeting, I then requested permission to present our second prototype to the group. Despite being the only implementation that actually works, I was not allowed to inform others about it because we did not comply with the Query Health approach (standards and specifications).  

The TWG leaders would not change their approach even though, months earlier:
  • We posted to the group’s wiki a page detailing the changes to their approach we require in order to qualify as a viable Query Health solution and
  • I objected to the approach during the consensus voting then dropped my objection after being convinced via an offline conversation with group leaders that the approach is flexible enough to allow novel “overlay” implementations.
Frustrated, I decided to keep quiet and wait to see what would happen as the TWG stayed on its original course. And wow, a lot did happen … mostly in the form of ever-increasing increasing complexity!

Without diving deep into the technical details, here’s the situation today: Not a single query has been done by the TWG using their current approach, nor will any be done in the foreseeable future. A half year ago, however, our successful disruptive solution completed one of the most demanding queries—the NQF 0059 clinical quality measure for diabetes control—yet it remains forbidden to be seen or discussed by the TWG!  

So, what has the workgroup been doing all this time?

Well, several TWG members have been working for months to develop three complex XML translators. As best as I can understand, these translators are required by two web-based tools—i2B2 and hQuery—that have been developed with Federal monies and that have relationships with certain TWG members. The decision to use these tools, along with the PopMedNet Portal for data transport (also developed with gov’t grants), was made at a face-to-face meeting in Washington DC in Nov 2011 (I did not attend; I was informed of their decision via a private follow-up phone call). These tools are supposed to work in conjunction with the translators to change various forms of XML code into other forms of (XML) code.

The first translator is called the “intermediate translator.” It was conceived because the Health Quality Measures Format (HQMF) XML code was just too complex to be transformed into procedural code (like SQL) for executing a query. This translator is supposed to reduce the complexity of HQMF XML; they’re still working on it. The second translator is supposed to transform the XML from the first translator into the procedural code; I do not believe much has been done with this yet. And the third is supposed to translate the query payload into Quality Reporting Document Architecture (QRDA) XML code; still waiting for its construction. And all of this is supposed to conform to the Health Level Seven (HL7) Clinical Document Architecture Release 2.0 (CDA). Oh, forgot to mention one more thing, also needed is a “Query Envelope” to facilitate the secure exchange of queries and results.

Now that’s what I call COMPLEX!

A few other things to consider:
  • It appears that the organization responding to a Query Health request must do all sorts of complex mapping before the query can be run.
  • I'm not yet convinced that, if & when all this work is done, the current TWG approach will be successful since there are still difficult mathematical computations that must be done to complete the Query Health process.
  • Several people in the workgroup, including myself, gave a NO vote to the HQMF consensus round 1 and here’s a link to my critique of HQMF XML, which explains why XML is not right data model for Query Health.
  • The TWG is not focusing on using Direct Project protocols for transmitting queries and results.
  • There are several Query Health pilot projects underway, even though the primary tools necessary for a compliant implementation have not yet been developed.
I suppose all this convoluted complexity is just how the current system works? It certainly isn’t the path to profound healthcare transformation, a strategy I discussed five years ago.  

I contend that disruptive innovation is required to bring about meaningful change!

Our disruptive Query Health solution has NONE of the complexities I discussed above, and it works! To implement our approach, all that’s needed on the requestor and responder ends is a desktop or laptop computer loaded with MS Excel and the free Excel PowerPivot add-in. To make our solution Direct Project compliant, just add MS Outlook that operates in conjunction with our partner HISP. Best of all, IT WORKS!

Addendum: Here's an article from 4/22/13 that confirms what I said above.

My next post (within a few weeks), will examine a disruptive innovation business strategy we’re about implement that is consistent with our vision of how to reform healthcare sensibly and sustainably

Monday, August 06, 2012

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

In my previous posts (see this link for the first post in this series), I discussed the nature of a disruptive innovation, as well as my joy — and grief — with the ONC’s Direct Project and (S&I) Framework programs. On the one hand, I’ve been pleased and encouraged by increased government transparency and (at least verbal) support of true health IT (HIT) innovation. On the other hand, I've been disheartened by troubling issues involving decision-making, ballooning complexity, closed social networks, and restraint of trade attempts, as well as frustrated by efforts to dismiss disruptive innovation.

I presented an example of one such troubling issue, which I experienced firsthand, in my previous post. It relates to the Direct Project’s rules and regulations (called “specifications and standards”) that enable groups of vendor HISPs (health internet service providers) to knowingly engage in practices that are anti-competitive (restraint of trade), innovation inhibiting, and undermine the purpose of the Direct Project whose goal is to enable everyone to use simple and secure HIT that’s better than using a FAX machine (see this link). Although the HISPs' business strategy runs counter to the Direct Project’s goal, their tactics are being condoned by government officials. The reason: The HISPs are not breaking the rules, even though those same HISPs helped create those rules! So, instead of fixing broken rules, our leaders turn a blind eye and say that what they’re doing is OK. Well, it’s NOT OK!

Note that my views are from the vantage point of a small business whose efforts to gain acceptance for a disruptive technology has been repeatedly frustrated despite the fact that (a) literally everyone who sees our HIT in action is amazed by our capabilities and ingenuity, and (b) no one disputes our claim that we offer a viable solution to many daunting challenges facing meaningful healthcare reform.

When we became involved with ONC--volunteering our time and knowledge--we hoped that our gov’t would be delighted with our novel HIT because it is what they said they wanted, i.e., simple, secure, inexpensive, efficient, and convenient solutions for sharing patient information. We soon began to realize, however, that powerful influences in the private sector, which include corporations with gov’t ties, had different ideas. In an attempt to control the marketplace, they appear to deploy a strategy aimed at establishing HIT specifications and standards that (a) foster complexity and inefficiency resulting in costly, difficult to build products and (b) allow business agreements that block competition.

For example, we have faced resistance from HISPs since our novel peer-to-peer messaging architecture is the only Direct Project implementation that: (a) securely exchanges e-mail and attachments having end-to-end encryption (i.e., data are protected in transit and where stored) and (b) enables individuals to share individuals (not just organizations), thereby ensuring that everyone involved in healthcare, including patients, are all using compliant software…[that sends messages addressed to] the individual-for-no-other-eyes [as per this link and being discussed at this link].

In addition, Direct Project standards fail to duly consider disruptive HIT. For example, we are the only vendor (to my knowledge) using desktop tools (MS Outlook and Excel) that provide certain capabilities the standards assume HISPs would provide via web-based services in the cloud. From our vantage point, these standards do nothing but add incredible complexity to our straightforward approach (examples of this added complexity is doing DNS certificate lookup instead of LDAP only and doing XD* transformations). Since we are forced to comply with those standards, we had to team up with a new type of HISP that allows us to continue using our elegant approach and avoid much of the imposed technical complexity we don't want nor need.

In retrospect, we’re not surprised that the Direct Project has been resistant to our disruptive technology and unaccommodating to our needs. After all, that’s what to expect when disruptive innovations are introduced to mainstream markets. This conclusion is supported by Keith W. Boone in a recent post to his blog; Keith is a self-described “standards geek” for GE Healthcare and a long-time participant in gov’t initiatives, including the ones mentioned above. Here’s what he wrote:



A healthy IT marketplace would favor disruptive innovations (simple products and services that initially serve the bottom of a market and then move up to displace established competitors) for improving patient engagement, communication, and care coordination. Improved population health obtained at a lower cost would result … When disruptive innovators attempt to commercialize their innovations within the established value network in the industry — essential trying to cram it in the back plane of the competition … — that system will either reject it ... or co-opt the potential disruption, forcing it to conform to the existing value network in order to survive. The idea that disruptive innovations can fit into the current healthcare value network … ignores this key point … The real challenge is not providing disruptive technology in Health IT, but rather, in providing a new value network in health care that will enable disruptive innovation. When that happens, the new value networks will have the necessary technology to support it, and indeed, the current EHR industry will either adapt, or die.
So, can disruptive innovations be integrated into the value network of the current healthcare market? Well, if our country had created a rational healthcare value network, then good disruptive technologies would be welcomed with open arms.

But with our current healthcare system, this is obviously not the case. Instead, disruptive innovations must create new, more sensible value networks and markets that focus on transforming the system in ways that benefit the patient, reward the provider for delivering high-value care, reduce complexity, increase security, and save money. And that's what we are focused on doing.

In my next post, I’ll present my mind-boggling experience with the ONC Query Health initiative.

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




Wednesday, August 01, 2012

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

In my previous post, I defined what disruptive innovation is and why it's important to healthcare transformation. I will now discuss my experiences over the past year with attempting to introduce a disruptive health IT innovation to the Federal  Government.

I was delighted when I first found out that the Obama Administration was making good on its promise to increase transparency into the inner working of our gov't by opening to the pulic several programs administered by the National Coordinator of Health IT (ONC). ONC was looking for volunteers to join workgroups aimed at developing rules and regulations for the exchange and use of protected health information (PHI). Input from innovators was encourged time and time again as evidenced by the Fed's Care Innovation Summits, Meaningful Use and Health Care Innovations ConferenceDigital Government Strategy, "open government" initiative to drive rapid innovation, and more. Government transparency and support for true innovation aimed at improving patient care. WOW...Love it!!!

I found out about two such programs last year and jumped in with both feet. One is the Direct Project, which is focused on using secure e-mail to exchange PHI. The other is the Standards & Interoperability (
S&I) Framework, which is focused on "enabling harmonized interoperability specifications to support national health outcomes and healthcare priorities, including Meaningful Use and the ongoing efforts to create better care, better population health and cost reduction through delivery improvements." Each of these programs has various communities of volunteers who collaborated in many different workgroups and sub-workgroups. They establish use cases, standards, specifications, and reference implementations based on the specification; they also run pilot studies. I personally spent most of my time focused on sharing my knowledge, skills and novel technology with the Direct Project and the S&I Framework's Query Health Technical workgroup.

Although I've met some fine people during these meetings and gained useful knowledge, I've been frustrated by the programs' decision-making process, ever-growing complexity, closed social networks, and fear of disruptive innovation. The following situation exemplifies some of my concerns.

An article in InformationWeek last month, titled “ONC Releases Guidelines for Direct Clinical Messaging,” discussed some state-contracted health information service providers (HISPs) make secret deals to create and control data silos in an attempt to block competition within the Direct Project. These tactics not only stifle innovation and choice, but they also defeat the purpose of the program.

To me, the most troubling thing is that these anti-competitive (restraint of trade) and innovation-busting practices have been condoned by gov’t officials! Let me explain …

According to the article (bold added for impact):



ONC has issued guidelines for the more than 40 statewide health information exchanges (HIEs) that have launched or are starting services that use the Direct Project secure messaging protocol.
The guidelines are designed to ensure that state-contracted health information service providers (HISPs)--private companies that route Direct messages between providers or between providers and patients--allow information to flow within and across states. The ONC document also spells out how HISPs should comply with the Direct protocol and accompanying policies for trusted, secure data exchange.
[However, no rules exist] for sending messages [between people using]…different HISPs…some HISPs have [thus] started making one-on-one agreements with other HISPs to exchange Direct messages [even though] ONC says that ‘such peer-to-peer legal agreements are expensive and time-consuming to implement and are cumbersome to monitor and enforce. They are not a long-term basis for scalable trust.’
…[Nevertheless, some] HISPs will continue to make side agreements with one another—and [Erica] Galvez [community of practice director in ONC's state HIE programs] sees nothing wrong with that. If the HISPs comply with guidelines and the applicability statement, and consider themselves business associates…they certainly could enter into one-off agreements. If they do, I'd hope that they'd use these guidelines as the basis for that so they have a consistent, level playing field across HISPs.’
The ultimate goal of Direct, according to Galvez, is to provide a national standard for clinical messaging so that providers can easily push messages and attachments to each other and to patients. To the extent that HISPs create their own information silos, she noted, they defeat the purpose of the program.
In addition, a blog post by John Moehrke at this link quotes an ONC release sent to the HIE grantees:
ONC has found that many...HISPs...are deploying Direct in a way that proactively enables exchange within a given HISP’s boundaries while not offering mechanisms or supporting policies that enable exchange with other HISPs. Such limitations effectively block providers using different HISPs from exchanging patient information. In effect, HISPs are creating 'islands of automation using a common standard.'  
John then goes on to say that the release states that HISPs "should" do things differently, but criticizes ONC for failing to state that they "must" change their ways.

This whole thing bothers me! Here are my questions/issues:

WHY is it OK for HISPs to defeat the purpose/goal of the Direct Project, regardless of whether they "...comply with guidelines and the applicability statement, and consider themselves business associates"?

Shouldn't the guidelines and statements be changed to assure the purpose of Direct is upheld in light of this troubling issue?

More in my next post.

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.

Tuesday, June 26, 2012

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.