Gartner Blog Network

On eBay, the Fax and Healthcare Interop

by Wes Rishel  |  November 22, 2009  |  6 Comments

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.

Category: healthcare-providers  interoperability  vertical-industries  

Tags: arra  ebay  ehr  emr  health-20  health-internet  health-it  healthcare-interoperability  healthcare-providers  nhin  

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 On eBay, the Fax and Healthcare Interop

  1. Shane Taylor says:


    I wanted to clarify a bit on Notion 3. I should have done a better job explaining my stance on that. I think this might both agree and slightly disagree with your comment concerning “Notion 3: Direct Patient/Consumer Involvement Is Not the Solution”.

    I believe the following should happen:

    1.) The patient should be able to pre-authorize his network of providers (for example: his local hospital, local family physician, any local specialists, his PHR, etc…) Any communications between those endpoints can happen without repetitive patient involvement. But the patient is still in control of this communication and can “unauthorize” any endpoint/provider at any time (not typical with a lot of RHIOs where it is a complete opt in or opt out). But, again, I agree… having patient involvement each time would never gain traction.

    2.) If there is an emergency and the patient is unable to provide authorization (perhaps he/she is unconscious), then “break glass” authorization can be used in ad hoc querying for the patients information if the provider isn’t already pre-authorized. If a non-pre-authorized provider wants access to a record (via ad hoc querying) and it isn’t something that justifies “break glass” authorization, then a request would go to the patient to authorize the transfer. Also for any transfer, an audit trail should be provided to the patient at any time.

    Also a few comments, for “Notion 4: The eBay Model of Trust is Inadequate for Healthcare”:

    I agree that judgment is still needed when communicating between providers via a facilitator (just trusting blindly is not a good idea). But it is the facilitation that is required. Technology is ready today to exchange data as simple (only better) as a two party fax can already do and can provide that value today. Having a complete level of trust among all vendors is one of the major reasons why RHIOs and the NHIN are going to be slow to adopt (i.e. signing the DURSA). The eBay example was only used in the context of the facilitation. You are right that a manufacturer of baby food wouldn’t buy ingredients off eBay with the level of trust that it currently conveys. Perhaps one day a DURSA like agreement could be put in place for all members of eBay so that everyone can trust everyone else (like the NHIN is trying to do), but I don’t think that will happen any time soon. The end points (providers) of the exchange of information are still going to have to use their own judgment to some extent. However, the facilitator will ensure that at least the endpoints (physicians) are who they say they are (message authentication) and that the messages are reliably delivered (non-repudiation).

    Hopefully that helps clarify what I was trying to say. I believe your comments are, for the most part, spot on.

  2. […] This post was mentioned on Twitter by Wes Rishel and Shane Taylor, RecordNexus. RecordNexus said: More good health interoperability discussion that doesn't rely on RHIOs being the main model – […]

  3. Social comments and analytics for this post…

    This post was mentioned on Twitter by wrishel: “On eBay, the Fax and Healthcare Interop” ( is part of a set seeking a simpler approach for #HealthIT…

  4. David McCallie says:

    I agree with Wes’ general point that directed, provider-to-provider, “push” of patient information (i.e. “replace the fax”) should be a top priority for HIE. The reasons seem straight-forward:

    * Data sharing consent is simple because the patient will have already authorized the data flow by consenting to care. The provider will typically push only what’s necessary for this episode of care, as allowed under HIPAA TP&O

    * Since the data sharing authorization is implicit in the consent for care, the patient does not need to be involved in the data transfer. No PHR or RHIO is necessary. (If the patient wishes to exclude some other provider from the care process, then he should communicate his wishes to the sending provider.)

    * The data is not persisted anywhere except in the EMR systems of the sending and receiving providers. The “network” merely facilitates the transfer, but need not “repose” a copy of the data. Downstream privacy concerns (“pull” sharing) are minimized.

    * Concerning trust issues, I believe the biggest issue is authentication of the end-users. Since we aren’t going to get a national PKI anytime soon, authentication will have to be delegated to end-user-aggregating organizations. These organizations should make “reasonable efforts” to ensure that their users are who they say they are, etc.

    * These end-user-aggregating organizations could be RHIO/HIEs, but it’s my bet that they will most typically be the EMR vendors who provide the EMR to the provider. (For messaging to work well, it should be embedded in the EMR workflow, e.g., “inbox”, “export as CCD”, etc.)

    * The user-aggregating organizations need several things:
    – They must trust each other (around the end-user auth policies)
    – They need to share a common user directory service (LDAP?)
    – They need a standard message exchange protocol (SMTP over TLS?) I don’t think it is necessary to have a proprietary exchange/switch in the “middle.” We should seek to emulate the way email works, albeit with stricter end-user access controls, and full end-to-end encryption.

    * I also believe there is a second major kind of patient data sharing — where patient data is aggregated (directly or indirectly) for future, as-yet-unconsented use. This kind of data sharing is more complex, because the consent-to-share is decoupled from any specific episode of care. I personally believe that the “health bank” model (consumer-controlled, network-accessible PHR) is the best way to manage this, but that’s another discussion…

    David McCallie

  5. Liam Davis-Mead says:

    I like the way Wes and David are making a distinction between “push” and “pull” transactions–I think it’s an extremely useful distinction. In some way the push model is _much_ simpler, and in fact it’s more easily facilitated by current IHE profiles. It’s also no coincidence that it more closely mirrors the current paper process. Sure, you can think of calling the other office and requesting a record as a query, but you’re not going to get any data until they push it to you through that fax machine.

    As far as the trust issue, David is spot on about third party “end-user aggregating organizations”. This is precisely the role fulfilled by those root Certificate Authorities implicitly trusted by your web browser…Verisign, Thawte, etc., except those organizations do not typically provide mutual authentication, which is what’s needed here. He’s also correct that these organizations need to provide directory services. I see these types of organizations as being what Shane described as “Health Internet Service Providers” in his comment to the previous blog post (“Simple Healthcare Interop for Easy Applications”). They would provide these authentication and other services directly to end users — in this case, that means providers.

    I seriously doubt, however, that it will be the EMR vendors fulfilling this role. I suspect that they will continue to do what they do best, which is to provide differentiated software offerings for clinical settings of a wide variety of scales and specialties. I suspect that Shane’s HISPs will operate at more of a least-common-denominator level, and will communicate with other HISPs, as well as client software (the EMRs), via standardized and open protocols (IHE / HITSP profiles, etc). I also suspect that there will be a multitude of these service providers, as Shane initially mentioned, and then Jim followed up with a similar thought.

    I would also suggest that it is precisely these HISPs who should also provide the message handling — routing, reliable delivery, and delivery notification. There need not be a single central exchange or switch, and it need not be proprietary (I would suggest that the IHE profiles have much to offer here). However, the message routing will need to be coordinated at some level, and it seems easiest to place this level at the level of the aforementioned “end-user-aggregating” organizations, and have these gateways act as service providers that take care of all three parts: mutual authentication, directory services, and message handling.

    Now, RHIOs could provide these services, and indeed, their participation in the NHIN as NHIEs would seem to require it, but the existence of RHIOs is not _necessary_ to provide these services. RHIOs (and by extension, the NHIN) are a much more heavyweight solution, hence the current discussion, which basically asks, “Isn’t there an easier way?”

    There is another critical component that I believe HISPs would provide, and that is durable auditing of disclosures. If a physician practice implements an EMR that utilizes local storage, and they have some sort of glitch or crash that wipes out all of their patient records, that’s a big headache for that provider organization, but at least it’s localized to that organization. If that same data loss implies, however, that they are no longer able to furnish a disclosure audit to their patients (because that information was stored in the EMR), then we have a problem.

    Of course, we have the same problem today if all of an office’s paper records burn up in a fire, but I think that’s one of the areas where we want to try to improve over paper.

    To use a (poor) analogy: Microsoft, Cisco, and Level 3 all care about TCP/IP at some level. Microsoft has to code its client software (e.g. Internet Explorer) with some knowledge of it, Cisco has to design devices that can intelligently move it from place to place, and Level 3 has to provide the physical connectivity to pass it between Cisco’s devices. (This is a gross oversimplification, but that’s what you get) This is three separate markets, yet they form an ecosystem, as without any one of them, the other two would be pretty useless. To draw the parallels to the current discussion, I’d say that the EMR vendors play a similar role to Microsoft, Shane’s HISPs play Cisco’s role, and we can simply leverage the existing Internet to take the place of the physical connectivity provided by Level 3’s fiber. A set of core IHE / HITSP profiles would be the “TCP/IP” here.

    I also think that David’s email analogy is fine as far as it goes: from an end-user’s point of view, sending an email _is_ a simple point-to-point, direct connection (and we should strive for a model in which clinicians see precisely this level of complexity). But behind the scenes, that message can be routed between many different SMTP servers, each using mechanisms such as DNS to perform discovery of other servers. There’s all sorts of routing and message handling that happens out there, but it’s thankfully hidden from the consumers of the technology. You could draw a parallel between the work done by these SMTP servers on our behalf and the services provided by HISPs.

    So, I see four key services provided by these HISPs: mutual authentication of the endpoints (not unlike trusted root CAs); directory and discovery services (not unlike DNS); secure message handling and routing (not unlike Cisco and the rest of the decidedly grungy, unsexy plumbing of the Internet that we all take for granted); and auditing. As a stopgap, these service providers could also offer a fifth key service: legacy interfaces, such as interfacing with legacy EMR vendors through mechanisms such as HL7, or operating fax gateways so that paper-based providers can receive records from electronic sources. But in general, these sorts of proprietary interfaces should be frowned upon, and their use limited to “last mile” connections.

    On a last note, the more I think about the term “Health Internet Service Provider” (HISP), the more I seem to like what it implies. It is not as if the government or the healthcare industry is short on acronyms, but thinking of it this way may help others see a different model (similar to ISPs) about how health exchange can occur on a national or even global level.

  6. […] My Boggle-Busting Goal recapped the rationale for this “Simple Interop” thread. In On eBay, the Fax and Healthcare Interop I turned my own attitude around about that oft-deprecated bedrock of healthcare interoperability, […]

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.