Gartner Blog Network

Semi-Agreeing With David Kibbe

by Wes Rishel  |  November 18, 2009  |  4 Comments

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.


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” (


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


Wes Rishel
VP Distinguished Analyst
12 years at Gartner
45 years IT industry

Wes Rishel is a vice president and distinguished analyst in Gartner's healthcare provider research practice. He covers electronic medical records, interoperability, health information exchanges and the underlying technologies of healthcare IT, including application integration and standards. Read Full Bio

Thoughts on Semi-Agreeing With David Kibbe

  1. David McCallie says:


    I think you have advanced the conversation by cleverly making the distinction between the “provider internet” and the “health (consumer) internet.” This artifact may be a useful way to stage the discussion.

    In a more formal mode, I think the distinction of how health information should flow to and from providers, consumers, patients, payers, and government agencies is perhaps a little more complicated. I think it might be best to think of each data exchange in terms of the policies, regulations, and laws that govern the flow.

    For example, some data exchange is a function of WHERE (which state) the provider practices, e.g., state-mandated public health reports. These exchanges could be mediated by a local HIE, or perhaps just sent over a secure TLS connection to the state’s designated portal. These transactions should follow the appropriate HITSP standard, and need not be RESTful, as they are fixed in nature and by design are not expected to change except slowly as regulations require.

    Another large class of data exchange is governed by HIPAA. These data flows, as you nicely describe, are generally point-to-point, and are governed by an explicit consent to treatment (under TP&O.) These transactions likewise should follow HITSP standards, and likewise need not be RESTful, as they are intended for a well-defined, highly regulated purpose. “Secure, provider-to-provider messaging” with structured (and unstructed content) would fall under this category (and would eventually replace the fax machine.) It seems likely that as providers move more towards “hosted” or “software as a service” EMRs, many of these data flows would originate from vendor-supplied “inbox” software, using TLS to connect the provider to a vendor-hosted gateway, and from there to the desired target. It makes sense that the NHIN could provide the “gateway to gateway” message service, perhaps via rules around using S/MIME or simply SMTP over TLS. The NHIN (or ONC) could also coordinate and provide the LDAP directory service that will be necessary for the addressee to be determined, as well as core authentication services to guarantee that the recipient is authentic, etc.

    These data flows (and others that I mentioned on Dr. Kibbe’s blog) probably do not gain very much from an open-ended RESTful approach to interaction. There are reasonably well-defined standards that could enable these transactions to be quickly deployed. In this case, “simple” is the familiar. We don’t need to re-invent email, FTP, etc.

    The new category of consumer-facing services, on the other hand, are different. Most of these services don’t exist yet. PHR-like services (like Health Vault and Google Health) are emerging, but they represent the tip of the iceberg compared to what will be possible when consumers are able to control and direct the flow of data from the originating provider to the service(s) of their choice.

    These new services cannot be easily represented using SOAP or SOA-like models which presuppose the use-cases and expose only certain subsets of data behind pre-defined “service” transactions. Rather, these new services woudd benefit from a resource-oriented design, which exposes (to authorized users!) the actual data, using a yet-to-be-determined URI naming model, along with simple combinations of https’ GET, POST, PUT, etc. This is where the NHIN could define “the health internet,” by coordinating the URI naming standards, and by examples on how to use HTTPS to accomplish the core transactions. There are many new internet service APIs (like Twitter, Facebook, etc.) which could serve as models to follow.

    Several key problems need to be solved before these RESTful services would be widely deployed, including is a common authentication standard for users, and agreements on how to implement proper permission and access controls on top of the RESTful transactions. There are some good models to follow in the Internet commerce space. Hopefully, the HIT “dogs” can learn from the Internet “cats.” (Or did I get that backwards?)

  2. […] Article Wes Rishel, Gartner, 18 November 2009 SHARETHIS.addEntry({ title: "Semi-Agreeing With David Kibbe", url: "" }); […]

  3. Wes Rishel says:

    Thanks, David. Two areas of your reply to discuss further.

    Does the provider-provider approach to communications require the full weight of the structure of standards, HIEs, and an NHIN in order to accomplish it? I am thinking of a different kind of URI, that identifies a provider organization end-point, and the protocols to support authenticated, reliable, confidential and irrefutable transmission. Right now the typical lab system that delivers results has a slot for “fax number” and I wold see this URI occupying that slot. Any public certificates needed for transmission would be available by using the URI. We should explore building this, to the maximum exent possible based on widely-used Internet protocols. Although it is blasphemy to say that there is anything tha tshould not be done with HTTP maybe we should examine SMTP which supports the “store and forward” work flow needed here.

  4. David C. Kibbe, MD MBA says:

    Dear Wes, Dr. McAllie, and others: First, let me say that we all have something to learn from one another, cats, dogs, whatever… that if we put the patient’s health care and well being first, then we can make huge strides in solving whatever problems there may be. It is only when we fall back into our foxholes as representatives of special interests, be they standards organizations, consulting firms, IT vendors, or doctor groups, that we fail.

    So, let me echo the spirit and I hope the intent of Dr. Blumenthal’s recent communications about ONC’s and ARRA/HITECH’s major goal, which is to improve patient care, and to do so in part by removing barriers and impediments to health data and information flows. The information should follow the patient — be accessible whenever and wherever needed — and nothing should get in the way.

    There is nothing in either Wes’ post or Dr. McAllie’s post, that I would disagree with. These are good ideas, all. Since both David and Wes are members of the HIT Standards Committee, and have enormous respect in the industry, their ideas carry real weight, and I’m encouraged by them and their agreement with one another.

    And, as David says, Wes’ artifact of breaking the Health Internet discussion into two parts, one for patient-directed data flows, and one for provider-directed flows, may be a useful construct for moving the discussion along. Nice.

    This may help us come to terms with and accept the fact that the general problem of heath data constipation derives from attitudes and business models that are the responsibility of providers, IT vendors, and other health care entities to solve, not the patient’s. In the past, the entire industry involved in building, buying, and implementing health IT systems has refused to design in data exchange or interoperability. The reasons were simple: This strategy has been, and continues to be, enormously profitable to a few. It explicitly supports the perverse incentive of the FFS by making data LESS available, and therefore adds to the justification for repeating tests and duplicating procedures, which someone will pay for most of the time (until now?), generating profits for the provider organizations which they can then use to purchase expensive but not interoperable IT. We have created tens of thousands of proprietary “data islands” for each node in the health care system, a situation that requires huge consulting interface contracts and incessant upgrades and versionings, to address data transfers, and we’ve ended up with what Esther Dyson very accurately called an “enormous calcified hairball” from which even basic, summary health information is very difficult to extract on a consistent and reliable basis. Witness the ePatient Dave fiasco.

    So, I’m eager to join both of you and others to put the patient first and find ways that both providers and patients/consumers can get access to health data and information where and when it’s needed, to improve continuity and quality of care.

    A logical starting place in my own opinion is to focus on getting SOME meaningful and relevant summary health data to the patient, or to whomever the patient wants the data to be able to get to, on a consistent and reliable basis, using the Internet and World Wide Web protocols, standards, and conventions that already work for other types of personal data. If the big problem, really, is getting this small but relevant data set out of existing health information systems, let’s work together to make this as simple, efficient, and user-friendly as possible (always securely). This will surely lead to provider-provider exchange enhancements, too. I am certain that once we can do this small thing, we can expand and extend upon it, to include more data and different types of data.

    Rather than have the patient/consumer and his/her agents do an end-around the providers’ systems, let’s get them working together. This is my vision for the Health Internet.

    Very kid regards, DCK

Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.