Meaningful Use Stage 2 and HIE Transport – Meaningful Use Monday

I’ll admit that I’m far from an expert on all the various HIE transport standards and movement happening in making health information exchange a reality in healthcare. However, meaningful use stage 2 is a big step towards getting doctors to exchange information. So, I’ll leverage some experts comments on HIE in meaningful use stage 2 to hopefully get the conversation started. Then, I’m sure some other HIE standards geeks will join in the comments to help us all further understand what’s happening.

John Moehrke has some of the best information I’ve seen for those interested in HIE and meaningful use stage 2. In one post he described his initial “fantastic” impressions of meaningful use stage 2 in regards to security privacy and HIE transport. Here’s the section on HIE transport:

HIE Transport:They have given us one or two Push style transports, and recognized that they interoperate by way of a proxy service that can convert forward and backward. There is no real surprises here as ONC has spent much time developing the Direct Project. Healthcare Providers and EHR developers should really be focusing beyond Direct, but supporting minimal Direct is a good thing to do. It allows us as an industry to move away from the FAX, and start universally communicating and manipulating Documents. I will note that these more Exchange like HIE models would still be considered compliant under the optional third transport.

I think he’s dead on that the majority of providers are going to get to know Direct really well in order to meet the meaningful use stage 2 requirements. In another more detailed post on the various HIE transport options including 3 options within the Direct Project: Full Service HISP, email integration, and integrated into the EHR.

John Moehrke has 3 great images I’ve embedded below which illustrate the above 3 models:

In the Full Service HISP, the user uploads the health information to a web portal or possibly emails the information to the HISP. This model reminds me of the various physician portals I’ve seen out there. They’ve worked really well for doctors who do a lot of referrals and need to exchange data. Although, logging into a portal isn’t the most seamless way of sharing data.

The email integration option requires you to have some good IT experience to be able to configure your email properly to support the identity and security configuration that will be required on your email system. Considering the number of doctors I know that still use aol.com, yahoo.com and gmail.com accounts, this won’t be a good solution for them. I bet even Google Apps accounts won’t support this, but it would be really cool if they did. Would be a really smart move by Google to have gmail support it if they could. The nice part is that once it’s configured you can sign and encrypt the email in a pretty seamless fashion.

Integrating the direct project specification directly into the EHR is the best option since it provides the user a seamless experience. The challenge will be on the EHR vendors to be able to integrate it into their EHR software, but I expect many will see this as the best way to service their customers. It will be harder on the EHR vendor, but the EHR vendors that do this extra effort will have much happier users.

Hopefully this gives a decent overview of the Direct Project options. John Moehrke has a lot more technical details on the subject if you want to read more about those. I know he’s pretty active on Twitter, so I’ll ping him now to have him take a look at this post so I can add any clarifications if needed as well.

I’m excited to see the Direct Project in widespread use. I think the Direct Project vision has best been described as replacing the fax machine. The move to exchanging documents using direct will be a good step forward. Sure, it’s just the first step, but it’s an important and useful one.