The market for the internet of things in the medical field is growing rapidly, with innovative applications ranging from remote medical data monitoring to medical adherence. Medical IoT devices represent the next generation of smart connected medical solutions.
Here are some ideas to help you develop your next IoT healthcare device
The development of connectivity infrastructures and the maturity of cloud solutions and big data processing algorithms have been key in the development of IoT in recent years. This trend, which was initially technological, has become social with an impact in all fields and in every aspect of our daily lives.
IoT initially had the greatest impact and visibility on consumer markets with issues mainly relating to the Data/Cloud aspect. A lot of connected objects were developed; fairly basic things with low constraints (security, environmental, etc.).
In recent years, the IoT trend has opened up new perspectives in more industrial and/or professional fields, such as Smart Building, Smart Factory, and Connected Vehicles. This added a Device aspect to a mainly Data/Cloud-oriented aspect due to specific security, reliability, and interoperability issues which are much more critical than on the consumer market.
The medical IoT devices principle involves sharing large volumes of data which is then analyzed and processed in the cloud and correlated with data from other devices by Big Data processing algorithms. By crossing large volumes of heterogeneous data value can be created through creating new uses or providing services or solutions that would not otherwise be available. For example, in the medical world, a correlation between diagnostic data from medical devices and statistical data on lifestyles, climate, pollution, etc. could be considered.
This approach automatically entails device connectivity, information sharing, information flow security, and interoperability between different devices via machine-to-machine communication functions. These features and aspects are not ‘naturally’ integrated into medical devices; therefore, they need to be adapted to the specific issues of the medical market.
Standards and Patient Safety for IoT Medical Devices
Maximize project feasibility by isolating critical features in your medical IoT device project
Although it is evident today that software is present in the medical world, the development of a new medical system incorporating software may seem quite daunting.
It is important to keep the challenges of such an approach in mind to be able to assess the feasibility and viability of such a project. The main issue that needs to be considered is the need for a system to comply with the medical standard essential for any marketing.
All medical IoT devices must be developed in accordance with the ISO 13485 standard. Here we will review the IEC 62304 standard which focuses on the software development part. Analyzing system criticality is a key issue. By means of a risk assessment, the product must be classified from low criticality (class A, low patient impact) to high criticality (class C, high patient impact, even risk of death).
If you are not familiar with this approach, various firms specializing in standards will be able to help you. The software development effort required for a low criticality product and a product requiring a Class C certification is very different. Where class A is very focused on documentation and monitoring developments post-production to incorporate risks subsequently discovered, class C requires greater effort, such as very thorough software architecture testing and accurate documentation with follow-up requirements through architecture, code, and validation.
Once the criticality has been identified, hardware and software architecture solutions to facilitate software development and limit costs can be studied.
Several approaches are possible:
Develop all necessary software for the product in the requested class.
This may be possible for a very basic product or a product in a low criticality class. When product’s features are more sophisticated, and especially when connectivity is introduced, it can quickly become tricky. If criticality is high, it will certainly involve long and complex development, architecture, documentation, and tests, which can quickly become expensive.
Isolate hardware features with a major risk.
This approach usually consists in providing a microcontroller dedicated to critical features (or critical checks) with a very small software code facilitating certification. The other features can be implemented on another micro-controller (or microprocessor) with a lower criticality class. This minimizes development efforts. This second architecture opens up the field of possibilities for connectivity and the development of interfaces similar to those that found on other markets.
Isolate software features with a major risk.
The approach described above can have a major impact on the electronics, and therefore on the BOM (Bill of Material), size, power consumption, etc.; the project’s viability may be called into question.
A similar approach can, therefore, be applied to software.
This entails implementing a software program called a hypervisor which allows you to isolate different software environments. The principle is to guarantee that the various software running in parallel will not be able to interact outside an agreed framework (no voluntary or involuntary contamination possible outside a framework provided in the specifications, no memory overflow).
Critical functions can, therefore, run in a secure environment because the software layers that manage connectivity and data transfer to the cloud are running in another software environment. The hypervisor manages secure data transfer between the two environments.
This hypervisor will need to be certified in your product’s class, and its certification allows you to certify the entire software system.
Once this analysis and decision phase has been completed, you will have a clearer vision of the feasibility and issues of your project. Then, data security needs to be added to this safety vision.
Data security for medical IoT devices, action on several levels
As we have seen, the implementation of IoT scenarios in medical IoT devices involves the coexistence of two universes that sometimes have conflicting issues and pre-requisites.
On the one hand, an IoT solution implies the provision of as much information as possible, and thus the openness and connectivity of equipment between it and the cloud. On the other hand, this information concerns the health of individuals and entails security and confidentiality constraints that are not compatible with a logic of strong connectivity, openness, and data sharing.
Several technological building blocks can be implemented to ensure that your IoT medical device architecture is robust while integrating connectivity solutions for secure information sharing. The relevance of these solutions must be validated by system architecture expertise with a sound understanding of technological stakes.
Each project has its own issues. The technological choices and solutions implemented will differ according to the medical devices concerned and the connectivity and information sharing scenarios envisaged.
Secure the software system of your medical IoT device
Secure boot of your next medical IoT devices.
The first way to secure your system is to set up a multi-level boot system called a chain of trust.
Hardware, bootloader, system, or business application, through an asymmetric public key / private key cryptography system, each link signs and validates the authenticity of the next link before starting it.
Therefore, in the event of a non-genuine key problem, the processor stops booting and defaults the system.
This approach makes it possible to guard against the installation of counterfeit software which would pose a major security risk.
Provisioning and root of trust
In a connected system, securing exchanges is paramount; therefore, a provisioning mechanism is used. Certified keys are written into the product during its manufacture. These keys allow the cloud to identify and recognize hardware; they prove its identity, and the cloud can trust it.
Conversely, the product has to trust the cloud server. We use security mechanisms, such as https, that prove the server’s authenticity.
This security, integrated into the manufacture of the product, requires a root of trust to be established with certificates giving authority to your factories and subcontractors, for example, and allowing you to revoke them if necessary.
Provide a secure Over the Air update mechanism for your medical IoT device
Implementing secure update mechanisms to protect your medical IoT device is essential. First, because no software system is infallible over time. You must be able to update it when you identify and correct flaws. Moreover, all client interfaces evolve, and you will probably need to make changes, add new features, and so on.
The purpose of a secure update mechanism is obviously to protect each hardware item as well as to avoid, in case of problems, compromising the entire pool.
An authentication system should be implemented here to avoid unique keys.
Choose a specialized semi-public or private cloud for your medical IoT device
In order to address privacy and security issues specific to the medical IoT devices field, some infrastructure providers offer specialized cloud solutions guaranteeing high data storage and transfer security.
For example, solutions such as OVH Healthcare, FollowMed exist and cloud giants also provide solutions, such as Google Healthcare or Microsoft HealthVault.
Certification of these solutions is progressing. In early 2018, following a change in the legislation, the ASIP (French Shared Healthcare Information Systems Agency) revised its procedure.
It now imposes a documentary and on-site audit carried out by an independent third party and verifies the equivalence of any ISO27001 and ISO20000 certifications already obtained. The ASIP also differentiates between two certification perimeters: physical infrastructure host and hosting companies.
See things differently with Edge Computing for medical IoT devices
The principle of this solution is to not transmit all raw data to the cloud but to pre-process the data directly in the hardware of your medical IoT device. Unlike Cloud computing, which consists in transmitting all data to the cloud to be exclusively processed, Edge computing is a solution when high volumes of data need to be transmitted and stored in the cloud. In our context, it can also address sensitive data security by processing it directly in the hardware and only transmitting pre-processed and potentially less sensitive data.
Medical IoT devices: Open up the field of possibilities with artificial intelligence
Recent developments in this field have applications in multiple fields and open up a number of perspectives.
As regards to the medical IoT devices market, the implementation of artificial intelligence algorithms could address data confidentiality issues by generating data models that are in every way similar to real data without actually being the data of real patients.
For example, an artificial intelligence engine can learn to generate patient data from real patient data, and once it has learned how to do this, it can generate thousands of similar data, consistent with real data but without privacy issues as the data generated is not related to an actual patient. The learning phase is done in a secure environment (because handling and access to real data), but once completed, the AI engine can be implemented in an open environment.
AI can be used to develop new diagnostic and interpretation tools of exceptional reliability, for example.
No doubt there are software solutions for successful medical IoT devices, the key is to start with the right questions
As we have seen, there are various mechanisms that guarantee security, confidentiality, and compliance with medical market development standards while providing connectivity and data transfer interfaces to implement IoT scenarios.
The implementation of these different technologies is far from trivial and the choice of technologies and their integration with the right level of security requires specific software expertise as well as proven software architecture and integration skills.
It is also important to keep in mind that each scenario is different. Depending on the type of medical device, its purpose, the type of data handled, the level of security required, the environment of use, and the scenarios of uses envisaged, the technological choices and the manner in which they are combined will be completely different.
The key to success for this type of development is to integrate system architecture expertise in the early stages of the project for a global vision of software issues, both in terms of uses and system or technological constraints.
You might also like...
IoT in Healthcare : Take Up The Challenges Of Connectivity Connected medical devices present challenges to manufacturers and software developers alike. Discover the three ways Witekio delivers value for IoT Healthcare devices.
Read more