Scaling, Change & Maintenance

Category: Customer Lifecycle | Audience: undefined | Page: 31 of 33

Table of Contents

• Key Concepts
• What You Can Do
• How To

- Set Up a Maintenance Window

- Test Changes Before Deployment

- Opt Out of Features in the MTJ Patient App

• Tips & Best Practices
• Next Steps

---

Scaling, Change & Maintenance

Welcome to the onboarding documentation for Scaling, Change & Maintenance on the Elixia Health clinical trial platform. This guide will help you understand how platform updates, maintenance, and changes are managed to ensure the smooth operation of your clinical trials.

Key Concepts

• Platform Updates: Regular updates to the MyClinicalTrial (MCT) platform to ensure security and availability.
• Maintenance Windows: Scheduled times for performing maintenance tasks, such as patching, on your servers.
• Change Classification System: A framework to categorize software changes based on their impact, urgency, and complexity.
• Advance Notice Commitments: The process of informing stakeholders about upcoming changes.
• Customer Validation Responsibilities: Your role in ensuring the MCT Application meets regulatory compliance standards.

What You Can Do

• Receive regular platform updates
• Configure and manage maintenance windows
• Test changes before deployment
• Opt out of specific features
• Ensure backward compatibility
• Understand change classifications
• Receive advance notice of changes
• Fulfill customer validation responsibilities

How To

Set Up a Maintenance Window

1. Log in to the MTJ Site Coordinator app:

- Navigate to the MTJ login page (https://mtj.elixiahealth.com)

- Enter your Site Coordinator credentials

- Complete multi-factor authentication if required

- You should have "System Administrator" or "Maintenance Manager" role to create maintenance windows

1. Navigate to the "Maintenance Windows" section:

- Click on the "Administration" menu in the main navigation

- Select "System Maintenance" or "Infrastructure"

- Click on "Maintenance Windows" to access the maintenance schedule

- You will see a calendar view and list of existing maintenance windows

1. Click on "Create Maintenance Window":

- Click the "+ New Maintenance Window" button

- A form will open with the following sections to fill in

1. Fill in the name, description, and schedule:

- Window Name: Provide a descriptive name (e.g., "January 2026 Security Patch - MCT Production")

- Description: Detailed description of what maintenance will be performed:

- Security patches being applied

- System upgrades or updates

- Database maintenance or optimization

- Infrastructure changes

- Start Date/Time: Select the date and time when maintenance will begin

- Recommended: Off-peak hours (e.g., 2:00 AM - 6:00 AM EST)

- Consider multiple time zones if your organization spans regions

- Avoid dates with known high trial activity

- End Date/Time: Select the expected completion time

- Account for typical maintenance duration (usually 2-4 hours)

- Build in buffer time for unexpected issues

- Blackout Period: Select dates when maintenance cannot occur

- FDA inspection dates

- Critical trial enrollment periods

- Patient visit windows

- Data audit periods

1. Specify the instances and patch baselines:

- Affected Instances: Select which systems will be affected:

- ☐ MCT Production Environment

- ☐ MCT Staging/Test Environment

- ☐ MTJ Patient App Servers

- ☐ MTJ Site Coordinator Servers

- ☐ Database Servers

- ☐ API Gateway/Load Balancers

- ☐ Other (specify): ___________

- Patch Baselines: Specify which patches will be applied:

- Operating System patches (e.g., "Windows Server 2022 KB5034672")

- Application patches (list specific version numbers)

- Security updates (reference CVE numbers if applicable)

- Database patches

- Firmware updates

- Rollback Plan: Specify how to revert if issues occur:

- Backup restoration procedures

- Previous version availability

- Rollback timeline and responsibilities

1. Set the duration and cutoff time:

- Planned Duration: Estimated time for maintenance (e.g., 3 hours)

- Based on complexity and typical execution time

- Add 25% buffer for unexpected delays

- Cutoff Time: Time by which maintenance must be completed

- If not completed by cutoff, abort and schedule retry

- Ensures business continuity (e.g., "Must complete by 6:00 AM EST")

- Grace Period: Additional time for final validation and monitoring

- Time after maintenance completion before full service restoration

- Allows monitoring for issues before users are notified

1. Configure notification and approval settings:

- Notification Recipients: Select who will be notified:

- ☐ All Site Administrators

- ☐ Study Teams

- ☐ Patients/Patient App Users

- ☐ External stakeholders

- Notification Timing:

- 2 weeks before maintenance window

- 48 hours before window

- 24 hours before window

- At start of maintenance

- Upon completion

- Notification Template: Choose predefined template or customize message

- Approval Required: If enabled, specify who must approve the maintenance window

- Project Manager

- Compliance Officer

- CISO or Security Officer

1. Click "Create" to save the maintenance window:

- A confirmation message will appear

- The maintenance window is now scheduled and visible on the calendar

- Automated notifications will be sent at the specified intervals

- An email confirmation is sent to maintenance administrators

- The maintenance window can be edited or cancelled until 24 hours before the start

Test Changes Before Deployment

1. Review the Changes:

- Obtain the change request documentation including:

- Change Summary: What is being changed and why?

- Technical Details: Code changes, configuration updates, database schema changes

- Affected Components: Which systems, modules, or services are impacted?

- Risk Assessment: What could go wrong? What are potential failure points?

- Rollback Plan: How will changes be reverted if critical issues arise?

- Review the change control board (CCB) approval status

- Understand the business drivers for the change

- Identify any dependencies on other systems or changes

- Document any questions or concerns about the change

1. Set Up Testing Environments:

- Development Environment: For initial testing by developers

- Staging/UAT Environment: Mirrors production as closely as possible

- Includes production-like data volumes

- Similar server configurations and infrastructure

- Same database versions and patches

- Test Data Preparation:

- Use anonymized production data if available

- Create realistic test scenarios

- Include edge cases and boundary conditions

- Prepare test cases matching production usage patterns

1. Run Automated Tests:

- Unit Tests: Verify individual components work correctly

- Execute all unit test suites

- Ensure code coverage meets standards (target: 80%+ coverage)

- All tests should pass with zero failures

- Run: dotnet test or equivalent test runner

- Integration Tests: Verify components work together

- Test data flows between components

- Test API integrations and data exchanges

- Verify database interactions

- Test authentication and authorization changes

- Regression Tests: Ensure existing functionality still works

- Run full test suite against all previously tested features

- Focus on areas that could be affected by the change

- Test backward compatibility if applicable

- Verify no new bugs were introduced

- Performance Tests: Verify no performance degradation

- Load testing with realistic user volumes

- Measure response times and throughput

- Monitor memory and CPU usage

- Test database query performance

- Security Tests: Validate security controls

- Authentication and authorization tests

- SQL injection and cross-site scripting (XSS) tests

- Data encryption and privacy checks

- API security and rate limiting tests

- Document Test Results:

- Record pass/fail status for all tests

- Document any failures with details

- Capture performance metrics and benchmarks

- Include test execution date and tester name

1. Manual Testing:

- Functional Testing: Verify features work as intended

- Test each user workflow affected by the change

- Test in different browsers/devices if applicable

- Verify UI/UX changes appear correctly

- Test with different user roles and permissions

- User Acceptance Testing (UAT):

- Have business users test the changes

- Test realistic end-to-end scenarios

- Gather user feedback on new features

- Verify changes meet business requirements

- Scenario Testing: Simulate real-world usage

- Scenario 1: Normal peak usage times

- Scenario 2: High data volume processing

- Scenario 3: Multiple concurrent users

- Scenario 4: Data import/export operations

- Scenario 5: Error and edge case handling

- Edge Case Testing: Test boundary conditions

- Maximum data field lengths

- Special characters in data

- NULL or empty values

- Concurrent operations on same data

- Manual Test Documentation:

- Create detailed test cases with expected results

- Document actual results and any deviations

- Capture screenshots of issues found

- Record tester name and test date

1. Verify Deployment:

- Pre-Deployment Checks:

- Confirm all tests passed successfully

- Obtain stakeholder approval to proceed

- Verify backup procedures are in place

- Ensure rollback plan is documented and tested

- Confirm change window is appropriate (no scheduled events)

- Deployment Execution:

- Follow deployment procedure step-by-step

- Document each step and completion time

- Monitor system during deployment

- Watch for error messages or warnings

- Post-Deployment Validation:

- Verify all services are running correctly

- Check database connectivity and performance

- Test critical workflows end-to-end

- Verify all features are accessible to users

- Check for any error messages in logs

- Monitor system performance metrics

- Sign-Off:

- Obtain formal sign-off from change manager

- Document deployment completion time and status

- Create change record noting actual deployment details

- Notify stakeholders of successful deployment

1. Monitor Closely:

- Real-Time Monitoring (first 24-48 hours post-deployment):

- Watch system dashboards and performance monitors

- Monitor application and system logs for errors

- Review user activity and transaction logs

- Watch for unexpected data patterns

- Monitor server resource usage (CPU, memory, disk)

- Performance Monitoring:

- Compare response times to baseline

- Monitor database query performance

- Watch for memory leaks or resource issues

- Alert on any performance degradation >10%

- Error Monitoring:

- Monitor application error logs

- Track exceptions and warnings

- Alert on new error types or increased error rates

- Investigate and document any errors

- User Issue Tracking:

- Monitor support tickets for new issues

- Track any user-reported problems

- Respond quickly to critical issues

- Document any workarounds needed

- Escalation Procedures:

- If critical issues found:

1. Notify change manager immediately

2. Assess need for rollback

3. Execute rollback if necessary

4. Document issue and root cause

5. Plan remediation

- If minor issues found:

1. Log as issue ticket

2. Prioritize for next maintenance window

3. Document workaround if available

- Extended Monitoring (1-2 weeks post-deployment):

- Continue monitoring for delayed issues

- Track any increase in support tickets

- Verify no data quality issues emerged

- Monitor for performance issues over time

- Review usage patterns

1. Post-Deployment Review:

- Schedule Review Meeting within 5 business days

- Participants: Change manager, developers, testers, operations

- Agenda: What went well? What could be improved?

- Document Lessons Learned:

- Issues encountered and resolutions

- Testing gaps that should be addressed

- Deployment procedures to refine

- Update Change Record:

- Final status and any issues

- Actual duration vs. planned

- Performance impact assessment

- Recommendations for future changes

- Close Change Request: Mark change as complete and verified

Opt Out of Features in the MTJ Patient App

1. Log in to the MTJ Patient app.
2. Go to "Settings" or "Preferences."
3. Find the "Opt-out" or "Consent" section.
4. Select the features you wish to opt out of.

Tips & Best Practices

• Stay Updated: Regularly check the MCT dashboard for notifications and announcements about platform updates.
• Plan Ahead: Schedule maintenance windows during periods of low trial activity to minimize disruption.
• Document Everything: Maintain detailed documentation of all changes, including version history and compatibility information.
• Communicate: Inform your team and stakeholders about upcoming changes well in advance.

Next Steps

• Familiarize yourself with the MCT and MTJ platforms.
• Configure your maintenance windows to align with your trial schedules.
• Test any upcoming changes thoroughly before deployment.
• Reach out to the Elixia Health support team if you have any questions or need assistance.

---

Navigation

← Previous: Security Incidents & Compliance Events

📚 Documentation Home

Next: Renewal, Exit & Archival →

---

Generated from MCT Knowledge Base • v1.1.0 • January 2, 2026