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.
