BMET3921/BMET9921

Biomedical Design &

Technology
Week 2: The Design Process

Dr Sandhya Clement
Associate Lecturer
School of Biomedical Engineering

The University of Sydney Page 1

Clarifications

The University of Sydney Page 2

 Clarifications
What happens if a team member drops the unit?

Please let us know as soon as possible. We take into account the

team composition when assessing group work.

New students can enrol over the next week or so and we will add
them to your team. If minutes and documents have been kept, then
they can be brought up to speed.

The University of Sydney Page 3

 Announcements
I don’t get announcements from Canvas emailed to me.

This is a personal Canvas setting. Please enable announcement

notification in your Canvas profile.

Check to see that

notifications@instructure.com
is not being blocked or in
spam.
The University of Sydney Page 4
 Collaborations on Canvas

The University of Sydney Page 5

This Week

The University of Sydney Page 6

 This Week – Lecture
– The overall design process
– Considering ISO standards
– Stages and steps involved
– Risks and Trade-offs
– Documentation
– Application to your projects
– Review Quiz: 2 questions (available after the tutorial)

The University of Sydney Page 7

 This Week – Tutorial
– Meet your team and tutor
– Develop a Team Charter
– Select a contact person
– Identify strengths
– Clarify key questions for clinical partner
– Make appointments for longer meetings
– Start activity – see Week 2 page on Canvas

– The activity will continue with some modifications in Weeks 3, 4

The University of Sydney Page 8
 This Week – Contact Person
Teams will need to select a primary contact
person
• Responsible for coordinating contact with the client or
consultants
• Everyone can still be in the email list or meetings
• One contact person makes things easier for client
response
• Can avoid complaints like “I am getting emails from 7
people”
• Always CC your tutor

The University of Sydney Page 9

 External Project Partner
– Plan an email/teleconference communication if not a face-to-
face meeting
– Face-to-face meetings may need to have limited attendees if space is
limited
– Coordinate between project teams to limit doubling up
– Clarify project brief

– NOTE: Partners are quite busy, so be proactive in arranging

communication

The University of Sydney Page 10

The Overall Design Process

The University of Sydney Page 11

 Engineering Design Loop
Formulation
Define Problem

Iteration/Evolution
Improve Conduct Research

Document
Obtain Feedback Brainstorm Ideas
/ Evaluate

Develop A
Solution

Finalisation
The University of Sydney Page 12
 Define the Problem

The University of Sydney

Conduct Background
Research

Formulation
Specify
Design Process

Requirements

Brainstorm Ideas

Choose Design to
Flesh Out
Improve and Refine

Detail Design
Iteration/Evolution

Evaluate Design
Finalisation
Fail

Pass

Prototype

Evaluate Prototype
Document
Fail

Pass

Page 13
 Stage 1: Formulation

Goal: to Duration:
understand the Research 3-4 weeks
problem and its (this project)
challenges

Document

Think Discuss
The University of Sydney Page 14
 Stage 2: Iteration and Evolution

Goal: To Duration:
develop an Outline 3-4 weeks
overall design (this project)

Refine Document Detail

Analyse
The University of Sydney Page 15
 Stage 3: Finalisation(?)

Goal: To detail Duration:

Detail
the final design 3-4 weeks
and its (this project)

Document
components Specify

Model

Plan

Communicate

The University of Sydney Page 16

 An ongoing process
– The design process can continue even after one ‘stable’ design
has been finalised
– Discovery of new problems
– Identification of areas of improvement
– Some lower priority risks or requirements left
– Product updates and upgrades
– A way to maintain competitive advantage
– Documentation allows this process to continue over time

The University of Sydney Page 17

Why document?
Standards and Regulations

The University of Sydney Page 18

 Pillars of Medical Device/Technology Development

Safety Effectiveness Efficacy

Expectation that Performance Performance
users and others under “real under ideal and
will be kept free world” controlled
from harm circumstances circumstances

The University of Sydney Page 19

 ISO 13485:2016

Medical devices – Quality

management systems –
Requirements for regulatory
purposes

The University of Sydney Page 20

 What is it?

– Requirements of a quality – Can also be applied to

management system (QMS) suppliers or external parties
– For organisations that need to a company
to demonstrate medical – Responsibility of
devices and other services organisation to ensure
meet customer and external processes/suppliers
regulatory requirements are compliant
– Required to explain:
– What the device does

The University of Sydney

– How it does it Page 21
 Related Standards
Medical devices -- Symbols to be used with
ISO 15223-1:2016 medical device labels, labelling and information
to be supplied -- Part 1: General requirements

Medical devices -- Application of risk

ISO 14971:2007 management to medical devices

ISO 9001:2015 Quality management systems – Requirements

And more…

The University of Sydney Page 22

 Standards Catalogue

https://www.iso.org/ics/11.040.01/x/
The University of Sydney Page 23
 Back to ISO 13485

Introduction
and use of the
standard

Requirements
to be compliant
Supporting
material

The University of Sydney Page 24

 The Components are Related
defined
measures
strategic Management
allocation Responsibility
information for
decision-making

Quality Measurement
Resource
Management Analysis and
Management
System Improvement

used to
make evaluated
products and
Product Realisation assessed

The University of Sydney Page 25

 Let’s Take a Closer Look…

The University of Sydney Page 26

 Medical Device File
– Document that describes:
– Design records
– Product specifications
– Manufacturing procedures
– Usage guides
– Storage, packaging and handling guides
– Processes for monitoring and evaluating (quality measurement criteria)
– Level of compliance with regulations
– Servicing and installation guides (if needed)
– Can have medical device files for device families
– Similar devices with some variations
group of medical devices manufactured by or for the same organization and having the same
basic design and performance characteristics related to safety, intended use and function
The University of Sydney Page 27
 Some Definitions
– Design Inputs
– Initial requirements that describe device to be produced
– Influenced by a multitude of sources
– Design Outputs
– Results of design and engineering efforts
– Final specifications of the device
– Documented in models, drawings, analyses etc.
– Includes manufacturing process
– Describes inspection, test methods, and criteria
– Verification and Validation – compares outputs against inputs
The University of Sydney Page 28
 Design Inputs – Types/Sources of Requirements
– Functional – what it does
– Performance – how well it does it
– Safety
– Statutory/Regulatory
– Previous and Similar Designs
– Essential – for CE certification
– Risk Mitigation – needed to reduce risk
– User – what the customer wants
– Organisational – what the customers’ organisations need
The University of Sydney Page 29
 An Example
– Design input: Catheter must be small enough to fit inside
femoral artery
– Design input: Catheter must allow interventional radiologists to
navigate to a specific location to administer therapy
– Design input: Catheter must be smaller than a competitor’s
catheter

– Design output: Specification/model where the catheter is

2.3±0.05mm

The University of Sydney Page 30

 Product Realisation as a Process

INPUTS Product Realisation OUTPUTS

What are they? What are they?

The University of Sydney Page 31

 Product Realisation as a Process

INPUTS Product Realisation OUTPUTS

Verification and Validation to evaluate

Requirements Product Design

The University of Sydney Page 32

Breaking down the design stages

The University of Sydney Page 33

 1. Define the Problem
– Key goal: understand the different perspectives that surround
the need for a new device or solution

1. Who faces the problem?

2. What is the clinical need?
3. Why is the problem important to solve?
4. Are there any other stakeholders who would be affected by either the
problem or the solution?

The University of Sydney Page 34

 1. Define the Problem

– User – Clinical Need

– Person who will be – Specific challenge or
involved in utilising it pain point
– Examples – Varies based on project
– Clinicians or departments – Can be related to non-
– Patient clinical factors
– Administrator • Throughput
– Educator • Training

The University of Sydney Page 35

 1. Define the Problem

– Importance – Stakeholders
– What will change by – Aside from the user, who
solving it else is affected?
– Conversely, what will – Examples
remain the same if not – Caregivers/families
addressed – Other hospital staff
– Why now? – Financial departments
– Government
The University of Sydney Page 36
 1. Define the Problem – Your Projects

expand

describe

some

Project Brief Design Report Template

The University of Sydney Page 37
 2. Conduct Background Research
– Key goal: To benefit from the prior work that has been done
before, such as existing solutions and the experience of others.
A key benefit is being able to avoid mistakes made from the
past.

1. What solutions already exist for the problem and how do they work?
2. What do other similar users/stakeholders use, and what do they think
are the problems?
3. What are the key strengths and limitations of existing solutions?
4. What other technology might be relevant to the problem?

The University of Sydney Page 38

 2. Conduct Background Research
– Research must be structured
– Others must be able to replicate your research process
– Focus on expanding your knowledge about the project
– “What do I need to study to better understand the project?”

Users & Environment Health & Existing Science

Stakeholders Biology Technology

The University of Sydney Page 39

 2. Conduct Background Research
– The information you find needs to be of a high quality
– Otherwise you may not be able to trust it!

Good Quality Reference Poor Quality Reference

Reputable, credible, or trusted source
Relatively recent
As objective and unbiased as possible
Cites its own data/information sources
Indexed (easily found)
Unknown or untrustworthy source
Outdated
Unfair, biased points of view
Unclear sources of data/information
Not indexed, or published at random

The University of Sydney Page 40

 2. Conduct Background Research – Your Projects

The University of Sydney Page 41

 3. Specify Requirements
– Key goal: Define the attributes or characteristics that the
solution should possess in order to be considered successful,
appropriate, and useful.

1. Features that must be present, without which the solution is useless

2. Features that are highly desired and would be useful
3. Features that are nice to have
4. Features that are completely optional
5. Prioritisation

The University of Sydney Page 42

 3. Specify Requirements
– Requirements may change after research
– May become more specific
– May have reduced priority
– Important to consider the feasibility of each requirement
– Requirements have a direct relationship to the needs

Need What is essential to meet the need

Portable Light enough to carry
Small enough to transport

The University of Sydney Page 43

 3. Specify Requirements – Prioritisation & Risks
– Highly likely that its not possible to solve everything at once
– May be unclear what needs are essential, which are optional
– Research may inform this
– Ranking of requirements necessary to focus the design
iterations
– Each design iteration to be evaluated by comparison to the
requirements

– What is the effect if a requirement is not met? What is the risk?

The University of Sydney Page 44
 3. Specify Requirements – Your Projects

needed for short but source (may have come

consistency descriptive from prior art)

The University of Sydney Page 45

 4. Brainstorm Ideas
– Key goal: To generate multiple potential solutions for the
problem
– The first idea that comes to mind may not be the best one!
– Ideation – the process of generating ideas
– Do not limit yourself (yet!)

– Simple ideas
– Ideas that build upon prior work
– Ideas that merge multiple things
– Wild and crazy ideas
The University of Sydney Page 46
 4. Brainstorm Ideas
– Many different ways to approach it
– Could begin with an existing solution and try to improve it
– Could look at different requirements and try to identify something that
solves each one individually
– Rough sketches may help to visualise the approach
– Generate ideas quickly
– Don’t get bogged down in details or exactly fulfilling requirement
– Don’t worry about feasibility or cost
– These core evaluated later!

The University of Sydney Page 47

 4. Brainstorm Ideas – Your Project

By jorisaerts1 - Own work, FAL, https://commons.wikimedia.org/w/index.php?curid=13665504

By Steveonmz - Own work, from LeftLeads Photography, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=61093066
By Michael Rieger - This image is from the FEMA Photo Library., Public Domain, https://commons.wikimedia.org/w/index.php?curid=8078675
The University of Sydney Page 48
 5. Choose Design Idea to Flesh Out
– Key goal: Identify the idea or ideas that have the highest
possibility of meeting the requirements
– This eliminates ideas that may not work out
– Important to note these because there may be components that you can
borrow later during improvement and refinement
– Additional factors to consider:
– Feasibility
– Resources required
– Time required
– Availability of technology

The University of Sydney Page 49

 5. Choose Design Idea to Flesh Out – Your Project
– Many possible reasons to choose an initial design
– Maybe the one that sounds simplest to start with
– Maybe the one that seems the most feasible
– Maybe the one that seems it may fulfil the primary requirement
– Maybe the one that seems may fulfil most requirements
– Maybe the one that seems the most innovative
– Maybe the one that seems cheapest

– Explain your decision!

The University of Sydney Page 50

 6. Detail Design
– Key goal: Describe the specifics of the solution in detail

– Essentially describing:
– What the components are
– What their dimensions, and other characteristics are
– How the components integrate and how they work together
– How the solution can be built
– What resources might be used (materials, sensors etc.)
– What the costs might be

The University of Sydney Page 51

 6. Detail Design
– Depending on the problem/project, the types of information in
the detailed design may be different

Dimensions Sensors/Electronics Material/Chemicals Safety Features

Battery/Power Diagram/Model/ Security Features Relationship between

The University of Sydney
Mathematical Analysis Components Page 52
 6. Detail Design – Sketches or Diagrams
– Good way to communicate ideas to project partner
– Clinicians often work in orthogonal terms
– Consider isometric and orthogonal sketches of solution
– Guidelines
– Include labels
– Identify key features
– If required, show assembly
– Good to show points of interaction
• User
• Anatomy of patient
• Other devices
The University of Sydney Page 53
 6. Detail Design – Your Project

By Ruizo - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=3832101

By Own drawing{[Inkscape, Public Domain, https://commons.wikimedia.org/w/index.php?curid=1416571
By R. Dupont - Levicron GmbH, CC BY-SA 3.0 de, https://commons.wikimedia.org/w/index.php?curid=22735103
By John HartwigNdeanchem at en.wikipedia - Hartwig, J. F. Organotransition Metal Chemistry, from Bonding to
Catalysis; University Science Books: New York, 2010, Public Domain,
The University of Sydney https://commons.wikimedia.org/w/index.php?curid=37045809 Page 54
 7. Evaluate Design
– Key goal: Check how well the design addresses the
requirements
– Must also take into account the priority and the risks
– Maximise the number of higher priority requirements
– Reduce or mitigate most of the risks
– Identify what is missing and what can be improved
– This can then become the focus of future iterations

The University of Sydney Page 55

 7. Evaluate Design – Your Project
Requirements

Risks

Design Aims/
Deliverables

Iteration Score

The University of Sydney Page 56

 10. Improve and Refine
– (We skipped from 7 to 10)
– If your design isn’t ideal, perhaps not the best time to prototype
– Better to improve
– Key goal: Optimise your solution

– Evaluation will have identified where your design is not ideal

– Identify what is missing
– Check research to see what is available
– See if you can modify your current design or need to start from scratch
– Document this evolution!
The University of Sydney Page 57
 10. Improve and Refine – Your Project

2
1

The University of Sydney Page 58

 8. Prototype
– Key goal: Develop a working proof-of-concept that
demonstrates your solution
– Not normally what the final product will look like
– Has main functionality and user requirements fulfilled
– May be missing the tidiness/elegance of a commercial product
– Sometimes the prototype may have its own compelxities
– If it requires specific biomaterials
– If it requires a special fabrication technology

The University of Sydney Page 59

 9. Evaluate Prototype
– Key goal: Analyse if the prototype works as expected
– May identify issues in safety or efficacy
– May inform new design requirements
– May require rebuilding or redesign

– Even if prototype doesn’t work as expected, it doesn’t mean

the design process was incorrect
– Additional requirements that were discovered when practically
implemented

The University of Sydney Page 60

Risks and Trade-offs

The University of Sydney Page 61

 What are risks?
– ISO 13485:2016, 3.17
– Combination of probability of occurrence of harm and the severity of
that harm

– Risk is exposure to danger, harm, or loss

– What can go wrong? (mode of failure)
– How often can it possibly occur? (likelihood)
– How bad will it be? (severity)

The University of Sydney Page 62

 Severity and Likelihood
– Both play an important role in risk assessment
– Low severity, low likelihood
– Low severity, high likelihood, e.g., manageable side effect
– High severity, low likelihood
– High severity, high likelihood, e.g., a major side effect

– Many existing medical technologies have risks

– CT scanners (ionising radiation)
– Pharmaceuticals (side effects)

The University of Sydney Page 63

 Severity and Likelihood

– Drowsiness or tiredness
– Low grade fever
– Anaphylaxis (allergic reaction)
– Guillain-Barré syndrome (1/1000000)

The University of Sydney Page 64

 The Risk Matrix
– Used to assess risk rating
– Accounts for severity and likelihood
– Rank severity and likelihood separately from low (1) to high (5)
– Risk rating is the product of these two values
– Higher numbers represent modes of failure with higher risks

Frequent (5) 5 10 15 20 25
Likelihood

Probable (4) 4 8 12 16 20
Occasional (3) 3 6 9 12 15
Remote (2) 2 4 6 8 10
Improbable (1) 1 2 3 4 5
Minor (1) Negligible (2) Marginal (3) Critical (4) Catastrophic (5)
Risk Rating = Severity x Likelihood
Severity

The University of Sydney Page 65

 Risk Mitigation
– Strategy or processes for reducing risk
– Decrease the severity, or
– Decrease the likelihood, or
– A combination of both
– Reduction of risk could inform part of your design requirements
and final specification
– May not help the function of the solution or its usability
– Important to specify component of your solution is there to reduce a
particular risk (documentation)

The University of Sydney Page 66

 Post-Mitigation Risk Assessment
– It is important to assess what the risks will likely be after the
mitigation strategy is put into place
– This formally indicates whether the strategy affected the
likelihood or severity or both, and the corresponding impact on
the risk rating
# Risk Category Severity Likelihood Rating Mitigation Method Severity Likelihood Rating Accept?
(1-5) (1-5) (/25) (1-5) (1-5) (/25) [Y/N]
RSK1.1 Causes injury User
RSK1.2 User
… User
RSK2.1 Tool breaks Technical
…

before after
The University of Sydney Page 67
 Trade-offs
– Not likely that all risks can be completely eliminated
– May not be able to completely eliminate risk without reducing
functionality necessary for the specific need

– Trade-offs may be necessary

– Need documentation about why the trade-offs were made
– Need a justification and explanation of the reasoning behind trade-offs

The University of Sydney Page 68

 Considering Acceptability
– After generating the post-mitigation risk rating, it is necessary
to assess whether the remaining risk is acceptable
– Can the solution still be used relatively safely?
– Can the risk be managed/worked around? (e.g., 15 min wait after
vaccination)

– If the answer is No, perhaps another mitigation strategy is

needed

The University of Sydney Page 69

Documentation

The University of Sydney Page 70

 The Documentation Pyramid
What will be done
Why will it be done
Policies
Who will do it
Procedures When will it be done
Where will it be recorded

How will it be done Practices

Evidence
Proofs

Increasing detail

The University of Sydney Page 71

 Traceability
– Vagueness introduces doubt
– Important to be specific when referring to a requirement, a
risk, a design specification, and how they connect

– Not just about looking back at the decisions that were made
– Confidence through consistency
– Referring to each requirement, risk, specification in a unique and fixed
way
– Use a unique numbering scheme

The University of Sydney Page 72

 Evolution of Ideas
– The journey to the solution also needs to be documented
– For each intermediate design stage, what was insufficient?
– This will form Section 5 of your report

The University of Sydney Page 73

 Usage Guides / User Manuals
– Form part of the medical device files
– Explains how the solution is intended to be used
– A reference to for revision or troubleshooting
– Written in a manner that is specific and makes few assumptions

– Not required for your Design Report

– Important to consider how to teach/instruct people to use

The University of Sydney Page 74

 Level of Compliance with Regulations
– Another element of the medical device file
– Possible that device or solution may be exempt from certain
regulations
– Need to explain which regulations and how close the
compliance is
– If regulations are updated to apply, the device may also need
to be revised

The University of Sydney Page 75

Application to your Projects

The University of Sydney Page 76

 Weeks 2–4 – Tasks and Tutorials
– You will be working on the Formulation part of the project
– Defining the clinical problem
– Identifying areas where you need to conduct research
– Actually doing some preliminary research (finding relevant
sources to read)
– Jotting down requirements
– Brainstorming ideas to work on

The University of Sydney Page 77

What to put in your logbook?
(Tips for Week 2)

The University of Sydney Page 78

 Design Development

What have you How do you think What do you

learned about the the process will be understand from
design process? applied to your the brief?
topic?

What questions do Have you done any What don’t you

you have from the research on the know? What
brief? topic? What did questions do you
you discover? have for the client?

The University of Sydney Page 79

 Project Management

Who is on the What will be What will be the

team and what your plan for the
are the roles? responsibility? overall project?

What is the key What are your What are the key
outcomes for the plans regarding tasks? What will
next few weeks? the client? be prioritised?

The University of Sydney Page 80

 Assessment of Self and Team

What are your What is your Where will the

strengths and assessment of the team need to
weaknesses? strengths of work together
others? closely?

Was the meeting How would you What is your plan

effective? assess your for improving the
progress? team processes?

The University of Sydney Page 81

End

Remember to prepare for Week 3!

And select your Project Contact!

The University of Sydney Page 82