Completely inspired from my trip to HIMSS last week, I thought it made sense to talk about healthcare interoperability, connectivity and the component pieces to making this happen. This mini series is broken up into several parts that will cover:

1. What is connectivity and interoperability?

2. File protocols, formats and requirements, i.e. HL7 (including discussions on version 2 vs. 3), DICOM, EHI, and CCD;

3. Transport protocols and interfaces: MLLP, TCP/IP, FTP, etc.;

—

Part 1: What is Healthcare Integration and Interoperability?

According to HIMSS, healthcare integration “is the arrangement of an organization’s information systems in way that allows them to communicate efficiently and effectively and brings together related parts into a single system.” †

The 2006 White House executive order defines Interoperability as (section 2 paragraph c):”Interoperability” means the ability to communicate and exchange data accurately, effectively, securely, and consistently with different information technology systems, software applications, and networks in various settings, and exchange data such that clinical or operational purpose and meaning of the data are preserved and unaltered. ‡

These are great standard definitions and allow you to understand the difference between the two. Integration relates to how systems can work or collaborate for a common purpose, e.g. a patient management system working with a scheduling system. Interoperability speaks to how these systems are connected, in order to provide a continuous flow of information that improves care for the patient.

In order to achieve Interoperability, systems must be connected in a secure way, authenticating all users and allowing one healthcare application to share data with another anywhere in the country, without compromising a patient’s privacy.

From a real world scenario, what this means is that all systems must be integrated in order to achieve interoperability, i.e. a physicians patient management system must be able to authenticate and securely connect to a hospitals EMR; Ambulatory centers to pharmacies; hosted EMRs to wound treatment centers. Patient information can no longer live in just one place.

Interoperability Dimensions º

• Uniform movement of healthcare data
• Uniform presentation of data
• Uniform user controls
• Uniform safeguarding data security and integrity
• Uniform protection of patient confidentiality
• Uniform assurance of a common degree of system service quality

No Small Task

Connecting all of these systems is no small task and is as much of an organizational challenge as it is a technological one. People and healthcare systems no longer exist within a vacuum and teams need to collaborate to make integration projects happen. These same people will need to agree on the best way to solve the connectivity problem and rely on the guidance of Health Information Service Providers to come up with solutions that meet the needs of all while adhering to the mission of improving patient care. As we continue to move forward in achieving interoperability, the scope and magnitude and of what needs to happen cannot be underestimated and careful planning must take place.

Throughout the mini-series, we will discuss the component pieces that are involved in achieving interoperability including application interfaces, file protocols, transport protocols, security & authentication, and compliance.

The Goal

Integration and Interoperability are significant pieces of the Meaningful Use objectives and the mission is to improve the care of individuals while providing them with secure, ubiquitous access to their health information. While there is no one way that can solve the challenge of interoperability, understanding the mission and the various parts of the goal can help make achieving connectivity as prescribed by the ONC and Meaningful Use.

Bonus Treat:

Healthcare Interoperability Panel Discussion

Tomorrow: Part 2 - File protocols, formats and requirements, i.e. HL7 (including discussions on version 2 vs. 3), DICOM, EHI, and CCD

† http://www.himss.org/ASP/topics_integration.asp

‡ http://cyrusxp.com/?page_id=18

º As defined by HIMSS

I think Ascendian’s CEO Shawn McKenzie’s interview is a great summary of HIMSS 11 and what is happneing in Healthcare IT:

Ascendian Healthcare, CEO and President, Shawn McKenzie at HiMSS 2011 from MedicExchange.

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.