Regulatory Open Forum

 View Only
  • 1.  OTS Medical device

    This message was posted by a user wishing to remain anonymous
    Posted 30-Apr-2020 17:12
    This message was posted by a user wishing to remain anonymous

    Hi Everyone,

    I recently started working on a 510 K cleared legacy IVD. This detection unit is connected to a PC and is sold as one equipment to the end user.
    While over the course of the product's life due to obsolete technology various parts are often replaced. I am unclear how do assess the severity of these changes.
    1) If this was cleared as one device ( i.e. including the monitor , PC, mouse, software etc) . will these parts viz monitor , printer, etc fall under the scope of "Off the Self " software use ?

    Is it appropriate to classify this as a Off the shelf Software ? ( eg monitor from dell or HP used to replace the old monitor)

    I know there is a guidance on " Off-The-Shelf Software Use in Medical Devices" but this question is to understand if such devices come under the OTS category?

    Thanks,


  • 2.  RE: OTS Medical device

    Posted 01-May-2020 05:00
    Hello Anon,

    Generally yes many devices can be used with Off-The-Shelf components or products, such as being connected to a computer system.  What you have to consider as part of the design input of your device is the Minimum or Recommended Specifications for the OTS products.  If your device can be connected to any computer, that is fine and has been thoroughly accepted by regulatory professionals and authorities.  However, while you can connect to any OTS product this should be specified for your current version or model of device, i.e. computer specification being Dual-Core, 8 meg RAM, 250 meg memory, Windows 8 or later release, at least 1280x1920 monitor.  Something like that.  What you do not want to happen is the coding in your device is linking to DLL libraries for recent releases and if someone connects your device to a computer with say Windows 7 or Windows XP (is XP still around?!?) and then the device does not work, you get those frustrated customer calls.  So if you already specify the minimum requirements so when a customer wants to connect to a Mac OS, at least you have clearly stated the minimum requirements.  Part of your device/software validation would then be running the device with a standard system with the minimum requirements to ensure full functionality.

    ------------------------------
    Richard Vincins RAC
    Vice President Global Regulatory Affairs
    ------------------------------



  • 3.  RE: OTS Medical device

    Posted 01-May-2020 10:29
    I agree with Richard Vincin with a couple of subtle clarification:

    1) Your issue is NOT covered by OTS Software. It is a hardware question as to whether your proprietary SW is compatible with alternative peripheral hardware.
    2) The solution is the same as what Mr. Vincin recommends, with the addition of, at a minimum, preparing a Letter to File to expand the original description of these peripherals (especially if they were called out by brand and model) to the minimum, and possibly maximum requirements for proper function of the system (e.g., resolution of the monitor).
    3) It appears in your case the system was designed to perform with older peripherals and therefore the concern is not whether it works with obsolete interfaces but to newer, faster interfaces. If the company is shipping these components with new systems, the newer peripherals should be tested prior to distribution and documented in the Letter to File as irrelevant to product performance. If the peripherals are user supplied then the minimum specs in the installation instructions should suffice.

    ------------------------------
    Gregg Harris
    VP, Clinical & Regulatory Affairs
    Glen Allen VA
    United States
    ------------------------------



  • 4.  RE: OTS Medical device

    This message was posted by a user wishing to remain anonymous
    Posted 04-May-2020 08:48
    This message was posted by a user wishing to remain anonymous

    Hi Richard, Dan and Greg,

    Thank you so much for your suggestions.

    The product in question goes a one unit . Therefore the end user actually gets the PC attached to the unit.( Any of these end of life component replacement changes will not affect the products in the field.)
    From what I understand is, with the change in certain components/peripherals, the drivers do get replaced.
    I came across this Section V question 2 of the OTS software guidance that makes me think I need to refer to this guidance . This also mentions about conducting the risk analysis and mitigation for OTS software ( See the snapshot below)
    As Dan rightly pointed out the change assessment conditions under which a new or changed medical device including OTS Software will
    require a new 510(k) are the same as for a device not involving OTS Software.

    But in order to ensure that the risk management covers all the required elements should this Guidance not be used while carrying out the risk assessment and the validation? and should  the OTS driver software package not be part of the system interface validation process and the risk assessments ?
    (Though these are considered peripherals will these fall under the scope of OTS software guidance ?) 
    Or did I get this wrong ?

    Thank you so much for your time.
    https://www.fda.gov/media/71794/download




  • 5.  RE: OTS Medical device

    Posted 04-May-2020 11:42

    The direction depends on the problem you are trying to solve.

    Initially you said, "I am unclear how to assess the severity of these changes". To my mind the severe case is when you change a 510(k) device and did not determine whether or not the change requires a new 510(k). It is even worse if you continue to market a device that should have had a new clearance.

    FDA does not seem to be strictly enforcing the UDI rule. However, if they find a problem looking at something else, it could be on a 483.

    Both of these issues could come up in an inspection that includes design control.

    When you make a design change you need to include four evaluations:
    New 510(k)
    New UDI-DI
    Update to risk management
    Part 806 C&R report required

    The 510(k) evaluation has two parts: one is the general guidance document and one is the software guidance document. The 510(k) evaluation includes an analysis of any changes to the hazard analysis in the risk management file.

    Use the ISO 14971:2019 (or ISO 14971:2007) hazard analysis. This is the part of the process flow that starts with the hazard, sequence of events, hazardous situation, and harm. First determine if any change introduced one of these elements. Then determine if any change modified one of these or any resulting risk control measure.

    The 510(k) change analysis expects you compare the before and after hazard analysis.

    Use all the help you get. If, for example, the OTC software guidance document provides useful information, then use it.



    ------------------------------
    Dan O'Leary CQA, CQE
    Swanzey NH
    United States
    ------------------------------



  • 6.  RE: OTS Medical device

    Posted 01-May-2020 10:51

    I recommend you do not take the software approach, but, instead, consider this as a change to a 510(k) cleared device. This leads you to conduct an evaluation of the need to notify FDA. Follow the guidance document on general changes and the one on software changes. You should also evaluate the need for a new UDI-DI.

    Start with the configuration of the device covered by the most recently cleared 510(k). Identify the indented use and list all the components, modules, etc. in the configuration. Look at the Device Master Record and a few Sales Orders from the time. Call this the base 510(k) configuration.

    Next look at the configuration of the device on the Publish date you entered into GUDID. Take the approach above. Call this the base UDI configuration.

    Next look at the configuration of the device you are currently shipping. Take the approach above. Call this the current configuration.

    Identify the differences between the base 510(k) configuration and the current configuration. For each difference, apply the flow charts in the guidance documents. For each decision step, record the result (Y/N) and the reason for the decision. Do the evaluation one more time for the overall configurations. If any evaluation leads to submitting a 510(k), make a decision if you will continue to offer the device until you receive a new 510(k) clearance.

    A new 510(k) clearance requires a new UDI-DI.

    If none of the evaluations lead to a 510(k), then conduct a UDI evaluation. Using the definition in Part 830, identify the characteristics of the version or model in the base UDI configuration and in the current configuration. If they are not the same, then assign a new UDI-DI, revise the label, and create a new UDI record in GUDID.



    ------------------------------
    Dan O'Leary CQA, CQE
    Swanzey NH
    United States
    ------------------------------