I could talk at length about the technology involved in the digital security of telemedicine. From the ins and out of architectures to details of encryption, protocols and much more besides. But of course, the technology you deploy depends on a very particular situation – the risk you face and the data and systems you are protecting.  

So, I’ll get straight to the crux of the matter and begin by discussing customers and their views. I firmly believe that this is a crucial aspect when considering security for any business – whether medically related or not – and needs to precede technical solutions. 

Read more about whether the value proposition of your telemedicine device is clear?

Business is all about customers. An obvious statement, but all too often we don’t start here when we think about security. Patient safety, medical device regulatory frameworks and data protection laws are front and centre when thinking about medical systems. However, security can impact the usability of a system, how and whether it’s adopted and the lifetime over which we can use it. 

And of course, we can’t ignore the possible impact on the reputation of a business when things fail. Across many business sectors we have seen the effects that data breaches have on customer confidence in digital services. We need to gain and maintain the trust of our customers.  

Designing security from the customer perspective  

Firstly, let’s put the discussion in the context of the telemedicine system. Here, I’m thinking about solutions primarily used in the home to enable remote diagnosis, monitoring and treatment of patients. The solution may even include a level of automation, where changes to health or treatment effectiveness are flagged quickly to the physician. 

So, who is the customer for a device manufacturer providing a telemedicine solution? Is it the patient or the physicians who use the solution? Is it the medical facility that buys the solution or the payer that reimburses it? Well, of course they are all stakeholders in the decision to buy or use a new telemedicine system and they all have perspectives and concerns relating to security. They are all customers. 

The patient needs ease of use  

The patient requires a system that is simple to set up and use and integrates easily into their life. This probably means that the telemedicine system needs to link to their existing Wi-Fi hub, phone or other device. This throws up security concerns that we need to account for in our design. How do we ensure security if the system relies on connectivity with devices that are beyond our control? With devices and hubs that may or may not be updated with the latest patch from Apple or Microsoft? How do we make security in this context easy to use?  

Here we should raise the question of trust. Will the user trust the system enough to use it? One aspect we haven’t touched on yet is proving that the system is what is proports to be – i.e. authenticating. It’s an area that gets harder when the patient is remote. Their trust reduces when things come through the post, perhaps from a third party who is not their physician. How are they going to be confident that the product they are going to attach to their body is not fake, or that they are using it correctly? There are technology solutions here that customers are used to – holographic stickers, online tests and so on – but again we need to convince them.   

This brings me to the concept of ‘explainable security’. It’s relatively new, it hasn’t got much further than academic papers yet, but it’s a vital thread in the development of any new security system. In the context of this discussion, the concept boils down to: “It’s no good having the best, most secure system, if you can’t convince your customer base that it’s secure.” You need to be able to explain to your customer what actions you need from them to keep your system secure – you need those actions to be simple – and you need to be able to explain that their data is secure.

At the basic level if we think about security and patient’s needs the answer is simple, I.e. they want their data to be secure. But they also need it to be easy to use and of course here there can be a conflict with some methods of securing a system. Complex passwords, multi-factor identification and such methods make using equipment complicated and for a medical device used by a wide cross-section of our population (many with impairments or less familiar with technology) this can mean it is not useable at all.  

The physician also needs simple, explainable security  

The physician is a key stakeholder, both as a potential champion to adopt (or not) a particular telemedicine solution in their healthcare facility and as the decision maker that prescribes it for their patients.  

Why am I highlighting non-adoption due to security concerns as a risk? Well in similar situations, recent work has shown that the perception of security affects adoption of technology. An example of this is revealed in a PwC report on the Sharing Economy, which is of course built on a digital services backbone. PwC reported that 67% of people would not trust Sharing Economy companies until they were recommended by someone they trust. It isn’t clear whether this is just about safety in numbers or because they don’t understand the concept or how they are protected. But what is clear from the report is that if you want rapid adoption at the start, you will need to get over this hurdle.  

Ease of use is critical to the busy physician. Clearly, they will be concerned about security, but when treatment of the patient is their number one priority, you may find that actions that need to be completed to ensure security get overlooked. So, we need the system to be easy to use, security to be almost transparent to the physician, whilst also visibly assuring them that patient data is secure.  

Health providers need to buy into the numbers 

The healthcare provider (hospital or other service provider) is our immediate customer who will purchase the telemedicine system. They perhaps have some additional security concerns, including reputational risk. Ultimately their decision to buy a system will be driven by the numbers.  

Now more than ever healthcare providers will be alive to security concerns. In recent times there has been a surge of attacks as we move to remote working with healthcare hitting the headlines and being in the top 10 of industries targeted according to Microsoft. Due to this increase in threat, the US Government has issued recent advice to this sector. So, security will be a key part of the decision making on any new system, particularly those with remote connectivity such as telemedicine. 

The equation crunched by healthcare providers revolves around a financial one of reducing the cost of care and an output measure of improving outcomes, or at least not reducing care quality. Security plays into this in a number of ways. Firstly, the purchase cost of the system, so security needs to have the right price tag. The system needs to be easy to support with security patches and updates, so that ongoing costs are minimised.   

Security needs to be effective, otherwise there are downstream cost risks of the recovery of attacked healthcare systems, fines and litigation as a result of security breaches. And they need to be confident that the adoption rate of the system will be high, otherwise the system is an expensive flagship with few patients and physicians using it. So, all the considerations I’ve discussed above all play into the decision making here. 

Security design is complex

I have talked about a number of things that need to be considered when designing a telemedicine solution. I haven’t even touched on the technical complexities or how you think about risk and the appetite your business has for accepting that risk. Taking the viewpoint of our customers in the design of our service makes us think about: 

  • Who are my customers and what are their different perspectives and needs in relation to security? 
  • What do they expect to be kept secure and how will I convince them that my product will do that, so that they are happy to buy and use it? 

  • What’s the user and customer’s role in the security solution? What can they be expected to do to ensure security? What might they get wrong? How do these things affect the design? 

We can’t forget it’s a medical device and we will also need to comply with safety standards. There are bad guys out there, who want to hold systems to ransom, copy your product or just have some fun hacking a system. The consequences of such attacks can be very serious. Data integrity is important in medical decision making and it can’t be compromised by accidental or malicious attacks. Further, if we are considering medical treatment devices and the potential for delivery settings being changed by a hacker then there is a very direct risk of safety being affected.   

But this doesn’t contradict the thinking above… customers also want to be safe too! And the fact that you are meeting a certain standard like HIPAA will add a level of comfort to them as users. Where we do need to be careful is if we drive things solely from such standards and not from the customer’s viewpoint. How do we do this? We have embraced the various customer viewpoints and we need to ensure we build them into our system requirements, in the form of usability needs, security needs and so on. And we need to then work these requirements through a robust systems design process that finds the best balance of these needs with those of the functional requirements.

Security of telemedicine is a complex challenge. But that’s what we like at Cambridge Consultants and we have been designing security solutions in such situations for decades. If you are faced with a challenge like this, give us call.  

Mark Dorn
Associate Director

Mark has worked extensively in the defence, security, transport, industrial and space sectors. He has 30 years of experience in providing technology advice across the product and service life cycle. In digital security, he helps clients understand business threats and their risk appetite, balanced with the cost of mitigation.