Buy the GCP R3 course & get a FREE eBook— your complete ICH-GCP R3 reference guide. Book Now →

  • AI ClinicalAI ClinicalNewRight Arrow
  • Clinical PracticeClinical PracticeRight Arrow
  • PharmacovigilancePharmacovigilanceRight Arrow
  • ManufacturingManufacturingRight Arrow
  • Laboratory PracticeLaboratory PracticeRight Arrow
  • DistributionDistributionRight Arrow
  • Medical DevicesMedical DevicesRight Arrow
  • Regulatory AffairsRegulatory AffairsRight Arrow
  • Research ComplianceResearch ComplianceRight Arrow
  • Health & SafetyHealth & SafetyRight Arrow
  • Quality AssuranceQuality AssuranceRight Arrow
  • All Bundles
  • Clinical Trials Development
  • GCP & GxP Standards
  • Pharmacovigilance
  • Role Based
  • Distribution
  • Medical Devices
  • Medical Writing
  • AI Clinical
View all 21 learning paths
  • Preclinical & Laboratory Foundations Learning Path
  • Phase I – First-in-Human Trials Learning Path
  • Phase II & III – Efficacy & Pivotal Trials Learning Path
  • Clinical Trials Foundation PathNew
  • Regulatory Submission & Approval
Preclinical & Laboratory Foundations Learning Path - courses at £199

About

Software as a Medical Device (SaMD) is transforming healthcare by enabling software to perform medical functions independently of dedicated medical hardware. Developing compliant SaMD requires a structured approach to software engineering, risk management, quality systems, cybersecurity, and regulatory compliance throughout the product lifecycle.
This Software as a Medical Device (SaMD) Training Course & Certification provides comprehensive knowledge of SaMD concepts, global regulatory frameworks, software lifecycle processes, IEC 62304, IEC 82304-1, ISO 14971, software safety classification, quality management systems, software verification and validation, cybersecurity, release management, maintenance, and post-market activities. Upon successful completion, learners receive a certification demonstrating their understanding of SaMD development, regulatory expectations, and industry best practices.

Who Should Enrol?

  • Medical Device Software Engineers and Developers
  • Software Architects and Technical Leads
  • Quality Assurance and Quality Management Professionals
  • Regulatory Affairs and Compliance Professionals
  • Risk Management and Cybersecurity Specialists
  • Verification, Validation, and Software Test Engineers
  • Medical Device Manufacturers and Product Managers
  • Anyone involved in the development, validation, regulation, or maintenance of Software as a Medical Device (SaMD)
📢 Every purchase also includes our FREE companion Software as a Medical Device eBook, designed to help you apply principles in real-world clinical trial settings.

What you will learn

Understand the fundamentals of Software as a Medical Device (SaMD), its intended use, regulatory definitions, and how it differs from traditional medical devices and software in medical devices.

Learn global SaMD regulatory requirements, software safety classification, quality management principles, and applicable standards including IEC 62304, IEC 82304-1, ISO 14971, and IMDRF guidance.

Develop knowledge of software development lifecycle processes, requirements management, architecture, verification, validation, cybersecurity, risk management, and software maintenance.

Gain practical understanding of software release, post-market surveillance, problem resolution, configuration management, documentation, and regulatory compliance best practices for SaMD products.

Course Syllabus

  1. Section 1.1 — What is software, actually?
  2. The layers: hardware, operating system, platform, application
  3. Firmware — software that lives inside the thing
  4. Applications, mobile applications, web applications
  5. Mobile applications — why they carry extra risk
  6. Web applications and the browser as a platform
  7. Cloud software — someone else's computer, your responsibility
  8. Software platforms — what you are standing on
  9. Algorithms — a recipe, written down
  10. Artificial intelligence — an umbrella, not a technology
  11. Machine learning — rules learned from data
  12. Locked models and adaptive models
  13. Software components, items and units
  14. Interfaces — where two pieces of software meet
  15. APIs — an interface with a published contract
  16. Databases — where the clinical evidence actually lives
  17. Operating systems — the software you did not write but depend on
  18. Section 1.2 — the words that carry legal weight
  19. Health software — the widest circle
  20. Medical-device software (MDSW) — the European term
  21. Software as a Medical Device (SaMD)
  22. Software in a Medical Device (SiMD) — embedded software
  23. Drawing the line: three worked calls
  24. Clinical decision-support software
  25. Digital therapeutics
  26. Medical mobile applications
  27. Connected devices and remote monitoring
  28. Software accessories
  29. Software modules — when part of a product is the device
  30. Software functions — the US vocabulary
  31. The terminology map — one picture to keep
  32. Section 1.3 — why software is not like a hinge
  33. Intangibility — you cannot inspect what you cannot see
  34. Complexity — the state space nobody can walk
  35. Replication — perfect copies, perfect defects
  36. Rapid change — the device you validated is not the device in the field
  37. No physical wear — the bathtub curve does not apply
  38. Systematic faults — the central teaching point
  39. Why hardware reliability statistics do not transfer
  40. So testing volume is not the control — rigour is
  41. Dependency on platforms
  42. Dependency on networks
  43. Cybersecurity exposure — and the distinction to hold
  44. User-interface dependence — the screen is part of the device
  45. Configuration dependence
  46. Data dependence — the input you do not control
  47. Section 1.4 — intended purpose decides everything
  48. Medical purpose — what actually counts
  49. Intended users — who is holding it, and what do they know?
  50. Patient population — who is it for, and who is it not for?
  51. Use environment — where will this actually be used?
  52. Inputs — what goes in, and can you trust it?
  53. Outputs — what comes out, and what will be done with it?
  54. Clinical decisions — how strongly does the software drive them?
  55. Limitations — the honest paragraph
  56. Contraindications — when the device must not be used
  57. Foreseeable misuse — what people will actually do
  58. Anatomy of an intended-purpose statement
  59. Same software, different intended purpose, different device
  60. The trap: writing the intended purpose to dodge the rules

  1. Section 2.1 — How Europe regulates software
  2. Regulation (EU) 2017/745 — what is actually in it
  3. Who is who under the MDR
  4. Two questions, in this order: qualification, then classification
  5. MDCG 2019-11 Rev.1 — the guidance that governs both
  6. Qualification — is it a medical device at all?
  7. The qualification decision path
  8. The 'acts on data' test — where the arguments happen
  9. Software modules — when part of a product is the device
  10. Software that drives or influences a device
  11. Classification — Annex VIII and its implementing rules
  12. Rule 11 — the rule that decides most software
  13. Rule 11, branch A — 'information used to take decisions'
  14. Rule 11 escalation — when it becomes Class III
  15. Rule 11 escalation — when it becomes Class IIb
  16. Rule 11, branch B — monitoring physiological processes
  17. Rule 11, branch C — 'all other software' is Class I
  18. Rule 11 as a decision tree
  19. Teach the reasoning, not the answer
  20. Other Annex VIII rules can bite harder than Rule 11
  21. What the class buys you: conformity-assessment routes
  22. The notified body — what they actually do
  23. Annex I — the General Safety and Performance Requirements
  24. Annex I, section 17 — the software requirements
  25. Technical documentation — Annex II
  26. Technical documentation on post-market surveillance — Annex III
  27. Clinical evaluation for medical-device software
  28. Post-market surveillance — Articles 83 to 86
  29. Vigilance — serious incidents and field safety corrective actions
  30. Significant changes — when a change reopens the assessment
  31. UDI, EUDAMED and registration — the housekeeping that is not optional
  32. Section 2.2 — a different architecture entirely
  33. Device software functions — the US unit of analysis
  34. Intended use — the American cousin of intended purpose
  35. Software functions that are not devices — and enforcement discretion
  36. US risk classification — Class I, II and III
  37. Finding your classification — regulation numbers and product codes
  38. The premarket pathways — an overview
  39. 510(k) — substantial equivalence
  40. De Novo — novel, but not high risk
  41. PMA — premarket approval
  42. The QMSR — the US quality-system framework
  43. Software documentation levels — Basic and Enhanced
  44. What makes a device software function Enhanced?
  45. What you actually submit at each level
  46. Cybersecurity in premarket submissions
  47. US post-market responsibilities
  48. US software changes — when do you need a new submission?
  49. Predetermined change control plans — changing without resubmitting
  50. EU and US side by side — where they agree and where they do not
  51. Section 2.3 — the international picture, at high level
  52. IMDRF SaMD terminology
  53. The IMDRF SaMD risk categorisation framework
  54. The IMDRF categories I to IV
  55. Regulatory convergence — where the world agrees
  56. Jurisdictional differences — where the world does not agree
  57. Section 2.4 — three classifications, not one
  58. The most important distinction in this course
  59. Different scales, decided at different times
  60. Why a Class IIa device contains Class C software
  61. Why the conflation happens
  62. The order of operations — one slide to keep

  1. Section 3.1 — Why a quality-management system exists at all
  2. What a quality-management system actually is
  3. ISO 13485:2016 — what it is, and what it is not
  4. ISO 13485 and ISO 9001 — related, but not the same animal
  5. The shape of ISO 13485 — the clause map
  6. The QMS is the wrapper — where the software lifecycle sits
  7. Where the law requires a QMS
  8. The FDA QMSR — effective 2 February 2026
  9. The certification rule — say it exactly right
  10. Design and development controls — the spine of clause 7.3
  11. Design and development planning (ISO 13485, 7.3.2)
  12. Design and development inputs (7.3.3)
  13. Design and development outputs (7.3.4)
  14. Design and development review (7.3.5)
  15. Design and development verification (7.3.6)
  16. Design and development validation (7.3.7)
  17. Design and development transfer (7.3.8)
  18. Control of design and development changes (7.3.9)
  19. The design and development file (7.3.10) — the design history
  20. Document control (ISO 13485, 4.2.4)
  21. Record control (4.2.5)
  22. Records in a software organisation — where they actually live
  23. Purchasing and supplier control (7.4)
  24. Risk management inside the QMS
  25. ISO 14971:2019 in one slide
  26. ISO/TR 24971:2020 — guidance, not requirements
  27. The three things called 'validation' — and how to tell them apart
  28. Validation of software used in the QMS (4.1.6)
  29. Corrective and preventive action (8.5.2 and 8.5.3)
  30. Correction, corrective action, preventive action — in software
  31. Change control across the QMS
  32. Complaint handling (8.2.2)
  33. Reporting to regulatory authorities (8.2.3) — vigilance
  34. Post-market surveillance
  35. Internal audit and management review
  36. Section 3.2 — the gap that IEC 62304 deliberately leaves
  37. IEC 82304-1:2016 — scope and identity
  38. What is a 'health software product'?
  39. The stages IEC 82304-1 addresses
  40. Product requirements — the heart of IEC 82304-1
  41. Product requirements — the operating environment
  42. Product requirements — security and privacy as product requirements
  43. Product design and development — where 82304-1 hands over
  44. Product validation under IEC 82304-1
  45. Three activities, three different questions
  46. Accompanying documentation — the requirement everyone underestimates
  47. Information for safety is the weakest risk control
  48. Product identification and versioning
  49. Installation
  50. Operation
  51. Maintenance of the product in the field
  52. Decommissioning — the stage nobody plans
  53. Product safety — what 'safe' means at product level
  54. Product security — and where IEC 81001-5-1 comes in
  55. Section 3.3 — the interlock
  56. What each standard is FOR — one sentence each
  57. IEC 62304 vs IEC 82304-1 — process and product
  58. ISO 13485 as the wrapper — it holds all the others
  59. IEC 62366-1 — use error is a hazard source
  60. IEC 81001-5-1 — security activities across the lifecycle
  61. Regulatory requirements sit above them all
  62. Harmonised standards and the presumption of conformity
  63. Section 3.4 — three releases, and they are not the same event
  64. Gate 1 — software release (IEC 62304, clause 5.8)
  65. Gate 2 — product release (IEC 82304-1 / ISO 13485)
  66. Gate 3 — regulatory release (placing on the market)
  67. The three gates, side by side
  68. The standards applicability matrix (T004)
  69. Where the interlock fails in practice

  1. Section 4.1 — Why IEC 62304 exists
  2. The effective edition — and why that matters
  3. Purpose — what IEC 62304 is actually FOR
  4. Scope — what IEC 62304 covers
  5. Scope — what IEC 62304 does NOT cover
  6. The three things IEC 62304 assumes you already have
  7. The structure of the standard — navigate it by clause
  8. The five processes — one runs, four never stop
  9. Software SYSTEM, software ITEM, software UNIT
  10. The vocabulary that catches people out
  11. Compliance evidence — what conformity actually looks like
  12. Legacy software — the honest route (Clause 4.4)
  13. Legacy software — what field experience can and cannot prove
  14. Legacy software — the gap analysis, honestly done
  15. Looking ahead — IEC 62304 Edition 2 (not published)
  16. Section 4.2 — Software safety classification: the one question
  17. What a HAZARDOUS SITUATION is — and why the word matters
  18. The assumption that changes everything: assume the software fails
  19. Why probability is not a lever — the systematic-failure argument
  20. The classification decision — as a decision tree
  21. Risk-control considerations — which controls can lower a class
  22. Software SYSTEM class versus software ITEM class
  23. SEGREGATION — what it actually means
  24. Segregation mechanisms — from strongest to weakest
  25. Segregation — how to VERIFY it
  26. The item-class 2x2 — the only quadrant that earns a lower class
  27. The three ways teams get segregation wrong
  28. What changes when an item is Class A rather than Class C
  29. Initial classification — when, and by whom
  30. RECLASSIFICATION — the class is a decision, not a fact
  31. Keep the two classifications apart — permanently
  32. Documenting the classification — the deliverable is the rationale
  33. Architecture-based risk control — the class is an architecture problem
  34. Section 4.3 — The lifecycle processes: what the standard does NOT say
  35. Clause 5 — the development process, end to end
  36. 5.1 Software development planning
  37. 5.2 Software requirements analysis
  38. 5.3 Software architectural design — Class B and C
  39. 5.4 Software detailed design — Class C only
  40. 5.5 Software unit implementation and verification
  41. 5.6 Software integration and integration testing — Class B and C
  42. 5.7 Software system testing — Class B and C
  43. 5.8 Software release
  44. Clause 6 — the software maintenance process
  45. Clause 7 — the software risk management process
  46. Clause 8 — software configuration management
  47. Clause 9 — the software problem resolution process
  48. Traceability — the connective tissue of the whole standard
  49. Section 4.4 — Applicability: the class decides the work
  50. The applicability matrix — activity by class
  51. What Class A does NOT excuse you from
  52. Justified tailoring — what it is, and what it is not
  53. Organisational procedures versus product-specific plans
  54. Supplier activities — you may outsource the work, never the responsibility
  55. Evidence by class — what an auditor will ask for
  56. The ten classification errors that cost real money

  1. Section 5.1 — Software risk management: the shape of the problem
  2. The four words — and they are not interchangeable
  3. The ISO 14971 chain — the single most important diagram in this module
  4. Software does not cause harm — it starts a sequence of events
  5. Probability is the trap
  6. Where probability legitimately survives — and where it does not
  7. The risk matrix, honestly labelled
  8. The software failure modes — a working taxonomy
  9. Use error — the software worked perfectly and the patient was harmed
  10. Data error — wrong, stale, lost, duplicated, out of order
  11. Interface failure — the contract nobody wrote down
  12. Cybersecurity-related safety risks — the bridge into section 5.4
  13. Writing a sequence of events that an auditor can follow
  14. Section 5.2 — ISO 14971:2019: the process you must plug into
  15. The risk-management plan — what it must actually decide
  16. Hazard identification for software — techniques that actually work
  17. Risk estimation — severity scales that survive contact with a clinician
  18. Risk evaluation — and the honest conversation it forces
  19. Risk control — the order of priority is not a suggestion
  20. What each level of control looks like IN SOFTWARE
  21. Risk controls implemented IN software are themselves software
  22. Verification of risk controls — you must verify it TWICE
  23. Risks arising FROM risk controls — the second-order hazard
  24. Residual risk — individual, and overall
  25. Benefit-risk analysis — the last resort, not the first argument
  26. Production and post-production information — the loop that closes
  27. The risk-management report — what it must conclude
  28. How IEC 62304 Clause 7 sits inside ISO 14971
  29. Section 5.3 — The development process IS a risk control
  30. Fault introduction and fault survival — where each activity acts
  31. Requirements quality as a risk control
  32. Architecture as a risk control
  33. Segregation as a risk control — and its evidence
  34. Defensive design — assume every input is wrong
  35. Coding standards — eliminating defect classes by construction
  36. Static analysis and reviews — catching what testing cannot
  37. Testing is a detection control — and it has hard limits
  38. Configuration management as a risk control
  39. Change control as a risk control
  40. Section 5.4 — Safety risk and security risk are not the same thing
  41. The intersection — where a security failure becomes a safety hazard
  42. The security vocabulary — asset, threat, vulnerability, attack surface
  43. Threat modelling — a defensive discipline
  44. Security requirements — where the threat model becomes buildable
  45. Secure architecture — defence in depth, and least privilege
  46. Authentication and authorisation — two different questions
  47. Encryption, integrity and key management
  48. Logging and audit — the control that makes everything else investigable
  49. The update mechanism — your most powerful control, and your biggest risk
  50. The software bill of materials — what it is FOR
  51. The SBOM and the SOUP register — the same information, two purposes
  52. Vulnerability management — a continuous process, not an event
  53. Coordinated vulnerability disclosure
  54. Post-market cybersecurity — the regulatory position
  55. Cloud and third-party risk — you outsourced the work, not the responsibility
  56. Section 5.5 — IEC 81001-5-1:2021: what it is, and what it is for
  57. The secure lifecycle processes — what 81001-5-1 asks of you
  58. Security risk management inside 81001-5-1 — and its link to 14971
  59. Secure implementation, verification and release
  60. Maintenance and vulnerability response under 81001-5-1
  61. Integrating the three standards — one lifecycle, not three projects
  62. The ten risk and security errors that cost real money

  1. Section 6.1 — Planning: the deliverable that governs every other deliverable
  2. The plan is itself a deliverable — and it is maintained
  3. Planning is proportionate to the software safety class
  4. What Clause 5.1 asks the plan to address
  5. The lifecycle model — IEC 62304 does not choose one for you
  6. Agile and IEC 62304 — compatible, and commonly done
  7. Scope — what the plan covers, and what it deliberately does not
  8. Roles and responsibilities — named, competent and resourced
  9. Deliverables — the list you will be audited against
  10. Reviews and milestones — where the plan meets reality
  11. Risk-management activities inside the plan (Clause 5.1.7)
  12. Configuration and change management in the plan (Clause 5.1.9)
  13. Problem resolution in the plan (Clause 9, planned at 5.1)
  14. Verification planning (Clause 5.1.6) — decided before, not after
  15. Validation — planned here, owned elsewhere
  16. Tools — the ones that build your device are part of your device's story
  17. Suppliers — you may outsource the work; you cannot outsource the responsibility
  18. Maintenance and post-market activities — planned before you ship
  19. Cybersecurity activities in the plan
  20. Documentation planning and common software defects (5.1.8, 5.1.12)
  21. The five planning failures that generate findings
  22. Section 6.2 — Configuration management: the question that decides everything
  23. Clause 8 — three processes, not one
  24. Configuration items — what actually counts
  25. SOUP is a configuration item — and the standard says exactly what to record
  26. Baselines — the noun that makes 'the software' a thing
  27. Version control — the tool, and what it does not give you
  28. Software versioning and configuration identification (LO31)
  29. Branching — a strategy, not an accident
  30. Build identification — the binary must be able to tell you what it is
  31. Reproducible builds — the discipline behind the promise
  32. Environment configuration — the software is not the only thing you ship
  33. Infrastructure as code — control the infrastructure the way you control the code
  34. Access controls — who may change the controlled thing
  35. Backup, recovery and retention — the records must outlive the project
  36. Change control (Clause 8.2) — the loop every change must close
  37. Impact analysis — the step that decides how much re-verification you owe
  38. Configuration status accounting (Clause 8.3) and the change history
  39. Release identification — what 'released' actually means
  40. Section 6.3 — SOUP: the code you did not write, and are answerable for
  41. What SOUP actually means — three tests, all of which must hold
  42. SOUP is NOT a synonym for open source
  43. The families of SOUP — and what each one hides
  44. Transitive dependencies — the SOUP you did not choose
  45. What you must specify for every SOUP (Clauses 5.3.3 and 5.3.4)
  46. Known anomalies (Clause 7.1.2) — the requirement people have never heard of
  47. SOUP and risk (Clause 7.1.2 continued) — the failure you cannot fix
  48. SOUP evaluation — the criteria that make the decision defensible
  49. Licensing — a legal question with an engineering consequence
  50. Reading a SOUP register row properly
  51. SOUP cybersecurity — monitoring is the requirement, not the aspiration
  52. PR-1063 — the three things a SOUP upgrade is not
  53. End of life — the SOUP will outlive its maintainer, or you will outlive the SOUP
  54. Monitoring — the obligation that never ends
  55. Cloud and third-party risk — accountable for what you do not control
  56. The SLA is not a risk control — unless you verify it
  57. A managed service can be updated underneath you
  58. Controls for cloud and third-party SOUP
  59. How the three machines fit together
  60. The ten errors that cost real money

  1. Section 7.1 - Software requirements: the contract everything else is measured against
  2. Where requirements sit: the inputs, and where they come from
  3. Clause 5.2 in outline - what the standard actually asks for
  4. The central rule: a requirement you cannot verify is not a requirement
  5. 'The system shall be fast' - the rewrite
  6. Requirements are risk controls - and vague requirements are a safety problem
  7. The eleven categories - and why teams only write the first one
  8. Functional requirements - what the software must do
  9. Performance requirements - how well, under what load, how often
  10. Interface requirements - the three interfaces people forget
  11. Safety requirements - where the risk control lands
  12. Security requirements - a different kind of risk, in the same specification
  13. Usability requirements - the ones that stop being optional when the user is a clinician
  14. Data requirements - the category that quietly carries the most risk
  15. Regulatory requirements - the obligations that are also software behaviour
  16. Installation, maintenance and update requirements - the whole life of the product
  17. The five qualities of a usable requirement
  18. Verifiability - the quality that makes the others possible
  19. Unambiguity - and the six words that destroy it
  20. Traceability - the quality that turns a specification into evidence
  21. Completeness - a property of the set, not of a sentence
  22. No implementation bias - say WHAT, not HOW
  23. Clause 5.2.5 - verifying the requirements themselves
  24. Clause 5.2.3 - writing requirements changes the risk analysis
  25. The traceability matrix - what it is, and what it proves
  26. Requirements under change control - and why the baseline matters
  27. The requirement failures that generate findings
  28. Section 7.2 - Architecture: where the safety class is earned
  29. Clause 5.3 in outline - what the architecture must actually contain
  30. The vocabulary: software system, software item, software unit
  31. The architecture as a picture: items, interfaces, data flow
  32. Data flow - follow the clinical data, and classify what it touches
  33. Control flow - who decides what, and what happens when nobody does
  34. Segregation - what it actually means, and what it does not
  35. How segregation is actually built
  36. Verifying that segregation works - the part everyone skips
  37. Fault containment - designing for the failure you know is coming
  38. Redundancy and diversity - and when redundancy buys you nothing
  39. SOUP in the architecture - Clauses 5.3.3 and 5.3.4, in their proper place
  40. Cloud architecture - accountable for infrastructure you do not run
  41. Distributed systems - the failures that only exist between the boxes
  42. Mobile architecture - the platform is not yours, and it changes
  43. Platform dependencies and third-party services
  44. Cybersecurity boundaries - drawing the trust boundaries on the architecture
  45. The architecture document, and the architecture review
  46. Section 7.3 - Detailed design: the level at which the software is actually reviewable
  47. Clause 5.4 in outline
  48. What a detailed design actually contains
  49. Algorithms - describing intent without writing code
  50. State models - because most safety defects are state defects
  51. Data structures and error handling
  52. Logging - the design decision you will be grateful for in three years
  53. Interface definitions between units - the contract, written down
  54. Design verification and the design review (Clause 5.4.4)
  55. Software unit implementation (LO20) - what the standard asks of the code
  56. Coding standards - a process control, expressed as rules
  57. Software unit verification (Clauses 5.5.2 to 5.5.5) - process and evidence
  58. How much design is enough? The class decides
  59. Section 7.4 - AI and machine learning: an introductory overview
  60. Training, validation and test data - three sets, three jobs
  61. Data governance - the model is only as good as what it learned from
  62. Model performance - the numbers, and what they hide
  63. Bias - it is not a moral term here, it is a technical and clinical one
  64. Generalisability - performing well on your test set is not the claim you are making
  65. Drift - the model stayed the same; the world moved
  66. Explainability and human oversight
  67. Locked versus adaptive models - the distinction that governs everything else
  68. The FDA Predetermined Change Control Plan - the three components
  69. The PCCP condition everyone forgets: EXACTLY as prescribed
  70. Looking ahead - the broader FDA AI lifecycle guidance is DRAFT
  71. Monitoring a model in the field
  72. How requirements, architecture and design fit together
  73. The ten errors this module exists to prevent

  1. Section 8.1 - Verification and validation
  2. Verification, defined
  3. Validation, defined
  4. The difference, stated so it sticks
  5. The perfectly verified, entirely unvalidated product
  6. The scope boundary - who owns which V
  7. Verification is not one activity - the five methods
  8. Verification always names its input
  9. Objective evidence - what actually counts
  10. The evidence must survive the people
  11. Relationship to requirements - verification's anchor
  12. Relationship to intended use - validation's anchor
  13. Independence - the person who wrote it is the worst person to check it
  14. Independence scales with safety class
  15. Test environments - the environment is part of the evidence
  16. The environments you will actually need
  17. Planning it: the verification plan and the validation plan
  18. Section 8.2 - The testing levels
  19. Unit verification - a one-slide reminder
  20. Integration testing - Clause 5.6 - what it actually tests
  21. What integration testing looks for
  22. Integration strategy - and why big-bang hides the joins
  23. Integration and SOUP - testing what you did not write
  24. Software system testing - Clause 5.7 - what it actually tests
  25. Coverage - what 'against the requirements' really demands
  26. 5.6 versus 5.7 - the distinction, stated plainly
  27. Regression testing - and what it is not
  28. Performance testing - a requirement, a load, a metric, a limit
  29. Stress testing - find the failure MODE, not just the failure point
  30. Security testing - a different question, a different criterion
  31. Installation testing - the product has to actually arrive
  32. Upgrade testing - the update path is a safety path
  33. Compatibility testing - the platform moves under you
  34. Building a platform test matrix
  35. Recovery testing - what happens after the failure
  36. Exploratory testing - structured, chartered, time-boxed
  37. User acceptance testing - and who the 'user' actually is
  38. Clinical validation - where it applies, and where it does not
  39. Section 8.3 - Test documentation: the test that left no record did not happen
  40. Test strategy - how this organisation tests, and why
  41. Test plan - what it must decide before anyone tests anything
  42. Test protocol and test case - the difference
  43. The anatomy of a test case
  44. Expected results are defined BEFORE execution
  45. Pass, fail, and the space between
  46. Actual results - record what happened, not what should have
  47. Deviations - the honest record of what went differently
  48. Defects - raising, classifying, and connecting them to the risk file
  49. Retesting and regression - the two questions after a fix
  50. Approval - what a signature actually means
  51. Traceability - both directions, and what each direction finds
  52. Traceability gaps are findings in both directions
  53. The test summary report
  54. The failed-test investigation - a process, not a reaction
  55. The four possible causes of a failed test
  56. The thing you must never do
  57. Section 8.4 - Automated testing: a multiplier, not a method
  58. What automation is genuinely good at
  59. What automation is structurally bad at
  60. A green pipeline is not evidence of safety
  61. Tool qualification - if a tool decides pass or fail, it is part of your evidence
  62. Tool qualification, proportionate to what the tool decides
  63. Test code is a configuration item
  64. Test data - provenance, control, and the patient problem
  65. False positives and false negatives - and which one ends careers
  66. Flaky tests - the quiet erosion of evidence
  67. Automated evidence - what a reviewer must be able to reconstruct
  68. Continuous integration in a regulated lifecycle
  69. The ten errors this module exists to prevent

  1. Section 9.1 - Software release under IEC 62304 Clause 5.8
  2. What Clause 5.8 actually requires
  3. Release readiness - the questions you answer before you ask for a signature
  4. Verification completion - what 'complete' means at release
  5. Validation completion - the gate 62304 does not own
  6. Residual anomalies - the honest doctrine
  7. Documenting known residual anomalies
  8. Evaluating an anomaly for its contribution to a hazardous situation
  9. The residual-anomaly assessment table
  10. Risk management review at release
  11. Configuration identification - what exactly are you releasing?
  12. Reproducibility - you must be able to rebuild exactly what you shipped
  13. Archiving and retention
  14. The release record - what the file actually contains
  15. Release approval - what a signature actually means
  16. Release notes - the document the user actually reads
  17. Installation and distribution - the product has to arrive intact
  18. Rollback - the plan you write before you need it
  19. Section 9.2 - Product release: three gates, operated
  20. Software release versus product release
  21. Quality-system release under ISO 13485
  22. Regulatory release - the gate that is not yours to open
  23. Accompanying documentation is part of the product
  24. Distribution and deployment models - and what each one costs you
  25. Cloud and continuous deployment - the gates do not disappear
  26. Section 9.3 - Maintenance: IEC 62304 Clause 6
  27. The maintenance plan - Clause 6.1
  28. Monitoring and feedback - the intake side of Clause 6
  29. The four kinds of maintenance
  30. Corrective maintenance - and the temptation of the hotfix
  31. Adaptive maintenance - the environment moves without asking you
  32. Perfective and preventive maintenance
  33. Security updates are maintenance - and maintenance is change control
  34. SOUP updates and version drift
  35. Compatibility management - the matrix you must maintain
  36. Obsolescence - the component you no longer control
  37. End-of-life and end-of-support
  38. Section 9.4 - Problem resolution: IEC 62304 Clause 9
  39. What Clause 9 actually requires
  40. Where problem reports come from
  41. What a problem report must record
  42. Classification and severity - two different questions
  43. Investigation - evidence before opinion
  44. Root cause - and why 'developer error' is not one
  45. Product impact - the same defect is probably somewhere else
  46. Safety impact - assessed for EVERY problem report
  47. Problem resolution feeds the risk file
  48. Cybersecurity impact of a problem report
  49. Correction, corrective action - and the difference that matters
  50. Verifying the fix - and the regression question
  51. Closure - what 'closed' actually means
  52. Trending - the analysis nobody does
  53. Section 9.5 - Change control
  54. The change request - the front door
  55. Impact analysis - the heart of change control
  56. What impact analysis routinely misses
  57. Risk review of the change
  58. The regulatory assessment - is this a significant change?
  59. The significant-change assessment - how to structure the question
  60. Predetermined Change Control Plans - the three components
  61. PCCP - exactly as prescribed, or not at all
  62. Implementing the change - the re-entry into development
  63. Regression testing scope for a change
  64. Post-implementation review
  65. Section 9.6 - Post-market monitoring
  66. Complaints - and what makes a complaint a complaint
  67. Incidents and vigilance
  68. Trend reporting and signal detection
  69. Post-market cybersecurity - monitoring what you already shipped
  70. Field safety corrective actions
  71. User feedback - the signal that never becomes a complaint
  72. Performance monitoring - the SaMD-specific obligation
  73. CAPA - the corrective and preventive action loop
  74. Periodic review and product improvement
  75. Audit readiness - what a reviewer will actually ask for
  76. The nine artefacts - and what each one must be able to show
  77. The twelve errors this module exists to prevent

  1. 📘 Bonus: Software as a Medical Device eBook (Free with purchase)

Our Certified Customers

novartis
NHS
takeda
roche
baxter

Learner Rating & Reviews

4.7
★★★★★★
Average Rating
536 global ratings
★★★★★
87.0%
★★★★★
5.0%
★★★★★
3.0%
★★★★★
3.0%
★★★★★
2.0%
RC

Working with Whitehall training for the last two years of partnership has been a very successful experience – I have fast access to all the GCP course...

SM

I have finalised the demo for the ICH-GCP E6 R3 refresher course. Overall, I liked the content and the interface. I also want to thank Whitehall Train...

Recommended Courses

Essentials of EU MDRBest Seller

Essentials of EU MDR

Professional
£493 hrs3 points
GCP for Medical Devices ISO 14155:2026

GCP for Medical Devices ISO 14155:2026

Beginner and Intermediate
£392 hrs3 points
Agile Medical Device Software Development

Agile Medical Device Software Development

Intermediate
£393 hrs3 points
Advanced Medical Device Lifecycle, Clinical Investigations & Risk Management

Advanced Medical Device Lifecycle, Clinical Investigations & Risk Management

Intermediate
£393 hrs2 points
Risk Management for Medical Devices ISO 14971:2019

Risk Management for Medical Devices ISO 14971:2019

Intermediate
£393 hrs2 points