GP-029 Software Delivery and Commissioning

Procedure flowchart

Purpose

This procedure establishes the process for API delivery, deployment, commissioning, and validation of AI Labs's medical device API in its intended environment of use. The purpose is to ensure that:

• The API meets user requirements when integrated into client applications
• API deployment to production infrastructure is controlled and traceable
• The API operates correctly when accessed by authorized clients in real-world conditions
• Complete integration documentation and Instructions for Use are delivered to clients
• Post-deployment monitoring and client support are established
• Clients have the necessary resources and guidance to integrate the API into their end-user applications

Note: AI Labs develops and maintains a medical device API. The integration of this API into end-user applications (mobile apps, web applications, EHR systems, telemedicine platforms, etc.) is performed by clients. This procedure covers both AI Labs's deployment of the API to production infrastructure and the validation of the API when integrated into representative client environments.

This procedure is based on section 6.2 "Software product validation" of IEC 82304-1:2016, which requires manufacturers to demonstrate that the software product satisfies user requirements in the intended environment of use.

Two-Objective Approach

This procedure addresses two critical aspects of API commissioning and validation:

Objective 1: AI Labs's Internal Validation in Representative Environments

Objective: Demonstrate through internal testing that the API can be successfully integrated by clients.

AI Labs performs comprehensive validation testing by creating representative test environments that simulate how clients will integrate the API. This includes:

• Building test applications (mobile, web) that integrate the API
• Simulating different integration scenarios (EHR systems, telemedicine platforms)
• Testing with various authentication methods and network conditions
• Validating that the API behaves correctly when consumed by different client types
• Verifying that integration documentation is complete and accurate

Purpose: This validation provides objective evidence that the API is ready for client integration and that the integration process is feasible and well-documented.

Section in this procedure: Covered primarily in Section 3 - Product Validation in Intended Environment

Objective 2: Client Integration Assurance Process

Objective: Ensure that when clients integrate the API, they do so correctly and safely.

AI Labs establishes a comprehensive support framework to guide and verify client integrations:

• Providing complete integration documentation, guides, and code examples
• Offering a sandbox environment for client testing before production use
• Establishing support channels to assist clients during integration
• Defining best practices and integration requirements
• Monitoring early client integrations to identify issues
• Collecting feedback to continuously improve documentation and support

Purpose: This framework ensures that clients have the necessary resources and support to integrate the API correctly, safely, and in compliance with its intended use.

Section in this procedure: Covered in Section 1.3 (Client-facing documentation), Section 3.3 (Client Integration Documentation Validation), Section 4.2 (Client Documentation and Resources Delivery), and Section 5 (Post-Deployment Activities)

Together, these two objectives ensure that the API is both technically capable of being integrated correctly (Objective 1) and that clients are equipped and supported to perform correct integrations (Objective 2).

Integration with Development Lifecycle

This procedure (GP-029) is executed as part of Phase 5 (Product Validation) of the software development lifecycle described in GP-012 Design, Redesign and Development. The following diagram illustrates how GP-029 integrates into the overall development process:

Process Flow:

1. Phase 1-4 of GP-012:
   • Phase 1: Product Design
   • Phase 2: Software Design
   • Phase 3: Product Development
   • Phase 4: Software Verification
2. Phase 5 Start: Product validation phase begins
3. Clinical Evaluation (GP-015): Clinical validation of the medical device is performed
4. GP-029 Execution: After clinical validation, this procedure (GP-029) is executed to:
   • Deploy the software to the intended environment(s) of use
   • Validate that the software meets user requirements in real-world conditions
   • Commission the software for operational use
5. Return to Phase 5: With validation evidence from GP-029, return to GP-012 Phase 5 to:
   • Complete the Phase 5 validation checklist
   • Document all validation activities
   • Approve the validation phase completion
6. Market Release: Upon successful completion of Phase 5 (Product Validation), the product can be released to market

This procedure ensures that the final validation step—demonstrating the software works correctly in its intended environment—is completed before the product is considered validated and ready for market release.

Scope

This procedure applies to AI Labs's medical device API and covers:

• AI Labs's activities: Deployment of the API to production infrastructure, validation of API functionality in representative environments, and preparation of integration resources for clients
• Client activities: Integration of the API into end-user applications, which is performed by clients following AI Labs's integration documentation and Instructions for Use
• Validation: Demonstration that the API satisfies user requirements when integrated into representative client applications and environments

This procedure covers:

• API deployment to AI Labs's production infrastructure
• Validation of API endpoints, authentication, performance, and functionality
• Validation of API integration in representative client environments (simulating real integrations with mobile apps, web applications, EHR systems, etc.)
• Preparation and delivery of integration documentation, API documentation, and Instructions for Use
• Establishment of client support and monitoring procedures
• Updates and new versions of the API

Out of scope: This procedure does not cover the deployment or commissioning of client applications that integrate the API. Clients are responsible for deploying and maintaining their own applications according to their internal procedures.

References

Reference document code	Reference document description
ISO 13485:2016	Medical devices - Quality management systems - Requirements for regulatory purposes
EN ISO 13485/A11:2021	European standard for medical devices quality management systems
IEC 82304-1:2016	Health software - Part 1: General requirements for product safety
IEC 62304:2006+A1:2015	Medical device software - Software life cycle processes
ISO 14971:2019	Medical devices - Application of risk management
21 CFR 820.70	FDA regulation for production and process controls
Regulation (EU) 2017/745	Regulation of the European Parliament and Council on medical devices

Definitions

• Commissioning: The process of ensuring that all systems and components of a software product are designed, installed, tested, operated, and maintained according to operational requirements.
• Deployment: The process of releasing software to a production or customer environment.
• Environment of use: The combination of conditions under which the software product is intended to be used, including technical infrastructure, network conditions, and operational context.
• Integration testing: Testing performed to verify that different components or systems work correctly together.
• Product validation: Confirmation through provision of objective evidence that requirements for a specific intended use are fulfilled.
• Representative environment: A pre-production or staging environment that simulates the intended production environment with sufficient fidelity to demonstrate that the software will function as expected in real-world conditions.
• Software release package: A collection of software components, configuration files, documentation, and installation instructions that constitute a deployable version of the software product.

Responsibilities

JD-001

• Approve the commissioning and deployment process
• Approve handover to operations
• Ensure compliance with regulatory requirements

JD-003

• Oversee the validation and commissioning activities
• Ensure product meets user requirements in intended environment
• Approve commissioning documentation

JD-007

• Execute API deployment to production infrastructure
• Perform technical validation and testing of the API
• Document deployment and commissioning activities
• Coordinate with infrastructure and operations teams
• Prepare integration documentation and client resources
• Provide technical support to clients during integration

JD-004

• Ensure proper documentation is generated and archived
• Verify traceability of commissioning activities
• Maintain Device History File records

Detailed Process

1. Pre-Deployment Preparation

Before deploying the API to production infrastructure, the following prerequisites must be satisfied:

1.1 API Release Package

The API release package must be complete and include:

• Compiled and tested API artifacts
• API configuration templates
• Database migration scripts (if applicable)
• Internal deployment instructions for AI Labs infrastructure
• Release notes
• API documentation (OpenAPI/Swagger specification)
• Integration guide for clients
• Instructions for Use (IFU) for the API
• Known issues and limitations documentation
• Client SDK/libraries (if applicable)
• Code examples and integration samples

1.2 Production Environment Preparation

AI Labs's production infrastructure must be prepared according to the following requirements:

API Infrastructure:

• Network infrastructure configured (firewalls, load balancers, DNS, CDN)
• Public API endpoints configured and accessible
• Authentication and authorization mechanisms deployed (API keys, OAuth, JWT, etc.)
• Database and data storage systems provisioned
• Monitoring and logging infrastructure established
• Backup and disaster recovery systems configured
• Security certificates and credentials installed (TLS/SSL)
• Rate limiting and throttling configured
• API gateway configured (if applicable)

Client Integration Support:

• Test/sandbox environment available for client integration testing
• Test credentials and sample data prepared
• API documentation portal accessible
• Support ticketing system operational

1.3 Deployment Documentation

The following documentation must be prepared:

Internal documentation (AI Labs):

• Software Commissioning Plan (T-029-001) - comprehensive plan including:
  • API deployment plan for production infrastructure
  • Rollback plan
  • Objective 1: Internal validation approach and test scenarios
  • Objective 2: Client integration assurance process
  • Annex A: Objective 1 Validation Checklist (detailed test cases)
  • Annex B: Client Integration Checklist
  • Acceptance criteria and success metrics

Client-facing documentation:

• API Integration Guide (step-by-step integration instructions)
• API Reference Documentation (endpoints, parameters, responses)
• Authentication and Authorization Guide
• Error handling documentation
• Integration best practices
• Code examples and sample implementations
• Instructions for Use (IFU)
• Support procedures and contact information

2. API Deployment to Production Infrastructure

2.1 Controlled API Deployment

API deployment to AI Labs's production infrastructure must be performed according to the deployment plan, following these principles:

• Use version control and release management tools
• Maintain traceability of deployed API artifacts and versions
• Follow change management procedures (GP-023)
• Implement deployment in phases when appropriate (e.g., canary deployments, blue-green deployments, rolling updates)
• Maintain API versioning strategy (ensure backward compatibility when possible)
• Document all deployment actions
• Notify clients of upcoming changes (for breaking changes)

2.2 API Installation Verification

After deployment to production infrastructure, verify that:

• All API components are deployed correctly
• API configuration matches requirements
• Database schemas are updated correctly
• API endpoints are accessible via public URLs
• Service dependencies are resolved
• Health check endpoints respond correctly
• API gateway routing is configured correctly (if applicable)
• Load balancing is functioning correctly
• SSL/TLS certificates are valid and correctly configured
• DNS records point to correct endpoints

3. Product Validation in Intended Environment (Objective 1)

This section implements the requirements of IEC 82304-1:2016, section 6.2. The manufacturer must demonstrate that the software product satisfies user requirements in the intended environment of use.

Purpose of this validation: AI Labs conducts internal validation testing in representative environments to demonstrate that the API can be successfully integrated by clients. This validation provides objective evidence that:

• The API functions correctly when consumed by different types of client applications
• The integration process is technically feasible
• The integration documentation is complete and accurate
• Common integration scenarios work as expected

Who performs this validation: AI Labs's technical team performs this validation by creating test applications and integration scenarios that simulate how clients will use the API.

3.1 Representative Environment Validation

The validation must be performed in environments that are representative of how the API will be used in real-world conditions. This includes:

AI Labs's Production Environment:

• The API deployed to production infrastructure with actual network conditions
• Production-level security configurations
• Real authentication and authorization mechanisms
• Production monitoring and logging systems

AI Labs's Representative Client Integration Test Environments:

AI Labs creates and maintains test environments that simulate how clients will integrate the API:

• Mobile application integrations: AI Labs develops test mobile applications (iOS, Android) that integrate the API, simulating how client mobile apps will consume the API
• Web application integrations: AI Labs develops test web applications that integrate the API, simulating how client web apps will consume the API
• EHR system integrations: AI Labs creates test environments that simulate API calls from EHR systems, including HL7/FHIR data exchange scenarios
• Telemedicine platform integrations: AI Labs creates test scenarios simulating API calls from telemedicine applications
• Expected technical configurations: Test with various authentication methods (API keys, OAuth, JWT), network conditions (latency, bandwidth limitations), and error scenarios
• Key functional conditions: Simulate realistic traffic volumes, concurrent API calls, response times under various load conditions
• Business and clinical rules: Validate that API responses correctly implement clinical algorithms and business rules under various input scenarios

Documentation of Validation Environments:

All validation environments must be documented, including:

• AI Labs's production infrastructure specifications
• Specifications of each representative client integration test environment created
• Network topology and conditions tested
• Security configurations and authentication methods tested
• Integration scenarios tested (with test cases)
• Test data sets used
• Results of validation testing in each environment

3.2 Internal Validation Testing Activities

AI Labs performs the following validation activities in the representative environments:

3.2.1 Endpoint Availability Testing

• Verify endpoints are publicly accessible (or accessible on expected network)
• Test DNS resolution from different locations
• Verify load balancing distributes requests appropriately
• Test health check endpoints respond correctly
• Validate API versioning and routing

3.2.2 Authentication and Authorization Testing

• Test that HTTP(S) calls can be made using different authentication methods
• Validate authentication mechanisms (API keys, OAuth, JWT, etc.) work correctly from test client applications
• Verify authorization rules are enforced correctly (role-based access control)
• Test rate limiting is applied as specified
• Validate token expiration and refresh mechanisms work correctly
• Test behavior with invalid or expired credentials

3.2.3 Integration Scenario Testing (Core of Objective 1)

AI Labs creates and tests complete integration scenarios to prove the API can be integrated successfully:

Mobile App Integration Testing:

• Develop test mobile applications (iOS and/or Android) that integrate the API
• Test all API endpoints from mobile applications
• Verify data exchange formats work correctly with mobile platforms
• Test with various mobile network conditions (WiFi, 4G, 5G, poor connectivity)
• Validate offline/online transitions (if applicable)
• Test authentication flows from mobile applications
• Document the integration process and identify any challenges

Web App Integration Testing:

• Develop test web applications that integrate the API
• Test all API endpoints from web applications
• Verify API works correctly with different browsers
• Test CORS configurations if applicable
• Validate authentication flows from web applications
• Test with various network conditions
• Document the integration process

EHR Integration Testing:

• Simulate or implement test integrations with EHR data formats (HL7, FHIR)
• Validate data exchange between API and EHR-like systems
• Test clinical data workflows
• Verify data mapping and transformation logic
• Document integration requirements and process

Telemedicine Platform Integration Testing:

• Simulate telemedicine application workflows
• Test real-time and asynchronous API usage patterns
• Validate clinical decision support integration
• Test with realistic clinical scenarios
• Document integration approach

SDK/Library Testing (if applicable):

• If client SDKs are provided, test them in representative environments
• Validate SDK functionality across different platforms/languages
• Verify SDK documentation accuracy

Integration Documentation Validation:

• Follow the integration documentation step-by-step as if AI Labs were a client
• Verify that integration guide enables successful integration
• Test all code examples provided in documentation
• Identify any gaps or unclear instructions in documentation
• Update documentation based on testing experience

3.2.4 Error Handling and Logging Validation

• Verify error responses follow documented specifications in all integration scenarios
• Test that error messages are appropriate and do not expose sensitive information
• Validate that client applications can properly handle all API error scenarios
• Verify logging captures sufficient information for troubleshooting
• Test that log levels are configured correctly
• Verify monitoring systems receive and display metrics correctly
• Test alerting mechanisms function as designed

3.2.5 Performance Requirements Validation

• Test response latency meets specifications under normal load
• Verify system maintains availability targets
• Validate throughput meets specified requirements
• Test system performance under peak load conditions (load testing)
• Verify resource utilization is within acceptable limits
• Test graceful degradation under stress conditions
• Measure performance from representative client applications

3.2.6 End-to-End Clinical Workflow Testing

• Execute complete clinical workflows through the API
• Validate clinical algorithms produce correct results
• Test with realistic clinical scenarios and edge cases
• Verify clinical decision support accuracy
• Document clinical validation results

3.3 Documentation and Deliverables from Pillar 1 Validation

3.3 Documentation and Deliverables from Objective 1 Validation

The validation testing in representative environments must produce:

Software Commissioning Report (T-029-002) documenting:

• Description of all representative test environments created
• Test applications developed and their specifications
• Test cases executed in each environment (from T-029-001 Annex A)
• Results of all validation activities
• Evidence of successful integrations (screenshots, logs, test results)
• Any issues identified and their resolutions
• Confirmation that integration documentation is accurate and complete
• Conclusion that the API can be successfully integrated by clients
• Objective evidence of IEC 82304-1:2016 section 6.2 compliance

Updated Integration Documentation based on validation experience:

• Integration guide refined based on actual integration testing
• Code examples validated and corrected if needed
• Common pitfalls and troubleshooting tips added
• Best practices documented

Test Applications/Artifacts (maintained for reference):

• Test mobile applications created for validation
• Test web applications created for validation
• Test scripts and automation
• Test data sets used

This validation provides the objective evidence required by IEC 82304-1 that the API satisfies user requirements in the intended environment of use.

3.4 Security Validation

Validate security controls in the production environment and through integration testing:

3.4 Security Validation

Validate security controls in the production environment:

• Data encryption in transit (TLS/SSL)
• Data encryption at rest
• Access controls and authentication
• Input validation and sanitization
• HTTPS enforcement
• Security headers configured correctly
• Vulnerability scanning results reviewed
• Security logging operational

3.5 Data Integrity Validation

Verify data integrity mechanisms:

• Data validation rules applied correctly
• Data persistence operates correctly
• Backup mechanisms function as designed
• Data recovery procedures validated
• Audit trails capture required information
• Data retention policies implemented correctly

4. Commissioning Activities

4.1 Commissioning Checklist

Complete the commissioning activities as specified in the Software Commissioning Plan (T-029-001), which verifies:

• API deployment to production infrastructure completed successfully
• All API validation activities passed (Annex A checklist completed)
• API endpoints are accessible and functioning correctly
• API performance meets specifications
• Security controls are operational
• Monitoring and logging systems are operational
• Client-facing documentation is complete and accurate
• Integration documentation has been validated
• Client support procedures are established (Annex B checklist completed)
• Incident response procedures are defined
• API versioning and deprecation policies are documented

Document all results in the Software Commissioning Report (T-029-002).

4.2 Client Documentation and Resources Delivery

Before making the API available to clients, ensure:

• API Integration Guide published and accessible
• API Reference Documentation published (OpenAPI/Swagger documentation)
• Instructions for Use (IFU) for the API delivered to clients
• Authentication and Authorization Guide available
• Code examples and sample implementations available
• Client SDK/libraries published (if applicable)
• Sandbox/test environment accessible to clients
• Test credentials and sample data available
• Support procedures and contact information communicated to clients
• API changelog and versioning information published
• Known issues and limitations documented and communicated

4.3 API Go-Live and Client Notification

The API commissioning and go-live includes:

• Internal handover: Transfer of operational responsibility to infrastructure/DevOps team
• Client notification: Inform clients that the API is available for production use
• Documentation availability: Confirm all client-facing documentation is accessible
• Support readiness: Confirm client support team is ready to handle integration questions
• Monitoring confirmation: Verify that API monitoring dashboards and alerts are operational
• Sign-off: Obtain formal approval on commissioning checklist
• Communication of support channels: Ensure clients know how to get help during integration

5. Post-Deployment Activities

5.1 Initial Monitoring Period

During the initial period after API deployment (typically 24-48 hours for critical systems):

• Monitor API performance continuously (response times, throughput)
• Review logs for errors or anomalies
• Monitor API call patterns and volumes
• Validate that monitoring alerts function correctly
• Verify backup procedures execute successfully
• Monitor first client integrations closely (if clients begin integration immediately)
• Confirm API authentication and authorization systems are working correctly
• Track any client support requests or integration issues

5.2 Post-Deployment Review

Within one week of deployment, conduct a post-deployment review:

• Review any issues encountered during API deployment
• Assess actual API performance against expected performance
• Review initial client feedback and integration experiences
• Document lessons learned
• Identify improvements for future API deployments
• Update deployment procedures if needed
• Review client support tickets and identify documentation improvements

5.3 Ongoing Monitoring and Client Support

Establish ongoing monitoring and support activities:

• API Performance monitoring: Response times, throughput, error rates
• API Usage monitoring: Track API calls, client usage patterns, rate limiting
• Error monitoring: Monitor API errors and client error rates
• Security event monitoring: Monitor authentication failures, suspicious activity
• Availability monitoring: Track API uptime and availability
• Client integration support: Provide ongoing support to clients during integration
• Client feedback collection: Gather feedback on API functionality and documentation
• Documentation updates: Update documentation based on client feedback and common questions

6. Client Integration Assurance Process

This section describes the systematic process AI Labs follows to ensure clients integrate the API correctly and safely.

6.1 Pre-Integration Phase

Before clients begin integration, AI Labs ensures:

6.1.1 Documentation Availability

• API Integration Guide is published and accessible
• API Reference Documentation (OpenAPI/Swagger) is available
• Instructions for Use (IFU) is delivered
• Code examples in relevant programming languages are available
• Authentication and authorization guide is clear and complete

6.1.2 Sandbox Environment Access

• Test/sandbox environment is available and accessible to clients
• Sandbox environment mirrors production API behavior
• Test credentials are generated and delivered securely
• Sample data sets are available for testing
• Sandbox usage is monitored for troubleshooting

6.1.3 Client Onboarding

• Initial contact with client technical team
• Overview of integration process and timeline
• Identification of support channels and contacts
• Discussion of client's intended use case and integration approach
• Review of any specific requirements or constraints

6.2 During Integration Phase

While clients perform the integration, AI Labs provides:

6.2.1 Technical Support

• Dedicated support channel (email, ticketing system, or direct contact)
• Response time commitments for support requests
• Technical experts available to answer integration questions
• Assistance with authentication and authorization setup
• Troubleshooting of integration issues
• Review of client's integration approach if requested

6.2.2 Integration Monitoring

• Monitor client's API usage in sandbox environment
• Identify unusual patterns or potential integration issues
• Proactively reach out if issues are detected
• Track common integration challenges to improve documentation

6.2.3 Integration Best Practices Communication

• Provide guidance on optimal API usage patterns
• Recommend error handling strategies
• Advise on rate limiting and performance optimization
• Share security best practices for API integration
• Communicate any known issues or limitations

6.3 Pre-Production Validation

Before clients move to production, AI Labs recommends and supports:

6.3.1 Client Testing Checklist Provide clients with a recommended testing checklist:

• Functional testing of all integrated API endpoints
• Authentication and authorization testing
• Error handling testing
• Performance testing under expected load
• Security testing (data encryption, secure credential storage)
• End-to-end testing in client's staging environment
• User acceptance testing with end users

6.3.2 Integration Review (Optional) For critical integrations or upon client request:

• Review client's integration implementation
• Validate proper error handling
• Verify secure credential management
• Confirm adherence to API best practices
• Provide feedback and recommendations

6.3.3 Production Credentials

• Generate production API credentials
• Deliver credentials securely
• Confirm client's production environment readiness
• Document production go-live date

6.4 Post-Integration Support

After client's production go-live:

6.4.1 Initial Monitoring

• Monitor client's production API usage closely (first 48-72 hours)
• Track error rates and performance metrics
• Be available for urgent support if issues arise
• Proactively identify and address any problems

6.4.2 Integration Success Validation Within 1-2 weeks after client go-live:

• Review integration performance and stability
• Collect client feedback on integration experience
• Document any issues encountered and resolutions
• Identify improvements for integration process

6.4.3 Ongoing Support

• Continue monitoring client API usage
• Provide ongoing technical support
• Communicate API updates and changes in advance
• Conduct periodic check-ins with established clients
• Gather feedback for continuous improvement

6.5 Integration Documentation and Records

For each client integration, maintain records of:

• Client identification and contact information
• Integration start and production go-live dates
• Support requests and resolutions
• Any integration issues identified
• Client feedback received
• Modifications made to documentation or support process

These records should be documented in Section 4.6 of the Software Commissioning Report (T-029-002) for clients integrating during the commissioning period, and tracked separately for subsequent client integrations.

These records help:

• Track successful integrations
• Identify common integration challenges
• Continuously improve integration documentation and process
• Provide evidence of proper client support
• Support post-market surveillance activities (GP-008)

7. Issue Resolution

If issues are identified during commissioning or post-deployment:

• Document the issue in the issue tracking system
• Assess severity and impact using risk management procedures (GP-013)
• Implement corrective actions following change control (GP-023)
• Perform regression testing to verify fixes
• Update documentation to reflect changes
• Communicate with stakeholders about resolution

7. Rollback Procedures

If critical issues prevent successful commissioning:

• Execute rollback plan to restore previous version
• Document rollback actions and reasons
• Perform root cause analysis of failures
• Update deployment and validation procedures based on lessons learned
• Plan remediation and schedule redeployment

Documentation

All API commissioning activities must be documented and retained in the Device History File (DHF). The two primary documents are:

Primary Commissioning Documents

T-029-001 Software Commissioning Plan - Prepared before commissioning, includes:

• Deployment plan and schedule
• API release package specifications
• Production environment requirements
• Objective 1: Internal validation plan and approach
  • Representative environments to be created
  • Test applications to be developed
  • Integration scenarios to test
  • Annex A: Detailed validation test cases (checklist)
• Objective 2: Client integration assurance plan
  • Client documentation to prepare
  • Support infrastructure requirements
  • Annex B: Client integration process checklist
• Acceptance criteria and success metrics
• Roles, responsibilities, and schedule

T-029-002 Software Commissioning Report - Completed after commissioning, documents:

• Deployment activities and results
• Objective 1: Internal validation results
  • Representative environments created
  • Test applications developed
  • Validation test results (from T-029-001 Annex A)
  • Evidence of successful integrations
  • Objective evidence of IEC 82304-1:2016 compliance
• Objective 2: Client integration assurance implementation
  • Client documentation published
  • Support infrastructure status
  • Initial client integrations (if applicable)
  • Results from T-029-001 Annex B activities
• Post-deployment monitoring results
• Acceptance criteria verification
• Issues, deviations, and resolutions
• Lessons learned and recommendations
• Commissioning approval and sign-off
• Appendices with detailed evidence

Supporting Documentation

From Objective 1 (Internal Validation):

• Test applications code and documentation
• Test scripts and automation
• Test data sets and results
• Performance monitoring data
• Security assessment results
• Screenshots and evidence of successful integrations

From Objective 2 (Client Integration Assurance):

• Client integration tracking records (for clients beyond commissioning period)
• Client support logs and metrics
• Documentation update history
• Client feedback records

General Commissioning Documentation:

• API deployment logs and evidence
• Infrastructure configuration documentation
• Monitoring dashboard configurations
• Incident reports and resolutions
• Post-deployment review notes

Client-Facing Documentation (to be delivered and maintained):

• API Integration Guide - complete step-by-step guide for clients to integrate the API
• API Reference Documentation - technical documentation of all API endpoints (OpenAPI/Swagger)
• Instructions for Use (IFU) - regulatory IFU for the medical device API
• Authentication and Authorization Guide - how to authenticate and authorize API calls
• Error Handling Guide - documentation of error codes and handling procedures
• Code Examples and Sample Implementations - working code examples in multiple languages (validated in Pillar 1)
• Client Support Procedures - how clients can get help during integration
• API Changelog - version history and changes documentation
• Integration Best Practices - recommendations for optimal API integration

Templates

• T-029-001 Software Commissioning Plan - comprehensive plan including deployment, validation approach (Objective 1), client integration assurance process (Objective 2), with Annex A (validation checklist) and Annex B (client integration checklist)
• T-029-002 Software Commissioning Report - comprehensive report documenting all commissioning activities, validation results, client integration assurance implementation, and evidence of IEC 82304-1:2016 compliance

Associated Procedures

• GP-012 Design, Redesign and Development
• GP-013 Risk Management
• GP-023 Change Control Management
• GP-028 AI Development
• GP-030 Cybersecurity Risk Management

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