Looking at the regulations and standards, that must be followed when designing a Medical Device, it may seem impossible to use Cloud Services and IoT for this. After all, IEC 62304, IEC 82304-1 and ISO 13485 are all very rigid when it comes to configuration management, version control, management and a range of other areas. The whole concept behind the software standards 62304/82304-1 is a stand-alone device with explicit functionality limited to measurement of something, e.g. a vital parameter, such as ECG. Moreover, the standards not only cover the functionality of the Medical Device, but also the design and development process.

And yes, it is indeed a challenge to use Cloud Services and IoT in a Medical Device.

But what exactly does a Medical Edge Device involve?

There are at least 3 possible scenarios for a Medical Edge Device. It may
•    Use the Cloud as a Device Management Platform
•    Use the Cloud as a Data Collection System
•    Use the Cloud as an Integrated Part of the Software System

Let me explain this further.

Using the Cloud as Device Management Platform

The architecture for this, using Microsoft Azure IoT as example, is called Azure IoT Edge. Microsoft is focusing a lot of resources on this and has a system, that works very well (and yes, we have it running).

Off course, you need to build your infrastructure to support it, but it is possible even on small embedded devices running variants of Linux.

The advantage of this is primarily three things:
•    You have a housekeeping infrastructure for software updates, patches and recalls
•    You have access to your Medical Edge Device usage and performance (part of your post marketing surveillance)
•    Analysis of collected data from the Edge will give insights on how to improve the software

On the other hand, you need to control mainly two things:
•    Configuration Control of development tools
•    Configuration Control of SOUP components

Control of your configuration of SOUP components will require focus. Your architecture and segregation strategy has to support this.

And you also have new challenges, which should not be underestimated
•    Registering, provisioning, of new Medical Edge Devices on the Cloud Platform
•    Secure data from measuring on the Device to deletion in the Cloud

Off course, all major Cloud IoT providers have solutions for provisioning – some more mature than others. Azure IoT Hub Device Provisioning Service is an example of a powerful solution.

Depending on your volume of Medical Edge Devices and level of security, securing data requires different, mostly established and proven strategies. For example, securing safe transmission from sensor to cloud has well known solutions from the industrial area.

Using the Cloud as a Data Collection System

Collection of results in a Cloud database is not particularly interesting in the context of this article, as the “intended use” of this typically does not fall under the definition of a medical device.

Using the Cloud as an Integrated Part of the Software System

This is where it becomes difficult. But why would you want to do this?

•    You may have an analysis algorithm, that requires more resources than your device provides
•    You may want to utilize the Interfaces of the Cloud Architecture
•    You may have a business model that requires online access

In the world of real-time units like ECG and SpO2 monitors, pacemakers, Cardiopulmonary bypass machines (heart-lung machines) or anesthesia workstations, this does not make any sense. The speed and reliability of internet access to the Cloud is not guaranteed. Possible delays conflict with the need for fast response time.

However, for devices that measure, analyze and report (diagnose) in a sequence that takes minutes, the Cloud Architecture does provide some obvious advantages. Examples of this are blood analysis and heart and lung abnormality detection devices. Typically, In Vitro Diagnostics (IVDs) devices fall in this category.

But are you able to move the very heart of this diagnostic device to the Cloud. Has it been done? Is it possible?

Yes – it does seem possible. And yes – it has been done.

Figure 1, Monitoring using Azure IoT, click for info.

Microsoft references a monitoring case (digilog) where Azure IoT is used as basis for the off-line analysis.

Figure 2, Spectrometer using AWS, click for info.

The RND Group references a spectrometer solution using Amazon Web Services.

Figure 3, Flex and Google collaboration, click here info.

Even Google has a reference with a Medical Edge Device (or at least the architecture for it).
Also, the vast range of healthcare apps could be argued to fall in this range (although most of the have not been registered as Medical Devices).
And yes, it is possible to get a Cloud Based Architecture FDA cleared.

Figure 4, Cloud DX, click for info.

“Pulsewave is a unique “pulse acquisition device” that records up to 4,000 data points from your radial artery pulse, then securely transmits the raw pulse signal to our Cloud Diagnostics servers, which display nearly instant results: Heart Rate, Blood Pressure, Pulse Variability, Average Breathing Rate*”.

Having the fundamental issues regarding configuration control of Development Tools and SOUP components and provisioning of Medical Edge Devices addressed, the remaining issues can be related to risk management. Examples of these issues are:
•    What offline functionality is required?
•    How do we ensure data integrity in communication of the result?
•    How do we mitigate unknown behavior of the Cloud platform?
It will be interesting to follow how well the Medical Device Community will adapt all the new exciting possibilities and how this will impact the traditional business in the Medical Device market.

More information:

Glaze Partner Flemming von Holck,, +45 30 66 30 61

Positioning technologies currently applied across industries:

Global Navigational Satellite System: Outdoor positioning requires line-of-sight to satellites, e.g. GPS: the tracking device calculates its position from 4 satellites’ timing signals then transmits to receiving network
–    via local data network, e.g. wifi, proprietary Wide Area Network
–    via public/global data network, e.g. 3G/4G

Active RFID: A local wireless positioning infrastructure built on premises indoor or outdoor calculates the position based on Time of Flight from emitted signal & ID from the tracking device to at least 3 receivers or when passing through a portal. The network is operating in frequency areas such as 2.4 GHz WiFi, 868 MHz, 3.7 GHz (UWB – Ultra Wide Band), the former integrating with existing data network, the latter promising an impressive 0.3 m accuracy. Tracking devices are battery powered.

Passive RFID: Proximity tracking devices are passive tags detected and identified by a reader within close range. Example: Price tags with built-in RFID will set off an alarm if leaving the store. Numerous proprietary systems are on the market. NFC (Near Field Communications) signifies a system where the reader performs the identification by almost touching the tag.

Beacons: Bluetooth Low Energy (BLE) signals sent from a fixed position to a mobile device, which then roughly calculates its proximity based on the fading of the signal strength. For robotic vacuum cleaners an infrared light beacon can be used to guide the vehicle towards the charging station.

Dead Reckoning: Measure via incremental counting of driving wheels’ rotation and steering wheel’s angle. Small variations in sizes of wheel or slip of the surface may introduce an accumulated error, hence this method is often combined with other systems for obtaining an exact re-positioning reset.

Scan and draw map: Laser beam reflections are measured and used for calculating the perimeter of a room and objects. Used for instance when positioning fork-lifts in storage facilities.

Visual recognition: The most advanced degree of vision is required in fully autonomous vehicles using Laser/Radar (Lidar) for recognition of all kinds of object and obstructions. A much simpler method can be used for calculating a position indoor tracking printed 2D barcodes placed at regular intervals in a matrix across the ceiling. An upwards facing camera identifies each pattern and the skewed projection of the viewed angle.

Inertia: A relative movement detection likewise classical gyroscopes in aircrafts now miniaturised to be contained on a chip. From a known starting position and velocity this method measures acceleration as well as rotation in all 3 dimensions which describes any change in movement.

Magnetic field: a digital compass (on chip) can identify the orientation provided no other magnetic signals are causing distortion.

Mix and Improve: Multiple of the listed technologies supplement each other, well-proven or novel, each contributing to precision and robustness of the system. Set a fixpoint via portals or a visual reference to reset dead reckoning & relative movement; supplement satellite signal with known fixpoint: “real time kinematics” refines GPS accuracy to mere centimetres; combine Dead Reckoning and visual recognition of 2D barcodes in the ceiling.

LoRaWAN: A low power wide area network with wide reach. An open standard that runs at unlicensed frequencies, where you establish a network with gateways.

Sigfox: A low power wide area network reminiscent of LoRa. Offered in Denmark by IoT Danmark, which operates the nationwide network that integrates seamlessly to other national Sigfox networks in the world.

NFC: Used especially for wireless cash payments.

Zigbee: Used especially for home automation in smart homes, for example. lighting control.

NB-IoT: Telecommunications companies’ IoT standard. A low-frequency version of the LTE network.

2-3-4G Network: Millions of devices are connected to a small SIM card, which runs primarily over 2G, but also 3G and 4G.

Wifi: The most established standard, especially used for short-range networks, for example. in production facilities.

CATM1: A low power wide area network, especially used in the United States.