Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
    • GP-001 Control of documents
    • GP-002 Quality planning
    • GP-003 Audits
    • GP-004 Vigilance system
    • GP-005 Human Resources and Training
    • GP-006 Non-conformity, Corrective and Preventive actions
    • GP-007 Post-market surveillance
    • GP-008 Product requirements
    • GP-009 Sales
    • GP-010 Purchases and suppliers evaluation
    • GP-011 Provision of service
    • GP-012 Design, redesign and development
    • GP-013 Risk management
    • GP-014 Feedback and complaints
    • GP-015 Clinical evaluation
    • GP-016 Traceability and identification
    • GP-017 Technical assistance service
    • GP-018 Infrastructure and facilities
    • GP-019 Software validation plan
    • GP-020 QMS Data analysis
    • GP-021 Communications
    • GP-022 Document translation
    • GP-023 Change control management
    • GP-024 Predetermined Change Control Plan
    • GP-025 Usability and Human Factors Engineering
    • GP-027 Corporate Governance
    • GP-028 AI Development
    • GP-029 Software Delivery and Commissioning
      • Templates
        • T-029-001 — Deployment & Configuration Commissioning Template
        • T-029-002 — Functional & Interface Commissioning Template
        • T-029-003 — Clinical Workflow & Operational Readiness Commissioning Template
    • GP-030 Cyber Security Management
    • GP-050 Data Protection
    • GP-051 Security violations
    • GP-052 Data Privacy Impact Assessment (DPIA)
    • GP-100 Business Continuity (BCP) and Disaster Recovery plans (DRP)
    • GP-101 Information security
    • GP-200 Remote Data Acquisition in Clinical Investigations
    • GP-026 Market-specific product requirements
    • GP-110 Esquema Nacional de Seguridad
  • Records
  • Legit.Health Plus Version 1.1.0.0
  • Legit.Health Plus Version 1.1.0.1
  • Licenses and accreditations
  • Applicable Standards and Regulations
  • Grants
  • Pricing
  • Public tenders
  • Procedures
  • GP-029 Software Delivery and Commissioning
  • Templates
  • T-029-002 — Functional & Interface Commissioning Template

T-029-002 — Functional & Interface Commissioning Template

1. Document Control​

  • Document ID: T-029-002
  • Title: Functional & Interface Commissioning
  • Device: Legit.Health Plus
  • Document Type: Commissioning Template
  • Lifecycle Phase: Release / Commissioning
  • Standard(s): ISO 62304, ISO 82304-1

Regulatory purpose: This document defines the controlled commissioning activities required to confirm that the deployed software instance exposes the intended API interfaces correctly, enforces required access controls, and integrates correctly with internal services and external interfaces necessary for intended use.

2. Scope​

This template applies to the commissioning of the production-deployed Legit.Health Plus API-based SaMD, including:

  • API availability, routing, and versioning
  • Authentication and authorization enforcement
  • End-to-end request/response behavior at the API boundary
  • Internal service-to-service connectivity required to produce outputs
  • Audit logging behavior required for traceability

This template does not cover:

  • Algorithm performance validation (clinical performance)
  • Model quality metrics (e.g., sensitivity/specificity)
  • Load/performance qualification beyond commissioning sanity checks
  • Security penetration testing (handled in dedicated security activities)

3. Normative Basis​

This commissioning activity is required to satisfy the following normative intents:

  • ISO 62304 §5.7: Verification of integrated software system behavior in the target environment
  • ISO 62304 §5.8: Release readiness confirmation includes correct operation of integrated system
  • ISO 82304-1 §5.6: Interface and dependency behavior verified in the context of use
  • ISO 82304-1 §7.2: Confirm correct operation of the health software product in its operational environment

4. Inputs and Preconditions​

The following shall be available prior to execution:

  • Completed R-TF-029-001 for the same release (deployment & configuration commissioning)
  • Approved release identifier and deployed API base URL(s)
  • Access to production monitoring/logging relevant to commissioning evidence
  • Commissioning test credentials (non-patient) with least privilege
  • Representative commissioning test images (non-identifiable or synthetic) and metadata payloads

5. Device and Release Identification​

Objective: Ensure traceability between commissioning results and the released/deployed baseline.

ItemValue
Device name
Software version
Internal release identifier
Commissioning execution date
Production base URL
API version(s) commissioned

6. Commissioning Test Controls​

6.1 Data Controls​

Objective: Ensure commissioning does not process identifiable patient data.

  • Test images and payloads shall be non-identifiable and authorized for commissioning use.
Data set / artifactDescriptionSourceApproved for commissioning (Y/N)

6.2 Credentials and Access Controls​

Objective: Ensure commissioning accounts are controlled and traceable.

Credential / principalIntended scopeControl mechanism (e.g., IAM/JWT)Notes

7. API Availability and Routing​

Objective: Confirm the API is reachable over HTTPS, routes requests correctly, and exposes correct device information.

Check IDEndpoint / InterfaceMethodExpected resultActual resultPass/FailEvidence reference
A1/device/healthGET200 OK, reports healthy
A2/device/aboutGETReturns device + version metadata consistent with release
A3Base URL + TLSN/ATLS enforced, no plain HTTP

8. Authentication and Authorization Enforcement​

Objective: Confirm that protected clinical endpoints require valid authorization and reject invalid/expired credentials.

Check IDEndpoint / InterfaceMethodScenarioExpected resultActual resultPass/FailEvidence reference
AUTH1/auth/loginPOSTValid commissioning credentialsJWT issued
AUTH2/clinical/*POSTNo token401/403 as specified
AUTH3/clinical/*POSTInvalid/expired token401/403 as specified
AUTH4/clinical/*POSTValid tokenRequest accepted

9. Input Validation and Error Handling​

Objective: Confirm that malformed inputs are handled predictably, safely, and traceably.

Check IDInterfaceScenarioExpected resultActual resultPass/FailEvidence reference
VAL1/clinical/*Missing required fields4xx with clear error structure
VAL2/clinical/*Unsupported content type4xx returned
VAL3/clinical/*Corrupted/invalid image payload4xx returned; no server error

10. Internal Service Integration Sanity Checks​

Objective: Confirm that API requests traverse required internal dependencies to produce outputs.

Check IDWorkflow / DependencyScenarioExpected resultActual resultPass/FailEvidence reference
INT1API → Control PlaneStandard requestRouted successfully; no orchestration errors
INT2Control Plane → Expert servicesStandard requestRequired expert calls succeed
INT3Expert results → Report BuilderStandard requestReport builder produces canonical report
INT4Report → API responseStandard requestResponse conforms to expected schema

Note: Detailed clinical workflow commissioning is performed in T-029-003. The checks above confirm integration readiness only.

11. Audit Logging Verification​

Objective: Confirm that API interactions produce audit records consistent with device traceability requirements.

Check IDScenarioExpected resultActual resultPass/FailEvidence reference
AUD1Successful clinical requestAudit entry created
AUD2Rejected request (auth failure)Audit entry created (as specified)

12. Failure Mode Sanity Checks​

Objective: Confirm safe behavior for common operational failures without requiring full resilience qualification.

Check IDFailure stimulusExpected system behaviorActual resultPass/FailEvidence reference
FM1Downstream timeout / dependency delayPredictable error response; no undefined behavior
FM2Partial expert failure (if testable)Controlled degradation or error per requirements

13. Evidence Register​

Objective: Identify where commissioning evidence is stored in a controlled manner.

Evidence itemTypeLocation / referenceNotes
API call logs / request IDsLog
Monitoring snapshot (health)Snapshot
Audit log proof (record IDs)Log / DB reference
Commissioning test artifactsFile

14. Deviations​

Objective: Record any observed deviations, assess impact, and document resolution.

Deviation IDDescriptionImpact assessmentResolution / corrective actionStatus (Open/Resolved)Evidence reference

☐ No deviations encountered

15. Functional Commissioning Acceptance​

Objective: Formally confirm that functional and interface commissioning requirements have been met.

Acceptance statement:

The deployed software instance has been commissioned and confirmed to expose the intended API interfaces, enforce required access controls, and integrate correctly with internal services necessary to support intended operation in the production environment.

RoleNameDateSignature
Responsible engineer
Quality / Regulatory

16. Output​

The completed commissioning record generated from this template shall be stored as R-TF-029-002 and maintained as part of the release evidence set for the commissioned software version.

Previous
T-029-001 — Deployment & Configuration Commissioning Template
Next
T-029-003 — Clinical Workflow & Operational Readiness Commissioning Template
  • 1. Document Control
  • 2. Scope
  • 3. Normative Basis
  • 4. Inputs and Preconditions
  • 5. Device and Release Identification
  • 6. Commissioning Test Controls
    • 6.1 Data Controls
    • 6.2 Credentials and Access Controls
  • 7. API Availability and Routing
  • 8. Authentication and Authorization Enforcement
  • 9. Input Validation and Error Handling
  • 10. Internal Service Integration Sanity Checks
  • 11. Audit Logging Verification
  • 12. Failure Mode Sanity Checks
  • 13. Evidence Register
  • 14. Deviations
  • 15. Functional Commissioning Acceptance
  • 16. Output
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI Labs Group S.L.)