Interoperability--are we there yet?
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 MPO myeloperoxidase.
MPO Myeloperoxidase, see there .)
At that time, various groups seeking to harmonize standards and establish certification were in their infancies--the Healthcare Information Technology Standards Panel The American National Standards Institute (ANSI) Healthcare Information Technology Standards Panel (HITSP) was created in 2005 as part of efforts by the Office of the National Coordinator for Health Information Technology (ONC, part of the US Department of Health and Human Services) to (HITSP HITSP Healthcare Information Technology Standards Panel ), the Integrating the Healthcare Enterprise IHE is an initiative by healthcare professionals and industry to improve the way computer systems in healthcare share information.
In 1997, a consortium of radiologists and information technology experts formed IHE, or “Integrating the Healthcare Enterprise. group (IHE IHE Integrating the Healthcare Enterprise
IHE Institutions of Higher Education
IHE International Institute for Infrastructural, Hydraulic and Environmental Engineering (historical acronym only, replaced by: IHE Delft, the Foundation) ), 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 (Electronic Health Records) Computerized medical records that bring patient care into the digital age and save time, money and lives. The push to adopt comprehensive electronic documentation between doctors' offices and hospital settings intensified after the RAND ) 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 har·mo·nize
v. har·mo·nized, har·mo·niz·ing, har·mo·niz·es
1. To bring or come into agreement or harmony. See Synonyms at agree.
2. Music To provide harmony for (a melody). of standards and the establishment of certification criteria represent significant advances toward the seamless sharing of information. Yet, the landscape is still heavily populated pop·u·late
tr.v. pop·u·lat·ed, pop·u·lat·ing, pop·u·lates
1. To supply with inhabitants, as by colonization; people.
2. 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 CCHIT Certification Commission for Healthcare Information Technology ) has certified more than 160 EHR products based on detailed functional and standards conformance con·for·mance
Noun 1. conformance - correspondence in form or appearance
agreement, correspondence - compatibility of observations; "there was no agreement between theory and criteria.
* More than 100 companies have published IHE Integration Statements. John D. Halamka, M.D., M.S., chairman of HITSP and New England New England, name applied to the region comprising six states of the NE United States—Maine, New Hampshire, Vermont, Massachusetts, Rhode Island, and Connecticut. The region is thought to have been so named by Capt. Healthcare EDI (Electronic Data Interchange) The electronic communication of business transactions, such as orders, confirmations and invoices, between organizations. Third parties provide EDI services that enable organizations with different equipment to connect. Network (NEHEN NEHEN New England Healthcare EDI Network ), chief information officer of CareGroup Health System and the Harvard Medical School Harvard Medical School (HMS) is one of the graduate schools of Harvard University. It is a prestigious American medical school located in the Longwood Medical Area of the Mission Hill neighborhood of Boston, Massachusetts. , provided additional evidence in his "Life as a CIO CIO: see American Federation of Labor and Congress of Industrial Organizations.
(Chief Information Officer) The executive officer in charge of information processing in an organization. " 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 har·mo·nize
v. har·mo·nized, har·mo·niz·ing, har·mo·niz·es
1. To bring or come into agreement or harmony. See Synonyms at agree.
2. Music To provide harmony for (a melody). 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 Reinvestment
Using dividends, interest and capital gains earned in an investment or mutual fund to purchase additional shares or units, rather than receiving the distributions in cash.
1. In terms of stocks, it is the reinvestment of dividends to purchase additional shares. 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 expectations for 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 PCD
polycystic disease. )
* 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.
Investigate the harmonized standards and certification criteria to understand what is expected. The organizations mentioned previously have been busy in defining and approving 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.
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 (1) In object technology, the creation of self-contained modules that contain both the data and the processing. See object-oriented programming.
(2) The transmission of one network protocol within another. considerations: Event-driven and service-oriented architectures See SOA. (SOA (1) (Start Of Authority) The first record in a DNS zone file. See DNS records.
(2) (Service Oriented Architecture) The modularization of business functions for greater flexibility and reusability. ) 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.
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 Product Planning is the ongoing process of identifying and articulating market requirements that define a product’s feature set. See also
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 The examples and perspective in this article or section may not represent a worldwide view of the subject.
Please [ improve this article] or discuss the issue on the talk page. 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 Thomson Financial
A major provider of information, analytical tools, and consulting services to the financial community. The firm, a division of Thomson Corporation, is best known to investors for its First Call segment, which publishes consensus earnings Services, Bosch was director of product support services Product Support Services, more commonly referred to as PSS, is the Microsoft business unit with primary responsibility for responding to end-user and partner requests for assistance with the company's products and 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.