Navigating the integration and interoperability rapids.
To achieve integration and interoperability that supports EHR, first you must understand the difference between integration and interoperability; learn integration and interoperability "best practices" approaches; and avoid the pitfalls of poorly planned and executed integration and interoperability.
The terms "integration and interoperability" frequently are used together and often exchanged as if they were synonyms for the same concept. In actuality, however, each term addresses different areas of concern, with different implications for a medical device or medical information system.
Integration is the process of incorporating parts or components to form a whole or complete system. Some use this term to describe the sharing of information among enterprise systems or across enterprise boundaries. However, the sharing of information within a system of systems found in an enterprise actually refers to interoperability.
Integration, at its simplest, is the use of a component to provide functionality needed to satisfy a particular system or product need. This component may be a commercial off-the-shelf product, a third-party tool or library, or your own reusable component.
At its most complex, integration for a vendor with multiple healthcare information management capabilities--clinical information, revenue, patient, imaging and others--often involves common lookand-feel, data model, configuration or customization capabilities and operations management controls. These common capabilities are deemed necessary to provide a uniform appearance to the user/customer and to ensure coordinated information sharing among this single vendor's various capabilities.
Making the Best Decision for Your Needs
When deciding to integrate components into your system, remember that cost always matters. While component integration offers rapid development and lower development cost possibilities, it could result in higher support or operational costs. Be careful to consider all costs before moving forward--run-time license, development license, packaging and distribution impact, as well as operational implications for installation, configuration, training and support.
In addition to cost, real-world experience demonstrates that you may need to alter your system design methodology to take best advantage of component integration. Traditional processes drive requirements through to architecture, and only then are components considered. This approach can lead you to conclude that no component is a "good" fit. Rarely does a component meet 100% of your requirements. As a result, you may decide (in error) to build the capability yourself.
As an alternative, first you may need to identify the components that best fit your needs and adjust requirements and architecture around the components. Always document your decisions and the reasons you're making them, along with any alternatives you rejected. This helps inform the development process and can be of assistance down the road if you need to re-architect the system due to changing conditions.
While it may seem obvious, make sure you specify each data source; data format and meaning (data types and semantics); data transformations (especially when third-party components are involved); and data produced by your system.
It regularly comes as a surprise during implementation or testing that some data item or transformation was not well understood. Usually at the worst possible time--often during integration or acceptance testing--you discover that expected data don't exist, are unexpectedly transformed or are not available. Define the data flow to avoid these hassles, and map data items at each step, especially with component input/output.
Interoperability is the ability for disparate systems to communicate; exchange data accurately, effectively and consistently; and successfully use exchanged information. While interoperability is a hot healthcare topic, it is not a new concept. Many interoperability standards and protocols have been defined along the way. Electronic Data Interchange for Administration, Commerce and Transport and the American Society for Testing and Materials protocol standards are two of the means to define data format, meaning, options and, in some cases, transport level details. In healthcare, Health Level 7 has been around for years as a data exchange standard.
How can you build interoperability into your device or system? The best approach involves analysis and planning to guide development activities. Interoperability planning should involve assessing your system's interoperability needs and capabilities; determining the quality of service requirements; and defining interoperability mechanisms.
Various techniques help identify interoperability needs that focus on defining real-world business drivers, expectations, constraints, challenges and agents of change. Careful future needs consideration will help clarify your business needs and allow these needs to guide your system architecture.
Quality of Service
As care delivery organizations grow to depend on interoperability, quality-of-service considerations take on even larger importance. One system's ability to deliver its expected quality of service will depend on other systems with which it interoperates to provide a corresponding (or known) quality of service. Clearly define quality expectations for your system, and know the quality-of-service commitments of other systems through service-level agreements, certification through an organization such as the Certification Commission for Healthcare Information Technology or published test results from the HIMSS Integrating the Healthcare Enterprise annual "Connectathon" event.
Quality-of-service expectations should include:
* Performance--measured in terms of throughput and latency, where throughput is the amount of data or number of requests that can be handled, and latency is the time between request and response
* Reliability--the degree to which performance is maintained
* Availability--specifies the probability that the system is able to provide the expected capabilities with the expected quality of service
* Integrity-controls interaction correctness. Simple controls such as checksums or cyclical redundancy checking values can validate data correctness. Transaction controls can treat a set of activities as a single work unit.
* Security--specifies transport and data security and integrity, and access control
It's interesting to note that members of the HIMSS Integration and Interoperability Steering Committee found defining the terms integration and interoperability to be "a lot more challenging" than they imagined. They wanted to define the difference between integration and interoperability but, in the end, focused strictly on interoperability. They stated the goal of interoperability as "... the ability of health information systems to work together within and across organizational boundaries in order to advance the effective delivery of healthcare for individuals and communities." For healthcare systems and devices, interoperability focuses on:
* Movement of healthcare data in a way that preserves the meaning and operational intent of the data
* Protection of patient confidentiality
* Assurance of quality of service characteristics
It is best to disentangle integration from interoperability. Remember that integration is done within the context of your system and that it may require you to re-think your approach to system design. Interoperability is inevitable, given the forces driving its need and adoption. Be careful, however, to protect your system investment through proper analysis and planning, and through the correct use of standard software architecture principles and practices.
Tim Bosch is chief architect for the medical division of Foliage, a technology consulting and product development services firm. Tim directs consulting/development efforts and has been involved in several projects. For more information, e-mail Tim at email@example.com or visit www.foliage.com.