R-TF-029-002 — Functional and Interface Commissioning Record

Document Control

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

Release and Identification

Regulatory objective: Establish traceability between functional commissioning results and the commissioned software baseline.

Item	Value
Device name	Legit.Health Plus
Software version	1.1.0.0
Internal release identifier	1.1.0.0
Commissioning execution date
Production base URL	https://medical-device.legit.health
API version(s) commissioned	v1.0 (API scheme vA.B)

Commissioning Controls

Test Data Controls

Regulatory objective

Ensure that commissioning activities do not involve identifiable patient data.

Data Anonymization

All image inputs were verified to be free of patient-identifiable metadata (EXIF) prior to execution.

• Synthetic Payloads: Request payloads were manually or procedurally generated using synthetic identifiers (e.g., "TEST-ID") to ensure no real patient names or histories were processed.
• PII Confirmation: No patient-identifiable information (PII) was processed or stored in the production environment during commissioning

Credentials and Access Controls

Regulatory objective: Ensure commissioning access is controlled, traceable, and appropriate to scope.

Account identifier	Role / context	Scope / permissions
admin@legit.health	Internal commissioning account	Full access to clinical API functionality required for commissioning

API Availability and Routing

Regulatory objective: Confirm that the production API is reachable, correctly routed, and exposes the intended interfaces.

Commissioned endpoints:

• Authentication routes: /auth/login
• Clinical routes: /clinical/diagnosis-support, /clinical/severity-assessment
• Device routes: /device/about, /device/health
• Documentation routes (protected): /openapi.json, /docs

Verification result:

• All defined API endpoints were reachable and responded as expected.
• HTTPS was enforced for all API access.
• Endpoint behavior was consistent with the approved API specification.

Authentication and Authorization Enforcement

Regulatory objective: Confirm enforcement of access control mechanisms.

• /auth/login successfully issued JWT access tokens when valid credentials were provided.
• Access to protected endpoints without a token was denied as expected.
• Access using invalid or expired tokens was denied as expected.
• Access using a valid JWT token was granted as expected.

Input Validation and Error Handling

Regulatory objective: Confirm predictable and safe handling of malformed or invalid inputs in the commissioned production environment.

• Requests with missing required fields resulted in controlled client error responses (4xx), as observed during commissioning execution.
• Requests with unsupported content types were rejected with appropriate client error responses (4xx), as observed during commissioning execution.
• Requests containing invalid or corrupted image payloads were rejected without server-side failures, unhandled exceptions, or service crashes during commissioning execution.

Link to verification evidence:

• The behaviors observed during commissioning are consistent with the outcomes defined in the approved automated verification test suite.
• Detailed test cases and expected behaviors are maintained in the software verification documentation set and were reviewed as part of commissioning acceptance.

Internal Integration Sanity Checks

Regulatory objective: Confirm end-to-end functional integration of internal services.

• A commissioning request was submitted to the production API and resulted in a structured clinical response.
• The response demonstrated aggregation of expert-derived results and report generation.
• Logs confirmed successful invocation of the Control Plane, Expert services, and Report Builder for the commissioning request.

This confirms successful traversal of:

• API → Control Plane
• Control Plane → Expert services
• Expert services → Report Builder
• Report Builder → API response

Audit Logging Verification

Regulatory objective: Confirm generation of audit records for traceability.

• Audit records were created for successful clinical requests.
• Audit records were created for rejected requests due to authentication failures.

Failure Mode Sanity Checks

Regulatory objective: Confirm predictable system behavior under common operational failure conditions within the defined scope of functional commissioning.

• Downstream timeout or dependency delay scenarios were not exercised during this commissioning phase, as they fall outside the scope of functional and interface commissioning and are addressed through dedicated verification, monitoring, and risk control activities.
• Partial expert failure scenarios were not exercised during this commissioning phase; controlled behavior for such conditions is implemented through predefined error handling and operational monitoring mechanisms verified elsewhere in the lifecycle.

Evidence Register

Regulatory objective: Identify controlled locations where commissioning evidence can be retrieved.

Evidence type	Location / system of record	Notes
Functional verification artifacts	S3 bucket: s3://legit-health-plus/software-tests/v1.1.0.0/production/commissioning/testrail/	Contains EXIF/Payload checks (EV-DAT), Routing/Auth verification (EV-ROUTE, EV-AUTH), and Input Validation results (EV-VAL).
Internal integration and sanity checks	S3 bucket; Local Docker logs	Verification of end-to-end traversal (EV-INT), service stability, and safety scope attestation (EV-FAIL).
Audit trail and record persistence	DynamoDB table legit_health_plus_api_gateway_calls	Immutable records of successful clinical and security-relevant requests (EV-AUDIT).
Commissioning records and acceptance	Controlled QMS document repository	Includes the finalized R-TF-029-002 record (EV-ACC-02) and the functional deviations review (EV-DEV-02).

Functional Deviations Review

Regulatory objective: Ensure transparency of commissioning execution.

• No deviations were observed during the functional and integration commissioning of Legit.Health Plus.

Functional Commissioning Acceptance

Regulatory objective: Formally confirm functional readiness for operational use.

Acceptance statement:

The functional baseline of the software instance has been commissioned and confirmed to maintain active integration, enforce required security controls, and handle internal service failures gracefully in the production environment.

Record Status

This commissioning record establishes the functional and integration baseline for the specified software version in accordance with ISO 62304 and ISO 82304-1.

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

Appendix A: Functional and Interface Commissioning Test Log

Regulatory objective: Provide detailed traceability of all commissioning test cases executed for functional and interface validation.

The following table summarizes all test cases executed during the functional and interface commissioning phase:

Loading test data...

Legend:

• Title: Name and identifier of the test case
• URL: Link to the test case in the TestRail system
• Expected Results: Summary of expected outcomes for the test case
• Evidence URI: Location of the commissioning evidence artifacts in the S3 repository