HIE: Health Information Emperor Has No Clothes

emperorNoClothes
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?


FTP is a Bad Idea

July 14, 2010 / CloudPrime, Security / 0 Comments

bad-toasterApplication-to-application messaging is a critical component of most enterprise grade organizations. On a daily basis, tens if not hundreds of thousands of application messages, files, requests, etc. are processed over their messaging fabric. What is interesting to note is how a lot of organizations are creating their application messaging network. For lack of a better solution, a lot of organizations are relying on FTP to transmit sensitive data over the network. This is bad.

FTP is a simple protocol that allows for the exchange of data over a network, but it should NOT be depended upon for sending any information that is regarded as sensitive or confidential in nature. The reason why FTP is a problem is because it does not encrypt data as it passes over the network and you only need a username and password to send/receive files. The real threat is that messages can be sniffed out or intercepted en-route, exposing each party to big-time security problems.

There are some simple ways to help secure FTP transactions, but for the most part, it is still an unsecure and unreliable way to send messages and by some estimates can cost an organization $300k to $1M per year in maintenance and recovery costs, even though FTP is “free”.

To further mitigate the issues with FTP, a lot of organizations will employ “roll your own” solutions that help secure the message network and provide the necessary features needed to comply with various requirements and compliance regulations. Where this becomes an issue is that typical RYO solutions can be rigid, hard to maintain, and are expensive to deploy (not to mention the resources that will be needed manage and update the network on a regular basis).

In the end, both FTP and “Roll your own” solutions leave a lot of gaps in an organization’s application messaging infrastructure that not only may hurt them from an operational and security standpoint, but end up costing them millions in maintenance and recovery costs.

Cloak Labs solves these problems by providing a completely managed service that allows applications to communicate with each other in a secure, reliable, and cost-effective way.

Features:

  • Cloak Labs’ patented technology makes sending messages through “the Cloud” safe
  • Guaranteed delivery of all transactions
  • Non-repudiation
  • Rules-based, encrypted message archival
  • Easy to deploy software Security Gateways
  • No hardware to buy or upgrade

To learn more about how Cloak Labs can help your organization implement secure and reliable application-to-application messaging network, contact us today.


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?