Wes Rishel

This is a reply to Shane Taylor’s interesting comment on my Simple Healthcare Interop for Easy Applications post. I am using his comment as an opportunity to flog some important notions.

Notion 1: You Can’t Step on Someone’s Toes with a Thoughtful Blog Comment

Shane expressed a concern that his reply might be considered inappropriate. Nothing that adds to the discourse is inappropriate.  Gartner has ‘bots to delete autoposting from other ‘bots that are simple product pitches. I might delete a comment that was totally irrelevant or grossly offensive, but vendors are welcome to post descriptions of their products that add to the subject at hand. I assume my readers will look at the quality of the ideas and consider the source when evaluating the evidence that supports the ideas.

Notion 2: The Fax is the Standard to Beat

Strengths: If we are going to ever get beyond the fax we have to first recognize the full value it adds.

• The fax can communicate complex information in human readable format. Text and diagrams, and handwritten notes are all handled well.
• It is a ubiquitous capability that can be added to an office for less than $25/mo. The technology is used for many purposes so the allocated cost for clinical information sharing is close to nothing.
• It involves only two parties the sender and the receiver.
• There are no complications associated with verifying the trust relationship between the sender and receiver. That happens off-line.
• The transmission itself is reasonably secure. HIPAA quite reasonably does not impose encryption requirements on information sent over a switchable network.
• There is no time-consuming and difficult to understand overhead to maintain security keys.
• Every fax machine in the world is directly addressable with a simple number containing fewer than 12 digits.
• Fax can easily be integrated into IT systems both for outgoing and incoming messages.
• It works well in mixed modes, where some providers have integrated IT systems and others have no integration or no clinical IT system.

Weaknesses. Since it will be at least a decade before we can match the ubiquity of the fax with any other technology, there must be things that can be fixed that add enough value to justify the complexity of dealing with the Internet. Fortunately there are several.

• Fax communications errors sometimes obscure the documents. The error-recover protocol (call back and have the document sent again) is so heavyweight it is often skipped.
• No-one uses features that would provide end-point authentication. Who hasn’t once or twice received a fax intended for someone else with confidential financial data therein? In any event it is trivially easy to fake the end-point credential of a fax machine.
• The solution for color is not ubiquitous.
• Resolution of photographs is too low for all but the most trivial uses.
• There is no ability to mix structured and human-readable data and pass the structured data directly to an IT system.
• There is no potential to automate patient identity mapping in IT systems. Even when the fax comes into an IT system a person still has to review the document, match it to a patient and determine what to do with it, but it is not necessary to take a piece of paper from the fax machine and run it through a scanner.
• There is no reliable directory service that will get you, say, to the fax machine associated with the gastroenterology clinic of the Lucile Packard Children’s Hospital on the Stanford University campus. The identifier (fax number) also must be established externally.

The approach we are working on depends on fixing enough of these problems to be worth investing in changing things. We aren’t trying to fix them all, because that would raise the cost and implementation time too much.

Notion 3: Direct Patient/Consumer Involvement Is Not the Solution

While I am a big fan of consumer/patient engagement through the Web I am not in favor of entangling that approach with provider-to-provider communications that occur in the routine course of giving care.  Consumer involvement may be the only solution that supports ad hoc lookups of patient data. Communication between providers and consumers is also very important. But if patient facilitation is required for all IT-based communications among providers in the course of treating the patient, fax will continue to be the default technology 10 years from now.

Notion 4: The eBay Model of Trust is Inadequate for Healthcare

Comparisons to the Web megavendors must be made carefully. This is particularly true when you compare the business value and risks involved in sharing information with value and risks of conducting financial transactions. Shane’s characterization of eBay has merit although it could be misleading The primary value that eBay brings to the world is the auction-based marketplace. This is not a value you would expect to provide for healthcare information.

The analogy is good, though, in that the secondary value that eBay adds is trust, at least to the scale of large consumer transactions and the transactions of small businesses. However, the trust model is based on the ability to limit losses to the dollar value of the merchandise exchanged. I can’t imagine a manufacturer of baby food buying ingredients on eBay just using the level of trust that can be conveyed through eBay. They would have to have a separate trust relationship with the ingredient-seller, often-based on sending inspectors to the plant from time to time to review their QA procedures. We need to think carefully about the level of trust that a vendor would need to convey in order to be an eBay-like connector of healthcare organizations that do not have a separate means of establishing trust.

My current approach is different than RHIOs or HIEs in that it doesn’t assume that an intermediary or protocol is adding business trust, only authenticity.

After reading Health 2.0: Take a Lesson From the Web Peter Basch asked me “exactly what a Provider Health Internet looks like – [and what are] the implications of using it vs. a RHIO / NHIN?” The question has special piquancy because users of EHRs will need to show certain kinds of interoperability to meet anticipated meaningful use requirements in 2011. This includes sending patient summaries from one provider to another, as for care transitions; reporting information to registries; and getting structured lab results into EHRs.

In theory, HIEs or RHIOs provide a basis for interoperability among EHRs and between EHRs and other data sources or users. They provide several important functions.

• They create the technical framework to enable Internet-based connectivity
• They create the social capital necessary to create trust among the participants in the HIE
• They operate the governance to maintain the trust
• They operate a service that correlates the IDs of patients even though the various edge systems use different ID numbers.
• Having correlated IDs, HIEs implement a consent model such as opt-in or opt-out giving consumers control over whether their data is searchable. Some offer a more fine-grained consent model.
• Usually they provide the analysis to create mappings between proprietary codes and standard codes such as LOINC; and then provide the software transformation to make the mappings work.
• Usually they provide a means for storing clinical information that is distinct from the IT system that is the actual source of the data. This may be a centralized data base or it may be a fleet of proxy servers, one per data source.
• They provide support to both the operators of the EHRs and the data sources or recipients (such as labs).

By itself the idea of a regional HIE doesn’t cover some very important edge cases including multi-regional entities that don’t want to have individual business or technical relationships with dozens of HIEs, patients who regularly see providers in multiple regions and the statistically rare case of needing to access information about a patient from a distance location.

The NHIN has been the conceptual approach to gluing together HIEs. It includes the notion that multi-regional providers such as Kaiser or the VHA would connect with HIEs as if the provider were another HIE. The architecture includes technical support for an approach to transitive organizational trust and correlating patient identity across HIEs despite the lack of a national patient or consumer ID. The project was called the “Nationwide Health Information Network” rather than the “National Health Information Network” to emphasize that it was intended to support interconnection as opposed to constructing a singuler, national network.

(Begin soapbox rant.)

It is my personal opinion that the NHIN work has been dissed excessively. Its concepts are in use in production now. They are used to connect the Social Security Administration to MedVirginia which is the HIE connecting to many providers. For applicants for disability in those states the connection has reduced the time for determination by more than 20 percent. The substantial policy challenges necessary to connect a government provider (such as the VHA or DoD) to a private provider are nearly solved and some transfer between those agencies and Kaiser is contemplated soon. The NHIN CONNECT Gateway is an open source project that implements the inter-HIE connection protocols. CONNECT has a robust community. The California eHealth Collaborative was used CONNECT to conjoin five HIEs in California for demonstration purposes. This was accomplished in a matter of a few weeks. Three HIEs downloaded the open source software and two modified their own software to follow the putatively undocumented and hard to implement protocols.

(End soapbox rant.)

Criticisms of the current NHIN approach are that the protocols are poorly documented and the complexity of dealing with cross HIE patient identification and security are complex for small vendors and self-developers to implement. Many feel that the protocols are too big a technological bite to push onto industry in a single gulp. In their view this ignores a fundamental discovery of the Internet, that a simple approach that meets a few requirements catches on way more quickly than a complex approach that has looked farther down the path of evolving requirements.

These issues are valid to varying extents, but the larger concern is that establishing the HIEs and building trust with and across HIEs is a time-consuming process. It is still more art than science, and therefore unpredictable. Without ubiquitous HIEs and the trust model the issue of whether the NHIN protocols could be simpler, better or better documented is moot. The fact is there cannot be a enough work done in 2011 to provide ubiquitous support for EHR users meeting meaningful use criteria. In my own opinion the situation could be a lot better by 2015 but ubiquity would still be a much longer reach.

So, at this point the definition of the NHIN is “under reexamination” and there have been rumor of fulfilling its goal with (and presumably diverting NHIN funds for) the “health Internet”. To the extent it has been described the Health Internet has  a strong emphasis on consumer involvement. The health Internet sounds a lot like a PHR or at least the PHRs that are designed to form the basis of an application ecosystem such as the work of Dossia, Google and Microsoft.

The main point of “Health 2.0: Take a Lesson From the Web” was just to point out that PHRs don’t cut it as the sole means for provider-provider communications. I didn’t mean to imply that the “provider Internet” would be a separate entity, just that the proposed “Health Internet” doesn’t meet provider to provider needs.

The real question is this: If the existing NHIN+HIE concept will take too long and if PHRs  or a consumer-based Health Internet are not a reasonable alternative, what’s left?

I and others are hoping that we can isolate some important functions of the HIEs + the NHIN and address the simplest use cases with fairly simple, point-to-point communications over the Internet.

This approach relies on an assumption: that the business trust between organizations that use EHRs and the organizations that receive data from them or send it to them can be addressed without the full formal architecture of transitive organizational trust that complicates the HIE+NHIN approach.

Organizations that exchange data would use the postulated simple Internet mechanism to exchange information with other organizations which they had independently determined to trust. They could send information through the Internet using about the same ground rules they use to fax information now. Instead of typing a fax number into one of those infernal machines they might type a URL into their EHR. The actual transaction would contain structured data to the extent needed and that structure would be standards-based. One way this could work is that the exchanges could occur between healthcare organizations that know each other and have physically exchanged the Internet addresses and digital certificates to support authentication and encryption. Another model might be an Internet service that provides that information on-line.

The next question might be what are the limits of health information exchange based on independently-established trust? There is a substantial difference in the policies that various care delivery organizations apply in deciding when to fax information about a patient to someone that calls and claims to be an entity with a legitimate reason to request information about a patient, or when someone faxes a putatively signed consent form. What is different about sending the information by a secure Internet connection rather than the fax?

One clear difference would be if the request for information came in directly to the IT system of a healthcare provider and the response went out automatically. Indeed, supporting “query-response” interactions has significantly upped the need for explicit trust models in and among HIEs. A first cut at how to approach simplified information exchange is to take automated query-response out of the picture. This limited model, which could go along way towards meeting meaningful user requirements for interoperability could be just for pushing information.

There is some work to do to see if this notion is useful and doable at a scale that is appropriate to help with meaningful use.

I am trying to give these ideas a voice in the blogosphere, but the ideas are not exclusively  my own The notion has been bubbling in many pots over the summer and many folks are discussing variations of it. I am particularly grateful to David McCallie of Cerner and Virginia Riehl, an independent consultant with whom I have enjoyed many hours developing these thoughts.

It is likely not a coincidence that David and I independently posted thoughts on the NHIN last night. The ONC has the HIT Policy Committee looking into it and this is generating interest the HIT blogging circles. His post is The Health Internet vs. the NHIN — A Matter of Control, Cost, and Timing and mine is Health 2.0: Take a Lesson From the Web. Subsequently I responded to his and he replied. These are copied at the end of this post. In it he asks whether I agree with him on some points.

First and foremost I believe that when we talk about the “Health Internet” there are two equally important problems to solve:

1. consumer-controlled accumulating and consumer-directed use of health records, and
2. inter-clinician exchange of health records in the course of caring for or managing the care of a patient.

I don’t believe that what has been written about the Health Internet describes a solution that deals with both cases. On the first point, above, I think David and I are in the same ballpark. The model of a PHR proffered by Dossia, Google and Microsoft has many of the fundamentals that are required: a clearly stated privacy model that can serve as the basis for informed decisions whether or not to use the service, access to consumers that is cheaper than Quicken on-line (i.e., free so far), a proactive consumer role in setting and changing consent for various kinds of information exchange, a way of verifying the consent on both sides (the consumer has to be logged into the web sites of both the PHR and the system that sends or receives data) and a rock-solid patient ID mapping (the mapping is created when the patient is logged in).  I would argue that the use of “cloud storage” and good offices of the vendors to facilitate connecting to the PHRs is a valuable and highly desirable.

I have not been able to understand David’s view on point #2. One could read his stuff to say that the Health Internet is all the industry needs. Given the growing presence of the Internet patient-mediated transfers should also be used to get lab results to the ordering physician, ED notes back to the primary care provider, to find out whether a patient presenting at the ED with chest pain has had a recent angiogram and get the results if so and so on through any number of care transitions that we handle very badly now in the health care industry.

There are problems with patient-mediated transfers of information in the course of giving care. Many patients who are fully deft at doing business on the Internet will forget or slow down the process. Some are simply unable to actively mediate information flows. A few patients will knowingly disrupt the flow of information. For example, they may delete reports that suggest that they don’t need high-end analgesics.  Anorexics, who already get more help on the Internet on maintaining their disease then they do on curing it, will also manipulate the information flow. Although these patients may be a minority, the potential for this manipulation will impact the credibility that physicians place on information received through patient-mediated sources.

Labs and other diagnostic facilities have legal and ethical obligations to ascertain that the information has gone to the ordering physician or one designated to receive copies. Information lost in transitions from hospitals to SNFs are a known source of death, and greatly reduced quality of life. I believe that solving the provider-to-provider problem for routine care delivery scenarios is every bit as important as patient engagement, particularly if one expects or hopes to maintain independent physicians as a viable participant in the US healthcare system.

Where we might agree is that the current conception of HIEs joined together in the NHIN has, at best, a very long lead time to create nonpatient-mediated exchange of healthcare information.  It is not that some HIEs haven’t done well or the current NHIN approach can’t link them to one-another and to multi-regional providers. However, it is not clear that this approach can be built out in a reasonable amount of time even with mid-course corrections on the goals and standards in use.

There is an alternative to HIEs and the NHIN we should consider during this period of reexamination of the approach. It might be called The Health Internet for Providers. I don’t see why we can’t be sending information about patients with the same facility that one sends an email. This approach has several advantages

• The consent model can be essentially the same as the consent model that is used to send faxes today.
• Unlike faxes the package that is equivalent to an email can have a variable amount of structured data. In particular
  • enough data to give the receive an easy shot at matching the patient with their data base
  • data about who sent the info and what is the subject
  • more structured data as appropriate to agreements between the sender and receiver. Presumably various incentive programs can improve the amount of structured data over time but the fundamental exchange mechnaism would not be broken.
• It should be straightforward to include in the approach irrefutability of transmission and receipt.

David McCallie has been talking this idea up with me and others and has come to a bright line to identify when a transaction should flow over the “provider health Internet” and when it should flow over the “consumer health Internet,” (i.e., be patient-mediated). If the transfer is one that would be expected now (by fax, letter, CD or whatever) then it should not need patient-mediation to be accomplished. If such transactions are sent electronically now they are usually “pushed.” Any kind of ad hoc searching of patient information (including looking up a critical patient in the ED) should be patient mediated. Perhaps there should be a “break the glass” capability for when the patient is incapacitated and there is no one else to give consent; that’s a fine point.

So I conclude that maybe David K and I agree on some things. At least with his peanut butter and my chocolate we would have a complete candy bar.

What follows is the dialogue from earlier on Wednesday.

Wes:

The statement that the NHIN was “created so that large systems like the VA and the DOD, Kaiser and Geisinger, can exchange data without having to reach the Internet” is blatantly untrue and contrary to everything that the ONC ever published about the NHIN. The NHIN was in fact built to run on the Internet.

Recently five small HIEs (RHIOs) working under the auspices of the California eHealth Collaborative created the ability to share patient data among them over the Internet in a matter of weeks using the NHIN protocols and the open-source code that was created as part of the last NHIN project. The small HIEs which have substantial support for physicians in small practices co-demonstrated with Kaiser. Far from the NHIN being designed to let the big providers ice out small providers it was designed to enable their interaction. In many ways this was a David v. Goliath use of open source software and the NHIN protocols as this the CAeHC is striving to position itself as an alternative to CalRHIO.

There is plenty of room to simplify the NHIN work so far. But we should not conflate the need for healthcare organizations to interact with the very important need for PHRs.

I address this in my recent blog posting “Health 2.0: Take a Lesson From the Web” (http://blogs.gartner.com/wes_rishel/2009/11/18/health-2-0-take-a-lesson-from-the-web/).

David:

Dear Wes: Thanks for your comments, and I stand corrected. In the future I’ll defer to your excellent blog post for a description of NHIN and CONNECT. I also think that the eHealth Collaborative patient data sharing project you refer to is real and substantial progress, and I’m glad that we agree on the point about simplifying NHIN and the protocols involved, so that health care organizations of all sizes can interact with one another and with PHRs.

However, the example of five RHIOs taking “weeks” to “create the ability” to share data, amongst themselves, is exactly the kind of enterprise and provider/organization control of data that Brian and I along with many others consider to be an insufficient solution, one that well describes the old idea of NHIN, but does not describe the new model Health Internet.

Perhaps we agree on this, too. That would be great.

But I want to emphasize that in my opinion patient-centered health data exchange should not require a RHIO or HIE or a formal NHIN. These constructs may be very useful in some ways in some communities, but they are not the same thing as what David McAllie described above, namely a means of exchange over the Internet by which “(T)he data will be available to them (patients/consumers) regardless of where they live or travel. The data will be exposed to services selected by the consumer via standards-based, simple, Internet-friendly (RESTful) protocols, and not via some overly complex service-oriented architecture that presupposes all of the use-cases.”

Believe it or not, this is about the Nationwide Health Information Network (NHIN) and maybe the Health Internet, whatever that turns out to be. But I’ll get back to that.

As discussed in Healthcare 2.0: Better Tweetment? I am on a mission to find concrete value propositions for Health 2.0. By this I mean not the “Wiffle Bat of hope” statements like “the Web changes everything” but the Louisville Slugger statements such as “modified primary care delivery models for self-pay professionals” or “Twittering from the operating room as a marketing tool.” Do I think that the hits that I identify will be the be the game changers? Of course not. Any day, in any park, the home runs may come from any batter.  But if we swing at every pitch, the odds of getting on base go down.

Let’s look at a home run from the Web. Did the Web revolutionize selling airline tickets? Well, for simple round trips and tours to major destinations it surely did. It is a simpler technology than the old one (calling a travel agent), more accessible and disintermediates some of the special knowledge of that agent. For complex itineraries, not so much. My company continues to use a major travel agency, that offers us its own version of Orbitz and offers real live people for the tricky bits.

What’s more, the Web experience didn’t revolutionize the entire travel industry. A great deal of the company to company and company to agency interchange is still enabled by computer-to-computer linkages among business application programs. Granted, the Internet helped with software compatibility but this was less the magic of new ways of dealing with consumers and more industry taking advantage of technologies originally driven by the consumer market.

Put it another way: woe be upon those who fail to aggressively improve their customer relationship through Web 2.0, but even more woe be on to those that think that they will sell boxcar lots of chemicals, oil drilling derricks or electronic subassemblies solely through consumer-friendly Web sites. More complex computer-to-computer interfaces are needed with a higher level of semantic interoperability than can be achieved by a person who is reading information from a screen and typing. Both accuracy and efficiency argue for getting people out of the loop.

We have the same issue with healthcare. We need to service both consumer engagement issues and the industrial-strength connections among healthcare providers, providers and other care delivery organizations. Better consumer engagement can profoundly impact people’s decisions on health maintenance and healthcare options, but the profound impacts depend on more than a social network and a snazzy Web experience. They depend on a long process of learning what actually changes behavior. To think otherwise is to ignore that the public had all the knowledge it needed to quit smoking thirty years ago.

We also need to connect the “industrial” healthcare organizations to those organizations and the agencies that are working to create transparency in quality and cost. Why, because we can avoid killing people in care transition. Every unnecessary death is precious, but talking only about deaths hides an equally important threat. By doing care transitions poorly and using 3 people to bill for every person who provides care we are denying care to many through the rationing that comes by limiting private and government coverage.

This is where the NHIN comes in. In the past it and health information exchanges (HIEs) have been focused on the “industrial” side, that is inter-HCO communications used in the course of giving care. We’ve had our share of Wiffle Bats in HIEs, but the 57 operational HIEs (according to eHI) and a number of self-sustaining HIEs show that it is possible to improve care transitions and even the gathering of quality data. The customer-facing channel (consumer engagement) was previously seen as the province of CDOs and PHRs. HIEs could be an enabler of interchange with the PHR but they were primarily about improving on the fax for gritty, back-room exchange of data.

The NHIN was seen to round off the edges of the HIE concept. It was to cover people who moved, overlapping catchment areas, and the providers and CDOs that operated where a local HIE was unlikely to occur and major organizations like the Veteran’s Health Administration and Kaiser that could not spare the resources to negotiate business and technology agreements with dozens or up to a hundred individual HIEs.

The NHIN also provided a work-around for the basic bug in U.S. healthcare IT: the lack of a singe person identifier.

Currently the NHIN work is on hold for a reevaluation of its direction and proposals abound for a Health Internet. Since the NHIN was designed to work over the Internet, what is different about the Health Internet? Apparently it is more consumer facing.

Consumer facing is good. It will achieve a measure of smarter use of healthcare and perhaps even smarter lifestyle choices. Reevaluation is good. There are plenty of opportunities to simplify the execution of the mission of the NHIN.

What would be bad would be to conflate the consumer-facing aspects of Web 2.0 and the “industrial” interchanges into a single solution that limited the “industrial interactions” to apply to those consumers that have proactively enabled it. We need to recognize that something akin to the HIPAA consent model is needed for some forms of information interchange.

We need to take the full lesson from the Web. It revolutionized consumer-facing business but is only a part of the solution for large-scale inter-business collaboration. We need to keep this distinction in mind during a reexamination of the NHIN. There is plenty of room to find a way to meet the NHIN mission better. The consumer-facing Web changes a lot in very important ways, but if we don’t recognize the rest of what healthcare needs we will face the possibility of reaching the year 2015 with the fax machine still being the primary interoperability technology among physicians and CDOs.

In A Singular Opportunity for Health Interoperability I summarized a metaphor based on the Web standards HTTP and HTML which was “get HL7 and other SDOs out of the HTTP business.”

Metaphors gain their power from poetic ambiguity. One of the great things about a metaphor is that it can rally so many folks to believe they agree. They each read the metaphor as supporting their favorite point. The follow-on to a metaphoric rally must be a drill-down to tease out where the metaphor singles out an important common cause and where it papers over differences.  Using a RESTful approach to interoperability is another metaphor. Some of the discussants take it quite literally as the single most important point to agree on; others see RESTful as an example of a broad approach to rapid innovation.

Over the last few days I have come to believe the following “big takes” on this discussion. In another simplification I break the discussants into two groups,  “the Internet crowd” and “the healthcare informatics crowd.” I mean no disrespect to either group and understand that many people have a foot in both camps or at least a foot in one and a toe in the other.

There are implicitly three levels of contention. I will arbitrarily assign them to a vertical stack.

Bottom: Connecting (in the broadest sense). So much has been accomplished with well-layered Internet protocols to create quite complex behaviors and progress has progressed so rapidly that “the Internet crowd” can’t understand why “the healthcare IT crowd” wants to stick to technologies for secure transport that are “so five years ago” but preclude participating in rapid evolution. “RESTful operations” are a token of the deeper conflict, not the actual point of contention. Some of the informatics crowd significantly confuses the issue by presenting discussions on security based on standardized roles and other as yet unproven constructs.

Top: Semantics of Data. Understanding data clearly is a never-ending task. As Bertrand Russell said “Everything is vague to a degree you do not realize till you have tried to make it precise.” The Internet crowd has done very well with a model where semantics evolve as rapidly with experience. They have productivity tools that rely on some unstated but “common sense” approaches such as using business names as XML element names. The health IT crowd has been through this learning curve on clinical data and wants to skip over many learning steps that uncover ambiguities on health data. However the health IT crowd (including HL7) has made it more difficult to propagate its knowledge about health data because they have chosen to package it in self-created modeling formalisms and XML that is obscure to the max and doesn’t work well with common XML tools. They further complicate the issue by not knowing how to package their sophisticated understanding in a way that it can be understood by programmers who know the data of their own application but don’t comprehend the abstract approach.

Middle: The Semantics of Exchange Sequences. To a certain extent saying something is “architecturally neutral” means “it isn’t interoperable in any architecture.”Any attempt to truly achieve interoperability involves a state machine that implies certain sequences of transactions needed to get the job done.

The Internet crowd is used to improvising the sequences of actions that are required to accomplish a task but not standardizing them. The health IT crowd has attempted to establish very loose architectures (i.e., no technology or system factoring constraints) that standardize the sequences enough that two products that are expected to be interoperable could interoperate without continually adjusting the code based on what is going on in the broader community. Thus the Healthcare IT has fought its way to largely agreeing on XDS over a five year period (and XDS has evolved in that period) and the Internet crowd sees XDS as not applicable to their use cases and restricting their ability to improvise.

The Internet crowd represents a culture that employs the power of the Internet protocols in an enterprising, high-energy, innovative and incremental approach that has revolutionized some industries. The informatics crowd really does have the ability to shortcut many learning cycles based on experience and understanding. How can we introduce combine the peanut butter with the chocolate? Oops! There goes anothe r metaphor.

Sean Nolan of Microsoft just published a finding from the HIT Standards Committee testimony on implementation last Thursday. See his blog item  Hey — was that just an HIT Standards breakthrough? I summarized and perhaps oversimplified an analogy that had built up during multiple conversations by saying healthcare SDOs should “get out of the HTTP business.” The analogy developed from a conversation on the benefits of the Internet suite of protocols by having cleanly separated layers and, in particular, separating specifications on data (such as HTML) from specifications on the communication protocol (such as HTTP, HTTPS, etc.)

A number of healthcare standards and standards-profiling groups have published not only format standards, but also communications standards. Some do not. One of the reasons that HIPAA transactions were largely a failure is that the regulations included no approved method for communicating X12 transactions. Providers must conform to many dozens of different various specifications for the physical transport of data in order to get their bills paid. Alternatively they can pay a substantial click fee to clearinghouses to cater to the communications-spec whims of the payers.

I did not at all mean to suggest that the ONC in its role guiding the implementation of the ARRA should allow the same thing to happen again.

The HTTP Side

To a certain extent the specifications that are most disputed now relate not directly to HL7 standards but to specifications created by Integrating the Healthcare Enterprise (IHE) and adopted by the Health IT Standards Panel. Those poor fellas at IHE started working on an approach to cross-enterprise data sharing in about 2004 and believed IBM and Microsoft that Web Services would be the way to achieve secure, reliable, technology-neutral inter-enterprise interoperability. At the same time they adopted ebXML as a then-proven approach for store-end-forward messaging.  IHE members dumped a ton of sweat into puzzling through the specs, developing selective profiles of them that might actually interoperate, conducting repeated multi-may inter-vendor testing sessions and honing their specifications. Now that they made this investment they are naturally reluctant to give it up. There are actually live implementations now using these protocols, we learned last week.

Oh how times change! During the five years that have passed new entrants such as Google and Amazon have joined the ranks of market-dominating vendors, serious concerns have developed about the complexity of Web services and everybody’s favorite new approach is RESTful Web services‎. This approach is, indeed, simple and layers well. There is a lot of real-world use of RESTful Web services. Security is very simply provided by using the security associated with HTTPS.  Other requirements important to healthcare, such as non-refutability transmission and receipt, can be handled equally well. Probably many of the big firms already are.

In fact, I would venture that each of Amazon, Google, Microsoft and other dominant players each have one or more specs built around the concept of RESTful Web services each of which is simple, particularly because it was catered to the needs of their specific applications. Like providers sending in HIPAA bills, software developers have to develop interfaces that are generally the same but differ in enough specifics that they either align with one vendor or re-develop their interfaces for each.

Is that the best we can do for healthcare interoperability? Somehow I had hoped for more. I don’t really care about RESTful Web services or the other kind. I do care that N x M interoperability work for medium sizes of N and M. For example, if a vendor or care delivery organization (CDO) is developing a clinical solution that needs to interoperate with some other HCOs, labs, multiple PHRs, public health and quality measurement agencies, I would like to believe that they could do so, without getting into a “my business is bigger than yours ” contest. It is clearly not the case that every CDO needs to talk to every other CDO. More and more they will outsource the communications to their vendors, a trend that is underway. So, would each vendor have to be a clearinghouse? Would a new vendor coming into the market face a daunting challenge because it needs to develop a body of intellectual property to communicate with all the labs, PHRs, payers, health agencies and quality measurement organizations, each of which uses a different approach to RESTful Web Services?

Let’s suppose that all the various supporting specs needed for healthcare interoperation already exist in one or the other of the big vendors’ use of RESTful Web services. Is there really a standard for all that that is standard as, say HTTPS or HTML? If so, great let’s go full time ahead. If there is no standard but a lot of good experience, can we somehow put together a tiger team that looks at what’s in use and agrees on a common approach? Such a team would have to follow much of the advice we heard at the HIT SC testimony last week including:

• focus solely on the most immediate needs for fulfilling meaningful use requirements
• focus on reusing what is widely being done across many industries
• spec a little, implement a little, test a little, spec some more until you reach a stopping point
• create open source specs and code that has been tested for interoperability.

The “HTML Side”

There is also work that needs to be done on the side that is the equivalent of HTML in our metaphor. This side includes the specs that represent the payloads communicated through HTTPS for healthcare interoperability. Perhaps the most critical thing is to revisit the specifications to see whether they intermix information needed for the communications with information needed for business processing of the payload. This is a tricky business, because there is overlap. I don’t really know how much IHE and HITSP have already done to create the correct separation. Perhaps it is already done. But if not, could a “tiger team” on the payload side work closely with the communication side to sort out these issues and provide an urgent interface back to the standards bodies if any changes are needed?

Can We Create the Trust to Get This Done?

Like Sean, I see this as an opportunity to get the U.S. healthcare industry to make a leap forward on interoperability that could meet the challenge of the ARRA meaningful use criteria.

For something to come of this, various parties will have to trust a small team to do the work without the formal governance of an SDO. Developers will have to be prepared to accept solutions that require changes to their software. SDOs will have to accept the challenge to change their standards to catch up with the work of the tiger team.

The biggest problem will be antibodies created by the bile and spittle of numerous commenters in this area. Every time an advocate for a more RESTful approach refers to Electronic Health Record Association and IHE as being a cartel working to restrain trade it becomes that much harder to bring the mainstream EHR vendorsto the table. On the other side, HITSP, IHE and others need to do a better job of understanding the advantages of totally separating the two layers and be willing to give some in order to bring in the Health 2.0 crowd.

If this is going to work, all parties are going to have to accept that we need some change and we have a singular opportunity to accomplish it. They are going to have to accept that the parties they disagree with won’t go away. They must refute even their supporters who continue to play the name-calling game.

In the words of comedian Judy Tenuta, “Hey! It could happen!”

This posting was revised on 1 November based on thoughtful feedback from several people.

I just Googled “‘Health Internet’ Aneesh” and found 723 responses. I wonder what the over/under is for 2000 by the end of the month?

Given that the statements from Chopra and Todd Parks have been fairly general, they are treated like ink blots. Each blogger interprets them to find what he loves or hates and writes a brief essay on that. My particular essay will be that I love it and to list the issues that I hope it solves.

In healthcare we have four basic interoperability challenges.

1. Reduce the friction of personal health information flow between the providers in the course of care transitions and between providers and other stakeholders for aggregate management of care.
2. Reduce and increase the friction of personal information flow among healthcare providers, consumers, and a broad class of stakeholders such as patient advocates, providers of special services. We need to reduce the technical barriers to sharing information with consumers and create a positive incentive to do so. At the same time we need to provide consumers with substantial reason to trust that their intentions to limit information sharing are not betrayed. As they trust their control of this health information the increasingly become a force compelling healthcare providers to provide information. In effect the consumers are both the agents of (good) friction and the lubricant.
3. Enable rapid technology innovation without requiring it. Computers are actually doing a lot of good in healthcare now and the challenge that innovators face must include “changing the tires on the moving car,” a sentiment that has often been expressed as “no rip and replace.” This matters particularly when working on the first challenge.
4. Avoid “innovation dead ends” such as the fax machine. It was not so many years ago that the pre-fax epitome of healthcare interoperability was pieces of paper sent through the U.S. Mail. In that context the fax was a wildly disruptive piece of innovation. It needed no new infrastructure outside of an extra phone line, had fewer security vulnerabilities than the mail, was fully upgradeable from paper (as long as you didn’t use color and accepted blotches and pixelation), and no standards were required that hadn’t already been hashed out by the telecomm industry. It was the very strength of the fax machine that has limited our ability to replace it. The comparable challenge in today’s interoperability world do establish standards that are easy enough to enable rapid grown and don’t freeze progress just one step forward.

Some will ask if there is truly a difference between the first two challenges or whether meeting the second challenge wouldn’t also take care of the first. I hope to address that more in a future blog and to present ideas on how we can meet all four of these challenges.

I am enjoying that all-too-brief time between finishing one big project and starting the next. It’s a time to read some emails I might have skipped and even take a minute to ponder them.

One email recommmendedThe Watch for Flu and More. It is a well-written article for the public describing the benefits and challenges of syndromic surveillance for adverse reactions during H1N1 immunization in the U.S. “Harvard Medical School scientists are linking large insurance databases that cover as many as 50 million people with vaccination registries around the country for real-time [emphasis added] checks of whether people see a doctor in the weeks after a flu shot and why.”

This program challenged by three factors.

• The time-lag associated with respect to detecting rare events in a fast-moving vaccination program. I inserted the snarky “emphasis added” to point out that it is difficult to put “real-time” and “billing data” in the same sentence.

• Subject identification. For populations of 50 million, what are the chances in a large program like this that the patient demographic  information will match between insurance and registry data? The good news is that occasional mismatches are tolerable in a statistical study. The bad news is that the goals of the study are to detect relatively infrequent adverse effects,  so the error level will reduce the sensitivity of detection. Perhaps the most important outcome of this study will be determining whether it is possible to detect adverse events this way. If there is an adverse event and it is not detected soon, perhaps ethicists who speak about the balance between protecting privacy and achieving the benefit of healthcare IT will have a real-world example to show the value of a universal healthcare ID.

• Registry compliance. For many patients getting the flu vaccine is a cash transaction. It is hard to imagine that Safeway and the airport immunization clinics are registering all their clients. Where they are registering there is little incentive to collect identifying information as thoroughly as when a bill must be submitted.

Changing the Odds

It is really important that the Harvard study happen. Perchance it will be a major discovery on adverse event detection and registries. More likely it will sharpen the policy discourse on where population studies have value and what can be done to improve their sensitivity. It is unrealistic to depend on the proliferation of EHRs into doctors’ offices to be complete in, say, 10 years. What is the level of proliferation that makes direct transmission of clinical data including immunizatin status a possibility for adverse event detection? Gartner believes that the combinaiton of incentive funds and Stark safe-harbor programs will create a pretty substantial nudge on proliferations. We could see as many as 20% of physicians using EHRs well enough to qualify for “meaningful use” by 2013. If those physicians are collecting immunization status and other indicators for adverse event reporting then the identity correlation would be reduced. If they have true “real-time” feeds of clinical data to massive adverse-event servers then the time-lags could be substantially reduced.

Being able to go beyond detection to associating problems with lot numbers will remain a challenge since patients will frequently get vaccinated through a different provider than the one that they use when symptoms develop.

Thinking in a ten-year timeframe it is also possible to think about policy changes that would motivate better use of data for various kinds of population studies. Perhaps it is possible to require those that adminster vaccines to register patients and submit the info to registries? It probably wouldn’t be cost-effective to pay them to register patients, given the limited value of adverse event detection for vaccines, on the average.

Absent a universal patient ID perhaps it would prove cost effective to pay PHR operators for providing linked up data sent with patient consent. PHR operators would likely use most of that payment to find ways to motivate patients to provide consent and authorize the necessary linkages with their providers. I’d bet these folks, who have a good handle on consumer behavior, could deliver a substantial number of patients for five bucks a head, and bask in the glory of making a proven contribution to population healthcare.  Such a program might be cost effective because the data could be put to many uses.  Like the Harvard study, a demonstration program on this model would yield important findings, succeeding or failing. It would provide some calibration of how much benefit a consumer must receive to share data. If it’s really $5 per person, or anywhere close, that would certainly inform the debate about the relative value that a consumer must receive to overcome privacy concerns.

Finally, simply requiring all health plans to play for all immunizations would create a data stream correlated on patient ID for analysis.

When it comes to achieving population-based value from clinical data, the hell of it is that we are required to accomplish this without a universal patient id. The good thing is that we are following Winston Churchill’s maxim, “when you are going through hell, keep going.” This Harvard study puts us one step forward.

Joe Heyman wrote a response to Practical Concerns re: Certification Recommendation that raised some important points. A dialogue between us may further illuminate the points.

I don’t know if Joe meant to imply that I am advocating CCHIT as the sole certifier, but let’s be clear up front that I am not. My concern is with the provision of the recommendation that implies that only the vendor gets to choose which certifying agency they use.

On to specifics. Joe writes:

In Practical Concerns re: Certification Recommendation I drew from the experience with CCHIT to identify issues that must be dealt with in certifying EHRs for various programs created under the ARRA. I further suggested that these issues are compounded by the “waterfall” process recommended by the HIT Policy Committee, wherein one organization (ONC) determines certification criteria and other organizations actually implement certification programs.

I immediately received an e-mail response suggesting that the waterfall approach is mandated by the HITECH portion of ARRA. Specifically at Section 13101 it amends The Public Health Service Act to add Sec 3004 giving the process for adoption of endorsed recommendations; adoption of initial set of standards, implementation specifications, and certification criteria.

While only lawyers can interpret legalese, as a layman it seems pretty clear that 13101 dictates a process wherein the HIT Standards Committee ends up enumerating specific requirements for certification. This only slightly changes what I wrote however. ONC must recognize that it has only two choices for certification:

• Be precise and uniform not only on what is certified but also how, or
• Expect that multiple certifiers will be driven by market forces to “race to the bottom,” giving the most benefit of the doubt to vendors they can get away with.

If it chooses the former, it should determine what level of support the HIT Standards Committee needs to work out the details on how. I would urge it to look at the CCHIT experience for at least one working methodology and resource estimate.

Alternatively, I have not actually found language in the HITECH act that requires multiple certifiers. That seems to be a recommendation of the HIT Policy Committee. The ONC should at least consider whether the heavyweight approach used for ISO 9001 and the like is really required.