IEC 62304 Training: Software as a Medical Device, from Qualification to Release

Opens with a self-check: can you explain why your software is, or is not, a medical device in the US and the EU, and which software safety class each part has? Presents two FDA cases: the March 2024 Tandem Diabetes Care recall of its iPhone app for the t:slim X2 insulin pump, whose crash-and-relaunch cycle drained the pump battery, and a patient monitor with a hidden backdoor. Draws four questions for any software team: do we know our risks, control what we use, listen after release, and can we show it? Introduces DEF Digital Health, a software company in Boston with about sixty staff, and clears up myths about life cycle models, SOUP and platforms. Ends with the thirteen modules, practice questions, four practice exercises and the final exam, and a recap.

What you will be able to do

• Explain how software can harm patients without any part breaking
• Ask the four questions that show whether a software process is safe
• Describe how the course, exercises and exam work

Why it matters

Seeing how an app update drained insulin pumps shows why safe software has to be shown by its process, not assumed.

Practice: Practice: Why software safety matters · 3 questions

Starts with DEF's first product idea, a simple diabetes diary that stores and displays readings, and the feature request that changes everything: recommending the next insulin dose. Explains the international definition of software as a medical device, software for a medical purpose that does not need to be part of a hardware device, including apps. Covers the US definition of a device and the software functions it excludes, and the five EU decision steps, showing why dose recommendation software is a device under both. Then shows DEF's function inventory, separating the meal and reading log from the dose function, and its claims review across labelling, app store pages and websites, signed by regulatory affairs, with a change form that asks whether a change alters the intended purpose. Ends with a recap.

What you will be able to do

• Decide whether a software function is a medical device in the US and the EU
• Build a function inventory that separates device and non-device functions
• Check that claims in labelling and app stores match the intended purpose

Why it matters

The intended purpose decides device status, so one new feature or marketing claim can turn an app into a regulated device.

Practice: Practice: When software is a medical device · 3 questions

Opens with DEF's leaders agreeing the risk class of the Bolus Advisor before setting the budget, comparing a team that assumes users can ignore the advice with one that classifies by what a wrong output could cause. Explains the IMDRF framework, which sorts software by the significance of its information, to treat or diagnose, drive or inform clinical management, and the state of the healthcare situation, into categories one to four, using the framework's table. Covers the EU's Rule 11, which gives classes IIa, IIb or III by what decisions could cause, and FDA's device class and pathway with a separate documentation level. Then explains that IEC 62304's software safety class is its own question, for each software system, deciding which tasks of the standard you must perform. Ends with a recap.

What you will be able to do

• Place software in an IMDRF category using significance and situation
• Apply EU Rule 11 to decide a software class
• Explain why the IEC 62304 safety class is a separate decision

Why it matters

Getting the class right at the start avoids a rejected submission that forces the plan, budget and timeline to change.

Practice: Practice: Risk categories and classes · 3 questions

Starts with a team two weeks before an audit that has code, tests and a product but almost none of the records the standard expects, comparing documents written after the fact with records built as the work was done. Explains the scope of IEC 62304: the life cycle of medical device software, development and maintenance, but not validation of the whole device. Covers its structure: general requirements in Clause 4, then development, maintenance, risk management, configuration management and problem resolution, and what compliance means: performing the tasks required for each class, with documented justifications where a task is not done. Then shows how software risk tasks feed the device risk management file within the quality system, legacy software, and how DEF maps its agile process, with release and sprint plans forming the development plan under 5.1.2. Ends with a recap.

What you will be able to do

• Explain what IEC 62304 covers and what it leaves to device validation
• Describe the structure of the standard's clauses
• Map an agile process to the standard's tasks and records

Why it matters

The standard describes how you work every day, so records made as you go stand up to audit where last-minute documents do not.

Practice: Practice: IEC 62304 at a glance · 3 questions

Opens with DEF's team wanting to treat the app's help and education screens as class A, although they run in the same process as the dose engine and could, in principle, corrupt a dose. Explains how each software system gets class A, B or C by the worst harm from a hazardous situation it could contribute to, assuming the software fails, and four ideas behind the rule. Covers why only risk controls outside the software can lower its class, why software that implements a risk control takes the class of the risk it controls, and how items inherit their parent's class unless a documented rationale shows real segregation. Then shows the classification DEF recorded after the device risk analysis, with the dose engine and confirmation screen as class C and the logbook and charts using an open-source library. Ends with a recap and a practice exercise classifying five items.

What you will be able to do

• Assign software safety class A, B or C to a software system
• Explain when an external risk control can lower a class
• Write a segregation rationale for an item with a lower class

Why it matters

Until the class is known it is C; a defensible classification avoids both wasted effort and gaps an auditor will find.

Practice: Practice: Software safety classes · 3 questions

Starts with a DEF story that only says calculate the mealtime dose, so two developers round differently and no test can say which build is right. Explains the software development plan: processes, deliverables, traceability, configuration and problem handling, sized to the classes and kept up to date. Covers software requirements drawn from system requirements and covering the headings of 5.2.2, from functional and capability requirements to the computing environment, with risk controls included for classes B and C, shown in one requirement as it sits in DEF's requirements tool. Then covers verifying requirements against six criteria: consistent, unambiguous, testable, uniquely identified, traceable and implementing the system requirements. Ends with the common mistake of a trace matrix built in the last week, good practice of using 5.2.2 as a review checklist, and a recap.

What you will be able to do

• Write a software development plan sized to the safety classes
• Write software requirements that cover the headings of 5.2.2
• Verify requirements against the six criteria in the standard

Why it matters

A requirement you cannot test is a wish; clear requirements stop two builds from behaving differently with no way to judge.

Practice: Practice: Planning and requirements · 3 questions

Opens with a moment built for this course: DEF's cloud sync item and dose engine pass each other the carbohydrate ratio in opposite units, each meeting its own tests while together they could produce a wrong dose. Explains the architecture under 5.3.1: software items, the interfaces between and around them, functional and performance requirements for SOUP, segregation for class C, and a documented verification, shown in DEF's architecture with the logbook and charts as class B. Covers detailed design: subdividing into units for classes B and C, with unit and interface designs verified against the architecture for class C. Then covers implementing units for every class and verifying them for B and C against acceptance criteria set before integration, with extra criteria for class C, and the evidence each activity leaves. Ends with a recap.

What you will be able to do

• Document software items and the interfaces between them
• Explain what detailed design requires for classes B and C
• Verify software units against acceptance criteria set in advance

Why it matters

The risk often lives between the boxes; written interfaces catch the mismatch that unit tests on each side will miss.

Practice: Practice: Architecture, design and units · 3 questions

Starts with DEF about to release version 2.3 of the Bolus Advisor, comparing system tests run on a developer's laptop build with one controlled build that is tested and shipped. Explains integration for classes B and C: integrating per plan, testing the integrated items, evaluating the procedures, running regression tests and keeping repeatable records. Covers software system testing for every class: tests covering all requirements, retests after change, an evaluation and complete test records, avoiding a test log that says only OK, with an eye-screening software firm in Hyderabad testing on the oldest and newest phone operating systems. Then covers release: verification complete, residual anomalies documented and evaluated, the version and build recorded, the software archived and delivered reliably. Ends with a recap and a practice exercise reviewing a draft release record against the eight release tasks.

What you will be able to do

• Plan integration and regression testing for classes B and C
• Write system test records with version, environment and tester
• Check a release record against the standard's release tasks

Why it matters

Release what you tested, and show it; one controlled build removes doubt over whether the shipped app was ever tested.

Practice: Practice: Integration, testing, release · 3 questions

Returns to the March 2024 Tandem Diabetes Care recall of version 2.7 of its iPhone app, where repeated crashes and automatic relaunches caused excessive Bluetooth communication that could drain the insulin pump battery. Explains how software risk management fits with ISO 14971 in one risk management file for the device. Covers analysis: identifying the items that could contribute to hazardous situations, considering five kinds of cause, evaluating SOUP anomaly lists and documenting it all. Then covers control and verification: defining controls in hardware, software, the working environment or user instructions, putting software controls into the requirements and classing them by the risk they control, verifying them and tracing four links. Ends with analysing every change, including fixes and SOUP updates, for new causes and effects on existing controls, and a recap.

What you will be able to do

• Identify software items that could contribute to hazardous situations
• Put software risk controls into requirements and verify them
• Analyse a software change for new causes and effects on controls

Why it matters

Risk work lives in the software work; tracing each control from hazard to test is what reviewers look for after a recall.

Practice: Practice: Software risk management · 3 questions

Opens with DEF's logbook pulling the latest release of an open-source charting library on every build, until a change in axis scaling alters the glucose chart with nobody approving or testing it. Explains SOUP: software not made for the device, or without records, and how to name each item and version, specify what it must do, check its anomaly lists and analyse its changes, with a lab-analysis software firm in Vienna whose build checks a single SOUP register on every run. Covers configuration management for every class: identifying items and versions, changing them only through approved requests and keeping a retrievable history. Then covers problem resolution: a report with criticality for every problem, a safety evaluation, change control, trends and a verified resolution. Ends with a recap and a practice exercise turning a support message into a problem report.

What you will be able to do

• Keep a SOUP register with item, version, requirements and anomaly checks
• Control software changes through approved change requests
• Write a software problem report with criticality and safety evaluation

Why it matters

If you cannot name the version, you cannot control it; a SOUP register stops an unapproved library change reaching patients.

Practice: Practice: SOUP, configuration, problems · 3 questions

Starts with the January 2025 FDA warning about cybersecurity vulnerabilities in Contec CMS8000 patient monitors, and the same monitors relabelled by Epsimed, including remote control by an unauthorised user and a backdoor. Explains the maintenance process for every class: a plan, monitored feedback, problem reports, and analysed and approved changes, following subclause 6.2 from feedback to change. Covers informing users and regulators as local rules require: in the EU, 15 days for serious incidents, 10 for deaths or unanticipated serious harm and 2 for serious public health threats, field safety corrective actions reported in advance, and generally 30 days in the US. Then covers cybersecurity: section 524B for cyber devices in the US, the software and security requirements of Annex one in the EU, mobile platform features, and checking the SBOM against the SOUP register. Ends with a recap.

What you will be able to do

• Run software maintenance from feedback to approved change
• State the EU and US reporting timelines for software incidents
• Check the SBOM against the SOUP register for a connected device

Why it matters

Maintenance is part of the product; knowing the reporting clocks and cyber rules avoids late reports and exposed devices.

Practice: Practice: Maintenance and cybersecurity · 3 questions

Opens with DEF's plan to import readings automatically from a continuous glucose sensor, treated in one version as just another feature, although it adds a new interface and changes how data enter the dose calculation. Explains the two layers: the software standard controls how every change is analysed, approved and verified, while the law decides whether a regulator must see it first. Covers the US questions on cybersecurity, specification, risk and performance for deciding whether a new 510(k) is likely, and the Basic or Enhanced software documentation when a submission is needed. Then covers the EU: changes that could affect safety and performance go to the notified body before release, with MDCG 2020-3 helping to judge significance. Ends with a recap and a practice exercise assessing four DEF changes for the US and the EU.

What you will be able to do

• Decide whether a software change is likely to need a new 510(k)
• Explain the Basic and Enhanced software documentation levels
• Judge whether to inform the notified body using MDCG 2020-3

Why it matters

Decide before you build, not after you ship; a change released without the right submission can force a recall or a halt.

Practice: Practice: Changes and submissions · 3 questions

Follows DEF's glucose sensor import feature from the first plan to its first month on the market, naming the earlier module behind each step. Before any code, it asks whether the app is still a medical device, what class applies and whether the change needs a submission. The feature is then built and tested under Clause 5, controlled under Clause 7, submitted in both regions with the cybersecurity content for a cyber device, including the SBOM and vulnerability management plan, released with the SBOM checked against the SOUP register and archived, and watched in the field. Covers common mistakes, such as an architecture drawn after the code and a risk file updated once a year. Ends with a ten-step road map, a reminder of the four practice exercises, and the final exam: scenario questions with 60% for the Certificate of Competence.

What you will be able to do

• Trace one software feature through every IEC 62304 process
• Recognise the common mistakes that weaken a software file
• Apply the ten-step road map to your own team

Why it matters

Seeing one feature go from idea to market shows how the processes connect and where your own team should start.

Practice: Practice: Putting it together · 3 questions