Connecting an existing diagnostic device to the cloud in a cost-effective way and under tight timescales.
We used limited resources to work within time and budget by using an off the shelf connectivity and Microsoft Azure’s public cloud services.
The diagnostic device is connected to the cloud, sending telemetry data reliably, securely and at minimal cost.
The brief was to develop a proof-of-concept demonstration platform for a future cloud-enabled diagnostic device and add cloud connectivity rapidly and cost-effectively. We wanted to demonstrate that it was possible to send and keep the diagnostic test result in the cloud securely and in compliance with regulatory standards. This allowed us to decide the best approach for the system: collaborate with a third party or invest in a ‘data as a service’ infrastructure.
We wanted to avoid costly and time-consuming datacentre infrastructure to fit within the timeline and budget. Using a public cloud service meant that it would only take minutes to start a custom cloud infrastructure, there would not be any capital expenditure and the ongoing cost would only depend on usage.
Public cloud services also provide security and a privacy compliance framework which could help reduce development and running cost. However, having a public cloud service does not mean that a medical device will be compliant. Even if the device connectivity was built on top of the framework, we still needed to define the data structure, manage the users’ identity and credentials, and control the data accessibility for individual users in order to make the device compliant to relevant standards such as GDPR.
We needed to find an easily accessible and appropriate piece of hardware to fit the existing design. We reviewed the existing system and discovered a serial port which had been previously used during manufacture testing. The serial port could be connected to an off-the-shelf serial-to-Wi-Fi module to connect to the internet and the cloud.
But the connectivity would not work without appropriate software packages integrated to the existing firmware. Therefore, we needed to evaluate which software would support a serial-to-Wi-Fi module.
We investigated different software support systems and checked each one against each hardware specifications. This allowed us to select an appropriate software package and the best off-the-shelf hardware to meet our needs.
For this project, we thought it was crucial to have unique identity and credentials for every cloud-enabled device. In the demonstration platform, we decided to manually generate unique identification and credentials. In parallel, we ensured we highlighted what would be involved to automate this process for subsequent mass production.
Security and privacy of medical devices with enabled cloud connectivity should not be limited to creating unique identification and credentials; it impacts a lot of different aspects of the system architecture. For example, we also needed to keep the unique device identity and credential in a safe place and ensure they would be accessed by the right user at the right time. We therefore had to consider security and privacy from the top down and bottom up.
The solution we came up with enabled us to demonstrate connectivity and security for a future product and at the same time, it helped estimate the effort and cost to develop security in a future product.
