Overview of Quality Management System (QMS)

Overview of Quality

Management System

(QMS)Yan Chia

November 2021

Hi, I’m Jane!

I bake cakes!

Upgrade!

Investigate – equipment, process, materials

How to solve the problems?

Quality Objectives

Process & Production Control

Customer Requirements Procedures &

Work InstructionsTraceability – Lot Number Supplier Quality

Design Control

Risk Management Inputs / Outputs Verification & Validation

Change Management

Change Management Risk Review

Resources

Training Work EnvironmentInfrastructure

Corrective & Preventive Action

Manage Non-conformities Verify EffectivenessProcess Improvement

Product Surveillance

Complaint Handling VigilanceRisk Monitoring

Management Responsibility

Management Review Internal AuditInspection Readiness

Happy customers!

Happy staff!

Happy boss!

5 stars review!

Advantages of QMS

How to implement QMS to a

MedTech Company?

Legislative Hierarchy

Formal, broad description of the

law (mandatory)

Support the Act, providing more detailed

information (mandatory)

Provide guidance to comply with and

achieve goals imposed in regulations

(mandatory if referenced by an Act or

Regulation. Otherwise, voluntary)

Provide guidance to comply with and

achieve goals imposed in standards

(voluntary)

Criteria within an industry (mandatory if

referenced by an Act or Regulation.

Otherwise, voluntary)

Regulations & Standards

ISO 13485 – Medical Devices QMS

FDA 21 CFR Part 820 – Quality System Regulation

EU MDR – European Medical Device Regulation

IEC 62304 – Medical device software – Software life cycle processes

IEC 62366-1 – Medical Device Usability Engineering

ISO 14971 – Risk Management

Document System Hierarchy

Describes the QMS & Policy

Describes the processes of the QMS

Used to record the data

Provide detailed information pertaining

to specific events or a series of related

events

Describes the tasks within the processes

Therac-25 Incident

1985 – 1987

Therac-25

What Happened?

June 1985

Katie Yarborough, 61

200 Rads

Medical Physicist, Tim Still

PDP-11 Computer

1990

2nd incident

June 1985

Ontario, Canada

3rd incident

Yakima, Washington

4th incident

Tyler, Texas

5th incident

1986

6th incident (final)

1987

Fritz Hager

Malfunction-25 =

Overdose/ Underdose

Unknown

“dual-mode” radiation-

therapy machines

Electron Mode

X-Ray Mode

Therac-20

Hardware Interlock

Assembly

What happened next?

The FDA declared the Therac-25 DEFECTIVE

AECL issued software patches and hardware updates which

eventually allowed the machine to return to service

The lawsuits were settled out of court

The problems were solved until…

Another problem

January 1987

Counter-overflow

Unscanned Beam & Overdose

Patient died 3

months later

Where is the responsible

programmer?

Who’s fault?

The programmer?

The Manager?

The Business Owner?

Never Blame People,

Blame the System

Root cause - Company’s system problem

Software requirements and design documentation were written as an after-

thought

No quality systems in place to control the design and development of software

Inadequate testing

Only system-level software testing was performed

No unit level or integration level testing was evident

No plan for regression testing of all software changes

Software’s user interface was confusing to the user

Error messages were cryptic

User manual was difficult to understand – no explanation of the error codes or any

guidance for the user when error codes were displayed

Root cause - Company’s system problem

Risk assessment

Only performed risk assessment for hardware, not software

Removed the interlock (fuse) in the hardware without doing risk assessment

Assume product is safe purely because prior generation was safe

Design issue

Lack of defensive design (no adequate cross checks, error detection, and error-

handling capabilities)

E.g., when the error message pops up, it should stop the machine from functioning

until certain action is in place

Inadequate investigations or follow-up on complaints

Root cause - Company’s system problem

Resources

Programmer did not have experience in the Assembly language

Engineers did not have sufficient training

What happened to AECL?

What happened to AECL?

Therac-25 discontinued, recalled

AECL dissolved AECL Medical in 1988 and renamed it Theratronics

International Ltd

No longer makes linear accelerators

Despite passing repeated Canadian safety inspections, the company

has suffered through an FDA ban on all its medical equipment from

1991 to 1994

Changes to the FDA since then

Define more requirements to regulate medical devices, focus on

software

Power to inspect the work of manufacturers, ask manufacturers to

recall products, issue injunctions against distribution of products if

non-compliant

Issue guidance documents

This incident also have an impact on other federal agencies including

the US Federal Aviation Administration and Nuclear Regulatory

Commission – these agencies also govern software-development

practices like the FDA

Case study gives us the opportunity

to learn from past mistakes

Over 35 years later, some companies

are still struggling with many of the

same issues as the Therac-25 incident

An effective QMS will reduce the

product risk to the patient, user and

company

The QMS wouldn’t work by just relying

on a single person in an organisation

It will only work if everyone is trained

and comply with the QMS