\ – Software Validation Form
1. Software Information
| Field | Details |
|---|---|
| ID | \<ID> |
| Name | \<Name> |
| Version | \<x.x.x> |
| Location | \<url> |
| Processes | \ |
2. Intended Use and Context
Provide a description of the software’s intended purpose and how it is used (e.g., automation, testing, control, or data modification). Include technical specifications and usage requirements the system must fulfill.
3. Quality Relevance
Evaluate the following criteria with “Yes” (Y) or “No” (N). If any criteria are marked “Yes,” the system is deemed quality-relevant and requires validation.
| Criteria | Y/N |
|---|---|
| Is the software involved in processes critical to steering the QMS? | |
| Could device conformity be affected if the software fails to perform as specified? | |
| Could software failure result in risks to patients, users, third parties, or the organization? | |
| Does the software create or manage data/records relevant to the QMS or medical device regulatory compliance? | |
| Is the software used to generate electronic signatures required for QMS or regulatory purposes? |
4. Overall Assessment
4.1 Software Classification
- GAMP Category 1: Infrastructure software (e.g., OS, databases, network management tools)
- GAMP Category 3: Non-configurable software
- GAMP Category 4: Configurable software
- GAMP Category 5: Custom-developed software
4.2 Risk Analysis
Identified Risks:
* \
Risk Mitigation Measures:
* \
4.3 Criticality and Review Schedule
- Low: Review upon significant changes
- Moderate: Annual review
- High: Review every six months
Refer to Section 10 for additional details on criticality classifications. Continuous validation during use may apply to widely used, non-critical software.
5. Validation Plan
5.1 Participants
| Role | Name | Responsibilities |
|---|---|---|
5.2 Test Environment
- System accessed via \
. - Reference: User manual provided.
5.3 Test Procedure
- Execute the software on a representative set of sample data.
6. Validation Results
6.1 Acceptance Criteria
The software is approved for use if it meets all predefined validation criteria and performs as expected.
6.2 Validation of Usage Requirements
| ID | Expected Outcome | Actual Outcome | Pass? |
|---|---|---|---|
| U1 | e.g., “A radiologist can log in using email and password.” | “Login with valid credentials grants access to tools.” | Yes |
6.3 Validation of Technical Requirements
| ID | Expected Outcome | Actual Outcome | Pass? |
|---|---|---|---|
| T1 | e.g., “Executes correctly in the required runtime.” | “Application runs properly in Google Chrome.” | Yes |
6.4 Summary of Validation Results
| Type | Total | Pass | Fail |
|---|---|---|---|
| Usage Requirements | 1 | 1 | 0 |
| Technical Requirements | 1 | 1 | 0 |
6.5 Final Conclusion
The software is recommended for approval as all acceptance criteria have been met.
7. Validation Evidence
Optionally include screenshots as evidence of validation success. While not mandatory, these can be useful for audits.
| Requirement ID | Screenshot |
|---|---|
| U1 | \ |
| T1 | \ |
8. Approval and Release
| Approval Date | Approver Name |
|---|---|
| \<date> | \<name> |
9. Version History
| Date | Name | Activity |
|---|---|---|
| \ |
10. Annex: Criticality Classification Details
GAMP Implications
- GAMP 5: High criticality
- GAMP 4: High or moderate criticality depending on risk analysis in Section 4.2
- GAMP 1 & 3: Typically low or moderate criticality based on Section 4.2 risk analysis
Criticality Levels
- High: Failure may cause harm requiring medical intervention or affect quality-critical records.
- Moderate: Failure may cause harm not requiring intervention or affect audit-relevant information.
- Low: Failure affects records relevant to audits without patient or device impact.