Understanding the Direct Project

Looking through some of the recent announcements on the Direct Project, it is not completely clear what NHIN is trying to represent if you are an EMR, Health Care Professional or Health Information Service Professional (HISP).

NHIN’s Direct Project is providing a specification and guidance on how interfaces can be built to exchange information in a secure, encrypted way using “email like” addresses on a network.

This is great! This is not an implementation though.

Health care professionals or ISVs who are looking at the Direct Project to solve their connectivity problems will need to understand that an interface will still need to be built, and encryption and key management will still need to be licensed in order to ensure all data is securely sent and in compliance.

This is a great step forward, and standards help drive adoption and innovation, so we will be excited to see how the trials turn out.


NHIN (The Direct Project): Ready for Prime Time?

NHIN and NHIN Direct (now called “The Direct Project:) are frameworks for creating a standard system through which health care applications can communicate, share information, and connect with one another. And, according to Shahid Shah, in his article titled An Overview of NHIN and NHIN Direct for Software Developers*, “NHIN is far from settled and is not a forgone conclusion for data exchange, so you shouldn’t rest your complete integration strategy on it. In fact, make sure you have other options available to you.”

I don’t want to be too negative on NHIN or those who are striving to make it a production reality, but if you are considering connecting systems leveraging NHIN, you should understand where NHIN stands as a health information exchange solution.

With the HITECH Act, meaningful use (MU), and incentive payments on the line, a lot of organizations are trying to find their health information integrations solutions now, not in the future. As such, below are some weaknesses of NHIN that might be an issue when trying to implement a health care application integration solution:

  1. Still in early stages of testing with users
  2. Many security policies still need to be defined and implemented by the user
  3. Limited documentation for implementation
  4. May require application development for exchange integration, making it a resource intense solution to roll out

Given that there are a lot of new compliance regulations to meet in order to receive incentives, IT resources will be stretched, and anywhere you can implement a solution that does not require a large amount of overhead and technical expertise is going to be attractive. Even if NHIN and The Direct Project were ready for prime time, integrating your systems (which could be dozens per location), will require a lot of resources, time, and money.

In short, NHIN is not the silver bullet for health information exchange, nor is it the solution that companies, health care professionals, and application integrators can count on now.

Life is a Health Information Exchange Highway…

John Moore is a much smarter person than I, and his colleagues at Chilmark research know their stuff, and that is why I was so happy to see Mr. Moore discuss HIEs in his Health IT News Blog on August 4, 2010.

John, in greater eloquence than yours truly could deliver, openly discussed the problems with the haphazard way health information exchange is being approached within the healthcare industry.

Yes, we know that there are large numbers of dollars dedicated to establish a free flowing, secure network of health information; and yes, there is a limited timeline. This is not an excuse to achieve interoperability the wrong way, but instead a call-to-action to do it right!

An interesting point in John’s blog is his comparison to private vs. public HIEs and how they are organized. It should not really be too surprising that private HIEs are more efficient and organized. The private sector’s main goal is optimization to increase margins without comprimising quality (hopefully). States don’t really have the same motivations, and typically they work with grants and funding allocated to special initiative programs thatmust be spent, not conserved. This is not a cheap shot at the state HIEs, just an observation of how projects are organized between the two sectors.


Mr. Moore goes on to make a great comparison to the Interstate System and Eisenhower’s vision for an interconnected nation, including a statement that like the Interstate Highway System, “it won’t be cheap”. The current amount of funding for public HIEs is half a billion dollars… that is not cheap!

I think that with the right plan in place, we can solve the connectivity problem in a cost-effective way with a reasonable timeline. Having said that, John is right, that a plan and vision will make HIEs a success and will become a “Symbol of Health”.

Application Messaging Integration: Look into my Portal

Let’s face it, Middleware is not sexy. It is the stuff that literally can be found in “the middle” or lying below the surface of what a general user of software technology experiences. CloudPrime, to many, is just that: a service that allows applications to communicate in a scalable, secure, and cost-effective way. Yep, that sounds like Middleware.

However, what is not typically available through Middleware services, is a portal; a window that allows a user or manager gain visibility into a system. Cloak Labs is an exception to that rule and offers a very detailed interface that allows professionals to have better visibility into their messaging network.

Cloak Labs’ messaging portal provides a variety of features for network managers and users alike, including:

  • Simple, graphical interface for easier management
  • File-level tracking
  • Security Gateway management
  • Message network reporting
  • Exception reporting
  • Network message alerts

Whether you are a Healthcare Application Integrator, EHR Vendor, or Healthcare IT Professional, how you connect systems and manage the messaging infrastructure between them is extremely important, especially in the context of compliance.

The idea behind the Cloak Labs portal is to give Health IT Managers and users more out of their Middleware, and expose as much information as possible, allowing these users make intelligent, well-informed decisions about how they connect systems.

HIE: Health Information Emperor Has No Clothes

No sooner than we posted our blog on achieving interoperability, Health IT News posted an article titled “Sustainability threatens HIEs even as their numbers increase”

If you read through the article, it will not be hard for you to figure out that the major problems HIEs face is that they do not have solutions that will make them successful in creating healthcare interoperability. While some HIEs report they are independent of Federal funding and are sustainable, most report they are completely reliant on tax payer dollars. What is frustrating is that this money was passed out without the assurance there was a real plan in place to use the money effectively and achieve the goals of a connected healthcare infrastructure where data moved freely and securely.

The sentiment shared by a lot of integrators and state agencies is that these HIEs do not have a strategy for achieving interoperability and that they are way behind.

As mentioned before, it is not completely fair (nor in this author’s nature) to accuse the HIEs of sleeping on the job or not trying, but the stark reality is that archaic means for achieving interoperability are still being used to solve the problem. When the White House passed the HITECH Act, the idea was to bring the healthcare system into the 21st century with fresh ideas and new technology, but instead, what we are seeing is the Emperor has no clothes.

Is Healthcare Interoperability Achievable?

We have written numerous times applauding Dr. Blumenthal and the ONC for pointing out the importance of Health Information Exchange and interoperability in the context of bringing healthcare into the digital age. However, it is not totally clear that the dollars are actually making it to backend systems and that the main focus has been on patient and physician interfaces for collecting data.

In the end, there are some very simple things that need to be understood in order to achieve interoperability:

  1. People need to understand that there is a backend system that needs to be in place in order to achieve healthcare interoperability;
  2. Health Information Exchange needs to be more than just people and physician focused, i.e., only concerned with front-end systems such as a PMS;
  3. Untill all the endpoints are connected, there is no Health Information Exchange;

sand-castlePatients are no doubt important, and they are the raison d’etre for the HITECH Act, but how well will they be served when their doctor’s Patient Management System or EHR cannot connect to the regional HIEs? Or if one patient medical record cannot be shared across hospitals?

To date, millions of dollars have been awarded as grants to regional HIEs and state coalitions to implement and enhance how healthcare systems connect, but there is no real plan for making this happen. This is not a criticism of the people who are trying to find a solution to their problem, but it shows that the current solutions for achieving interoperability are not up to the requirements and healthcare IT professionals need new solutions and ideas.

The backend systems that will provide interoperability are the backbone of HIE. Without interconnectivity between all healthcare systems, HITECH is a castle built on sand.

So the question to you is: how will Healthcare Interoperability be achieved?

Liberate Your Application Messaging Network!

Shameless plug #2

Continuing on the healthcare application messaging theme, I thought it would be good to discuss how you can get more from your application network while spending less on it.

When we talk with customers and integrators, we usually start with the basic set of requirements which revolve around what message types we can handle and which protocols we support (e.g. HL7, X.12, MLLP, etc.).

As we dig deeper into the conversation, most people start realizing how powerful our solution is because:

  1. Babies-Collection-Spaghetti-Head-82310-752897We are a managed service, meaning that we handle the management and support of the messaging network
  2. We provide several value added services including guaranteed delivery of all transactions, rules based message archival/storage, multi-protocol support, PKI Management and ease of implementation
  3. We are cost effective
  4. We don’t make your application fabric look like a spaghetti nightmare

Traditionally, when IT managers, integrators, or Health Information Exchanges are evaluating how they will connect networks, applications, clouds, etc. many people scratch their heads and start compiling complex blue prints on how they will cobble together open source tools, legacy hardware, and VPNs to meet their needs.

Where this falls down is:

  1. It is hard to actually pull the system together
  2. Once implemented, it is difficult to manage and maintain
  3. Support is not included
  4. It is not easy to bring up (bring down) new trading partners on the network
  5. Forget about updating your system

In short, there are many ways to skin the application messaging cat, but the question is, do you want to do it the most effective way?

Cloak Labs provides a “fire and forget it” application messaging and reporting platform that takes the burden of building complex and unmanageable messaging networks. Doesn’t that sound way better than the “do it yourself” way?