Climbing the Mountain of Regulatory Documentation for SaMD

Bob Moll
Bob Moll

If you are involved with Software as a Medical Device (SaMD), what regulatory guidance documents do you need to read, and in what order? With over 100 documents to choose from, it can be an overwhelming task. While you will still need regulatory experts, you can get started on building your background by using the table of documents we present at the end of this article. We recommend focusing on the highest-priority documents first, followed by the medium- and then low-priority documents. These documents will help you identify your SaMD’s software classification as well as understand and plan for what you need to submit to the FDA for clearance. Completing these crucial steps ahead of submission will save you time and set your software up for success. 

What is SaMD?

In short, it is standalone software that serves as a medical product in and of itself. While SaMD may take data input from external sensors, it is distinguished from software that is embedded in a medical device (known as SiMD, or Software in a Medical Device). For a more detailed exploration of SaMD, read our white paper “Software as a Medical Device (SaMD): What it is and Why it Matters?”

How is SaMD regulated?

With the exception of four guidance documents from the IMDRF, SaMD is neither specifically called out in FDA or EMA regulatory and guidance documents, nor in medical device standards. This makes it more challenging to explore the document landscape. Our table below will help guide your regulatory journey.

What is the best way to think about draft guidance vs final guidance?

In general, you always want to defer to the final guidance, unless the draft guidance is newer, clearer, safer and not inconsistent with the final guidance. Draft guidance can be extremely helpful when it is clarifying or closing gaps in the current guidance. It can also prepare you for major upcoming changes. 

Use the tables below to help guide your reading. If you’ve still got questions, or simply want to talk to SaMD regulatory experts, feel free to contact us.

Getting Started

ReferenceNotes Priority
Greenlight Guru: The Ultimate Guide to Design Controls for Medical Device CompaniesGood place to start on Design Controls and summary level. Deals with contrast between 13485 and Part 820.High
Classify Your Medical DeviceHow to study and market your device, from the FDA.High

ISO 13485: 2016, Quality management systems─Requirements for regulatory purposeInternational Standard, foundational/ referenced by other standards like IEC 62304 and 14971. Recognized and adopted in the EU; FDA transitioned to this from 820.High
IEC 62304:2006/Amd 1:2015, Medical device software ─Software lifecycle processesThis maps ISO 13485 and ISO 14971 to Software Lifecycle Processes. Written as waterfall, with a one paragraph appendix that says you can use it in non-waterfall ways. Software Safety Classification and Segregation for scaling design controls is a very useful part of this.High
Greenlight Guru: The Definitive Guide to ISO 14971 Risk Management for Medical DevicesAnother good high-level read from Greenlight Guru – read before 14971.
ISO 14971: 2019, Medical devices─Application of risk management to medical deviceReferred to by ISO 13485, IEC 62304 and FDA Guidance. Must read.High
Understanding Intended Use from ISO TR 24971:2020Summarizes key understandings from ISO 24971.High
Deciding When to Submit a 510(k) for a Software Change to an Existing Device; Guidance for Industry and Food and Drug Administration Staff, 2017Important for when you are looking to have more frequent releases.High

SaMD Background

ReferenceNotes Priority
IMDRF: Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding ConsiderationsReferenced by FDA – useful background.Low
IMDRF: Software as a Medical Device (SaMD): Application of Quality Management SystemReferenced by FDA – useful background.Low
FDA: Guidance on Design Considerations and Premarket Submission Recommendations for Interoperable Medical Devices (2017)Very useful if you are looking to develop algorithms, or SaMD that will be integrated with other systems.Medium
Software as a Medical Device (SaMD): Key DefinitionsKey definitions of SaMD from the International Medical Device Regulations Forum.Medium
“Software as a Medical Device”: Possible Framework for Risk Categorization and Corresponding Considerations.Possible Framework for Risk Categorization and Corresponding Considerations for SaMD from the International Medical Device Regulations Forum.Medium
Software as a Medical Device (SaMD): Application of Quality Management System.Application of Quality Management System for SaMD from the International Medical Device Regulations Forum.Medium
Software as a Medical Device (SaMD): Clinical EvaluationGuidance for FDA staff.High

Classification, Regulation, and QMS

ReferenceNotes Priority
Code of Federal Regulations (CFR), Title 21, Part 820, Quality System RegulationDense and dry. We recommend that you read the guidance document FDA Design Control Guidance for Medical Device Manufacturers (1997).Low
FDA Design Control Guidance for Medical Device Manufacturers (1997)Guidance on how to interpret Part 820. Read instead of 820.Medium
IEC 82304-1:2016, Health Software – Part 1: General Requirements for Product SafetyAnother related standard to IEC 62304 – more recently developed, overlaps and extends 62304.Low
FDA: Off-The-Shelf Software Use in Medical Devices; Guidance for Industry and Food and Drug Administration Staff, 2019Similar to SOUP-related guidance in 62304.Medium
FDA: General principles of software validation; Final guidance for industry and FDA staff, 2002Good reference, but mostly covered in other areas. Useful especially for tools validation.Medium
Code of Federal Regulations (CFR), Title 21, Part 11, Electronic Records, Electronic SignaturesDense and dry. Likely only something you need to dig into when you are looking to reengineer processes and tools within your Quality Management System.Low
FDA Precertification Program Working ModelIn pilot, but covers FDA thinking on how precertification works.
EU: Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDRThe EU’s guidance on software classification and regulation.Low
EU: Guidance on clinical evaluation (MDR) / Performance evaluation (IVDR) of medical device software, 2020The EU’s guidance on clinical and performance evaluation of medical device software.Low
EU MDR: Post Market SurveillancePost-market surveillance (PMS) and post-market clinical follow-up (PMCF) requirements.Medium
FDA In Brief: FDA Provides New Draft Guidance on Premarket Submissions for Device Software FunctionsFDA draft guidance for premarket submissions for device software functions.Medium

Agile Practices

ReferenceNotes Priority
AAMI TIR45:2012 Guidance On The Use Of AGILE Practices In The Development Of Medical Device SoftwareMaps IEC 62304 to Agile practices. This is a pretty fast read as a companion to IEC 62304. Does not deal with Risk Management or Cybersecurity; this is being addressed in the next version, currently under development at AAMI.Medium


ReferenceNotes Priority
Post Market Management of Cybersecurity in Medical Devices; Guidance for Industry and Food and Drug Administration Staff, 2016Useful context for how you design for monitoring and how you incorporate for maintenance.Medium
Content of Premarket Submissions for Management of Cybersecurity in Medical Devices; Draft Guidance for Industry and Food and Drug Administration Staff, 2018Useful context. Similar process to patient Risk Management, just focused on Cybersecurity risk. Use the draft guidance from 2018, rather than the one in force from 2014: More current thinking, not likely to change.Medium
FDA: Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket SubmissionsDraft guidance from the FDA on Cybersecurity.Medium


ReferenceNotes Priority
Good Machine Learning Practice for Medical Device Development: Guiding PrinciplesAI machine learning position paper by the FDA. A baseline set of principles on good machine learning practices. A more comprehensive document is expected in 2023.Medium
Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-based Software as a Medical Device (SaMD)U.S. FDA Artificial Intelligence and Machine Learning Discussion Paper. A more comprehensive document that lays out how the FDA might regulate changes to AI/ML based software. There’s a particular emphasis on continuous online learning and what types of changes would not require additional regulatory filing.
The position paper relies on the FDA Precertification working model, which is currently only used in the precertification pilot. Nevertheless, the content is useful if you are looking to implement a factor for an AI algorithm-based SaMD.

Design and Human Factors

ReferenceNotes Priority
IEC 62366 Application of Usability Engineering to Medical DevicesThe FDA’s guidance on applying design and Human Factors practices to medical device design.Medium

Mobile Apps

ReferenceNotes Priority
Multiple Function Device Products: Policy and Considerations; Guidance for Industry and Food and Drug Administration, 2020Context for developing on Mobile and Cloud, useful analogies for what you need to test and validate, and how to do it.Medium
FDA: Medical Device Accessories – Describing Accessories and Classification Pathways; Guidance for Industry and FDA Staff, 2017Useful if mobile or web apps are considered accessories.Medium
FDA: Policy for Device Software Functions and Mobile Medical Applications; Guidance for Industry and Food and Drug Administration Staff, 2019Useful more on what the FDA intends to exercise enforcement discretion on.Low


Related Posts


Bluetooth for Medical Devices: Academic Article Digests


Legacy of Earliest FDA-Cleared Bluetooth Medical Devices


Optimizing BLE Medical Devices: Identifying Edge Cases


Introduction to Bluetooth for Medical Devices