EN 62304 Checklist
This checklist provides a comprehensive review of compliance with the EN ISO 62304:2006/A1:2015 standard for medical device software lifecycle processes. The checklist is structured according to the major clauses of the standard and should be completed as part of the quality management system documentation for the device.
Document Information
| Field | Value |
|---|---|
| Product Name | Legit.Health Plus |
| Version | 1.1.0.0 |
Software Safety Classification
Software safety classification
According to IEC 62304, the device can be classified as a Class B medical device. As such, not all the items of the checklist are required. When an item is required, it will be noted in the column Required of the following table.
Primary Lifecycle Processes
General Requirements
| Reference | Software Lifecycle Process | Required | Fulfilled | Evidence/Comments |
|---|---|---|---|---|
| 4.1 | Quality Management System | TRUE | ☑ | Quality management system is established and documented according to UNE-EN ISO 13485:2018. QMS procedures applicable to software development are documented in GP-012 Design, redesign and development. |
| 4.2 | Risk Management Process | TRUE | ☑ | Risk management process is established according to UNE-EN ISO 14971:2020 and documented in GP-013 Risk management. Software-specific risks are documented in R-TF-013-002 Risk management record and R-TF-013-003 Risk management report. |
| 4.3 | Software safety classification | TRUE | ☑ | Software is classified as Class B according to IEC 62304. Classification is documented in R-TF-012-023 Software Development Plan section "Software safety classification". |
| 4.4 | Legacy software | TRUE | ☑ | SOUP (Software of Unknown Provenance) components are identified and documented in SOUP directory. Requirements for SOUP are specified in software architecture documentation and managed according to GP-012 change control procedures. |
Software Development Process
Software development planning
| Reference | Software Lifecycle Process | Required | Fulfilled | Evidence/Comments |
|---|---|---|---|---|
| 5.1.1 | Plan software development process | TRUE | ☑ | Software development process is planned and documented in GP-012 and R-TF-012-023 Software Development Plan. Five-phase development methodology (Product Design, Software Design, Agile Development, Verification, Validation) is specified. |
| 5.1.2 | Keep plan current | TRUE | ☑ | Software development plan is maintained current through GP-023 Change control management process. Updates are recorded in Git version control system |
| 5.1.3 | Document software development plan | TRUE | ☑ | Software development plan documented in R-TF-012-023 including organization, roles, planning approach, project roadmap, milestones, development activities, deliverables, and responsibilities. |
| 5.1.4 | Software development standards, methods and tools planning | TRUE | ☑ | Development standards (Python coding standards, documentation standards), methods (phase-gate approach, agile sprints), and tools (Git, Python, testing frameworks) are documented in R-TF-012-023 Software Development Plan and GP-012. |
| 5.1.5 | Software integration and integration testing | TRUE | ☑ | Integration strategy documented in R-TF-012-023 Phase 3 "Agile and Iterative Development" and Phase 4 "Software Verification". Integration test plans documented in test-plans directory. |
| 5.1.6 | Software verification planning | TRUE | ☑ | Verification activities (unit testing, integration testing, system testing) planned in R-TF-012-023 Phase 4. Test protocols and results documented in test-plans and test-runs directories. |
| 5.1.7 | Software risk management planning | TRUE | ☑ | Risk management activities documented in R-TF-013-001 Risk management plan according to GP-013 and UNE-EN ISO 14971:2020. Software risks tracked in R-TF-013-002. |
| 5.1.8 | Documentation planning | TRUE | ☑ | Documentation requirements documented in R-TF-012-023 including specifications, design documents, test protocols, IFU. Documentation structure established with organized directories for all documentation types. |
| 5.1.9 | Software configuration management planning | TRUE | ☑ | Configuration management documented in GP-023 Change control management. Git version control system used throughout project with branching strategy and release management. Traceability maintained through Git commits and tags. |
| 5.1.10 | Supporting items to be controlled | TRUE | ☑ | SOUP components documented in SOUP directory. Development tools, libraries, and dependencies tracked. GP-029 API Verification and Validation Plan addresses software validation and external software control. |
| 5.1.11 | Software configuration item control before verification | TRUE | ☑ | Configuration items controlled through Git version control before verification. Change control process (GP-023) ensures baseline establishment. Test execution requires specific version identification. Evidence in Git repository structure and change control procedures. |
| 5.1.12 | Identification and avoidance of common software defects | TRUE | ☑ | Code review processes, Python coding standards, automated testing (pytest), and static analysis implemented. Development practices documented in GP-012 and R-TF-012-023. Test coverage tracked in test execution records. |
Software requirements analysis
| Reference | Software Lifecycle Process | Required | Fulfilled | Evidence/Comments |
|---|---|---|---|---|
| 5.2.1 | Define and document software requirements from system requirements | TRUE | ☑ | Software requirements derived from system requirements documented in Description and specifications and software requirements directory. Requirements traceable to product requirements. |
| 5.2.2 | Content of the software requirements | TRUE | ☑ | Software requirements include functional requirements, performance requirements, API interface requirements (REST API, FHIR compliance), safety requirements, and security requirements. Documented with sufficient detail in software-requirements and product-requirements directories with JSON specifications. |
| 5.2.3 | Integration of risk control measures into software requirements | TRUE | ☑ | Risk control measures from R-TF-013-002 Risk management record integrated into software requirements. Risk-software requirements traceability maintained in risk management documentation. Software requirements explicitly address identified hazards and risk mitigation strategies. |
| 5.2.4 | Re-evaluation of the risk analysis of the medical device | TRUE | ☑ | Risk analysis re-evaluated when software requirements change through GP-013 Risk management process. Changes tracked in R-TF-013-002 with version history. Change control process (GP-023) requires risk impact assessment for all requirement changes. |
| 5.2.5 | Update of system requirements | TRUE | ☑ | System requirements updated when software requirements impact system level through GP-023 Change control management. Bidirectional traceability maintained between system and software requirements. Change history tracked in Git repository and documented in change control records. |
| 5.2.6 | Verification of the software requirements | TRUE | ☑ | Software requirements verified through requirements reviews documented in review-meeting directory. Verification confirms completeness, consistency, correctness, testability, and traceability. Test cases in test-plans directory map to requirements demonstrating testability and verification. |
Software architectural design
| Reference | Software Lifecycle Process | Required | Fulfilled | Evidence/Comments |
|---|---|---|---|---|
| 5.3.1 | Transform software requirements into an architecture | TRUE | ☑ | Software architecture documented in Description and specifications with API design, component architecture (HTTP API, Processors, Orchestrator, Report builder), AI model architecture. Architecture fulfills requirements. Documented in description-and-specifications and STED. |
| 5.3.2 | Develop an architecture for the interfaces | TRUE | ☑ | Interface architecture documented with REST API design, FHIR compliance, OpenAPI specifications. Interface specifications include endpoints, data formats (JSON), HTTP protocols, authentication. Documented in description-and-specifications section "Technical features" and verified in test execution records (TEST_013, TEST_017). |
| 5.3.3 | Specify functional and performance requirements for SOUP | TRUE | ☑ | SOUP components documented in SOUP directory with functional and performance requirements. Requirements ensure SOUP components meet device safety and performance needs. Software Bill of Materials (SBOM) maintained. |
| 5.3.4 | Specify hardware and software required for SOUP | TRUE | ☑ | Hardware and software requirements for SOUP documented in IFU technical specifications (IFU) and SOUP documentation. Python runtime environment, operating systems, hardware specifications for AI model execution defined. |
| 5.3.5 | Identify segregation necessary for risk control | FALSE | N/A | Not required for Class B software. However, modular design implemented with clear component separation (API, Processors, Orchestrator, Report builder) as documented in architecture documentation. Component segregation follows software engineering best practices. |
| 5.3.6 | Verify software architecture | TRUE | ☑ | Architecture verified through design reviews documented in review-meeting directory. Reviews verify architecture fulfills requirements, implements risk controls, follows design standards. Architecture review records maintained. |
Software detailed design
| Reference | Software Lifecycle Process | Required | Fulfilled | Evidence/Comments |
|---|---|---|---|---|
| 5.4.1 | Subdivide software into software units | TRUE | ☑ | Software subdivided into modules (HTTP API, Processors, Orchestrator, Report builder) and classes/functions with defined interfaces. Component structure documented in STED "Key materials" section. Python modules organized with clear responsibilities. |
| 5.4.2 | Develop detailed design for each software unit | FALSE | N/A | Not required for Class B software. Code structure, algorithms, and implementation details documented through inline code documentation, API specifications (OpenAPI), and technical documentation in description-and-specifications. |
| 5.4.3 | Develop detailed design for interfaces | FALSE | N/A | Not required for Class B software. Interface design documented at architectural level through REST API specifications, FHIR data models, OpenAPI specifications. API documentation and communication protocols documented in description-and-specifications "Technical features" section. |
| 5.4.4 | Verify detailed design | FALSE | N/A | Not required for Class B software. Design verification performed through code reviews, automated testing (pytest), and system testing. Test execution results in test-runs directory demonstrate verification. |
Software unit implementation and verification
| Reference | Software Lifecycle Process | Required | Fulfilled | Evidence/Comments |
|---|---|---|---|---|
| 5.5.1 | Implement each software unit | TRUE | ☑ | Software units implemented in Python following coding standards. Source code managed in Git repository () with version control, code reviews, and comprehensive documentation. Implementation follows requirements and design specifications. |
| 5.5.2 | Establish software unit verification process | TRUE | ☑ | Unit verification process includes pytest unit testing, code reviews, and automated testing. Process established in GP-012 and R-TF-012-023. Test framework implemented throughout project. procedures and development plan documentation. |
| 5.5.3 | Document software unit acceptance criteria | TRUE | ☑ | Acceptance criteria defined in test plans (test-plans/ directory) including functional correctness, test coverage, code quality standards, and compliance requirements. Test cases specify expected outcomes and pass/fail criteria. Documented in. |
| 5.5.4 | Document additional software unit acceptance criteria | FALSE | N/A | Not required for Class B software. Standard acceptance criteria through test plans sufficient. Code coverage and quality metrics tracked through pytest and development tools but formal documentation not mandatory. |
| 5.5.5 | Document software unit verification results | TRUE | ☑ | Unit verification results documented in test execution records directory. Test results include actual outputs, pass/fail status, and evidence. Git commit history provides verification traceability. |
Software integration and integration testing
| Reference | Software Lifecycle Process | Required | Fulfilled | Evidence/Comments |
|---|---|---|---|---|
| 5.6.1 | Integrate software units | TRUE | ☑ | Software units integrated following R-TF-012-023 Phase 3 "Agile and Iterative Development" strategy. Integration performed incrementally with Git version control and continuous integration. Component integration (API, Processors, Orchestrator, Report builder) documented in architecture and verified through integration tests. |
| 5.6.2 | Verify software integration | TRUE | ☑ | Integration verification through integration testing documented in test-plans/ and test-runs/ directories. Tests verify interface functionality (REST API, FHIR compliance), data flow between components. Examples: TEST_013 (FHIR compliance), TEST_017 (API functionality). |
| 5.6.3 | Document integration testing | TRUE | ☑ | Integration test strategy documented in R-TF-012-023 and test plans in test-plans/ directory. Test cases specify test objectives, steps, expected outcomes for component integration. PLAN_012 example demonstrates integration testing approach for multiple images endpoint. |
| 5.6.4 | Document test procedure and test case specification | TRUE | ☑ | Test procedures and cases documented in test-plans/ directory with test objectives, preconditions, input data, steps, expected outcomes, requirements traceability, and risk control mappings. Each test plan includes comprehensive specification. Example: PLAN_012. |
| 5.6.5 | Use test procedures for conducting integration testing | TRUE | ☑ | Integration testing conducted following documented test procedures. Test execution records in test-runs/ directory document actual results, evidence (JSON outputs, API responses), pass/fail status. Examples: TEST_013, TEST_017 show execution following test procedures with detailed actual results. |
| 5.6.6 | Document integration test results | TRUE | ☑ | Integration test results documented in test-runs/ directory including test execution records, actual outputs, evidence (API responses, FHIR resources), pass/fail status, deviations. Test summary available in test execution records. |
| 5.6.7 | Document regression tests | TRUE | ☑ | Regression testing documented through test execution across versions. Test cases re-executed after changes to verify no adverse effects. Git version control and test execution records track regression testing. Continuous integration approach ensures regression testing after changes documented in R-TF-012-023. |
| 5.6.8 | Use software problem resolution process for anomalies | TRUE | ☑ | Anomalies managed through GP-023 Change control management process. Problem reports tracked in Git issues and change control system. Problem resolution, investigation, and corrective actions documented per GP-023. |
Software system testing
| Reference | Software Lifecycle Process | Required | Fulfilled | Evidence/Comments |
|---|---|---|---|---|
| 5.7.1 | Establish tests for software requirements validation | TRUE | ☑ | System test cases established in test-plans/ directory to validate software requirements. Tests cover functional requirements (API functionality, FHIR compliance, diagnosis support), performance, safety, security, usability. Test cases traceable to requirements through "Verifies software requirements" and "Risk control for" sections in test plans. |
| 5.7.2 | Use software problem resolution process for anomalies | TRUE | ☑ | Anomalies from system testing managed through GP-023 Change control management. Problems tracked with severity assessment, investigation, resolution. Problem tracking integrated with development workflow through Git and change control procedures. Documented |
| 5.7.3 | Retest after changes to software | TRUE | ☑ | Retesting and regression testing performed after changes. Test execution records document re-execution of tests. Change impact analysis per GP-023 guides retest scope. Version control in Git tracks changes and associated testing. Test-runs/ directory shows multiple test executions validating changes. |
| 5.7.4 | Document software system testing protocol | TRUE | ☑ | System testing protocol documented in R-TF-012-023 Phase 4 "Software Verification" and test plans in test-plans/ directory. Protocol includes test strategy, test environment (API integration), test data, execution procedures, acceptance criteria. Test plan templates define consistent testing approach. |
| 5.7.5 | Document software system testing results | TRUE | ☑ | System testing results documented in test-runs/ directory with execution records, actual results, evidence (API responses, JSON outputs), pass/fail status, test coverage. Results demonstrate software meets requirements and is safe for intended use. Test execution provides comprehensive validation evidence. |
Software release
| Reference | Software Lifecycle Process | Required | Fulfilled | Evidence/Comments |
|---|---|---|---|---|
| 5.8.1 | Ensure software verification is complete | TRUE | ☑ | Release checklist in R-TF-012-038 Verified Version Release verifies all verification activities complete. Test execution records demonstrate comprehensive verification. Release process in R-TF-012-023 Phase 4-5 ensures verification completion before release. |
| 5.8.2 | Document known residual anomalies | TRUE | ☑ | Known residual anomalies documented in R-TF-012-038 Verified Version Release template includes "Known Limitations" section. Anomalies tracked in issue tracking system (Git issues) and release documentation. Release notes document known issues for each version. |
| 5.8.3 | Evaluate known residual anomalies | TRUE | ☑ | Residual anomalies evaluated for safety impact through risk assessment (R-TF-013-002). Evaluation considers clinical impact and benefit-risk balance per GP-013 Risk management. Anomaly impact assessment documented in risk management records and release approval documentation. |
| 5.8.4 | Document released version | TRUE | ☑ | Released version documented in DeviceCharacterisation (Version 1.1.0.0), R-TF-012-038, declaration of conformity (R-TF-001-007). Version information in IFU, label (R-TF-001-008), UDI. Git tags mark releases. Documented in DeviceCharacterisation and device description documents. |
| 5.8.5 | Document how released software was created | TRUE | ☑ | Build process documented in R-TF-012-023 development plan. Software Bill of Materials (SBOM) in GP-110 documents components, versions, dependencies. Python environment, dependencies, and build procedures documented. Git repository provides complete build traceability and reproducibility. |
| 5.8.6 | Ensure activities and tasks are complete | TRUE | ☑ | Release approval process documented in GP-012 and R-TF-012-023. R-TF-012-038 Verified Version Release checklist verifies all activities complete including development, verification, documentation, regulatory requirements. Release requires JD-001, JD-003, JD-004 approvals per organizational roles defined in R-TF-012-023. |
| 5.8.7 | Archive software | TRUE | ☑ | Released software archived in Git repository with tags for version identification. Complete source code, documentation, test records maintained in QMS structure. GP-019 Document and record control governs archival. Git provides permanent archive with full history enabling release recreation. Backup systems ensure archive preservation. |
| 5.8.8 | Assure repeatability of software release | TRUE | ☑ | Release repeatability assured through Git version control, documented build procedures in R-TF-012-023, SBOM dependency management, and automated build processes. Git tags and commit history enable exact release recreation. Development environment specifications documented. |
Software Maintenance Process
| Reference | Software Lifecycle Process | Required | Fulfilled | Evidence/Comments |
|---|---|---|---|---|
| 6.1 | Establish software maintenance plan | TRUE | ☑ | Software maintenance documented in R-TF-012-023 and GP-012 procedures. Plan includes feedback handling (GP-007 Post-market surveillance), problem resolution (GP-023), modification procedures, release management. Post-market activities documented in R-TF-007-001 PMS Plan. Documented in procedures and post-market surveillance documentation. |
| 6.2.1 | Develop and document procedures for receiving feedback | TRUE | ☑ | Feedback procedures established in GP-007 Post-market surveillance and GP-021 Complaints and incident management (referenced in GP-013). Feedback channels include customer support, complaint forms, post-market surveillance. Procedures documented |
| 6.2.1.1 | Document feedback evaluation process | TRUE | ☑ | Feedback evaluation process documented in GP-021 (referenced in multiple procedures). Process includes review, classification, severity assessment, and action determination. Evaluation criteria and responsibilities defined in QMS procedures and R-TF-007-001 PMS Plan. |
| 6.2.2 | Determine whether feedback is a problem | TRUE | ☑ | Feedback evaluated per GP-021 to determine if it represents a problem requiring corrective action. Evaluation considers safety impact, performance, regulatory requirements. Determination documented in complaint investigation records and post-market surveillance tracking. |
| 6.2.3 | Provide adverse event information to users | TRUE | ☑ | Adverse event communication procedures in GP-021 and regulatory requirements per MDR. Safety notifications, field safety notices communicated to users. Vigilance system in place. Communications documented and tracked per regulatory requirements. |
| 6.2.4 | Documented feedback | TRUE | ☑ | All feedback documented with date, source, description, classification, evaluation per GP-021. Records maintained in complaint management system and R-TF-007-001 PMS Plan tracking. Post-market surveillance activities documented |
| 6.2.5 | Document evaluation of problem reports | TRUE | ☑ | Problem report evaluations including investigation, root cause analysis, impact assessment documented per GP-023 Change control management. Evaluations recorded in change control records and complaint investigations per GP-021 procedures. |
| 6.3.1 | Use software problem resolution process | TRUE | ☑ | Software problems resolved using GP-023 Change control management process. Process includes problem investigation, change implementation, verification, release. Problem tracking integrated with Git version control and change management. Documented |
| 6.3.2 | Analyze change request regarding patient safety | TRUE | ☑ | Change requests analyzed for patient safety impact through GP-013 Risk management. Risk assessment conducted per R-TF-013-001 plan for all changes. Safety analysis considers hazards, risk controls, benefit-risk. Results documented in R-TF-013-002 Risk management record and change control records. and /. |
Software Risk Management Process
| Reference | Software Lifecycle Process | Required | Fulfilled | Evidence/Comments |
|---|---|---|---|---|
| 7.1.1 | Identify software items that could contribute to a hazardous situation | TRUE | ☑ | Software items (API functions, AI model outputs, data processing, interfaces) that could contribute to hazards identified through hazard analysis in R-TF-013-002. Software failure modes, incorrect outputs, interface failures analyzed. Risk management integrated in GP-013 |
| 7.1.2 | Identify potential causes of contribution to a hazardous situation | TRUE | ☑ | Potential causes including software defects, incorrect AI model outputs, data errors, API interface failures, integration issues identified in R-TF-013-002. FMEA and hazard analysis techniques used. Causes documented in risk management record per GP-013 process. |
| 7.1.3 | Evaluate published SOUP anomaly lists | TRUE | ☑ | SOUP anomaly lists, security advisories, CVE databases evaluated for components documented. Evaluation during SOUP selection and ongoing monitoring. SBOM documentation in GP-110 tracks components and security. Results in R-TF-013-002 SOUP risk assessments. |
| 7.1.4 | Document potential causes in risk management file | TRUE | ☑ | Potential causes documented in R-TF-013-002 Risk management record with cause description, contributing software items, relationship to hazards. Risk management file includes comprehensive documentation of software-related hazards and causes. |
| 7.2.1 | Define risk control measures | TRUE | ☑ | Risk control measures defined in R-TF-013-002 including software design controls (input validation, error handling), verification activities (testing documented in test-plans/ and test-runs/), user warnings (in IFU), operational controls. Measures documented per GP-013 Risk management process. |
| 7.2.2 | Document risk control measures in risk management file | TRUE | ☑ | Risk control measures documented in R-TF-013-002 with description, implementation approach, verification methods, traceability to requirements. Implementation tracked through development activities and test execution. |
| 7.3.1 | Verify risk control measures | TRUE | ☑ | Risk control measures verified through testing (test-runs/ directory), code reviews, validation activities. Verification confirms effective risk reduction and proper implementation. Results documented in test execution records and R-TF-013-002. Verification activities traceable to risk controls through "Risk control for" sections in test plans. |
| 7.3.2 | Document any new sequence of events | TRUE | ☑ | New hazardous situations identified during risk control implementation documented and analyzed per GP-013 process. New risks added to R-TF-013-002 Risk management record with appropriate controls defined. Change control (GP-023) ensures new hazards from modifications are identified and addressed. |
| 7.3.3 | Document traceability | TRUE | ☑ | Traceability maintained between hazards, risks, risk controls, software requirements, design elements, verification activities. Test plans include "Verifies software requirements" and "Risk control for" sections establishing traceability. Risk management documentation and test documentation provide comprehensive traceability matrix. Documented across risk management and verification documentation. |
| 7.4.1 | Analyze changes to medical device software with respect to safety | TRUE | ☑ | Software changes analyzed for safety impact per GP-023 Change control management before implementation. Change impact analysis considers affected functions, potential new hazards, impact on existing risk controls. Analysis documented in change control records. Flowchart in GP-023 shows safety evaluation in change process. |
| 7.4.2 | Analyze impact of software changes on existing risk analysis | TRUE | ☑ | Impact of changes on existing risk analysis evaluated per GP-023 and GP-013 integration. Evaluation determines if risk management file update required. Impact assessment considers effect on identified hazards, risks, risk control measures. Analysis documented in change impact assessments within change control records. |
| 7.4.3 | Update risk management | TRUE | ☑ | R-TF-013-002 Risk management record updated when changes affect risk analysis, new hazards identified, or risk controls modified. Updates performed per GP-013 with version control in Git and change history. Risk management plan (R-TF-013-001) states annual review and updates as needed. |
Software Configuration Management Process
| Reference | Software Lifecycle Process | Required | Fulfilled | Evidence/Comments |
|---|---|---|---|---|
| 8.1.1 | Establishment of means to identify the configuration items | TRUE | ☑ | Configuration items (source code, documentation, specifications, test cases) identified and controlled through Git version control. Identification scheme uses version numbers (1.1.0.0), Git commit hashes, tags. Configuration identification documented in GP-023 Change control management. Configuration items organized in QMS structure. |
| 8.1.2 | Identification of SOUP | TRUE | ☑ | SOUP components identified with name, version, supplier, purpose directory. SBOM documented in GP-110 with component tracking. Python dependencies managed through requirements files. SOUP version management ensures traceability. |
| 8.1.3 | Identification of system configuration items | TRUE | ☑ | System configuration including Python runtime, API deployment environment, network configurations documented in IFU technical specifications (IFU) and STED. System requirements documented in description-and-specifications. Configuration items tracked through SBOM and deployment documentation. |
| 8.2.1 | Approve change requests | TRUE | ☑ | Change requests reviewed and approved per GP-023 Change control management. Approval authorities defined (JD-001, JD-003, JD-004) in R-TF-012-023 organization section. Approval considers technical feasibility, safety impact (flowchart in GP-023 shows safety evaluation), resources, regulatory implications. |
| 8.2.2 | Implement change control | TRUE | ☑ | Change control process implemented per GP-023 including change request, evaluation, approval, implementation, verification, release. All changes tracked in Git version control and change control system. |
| 8.2.3 | Communicate configuration item changes | TRUE | ☑ | Configuration changes communicated to stakeholders (development team, QA, regulatory, users when applicable) per GP-023 procedures and GP-011 Provision of service for customer communications. Change notifications include description, impact, implementation status. Git commit messages and change records document communications. Release notes communicate changes to users. |
| 8.2.4 | Provide means for traceability | TRUE | ☑ | Traceability maintained through Git version control, test case mappings to requirements, risk-requirement traceability in risk management. Test plans include "Verifies software requirements" sections. Git commit history provides complete traceability of changes. Project structure organizes documentation for traceability across requirements, design, verification, risk management. |
| 8.3 | Configuration status accounting | TRUE | ☑ | Configuration status tracked through Git version control (commit history, tags, branches), version documentation (DeviceCharacterisation shows Version 1.1.0.0), change control system. Status information available through Git logs, release documentation (R-TF-012-038), change records. Status reports generated for releases and audits. Current configuration state visible in repository structure and documentation version information. |
Software Problem Resolution Process
| Reference | Software Lifecycle Process | Required | Fulfilled | Evidence/Comments |
|---|---|---|---|---|
| 9.1 | Prepare problem reports | TRUE | ☑ | Problem reports prepared documenting description, severity, affected versions, reproduction steps, impact. Git issues used for problem tracking. Problem report procedures defined in GP-023 Change control management. Problem reports created for defects, complaints, anomalies identified through testing, post-market surveillance, user feedback. Template and procedures in GP-023. |
| 9.2 | Investigate the problem | TRUE | ☑ | Problems investigated to determine root cause, scope, affected systems, potential solutions. Investigation includes code analysis, test reproduction, documentation review. Investigation results documented in problem reports (Git issues) and investigation records. Investigation approach documented in GP-023 change control process. |
| 9.3 | Advise relevant parties | TRUE | ☑ | Relevant parties (development team, QA, regulatory, management, users) advised of problems per GP-023 and GP-021. Safety-critical problems follow escalation in GP-021 Complaints and incident management. Communication procedures ensure appropriate stakeholders informed. User communication through support channels and safety notices when applicable. |
| 9.4 | Use change control process | TRUE | ☑ | Problem resolution changes implemented through GP-023 Change control management. Process ensures changes evaluated, approved, implemented, verified, released in controlled manner. Change control records link problems to resolutions. Git version control tracks problem fixes with flowchart showing change evaluation and approval process. |
| 9.5 | Maintain records | TRUE | ☑ | Problem resolution records including problem reports (Git issues), investigations, change requests, implementation records, verification results (test-runs/) maintained. Records stored in Git repository, change control system, QMS documentation structure (). Record retention follows GP-019 Document and record control. Git provides permanent record with full history. |
| 9.6 | Analyze problems for trends | TRUE | ☑ | Problems analyzed for trends through post-market surveillance (GP-007, R-TF-007-001 PMS Plan), quality management review. Trend analysis identifies systemic issues, common failure modes, improvement areas. Analysis documented in PMS reports (R-TF-007-003 PSUR) and quality review. Results inform preventive actions and process improvements. |
| 9.7 | Verify software problem resolution | TRUE | ☑ | Problem resolutions verified through testing, inspection, review to confirm fix and no adverse effects. Verification includes retesting fixed functionality and regression testing. Test execution records in test-runs/ directory document verification. Verification results documented in problem resolution records and test records. Test cases re-executed after fixes to verify resolution. |
| 9.8 | Test documentation contents | TRUE | ☑ | Test documentation verified for completeness, accuracy, consistency with testing performed. Test documentation review ensures test cases, procedures, results properly documented and traceable. Review documented in test review records. Test plans and test runs demonstrate comprehensive documentation. |
Summary
| Section | Total Items | Required Items | Percentage of Required |
|---|---|---|---|
| 4. General Requirements | 4 | 4 | 100% |
| 5. Software Development | 54 | 46 | 85% |
| 6. Software Maintenance | 9 | 9 | 100% |
| 7. Software Risk Management | 12 | 12 | 100% |
| 8. Configuration Management | 8 | 8 | 100% |
| 9. Problem Resolution | 8 | 8 | 100% |
| Total | 95 | 87 | 92% |
Summary Notes
Of the 95 total items in EN ISO 62304:2006/A1:2015, 87 items (92%) are required for Class B software. The 8 items not required are specific to Class C software and relate to detailed design documentation and additional verification activities.
This summary provides an overview of compliance requirements. Complete the "Fulfilled" checkboxes during verification activities to track compliance status. Calculate fulfillment percentage by dividing fulfilled required items by total required items.
Compliance Statement
☑ Full Compliance: All required items have been fulfilled and documented appropriately.
☐ Partial Compliance: Some items remain unfulfilled. See action plan below.
☐ Non-Compliance: Significant items are unfulfilled. Immediate corrective action required.
Signature meaning
The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:
- Author: Team members involved
- Reviewer: JD-003, JD-004
- Approver: JD-001