IEC 82304-1: IEC 82304-1 – Tutorial (about 60 minutes)

IEC 82304-1 is the international standard for the safety and security of health software products that run on ordinary computers, phones, tablets and cloud platforms, without hardware of their own. Manufacturers of medical apps, clinical web services, symptom checkers, remote monitoring portals and many wellness tools use it to show that their product was specified, built, validated, documented and supported in a disciplined way. After this tutorial you will be able to explain what the standard covers, walk through its clauses, plan the work it expects for a real product and talk confidently with auditors, regulators and customers about conformity.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current and only edition is IEC 82304-1:2016, Health software – Part 1: General requirements for product safety, edition 1.0, published by the International Electrotechnical Commission (IEC) on 27 October 2016. It is maintained by IEC technical committee 62, subcommittee SC 62A (common aspects of medical equipment, software and systems), which developed it in cooperation with ISO technical committee TC 215 (health informatics). The IEC webstore lists no amendment or newer edition and shows a stability date of 2029, which means the committee does not expect to change the publication before then. Related work is moving, however: the second edition of IEC 62304, which IEC 82304-1 relies on for its software life cycle clause, is in development and is planned to cover all health software, so the way clause 5 is met may change once it is published. A companion document, ISO/TS 82304-2:2021, covers quality and reliability of health and wellness apps. This course teaches the 2016 edition, the one manufacturers and assessors use today. Verified 2026-10-29 against the IEC webstore entry for IEC 82304-1:2016 (status valid, no project under development).

Who it is for: product managers, software engineers, testers, quality and regulatory specialists, clinical safety officers and founders who build or buy software that influences people's health, and who need a clear foundation before they read the standard itself. It is equally useful for teams whose app is a regulated medical device and for teams whose app is not, because the standard applies to both.

Prerequisites: none. Basic familiarity with how software is planned, built, tested and released helps. Every term specific to the standard is explained when it first appears.

Learning objectives. After the seven lessons you will be able to:

Explain why IEC 82304-1 exists, which products it covers and which products it deliberately leaves to other standards.
Use its vocabulary correctly, including health software product, accompanying documents, use requirements, system requirements and validation.
Describe the purpose of clauses 4 to 8 and how they link to IEC 62304 for the software life cycle.
Plan the product-level work: initial risk assessment, requirements, validation, identification, documentation and post-market activities.
Explain how conformity is demonstrated, who may assess it and why there is no single certificate that proves it.
Apply the standard step by step to a realistic app and spot the gaps an assessor would find.
Position IEC 82304-1 among neighbouring standards such as IEC 62304, ISO 14971, IEC 62366-1, IEC 81001-5-1 and ISO/TS 82304-2.

Lesson 1 – Origins, purpose and scope

Why a product standard for health software was needed

For decades the safety of medical technology was organised around physical equipment. An infusion pump, an X-ray machine or a patient monitor has a housing, a power supply and electronics, and the IEC 60601 family of standards describes how such medical electrical equipment must be designed and tested. Software inside that equipment is developed under IEC 62304, the software life cycle standard, and the overall product is tested as a whole.

Smartphones, web browsers and cloud platforms changed this picture. A large share of the software that now affects people's health has no hardware of its own. A medication reminder app, a portal where patients upload blood pressure readings, a decision support service used by clinicians, or a mental health programme delivered through a browser runs on hardware that the manufacturer did not design and does not control. There is no equipment standard to test against, and IEC 62304 alone does not help much, because it describes the processes for developing software, not the product a user downloads and relies on.

That gap left important questions unanswered. Who checks that the app actually meets the needs of the people who use it? Which platforms must it run on, and what happens when the operating system is updated? What must the user be told before installing it? Who informs users when a safety problem is found, and what happens to stored health data when the product is withdrawn? IEC 82304-1 answers these questions at the level of the whole product. It treats stand-alone health software as a product in its own right, with a beginning, a long period of use and an end.

Purpose in one sentence

The standard sets out what a manufacturer must do so that a health software product that runs on a general computing platform is safe and secure throughout its life: from deciding what it is for, through development and validation, to release, maintenance, communication with users and finally decommissioning.

Who it addresses

The standard is written for manufacturers, meaning the organisations that place a health software product on the market or put it into service under their own name. It does not place requirements on hospitals, clinics or other organisations that only install and operate the software. Those organisations are addressed by other work, notably IEC 80001-1 on risk management for IT networks that incorporate health software. This division of responsibility matters: a hospital cannot become conformant with IEC 82304-1 by running an app, and a manufacturer cannot pass its own responsibilities to the hospital by writing a contract.

What is in scope

The scope covers health software products that are intended to be placed on the market without dedicated hardware and that run on general computing platforms such as personal computers, smartphones, tablets, servers or cloud services. "Health software" is understood broadly. It includes software intended to manage, maintain or improve the health of individual people, or to support the delivery of care. Crucially, the scope does not depend on whether the product is legally a medical device. A regulated medical app and an unregulated wellness or self-care app can both fall within it, and the standard's rigour scales with the risk identified for the product.

What is out of scope

Software that forms part of a product with dedicated hardware is excluded, because other standards already cover the combined product. The scope names three such families: medical electrical equipment and systems covered by the IEC 60601 series, in vitro diagnostic equipment covered by IEC 61010 and active implantable devices covered by ISO 14708. Software embedded in those products is developed under IEC 62304 and assessed as part of the equipment. The standard also does not cover the clinical safety of the care pathway in which a product is used, or the operation of the software inside a hospital network, which is the operator's job.

Figure 1 – How the scope of IEC 82304-1 separates stand-alone health software from software that ships with dedicated hardware.

How compliance is decided

The scope also tells you how conformity is judged: by inspecting the documentation the standard requires. There are very few laboratory-style tests in IEC 82304-1. Instead, an assessor reads the manufacturer's records, such as the initial risk assessment, the requirements, the validation plan and report, the instructions for use and the post-market procedures, and checks that each required activity was carried out and recorded. This makes the standard practical for software, where the evidence lives in documents, tools and repositories rather than on a test bench. It also means that undocumented good work counts for nothing in an assessment.

The "Part 1" in the name

The number 82304-1 signals a multi-part family. Part 1 sets general product safety requirements. ISO/TS 82304-2:2021, a technical specification published by ISO, adds a quality and reliability assessment for health and wellness apps, including a way to present the results to the public as a label. Part 2 builds on the ideas in Part 1 but is a different kind of document with a different audience, and conformity with one does not imply conformity with the other.

Lesson 2 – Key concepts and vocabulary

IEC 82304-1 uses a compact vocabulary, and much of the confusion around it comes from mixing up a few of these terms. The descriptions below paraphrase the ideas; the standard's own wording is copyrighted and slightly more precise.

Health software – software whose specific purpose is to help keep or make an individual person healthier, to manage their health, or to support the delivery of care to them. It may or may not be a medical device.
Health software product – the health software together with its accompanying documents. The documentation is part of the product, not an optional extra; a perfect app with misleading instructions is an unsafe product.
Accompanying documents – the information delivered with the product for users, installers and operators: at minimum the instructions for use and the technical description.
General computing platform – hardware and system software that was not designed specifically for the health product, for example a phone with its operating system, a laptop, a browser or a cloud runtime.
Manufacturer – the person or organisation responsible for the design, production, labelling and placing on the market of the product, whether or not it does all of that work itself.
Intended use – what the manufacturer says the product is for, for whom and in which environment. Every later decision, from risk to validation, is measured against it.
Initial risk assessment – an early analysis of how the product could contribute to harm, carried out before detailed design, so that requirements and rigour match the risk.
Use requirements – the needs the product must satisfy from the point of view of its intended users and other stakeholders, including safety, security, usability and data protection needs.
System requirements – the technical requirements derived from the use requirements, such as supported platforms, performance, interfaces, interoperability and security mechanisms. They become the input to software development.
Verification – checking, with evidence that others can inspect, that an output meets the requirements written for it, for example that system requirements correctly and completely reflect the use requirements, or that a build behaves as specified. It answers "did we build it right?"
Validation – showing, with objective evidence, that the completed product satisfies what its intended users need in their real context of use. It answers "did we build the right thing?"
Independence – the requirement that the people who validate the product are competent and independent of the team that designed and developed it, so that the developers' assumptions are challenged.
Instructions for use – the user-facing part of the accompanying documents: intended use, warnings, installation and start-up, how to use the product safely and how to get help.
Technical description – the part of the accompanying documents aimed at people who install, configure, integrate and maintain the product, including platform and network requirements and security information.
Post-market activities – everything the manufacturer does after release: maintenance, re-validation after changes, communication with users and, eventually, decommissioning.
Decommissioning – the planned end of a product's support and availability, including what happens to the software, the users and any health data it holds.
SOUP – software of unknown provenance, a term from IEC 62304 for third-party or legacy software items whose development records are not available, such as an open-source library or the phone's operating system.

Two distinctions that matter most

The first distinction is health software versus health software product. Engineers naturally think of the product as the code. The standard insists that the product is the code plus the information that tells people how to use it safely. This is why identification, instructions for use and technical description have a whole clause, and why updating a feature without updating its documentation is a nonconformity.

The second distinction is verification versus validation. Verification compares outputs with specifications; validation compares the finished product with real needs. A team can pass every automated test, which is verification, and still ship a product that nurses misread under time pressure, which is a validation failure. IEC 82304-1 adds product validation on top of the software verification that IEC 62304 already requires, and that is one of its main contributions.

Lesson 3 – Structure of the standard

IEC 82304-1 is short compared with many safety standards. The requirements sit in clauses 4 to 8, which take up only part of the document; informative annexes explain the rationale. The main body follows a logical product life: requirements, development, validation, release documentation and post-market care.

Clauses 1 to 3: the frame

Clause 1, Scope, sets the purpose, the field of application and the way compliance is checked, as covered in Lesson 1. Clause 2, Normative references, lists the documents that are indispensable for applying the standard; the most important is IEC 62304, whose life cycle processes are pulled in by clause 5. Clause 3, Terms and definitions, defines the vocabulary from Lesson 2.

Clause 4: health software product requirements

Clause 4 is where the product is defined. It covers general requirements and the initial risk assessment, the health software product use requirements, the system requirements derived from them, how those requirements are kept up to date as the product evolves, and how the requirements themselves are verified. The use requirements are expected to address the intended use and users, the use environment, the platforms, interoperability needs, safety, security and privacy needs, and the information that must accompany the product. System requirements turn those needs into technical terms that developers can implement and testers can verify.

Clause 5: software life cycle processes

Clause 5 does not invent a new development process. It requires the health software to be developed and maintained according to the process clauses of IEC 62304 (clauses 5 to 9): planning, requirements analysis, architecture, design, implementation, integration and testing, release, maintenance, software risk management, configuration management and problem resolution. The use and system requirements from clause 4 are the inputs; IEC 62304 governs how the software is built from them. This is the clause most likely to be affected by the future second edition of IEC 62304.

Clause 6: health software product validation

Clause 6 asks for a validation plan, the performance of validation according to that plan and a validation report. The plan defines what will be validated against which use requirements, with which methods (for example simulated use, user studies, inspection or analysis), by whom and with what acceptance criteria. Validation is carried out on the finished product, including its accompanying documents, by a validation team that is competent for the task and independent of the people who developed the product. The report records results, deviations and the conclusion that the product is, or is not, fit for its intended use.

Clause 7: identification and accompanying documents

Clause 7 covers how the product is identified and what information comes with it. Identification means users and support staff can always tell exactly which product and version they are dealing with, and who the manufacturer is. The accompanying documents include the instructions for use, with the intended use, warnings, installation and operating information, and the technical description, with platform requirements, configuration, network and security information and maintenance guidance. The clause is detailed enough to be used as a checklist, which many teams do.

Clause 8: post-market activities

Clause 8 deals with life after release. It covers software maintenance (handled through the IEC 62304 maintenance process), re-validation when changes affect the product's use or safety, communication with users about issues, updates and changes, and decommissioning and disposal at the end of the product's life. This clause is what turns IEC 82304-1 from a launch checklist into a whole-life standard.

Annexes

The informative annexes explain the rationale behind the requirements and give guidance on applying them. They are not requirements, but they are worth reading because they show what the committee intended, which helps when a requirement is open to interpretation.

Figure 2 – The main clauses of IEC 82304-1 and the order in which they shape a health software product.

A useful way to remember the structure is as a set of questions. Clause 4 asks "what must this product do, for whom, and how risky is it?". Clause 5 asks "was the software built with a controlled process?". Clause 6 asks "does the finished product really meet its users' needs?". Clause 7 asks "can people identify it and use it safely from the information provided?". Clause 8 asks "do we keep it safe after release and end it responsibly?".

Lesson 4 – How it works in practice

Standards are easier to apply when you see them as a sequence of work products. This lesson walks through the activities in the order most teams perform them, with the roles and artefacts involved. Real projects iterate, especially agile ones, but every iteration still needs to keep these artefacts consistent.

Figure 3 – The product-level workflow that IEC 82304-1 expects, from intended use to release, post-market change and decommissioning.

Step 1 – Define the intended use

Write down, in plain words, what the product is for, who uses it (patients, carers, clinicians, administrators), in which environment (home, clinic, ward, on the move), on which platforms and with which other systems. This statement drives everything, including whether the product is a regulated medical device in a given market. Teams often discover at this stage that marketing claims and the intended use disagree; resolve that early, because regulators read marketing material too.

Step 2 – Carry out the initial risk assessment

Before designing features, identify how the product could contribute to harm. For health software the harm is often indirect: wrong or late information leads someone to act, or fail to act. Typical hazard sources include incorrect calculations, stale or lost data, data shown for the wrong person, misunderstood displays, missed notifications, unavailability, platform changes and security breaches that expose or corrupt health data. Estimate the risk, decide which controls are needed and record the results. The outcome also sets the level of rigour for development; under IEC 62304 this is expressed as a software safety class.

Step 3 – Write the use requirements

Translate the intended use and risk controls into needs stated from the user's point of view: what the user must be able to do, what information they need, how quickly, with which accessibility needs and under which conditions. Include requirements for security and privacy, for interoperability with other systems, for installation and updating, and for the accompanying documents. Each requirement must be testable, because validation will check it later.

Step 4 – Derive system requirements

Turn each use requirement into technical requirements: supported operating system versions and browsers, minimum hardware, network conditions, interfaces and data formats, response times, availability targets, authentication and encryption, logging, backup and restore. Keep traceability, meaning a recorded link from each system requirement back to the use requirement it serves, so that a change on either side shows its impact.

Step 5 – Verify the requirements

Review the requirement sets before building on them. Check that the system requirements fully and correctly cover the use requirements, that nothing contradicts the intended use, that every risk control appears as a requirement and that each requirement can be tested. A structured review with recorded findings is usually enough evidence.

Step 6 – Develop and maintain the software under IEC 62304

The development team follows IEC 62304: a development plan, software requirements, architecture and design appropriate to the safety class, implementation, unit and integration testing, software system testing, release, configuration management, problem resolution and software risk management. Third-party components such as frameworks, cloud services and the mobile operating system are handled as SOUP, with their versions recorded and their known problems evaluated.

Step 7 – Validate the finished product

Prepare a validation plan that states which use requirements will be validated, how, by whom, in which environment and against which acceptance criteria. Then perform validation with the released candidate build and its real accompanying documents on representative platforms, ideally with representative users. Usability engineering under IEC 62366-1 often supplies much of this evidence, through formative evaluations during design and a summative evaluation at the end. Make sure the people who validate are competent and independent of those who designed and developed the product; in a small company this often means bringing in someone from outside the project. Close with a validation report that states the conclusion and any residual concerns.

Step 8 – Identify the product and complete the accompanying documents

Give the product a name and a unique version identifier visible to users, for example on an "About" screen and in the store listing, and state the manufacturer's identity and contact details. Finalise the instructions for use and the technical description, and check them during validation, not after. If the product is delivered through app stores, think about what users actually see before installing, and where they can find the full documents.

Step 9 – Release and operate post-market processes

After release the manufacturer collects feedback, complaints and problem reports, monitors platform changes announced by operating system and browser vendors, and evaluates each change for safety impact. Changes go back through the requirements, development and, when they affect use or safety, re-validation. Users are told about important issues, required updates and changes in supported platforms. Security vulnerabilities in the product or its SOUP are treated as potential safety issues.

Step 10 – Plan decommissioning

Every product eventually ends. The manufacturer decides in advance how it will announce end of support, how long it will keep the service running, how users can export or move their data, what happens to data held in the cloud and how remaining installations are prevented from silently failing. A product that simply stops working can be as dangerous as one that works incorrectly.

Roles and typical artefacts

Product owner or manager – intended use statement, use requirements, release decisions.
Clinical or domain expert – hazard identification, review of use requirements and warnings, participation in validation.
Systems or lead engineer – system requirements, platform and interface specifications, traceability.
Development and test team – IEC 62304 records: plans, designs, test reports, SOUP list, release notes.
Quality or regulatory lead – procedures, document control, assessment readiness, regulatory filings.
Independent validator – validation execution and report.
Support and post-market team – complaint handling, user communication, field action records, decommissioning plan.

Small companies often combine several roles in one person. That is acceptable as long as the independence required for validation is achieved and responsibilities are written down.

Lesson 5 – Assessment, certification and compliance

Self-assessment is the starting point

Because conformity is determined by inspecting documentation, the first assessor is the manufacturer. A typical approach is a conformity checklist that lists every requirement of clauses 4 to 8 and, for each one, points to the record that demonstrates it: the risk assessment file, the requirement specifications, review minutes, the IEC 62304 records, the validation plan and report, the instructions for use, the technical description and the post-market procedures. Many manufacturers then issue a declaration that their product conforms to IEC 82304-1, backed by this evidence.

Who else may assess conformity

Third parties look at the same evidence for different reasons:

Regulators and notified bodies reviewing a medical device application may use IEC 82304-1 as a recognised way of showing that a stand-alone software product meets general safety and performance expectations. In the European Union a European adoption of the standard exists; whether it is listed as a harmonised standard under the medical device regulations at a given date must be checked in the current Official Journal list, because that list changes.
Health system buyers and app assessment programmes may ask app suppliers for evidence of conformity, or reuse its concepts in their own assessment criteria.
Hospitals and clinics procuring software use the accompanying documents, especially the technical description, as input to their own risk management of the IT network.
Testing and certification organisations offer independent evaluations against the standard. Their reports can carry weight with customers, but they are commercial services, not an official IEC certificate.

Is there a certificate?

There is no single, mandatory certification scheme run by IEC for this standard, and no levels or grades of conformity. A product either meets each applicable requirement, as shown by its documentation, or it does not. Be careful with marketing that implies an official "IEC 82304-1 certified" status: ask who performed the evaluation, against which version of the product and with what scope. Equally, a quality management system certificate, for example to ISO 13485, does not by itself show that a particular product conforms to IEC 82304-1; it shows that the organisation has a controlled system in which such work can be done.

What assessors typically check

A clear, consistent intended use statement that matches the product's claims in stores and on websites.
An initial risk assessment that addresses indirect harm, platform dependencies and security, and whose controls appear as requirements.
Use and system requirements with traceability and recorded verification.
Evidence that IEC 62304 was followed, proportionate to the software's safety class, including the SOUP list.
A validation plan and report, performed on the finished product with its documents, with independence shown.
Version identification visible to users and complete instructions for use and technical description.
Post-market procedures that actually operate: complaint records, change evaluations, re-validation decisions, user notices and a decommissioning plan.

Common findings

Assessors often find that validation was replaced by system testing, that documentation describes an older version, that platform support claims were never tested on the oldest listed operating system version, that security appears in the risk assessment but not in the requirements, or that nobody has thought about what happens to user data at end of life. Each of these is easy to prevent if the clause structure is used as a planning tool from the start rather than as a checklist at the end.

Conformity over time

Conformity is not a one-time event. Each release changes the product, so the evidence must be kept up to date. A sensible rule is that a release is not complete until the requirements, risk records, validation evidence and accompanying documents reflect it. Teams that use continuous delivery build these updates into the definition of done for each change instead of batching them before an audit.

Lesson 6 – Worked example: a post-surgery recovery app

The organisation and the product

KneeWell is a fictional twelve-person company that builds a recovery app for patients after knee replacement surgery. Patients use a phone app to log pain scores, swelling, wound photos and completed exercises. The app reminds them of exercises, shows progress charts and, when entries match certain warning patterns (for example rising pain with fever), advises them to contact their clinic. Physiotherapists see a web dashboard summarising each patient's progress. The back end runs on a public cloud. KneeWell sells the service to hospitals, which offer it to their patients.

Whether the product is a medical device depends on its claims and the market; the warning advice makes it likely to be regulated in several jurisdictions. KneeWell decides to apply IEC 82304-1 regardless, because hospital buyers ask for it and because it provides a clear structure for a small team.

Step 1 – Intended use

The team writes: "KneeWell supports adults recovering at home after total knee replacement to follow their prescribed exercise plan and record recovery information, and gives their care team a summary. It advises patients to contact their clinic when recorded symptoms match predefined warning patterns. It does not diagnose, and it does not replace scheduled follow-up." They also list users (patients, physiotherapists, clinic administrators), environment (home, mobile network, clinic office) and platforms (two recent major versions of each mobile operating system, current desktop browsers).

Step 2 – Initial risk assessment

A workshop with a physiotherapist, a surgeon adviser, the lead engineer and the product owner identifies hazards, including:

A warning pattern is not detected, so a patient with an infection delays contacting the clinic.
Entries from one patient appear in another patient's dashboard record.
Exercise reminders stop after a phone operating system update changes notification behaviour.
A wound photo leaks through an insecure storage configuration.
An older patient misreads the pain scale and records the opposite of what they feel.
The service is unavailable for several days and nobody notices that data is not being synchronised.

For each hazard they estimate severity and likelihood and decide on controls: independent checking of warning rules, strong patient identity binding, platform monitoring and re-testing, encryption and access control, a redesigned pain scale with clear anchors, and visible synchronisation status plus monitoring alerts. The software's contribution to possible serious harm leads the team to treat the warning logic with the highest rigour in its IEC 62304 plan.

Step 3 – Use requirements

Examples written from the user's point of view: "A patient can record a pain score in under 30 seconds using one hand." "When recorded symptoms match a warning pattern, the patient sees advice to contact the clinic, with the clinic's phone number, before leaving the screen." "A physiotherapist can see which patients have not synchronised data for more than 48 hours." "Wound photos are visible only to the patient and their assigned care team." "Instructions explain what the app does not do, in plain language." Each requirement carries an identifier and a link to the hazards it controls.

Step 4 – System requirements

The engineers derive technical requirements: supported operating system versions; local encrypted storage with synchronisation retries; server-side warning rule engine with versioned rule sets; role-based access control with single sign-on for clinics; encryption in transit and at rest; audit logging of access to patient records; monitoring with alerts for synchronisation backlog; daily backups with tested restore; notification permission checks at app start with a visible prompt if notifications are disabled.

Step 5 – Requirement verification

A recorded review checks traceability in both directions. It finds two gaps: no system requirement covered the "one hand" use requirement, and the decommissioning needs of hospitals had no use requirement at all. Both are fixed before development continues.

Step 6 – Development under IEC 62304

The team uses short iterations. Its development plan describes the iteration rhythm, the definition of done (code review, automated tests, updated trace links, risk records and draft documents) and the configuration management of rule sets. The SOUP list includes the mobile frameworks, the charting library, the cloud database and the operating systems, with versions and an evaluation of known issues. Software system tests cover every system requirement, including rule engine tests with clinically reviewed test cases.

Step 7 – Validation

The validation plan selects the use requirements that matter most for safety and effectiveness and defines methods: a summative usability study with fifteen recently operated patients and five physiotherapists using the release candidate on their own phones, a clinical review of warning advice texts, an inspection of the instructions for use by a nurse who was not involved in writing them, and a simulated outage to confirm that the synchronisation warning appears on the dashboard. A quality engineer from another product team leads the validation to provide independence. The study reveals that several patients did not find the clinic phone number quickly; the team redesigns the advice screen and repeats that part of the study. The validation report records both rounds and concludes that the product is fit for its intended use, listing two minor residual usability issues for the next release.

Step 8 – Identification and accompanying documents

The app shows its product name, version and build number, and the manufacturer's name and address on an "About" screen, and the same version appears in the store listing and the dashboard footer. The instructions for use cover the intended use, who should not rely on the app, warnings (for example "call emergency services in an emergency; do not wait for the app"), set-up, daily use, data privacy and how to get support. The technical description for hospitals covers supported platforms, single sign-on configuration, network endpoints, data hosting location, backup and retention, security measures and how updates are delivered.

Step 9 – Post-market

KneeWell runs a monthly post-market review: complaints, support tickets, usage analytics for warning screens, security advisories for its SOUP and announced operating system changes. When a mobile operating system beta changes background notification limits, the team evaluates the impact, adjusts the reminder mechanism, re-runs the affected system tests and re-validates the reminder use requirement on real devices. Hospitals and patients receive a short notice explaining that an update is required, and the minimum supported version is raised.

Step 10 – Decommissioning

The decommissioning plan states that hospitals will receive at least twelve months' notice of end of support, that patients can export their records as a PDF and a structured file, that clinic data will be returned in an agreed format and then deleted, that the app will display an end-of-service notice before the server stops, and that the store listing will be removed. The plan is reviewed every year.

What the example shows

None of these steps required heavy bureaucracy. The work products are a few concise documents, a requirements tool with trace links, test and validation records, and a handful of procedures. What IEC 82304-1 adds to ordinary good engineering is completeness at the product level: validation with real users, documents treated as part of the product, and explicit responsibility for the product's whole life.

Figure 4 – Life cycle states of the KneeWell product, showing that significant changes loop back through development and validation before release.

Lesson 7 – Relationship to other standards and frameworks

IEC 82304-1 sits in a family of health software standards. It is easiest to understand as the product-level layer that ties the others together. Think of it as answering "is this product safe and fit to place on the market and keep there?", while its neighbours answer narrower questions about process, risk, usability, security or operation.

Figure 5 – How IEC 82304-1 connects to the process, risk, usability, security, quality and operator standards around it.

Standard	What it covers	How it relates to IEC 82304-1
IEC 62304	Software life cycle processes for medical device software: development, maintenance, risk management, configuration management, problem resolution.	Pulled in by clause 5 for building and maintaining the software. IEC 82304-1 adds product requirements, validation, documentation and post-market duties around it.
ISO 14971	Application of risk management to medical devices across the life cycle.	Provides the risk management method that IEC 62304 relies on and that informs the initial risk assessment and later risk decisions.
IEC 62366-1	Usability engineering process for medical devices, including formative and summative evaluation.	A strong source of evidence for use requirements and product validation, especially for user-facing apps.
IEC 81001-5-1	Security activities in the life cycle of health software and health IT systems.	Adds detailed secure development and maintenance activities that go well beyond the security points in the 2016 edition of IEC 82304-1.
IEC 80001-1	Safety, effectiveness and security in the implementation and use of connected health software by healthcare delivery organisations.	The operator's side. The technical description required by IEC 82304-1 is a key input to a hospital's work under IEC 80001-1.
ISO/TS 82304-2	Quality and reliability assessment of health and wellness apps, with a public-facing label.	A companion part focused on app quality as seen by consumers and buyers; it complements but does not replace Part 1.
ISO 13485	Quality management systems for organisations in the medical device sector.	Provides the controlled organisational system (document control, CAPA, supplier control) in which IEC 82304-1 work is usually performed.
IEC 60601-1	Basic safety and essential performance of medical electrical equipment.	Covers products with dedicated hardware, which are outside the scope of IEC 82304-1.

Typical combinations

A regulated medical app usually combines ISO 13485 for the quality system, ISO 14971 for risk management, IEC 62304 for the software life cycle, IEC 62366-1 for usability, IEC 81001-5-1 for security and IEC 82304-1 for product-level requirements, validation, documentation and post-market care. A non-device wellness app may not need ISO 13485 certification, but IEC 82304-1 and ISO/TS 82304-2 together still give buyers and users a credible picture of safety and quality. A hospital deploying either app uses IEC 80001-1 and the manufacturer's technical description to manage risks in its own network.

Avoiding overlap and double work

Because the standards were written to fit together, one set of records can serve several of them. A single risk management file can hold the initial risk assessment, the software risk analysis and security risk analysis, with clear links. Usability evaluation records can be reused as validation evidence. A single trace structure can link use requirements, system requirements, software requirements, tests, validation activities and risk controls. Planning these overlaps at the start is the most effective way to keep the documentation burden reasonable for a small team.

Common pitfalls and best practices

Pitfalls

Assuming the standard only matters for medical devices. The scope is health software in general; buyers and assessors may expect it even when the product is not regulated.
Treating system testing as validation. Passing every test against the specification does not show that real users can use the finished product safely for its intended purpose.
Letting documentation drift. Instructions and technical descriptions that describe an older version make the product nonconforming, because documents are part of the product.
Ignoring platform dependency. Operating system, browser and cloud changes can silently break safety-relevant behaviour such as notifications or background synchronisation.
Listing security as a risk but never as a requirement. Risk controls that do not become requirements are never implemented or verified.
Forgetting the end of life. Shutting a service down without notice or data export can harm users who rely on it.
Validating with the design team only. Without independence, the same assumptions that shaped the design shape the validation.

Best practices

Write the intended use first and keep it aligned with marketing claims. Review store listings and websites whenever the intended use changes.
Use the clause structure as a project plan. Map clauses 4 to 8 to backlog items and release criteria from day one.
Maintain traceability continuously. Link hazards, use requirements, system requirements, tests and validation activities in the tool the team already uses.
Validate on real devices with representative users and the real documents. Include the oldest supported platform version.
Treat security vulnerabilities as potential safety issues. Feed SOUP advisories into problem resolution and post-market review.
Make version identification visible everywhere. App screen, dashboard, support tickets and documents should show the same identifier.
Plan decommissioning early and review it yearly. Include notice periods, data export and safe shutdown behaviour.
Reuse evidence across standards. Design one risk file and one trace structure that serve IEC 82304-1, IEC 62304, IEC 62366-1 and IEC 81001-5-1 together.

Summary and key takeaways

IEC 82304-1:2016 is the current edition; it sets product-level safety and security requirements for stand-alone health software that runs on general computing platforms.
It applies to manufacturers, covers the whole product life and does not depend on whether the product is legally a medical device.
Products with dedicated hardware, such as medical electrical equipment, in vitro diagnostic equipment and active implants, are covered by other standards.
A health software product is the software plus its accompanying documents; both must be correct and current.
Clause 4 defines the product through the initial risk assessment, use requirements and system requirements; clause 5 relies on IEC 62304 for the software life cycle.
Clause 6 requires validation of the finished product against users' needs, with independence; clause 7 requires identification, instructions for use and a technical description.
Clause 8 makes maintenance, re-validation, user communication and decommissioning explicit manufacturer duties.
Conformity is shown through documentation, usually by self-declaration supported by evidence; there is no single official certificate or rating.

Reflection questions

Think of a health-related app you use or build. Write its intended use in two sentences, then list three ways it could indirectly contribute to harm.
Your product supports five operating system versions. How would you decide which ones to include in validation, and what evidence would you keep?
Which parts of your current documentation would a user or hospital need that you do not yet provide, and where in clause 7 do they belong?
Your team ships updates every two weeks. How would you decide, for each update, whether re-validation is needed, and who makes that decision?
If your service had to close in six months, what would you need to tell users, and what would you do with the health data you hold?