By Wesley Aarsen

What is the definition of the Internet of Things (IoT)?

Gartner defines IoT as the following: “The Internet of Things (IoT) is the network of physical objects that contain embedded technology to communicate and sense or interact with the internal states or the external environment.”

If a medical device firm is implementing an IoT device, implied in the definition is a set of new product features related to the company ideation, realization and utilization systems. We will begin with a delineation some of the new capabilities and potential features IoT promises to bring to our devices. This list will be fairly short to illustrate the difficulty in implementing this kind of technology, and the need for a digital model to support the effort not only in

This list will be fairly short to illustrate the difficulty in implementing this kind of technology, and the need for a digital model to support the effort not only in creation of the product, but just as critical, in management of the device after deployment.

Benefits of IoT

We think of IoT connecting devices with a few primary capabilities unique to the Internet connectivity.

The device will have the ability to receive data

The device will have the capability to send data

These capabilities enable product features that are truly revolutionary. Examples:

Field update of device software

Server directed device control

Device status transmission

Remote device servicing

Risk management dashboarding

Device sensor data transmission

After determining what features are desirable, an analysis of the company systems should be completed to determine what systems are necessary to support the desired functionality.

Burden to company systems

Ideation

A simplified data model related to authoring and testing the product inputs is shown below. User needs are refined by a set of multi-discipline requirements. Each of the user needs and requirements are validated and verified respectively by testing.

Each of the design inputs are satisfied in the design outputs, and the design outputs comprise the device master record (DMR). In order to support field update of the software the system needs to support the following ideation system requirements:

1. We need to know specifically what components of the DMR are related to each input and subsequent test in order to define what testing would be needed to verify/validate the new software release complies with design requirements.

2. The design management system must support not only mechanical, but software requirements, and the system should provide a rich software development functionality including code branching, defect traceability to software database commits, support for complex, and automated testing.

3. The risk management system should support automated device performance feedback from the autonomous IoT device for analysis.

4. The requirements should be linked to the risk analysis to tie field performance gathered through the internet automatically to the user harm risk analysis report.

Question #1: What devices are the right devices to update?

In this case it’s unlikely that the lot of chips will correspond to the lot of product build, so we will need to know specifically what hardware is installed on which device. Otherwise, we will install the new software on the Lot 1 chips. An electronic DHR (eDHR) built from software commit/defect for the unique material for each device would provide the company with maximum flexibility in determining the most cost effective solution going forward.

Question #2: Is this a change to baseline product or is the branch only to be used for field update?

I hope this question drives home how complex this can get. Now we have an update to product software that will never be used on product released from the manufacturing plant. What if now we have another problem with a different component that requires an additional change? We potentially need to update two sets of code from different code trunks with all applicable verification testing, and none of this testing will be directly applicable to product released from the manufacturing facility.

Question #3: What testing is necessary to complete before approval of software update?

Once root cause has been established, and the component is identified it is necessary to provide the traceability from the component identified to the requirement it satisfies, and the software architecture to establish all testing necessary to determine whether the software not only fixes the problem identified, but that the medical device will still satisfy the requirements, user needs and intended uses in the context of product risk before exposing users to the correction. Integration of the device construction, software, and product design control is critical to making this possible.

Siemens systems to manage the device design control are: