The document provides an overview of Software as a Medical Device (SaMD), outlining its definition, development procedures, requirements, maintenance, and classification. It also discusses the FDA's pre-certification program, detailing the process for companies seeking pre-cert status, including the Culture of Quality and Organizational Excellence (CQOE) framework. Additionally, it highlights the importance of real-world performance analytics and resources available from the FDA regarding SaMD.

1. Food for Thought Series Session
An Overview for
Software as a Medical Device
SaMD
Presented by
Harshal Dear
Regulatory Affairs Specialist, West Chester
HDear@its.jnj.com

2. Content
• What is SaMD
• Software Development Procedure
• Requirements
• Design
• Implementation
• Integration and Test
• Design Transfer (to production)
• Maintenance
• SaMD Classification
• FDA “Precertification” Program
• Culture of Quality and Organizational Excellence (CQOE) framework
• Streamlined Pre-Market Review
• Post Launch - Multi-stakeholder Real-world Performance Analytics
• Clinical Evaluation & Evidence Collection
• Resources

3. What is SaMD?
SaMD is software that performs one or more medical functions.
SaMD Basic Programming Model

4. Software Development Procedure

5. Software Development Life Cycle
• Typical SDLC phases are:
• Requirements
• Design
• Implementation
• Integration and Test
• Design Transfer (to production)
• Maintenance

7. Requirements Phase
• Customer Requirements document
• Software (or Project) Development Plan
• Software Quality Assurance Plan:
• Defines standards to be used (e.g., coding standards, documentation standards)
• Defines review and audit plan
• Specifies configuration management plan
• Usually generated by Quality Assurance, with input from Engineering
• Software Requirements Specification (SRS)
• Should specify requirements, not design
• Should be unambiguous and testable
• Must be traceable to Customer Requirements
• Preliminary Risk (or Hazard) Analysis
• Identifies safety requirements
• Various techniques can be used
• Failure Modes and Effects Analysis (FMEA)
• Failure Modes, Effects and Criticality Analysis (FMECA)
• Fault Tree Analysis (FTA)
• Preliminary Software Validation Plan
• System Testing (e.g., test that requirements have been met)
• Design Review of all Requirements Phase Outputs
• Meeting minutes
System Description
External Interface Requirements
Functional Requirements
Performance Requirements
Safety Requirements
Design Constraints
References
Risk assessment (criticality)
Severity (S) – seriousness of effect of failure
Occurrence (O) – likelihood of failure
Detection (D) – ability to detect failure
Risk Priority Number (RPN) = (S) x (O) x (D)

8. Design Phase
• Software Architectural Design
• Architecture diagrams, data flow diagrams, etc.
• Software Detailed Design
• Software Design Specification (SDS)
• Traceability analysis from SDS to SRS
• Update Software Validation Plan
• Integration testing
• Update Risk Analysis
• Design Review II

9. Implementation Phase
• Write software according to Software Quality Assurance Plan (SQAP):
• Programming Guidelines
• Documentation Standards
• Update Software Validation Plan
• Unit or module testing
• Traceability analysis (SVP to SDS/SRS)
• Run module tests and write Test Reports

10. Integration and Test Phase
• Run Integration Tests and write Test Reports
• Run System Tests and write Test Reports

11. Design Transfer
• Write relevant manufacturing procedures
• Software installation procedure
• Software duplication procedure
• Ensure user documentation is complete
• Labeling review
• Release software
• Change control procedure

12. Maintenance Phase
• Review and update any necessary documents
(e.g., SRS, Risk Analysis, SDS)
• Implement changes
• Assess testing requirement
• Test changes
• Possible regression testing
• Release via Change Control Procedure

14. Requirements Design Implementation Integration & Test Design transfer (to production) Maintenance
Risk Management Report
Design And Development
Plan
User Requirements
Specification
System Requirements
Specification
Software Requirements
Specification
Software Specification
Supporting Material
Design Requirements
Specification
Unit Test Plan
Unit Test Protocol
Unit Test Report
Code Review Checklist
System Requirements
Traceability Matrix
System Integration Test Plan
System Integration Test
Protocol
System Integration Test
Report
Design Review for Medical
Device Software
QMS Documents outputs during SDLC

15. SaMD Classification

17. FDA “Precertification” Program
Since launching the program, the FDA has selected nine pilot participants representing a diverse
range of SaMD developers
1. Apple (Cupertino, California)
2. Fitbit (San Francisco, California)
3. Johnson & Johnson (New Brunswick, New Jersey)
4. PEAR Therapeutics (Boston, Massachusetts)
5. Phosphorus (New York, New York)
6. Roche (Basel, Switzerland)
7. Samsung (Seoul, South Korea)
8. Tidepool (Palo Alto, California)
9. Verily (Mountain View, California)

18. How FDA Pre-Cert Works
1. CQOE assessment.
A company seeking Pre-Cert status for its SaMD begins by creating an online account and providing the FDA
access to evaluate the company’s CQOE through organizational perspectives and excellence outcomes data, and
the performance of the company’s SaMD products already on the market, if applicable. The CQOE score
determines its Pre-Cert level. The more a company can demonstrate its commitment to a “culture of quality and
organizational excellence” the higher the Pre-Cert level it may achieve.
2. Product categorization.
The FDA categorizes the company’s SaMD according to the risk categorization framework.
3. Pre-Cert determination.
The CQOE score, in combination with the device’s SaMD risk category, determines the product’s ultimate path to
market. Those companies that qualify for Pre-Cert may be able to get into a shorter approval queue, provide less
data to FDA in the pre-market stage, or skip other steps in the approval process.
4. Post-market surveillance.
All SaMD products in categories I to IV remain under post-market surveillance. The company’s CQOE score and
Pre-Cert level may change based on post-market surveillance data.

19. Culture of Quality and Organizational Excellence
(CQOE) framework

20. FDA Pre-Cert in practice

21. Streamlined Pre-Market Review

22. SR : Streamlined Premarket Review L1 : Pre Cert Level1 L2 : Pre Cert Level 2

23. Streamlined Review

24. Post Launch
Multi-stakeholder Real-world Performance Analytics
The following sources of RWD that can contribute to the evaluation of Pre-Cert eligibility

25. Clinical Evaluation & Evidence Collection

27. Resources:
Relevant guidance docs from FDA on SaMD
• Software as a Medical Device (SAMD): Clinical Evaluation
• Changes to Existing Medical Software Policies Resulting from Section 3060 of 2the 21st Century Cures Act
• Applying Human Factors and Usability Engineering to Medical Devices
• Clinical and Patient Decision Support Software
• Software Precertification Program: 2019 Test Plan
• Software Precertification Program: Regulatory Framework for Conducting the Pilot Program within Current
Authorities
• Software Precertification Program: Working Model
• General Principles of Software Validation; Final Guidance for Industry and FDA Staff
• Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices
• Content of Premarket Submissions for Management of Cybersecurity in Medical Devices
• Postmarket Management of Cybersecurity in Medical Devices
• Cybersecurity for Networked Medical Devices Containing Off the-Shelf (OTS) Software
• IEC 62304:2006 Medical device software – Software life cycle processes

28. Questions?