Comment rater son projet d’externalisation de données de santé en 6 étapes ? #5
Penser que c’est uniquement un projet technique
« En externalisant mes applications de santé chez un hébergeur HDS, rien ne va vraiment changer en fait. J’ai vu avec lui, je peux continuer de gérer mes VMs comme avant. Cool ! C’est un projet avant tout technique : vCPU, RAM, disques SAN, firewalls, sauvegarde, débit internet, système d’exploitation, reverse proxy, … »
En prenant ce projet uniquement sous l’angle de la technique, il est quasiment certain de passer à côté des autres aspects fondamentaux liés à un projet d’externalisation : transfert du risque et de la responsabilité, clauses contractuelles, garanties de niveaux de services (Garantie de temps d’intervention GTI, Garantie de Temps de Rétablissement GTR, Garantie de Temps de disponibilité GTD, …), gestion des accès nomades pour les utilisateurs, formation des utilisateurs, contrôle des missions du prestataire, préparation et implication des Directions Métiers concernées par les applications hébergées, problématiques des accès des sous-traitants et éditeurs de logiciel santé, gestion des licences, sensibilisation des utilisateurs à la sécurité, gestion des différents environnements de travail (développement, intégration, staging, pré-production et production), gestion de l’anonymisation des données de production, plan de reprise d’activité (PRA), mécanismes de réversibilité, mise en œuvre de la traçabilité des accès, … Les sujets sont tellement nombreux qu’ils dépassent le simple cadre d’un projet de migration technique. Certes, la technique joue un rôle important et indispensable mais il s’agit avant tout de répondre à une problématique globale d’externalisation de système d’information de santé et qui nécessite un solide cahier des charges.
Expression de besoins, Cahier des charges, Request For Information (RFI), Request For Proposal (RFP) ou encore Cahier des Clauses Techniques et Particulières (CCTP), autant de documents avec lesquels il est indispensable d’en comprendre les rouages et enjeux afin de formaliser le projet d’externalisation en un langage universel et compréhensible pour le prestataire-hébergeur. Ce sont là de véritables outils de pilotage.
Parmi les best practices, il faut s’assurer de couvrir à minima les champs suivants :
- Présentation du demandeur (commanditaire/bénéficiaire), du contexte, des enjeux et de l’origine du projet
- Description des « lots » attendus : aspects techniques, organisationnels, contractuels, commerciaux (catalogue de prestations), services rendus, indicateurs qualité, …
- Exigences réglementaires : certification ISO27k, HDS, RGPD, …
- Exigences de sécurité : Plan d’Assurance Sécurité (PAS) du prestataire et idéalement du demandeur (le guide de l’externalisation de l’ANSSI constitue à cet effet un excellent document de départ)
- Exigences liées à la Politique de Sécurité des Systèmes d’Information (PSSI) ; Les 114 mesures décrites dans la norme ISO/CEI 27002 fournissent un socle solide de bonnes pratiques en terme de mise en œuvre d’un Système de Management de la Sécurité de l’Information (SMSI). La mise en œuvre de ces mesures sont souhaitables (au moins partiellement) chez le demandeur et obligatoires chez l’hébergeur
- Explication des critères d’évaluation de la proposition du prestataire (il peut s’agir de critères multiples portant sur la technique, le pricing, la qualité de réponse, la richesse du catalogue de service, …)
- Exigences de qualité : Plan d’Assurance Qualité (PAQ) du prestataire, document essentiel qui regroupe les modalités exhaustives de la prestation d’hébergement (principes du PAQ, circularisation de l’information, organisation des équipes du prestataire et du demandeur, annuaire des participants, présentation des services délivrés – technique, services managés, … -, limites du périmètre, phases du projet avec la matrice RACI sous-jacente). La PAQ est un document contractuel vivant donc mis à jour régulièrement
- Exigences contractuel en terme de réversibilité (formalisation d’un plan de réversibilité)
- Audits internes/externes, comitologie et suivi de projet
- Niveau de service attendus (engagement de résultat/moyen, SLAs, support, …)
Un projet HDS est de toute évidence un projet complexe de par la nature des données sensibles et critiques qu’il manipule. Aucune concession ne doit être permise sur la sécurité, la disponibilité, l’intégrité, la confidentialité et la traçabilité du système d’information de santé. C’est à ce prix que la confiance sera établie entre les parties prenantes au seul service du patient et de l’amélioration de la qualité de soins.
Conseil n°5 : Piloter un projet HDS en participant à la rédaction des exigences métier et en impliquant toutes les parties prenantes, à commencer par les Directions métier concernées