I think Ascendian’s CEO Shawn McKenzie’s interview is a great summary of HIMSS 11 and what is happening in Healthcare IT:
If you don’t have time for watching videos at work, then I will try to sum it up the best I can:
Widgets, lot’s of them. Mostly unimportant.
Shawn makes a great point that there is no real plan for Healthcare IT and interoperability. Instead (as we have commented before) there is a focus on EHRs and building “widgets” for healthcare professionals, which is essentially creating healthcare “silos”. While there is a ton of innovation being made at the practice side, very little is going into interoperability and the traditional medi-evil VPN solution for connectivity still reigns.
After walking the floor of HIMSS for days, we learned on our own how true this was. Most EMRs and EHRs didn’t care about interoperability and were content to tell us it was the customer’s problem. This seemed odd to us in 2 ways: 1. The idea is to solve customer problems, not ignore them, and 2. As a business, they are leaving opportunity on the table.
The Direct Project also had a showcase that demonstrated interoperability, but it was not clear who should be interested and why.
Once people realize that connectivity and interoperability are a big issue, they will also realize that the old way of doing things will not be sufficient. Real investment in new technologies that utilize the Cloud and provide real solutions to the connectivity and interoperability problem are needed. To borrow from Mr. McKenzie again, what we have now is the coal but not the train or the tracks.
With new regulation comes new opportunity. New healthcare requirements around the digitization of health information has caused a wide variety of start-ups and services to surface. Innovation is great, but there are very few standards being adhered to, causing a lot of headaches for ISV’s who are working with new customers to implement their systems.
If a hospital, physician, or clinical lab would like to start using a new product or service, that application needs to be able to communicate with older systems that may not be ready for retirement. Who will be responsible for ensuring that the two systems can interface to each other? How much will this cost and what impact will it have on deployment schedules? This typically falls on the vendor and a solutions specialist needs to be brought in.
Take for example a PMS system at a physician practice that now needs to communicate with a scheduling system that resides in a data-center off-site. The physician PMS will need to exchanges HL7 SIU messages with the scheduling system securely, meeting HIPAA requirements for health information exchange.
In order for this to happen, a secure connection between the two endpoints needs to be established, application interfaces need to be built, ports to the firewall need to be opened, and eventually a mechanism for ensuring each endpoint is authenticated must be implemented (See Wikipedia Article under Security Rule). What seemed to be a simple roll-out of a new system now requires professional services, network changes, and protocol conversion if there is a different transport protocol in use.
These integrations and road blocks can increase sales cycles and implementation times, making it harder to sell while decreasing margins for the ISV. Not to mention, the burden this may place on the customer.
Once an integration occurs, it is also necessary to monitor and maintain the network, which requires IT resources that may not have previously existed or may not have the bandwidth to support an increasing number of integration points.
As part of your integration strategy, it is important to evaluate a build vs. buy strategy:
– What will be the cost impact of rolling a VPN and application interface for each endpoint?
– What will be the cost of managing and maintaining that network?
– Who will bear the cost?
– What impact will this have on implementation times and sales cycles?
– As compliance regulations change, how will this impact your solution and margins?
Healthcare interoperability is an extremely important part of HIPAA regulations and a lot of health IT professionals will be focused on it, but as an ISV, connectivity may not be a part of your core offering, making it a distraction instead of an opportunity. If the numbers do not add up, it may make sense to use an application integration service as part of your value proposition to the customer, making implementation smoother, and decreasing network costs.
2011 is going to see a dramatic increase in the adoption of EHR software and digital patient information exchange will become an even greater priority in order to meet Stage 1 meaningful use requirements.
If you are an IT Manager, this looks like it will require an all hands on deck and a huge shift in how things have been run throughout your organization. Since all patient data will need to be exchanged digitally in a safe and reliable way, you will be tasked with:
Some things to think about in 2011 as you prepare to meet these new requirements are:
1. Meaningful Use Incentives: Registration for the EHR Incentive program started on January 3rd: http://www.healthcareitnews.com/news/government-ehr-incentive-program-ready-go
2. New Infrastructure: New processes will need to be learned as you begin interfacing to all the EHRs, PMS’, HIEs, Physician Groups, Clinical Labs, etc. being brought onto the network.
3. Security: All patient health information will need to be encrypted and transported securely in order to meet HIPAA compliance.
4. Training: Staff will need to be trained and allocated to manage these networks. As your network continues to grow, so will the resources required to support and manage it. Changes in your firewall will need to happen and application interfaces will need to be built.
5. Solution Providers: HISPs (Health Information Service Providers) will need to be selected. Not everything can/should be done in-house, so you will need to determine how to minimize the total impact of these new application interoperability requirements. Your EMR may already provide application interfaces, but it is possible that many of your systems do not support outbound connectivity.
2011 will bring a lot of change for the healthcare industry as a whole, and with that change, progress. Despite the huge burden these new regulations will have on IT departments large and small, the end game will produce a cohesive, secure and reliable patient information exchange that improves the quality of care for all Americans.
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 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:
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.
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?