There are some rather obscure definitions of health IT’s favourite term interoperability floating around, for example:
Wikipedia: Interoperability is a characteristic of a product or system, whose interfaces are completely understood, to work with other products or systems, at present or in the future, in either implementation or access, without any restrictions
Cambridge dictionary: the degree to which two products, programs, etc. can be used together, or the quality of being able to be used together.
These definitions are not wrong, but don’t quite capture the whole picture. First we need to clear up one thing, which is the question of semantic interoperability, often distinguished from syntactic interoperability. The former is usually understood as the ability of systems to share meaning, or similar, while the latter just means they agree on how to share data or API calls concretely. For healthcare IT, and indeed most industries, the only interesting interoperability is the semantic kind; if you have not achieved that, there is more work to do. So here, ‘interoperability’ means ‘semantic interoperability’.
The following is my definition.
interoperability (def): the level of interoperability between distinct components of an information processing environment (applications, services, systems etc) is proportional to their ability to correctly communicate their internal semantics to each other, without special measures, other than syntax or technology adaptation.
There may be some debate as to the extent to which the internal semantics of any component should be exposed to the external world. I would argue there are no semantics of any system that meaningfully remain hidden: if they are a valid part of the component’s design, they will appear somewhere in the exposed data or communication protocol of that component, otherwise, what are they doing there? Even systems that are essentially sinks of complex data (say, census records) and generate only aggregate statistics need to have their raw data visible to administrative-level tools. If they don’t, no-one can verify if the system is performing correctly.
So we are interested in the extent to which internal semantics – the domain models of the component – are understood by other components, without doing any special work other than technology or syntax transformation.
The only way this can occur is if the internal semantics of communicating components are common, which is achieved in two ways:
- private standardisation, i.e. the components are developed by the same organisation based on common models, or;
- public standardisation, i.e. the component developers independent adhere to common semantics and models published by third party/ies.
What we typically observe is that a very small fraction of the total semantics understood inside a component is directly comprehensible by other components not built by the same vendor.
The publication of ‘standards’ – de jure or de facto – is meant to improve the situation, based on the assumption that the products of vendors who implement the standards will communicate better than those which don’t. (I will avoid going down the rabbit-hole of what a standard is by referring to this post).
There are many implicit questions here. Firstly, standards for what? Common models? This does happen in telecommunications, and is what enables the mobile network, satellites and audio-visual systems to work properly. These standards may be understood as architectural, as they will define significant internal elements of the products based on them.
In health IT however, the main standards we have are for specific utterances rather than common models, i.e. use case specific interactions or messages, rather than general models of meaning (the exception is terminology, which is significantly standardised). Specific utterances are sentences, compared to common models, which are the language. Since the number of possible utterances transmittable by non-trivial systems is generally very large, standardisation by this means is very inefficient, and most likely non-scalable – at the best, it involves monotonically increasing work.
To obtain true interoperability, we need to build components based on common domain models and languages, not private ones. This may be understood as a open platform architecture. Then all possible ‘sentences’, i.e. specific messages and API calls will all be understood automatically. Via this method, interoperability is an emergent outcome rather than an post hoc attempt to reverse engineer a common language from and endless pile of sentence specifications – what I term the message mentality.
But how can domain models and languages be defined and shared? In health IT, these include things like:
- common information models, i.e. clinical data types, basic structures to represent observations, orders, actions, documents etc;
- domain definitions, formal representations of domain semantics:
- terminology, i.e. formal representation of ontological aspects of the domain, i.e. invariant truths, particularly the taxonomy of natural kinds;
- content models, i.e. definitions of information that is created due to particular business activities, such as taking a blood pressure, reviewing a diabetic patient, ordering a medication;
- process and reasoning models: care pathways and guidelines, consisting of plans and decision logic for best practice in care over time.
- languages of representation of domain definitions.
The first and last are technical concerns, and require the input of both domain and IT professionals. They are also the basis of software – tools, platform back-ends and applications, which if built correctly will consume domain definitions, i.e. the middle three. These artefacts may be built by domain experts using tools based on the two technical items. Ideally, these are consumed at runtime by deployed software, enabling such systems to continually track the domain rather than ossify into obsolescence, as is the usual case today.
This has been our project in openEHR for 20 years. It has been inspired by collegues in many places, and today, newer standards projects such as BPM+ are starting to work on the platform + models basis, via which interoperability is an automatic outcome.
wolandscat
Woland's cat 
It is good to think about what is needed in Health IT. For some the goal is semantic interoperability, but perhaps even this is not enough.
Thomas’ article tries to define ‘Interoperability’. Hellas he uses the term to be defined in the definition.
My take: ‘the faculty of two or more (health-)(IT-) systems to exchange data between two or more collections of data’.
An other thought is that ‘Semantic Interoperability’ is not enough when healthcare providers co-operate en exchange there data stored in IT-systems. What is needed to tale into account the context, the epistomology, of the data in each documenting system. What is needed is ‘Interpretability in IT’ defined as: ‘the faculty of two or more workers to understand correctly the data in each others documenting IT-system’.
This implies that on top of the list of standards we need, it is necessary to fully define data in their full context, but also that we need uniformity about the generic as[ects of the documenting process and the complex process of the provision of healthcare and the terms used.
I agree of course about the ‘interpretability’ thing, i.e. I think we should treat anything less than ‘System B understands system A’s message the same way system A did when it wrote it…’
I really like this (excellent) post, particularly the use of the phrase “specific utterances” to differentiate between the nature of health information concept representation and the standardized “transactions” that exist in other more structured business sectors. I hope I can be forgiven for “adopting” this expression myself.
And Gerard, I think your additional and meaningful nuance is important although, in my own definition, interoperable assumes… no, demands, interpretable. And this requires additional contextual data or meta-data that ultimately should be machine interpretable, however I fear that sets a very high bar across the vast spectrum of “specific utterances”.
For now, at the very least, I would settle for safely and reliably interpretable by persons using the data in contexts and roles that are likely different than the ones in which the data was gathered.
I agree with your definition, which has always been a goal of the semantic web but has not quite succeeded in anything other than terminologies and hierarchical ontologies using DL axioms. Interoperability for me requires a seamless syntactic and semantic data exchange between two different systems or apps. De facto and open standards are accepted as long as the affected market players dont see them as a threat for their business and/or they are complementary to proprietary data, Interoperability in my view can therefore only be truly accomplished when customers demand it from vendors. Are we in that scenario yet regarding health it, or is it still easier to lean on old trusted habits? Patients (we) have a lot to say in this, in my opinion.
Good question: but to demand the right kind of interoperability – e.g. models + platform-based automatic interoperability – you have to know what is possible. Most customers in healthcare have been conditioned to think that interoperability = messages (utterances / sentences, in the language of this post). They don’t realise that there is a far better alternative. They are also locked into vendor products, and the semantics are currently locked inside those, so there is a long way to go in healthcare to realise the benefits available from even quite mainstream technology.
You are right. There is reason for hope however, as we are now in a turning point, due to (a.o.) the emergence of genetic therapies and precision medicine, that will increase the size and heterogeneity of medical data; the increasing demand for health-anywhere, without institutional barriers, or the realization of patients that they need to “own” their medical records. All of this will cause pressure and unbearable costs for healthcare institutions, that need to be addressed today better than tomorrow. In that sense, it is probably a good moment to review the strategy.