Integration is not Interoperability

There is a tender out from the ADHA for an "Interoperability Framework" for Australian eHealth systems. Apart from the ridiculous timelines for such a wide ranging topic, I have a problem with what they seem to think 'Interoperability' actually is.

Interoperability is NOT the same as integration. It is not just about data transfer and communication mechanisms, but also about how well functional separation is maintained and demarcation of responsibilities. It is a consequence of good design and following the principle of high cohesion and loose coupling. The difference between the two is the difference between speaking the same language and playing well together. The concepts are linked but interoperability covers a much wider space and is somewhat more nebulous.

Integration between systems is a well understood discipline with many well thought out patterns, along with clearly guidelines on when and how each technique should be applied. To support the many (many) applications on the market that don't support modern integration techniques, there are products widely available which abstract the whole communication thing into a mediation layer, acting as a translator between the different units.

But just because you can talk together doesn't mean that you do - or do so effectively. Interoperability is what makes disparate applications work as a system, one that is able to work with other systems into a larger whole. At the lowest level it takes in the concept of workflow or business process management; do you use orchestration or a choreography, where and how is control handed off between components and where do responsibilities start and end. A well designed system, built for interoperability, is able to delegate tasks and accept responses, fitting other systems into its own flow so that tasks are performed as effectively as possible.

A prime example from the industry at hand would be the patient management system in a hospital. There is administration which tracks admission and discharge,  costs and payments, accommodation and feeding schedules. There is also the medical records which track condition, treatment, testing and medication. Both systems need to have a relationship management aspect which are looking at the patient from very different directions. Since doctors tend to also operate their own practices separately from hospitals, we have another set of records, and the government is now entering the mix with the MyHR initiative. Whatever happened to the principle of a single master source for data? The problem is that none of these systems has the capability to delegate responsibility for record keeping to another system - a proper CRM which is designed to track any and all interactions with an individual. Each is built to be self-contained, which is fine, and has no ability to interoperate when necessary, which is not.

Loose coupling between components of a system would allow it to disable the internal store and plug into an external module as and when required. It would allow workflows and processes to be handed off to sub-systems or associated applications and the results re-integrated once complete. This is the mindset behind the current approach of micro-services and composed applications. Unit design and interchangeable parts have been standard in the manufacturing industry for a century but IT is only just coming to grips with it.

That is interoperability.