Our Lead Quality Engineer, Nikita Angane, explains how to build a strong Quality Management System for your Software as a Medical Device.

1. www.emmainternational.com
Building a QMS
for Your SaMD
Part I
Nikita Angane, MS
Lead Quality Engineer

2. Leaders in FDA
Compliance Consulting
EMMA International Consulting Group, Inc. is a global leader in management consulting
services. We focus on quality, regulatory, and compliance services for the Life Sciences
industry.
EMMA International is certified as a Women’s Business Enterprise (WBE) through the
Women’s Business Enterprise National Council (WBENC), the nation’s largest third party
certifier of businesses owned and operated by women in the US.
We recognize the commitment to supplier diversity that is embraced by corporations and
government agencies today, and we can add diversity to your supply chain.
2

3. I
II
III
IV
Quality Management System
Adverse Events / Complaints
Continuous Improvement
Enforcement and Compliance
Key Principles for Software
3

4. All requirements set forth in 21CFR
820 are applicable.
Even if you are a software company and
not actually manufacturing a device, as
long as you plan on marketing your
developed software as an SaMD, 21CFR
820 remains the gold standard for QMS.
• Every requirement for a manufacturer
is applicable to you and the SaMD.
Quality Management System
4

5. Key QMS Requirements for SaMD
Management
Controls
Document
Change and
Records
Management
Management
Controls
Quality
Audits
Personnel CAPA
Complaint
Management
Adverse
Event
Reporting
Design and
Development
Controls
Change
Management
5

6. Management Controls
21CFR 820.20 outlines the accountability of the Leadership of an
organization.
• Establishing Quality Policy, Objectives, Project plans, and compliant processes for a healthy and
sustainable QMS.
• Organizational structure with responsibilities and authorities pre-assigned.
Additional requirements for SaMD manufacturing
companies’ leadership includes providing appropriate:
• Software development tools
• Testing environment
• Actual use simulation tools
• Personnel
• Infrastructure
• Hosting environments with third party controls in place if applicable
6

7. Example
For a software development company, assigning someone
with a clinical background for patient safety related
aspects would be beneficial in the long run.
7

8. Quality Audits
As 820.22 states, Internal Audits are a tool
for Management to verify the effectiveness of
the QMS and also an opportunity to correct
the deficiencies before an actual inspection.
Management also has the responsibility to
conduct Management Reviews per 820.20
(c) to make sure the organization is on
track to achieve its quality objectives and
to make any required adjustments.
8

9. Personnel
• The SaMD development
team should consist of
expertise in both the
software engineering and
clinical domains.
• It is important that the
developers understand the
clinical relevance of the
product they are creating
and its impact on patient
safety.
9

10. Personnel
Continuous in-house trainings and educational programs
may address the gap, or
•External consultants can also be an option for you
In cases where
a clinical expert
is not present
on the software
development
team:
10

11. CAPA is the most cited observation
in 483s and warning letters.
For a software company who has not
been in the medical device space
before, CAPA’s can be
overwhelming.
21CFR 820.100 outlines the
requirement for an organization to
implement a CAPA program
CAPA
11

12. CAPA
Sources of CAPA
Customer
Complaints
Field Actions
Design
Nonconformances
Design Reviews
Notified Body
Actions
Management
Reviews
Periodic Quality
ReviewsNonconforming
Material Data and
Reports
Post-Market
Surveillance
Data
Process
Nonconformances
Internal Audit
Results
Quality System
Nonconformances
Trend Data for
any of these
Risk
Management for
any of these
12

13. CAPA
This Photo by Unknown Author is licensed under CC BY
• When used properly, CAPA can provide a systematic and
disciplined way to approach and solve
nonconformities/complaints.
• Supplier CAPA (SCAR) is also a
very effective tool in managing
quality issues with the supplier.
13

14. Complaint Management
• 21CFR 820.198 requires SaMD manufacturers
to have a designated complaint handling unit
to take in customer complaints and maintain
complaint files.
• A customer complaint, depending on the
severity and the definition in your risk
management file or alternatively a trend
analysis of the complaints received may
trigger a CAPA and call for a change in the
product design and development activities.
• These are all aspects of Post-Market
Surveillance.
14

15. Adverse Event Reporting
The 30 day clock begins when any employee of the company becomes
aware that the device:
May have caused or contributed to a death or
serious injury or
Has malfunctioned and this device or a similar
marketed device would be likely to cause or
contribute to a death or serious injury, if the
malfunction were to recur.
Per 21CFR 803, manufacturers are required to report an adverse event on the
FDA Medwatch portal within 30 calendar days of becoming aware of the
incident.
Certain complaints may also be adverse events
15

16. Software Design Control requirements are part of Design Control requirements in 21CFR
820.30.
The requirements apply to:
• Software used as components in medical devices
• Software that is itself a medical device
• Software used in production of the device
• Software used in implementation of the device manufacturer's quality system
Device manufacturers are responsible for the adequacy of the software used in
their devices and used to produce devices. When device manufacturers purchase
"off-the-shelf'' software, they must ensure that it will perform as intended in
their chosen application.
FDA recognizes IEC 62304 when it comes to good software development practices.
Software Design Controls
16

17. • Section 5 – Software Development Process = main process SW groups are focused on and
includes all the key aspects of development from planning and requirements to testing and release.
• Section 6 – Software Maintenance Process = abridged form of main software development
process and is intended to quickly release patches for SW bugs and security risks
• Section 7 – Software Risk Management Process = risk assessment of SW failures as well as
management of SW safety features which serve as risk controls for HW failures, use error, and other
system failures
• Section 8 – Software Configuration Management Process = source code control system/
development environment and how to manage builds and releases
• Section 9 – Software Problem Resolution Process = bug tracking system and how your
organization evaluates bugs and related activities to resolve issues
IEC 62304 At a Glance
17

18. Software Development Process
Software Development Lifecycle Procedure
which includes
• Software Development Management Plan
• Software Requirements Specifications
• Software Architectural Design
Software Verification and Validation
• Software V&V Plan
• Specific requirements are included in CFR 820.30(g).
• Software validation is a part of the design validation for
a finished device, but is not separately defined in the
Quality System regulation.
Deliverables
required by
FDA include
18

19. Software Maintenance Process
Software needs to upgraded with
age as
• Supporting operating systems
change
• Hosting environment change
• User needs change
• Part of continuous improvement
effort
• Regulatory requirements change
• Defects are discovered and
removed
Long after the product has been
introduced in the market, active
post-market surveillance measures
will give rise to
• Continuous improvement
• Corrective changes
Manufacturers are permitted to use a smaller process than the full software
development process to implement rapid changes in response to urgent
problems.
19

20. This Photo by Unknown Author is licensed under CC BY
Software Maintenance Plan
• The maintenance process utilizes the post-market
feedback mechanism in place to modify the current
product.
• Software maintenance includes:
• Corrective
• Perfective
• Adaptive maintenance
• Software maintenance does not include:
• Preventive maintenance actions
• Software component replacement
• Changes made to correct errors and faults in the
software are corrective maintenance.
• Changes made to the software to improve the
performance, maintainability, or other attributes
of the software system are perfective maintenance.
20

21. Software Maintenance Plan
• Software changes to make the software system
usable in a changed environment are adaptive
maintenance.
• Once the modification or the corrective action is
decided, configuration management and change
control procedure should be utilized to approve and
document the change and the release of the revised
software.
• Feedback and other requests for changes can affect
the performance, safety, or regulatory clearance of
the device, hence a thorough analysis is necessary to
determine whether there is any impact.
• Maintenance of products with OTS Software
components may be particularly problematic as the
sponsor does not have control of the OTS Software
component life cycle process.
21

22. Software Risk Management
Software Risk
Management
program should
be per
requirements
set forth in ISO
14971
As part of post-market
surveillance, analyze
every
complaint/feedback
and check to see if the
hazard was included
in the risk
management file of
the device
If the identified
hazard is a newly
found risk, update
the risk management
file of the device to
reflect that and
implement risk
control measures.
22

23. Software Risk Management
Software changes
made as part of risk
control measures
must also be
processed through
the software
configuration and
change management
program.
Appropriate risk
management activities
should be carried out
for software changes
made as part of
proactive post-market
feedback or
maintenance
requirements.
23

24. • When changes are made to a software
system, either during initial
development or during post release
maintenance, sufficient regression
analysis and testing should be
conducted to demonstrate that portions
of the software not involved in the
change were not adversely impacted.
• This is in addition to testing that evaluates the
correctness of the implemented change(s).
Software Configuration and Change Management
24

25. • Software Configuration – version control, change control,
baseline and release management for software products.
• A software configuration and change management plan
must be established by the manufacturer that describes
all Software Configuration and Change Management
Configuration (SCCM) activities to be performed during
the course of a project lifecycle including the activities,
the assigned responsibilities, required resources,
including staff, tools, and computer facilities.
• In the case of AI/ML device, because of their adaptive
nature, FDA has proposed submitting a pre-determined
change control plan which contains:
• SaMD pre-specifications- Anticipated changes for the
algorithm
• Algorithm Change Control Plan- How the developer plans on
implementing these changes This Photo by Unknown Author is licensed under CC BY
Software Configuration and Change Management
25

26. Version control
Version control is used to avoid any conflicting changes, determine the version of the
software in use at a given time and provide a baseline for future change control activities.
Software tools may be used for appropriate version control measures and as
per the requirement of the organization.
Items that can be placed under version control include:
-Source codes -Executables
-Software libraries -OTS software
Software Configuration and Change Management
26

27. Change control
Software Configuration and Change Management
Once the baseline of the software has been released, any changes made from then on has
to be processed via the change control procedure/plan outlined in the SCCM Plan.
Change requests can be approved by a change control board or by a manager
or technical lead according to the software configuration management plan.
Approved change requests are made traceable to the actual modification and
verification of the software.
Each change should be traceable to an approved change request.
27

28. Documentation of Changes
• Proposed changes must be approved by an internal change review
board or any such higher authority.
• All records of change approval must be preserved, and every change
made since the original submission must be traceable to an approved
change request.
This Photo by Unknown Author is licensed under CC BY-SA
• Documentation Updating – Documentation
should be carefully reviewed to determine which
documents have been impacted by a change. All
approved documents (e.g., specifications, test
procedures, user manuals, etc.) that have been
affected should be updated in accordance with
configuration management procedures.
Specifications should be updated before any
maintenance and software changes are made.
28

29. • In Part II, we will cover how to design post market activities for
your SaMD.
• Topics that will be covered under Part II include:
• Changes made to the software post market
• Verification and validation activities
• Regulatory clearance of changes made to the software post market
Part II coming soon..
29

30. References
1. https://www.aami.org/newsviews/newsdetail.aspx?ItemNumber=6475
2. http://sunstonepilot.com/2018/09/fda-software-guidances-and-the-iec-62304-software-
standard/
3. https://www.medicalplasticsnews.com/news/medical-devices/five-big-medical-device-recalls/
4. https://www.fda.gov/medical-devices/postmarket-requirements-devices/recalls-corrections-
and-removals-devices
5. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-
premarket-submissions-management-cybersecurity-medical-devices-0
6. IEC 62304: 2006
7. https://promenadesoftware.com/blog/simplified-fda-and-iec62304-software-deliverables
8. http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-151002-samd-qms.pdf
9. https://www.fda.gov/medical-devices/device-advice-comprehensive-regulatory-
assistance/unique-device-identification-udi-system
10. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/deciding-when-
submit-510k-software-change-existing-device
30

31. 31