T-012-022 Software Design Phase 2 Checklist
Actors
Name | Title | Meaning | Approved Date & Time |
---|---|---|---|
Change history
Revision | Summary | Date |
---|---|---|
Process overview
The purpose of the Software Design Checklist review is to ensure the outputs of Phase 2 satisfy the criteria listed in the next section.
Project information
- Project title:
- Project manager (name and function):
Planning
Phase | Object | Done |
---|---|---|
Phase 1 Product Design Review | Establish input data | |
Phase 2 Software Design Review | SRs, Architectural Design and UI Prototypes | |
Phase 3 Software Candidate Release | Coding, integration and test plan | |
Phase 4 Software Verification Review | Software version verified and residual anomalies | |
Phase 5 Product Validation Review | Validation activities, Technical Documentation and DHF |
Previous reserves
Instructions
If there were any reserves or outstanding issues identified during Phase 1, list them here. Include a brief description of each reserve, the actions required to address them, and assign an owner and targeted completion date. See Product Design Phase 1 Checklist for an example.
N° | Documents / Purpose / Actions to implement | Owner | Targeted Date | Satisfying |
---|---|---|---|---|
Review according to ISO 13485 section 7.3.3
Product design
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
Review of product design inputs | |||
Main functions, Target Patient Population, Principle of operation, Intended conditions of use |
Validation
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
Validation protocol (including usability) | |||
Analysis of clinical data needs and possible clinical investigations. Application of EN ISO 14155-1:2003 |
Marketing
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
Market analysis : positioning/competing products/targeted markets |
Regulatory
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
Regulatory and Normative Plan | |||
Software classification |
Risk management
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
Preliminary Risk Plan and Analysis | |||
Initial Risk Management Report |
Cybersecurity
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
Cybersecurity risk plan |
AI/ML Development
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
AI/ML Development plan |
Review according to EN 62304
Planning (Class A, B, C)
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
4.3 EN 62304. The class of the software is identified | |||
5.1 EN 62304. Software Development Plan (Class A, B, C) | |||
5.1.9 EN 62304. Method for documented configuration management (Class A, B, C) |
Technical specification
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
5.2 EN 62304. Technical specifications of the Medical Device Software (SRS) (Class A, B, C) | |||
5.2.3 EN 62304. The requirements include RISK CONTROL measures implemented in the software to take into account hardware failures and possible software defects, depending on the MEDICAL DEVICE. (Class B, C) | |||
Are they complete ? | |||
Are they understandable ? | |||
Are they traceable with Safety Risks and Product Requirements ? | |||
Are they testable ? Can test criteria and performance of tests be determined ? | |||
Are they uniquely identified ? | |||
Do they include user interface related software requirements ? | |||
Do they include cybersecurity related software requirements and traceable with Security Risks ? |
Software verification planning
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
5.1.6 EN 62304. Planning the software verification (Class B, C) |
Architecture
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
5.3.1 EN 62304. SRs have been transformed into a documented ARCHITECTURE (Class B, C) | |||
5.3.2 EN 62304 ARCHITECTURE for the interfaces between the SOFTWARE ELEMENTS and external components external, as well as between the SOFTWARE ELEMENTS themselves. (Class B, C) | |||
5.3.3 EN 62304 Specification of functional and performance requirements for SOUP SOFTWARE ELEMENTS (Class B, C) | |||
5.3.4 EN 62304 Specification of SYSTEM hardware and software required for the SOUP SOFTWARE ELEMENT (Class B, C) | |||
5.3.5 EN 62304 Identification of separations necessary for RISK CONTROL (Class C) | |||
5.3.6 EN 62304 Checking the software ARCHITECTURE (Class B, C). Consistency of the architecture? | |||
5.3.6 EN 62304 Checking the software ARCHITECTURE (Class B, C). Verify that the software architecture allows the implementation of SRS? | |||
5.3.6 EN 62304 Checking the software ARCHITECTURE (Class B, C). Feasibility of use and maintenance of the system? | |||
7.1.1 EN 62304 SOFTWARE ELEMENTS which could contribute to a dangerous situation are identified (See ISO 14971) (Class B, C) | |||
7.1.2 - 7.1.5 EN 62304. Software Risk Analysis – Identification of potential causes / EVALUATION of published lists of SOUP ANOMALIES / Logging of potential causes / Logging of sequences of events (Class B, C) | |||
7.2 EN 62304. RISK CONTROL measures for each potential cause of the SOFTWARE ELEMENT contributing to a dangerous situation are documented in the RISK MANAGEMENT FILE. (Class B, C) |
Detailed conception
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
5.4.1 EN 62304. The software ARCHITECTURE is broken down until it is represented by the SOFTWARE UNITS. (Class B, C) | |||
5.4.2 EN 62304. Detailed design of each SOFTWARE UNIT of the SOFTWARE ITEM. (Class C) | |||
5.4.3 EN 62304. Detailed design of possible interfaces between the SOFTWARE UNIT and external components (hardware and software), as well as for interfaces between SOFTWARE UNITS. (Class C) |
Design history file
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
DHF updated. Available index and updated computer directories |
Review according to IEC 81001
Planning
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
4.2 EN 81001-5. The MANUFACTURER shall establish a PROCESS for managing RISKS associated with SECURITY. | |||
5.1.2 EN 81001-5. The MANUFACTURER shall establish risk-based procedural and technical controls for protecting the IT infrastructure used for development, production delivery and maintenance from unauthorized access, corruption and deletion. | |||
5.1.3 EN 81001-5. The MANUFACTURER shall establish and maintain secure coding standards consistent with current best practices related to the design and implementation of secure software systems. |
Software requirements analysis
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
5.2.1 EN 81001-5. SECURITY requirements are documented for the HEALTH SOFTWARE including requirements for SECURITY CAPABILITIES related to installation, operation, maintenance and decommissioning. | |||
5.2.3 EN 81001-5. The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) that identifies and manages the SECURITY risks of all REQUIRED SOFTWARE. |
Software architectural design
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
5.3.1 EN 81001-5. Specify a secure ARCHITECTURE | |||
5.3.2 EN 81001-5. Identify, enforce and maintain secure design practices. Document secure design best practices. | |||
5.3.3 EN 81001-5. Document and implement the architectural design review |
Software design
Object | Records & Comments | Satisfying | Reserves |
---|---|---|---|
5.4.1 EN 81001-5. Develop and document a secure HEALTH SOFTWARE design and maintain the use of best practices for the secure design. | |||
5.4.2 EN 81001-5. Include measures to address the THREATS identified in the THREAT MODEL. | |||
5.4.3 EN 81001-5. Identify and characterize each interface of the HEALTH SOFTWARE including physical and logical interfaces. | |||
5.4.4 EN 81001-5. Conduct design reviews to identify, characterize and track to closure WEAKNESSES associated with each significant revision of the secure design. |
Reserves
N° | Documents / Purpose / Actions to implement | Owner | Targeted Date |
---|---|---|---|
Conclusion
Instructions
Summarize the outcome of the Software Design Phase 2 review. This section should:
- State whether the reviewed output data is considered available, complete, and relevant.
- Confirm whether the phase milestone can be validated.
- Indicate clearly if any reserves have been raised and whether they affect the approval of the review.
- Include a direct statement on whether the review has been accepted, even in the presence of minor reserves.
Keep the wording concise, objective, and aligned with the overall project assessment.