Thanks to Laurence Sampson for writing this article, as a preview to the upcoming conference on Practical Solutions in CSV and SDLC for GXP & MedDev (London, 3/10/2018)
In today’s competitive landscape, every stage of the regulatory process – from first submission through ongoing, annual or semi-annual iterations – is a make-it- or break-it-scenario. From delays to audit failures and recalls, the challenges that may derail your product releases and updates are significant.
Digitized design control is the key to staying on track for a smooth launch and ongoing evolution of your device.
How you start is a good indication of how you may finish. While the first regulatory submission of your device may be possible to manage with an old-fashioned, non-digitized design control created in Word and Excel, this approach is ultimately unsustainable. Knowing that your device may be produced over many years and may then survive in the market for several additional years, it’s clear your Design History File (DHF) will have to be maintained for a period of 20 years or more.
Even in the rare instance where the design of the device itself does not change over that period, the environment will change, forcing you to update the design controls regardless. Thus keeping the design controls in a digital format will make a huge difference in:
- How easy is it for you to do the differential analysis (otherwise known as gap analysis), so you can efficiently assess how external changes impact your existing design controls and identify where your design needs to be updated accordingly.
- How easy it is to update the design controls in response to the change, even if the only thing you need is to update is the ancillary documentation.
As the preparations for compliance with the new EU Medical Device Regulation (MDR) loom over medical device companies, it reminds us of the two significant considerations for design control and underscores the need for digitization.
Differential analysis to your design file is “part of life”
As companies are finishing the transition to the ISO 13485:2016, the EU MDR is the next big change to address. For companies who have a robust digital design control setup, adjusting to the MDR actually demands minimal planning, as it’s mainly about execution. This is because a complete digital design file includes comprehensive information about all the normative and regulatory standards as part of the “Product sources,” which feed directly into design inputs.
With the transition from Medical Device Directive (MDD) to MDR, the first step is to update the product sources – superseding MDD requirements by MDR requirements – and adjust the links with existing design elements. This process will expose all the gaps between the existing controls and where you should be. Translate that information directly into work items for your team, and then proceed with working on closing those gaps. This differential analysis is made significantly easier when you have the digital file in place and can easily use the superseded regulation as the jumping off point to find the gaps.
In the ever-changing medical device development landscape, differential analysis is frequently a necessity, so the accumulative gains over time are very significant.
Feedback loop for post market surveillance into your risk management
The new MDR requires you to include in your post market surveillance (PMS) notable trends of non-serious incidents. This is a significant shift from previous practices and extends the PMS far beyond the realm of “exceptions management.”
We envision that this change will push for a need to collect more data from devices in the field (Internet Of Things, IoT) and require companies to take a deeper dive into that data to identify events that are associated with risks. These risks may be either those that have already been identified in your risk management file, or totally new ones.
This is how the feedback loop will work:
- Data points will be collected via multiple channels:
- Traditional complaints routes (i.e. help desk emails)
- Social media accounts
- In-app notifications (for health apps)
- Electronic logs collected by the devices themselves (i.e. from pacemakers, IVD equipment, health apps, etc.)
- This data will be collected into data lakes where it will be analyzed and tagged. Some of these events will be tagged as “risk-related events.”
- The “risk-related events” will be further analyzed to associate them with specific device risks.
- Within your DHF, the risk management file will now show not just the risks, but also the related risk events coming from that feedback loop.
- As required by the MDR, this information will now have to be analyzed periodically to identify what the feedback information can teach up about actual, real life risks associated with your device.
Obviously, this more intense constant feedback loop will inevitable drive change into your risk management file – even if the device itself has not changed. This once again arrives at the conclusion that in today’s marketplace, it’s imperative – particularly from a regulatory standpoint – to maintain design controls digitally.
Laurence Sampson will speak at the one-day conference, “Practical Solutions in CSV and SDLC for GXP & MedDev” on 3 October in London.
