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 involved 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.
