Land Speed Records

Wes Rishel said that if the Direct Project finished its work in a year, it would set a new land speed record.  He may be right, but I have thoughts about what record we are talking about.

From 0 to completed specification?  Nah, the Direct project missed that boat on that one.  IHE PCC took down that record in 2005 in the newly created Patient Care Coordination Domain.  That domain went from 0 to trial implementation specification (with a 30 day public comment period in the middle) from the beginning of July 2005 to October 2005, with testing by 14 implementors at the January 2006 connectathon. That's 4 months to an implementable specification, or 7 months to tested implementations, depending on how you want to count it.  Those implementations went into production in the following year.

HL7 has done pretty well also.  Several specifications have been created and published inside 6-8 months (mostly DSTUs, which require two implementors).  Some of those also went into production fairly quickly.

But not as fast as the Direct project seems to be going, and that is a real change.  The real record for the Direct Project is from project inception to announcement of commercial support (PDF).  But I don't think the Direct project can take all the credit for that speed.  In order for their to be commercial support for standards or interoperability specification, there must be a market for it.  Meaningful use created a market need for provider to provider communication with more than $20B in incentives, and the Direct project met that need.

It is no surprise to me that the Direct project is viewed as a big success.  It should be viewed that way, but it should also be viewed in the larger context as well. If the next project that is taken on in a "Direct-like" fashion doesn't have the same kind of incentives behind it, it may not succeed nearly as well.  We need to remember that in these projects and "keep our eyes on the prize" as it were. 

If we can do that, I believe we will succeed.

How can you be sure you have the right HIE solution?

I do have something else to say today, and it's about Wes Rishel's post: Surescripts Announcement Confirms Simple Interop Incremental Approach.

My frustration with Wes's response is not his clear appreciation of what Surescripts has done.  In fact, as a patient I too appreciate it.  It is with his first recommendation given in the Gartner Quick Take that he wrote last week:

HDOs that plan to deploy HIE to community physicians: Delay deciding on a solution, or choose one that can incorporate Surescripts if it is proven effective.

Wes talks about the challenges of setting up an HIE, and then throws yet another one at them.  Wait until a single vendor proves itself (a one to two year proposition), or figure out whether your current solution will be able to incorporate the technology they've chosen.  It's not even that he's provided the "wrong" advice.  He's simply written it in such a way that most people will have only two choices:  Wait, or trust what others tell you without being able to evaluate their answers.  As an analyst, one should really try to do more than just identify problems, the real work is to explain the solutions.

So, here's the nitty gritty from my perspective:

The Direct Project uses the same technology that e-mail uses to send information.  This is primarily SMTP and for security S/MIME.  These solutions and tools to support them are ubiquitous on the web, which is why it was chosen in the first place. If you cannot make something work with software that is this widely available, you need to find another line of work, or a different staff.

For anything more than a simple document, the Direct Project recommends wrapping the content in the IHE Cross Enterprise Documents Sharing for Media format.  That format is a ZIP file structured (alos ubiquituous) in a very simple way, with one additional file to store a metadata wrapper describing the clinical content in the files that you send.  That metadata wrapper supports health information exchanges that use the IHE XDS family of profiles.  In fact, The Direct Project also describes how systems which use one of these specifications, the IHE XDR profile to provide an alternative channel for communication.  The IHE XDR profile uses the XDS Provide and Register transaction to send the content and metadata.  The Direct Project demonstrated during the early development process the capability of a solution to take an XDR communication and forward it using the Direct protocol, and visa versa.

So, if you want to know whether the solution your HIE is looking at will support the technology used in the Direct Project, you need to ask whether the proposed HIE solution works with IHE XDS or IHE XDR.  And you need not just take someones word for it.  You can also find a list of solution providers who have tested their products against the IHE XDS specifications, IHE XDR Specifications, or the IHE XDM Specifications at IHE testing events.  These are the HIE solutions that are already poised to take exchange from beyond point to point push, onto the next level. 

Solutions which implement the recommendations made in The Direct Project specifications will be able to work with these HIE systems quite readily.  Given the popularity of the IHE XDS profile for use in Health information exchanges around the world, I quite expect that anyone who fails to account for these in any sort of Healthcare exchange is simply setting themselves up for failure.  I think the leadership at SureScripts has already demonstrated by their support of the Direct Project that they are smarter than that.

   -- Keith

NHINDirect from 10,000 Feet

A one page overview of NHIN Direct put together by @JanetlCampbell

---