Waterfall processes contrast greatly with agile processes and we strongly believe that they should be avoided.

Thirdly, the language used to describe regulatory requirements is not intuitive. Therefore, the design control requirements need some interpretation to get them working well with agile.

With quite a bit of experimentation, we’ve managed to get reasonably comfortable mixing design controls requirements and agile working practices.

Reconciling agile product development with Design Controls

Firstly, it is important to know that design controls are a set of requirements for how you should document the design of your medical device. Your design process and how you document it are two separate things and should not be confused.

We recommend viewing design controls as a parallel and inter-related activity to agile product delivery. The links between the different elements of design controls are logical links, and not steps in a process. Rather than thinking about elements of the design controls as a series of waterfall steps, think of them as a set of parallel streams, as illustrated in the following diagram.

The blue lines represent levels of activity in each of the streams, which becomes more intense at different points in the project and can be thought of as continuous (for example, defining user needs, defining design outputs). The blue dots represent activities that occur at defined points in time, such as design reviews, or verification tests.

Design control activities

We’ll start by defining some of the design control requirements in language that is more easy to understand for those familiar with agile product development and user-centered design. The two terms that are hardest to understand and have caused a lot of confusion (at least to us!) are design inputs and design outputs.

User needs

Happily, user needs are one aspect of design controls that are easy to understand. Users have needs and it is important to find out what these are so that your product can meet them.

We use contextual research (visiting people in their everyday environment) to discover user needs. This activity is most intensive during the discovery phase.

The waterfall diagram makes it look like you should find out your user needs at the start of the product development process before you start defining your design inputs. In reality, you should continually revisit the user needs and update them throughout the development process.

Documenting user needs:

• Define a statement as a user story or job story
• Give a unique ID
• Link to design inputs (requirements)
• Show evidence with research findings

Design inputs

Design inputs are best thought of as a list of requirements that the design for the product should meet. These might be user requirements, but also:

• Functional requirements
• Performance requirements
• Regulatory requirements
• Business requirements
• Outputs of risk management
• Customer requirements

Some requirements will be easy to write down from the start of the product development process while others will only be uncovered later. Requirements gathering will be an important part of the Discovery Phase, but should be revisited continually throughout the other phases. Requirements might change over time and some may become obsolete, especially those that relate to user-behaviour.

Requirements should not be prescriptive as to how they should implemented.

Documenting design inputs:

• Define a statement as a requirement
• Give a unique ID
• Optionally give a prioritisation. MoSCOW is a good approach for this.
• Categorise by type of requirement: Functional, Performance, Regulatory, etc.
• Link to user needs
• Link to design outputs
• Define how the requirement can be verified

Design outputs

In some ways, design outputs are easy to define: they’re simply the “outputs” of the design process. As you design a product, you produce documents such as drawings, specifications, prototypes and models that go towards describing the product and how it works. Intuitively, it would seem appropriate to collect these together, label them “design outputs” and be done.

Unfortunately, the qualities that make a design document valuable in the design process don’t necessarily meet the regulatory requirements for design outputs. For instance, a high-fidelity interactive prototype may be a fantastic tool for communicating the vision of the product to a potential user or customer, but it will probably lack a few key properties to qualify as a valid design output.

• It is unlikely to be comprehensive as it probably won’t include all the features in the final product (otherwise it wouldn’t be a prototype).
• It will be difficult to review in a systematic way as certain features may only become active if the user performs a certain sequence of actions.
• It is not a “portable” document – by this we mean that it will be difficult for a regulatory audience to view your prototype. Anything more complicated than a Word or PDF document will be unlikely to be admissible as part of your design history file. An auditor will not download and run your app.

Documenting design outputs

The requirements for design output documents are relatively simple: there should be clear traceability between the design input and the design output. That is to say, for each of the requirements you list in your design input, there should be a corresponding item in your design outputs that documents how you have met that requirement. In addition it should be easy to verify that this is the case.

For a hardware product, design outputs are likely to be the specification for the product: drawings, definitions, models and manufacturing instructions.

Software specification as design output

For software-as-medical-device products, the format of design outputs is open to interpretation. One option is to create a software specification that describes the different features of the product. Each of these features can then be mapped onto its related design input requirements. Another option is to treat the source code of the software itself as the design output. After all, source code is a detailed description of how a product functions.

At Ctrl Group, we generally document our design outputs as a specification. We do this because we find it helpful for team communication to have a document that describes how our software functions. This is one area where we diverge slightly from the agile orthodoxy that prioritises “Working software over comprehensive documentation”.

We have found that it is not worth documenting design outputs until later in the project when the design and features have settled. The end of the alpha phase or start of the beta phase is a sensible time to start and you’ll need to have defined a draft set of design outputs by the time that verification testing begins.

Documenting design reviews

Design reviews are an opportunity to get feedback from wider team and external experts and should be a frequent activity from the start of the product development process.

The regulations assume that a design review will be an in-person meeting, but we find it can be more effective as an activity that is conducted asynchronously over email or Slack. Sometimes, we’ll start a design review by circulating a set of designs for people to feedback on over email and follow up with a team meeting to discuss everyone’s feedback and decide what actions to take next.

Documenting design reviews:

• Date of review
• Give a unique ID
• Add a list of who contributed to the review
• Include the designs and documents being reviewed and the particular version
• Each item of feedback should be documented and include:
  • A given unique ID
  • Who contributed the feedback
  • Whether any action was taken based on the feedback

Documenting Design Controls

Meeting the requirements for design controls adds work for a team that is most interested in building a great product. It is therefore easy to make the mistake of deferring this additional work until it is too late, or ignore the requirements completely.

The key is to start documenting design controls from the start of the project, but to keep it light and simple to begin with. A few spreadsheets that list out your user needs and design inputs will probably suffice for the early stages of the project.

When the project becomes more complex, a specialised software tool might be more appropriate, but these can come at the cost of being inflexible or too complex. At Ctrl Group, we use our own tools as part of our wider quality management system.

However you document your design controls, it is important to keep track of the changes between the different versions of each document that you create over time. This is a requirement of document controls - which is another important element of a quality management system.

Documentation produced to satisfy design controls should be produced for a regulatory audience first and foremost, as they’ll form part of your regulatory submission when you seek approval for your medical device. However, a more positive goal to aim for is to use the design controls process to help with teame communications.