The path to successful telemedicine system architecture

Telemedicine is where telecommunication and healthcare converge. They are two industries clearly characterised by differing, competing and conflicting needs. This presents hurdles, because creating the architecture of an effective telemedicine system means bridging the sizeable gap between two very particular sets of design approaches, technology choices and development lifecycles.

In this article – the fourth in our series exploring the accelerating global prevalence of telemedicine – I’m going to plot the pathway to successful system architecture in this increasingly competitive space. My overriding message is simple. It is essential to think broadly and adopt an approach that considers the entire ecosystem. In architectural terms, this is a system-of-systems perspective that embraces the wider domain that must be understood if we are to answer the needs of all stakeholders.

Crucially, this approach will ensure that the system reflects the potential of the service, rather than a service that reflects the limitations of the system. Let me explain, starting with telecommunication and its associated needs: availability, scalability, flexibility and security.

Telemedicine applications that primarily act as communication and data management systems to provide healthcare services will not be radically different from, say, home banking applications. They are however subject to additional regulations, such as HIPAA, and need to take issues like data sovereignty into consideration. But they are not themselves Medical Devices in the strictest sense. It is only once you start adding diagnostic or therapeutic functions – that is functions with a specific medical purpose, for which safety and efficacy must be demonstrated – that things get interesting. This applies for the patient and clinicians but also for the manufacturer.

Systems evolving over time

Telecommunication systems, like all infrastructures, are live systems that evolve over time. They are designed for flexibility, highly modular in nature and based on a multitude of standards to allow for interoperability and in-service upgradability. Think of them as ancient wooden sailing ships. By the time they are decommissioned, they don’t have a single plank of original wood, with the exception of maybe the keel. Telecommunication systems morph. Their longevity, and hence their value, is heavily influenced by their architecture and their ability to allow for change along multiple axes: technology, scale, and their (digital) environment to name a few.

The primary needs of healthcare are safety and efficacy. And unlike in telecommunication, medical devices tend not to change whilst in-service. They are designed, and thoroughly validated, for a specific set of use cases and a specific, often controlled, environment. Their architectures tend to be more monolithic, as they are seldom upgraded in parts. Upgrades are provided with new generation devices, not incrementally and not frequently. Safety, which is paramount, favours tried and trusted approaches. I cannot readily think of any digital technology that was specifically developed by the medical industry. But examples from the telecom world are of course plentiful.

What I just described is stereotypical. But it highlights a mindset of manufacturers, regulators, and users that can be a barrier to the development of telemedicine systems if not addressed. Yes, there are obviously a number of successful telemedicine systems that incorporate Medical Devices or connected Medical Devices, but the industry is still in a pioneering phase.

Consider it as an ecosystem 

The architecture is certainly one of the success factors of any system and becomes more important as we move up the complexity scale. The first questions to be asked when designing an architecture are what is my system? What are the boundaries? This is not straightforward with telemedicine systems as what delivers value to patients, healthcare providers and manufactures is not necessarily the same thing.  

As I said at the outset, a telemedicine system, or indeed any connected device, needs to be considered as part of an ecosystem. With the problem of boundaries out of the way and a good knowledge of the ecosystem established, we can address the key requirements that are the responsibility of the architecture. These are qualities such as scalability, availability, flexibility, security and safety but also aspects like the lifecycle and compliance to potentially different regulatory regimes.  

The most common best practice is partition of the system, not just along technical boundaries, but also regulatory and lifecycle boundaries. What part of our system do we want to be able to upgrade? Why? How? Which functions are subject to which regulations? Can we ringfence the medical functions related to safety and efficacy to minimise regulatory burden, hence cost and effort, not just for the first release but for future updates as well?  

We also need to look ahead to the future. Can we draw a roadmap and stage the development? When there is too much emphasis on ‘version one,’ the lifecycle aspects often become secondary, with the risk of paying the price later. Devices usually only need updating due to parts obsolescence, but services need more frequent updates. Security for example, is reactive to threats from the environment. When updates are necessary, they need to happen fast. 

Different stakeholder needs 

There are additional considerations when we take a data view of a telemedicine system. Broadly speaking, there are a number of categories of data involved in a telemedicine system. Examples include medical data (personal information, images, results and so on), usage data (how and when a device or service was used), technical data (performance of parts, faults), software images and settings (software is data).  

All of these data types provide for different stakeholder needs. They pose different risks, if lost, corrupted or stolen, and are subject to different regulations – all of which may change and evolve over time. Because of this, partitioning communication channels, storage and processing based on an understanding of data will lead to better – that is, more valuable – architectures that can be quite different from those developed when only considering function and efficiency. 

We now have an architecture, but an architecture is not just a block diagram. It is the output of a process that relates high level technical decisions to stakeholder needs prioritised by their relative value. You can’t please everyone all the time, as the saying goes. In my opinion, those relationships need to be explicit, and ultimately stated in a way that stakeholders can understand.

In the medical industry this is standard practice for properties like safety and efficacy which need to be explicitly demonstrated to the regulators. But the same principles can be powerful tools when applied to other properties like security or scalability. What is the value of security, or rather a specific security architecture? How is it better than that of competitors, and how can that ‘better’ be translated into value? As my colleague Mark Dorn highlighted in his recent article, security can be a discriminator for your offering in the same way as safety.  

If that value is not understood by the stakeholders, then your solution will not be adopted so easily. Likewise, if you do not understand the relationship between technical choices and value you are at risk of creating costly overengineered solutions, with features that are in there ‘just in case’. Even worse, you run the risk of developing something that ‘kind of works’ technically but is actually missing the point entirely. Food for thought I hope – and do email me if you’d like to continue the conversation.