R-TF-029-002 — Functional & 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	1.1.0.0

Commissioning Controls

Test Data Controls

Regulatory objective: Ensure that commissioning activities do not involve identifiable patient data.

• Commissioning tests were executed using anonymized images from publicly available datasets and synthetic payloads generated specifically for testing purposes.
• All test data sources are explicitly licensed for research and testing use.
• No patient-identifiable information was processed during commissioning.

Credentials and Access Controls

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

Account identifier	Role / context	Scope / permissions
gerardo+medicaldevicetest@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
• Internal monitoring routes: /internal/status
• 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
API request IDs and logs	DynamoDB table legit_health_plus_api_gateway_calls	Request IDs are timestamped and immutable
Health / monitoring snapshot	Pending — CloudWatch metrics, /device/health output, and service health status	To be captured at execution time
Audit record identifiers	DynamoDB audit logging tables	Records persisted asynchronously
Commissioning artifacts	Controlled QMS document repository	Includes completed commissioning records

Deviations

Regulatory objective: Ensure transparency of commissioning execution.

• No deviations were observed during functional and interface commissioning.

Functional Commissioning Acceptance

Regulatory objective: Formally confirm completion of functional and interface commissioning.

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.

Record Status

This commissioning record supports release readiness and establishes functional commissioning evidence 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