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