IEC 62304 tells a medical-device software team how to run and document its software lifecycle. It does not decide whether your app is a medical device, prove that the finished device is safe, or hand engineers a coding framework. Start with intended use. If device rules apply, build a traceable evidence system around the standard’s processes.
Takeaways:
- Scope comes before lifecycle: a health app is not automatically device software.
- FDA recognizes IEC 62304 Edition 1.1 for medical-device software lifecycle processes.
- Safety class changes the required work, but it does not replace the product risk process.
- Maintenance, problem resolution, configuration management, and SOUP belong in the lifecycle from day one.
The first ticket is an intended-use decision
An engineer receives a request: “Add an alert when a lab value looks dangerous.” The code may be small. The intended use is not. Does the function merely store or display information? Does it analyze a signal? Does a clinician independently review the basis of a recommendation? What harm could follow if the software is wrong or unavailable?
Those questions belong before the sprint estimate. The FDA’s device software functions guidance explains the agency’s oversight policy for software functions that may meet the device definition and identifies categories where FDA intends to exercise enforcement discretion. The exact regulatory conclusion depends on the function and its claims.
Once the organization determines that software is itself a medical device or part of one, IEC 62304 supplies a lifecycle framework. The FDA consensus-standard record says IEC 62304:2006+A1:2015 defines lifecycle requirements for medical-device software and applies to development and maintenance. The same record notes that the standard does not cover validation and final release of the medical device.
The evidence map engineers can use
The standard is purchased text, so a blog should not impersonate it clause by clause. This map is a planning aid. Use the licensed standard and your quality system for the actual requirements.
| Workstream | Engineering question | Evidence that should stay connected |
|---|---|---|
| Development planning | Who does what, with which methods and tools? | Plan, responsibilities, lifecycle model, referenced procedures |
| Requirements analysis | What must the software do, and what must it never do? | Identified requirements, interfaces, risk controls, review record |
| Architecture and design | Where are responsibilities and risk controls allocated? | Architecture, units, interfaces, segregation rationale |
| Implementation and verification | What was built, reviewed, and tested? | Versioned code, review evidence, tests, results, unresolved anomalies |
| Integration and system testing | Do combined components meet the specified behavior? | Build identity, test environment, trace links, observed results |
| Release | Which known problems remain, and what exactly ships? | Release decision, configuration, anomaly record, archive |
| Maintenance | How are field changes assessed and controlled? | Change request, impact analysis, regression evidence, release history |
| Problem resolution | How does a defect move from report to closure? | Report, investigation, decision, correction, verification, notice |
| Configuration management | Can the team reproduce the evaluated software? | Item list, versions, baselines, change control, build record |
The hard part is not creating nine folders. It is keeping the links alive. A risk control points to a requirement. The requirement points to design and code. Verification shows the control was implemented. A later change shows which evidence was reconsidered.
Safety class is a work-scaling decision
IEC 62304 uses software safety classes A, B, and C. The class affects how much lifecycle work applies. Treat the classification as an engineering and risk-management decision with a written rationale, not a label chosen to reduce paperwork.
The useful conversation starts with failure. What hazardous situation can a software failure contribute to? Which controls outside the software reduce the possible harm? Are those controls independent and supported by evidence? The team then carries the result into planning, architecture, verification, and maintenance.
FDA’s premarket software guidance uses its own Basic and Enhanced documentation levels for premarket submissions. Do not silently equate those levels with IEC 62304 classes. They answer different documentation questions in different frameworks.
SOUP needs an owner, not a ban
Medical-device software contains operating systems, libraries, databases, and other components the device manufacturer did not develop under its own lifecycle. IEC 62304 calls out software of unknown provenance or pedigree, usually shortened to SOUP.
The practical job is inventory and control. Record what the component is, the exact version, why it is needed, known anomalies relevant to the device, cybersecurity and safety concerns, and the route for updates or replacement. Pin the evaluated version. Monitor problems that could change the risk analysis. Re-run the affected verification when it changes.
A dependency scanner can help find packages. It cannot decide whether an upstream defect affects a hazardous situation in your product. That link still needs a person.
Maintenance starts before release
The IEC publication record identifies the standard as “Medical device software - Software life cycle processes” and includes Amendment 1:2015 in the consolidated edition. Lifecycle means the job continues after the first release.
Suppose a library update closes a security flaw but changes timing around an alarm. The team needs the released baseline, affected requirements and risks, regression evidence, remaining anomalies, and a controlled decision. If those links live only in the memory of the engineer who left last spring, maintenance becomes archaeology.
We think the best implementation starts with one vertical trace. Pick a risk control. Follow it through the requirement, architecture, code, test, release, and first plausible maintenance change. The exercise will expose broken ownership faster than a document-count audit.
The Patient Square boundary
Patient Square is an AI clinical platform. Practice Copilot brings the whole practice under one AI copilot: an ambient AI Medical Scribe that hands back a structured SOAP note, ICD-10 suggestions, and a prescription draft minutes after the visit, plus a bundled AI EHR, scheduling, and messaging as you move up the plan. Hospitals get Hospital Copilot.
Patient Square does not represent Practice Copilot, Hospital Copilot, or its AI Medical Scribe as a medical device. This article is an educational explanation of a device-software lifecycle standard, not a claim that the standard applies to Patient Square or to every clinical software product.
If your team is defining a medical-device function, settle intended use and jurisdiction with qualified regulatory owners, obtain the licensed standard, and build the trace around your real process. For non-device clinical software, the HIPAA app architecture checklist covers a different question: how ePHI moves through the system. The healthcare interoperability guide covers exchange contracts rather than device lifecycle evidence.