In this issue, Peter Ogrodnik’s regular feature discusses the potential issues faced in the digital health market.
The 5G network and satellite communications is about to take off in a big way; it will bring interconnectivity at a scale we would not have dreamed of just a few years ago. Internet of Things (IoT) has the potential to transform healthcare (under the collective banner of “digital health”). The global digital health market is predicted to be $379 billion by 2024 [1] and my previous article described its opportunities for orthopaedics. In this article we examine some of the potential issues that could become barriers to widespread implementation.
IoT is not new: the first device was presented in 1990: a humble toaster [2]. Since then, the public perception is of a world dominated by clever fridges, clever doorbells, and central heating systems controlled by the smartphone. Unfortunately, this has tarnished IoT’s perceived value to medicine. This has not stopped an expansion of devices and sensors that can communicate directly with little or no intervention. These are often called “enabled devices”. Unlike the domestic fridge, however, the integrity of the data must be at the same level as if the clinician, or healthcare professional, were doing the measurements themselves. In instrumentation language, the whole chain (See Figure 1) has to be of “high integrity”. The first point in the chain is the enabled sensor.
The communication device that interconnects the sensor to the point of receipt is an important link in this chain. The temptation is to use a mobile handset, although many see the handset as being outside medical devices regulations, I cannot help but wonder how one ensures high integrity without considering the implications of its use. Any audiophile knows the performance of a high quality HiFi is compromised if one uses cheap wires to connect the speakers to the amplifier. The same concept applies to IoT systems. The information transferred could get modified during the transmission process; this may be due to weak signal strength, to noise, to differences between operating systems, or to the variations caused by different handsets. If it is the patient’s own handset, what happens when, say, Mum calls just as the data from the enabled device is being uploaded? How does the handset decide priority? If the patient is on a pay-as-you-go scheme and has run out of credit what happens to the data? Why should the patient have to provide this anyway? At the moment these problems are difficult to solve. Therefore, many digital health solutions provide a specified handset / tablet / proxy pathway (adding significant costs).
A plethora of communications methods, from broadband to satellite are available but these come with their own issues. If one uses WiFi, how does the enabled device connect? If a generic WiFi provider is to be used, how do we ensure location is not determinable? Your own personal experiences will confirm that 4G is not an ideal solution. In February 2018 the UK was 36th in the league table of 4G coverage [3] (at 77.28 per cent: mostly in urban areas): behind countries such as Lithuania, Estonia and Macedonia. 4G was launched in the UK in 2012 [4], how long is 5G going to take to permeate outside large conurbations?
Furthermore, all of the above demand energy, the very scale of the human body means that the energy source must be small. This inherently means battery life issues. Even the Apple iWatch (with all their skills) has a life of only 18 hours [5]. For short term monitoring battery life may not be an issue, for longer durations, and without alternatives, recharging or changing batteries are the only resort. One only has to think of the humble hearing aid to recognise the problems of changing batteries, and disposing of them afterwards.
These are not simple questions to solve and some could result in social exclusion based on postcode, and even location in said postcode.
Irrespective of the communications method all enabled devices potentially send data to “the cloud”; but where does this data actually reside? In many cases the actual server is so “virtual” not even the host provider really knows where it is. Hospitals will not accept this: there are data laws that they have to abide by. Physical location of the data is a very important consideration. If, and when, Brexit happens [6] the knock-on effect is that EU patient datasets may not be stored on a UK-based server. This could affect EU patients on holiday in the UK and vice versa, and US patients treated outside the US. How will the data be shared and what protocols will be necessary? How does one use big data analysis if the very data itself has been stratified across the globe based on country borders? By inference the EU will, therefore, be a massive data set: twice the size of the US.
Given the background of recent issues with some high profile network providers, should patient identifiable data [7] (PID or PII) be held outside of the care provider? I think not: there is no need. The only two people who need to know the link between the data set and the patient should be the patient and the care provider. Data security will also be an important consideration. For example, can someone break in and find out any personal details, can it be overwritten by a mistake, can someone go in and change the data maliciously? While we are discussing the data set, who owns it? We are not talking about one patient; but thousands, maybe millions. Does it belong to the patient, the company manufacturing the device, the healthcare provider (say the NHS), or the health insurance company paying for the treatment? This data set is valuable. Its analysis could provide prognoses, predictions, and alarms for both clinician and patient alike. Should these datasets be open access for researchers to mine, study and analyse? Should, for example, the NHS take the decision that, for the benefit of the UK’s population, it makes the anonymised data set accessible – and makes that a condition of provision of said service? If this is to be the case, what are the ethical issues?
Finally, the system needs to provide the healthcare provider with a synopsis of the individual’s data. At the moment the trend is that the device provider has its own, dedicated communication system and associated software. If this continues the consequence is that healthcare providers will have an array of servers and services to connect to. This cannot continue. As IoT provision matures it is more likely that a particular hospital, trust or practice will want to sign up to one service provider and they will enforce all enabled devices to connect to that service. This means that there is a need for a unified protocol: as yet these communication protocols are not prevalent [8]. Another overriding philosophy is that the system should be fully immersed in the healthcare provider’s own IT system, such that the data is automatically inserted in the patient’s notes. Even in the NHS these IT systems are multifarious, which makes this aspiration difficult to achieve. The alternative, nightmare scenario for most clinicians is the patient that brings six weeks of data, printed out, to a clinic and expects it to be examined and analysed, there and then. There must be another way.
At the very outset there is another temptation to resist. It is very tempting to have a dataset that covers everything possible, despite the original condition. But does an individual clinician want to take responsibility for data outside their own remit? If one is treating a patient with a neck of femur fracture does one, really, want to see the patient’s ECG? Will this bring with it a new realm of IoT litigation where someone misses a heart condition while treating a fractured limb? This litigation nightmare could happen, and there are examples of this happening with existing technologies.
Finally, this next generation IoT systems will depend on software. Because of the ease of developing and making changes to software there is a temptation to create programmes rather than design them. If you mention IEC 60601 [9] to many software developers they will return a blank look. This cannot be a pathway for slack regulatory practice to enter the medical devices arena. A quick scan of Apple Store or Google Play will reveal thousands of so-called healthcare apps. In late 2017 about 200 healthcare apps were added to the online catalogues every day [10]. A study of more than 40,000 healthcare apps was conducted [11]: of these 58 per cent were shown to have no influence on personal health and wellbeing. Many authors suggest that the regulatory bodies have a lot of catching up to do [12].
There is a clear and present opportunity, but it is one we must look at holistically and not as individuals. There are fantastic, transformational opportunities that remote monitoring brings. But if not conducted with the same rigour that all other medical devices go through, the potential pitfalls are numerous and the damage to their reputation maybe irretrievable.
Peter J Ogrodnik is Professor of Medical Devices Design at Keele University. His opinions do not necessarily represent that of the University, its staff, or its students.
References
- Pharmaphorum (2018), Digital health round-up: Market worth $379bn and still growing, https://bit.ly/2TgTtk6 (shortened URL)
- Postscapes (2018), Internet of Things (IoT) history, https://bit.ly/2y4VvcW (shortened URL)
- OpenSignal (2018), The state of LTE (Feb 2018).
- BBC (2012), UK’s first mobile 4G network. https://bbc.in/2LAcG1E (shortened URL)
- Apple (2018). Apple watch series 4. https://apple.co/2V95Mjy (shortened URL)
- OPN (2019), Are you prepared for Brexit? https://bit.ly/2PTyKmo (shortened URL)
- ICO (2019), What is personal data? https://bit.ly/2TjkHr0 (shortened URL)
- Digital Health Europe (2018), https://digitalhealtheurope.eu/
- IEC 60601-1(2014) Medical Electrical Equipment (note a large series)
- IQVIA (2017), The growing value of digitial health in the UK, https://bit.ly/2UGQyTi (shortened URL)
- Medical News Today (2014), https://bit.ly/2WqmX1n (shortened URL)
- Observer (2018), https://bit.ly/2H6IUx3 (shortened URL)
