EN 82304 Checklist
This checklist provides a comprehensive review of compliance with the EN IEC 82304-1:2016 standard for health software - Part 1: General requirements for product safety. This standard applies to health software products intended to be used by patients or healthcare providers.
Document Information
| Field | Value |
|---|---|
| Product Name | Legit.Health Plus |
| Version | 1.1.0.0 |
General Requirements
| Clause | Requirement | Fulfilled | Evidence/Comments |
|---|---|---|---|
| 4.1 | The manufacturer shall implement a quality management system | ☑ | Quality management system established and documented according to UNE-EN ISO 13485:2018. QMS includes documented procedures, work instructions, and records for all health software lifecycle processes. QMS procedures include GP-012 Design, redesign and development covering software lifecycle. directory. |
| 4.2 | The manufacturer shall have a risk management system | ☑ | Risk management system established according to UNE-EN ISO 14971:2020 and documented in GP-013 Risk management. Risk management process includes risk analysis, evaluation, control, post-production monitoring. Risk management activities documented in R-TF-013-001 Plan, R-TF-013-002 Record, R-TF-013-003 Report. / and risk-management/. |
Safety and Security Requirements
Health software safety requirements
| Clause | Requirement | Fulfilled | Evidence/Comments |
|---|---|---|---|
| 5.1.1 | Establish and document a health software safety specification | ☑ | Health software safety specification established in software requirements (design-and-development/software-requirements/) derived from risk analysis (R-TF-013-002). Safety-related requirements include risk control measures, safety-critical functions. Specification documented with functional and safety requirements traceable to risk management. |
| 5.1.2 | The health software safety specification shall be derived from the intended use | ☑ | Safety specification derived from intended use documented in Description and specifications (overview-and-device-description/description-and-specifications). Intended users (healthcare professionals), use environment (clinical setting), reasonably foreseeable misuse addressed. Traceability between intended use and safety requirements maintained in documentation. |
Data created, processed and exported by health software
| Clause | Requirement | Fulfilled | Evidence/Comments |
|---|---|---|---|
| 5.2.1 | Maintain integrity of data throughout health software lifecycle | ☑ | Data integrity maintained through input validation, FHIR data standards compliance (TEST_013 evidence), error checking, API authentication/authorization. Data validation rules implemented in software design. Integrity measures verified through testing (test-runs/ directory). Database integrity constraints ensure data consistency. Documented in description-and-specifications and verified in. |
| 5.2.2 | Prevent corruption of data | ☑ | Data corruption prevention through input validation, error handling, JSON data validation, HTTPS/TLS encryption for API communications. Software implements validation rules, error detection for data integrity. Measures documented in architecture (description-and-specifications) and verified through API testing (TEST_013, TEST_017 show data validation and FHIR compliance). |
| 5.2.3 | Provide means for backing up and restoring data | ☑ | As API-based software, data backup/restoration is healthcare organization responsibility. IFU provides guidance on data retention, backup recommendations, data export capabilities through API. API provides data export functionality (FHIR-compliant outputs documented in TEST_013, TEST_017). Data backup guidance in IFU and integration documentation. R-TF-001-006 IFU validation. |
| 5.2.4 | Document retention requirements for data | ☑ | Data retention requirements documented in IFU (information-provided-by-the-manufacturer/R-TF-001-006) and GP-011 Provision of service. Requirements specify data retention periods, archival procedures per regulatory requirements and customer agreements. Retention policies address healthcare data regulations and communicated to users in service documentation. |
Validation of software used in the health software development process
| Clause | Requirement | Fulfilled | Evidence/Comments |
|---|---|---|---|
| 5.3.1 | Validate software tools used in health software development | ☑ | Software development tools (Python, pytest testing framework, Git version control, IDEs, static analysis tools) validated for fitness for use. Tool validation addresses tool functionality, version control, appropriate use. Critical tools affecting product quality formally validated. API validation documented per GP-029 API Verification and Validation Plan including testing frameworks and development tools. |
| 5.3.2 | Maintain records of validation | ☑ | Tool validation records document tool identification, version, validation activities, validation results per GP-029 API Verification and Validation Plan. Records maintained for tools affecting product quality/safety (Python runtime, testing frameworks, version control). Validation records in test-runs/ directory. Tool inventory tracked in SBOM (SBOM documentation in GP-110). Validated tools documented with version and qualification status. |
Product Lifecycle Requirements
Health software development lifecycle
| Clause | Requirement | Fulfilled | Evidence/Comments |
|---|---|---|---|
| 6.1.1 | Establish and document health software development lifecycle | ☑ | Health software development lifecycle is established according to IEC 62304 and documented in R-TF-012-006 Lifecycle plan and report and GP-012 Design, redesign and development. Lifecycle includes planning, requirements analysis, design, implementation, testing, release, maintenance, and decommissioning phases. Lifecycle model and activities are documented in development procedures. |
| 6.1.2 | Define outputs for each phase of the lifecycle | ☑ | Outputs for each lifecycle phase are defined in GP-012 and R-TF-012-006 Lifecycle plan and report. Outputs include requirements specifications, design documents, source code, test plans, test results, release documentation, and maintenance records. Output requirements are specified in procedure documents and templates within the DHF. |
| 6.1.3 | Define verification activities for each output | ☑ | Verification activities (reviews, inspections, testing, analysis) are defined for each lifecycle output to ensure outputs meet requirements and quality criteria. Verification activities include requirements review, design review, code review, unit testing, integration testing, system testing, and documentation review. Verification activities and acceptance criteria are documented in GP-012 and DHF. |
Health software validation
| Clause | Requirement | Fulfilled | Evidence/Comments |
|---|---|---|---|
| 6.2.1 | Validate health software before initial release | ☑ | Health software validation is performed before initial release to ensure software meets user needs and intended use. Validation includes system testing, API testing, usability testing, clinical validation, and acceptance testing. Validation plan, protocols, and results are documented in GP-029 API Verification and Validation Plan, test-runs/ directory, and R-TF-015-003 Clinical evaluation report. |
| 6.2.2 | Demonstrate that the software product satisfies user requirements | ☑ | Validation demonstrates software satisfies user requirements through test execution, user acceptance testing, and clinical evaluation. Validation test cases are traceable to user requirements and intended use. Validation results document compliance with requirements. Results are documented in GP-029 API Verification and Validation Plan, validation reports within DHF including test-runs/ directory (TEST_013, TEST_017 showing FHIR compliance), and R-TF-015-003. |
| 6.2.3 | Conduct validation in the intended environment of use | ☑ | Validation is conducted in representative environment matching intended use conditions including API integration, network configurations, and user workflows. Environment specifications are documented in GP-029 validation protocol. Validation environment represents real-world deployment conditions including API endpoints, authentication mechanisms, and data exchange patterns documented in test-runs/ directory and validation reports within DHF. |
| 6.2.4 | Document validation results | ☑ | Validation results including test execution records, acceptance criteria, pass/fail status, identified issues, and validation conclusion are documented. Validation reports demonstrate software is safe and effective for intended use. Validation documentation is maintained in DHF including GP-029 API Verification and Validation Plan, test-runs/ directory with execution evidence (TEST_013, TEST_017), issue resolution, and validation summary report in product-verification-and-validation/. |
Health software maintenance
| Clause | Requirement | Fulfilled | Evidence/Comments |
|---|---|---|---|
| 6.3.1 | Establish software maintenance processes | ☑ | Software maintenance processes are established according to IEC 62304 Section 6 and documented in GP-012 Design, redesign and development and R-TF-012-006 Lifecycle plan and report. Maintenance processes include feedback handling, problem resolution, change management, update deployment, and documentation maintenance. Maintenance procedures are documented in GP-023 Change control management and GP-021 Complaints and incident management. |
| 6.3.2 | Document maintenance activities | ☑ | Maintenance activities including change requests, problem reports, change implementations, verification results, and release notes are documented. Documentation is maintained in change control system, issue tracking system, and DHF following GP-012 Design, redesign and development. Maintenance records provide traceability of software changes and demonstrate ongoing support. |
| 6.3.3 | Perform impact analysis for software changes | ☑ | Impact analysis is performed for all software changes to assess effects on safety, performance, functionality, documentation, and regulatory compliance per GP-012 Design, redesign and development. Impact analysis considers affected components, risk implications, validation requirements per GP-029 API Verification and Validation Plan, and user notification needs. Analysis is documented in GP-023 Change control management and risk assessment updates in GP-013 Risk management (R-TF-013-002). |
| 6.3.4 | Update health software documentation | ☑ | Health software documentation (IFU, technical specifications, user guides, release notes) is updated when changes affect documentation accuracy or completeness. Documentation updates are managed through document control process in GP-019 Document and record control. Updated documentation is distributed to users and maintained in current state. Documentation version control ensures users have access to correct information for their version. |
Health software decommissioning
| Clause | Requirement | Fulfilled | Evidence/Comments |
|---|---|---|---|
| 6.4.1 | Plan for health software decommissioning | ☑ | Decommissioning plan addresses end-of-life scenarios including product discontinuation, service termination, and technology obsolescence. Plan includes user notification procedures, data preservation requirements, transition support, and documentation archival. Decommissioning considerations are documented in R-TF-012-006 Lifecycle plan and report and service agreements in GP-011 Provision of service. |
| 6.4.2 | Preserve data during decommissioning | ☑ | Data preservation procedures ensure patient data and critical information are retained or migrated during decommissioning. Procedures address data export, data archival, data format conversion, and data accessibility. As API-based service, data preservation is responsibility of healthcare organization with support from manufacturer. Data preservation guidance is provided in IFU and decommissioning documentation. Data export capabilities are implemented in API. |
| 6.4.3 | Provide instructions for data migration | ☑ | Data migration instructions document procedures for exporting data, data formats, migration tools, and recommended migration approaches. Instructions ensure users can preserve and migrate their data to alternative systems. Migration guidance addresses data integrity verification, format compatibility, and data mapping. Data migration instructions are documented in IFU, API documentation, and decommissioning support materials. |
Product Requirements
Accompanying documents
| Clause | Requirement | Fulfilled | Evidence/Comments |
|---|---|---|---|
| 7.1.1 | Provide instructions for use | ☑ | Instructions for use (IFU) are provided documenting how to install, configure, use, maintain, and troubleshoot the health software. IFU follows harmonized standard UNE-EN ISO 15223-1:2021 for medical device symbols and labeling. IFU is available electronically according to MDR requirements and documented in Legit.Health Plus Instructions for use. IFU validation is documented in R-TF-001-006 IFU and label validation. |
| 7.1.2 | Include product identification in accompanying documents | ☑ | Product identification includes product name (Legit.Health Plus), version number, manufacturer name and address, UDI, GMDN code, and EMDN code. Product identification is documented in IFU, label, and all accompanying documents. Identification follows MDR Annex VI requirements. |
| 7.1.3 | Describe intended use | ☑ | Intended use is described in IFU documenting medical purpose, clinical benefits, target patient population, intended users, and intended use environment. Intended use description is consistent with regulatory submissions. Documented in Legit.Health Plus Description and specifications and IFU. |
| 7.1.4 | Identify intended users | ☑ | Intended users (healthcare professionals including dermatologists, general practitioners, medical specialists) are identified with required qualifications, training, and experience. User profiles are documented in IFU, usability engineering file R-TF-025-001, and Description and specifications document. |
| 7.1.5 | Specify IT environment for proper function | ☑ | IT environment requirements including network connectivity, internet access, API integration requirements, security requirements, and interoperability requirements are specified. IT environment is documented in IFU technical specifications section and integration documentation. |
| 7.1.6 | Describe minimum system requirements | ☑ | Minimum system requirements including hardware specifications for image capture devices, operating system compatibility, network bandwidth, storage requirements, and browser compatibility are documented. System requirements are specified in IFU technical specifications section. |
| 7.1.7 | Provide installation and setup instructions | ☑ | Installation and setup instructions document API integration procedures, authentication setup, configuration parameters, system integration steps, and verification procedures. Installation instructions are provided in IFU installation manual section and API integration documentation. |
| 7.1.8 | Provide user training if required | ☑ | User training requirements and materials are provided to ensure users can safely and effectively use the software. Training addresses device functionality, interpretation of results, limitations, and safety considerations. Training materials and requirements are documented in IFU and may include online resources, documentation, and support materials. |
| 7.1.9 | Specify conditions for installation, use, and maintenance | ☑ | Conditions for installation, use, and maintenance including environmental conditions, operational constraints, maintenance procedures, and performance monitoring are specified. Conditions are documented in IFU including sections on installation, operation, maintenance, and troubleshooting. |
| 7.1.10 | Describe data backup and recovery procedures | ☑ | Data backup and recovery procedures document backup strategies, backup frequency, data retention, recovery procedures, and data export capabilities. As API-based service, backup responsibility is with healthcare organization. Backup guidance and data export capabilities are documented in IFU data management section. |
| 7.1.11 | Describe health software updates | ☑ | Software update procedures document update notification process, update deployment methods, update verification, rollback procedures, and version management. Update procedures ensure continuity of service and data integrity. Update process is documented in IFU and service agreements in GP-011 Provision of service. |
| 7.1.12 | Provide cybersecurity guidance | ☑ | Cybersecurity guidance documents security requirements, security best practices, access control recommendations, data protection measures, and incident response procedures. Cybersecurity guidance is provided in IFU security section and follows GP-030 Cyber Security Management. Security requirements are documented in R-TF-013-002 Risk management record. |
| 7.1.13 | Identify known residual risks | ☑ | Known residual risks from risk management are communicated to users through contraindications, precautions, and warnings in IFU. Residual risks are identified in R-TF-013-002 Risk management record and R-TF-013-003 Risk management report and communicated appropriately in user documentation. |
| 7.1.14 | Provide information on how to report problems | ☑ | Problem reporting procedures document how users can report issues, complaints, adverse events, and feedback. Contact information, reporting channels, and response expectations are provided. Reporting procedures are documented in IFU and follow GP-021 Complaints and incident management. Serious incident reporting requirements per MDR are communicated. |
Installation and deployment
| Clause | Requirement | Fulfilled | Evidence/Comments |
|---|---|---|---|
| 7.2.1 | Verify successful installation | ☑ | Installation verification procedures document steps to verify API integration, connectivity, authentication, data exchange, and functionality after installation. Verification checklist is provided in IFU installation manual. Users are guided to perform test transactions to confirm successful installation and integration. |
| 7.2.2 | Provide mechanism to verify integrity of health software | ☑ | Software integrity verification mechanisms include API version verification, authentication mechanisms, HTTPS/TLS encryption for data transmission, and API health check endpoints. Integrity verification ensures software has not been tampered with and is authentic. Verification mechanisms are documented in IFU and API documentation. Digital signatures and secure authentication protect API access. |
Updates and patches
| Clause | Requirement | Fulfilled | Evidence/Comments |
|---|---|---|---|
| 7.3.1 | Provide means to deliver updates and patches | ☑ | Software updates and patches are delivered through API versioning and deployment processes. Update delivery mechanism ensures backward compatibility where possible and managed transitions for breaking changes. Update process is documented in GP-011 Provision of service and communicated to users through service notifications and API documentation. Version management ensures controlled deployment. |
| 7.3.2 | Inform users about availability of updates | ☑ | Users are informed about software updates through release notifications, service announcements, API documentation updates, and version deprecation notices. Notification process ensures users are aware of new features, bug fixes, security updates, and important changes. Notification procedures are documented in GP-011 Provision of service and service level agreements. |
| 7.3.3 | Describe the purpose and content of updates | ☑ | Update descriptions document purpose, content, changes, bug fixes, new features, security improvements, and known issues. Release notes provide detailed information about each update including change impact, migration requirements, and testing recommendations. Release notes are published with each update and archived for reference. Release documentation follows change control procedures in GP-023 Change control management. |
Problem Resolution
| Clause | Requirement | Fulfilled | Evidence/Comments |
|---|---|---|---|
| 8.1 | Establish process for receiving user feedback | ☑ | Process for receiving user feedback is established and documented in GP-007 Post-market surveillance and GP-021 Complaints and incident management. Feedback channels include customer support, complaint forms, user surveys, and service desk. Feedback is collected, documented, and evaluated systematically. Feedback process ensures all user input is captured and analyzed. |
| 8.2 | Establish process for problem resolution | ☑ | Problem resolution process is established according to IEC 62304 Section 9 and documented in GP-023 Change control management. Process includes problem reporting, investigation, root cause analysis, corrective action, verification, and closure. Problem tracking system maintains records of all problems and resolutions. Problem resolution follows defined workflows and escalation procedures. |
| 8.3 | Provide information about known problems | ☑ | Known problems and limitations are documented in IFU, release notes, known issues documentation, and support knowledge base. Information includes problem description, workarounds, resolution status, and planned fixes. Known problems are communicated proactively to users. Known issues are updated as problems are resolved. Critical issues are communicated immediately through safety notifications. |
| 8.4 | Provide timely information about critical safety issues | ☑ | Critical safety issues are communicated immediately to users through field safety notices, urgent safety communications, and direct notifications. Communication process follows regulatory requirements for vigilance and post-market surveillance. Safety communication procedures are documented in GP-021 Complaints and incident management and GP-007 Post-market surveillance. Timely communication ensures user safety and regulatory compliance. |
Summary
| Section | Total Items | Fulfilled | Percentage |
|---|---|---|---|
| 4. General Requirements | 2 | 2 | 100% |
| 5. Safety and Security | 8 | 8 | 100% |
| 6. Lifecycle Requirements | 14 | 14 | 100% |
| 7. Product Requirements | 20 | 20 | 100% |
| 8. Problem Resolution | 4 | 4 | 100% |
| Total | 48 | 48 | 100% |
Summary Notes
This checklist covers all 48 requirements from EN IEC 82304-1:2016 Health software - Part 1: General requirements for product safety. All requirements are applicable to health software products.
To calculate compliance percentage:
- Mark each fulfilled requirement with ✓ in the "Fulfilled" column
- Count total fulfilled items and divide by 48
- Percentage = (Fulfilled Items / 48) × 100%
The checklist should be completed during product development and reviewed before each release to ensure continued compliance with the standard.
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