Internet of Things: Creating Challenges for Medical Device Manufacturers

By Wesley Aarsen

We recently posted “Internet of Things: Expanding Into Medical Device Enterprise,” and welcome you to part two of the ongoing discussion about medical devices and the Internet of Things (IoT).

Realization

Because field update of software is possible for hardware that is no longer manufactured it is now probable that more than one DMR will be approved for use with the variety of different product configurations (hardware and software variants). In addition to this, an update of the product in the field requires the DHR not be a static lot based document. It is now time-based.

Each device can be different than any other device on the basis of which one has received a software update at any point in time. Need for sophistication of the design control system now becomes evident, and is propagated into the manufacturing process.It is possible to have almost as many different DHR’s as there are devices in the field, because the combination of software residing on the device could, depending on the complexity of the device, become unique to each device.A device specific electronic DHR (eDHR) has now become essential to regulatory compliance and avoidance of broad recall.

Consider for example an MRI machine, not the typical type of IoT device in view, but illustrates the point.A device of this complexity might have several hundred units and items of software.Over the life of the design it might only have the same manufactured software installed on 4-5 devices at a time.Now we introduce software changes based on either bug fixes or upgrades to hardware in the field.Pretty quickly it becomes unlikely that any two installations would have exactly the same code installed on both.

Another example might be a point of care diagnostic device.Even if all of the devices shipped have identical software, the hardware will often vary slightly.What if the supplier provides a chip, and we find that lot 1 and lot 2 of the chip perform differently, and a software change is required to make Lot 2 function properly.Well good news, we can update the software in the field with our IoT technology.However, this produces a variety of logistical issues.

The following is a list of questions that illustrate some of the difficulties.

Question #4: If I do not have the hardware combination available for the testing is the testing still valid?

It is entirely possible that there is no way to determine if the performance is acceptable without actually performing the test on identical hardware. That being said, the first step to resolve this problem is to know what hardware is affected, and the baseline DHR for the systems in question. The second is to understand completely the performance required, and whether either representative testing or simulation of the change is sufficient to approve the change. Often direct and granular integration of risk with product requirements provide us with the justification needed to make the change when user risk is minimal.

Question #5: What do I need to do to get this change approved?

First, we need to re-execute the applicable testing. To do this efficiently, we need a clear delineation of the testing required and a test management system to quickly and efficiently re-execute the test runs. Once this is competed approval of the test results and execution of a product change management system for approval of the baseline product is needed.

Of course, this does not mean the company is ready to implement the change. The company services organization needs to be made aware of the impending update, and work instructions should be implemented for the new changes to assure any issues related to the update are captured in the company system. This type of change requires that a secondary change control procedure be completed to assure the company is prepared for implementation of the change not simply update to a baseline product.

Siemens systems to manage product realization are:

Teamcenter
CamStar

Utilization

It is one thing to claim support for device support, but this is a whole different animal. Support of this nature requires automation to identify, update, and received status data for analysis. All of the systems previously described are necessary to identify, and approve the change, but now the change must be implemented and verified as correct in actual field use. The questions below will provide some context to why this is difficult.

Question #6: How do we deploy the maintenance software to only the applicable devices?

Now we have the devices we need, and a software change authored and approved for implementation we have the problem of actually deploying the software. In an integrated system, once the workflow for update is approved the system will automatically push the software update to the field.

Question #7: How do we collect data from updated devices?

Ideally, when this occurs the IoT device would immediately start updating the company performance data repository and updates to the risk analysis occurrences would start to populate. This would then be reported in an issue dashboard, and real time monitoring of the change would occur. Access not only to the change process is needed, but the compiled code, and an appropriate update to the current device configuration and details regarding the update process (time based) DMR are required to complete the transaction.

As you can see integration of systems is critical to evaluation of the desired changes, and implementation of approved changes.
Siemens systems used to manage product utilization:

Teamcenter MRO
Omneo
Teamplay

How do Siemens solutions map to these needs?