Chicken or the Egg: Should Device Interoperability or QMS Interoperability Come First?

MedTech Intelligence – Read More

MTI Viewpoint

Insights shared by industry relative to healthcare and the advancement of medical technology.

Carl Washburn is Director, Digital Quality at Eli Lilly and Company. He is a proven global business leader in mobile health technology and has a corporate background at Eli Lilly, Johnson & Johnson, Siemens Mobile, Siemens Medical, Shared Medical Systems, and GTE Health Systems. Carl has managed Quality and Design Control compliance of mobile apps as medical devices and is an inventor with 9 patents granted and co-inventor with 14 patents pending.

It is becoming increasingly important that drug and medical device companies develop an innovative and sustainable approach for Quality Management System (QMS) interoperability with development partners for Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD).

Device Interoperability

Modern medical devices are becoming more complex. They often include drug products, delivery systems, electronics, and mobile apps that all need to work together as one system for the patient. Sometimes, different parts of the device are made by different companies, each with their own way of managing quality (called a Quality Management System, or QMS). To achieve medical Device Interoperability, system boundaries need to be defined, system architecture needs to be aligned, and interfaces and communication protocols need to be established across individual components of the medical device.

In some cases, components of the medical device can be developed by a third-party medical device manufacturer under their own certified QMS. For example, a company might publish a mobile application in the app store that has been developed by a third party. In this case, it is as important to design and implement QMS Interoperability as it is to design Device Interoperability.

Device Interoperability vs. QMS Interoperability

Device Interoperability means making sure all parts of the medical device—like a pen injector and a mobile app—work together smoothly.
QMS Interoperability means making sure the quality systems of different companies can work together, especially when they are responsible for different parts of the device.

QMS Interoperability

A quality system can be developed that establishes QMS boundaries, defines QMS interfaces, establishes a communication protocol, involves risk mapping, and governance oversight as shown in Figure 1 below:

Figure 1:

Boundaries

Boundaries define what components of the medical device are covered by which QMS and define overall QMS responsibility. For example, with one connected-care solution, a pen injector could be developed under one QMS while a partner is responsible for developing a supporting mobile application under a separate QMS. Boundaries are defined in Development Plans and Quality Agreements.

Interfaces

For a connected medical device, interfaces define how information is passed between individual components. For QMS Interoperability, interfaces can define what key design control deliverables need the review and approval of both Quality Management Systems. Examples of key design control deliverables that may need the review and approval of both Quality Management Systems include:

Development Plans
Risk Assessments
Change Plans

Key design control deliverables and QMS approval requirements can be defined in Development Plans or Quality Agreements.

Communication

For connected medical devices communication protocols need to be established to define how the components of the system communicate with each other. For an interoperable QMS establish clear communication protocols to ensure coordination and transparency between the Quality Management Systems. Regular meetings and cross-QMS document approval requirements defined in the Quality Agreement keep everyone updated on progress, problems, and customer feedback.

Risk Mapping

A communication interface for a connected medical device can use an Application Programming Interface (API) to map data between the sending and receiving components. When risk assessments made under a partner’s QMS are being evaluated both QMS’ comply with ISO 14971, but there may be minor differences such as severity and probability tables at both organizations. In this case, it is helpful to provide translation tables mapping the probability and severity of the partner’s QMS so that accurate assessments can be made by governance teams assigned to evaluate risk.

Risk Transfer

A connected medical device may have one component where the risk is created under one QMS but may mitigate the risk in another component of the medical device under a different manufacturer under a different QMS. For example, patient safety risks with a connected pen injector under one QMS can best be mitigated by the mobile application under another QMS. Examples include presenting warning messages on the mobile application or providing additional instructions to the user. In this case QMS A creates risk transfer documents to transfer risks to QMS B and ensures those risks are mitigated which can includes examples in shown in Table 1:

Table 1:

Governance

When a development partner creates medical device software under a separate QMS, a risk management oversight committee approves key design deliverables and product launch. These cross-QMS governance meetings that facilitate cross-QMS document approval requirements enable QMS interoperability, with partner representatives (medical, patient safety, quality, regulatory) presenting to the governance committee as document approvals are evaluated. The risk mapping process facilitates these discussions, as outlined in Development Plans and Quality Agreements.

Results

The work put into defining boundaries, interfaces, communication protocols, QMS mapping, and governance has served both organizations and patients well in allowing both QMS’ to integrate and operate independently for projects out of scope and effectively interoperate for projects in scope.

Conclusion

For connected medical devices, what is the answer to the “chicken and the egg” question of which should come first? Well, the answer is both!! As an integration project matures new QMS Interoperability requirements may arise from new connected device requirements. Robust QMS Interoperability enabled through well-defined quality agreements; is the foundation for achieving seamless Device Interoperability.