Blog: IS YOUR NEXT MEDICAL DEVICE AN EDGE DEVICE?

IS YOUR NEXT MEDICAL DEVICE AN EDGE DEVICE?

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, flemming.von.holck@glaze.dk, +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.

Glaze IoT Cloud Project Process

Beacon Tower is Glaze’s Industrial IoT Cloud Platform that can act as either a stepping stone (Platform-as-a-Service, PaaS) or as an out-of-the-box solution (Software-as-a-Service, SaaS) for collection of IoT-data.

Beacon Tower resides in Microsoft Azure and is designed as a customisable and cost-effective IIoT Cloud Platform that helps simplify deploying, managing, operating, and capturing insights from internet-of things (IoT)-enabled devices. Our customers have the full ownership of their data.

When running it as a PaaS we utilise the design and can run it on our customers’ Azure tenant and customise it fully to their requirements.

Beacon Tower connects to all sensors, PLC, DCS, SCADA, ERP, Historians and MES to gain maximum automation flexibility and ​prevent vendor lock-in.

For more information visit www.beacontower.io or read the PDF.

Edge Computing Categories and Questions

Device:
o Sensors
o Internet connectivity
o Battery consumption
o Field Gateway
o Communication protocols (HTTP, AMQP, MQTT, Gateway)
o Format of the telegrams sent to the cloud (JSON, Avro, etc.)

Data:
o Number of devices & number of signals
o Amount of data to transfer per day
– Event-based or batched or mix
– Transfer rate (every second, minute, hour)
o Device timestamps
– Synchronized timestamps with cloud or not
– Local buffering on device, late and/or repeated data
o Any time-critical notifications / alarms
– Latency expectations for non-time critical data
– Alarms generated by device and/or by cloud platform
o Cloud-to-device messages & commands
o Analytics
– Results from time-series data / Streaming analytics
– Analytics workflows on data, machine learning etc.
– Edge analytics / intelligence

Cost expectations:
o Retention periods (for reporting purposes)
o Aggregation of data, possibilities for cost saving

External integrations:
o Reference data / online data

Administration, rights and access:
o Requirements for multi-tenancy (segregated owners)
o Owners/tenants and operators/technicians
o Administrating access to data, auditing use
o API management, consumption of data, 3rd party integrators

Operation:
o KPI measurements for device
o KPI measurements for cloud platform
o Requirements on operators and SLA’s

User-interfaces and functions:
o Operators/technicians
o Customers/end-users

Glaze Business Innovation and Development Framework (BIDF)

1. Strategy

Creating an IoT Strategy that aligns with the existing company strategy and/or points out any discrepancies that needs to be addressed. The IoT Strategy should pinpoint type of IoT opportunities that should be sought and how they can support the Company delivering on their overall strategies.

2. Ideation

The Ideation phase is an innovative and creative phase where we identify the IoT opportunities within the company. This is done by using existing assets, industry expertise, industry analysis, strategy and IoT expertise to find opportunities for IoT endeavors. This is done in an structured but open-minded and creative setting.

3. Refinement

In Refinement the opportunities are detailed, prioritized and evaluated in a series of steps with the goal of finding a short list of initiatives the company want to pursue. These steps takes strategy, competence, risk level, customer maturity etc into account during prioritization.

4. Valuation

The short list of opportunities are detailed even further and business cases are created for each of them. This will lead to a decision which opportunity to pursue further.

Moving on from the Business Innovation phases to Development activities we focus on taking the minimum possible risk of building the wrong solution by using agile development practices.

5. Exploration

Proof of Concepts carried out in this phase in order to map out technology as well as user-oriented risks. This also refines the budget and thus valuation and business case. Also giving valuable input to baseline system architecture and eco system involvement.

6. Planning

Moving to Planning phase, the most promising business case has been selected and now it is time to plan the Minimal Viable Product (MVP), in terms of timeline, resources and detailed design.

7. Foundation

Implementing the baseline architecture, toolchains and most critical points of the project.

8. Development

Full MVP is developed using these three principles: Start small, don’t over-engineer; Agile software development – late changes welcomed; Continuous delivery – every change is immediately visible.

9. Operations

Operations in an IoT-project is more than just keeping the product alive. It is life-long updates and continous sharpening of features and business model, meaning new ideas are fed back in the Innovation and Development Framework.

Heat map example on a typical business case: