On this page
- Choose the published European base and amendment
- Software lifecycle and device release are different boundaries
- Make software delivery evidence identifiable
- Questions before buying development services
- Example: contracting a diagnostic application update
- Use a baseline the next team can understand
- Frequently asked buying questions
- Related guidance
- Explore more standards buying guides
Choose the published European base and amendment
Software lifecycle and device release are different boundaries
The public scope concerns development and maintenance of software that is itself a medical device or forms part of a medical device. It states that validation and final release of the medical device are outside this document, including a device consisting entirely of software.
For procurement, identify the software function, the system interfaces and the people who own the broader device decisions. A development contract should explain the evidence the supplier will provide to that team, rather than implying that coding completion settles the device release.
Make software delivery evidence identifiable
| Deliverable | Question for the buyer |
|---|---|
| Release identity | Which software, configuration and supporting versions belong to the delivered release? |
| Lifecycle records | Which agreed development and maintenance evidence is included? |
| Device interfaces | What information passes to risk management and device assessment teams? |
| Support | Who handles defects, changes and evidence maintenance after delivery? |
The table is a commercial briefing map. It does not assign a software safety classification or reproduce the standard's lifecycle tasks. The responsible technical team must define the project work and acceptance criteria.
Questions before buying development services
- Which software items and interfaces are included in the supplier's assignment?
- Who approves requirements and answers incomplete or conflicting inputs?
- Which third-party components and development tools are used and identified?
- What records accompany an intermediate release and final handover?
- Who can maintain the software and its evidence when the initial contract ends?
Compare providers on evidence and support as well as features and delivery date. Ask about rights and access needed for maintenance, and about the work required from the manufacturer's own team. An executable file may be one deliverable among several.
Example: contracting a diagnostic application update
A manufacturer commissions an update to software used in a diagnostic device. The developer's initial quote lists new features and functional tests. The buyer supplies the existing release baseline and asks for a proposal identifying the lifecycle evidence, interfaces and change-review work included.
The agreed contract connects the new release to the manufacturer's risk-management and device-assessment assignments. It also identifies the defect-support contact and the evidence delivered at handover. The example describes procurement coordination; it does not classify the software or authorise device release.
Use a baseline the next team can understand
Keep release notes, configuration identities and agreed evidence together. Ask how a later correction will be linked to the original baseline and what records will be updated. This is especially useful when maintenance changes hands or a third-party component is replaced.
Define device validation, cybersecurity and usability assignments separately where relevant. Give each team clear input and output responsibilities. Shared software does not mean every service has the same scope, and the software lifecycle title should not be used as a shorthand for all medical-device evidence.
Frequently asked buying questions
Does EN 62304 cover final device release?
The public scope explicitly excludes that boundary. Assign the wider device work and identify what software information it needs.
Can I choose a software class from this article?
No classification is provided. Ask the responsible technical team to determine and document the project basis.
Does an old date mean I should buy the draft?
The verified European base and amendment remain published. Keep the successor project distinct from the document package agreed for current work.
Related guidance
Read risk management service buying, usability engineering purchasing and quality-system guidance.
Explore more standards buying guides
Browse standards by reference and subject to compare related document choices.