When most people talk about “The Enterprise”, they are referring to large corporate establishments. We all know it is a fictional craft sailing through the far reaches of space to “boldly go where no person has gone before”.[You either hate me or love me at this point]
All kidding aside, I recently engaged in a discussion with a friend where they asked if Cloak Labs works for “The Enterprise”. I am assuming that he meant corporations in the traditional sense, and when I responded that our customers in the Health Care space are enterprise customers, he looked at me with dismay.
When most people hear “The Enterprise”, they think of supply chain management, financial transactions and CRM tools to name a few. Rarely do I hear people mention Health Care (Health Care Networks, hospitals, physician groups, clinics, state agencies, etc.) when describing who their enterprise customers are.
In large part, I think this is due to the Health Care industry historically being late adopters of technology, and thus viewed as an outsider to The Enterprise discussion. With the recent stimulus funding, passing of the HITECH Act and stricter HIPAA compliance regulations, the Health Care industry is consuming enterprise grade applications and systems on a unparalleled scale and quickly is gaining a lot of attention by business and solution providers who wish to pander their goods to anyone and everyone in Health Care.
Where there can be a parallel drawn is to the late 80s (through today), when businesses began leveraging the Internet to connect to other systems within their trading community or across their organization (think EDI, Lease Lines, VANs, MFT, etc.). The Health Care industry is being challenged by a similar problem in that they are required to connect all systems to the health information exchange to allow for secure digital transmission and ubiquitous access to electronic health records.
While many still do not think of the Health Care industry as an enterprise-class market, it is hard to ignore how much focus companies like GE, IBM, and Intuit are putting into this space, signaling that the major players of enterprise grade solutions have a different perspective on what is and is not “enterprise”.
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”.
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:
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.
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.
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:
Patients 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?
Application-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.
To learn more about how Cloak Labs can help your organization implement secure and reliable application-to-application messaging network, contact us today.
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:
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:
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?