The Power of Push

Hi,

The NHIN Direct network has been criticized for lacking relevance for health information exchange. Specifically, Latanya Sweeney has submitted testimony to congress which has nothing good to say about either NHIN project. The paragraph I want to highlight says:

ONC’s website also describes NHIN Direct [11] as a parallel initiative underway [3]. The idea came from comments made by representatives from Microsoft and Cerner [12]. In current practice, two providers fax patient information as needed. So, the idea is to replace the fax with email that has secure channels to combat eavesdropping. There are numerous concerns with this design also. A glaring problem is its limitation. We cannot perform all meaningful uses with this system, so we will need an additional system, which begs the question: why build this system at all? For example, this design cannot reasonably retrieve allergies and medications for an unconscious patient presenting at an out-of-state emergency room (arguably a stage 1 meaningful use). Figure 2(b) summarizes concerns about these two designs. The NHIN Limited Production Exchange has serious privacy issues but more utility than NHIN Direct. On the other hand, NHIN Direct has fewer privacy issues, but insufficient utility. When combined, we realize the least of each design, providing an NHIN with limited utility and privacy concerns.

This  is not the first time that the NHIN Direct push-only model has come under attack, so I wanted to discuss this. Push-only means that A can send messages to B, but B cannot automatically get data  from A (that would be pulling). Email and Faxes are push models. Web pages are pull models (i.e. sent to you when your browser asks for them). The  benefits of both models are constantly debated in software design .

I am working on NHIN Direct, and not so much NHIN CONNECT, although I have great admiration for the project and many of my friends are working on that project. My experience with NHIN Direct, which has been excellent so far, has helped me to understand just how narrow-minded and short sighted these kinds of criticisms are.

Both projects, in so far as such a thing is possible while building technology, are taking a “policy-neutral” stance. That means that rather than defining policy in code, we try to code so that a broad range of reasonable policy decisions can be supported in a given protocol and codebase. But even under a given policy, there will be many many options to use these technologies in ways that are unexpected. So when anyone criticizes the “security and privacy features” of either CONNECT or Direct at this stage… it is typically by making certain poor assumptions about how the system will be actually used.

The most important poor assumption is to consider only standard uses of the technology when considering meaningful use. For instance, the NHIN Direct project concedes that mere usage of the NHIN Direct exchange will map to specific meaningful use requirements. Note the headers on that PDF to see that this map was contributed by my friend Will Ross and the Redwood Mednet team. In Open Source healthcare, as in Open Source generally, you see the same actors generating excellent contributions again and again. But these meaningful use mappings only consider the implications of mere use of the network, rather than considering anything that can be implemented on top of the network.

When people say the ‘Internet” what they usually mean is either email or the world wide web. In reality the “Internet” is a far richer technology space than this, but for most people only two of the thousands of protocols that operate over the Internet have become personally relevant: SMTP and HTTP/HTML. In fact as I say that, many of my clinical readers might not even recognize that SMTP, and sister protocols like IMAP, are the protocols that enable email, or that HTTP/HTML enable the world wide web. In fact both of these protocols rely on lower level protocols, like IP/UDP/TCP/SSL/DNS that enable the average user to surf and email.

But understand that the richness of the Internet, as we know it today, is not merely what the protocol implementations allow you to do directly (i.e. browsers let you surf the web and email clients let you read and send messages) but how those technologies are used. The web allows you to buy books on Amazon, win auctions on ebay and find dates on eharmony. Each of those website enables complex application functionality on top of the implementations of http and html.

It is easier to see how the web has more to offer than merely transferring hyper-linked web pages, to see the richness that is available at the application level that is not implied or assumed by the lower level implementations of the enabling protocols (that would be web-browsers and web-servers implementing http/html). Sometimes it easy to forget that we see the same thing with email. The email network does far, far more than merely send and receive messages . Like the web, higher level functionality is enabled by the lower level protocol driven functionality, in this case the ability to send and receive messages.

I wanted to highlight several things that you can do with email, that are examples of this higher-level functionality.

• You can use an email account to prove that you are a human to a website. Have you ever signed up to a website that insisted that you give them an email address and then automatically sent you an email that had something to click on to prove that you owned that email address? I have done this so many times that I have lost count. This is “email for authentication”. Software often uses email messages to provide greater access to websites.
• You can send messages to just one email address, which will then be sent to many other email addresses. Mailing lists can be pretty amazing software services, but fundamentally all they do is intelligently receive and re-send email messages. This makes email change from a one-to-one messaging system to a one-to-many messaging system. But it is implemented entirely with one-to-one messages.
• If you push the mailing list even farther you can see that it can become something even more substantial, like craigslist, which pushes the envelope on email broadcasting and blurs the lines between email application and web application.
• Programs can automatically send email messages when something changes, like Google Alerts tell you when the web has changed (or at least changed as-according-to Google)
• You can have many email addresses and configure them to aggregate to one email viewing client, enabling separate relationships, and even identities to be managed in parallel. For instance your work email address really means your work identity, and your personal email means your personal identity, but you might forward both to the same email client and then answer and send messages as both identities at the same time.
• You can use email to create a system for recycling things. Making it easier not to buy new things, and not to throw away working things. This is essentially email-enabled peer-to-peer conservationism.
• Email clients are more than just programs we use to send and receive messages. We expect them to integrate with calendaring software. We expect them to allow us to extend them with other programs. People use powerful email clients like gmail to run their lives before people started to do that with gmail, they where running their lives with outlook or eudora.

Email is not just a method for sending messages. It is an application platform. Other applications that want to do something interesting can use email as a messaging component to achieve that greater goal.

I want to be clear. The NHIN Direct project has not settled on STMP, or email as protocol choice (although an S/MIME email is on the table). At this point we are not sure what protocol we will be choosing. But it does not matter, the point here is that NHIN Direct will at least act like, private, secure, identity-assured (at least for clinicians) email for sending clinical messages. You can expect that a NHIN Direct implementation will either be tightly or loosely integrated with a doctors EHR and a patients PHR in the same way that you have tight or loose integration between email clients and calendaring applications.

At this point it is best to think of NHIN Direct as a “cousin” to email. With lots of the same features and benefits but also limitations (to protect privacy) and new features (clinical integration, meaningful message signing, etc etc) that email does not have.

But the most important shared benifit between NHIN Direct and email will be the fact that you can build new interesting stuff on top of it.

Which brings us back to Latanyas first criticism. Will NHIN Direct support the ‘break the glass’ use-case (where your information can be gotten-to in case of an emergency) that Latanya mentions? No. Will software that implements NHIN Direct be able to use NHIN Direct as part of an something that provides break-the-glass functionality? Yes.

Very soon after an NHIN Direct network stabilizes, you will start to see this functionality addresses this use case. PHR applications like Google Health, HealthVault and Indivo X (the most important three PHr platforms) will probably develop break the glass mechanisms that work something like this…

I am an emergency room doctor and a patient comes in unconscious. In his wallet I find a card that indicates his PHR is held at johndoe@healthvault.com.

I visit healthvault.com and click the “break the glass” link. HealthVault asks me to enter my NHIN Direct address.. which is going to look a lot like an email address. So I enter fred.trotter@nhin.methodisthospital.com (not a real address). HealthVault will have already performed extensive public key exchange with Methodist Hospital, and will be able to cryptically ensure that any address under that domain name (we call them health domain names.. since they will be used exclusively for this purpose) is in fact someone that Methodist Hospital vouches for, and they will have pre-approved Methodist Hospitals PHI handling procedures. Given that pre-arrangement of trust, they will know that they can securely send messages to any published Methodist hospital NHIN Direct address.

But they are not certain, at this stage, that I am in fact fred.trotter@nhin.methodisthospital.com so they will send a message to that address with a link. I will click the link which will confirm with HealthVault that I am in control of that address, and that they should forward the contents of the johndoe@healthvault.com PHR record. Now that they are sure that this is a valid break-the-glass request from a valid user at an institution that they have a trust relationship with, they will forward the record to the address.

They will also add a record to john’s PHR to indicate that I broke the glass. If this whole process was done fraudulently, John will know and there will be hell to pay for me personally for abusing my credentials and for Methodist Hospital for giving me a credentials to abuse. Current HIPAA rules and fraud statutes would be activated if I made such a fraudulent request, that was not in John’s best interest. People who abuse the system could be detected and sent to jail.

The whole process takes minutes and works even when the patient is unconscious.

Would that particular method answer the “break the glass” components of meaningful use? It seems like it would to me. Would this be the method that we end up using? I am not sure, but it would be something similar in spirit. Most importantly, it would be something  implemented on top of, and around, the messaging model provided by NHIN Direct.

All of that is to say: Push is Powerful. It is powerful because it does not need to work alone. It can be a component of a larger system that does much more. It creates the opportunity for innovation and greater functionality similar to the one provided by the original Internet protocols.

This is all true of the NHIN CONNECT project as well. The difference is that NHIN Direct is much simpler and has true parallels with the current fax and email systems. It is easier to see how NHIN Direct might change things because we are so familiar with its cousins, email and fax.

NHIN CONNECT offers much more functionality at the price of far greater complexity. Like the NHIN Direct system, and email and web before it, the NHIN CONNECT architecture will allow for innovation to occur on top of it. But it is doing much more work than NHIN Direct is.

For instance, if I were fully NHIN CONNECT enabled, I would be able to conduct a search for John Doe and find out that three hospitals had information that were not contained in the HealthVault record. NHIN CONNECT might be able to provide a merged view of that data for me, which is a much richer process than mere messaging can achieve. But that means that NHIN CONNECT must tackle the complex problems of sorting out which records actually belonged to John Doe and therefore deserved to be merged. It would make automated, but accurate, decisions that Jonathan Doe at hospital A was my John Doe but that Johnny Doe at hospital B was not… NHIN CONNECT  should understand that a blood pressure measurement that was in the data it gathered from HealthVault was or was not a duplicate of blood pressure readings that came from the hospital C EHR, that had the same date, but not the same time stamp. These kinds of issues, plus countless more just like them, are addressed or exposed by both the underlying NHIN protocols that CONNECT implements and by the CONNECT codebase specifically.

CONNECT uses push and pull and all kinds of other software models to do something very complex.

NHIN Direct just does push, but leaves potential complexity to higher level yet-to-be-made systems.

Some people think the NHIN Direct model is superior. Others think that CONNECT is better. I think we probably need both for different reasons.. which is essentially the ONC position on the matter.

But I wanted to be sure everyone was clear: Push has Power.

-FT