In part one of this two-part blog series, we looked at the field of digital health, and how we at eg define it.
I tried to work through the jargon surrounding it and explain precisely what Digital Health products are and where they are going. This part will address some of the things you should think about on your route to market. I am not going to talk in-depth about the regulations or standards, but rather the problems we see, that clients often miss.
If you are considering how to develop a Digital Health product, here are the areas that can be difficult:
CONSIDER THE WHOLE SYSTEM
Often a good idea can be developed in isolation and its usefulness not fully realised. We see this a lot, because often our clients have come up with a great idea from new scientific understanding. Naturally, they concentrate on the clever nugget of potential Intellectual Property that drives the new device. However, considering the whole system leads to a much better, and potentially more valuable, product. For instance, questions such as; Who are the users? How does a user interact with the system? How are they and the clinician (or anybody else important) going to access the results? Would a system be used more or completed better if it has an element of entertainment, progress or reward that engages the user?
This is often called gamification, but really it is part of proper study of Human Factors. Consider social media – not in a forced way, but how it might genuinely help. Could you help your patients and clinicians by developing a network effect and keeping people in contact at critical times? This has become particularly important over the last year, when seeing clinicians and patients face-to-face has become much harder. Considering the Whole System actually helps to tease out all the other pain points…
CONSIDER THE IT SYSTEMS
Hospitals are (quite rightly) paranoid about information security and so putting a device on their networks takes a lot of bureaucracy and time. I have seen big pieces of diagnostic equipment that have sat idle in a clinic for two years waiting to be connected. Because of this, we are seeing devices becoming less reliant on site-infrastructure such as Ethernet, WiFi or Bluetooth to a PC and instead incorporating their own communications using the newly emerging 5th generation (5G) mobile data standards.
This means that devices can be used in hospitals (though some still worry about interference with critical equipment, which frankly should have been designed to better comply with Electromagnetic Compatibility or EMC standards and regulations), local clinics or at home by anyone without having to understand how such gadgets are connected. They communicate with cloud servers rather than Hospital Information Systems which opens up access to clinicians and patients wherever they are. It also means that the data is yours…
OWN THE DATA AND USE IT
A good idea may just be the enabler for a business built on data. This might not be just the clinical data – the rise of social media also means that there is psychological data and treatment. With the rise of machine learning and artificial intelligence techniques, we are getting better and better at extracting information from data; but you need a lot of it and it is valuable.
Sometimes we see people realise, somewhat vaguely, that they need the data and so design a ‘bucket’ into to which they ‘throw’ everything, hoping that clever algorithms (magic!) will sort it all out later. This has significant problems when searching, retrieving and running analyses on such data due to the way computational algorithms scale. Carefully designing your data solution from the outset will reap rewards later as the size of your data grows. Of course, if the data is valuable, it also means that it is attracting regulation (think of the GDPR and ISO 2700x) and potential attacks…
This is a minefield and the rule is, ‘never roll your own’!
There are frameworks and design patterns that can be used all the way up from embedded microcontrollers, through mobile applications, to desktop applications and into server processes. These can be helped by understanding your workflow and data structures early and paying heed to the whole system design. At eg, we consider Human Factors to be essential to the design process and an important basis for considering security.
As I touched on in part one of this article, no-one wants medical devices to be unsafe or insecure (which can amount to the same thing), so there are plenty of regulations surrounding them. It all falls under the umbrella of the ISO 13485 harmonised standard and the main authorities – the FDA in the US, the MHRA and new UKCA in the UK and the Medical Device Regulation and CE mark in Europe.
Depending on the application of the device, there are then other standards that need to be applied, such as ISO 60601 (and the relevant parts) for a Medical Device or ISO 61010 for a diagnostic device, as well as any domain-specific standards. Often hidden, is the extra regulation covering radio devices (cellular, WiFi or Bluetooth) and it is worth understanding these early in the development to allow for testing and certification.
At eg, the route to market is well-trodden. We know all these hurdles and apart from the clinical validation (you will need medical professionals to carry out clinical trials) we can help with the mechanical, electronic and software design (and implementation), regulatory aspects, risk management, technical file preparation and transfer to small-scale or volume manufacture.
Remain part of the conversation. Subscribe to our blog by clicking on the subscribe button at the bottom of your screen!