Summary

A discussion of what a requirement is in an FDA compliant medical device.

What is a Requirement?

In common software development discussions, a requirement is a statement of what a user or stakeholder wants the app or device to do.

In a medical device a requirement is different.

Safe and Effective

Two primary goals for a medical device are:

  • Effective - deliver the expected treatment, therapy or behaviour required by the patient, doctor and/or nurse
  • Safe - if the device successfully delivers the expected benefit:
    • it must do it safely, i.e. any behavior it performs must not harm the patient/doctor/nurse
    • if the device fails, it must fail in a way that does not harm the patient/doctor/nurse

The intent of medical requirements is to specify as clearly as possible all the behaviors required to achieve these two goals.

PRS vs SRS

At the top level the PRS (Product Requirements Specification) document specifies the overall behaviors the device delivers.

This means that for similar medical devices e.g. intravenous (IV) pumps, the PRS docs are very similar. These devices all have a common intent i.e. to deliver fluid at an accurate, specific rate.

But the subcomponent SRS (Software Requirements Specification) document there are tend to be different. The device's chosen design affects how the device implements Safe and Effective behaviors. Those behaviors depend on each other and other component's (e.g. electrical and mechanical) designs as well.

The design and implementation of the device can be anything that provides the expected benefits, but to ensure all the other components and subcomponents in the device also behave correctly, then this component must behave a particular way as well. If it didn't, then those other components may fail or not be able to deliver the expected treatment.

The users and stakeholders of the device may not be aware of any these requirements. They may understand the top-level requirements in the PRS but will likely not understand the possible failure aversion behaviors necessary to create a safe device.

Less is More

Code fails. Adding a code that is not necessary for the delivery of a treatment increases the risk that device can fail. Therefore, reducing the software, mechanics and electronics to the minimum is key to reducing the risk of the device.

From this perspective, the SRS document specifies the minimal set of behaviors the device must do, and it specifies all the behaviors as well. In other words, the SRS is a "minimum necessary" document.

They are different

Based on all those aspects, requirements in medical SRS requirements are different from commercial products requirements.

- John Arrizza