How to submit prior art on the Medicity Direct Patent

Recently Medicity has tried to patent the concept of a HISP. Please join me in submitting prior art to prevent this undermining of everything that the Direct Project stands for.

Groklaw shows the way

Here is a specific page that I had some trouble with and the right answers for it…

The Patent number in question is 61/443,549

The confirmation number is: 9529

The first names inventor is: Alok Mathur , Alpharetta, GA (US)

The date of file is: 02-16-2011

The strange string they are going to ask you in the middle appears to be: 201161443549

Read Groklaw carefully because the form is massively unnecessarily complex. (Because that is how the government rolls)..

The following prior art exists for their claims:

* Conversion of encrypted payload content, perhaps CCDs, into HL7 2.3 transactions sent to an EMR over TCP/IP ports

Of course, converting to HL7 v2 is not actually a good idea in 99% of the cases, but it was always part of the original vision of the Direct Project


Just search this page for HL7 to find Arien discussing the need for HL7 2.x interoperability

or you can read about how we dithered over 2.x versions of HL7

I will no dignify the fact that they note that this happens over TCP/IP with a comment. Really, you are going to use the networks protocol for that?

Are you sure you do not want to use UDP? Or perhaps IPX? Wow. Innovation. <- (sarcasm, see note for USPTO employees below)

* Conversion of encrypted payload content, perhaps HL7 v3, into rendered PDF formatted reports that are automatically printed to a local printer device per the provider’s workflow preferences.

* Construct of a standard Direct compliant outbound S/MIME transaction with CCD attachments by converting native PDF or HL7 v2.x formats and contents.

This of course makes direct look like a fax machine. Which is a -huge- step backwards. But generally, converting between different healthcare interop standards has been done for quite some time.

A main goal of the HISP is to convert between various formats. We spent months talking about the particularly difficult conversions, i.e. Direct to IHE

As far as I know the central advantage of a PDF is that you can print with it.

Here is Keith Boone discussing the issue on his blog


This is 2 months too late but shows that we including printers as possible devices to send direct messages to.

The second set of claims is particularly annoying to me because I got involved in Direct specifically because it was not possible to do coordination of care without an underlying point to point messaging infrastructure.

  • Sharing of virtual care team records across disparate networks

  • Dynamic updates to disparate patient reocrds using encrypted serialized patient objects across disparate networks

  • Sharing of application context within applications across disparate networks

  • Sharing of user context within applications across disparate networks

  • Establishing long-term patient and provider object-level communication across disparate networks.

Its late, so my patience for this is wearing thin. Email handles “sharing PHI across disparate networks”. The whole fucking point of direct is that is -just- email.

So everywhere that Medicity is saying “share (PHI Type here) across disparate networks” they are full of shit. This is the problem that Direct itself solves.

Then the question becomes. “Hey, now that we have this amazing capacity to share PHI across disparate networks, what specifically should we share?”

Hmm… perhaps we should use this to keep patient records in sync… no shit.

(in case you cannot tell. The preceding text is sarcasm. I am saying this because someone from the USPTO might be reading this, and I am not sure you might not have picked up on that. Working at the USPTO might be the kind of job where you lose your sense of humor. I am just saying. )

The whole concept of a HISP is that it site on the edge of the Direct network and integrates the local environment into Direct.

Medicity has a HISP product. It does things that HISPs do.

They do not deserve a patent for concepts that are -both- obvious and well described by the Direct community during the -entire- process of developing Direct. The fact that the US government did not dictate what a HISP should do does not mean that it was not discussed carefully, completely and commonly by everyone working on this project.

The “HISP as a bridge concept” is something that I had a hand in creating. I do not appreciate my own work being co-opted and abused in this fashion. I am requesting that Medicity withdraw this patent application, and consider… I don’t know… competing for Direct HISP business, instead of applying for bullshit patents on ideas that were created as part of an Open Source project.










Simpler Direct Directories

Alan Viars is making the case for simpler direct directories.

He has allowed me to republish some of his ideas here!!

A couple of weeks ago, I attended ONC’s Direct Bootcamp in Crystal City, VA. A hot topic at the two-day conference was the notion of a “Provider Directory” that incorporates Direct email addresses.

I also read that HHS/CMS intends to revamp the National Plan and Provider Enumeration System (NPPES). This is the system that manages National Provider Identifiers or (NPIs). Every individual provider and provider organization has one of these numbers, sort of like a tax ID for providers. A common complaint I hear is that it contains information that is often out of date and/or incorrect.

So what, you might ask, does the NPPES have to do with the Direct Project? Having worked with the NPPES data and having some background with Direct, the idea of “killing two birds with one stone” has captured my imagination. (Nerdy and wonky I know.) This is an opportunity for government efficiency by consolidating systems. Efficiency can only be achieved if the new system is simple, however. Too often in health information technology, consultants and vendors introduce complexity for complexity’s sake. After all, complexity is good for the bottom line for many companies because it means more billable hours and more services sold. Sadly, I see this sort of thing all the time. As an American and a taxpayer it ticks me off.(See footnote)

To illustrate what I mean by “simple”, I’ve built a prototype web service application that illustrates my vision of a combined NPPES and Direct email Provider Directory. Before I outline that technical proposal, however, I’d like to point out how adding some other data fields to NPPES could result in a an empowering service for patients, providers, and payers.

The whole article is worth a read. The man makes a good case.


Direct should be in NPPES

For those wondering, the Direct Project is a secure email protocol based on SMTP/S-MIME for doctor-doctor and doctor-patient secure communication. It is all-but-required in Meaningful Use version 2 and it is intended to replace the fax machine for the transfer of health information in the United States. I had a hand in designing the protocol.

NPPES is the authoritative source of doctor contact information in this country. <shamelessplug> is probably the best way to actually search the NPPES data,  and we have an API and everything. </shamelessplug> But you can download the NPPES data yourself and almost every insurance company, clearinghouse, HIE vendor, etc etc does this on a regular basis, in order to ensure that they have updated contact information for doctors, hospitals and other organizations in the healthcare system.

The NPPES publishes the NPI, which is basically the “social security number” for doctors and hospitals as they conduct business. Anyone who is legitimately connected to healthcare can get an NPI and you should, just so you understand what the signup process looks like.

When you register for your NPI, you have the opportunity to insert your contact information. Once you have an NPI, CMS publishes that contact information. This is the list of every possible contact field in the NPI data:

  • Mailing Address Telephone Number
  • Practice Location Address Telephone Number
  • Authorized Official Telephone Number
  • Mailing Address Fax Number
  • Practice Location Address Fax Number
  • Mailing Address
  • Practice Location Address

This bundle of information is what a physcians is required, under HIPAA (the parts no one pays attention to) to keep updated. Right there in the middle you can see two fax numbers. As long as the NPPES data does not have a Direct Mailing address listed in addition to Fax numbers, the message from CMS is clear “Use Fax for health information exchange, not Direct”.

Here, are the reasons that NPPES is really the only place that a centralized Direct provider directory can be kept.

  • It is the only contact information that a physician has a legal obligation to keep updated.
  • The NPI is the basis for “HIPAA covered transactions” which could be conducted over Direct if there were a clean linkage
  • Direct is designed to handle Cert discovery, so there is no need for NPPES do bother with any kind of x509 stuff..
  • The alternative is “competitive” directories from private industry which directly (and already) translates to balkanization.
  • At the stage, all CMS needs to do is starting asking for the address as part of the NPI signup as a non-required field… This would not need to be a mandate
  • But even having a space for it in the record would cause Direct adoption to explode
  • By publishing Direct Addresses in NPPES, it would be trivial to detect and call attention to “certificate balkanization” which is the biggest threat to Direct’s success
  • There might be complicated reasons for also doing some other provider director solution. Which is fine as long as it is additional to putting Direct emails into NPPES..
  • There is literally no other, better, way to get Direct into the conciousness of every doctor in the US. Until you start requiring Direct Email for Meaningful Use Attestation, but that is a post for another day.

Mostly, I just wanted to write this down as a brain dump so that others can easily email a link around as to why this is not a terrible idea.

I have proposed this several times, in person and I believe in some comment to Meaningful Use or something else on I am certain that I am not the only one, but I tend to be more vocal than average about Health IT policy implementation details. But I cannot find what I have already written anywhere, and it is probably included in something longer I wrote. I am unfortunately given to ranting when people formally ask for my opinion. So I wanted to write a short post about why this is clearly the way forward for Direct Project adoption.

If you have anything to add to my bullet points, email me at fred dot trotter at that email service that google runs.






Sharks, Bees and Privacy


I am happy to announce that my new article on healthcare privacy and interoperability has been accepted in the Journal of Participatory Medicine.

I am not against privacy in healthcare, but I am against the notion that privacy concerns should trump issues relating to good healthcare.

You can read the full article here:


Google Health: influential, controversial and gone.

Google Health is no more.

Thats a shame, because I am writing a book on Health IT for O’Reilly and before this announcement, my rough draft featured Google Health extensively.

I guess this is better, though, than having Google Health shut down just -after- I finished writing my book.

Of course, I am going to have to change lots of content in the book, but Google Health will still be there.

For a project that no longer exists, it will end up being one of the most influential Health IT projects of our era. Google Health, and for that matter Google generally, has always been willing to make strong statements when they evaluate technology and technology protocols. In fact, Google has made two controversial technology picks and the opening and closing of Google Health.

At the opening Google decided that they would support CCR (Continuity of Care Record) from ASTM and AFFP rather than the much more complex CDA/CCD from HL7. The CCR vs CCD debate has been one of the most controversial and long-standing arguments in Health IT. HealthVault, the Microsoft product which survives Google Health has always elected to support both standards. But Google insisted that the CCD standard was too complex, and not only insisted on CCR, but a smaller subset of that standard.

Now, as the end support for Google Health, Google is choosing to allow export under the Direct Protocol. Again this is the simpler of the two protocols that is supported by ONC to be part of the NWHIN (the precursor to the Health Internet). The other protocol, IHE, is getting no love from Google Health.

Goodbye Google Health, whatever else I may have said about you, I must admit that you made some ballsy technical stands.


Google Health is dead, HealthVault Indivo win

Recently, Google announce that the Google Health PHR will be retiring.

I posted the announcement to the Society for Participatory Medicine mailing list, and there has been alot of discussion about this, there. There are several issues that lots of people do not seem to understand, and some implications of this that have been missed.

Losers: Google Health Users

Let me be perfectly clear. If you trusted Google Health with your healthcare data you are screwed, unless the Microsoft HealthVault team rescues you. Even then, you are likely screwed anyways.

The whole point of Google Health was that it was more than a mere store of your XML patient data. It was a network of providers, like pharmacies, drug companies, non-profits and countless other service providers who added value to your health record.

I love the Direct Project but it only makes health data mobile, it is another matter altogether to make your health data semantically useful again. There is no way that the HealthVault team will be able to replicate 100% of the value that Google Health was providing based merely on the XML output from Google Health. As service providers and patients themselves added to their Google Health record, it made those records more complex than HealthVault, or any other PHR system, can easily understand. This is called Lossy Data Conversion.

The patients who will lose the most useful data, are those patients who leveraged Google Health the most. The more you invested in Google Health, the more screwed you are now. Of course, the other group who is going to be really screwed are the people who do not pay attention to announcements like this at all, (and ignore or filter email warnings) who will try to find data they stored in Google Health four years from now, only to discover that the deadline for data download had passed, and their data is gone. Ironically, the people who this is most likely to happen to are older people, who are not terribly tech savvy -and- who might have stored data in Google Health precisely so that they could ensure it would be available as they aged. Again the more they invested, (seemed like a good idea at the time), the more screwed they are today. Not good.

Probably the most important lesson to take away from all of this is that trusting proprietary health software vendors or services with critical health data is a bad idea. But sadly, that will not likely be a lesson learned here.

Losers: PHR vendors

Second, there is the implications for  PHR vendors. It does not look good for you. Google is in a unique position as a company. It is capable of making money giving away very valuable services, because it makes more money on advertising when someone merely uses the site. The business plan on Google Health was, essentially

“Lets spend a few 10’s of millions on this, and then make it back because a few million people will click on ads, after leaving Google Health to do a web search of some kind.”

Your average PHR company cannot make that kind of play. Most companies do not have a way to translate mass visitors into dollars. That is what makes the gmail service work for Google. Enough people click on ads through the service to pay for the entire thing for everyone. Google specifically admitted this problem in the post above with:

But we haven’t found a way to translate that limited usage into widespread adoption in the daily health routines of millions of people. That’s why we’ve made the difficult decision to discontinue the Google Health service

So if you are trying to start a PHR business and you cannot afford to give away a product you spent millions developing for years… this spells trouble. Google Health and Microsoft Healthvault together spelled the end of the still languishing dot-com bubble PHR services. I cannot imagine an investor in their right mind who would touch this space with a business model anything like Google Health.

Here is the basic takeaway from Google Health PHR:

People are not willing to use a good stand-alone PHR, even if it is free.

That word  “stand-alone” is critical.

Losers: Me

I have been wondering, as a right this, if I should be a winner or a loser on this one. I get to say “I told you so” to everyone I warned not to invest in a proprietary platform… which is fun. But I also now have to almost entirely re-write a chapter in my new book.

I (along with intrepid David Uhlman) am writing the first book on Health IT for O’Reilly media, called “Getting to Meaningful Use and Beyond“. I wrote the chapter on patient-facing software, and I featured Google Health extensively. After all, it was relevant, last week. I felt reassured after I asked Roni Zeiger a month or two ago if Google Health would survive? After all, I had heard rumors. He told me not to listen to gossip and I left feeling like my chapter would be published intact.

So much for meeting my deadline.

Winners: Direct Project

As Google Health dies it is giving a ringing endorsement to the Direct Project (of which I am a contributor). Hopefully this will raise some awareness regarding Direct as the foundation for the first generation of the Health Internet.

Winners: Microsoft HealthVault

Most of the industry pundits, like myself, have recognized for years that the “build the platform” business model that worked for Facebook and Itunes, was not going to work for Personal Health Records. Why? No “killer app”. Itunes+Ipod was the killer app for the Iphone platform, for Xbox it was the original Halo. For Facebook it was your ‘wall’, or perhaps (shudder) FarmVille.

The killer app for a PHR is dead simple: Healthcare. The two most widely used and successful PHR deployments in the country are the Kaiser Permanente and the VA’s My Healthevet. Why? You can get a message to your doctor through them, and receive replies back. They are a component of your actual healthcare. You do not have to type data into them, its just there. If you want to schedule an appointment or view your lab results you can do that. If you want to renew a prescription, the PHR can help. In short, the PHR is a workhorse in your actual healthcare process.

The Microsoft Healthvault team gets this. That is why they have been working on the Direct Project for months. They know that the Direct Project is the only way that they can have their PHR connect to -all- doctors the same way that Kaiser and the VA connect to their doctors.

Moreover, HealthVault has the only working mass-scale Direct beta in deployment: It is very likely that the only place you will be able to transfer Google Health records will be directly into HealthVault, for the foreseeable future.

HealthVault just became the 800 gorilla in the space.

My only question is why didn’t the Google leadership see the strategic significance of the Direct Project? They were obviously aware of it technically, and they usually do a good job translating technical understanding into strategic understanding.

Seems pretty simple to me. PHR usage is high -only- in systems where you can communicate with your healthcare provider in various ways. Google was disappointed by how few people were using their PHR. Direct is the only chance in hell that you have to reach every healthcare provider in the United States in the next five years. When you put it like that, Microsoft’s strategy seems pretty obvious… why didn’t the Google leadership catch on? Probably the Direct opportunity was too little too late for the internal political process at Google.

Winners: Indivo X

Indivo X has almost all of the same benefits as HealthVault (they are little behind on the Direct implementation and beta deployment), but if you actually want to avoid a repeat of the Google Health fiasco, this is the way to go. If you import your Google Health record into an Indivo X instance, you are not locked-in again.

Indivo X is Open Source, you can run your own instance if you want..

From now on, people will regard Indivo X as the safe option for PHR deployment, and rightly so, it is the only safe option. Until I can convince Sean and the rest of the HealthVault team to go full kimono, Indivo X is by far the most mature Open Source option available.

Why I do not think Google Health will, or should go Open Source

If Google drops code for Google Health, thats cool and I would take a look…  but I am not going to hold my breath.

Its pretty simple; Indivo was Open Source and available before Google Health launched. Some people believe that Google Health, like Dossia, is actually a long-ago fork of Indivo.

Indivo has moved on to bigger and better things. Indivo X, the current version of Indivo already has substantial functionality that Google Health is missing. It is already a mature codebase, with a community, and is generally operating openly as an Open Source project should. The Indivo project is not perfect, but they have steam.

Steam, motion, community, these are the things that make the Open Source garden grow.

Google Health would not actually help the Open Source community that much. We already have a better PHR project, and anything coming out of Google would compete for developers and attention with Indivo X.

Even if they wanted to, I am not sure that Google could usefully Open Source the whole Google Health codebase. Google projects often run on Googles custom, and proprietary database and network services. It is entirely possible that Google  Health would be useless without that back end.

What -would- help is for Google Health to release any components that Indivo X is missing. If they have an interesting Blue Button parser (which I happen to know they do) for instance, or some generalizable code for managing CCRs (that CCR-in-a-feed thing was a nice trick for instance…) then those components would be very useful.

Moreover, any components that would help people to parse their own Google Health data would be very welcome.

Probably the most important thing that they can do is license their API under several Open Source licenses. This way, Indivo X and HealthVault would be able to write a bridge that would allow currently existing Google partners to interface with Indivo X, without re-writing code. That would be pretty cool.

EHR can make the paper problem worse

Once a persons record has gone electronic, it really should never go back.

A paper printout of an Electronic Health Record is often huge and unwieldy. If it is printed out or faxed it creates something so huge that it is pretty impossible to be useful in a paper record.

This is the reason why need electronic interoperability solutions like the Direct Project. Without it, when a patient leaves one doctor, they have to print out an electronic record, take it to the next doctor, and then have that doctor scan the record in.

That doesn’t sound too bad until you realize that a patients printed EHR record often looks like this:

What happens when you print the contents of an EHR record for a single patient

This image was provided to me by Jodi Sperber and Dr. Eliza Shulman, who generously agreed to share the photo under a Creative Commons license. Here is the full description from Flickr, which provides greater context.

An example of why interoperability is as important as the electronic health record itself.

The story behind this photo: This is a printout of a patient’s medical record, sent from one office to another as the patient was changing primary care providers. An EHR was in place in both offices. Additionally, the EHR in both offices was created by the same vendor (a major vendor); each health organization had a customized version. Without base standards the systems are incompatible. Instead, the printouts had to be scanned into the new record, making them less searchable and less useful.

Note that this was not the entirety of the patient’s medical record… Just the first batch received.

Direct gathers steam

Recently, the AAFP and Surescripts announced Physicians Direct, a secure messaging service for providers.  But neither the article nor the signup page for Physicians Direct detail the most critical single issue regarding the service. This is a very large deployment of the Direct Project. This is by far the most important part of the story, but it is buried deep with the FAQs.

That means that the service is compatible with other large adopters of the Direct Protocol. Most notably, HealthVault has just launched a beta deployment of Direct.
Think of the implications of this. One of the largest PHR providers in the country is on the network, one of the largest network of doctors is on this network.

We are watching the birth of the Health Internet.. its is truly wonderful to be involved in this work.

When I tell my grandkids what I did with my life, I hope the links to my early posts on the Security and Trust Working Group of the Direct Project are still up. “I was part of that from the beginning” I will say… My previous plan was to tell them that I invented bubble-gum ice cream, and then enjoy basking in their amazed adoration, until they discovered that Grampa’s stories are “unreliable”.

This will work out much better.

This is also a tremendous step for Surescripts away from being a proprietary network provider. For those who are unfamiliar with Health IT, Surescripts has a monopoly in e-prescribing after buying out its only competitor several years ago. If you e-prescribe in the United States, there is a 99% chance that the data cross the Surescripts network. Surescripts is free to use for Doctors, but the pharmacies pay for the privilege. But that business model will die as the Health Internet grows. Once the pharmacies realize that you can use the Health Internet to exchange prescriptions rather than the expensive Surescripts network, that business will dry up quickly. Moving into the Health Internet provider business is the only chance Surescripts has at long term survival. This is a very smart move for them.

Of course, this also has implications for meaningful use. Providers can use this exchange network, without making an expensive investment in EHR technology, and still qualify for part of the meaningful use dollars. $15 a month might seem expensive for glorified email, buts a whole lot cheaper than an EHR.


Patient Centered Health Internet

I have recently been approached by several policy people who are interested in ensuring that the consumer/patient is at the center of the coming Health Internet.

Through my work at the Cautious Patient Foundation, I have become pretty obsessed about only working on patient-centered and patient-empowering technologies. I often work on software for doctors, but only when it happens to also empower patients.

For that reason, I have chosen to donate time to the Direct Project. I was one of the more active members of the Security and Trust working group, and what I am about to describe relies heavily on the trust model that I advocated for (along with Sean Nolan, from Microsoft… strange bedfellows… I know…).

I believe that any consumer advocate should be helping to ensure that state and regional HIE efforts, as well as the RECs are fully informed about the basic implications of the Direct Project. They need to understand what their role is… or more precisely what their role is not.

I argue that the Direct exchange model is fundamentally empowering in a way that the IHE model is not… yet. To understand why you have to look carefully at the basic routing models of the two systems. Lets imagine that I change doctors from current doctor, in Houston, to a new doctor in Arizona. If I were to transfer my files using the IHE NW-HIN this is how it would look:

How health documents travel over the IHE NW-HIN
How health documents travel over the IHE NW-HIN

Each little blue hexagon is an organization that believes that it is determining the trust, privacy and interoperability policies for its constituent members.

See the problem? In order for there to be a path between health provider A and health provider B a pretty large number of trust relationships will need to be in place, and everyone has to agree. In the short term, that is a pipe-dream. IHE requires complex routing with lots of very specific decisions at each “blue” point. The organizations that are in charge of making these decisions currently have no idea how to implement their policies in either IHE or Direct protocols. For the most part, the deciders just dribble on about trust relationships and policy decisions without any clear understanding of the technologies that will implement those features. Further, the IHE technology is a complex protocol, and sometimes complex routing decisions will not be possible in initial generations of the technology and/or protocol.

There are good reasons for this architecture. It can work, entirely in the background, without the patient (you) having to initiate are request. This is pretty good if you are showing up unconscious in the new city… Your records will just magically appear in the ER from the network. But what happens when Planned Parenthood has records for your and a Catholic Charity Clinic is making a data request to the network for you? Those kinds of tremendously complex issues are all handled -inside- the IHE protocol and its open source implementation the CONNECT project.

Now lets consider how this health record process would occur on the Direct Exchange:

How a health record moves across the Direct Exchange
How a health record moves across the Direct Exchange

Ok its worth taking some time to explain this. The Direct project is specifically designed to handle point-to-point trust relationships for Health Information exchange. From the Direct Project Security Overview (I actually wrote this part):

In the same way that clinicians currently do not assume that it is safe to fax protected health information to anyone with a fax number, or mail PHI to anyone with a post office address, Direct Project users should not assume that it is safe to send messages to any Direct Project address. Direct Project users will need to establish real-world trust relationships with other Direct Project users on their own terms, but once they have established this real-world trust, they can be sure that a Direct Project network will securely deliver Direct Project messages to the trusted Direct Project user.

So the “old doctor” needs to configure his EHR to trust my PHR. I need to configure my PHR to trust his EHR. Once that trust has been established, I can securely receive a copy of my records knowing that there are no untrusted intermediaries. The “privacy and security” policies need to be agreed upon only by me and my doctor.

Similarly the “new doctor” and I need to establish a trust relationship. Once this happens I can forward a copy of my records.

So what does this have to do with patient empowerment and consumer-focus? In my mind, everything.

  1. No one but me and my doctor need to agree regarding privacy and trust. Once the doctor is sure I am really “Fred Trotter” he can transfer anything he wants directly to me.
  2. The old doctor and the new doctor do not need to trust each other. The both need to trust me.
  3. I do not need any third-party permission to send data to and from my doctor. If I want to setup my withings scale to pump my daily weight measurements into my doctors EHR… I can do that.
  4. My PHR is a peer on the Direct Exchange network. The model is PHR-centric and is therefore patient-centric.

In the Direct Model, the patient can literally the center of the transfer. If the “old doctor” and the “new doctor” have a trust relationship, they can directly exchange information about me. But they do not -need- to have a trust relationship for the network to function.

Eventually, the IHE-based Health Internet will support patients as equals on the Health Internet. Eventually, the routing between different IHE nodes will be more direct, and then the benefits of IHE might begin to outweigh the benefits of the simple Direct Exchange.But for now, the Direct model empowers the patient in ways the IHE model could never hope to.

So what does that mean for policy makers? For whatever reason, every time I study a local, regional or state HIE effort, they all seem to be pushing the top-down HIE model. There are many things that a local HIE exchange could do to facilitate a Direct Exchange model, but for whatever reason, I do not see Direct being discussed by the RECs or by the local exchanges. I can understand why. In the Direct model, the task of a local exchange is to facilitate trust relationships and then get out of the way. The local exchange never gets to have a local copy of the patient data or even to see the patient record go by on its way somewhere else. They are much much less important under the Direct exchange model, and in fact, a Direct Exchange can happen without the cooperation or facilitation of any “HIE organization” or REC. This is much much closer to the distributed peer-to-peer nature of the Internet, and those involved with the Direct Project believe that in the end, it will be substantively easier for organizations to use than a IHE-based local HIE.

The Direct project is backed heavily by Microsoft Healthvault and members of the Google Health team are now participating as well. Those are the two dominant commercial PHR systems available. I believe both of them are just waiting for something like the Direct Protocol to blossom into really useful tools. Both of these tools have solid consumer-facing options available today.

At every level, organizations are deciding whether to invest in Direct or IHE-based exchange. At this point, I believe the only viable option is for a local exchange to either support Direct only, or both Direct and IHE. IHE is simply going to be too heavy weight for early adoption. Eventually, IHE may become dominate but for now Direct is much simpler, and puts the patient right in the center of everything. If you are a policy maker, you should be asking anyone involved with an HIE process to detail what their Direct-strategy is. If any effort is ignoring Direct and going with IHE-only I would lay odds that they will be broke and defunct before the decade is out.

Moreover, an IHE-only strategy is going to exclude direct participation from patients at this stage. If you care about patient empowerment, I recommend that you advocate for the Direct project at every level, including in your local HIE and REC.


Fred Trotter

(Update 2-16-2011) Keith Boone, a collaborator of mine on the Direct Security and Trust working group, and one of the architects of IHE points out in the comments below that there is nothing in the IHE protocol itself that dictates that it should be used in this fashion. He is partly correct about that. The protocol itself indeed has nothing inside of it that dictates this design over another. However, the inherent complexity of the protocol does means that when IHE happens, it will happen in a “centralized” manner. There is no other way for any given community to accomplish IHE, other than to pool resources. That pooling of resources ends up meaning that the IHE chart I drew is inevitable initially, but as IHE competence spreads it might become more peer to peer. In any case it hardly matters ‘why’ the tree structure I diagrammed is happening… it -is- happening. Every HIE I am aware of, other than Direct-based efforts, are presuming this tree model. It is certainly what is happening in Texas.

Direct Project Updates

The Direct Project has a new name (formerly NHIN Direct),  a new website and an excellent write up over on O’Reilly Radar called Healthcare communication gets an upgrade.

I am also interested to see that the O’Reilly folks seem to agree with me that this new NHIN thing really should be thought of as a “Health Internet”.

I see so much potential in the NHIN, and I really think it will be a communication revolution in healthcare on par with the original Internet’s communication revolution for.. well… every other industry except healthcare… I am glad to see that they are thinking about it in the same way…