Service Level Agreement (SLA)
ARTICLE 1 – PURPOSE
This Service Level Agreement (SLA) defines the service commitments applicable to the Take-QAIR® software solution provided by MELTOD HEALTH as SaaS.
It notably specifies:
Service availability levels;
Performance commitments;
Incident management procedures;
Response and resolution times;
Backup and business recovery mechanisms;
Security and service continuity commitments.
This SLA is a contractual annex to the General Terms of Sale.
ARTICLE 2 – SCOPE OF THE SERVICE
The service covered by this SLA includes:
Access to the SaaS platform;
Application services;
Databases;
API interfaces;
Cloud hosting infrastructure;
Security and monitoring services;
Technical support.
The following are not included in the scope:
The Customer’s equipment;
Public internet networks;
Third-party services integrated by the Customer.
ARTICLE 3 – SERVICE AVAILABILITY
3.1 Availability target
The Publisher commits to an annual availability target of: 99.9%
This target corresponds to a theoretical maximum downtime of:
8 hours and 45 minutes per year
3.2 Calculation method
Availability is calculated using the following formula:
Availability = (Total time – unplanned downtime) / Total time
3.3 Exclusions
The following are not counted in the calculation:
Scheduled maintenance;
Interruptions due to force majeure;
Incidents related to external network infrastructure;
Unavailability caused by the Customer.
ARTICLE 4 – MAINTENANCE
4.1 Corrective maintenance
Corrective maintenance aims to fix anomalies affecting the normal operation of the platform.
Fixes are carried out according to the criticality level of the incident.
4.2 Evolutive maintenance
The Publisher may deploy:
Functional improvements;
Technical optimizations;
Security patches.
These updates may be deployed without significant interruption of the service.
4.3 Scheduled maintenance
Planned maintenance is generally carried out:
Outside working hours;
After prior notice to the Customer where possible.
ARTICLE 5 – TECHNICAL SUPPORT
5.1 Access to support
Technical support can be reached through:
Email;
Ticketing platform;
Dedicated support interface.
5.2 Standard support hours
Monday to Friday
09:00 – 18:00 (Paris time), excluding public holidays.
Extended support levels may be defined contractually.
ARTICLE 6 – INCIDENT CLASSIFICATION
Incidents are classified into four criticality levels.
| Level | Description |
|---|---|
| P1 – Critical | Total unavailability of the service or major impact preventing any use |
| P2 – Major | Essential function severely degraded |
| P3 – Moderate | Secondary function affected |
| P4 – Minor | Minor incident or request for assistance |
ARTICLE 7 – RESPONSE TIMES
| Priority | Response time | Resolution target |
|---|---|---|
| P1 – Critical | 1 working hour | 4 hours |
| P2 – Major | 4 working hours | 24 hours |
| P3 – Moderate | 1 working day | 3 working days |
| P4 – Minor | 2 working days | As planned |
The times indicated are service objectives.
ARTICLE 8 – SUPERVISION AND MONITORING
The Publisher implements monitoring systems that make it possible to:
Automatically detect incidents;
Monitor the availability of the platform;
Check application performance;
Generate alerts in the event of an anomaly.
Monitoring systems may include:
Infrastructure monitoring;
Application monitoring;
Analysis of technical logs.
ARTICLE 9 – DATA BACKUP
The Publisher sets up regular data backup mechanisms to ensure data protection.
Backups are:
Automated;
Stored in secure environments;
Retained for periods suited to operational requirements.
ARTICLE 10 – BUSINESS CONTINUITY AND RECOVERY PLAN
To ensure the resilience of the service, the Publisher implements:
A Business Continuity Plan (BCP);
A Disaster Recovery Plan (DRP).
10.1 RTO – Recovery Time Objective
Maximum service recovery objective:
4 hours
10.2 RPO – Recovery Point Objective
Maximum acceptable data loss:
15 minutes
These objectives may change depending on the technical architecture of the service.
ARTICLE 11 – SERVICE SECURITY
The Publisher implements appropriate security measures, in particular:
Encryption of communications;
Secure access management;
Access logging;
Control of administrator access;
Regular security audits.
Where the platform processes health data, the requirements relating to certified Health Data Hosting (HDS) are applied.
ARTICLE 12 – CUSTOMER RESPONSIBILITIES
The Customer undertakes to:
Report incidents through the support channels;
Provide the information needed to diagnose them;
Use the platform in accordance with its documentation.
The Customer is responsible for:
Its IT equipment;
The security of its access;
The quality of the data entered.
ARTICLE 13 – SLA LIMITATIONS
The commitments of this SLA do not apply where the incident results from:
Non-compliant use of the platform;
An unauthorized modification;
A malfunction of third-party services;
A case of force majeure.
ARTICLE 14 – CHANGES TO THE SLA
The Publisher may change this SLA to take account of:
Technical developments;
Improvements to the platform;
Regulatory changes.
Any substantial change will be notified to the Customer.