People like to lament interoperability standards for not meeting their expectations. It’s easy to understand why when you look at the way interoperability standards are marketed with promises to do everything from reducing costs to solving world hunger.
Most people expect the standard they are implementing to help them achieve the holy grail of interoperability, “…the ability of two or more eHealth systems to use and exchange both computer
interpretable data and human understandable information and knowledge.1” The first part in managing expectations is understanding that there are different factors impacting interoperability and there isn’t a single standard that can address them all.
The diagram published by eHealth Standards and Profiles in Action for Europe and Beyond, does an excellent job of explaining the different interoperability dimensions from technical, to semantic, to organizational.
Technical interoperability mostly focuses on the ability of computers to exchange information. The Open Systems Interconnection (OSI) model describes the 7 layers of standardization required for computers to exchange information – from the first physical layer through to the seventh application layer, which is where HL7 gets its name from. Technical interoperability is extremely important but insufficient if we want systems that meet broader health care goals like the triple aim of care.
Simply put, the triple aim of care is about improving the health of the individual, the health of the population, and reducing per capita costs of care. Achieving the triple aim requires semantic interoperability. Semantic interoperability means the different components of the system can use the data they’ve exchanged.
Semantic interoperability requires both structured data (e.g., a commonly understood data model) and codification of the data (e.g., value sets, vocabularies, etc.) to be exchanged. However, data models and value sets alone are insufficient to achieve semantic interoperability because they lack context. To achieve semantic interoperability also requires common understanding of the clinical procedures and medical guidelines used in the provision of care, and thus the data about that care.
This is where there tends to be misalignment about expectations of interoperability standards like HL7. None of the HL7 standards can dictate clinical procedures and best practices to be used
throughout the world. Nor can they restrict the valuesets and vocabularies for every possible concept used in the administration and delivery of care. Anyone expecting a single standard to do this is going to be disappointed.
Designing and developing semantically interoperable systems is tough, but getting people from different organizations to use them can be tougher. Our industry has made great strides in adopting best practices in change management and clinician engagement that address the willingness and ability of individuals to use these systems, but we have a long way to go in addressing barriers at the organizational level.
The term organizational interoperability refers to the willingness and ability for organizations to exchange data. It addresses the fact that organizations can operate in different ecosystems of legislations, policies, and procedures that impact system design and use. Far too many projects leave organizational interoperability until the end of the project lifecycle or don’t address it all, deferring it to therealms of programs and operations.
The challenge with this approach isthat reaching stakeholder consensus on organizational interoperability topics can take just as long as gaining consensus on the factors impacting semantic and technical interoperability. The end result is systems go live with a minimal set of early adopters, followed by long periods of little to no additional adopters. Idle systems that don’t deliver promised benefits within their touted timelines is far too common in our industry.
Addressing organizational interoperability is of particular importance for systems integrators. For these organizations, negotiating unique agreements (e.g., data sharing, service levels, privacy, funding, etc.) with each organization that contributes and / or consumes data is equally as unmanageable as supporting point-to-point interfaces. If you look at the number of IT staff
compared to the number of legal staff within most organizations, one could argue that maintaining point-to-point interfaces might even be easier.
Recognition of the importance of addressing organizational barriers to interoperability is rising. It is a key aspect of the US 21st Century Cures Act, which calls on the Office of the National Coordinator (ONC) to help develop a “trusted exchange framework, including a common agreement among health information networks nationally.”
Australia’s recent RFP for a Strategic Interoperability Framework Strategy asked respondents to consider organizational interoperability concepts because “…defining, developing and measuring the success of a system’s digital health maturity requires a range of interoperability considerations beyond its technical underpinnings.”
Interoperability is hard, and there is an expectation that standards will solve it. Examining the multiple dimensions of interoperability explains the variation in digital health solutions implemented across the country and how standards can only address aspects of the complete set of interoperability challenges. With expectations properly calibrated, more projects can be scoped to address the complete set of interoperability barriers and help ensure IT systems deliver their benefits as quickly as possible.