Interoperability: Are We There Yet?

Tim Bosch

A few years ago, a typical approach to interoperability was to define a proprietary, customized interface specification, or to use a standard such as HL7 (Health Level Seven is an all-volunteer, not-for-profit organization involved in development of international healthcare standards) with an agreement between individual parties regarding fields used and how data was represented. (For additional background, see the author’s previous column, “Navigating the Integration and Interoperability Rapids,” in the July/August 2007 issue of MPO.)

At that time, various groups seeking to harmonize standards and establish certification were in their infancies—the Healthcare Information Technology Standards Panel (HITSP), the Integrating the Healthcare Enterprise group (IHE), the Medical Devices “Plug-and-Play” program and others. These efforts have blossomed, and the approach to connectivity and interoperability has shifted significantly. The electronic health record (EHR) has been pushed to the forefront as a result of the Obama administration’s health initiatives, and with it come incentives for interoperability to feed an EHR with information from certified medical devices and medical information systems.

The harmonization of standards and the establishment of certification criteria represent significant advances toward the seamless sharing of information. Yet, the landscape is still heavily populated with systems and products operating under the  “old rules.” With all this, the question about medical devices and medical information systems interoperability remains—are we there yet?

Evidence of Interoperability is Mounting

One could argue that interoperability has arrived—at least in the sense that we are capable of true interoperability without the need to hand-stitch code for each data exchange for each set of system connections. Here is some evidence that we are there:

• The Certification Commission for Health Information Technology (CCHIT) has certified more than 160 EHR products based on detailed functional and standards conformance criteria.

• More than 100 companies have published IHE Integration Statements. John D. Halamka, M.D., M.S., chairman of HITSP and New England Healthcare EDI Network (NEHEN), chief information officer of CareGroup Health System and the Harvard Medical School, provided additional evidence in his “Life as a CIO” blog posting on Dec. 8, 2008, titled, “Obama’s Economic Plan.” Below is a brief summary:

• NEHEN: In 2008, there were 60 million data exchange transactions from EHRs, practices management systems and hospital information systems.

• Massachusetts SHARE (Simplifying Healthcare Among Regional Entities): There have been half a million e-prescribing transactions among providers, payers and pharmacies.

• Massachusetts eHealth Collaborative: It has wired three communities with roughly 500,000 patients, 597 physicians in 142 practices in 192 sites and four hospitals including hospital-based laboratories and imaging centers.

And, in his Dec. 1, 2008, blog posting, “Interoperability Advice for the New Administration,” he concluded “… interoperability is implementable today with harmonized standards, appropriate security and a service oriented architecture using the Internet. Now we need incentives to implement it.”

Interoperability appears to be rapidly coming to fruition with incentives now to help move your customers to seek certified solutions.

So everything is in place, right? For new systems and devices, or your latest product version, this may be true, but you are likely supporting several releases of your products, each with a number of custom or generic interfaces. Your ability to help your customers quickly take advantage of American Recovery Reinvestment Act incentives may be hindered by those legacy solutions.

Legacy Challenges Still Exist

A lot of workflows are based on legacy approaches, and it is not easy for care delivery organizations to change behavior and tools. Over time, it costs more to maintain customized connections, while systems and devices on both sides are changing—not to mention changing clinical needs and legislated expectationsfor interoperability.

The best approach to ease your interoperability burden and advance your capabilities involves analysis and planning steps to govern development activities such as:

• Assessing your system’s interoperability needs and capabilities

• Determining quality of service requirements

• Targeting interoperability standards (i.e. CCHIT, IHE PCD)

• Assessing your system architecture to determine its suitability to meet your needs

• Determining how to best realize desired interoperability capabilities. This may involve migration from your existing approach over time or redoing your interoperability component from scratch.

System Needs Assessment

Your interoperability needs are obvious to you. A clinical information system needs to exchange charge data with a revenue cycle management system. A diagnostic imaging system needs to exchange images and reports with a clinical information system. A laboratory device needs to exchange orders and results a with laboratory information system. With the goal of EHR in mind, what other data will you need to consume or produce?

If you have an existing system or device, an assessment of your current architecture and implementation will help determine how you can create or upgrade your interoperability capabilities. Architecture assessment methodologies like Architecture Tradeoff and Analysis Method can be used to identify how well your current architecture and software support your business needs.

Quality of Service

As care delivery organizations grow to depend on interoperability, quality of service considerations take on even larger importance. The ability of one system to deliver its expected quality of service will depend on other systems to provide a corresponding quality of service in areas like performance, reliability, security and data integrity. You need to clearly define the quality expectations for your system. Know the quality of service commitments of the other systems through service-level agreements or by the other system’s certification through an organization like CCHIT, or published test results from an event like IHE’s annual Connectathon event.

Interoperability Mechanisms

Investigate the harmonized standards and certification criteria to understand what is expected. The organizations mentioned previously have been busy in defining andapproving harmonized standards and certification criteria. IHE has active domain specifications for a number of healthcare areas, as does HITSP. CCHIT has criteria for ambulatory and inpatient EHR. Choosing the standards that meet your business goals based on the nature of your system or device and creating custom solutions is no longer a viable option. The faster you can provide systems or devices with certified interoperability solutions, the sooner you and your customers will benefit from incentives.

System Architecture

Analysis and planning activities drive system architecture upgrade or definition. The system architecture considerations are not revolutionary but reminiscent of current best practices. There are three key considerations:

• Interoperability considerations: Even though you will be using standard approaches, you must understand transport protocol, message format, service interfaces, error handling, data definitions, configuration parameters and run-time controls.

• Isolation and encapsulation considerations: Event-driven and service-oriented architectures (SOA) are good models for supporting isolation. SOA alone, however, does little to guarantee successful interoperability. It’s the combination of service capabilities, quality of service considerations and architecture that provides the solid foundation for your interoperability needs.

• Architecture distance considerations: Before embarking on a migration path, understand the associated complexities. Beware of attempting architecture migration across a large “architectural distance.” If your new approach is too different from your current approach in terms of software organizing and operating principles, refactoring legacy code within existing architecture may be more burdensome than writing new code in a clean architecture.

Use the new harmonized standards and certification criteria to guide your interoperability goals, but position your system to keep pace with these evolving standards and certification requirements.

Justifying Interoperability

It’s estimated that a 100-bed hospital could receive nearly $4 million over four years in government incentives for adopting a meaningful use of electronic health records. There is a significant amount of funding available to justify interoperability expenditures at the healthcare enterprise level. The ability to support customers in that effort starts with your ability to provide a timely and certified solution. That requires an assessment of your current capabilities and proper planning and alignment of your business goals with your product planning and execution.

Tim Bosch is chief architect at Foliage and has been with the company since 1999. In this role, he directs consulting and development efforts for a variety of projects. Past projects he has led include medication management system architecture assessment and product development; disease management system architecture assessment and product development; dialysis system architecture assessment; HIS/EMR assessment and product migration strategy; and cardiac care system architecture assessment. Bosch also has served as project director or lead architect for various enterprise information systems for several financial services projects at Foliage. He brings more than 25 years of software experience to the company. Prior to joining the Foliage, he held technical and management positions at Codman Research Group, where he was director of new product development. Previously, at Thomson Financial Services, Bosch was director of product support services and development project manager. Prior to Thomson, Bosch was engineering director and project manager/lead system engineer at Imagitex. Bosch began his technical career at Atex as a software engineer. Bosch holds a bachelor’s degree in English from Carnegie-Mellon University. In addition, he has completed graduate coursework in computer science and business at Harvard University’s Extension Division.