INSTITUT NATIONAL D'ASSURANCE MALADIE-INVALIDITE

28 NOVEMBRE 2018. - Protocole d'accord conclu entre le Gouvernement fédéral et les autorités visées aux articles 128, 130, 135 et 138 de la Constitution, concernant la gestion et le financement de l'applicatif informatique de financement des maisons de repos et de soins, maisons de repos pour personnes âgées, centres de soins de jour, centres de rééducation fonctionnelle, maisons de soins psychiatriques et équipes multidisciplinaire d'accompagnement pour les soins palliatifs et centres palliatifs de jour (RVT)

Vu les compétences respectives dont disposent l'Etat fédéral et les autorités visées aux articles 128, 130, 135 et 138 de la Constitution, ci-après dénommées Communautés, sur le plan de la politique de la santé à mener à l'égard des personnes âgées;

Vu les compétences personnalisables concernant la politique de santé à mener à l'égard des personnes âgées;

Considérant que la sixième réforme de l'Etat a transféré de nouvelles compétences en matière de santé (décrites dans la Loi spéciale du 6 janvier 2014 relative à la Sixième Réforme de l'Etat) vers les entités fédérées;

Considérant que certaines matières relatives à la politique de la santé (décrites dans la Loi spéciale du 6 janvier 2014 relative à la Sixième Réforme de l'Etat) continuent à relever de la compétence de l'Etat fédéral;

Considérant que, compte tenu de la date de fin de la période de transition (31/12/2018), il n'est techniquement pas possible de conclure un accord de coopération et qu'il convient de passer à un protocole d'accord pour les années à venir en tant que solution provisoire;

Considérant que RVT est un applicatif informatique destiné à la gestion des processus de financement des maisons de repos et de soins, maisons de repos pour personnes âgées, centres de soins de jour, centres de rééducation fonctionnelle, maisons de soins psychiatriques et équipes multidisciplinaire d'accompagnement pour les soins palliatifs et centres palliatifs de jour (fin de carrière, forfait, troisième volet, quotas) découlant de la loi relative à l'assurance obligatoire soins de santé et indemnités, coordonnée le 14 juillet 1994; et de la loi de programme du 2 janvier 2001 et sous laquelle le 1er janvier 2019 peut ou non être repris intégralement ou partiellement dans les réglementations régionales;

Considérant que le présent accord vise à définir le mode de gestion et le mode de financement de la maintenance, de l'exploitation et des développements de l'applicatif informatique RVT utilisé par les parties signataires;

Il est décidé ce qui suit: TITRE Ier. - Généralités

Article 1er.Dans le présent Protocole, on entend: a) par « INAMI », l'Institut national d'assurance maladie invalidité visé à l'article 10 de la loi relative à l'assurance obligatoire soins de santé et indemnités, coordonnée le 14 juillet 1994;b) par « applicatif RVT », un applicatif informatique destiné à la gestion des processus de financement des maisons de repos (fin de carrière, forfait, troisième volet, quotas) et d'autres institutions;c) par « RaaS », RVT-as-a-Service, le projet pour adapter l'application RVT aux besoins des parties signataires de ce protocole.

Art. 2.Les parties signataires décident d'utiliser une version unique et commune de l'applicatif RVT hébergée par l'INAMI à partir du 1er janvier 2019 (à l'exception de la Communauté flamande qui utiliseront déjà l'application RVT à partir du 1er décembre 2018). Si l'une des parties décide de quitter l'applicatif RVT, un préavis par écrit de 1 an doit être soumis par écrit aux autres parties signataires avant que ce départ puisse être effectif. Cette annulation ne peut avoir lieu qu'à partir du 1er janvier 2019.

La période de préavis commence au 1er janvier de l'année suivant la date de la notification de la décision de quitter l'applicatif RVT. Toutes les parties signataires sont co-utilisateurs de l'applicatif RVT et co-responsables de son bon fonctionnement.

Si une partie signataire décide de ne plus utiliser l'applicatif RVT, elle recevra une copie de l'applicatif RVT de l'INAMI et les données qui lui sont nécessaires pour exercer ses compétences.

En plus du code source et de la base de données, les informations suivantes sont également transmises: - Documentation complète et à jour comprenant l'analyse fonctionnelle et technique, les documents d'architecture de l'applicatif, le modèle de données logiques, les scénarios de tests, les notes des release, le manuel d'installation et les scripts qui décrivent la réinstallation dans le détail, les données des tests. - Documentation complète des calculs et des paramètres de calcul; - Les changements suite aux évolutions et aux corrections doivent être également documentés. Le code source doit contenir suffisamment de commentaires pour indiquer clairement les changements et faire les liens avec les documents précités. Une liste de toutes les différentes versions et leurs fonctionnalités et les corrections des problèmes rencontrés depuis la première construction de l'applicatif; - Les paramètres de connexion à l'applicatif et un aperçu des certificats de sécurité nécessaires à son bon fonctionnement; une description de l'infrastructure et des licences de logiciels nécessaires; les outils de développement et les caractéristiques des environnements de développement et d'exploitation .

Si les éléments ci-dessus sont insuffisants, la partie signataire désireuse de ne plus utiliser RVT, a droit jusqu'à 40 jours ouvrables d'assistance technique gratuite de l'INAMI pour compléter cette information.

TITRE 2. - Suivi d'un nouveau développement

Art. 3.Un Comité de pilotage est créé pour gérer l'applicatif RVT. Chaque partie signataire dispose de maximum deux représentants et suppléants au sein de ce Comité de pilotage.

Le Comité de pilotage se réunira toutes les 6 semaines et au moins 4 fois par an. Un chef de projet IT INAMI préside ce Comité de pilotage.

Le chef de projet IT fournit l'agenda et les documents à traiter au minimum trois jours ouvrables avant la réunion et fait un compte-rendu de chaque réunion du Comité de pilotage alternativement en français ou néerlandais et le diffusera aux représentants des parties signataires. CHAPITRE Ier. - Réception d'une demande de développement

Art. 4.Toutes les demandes de développement ou de corrections de l'applicatif RVT formulées par une partie signataire doivent être adressées au chef de projet IT. Le chef de projet IT tient un inventaire permanent des demandes accessible sous format informatique par toutes les parties signataires.

Les développements de fonctionnalités communes à toutes les parties signataires seront à favoriser.

Des développements de fonctionnalités spécifiques par une ou des parties signataires doivent être possibles. Voir article 9 de ce protocole.

Art. 5.Analyse d'une demande Le chef de projet IT et le chef de projet informatique déterminent l'impact et la cohérence de la demande sur l'ensemble de l'applicatif RVT et sur les différentes parties signataires.

Le chef de projet informatique et son équipe évaluent: - la faisabilité technique, - les ressources nécessaires au développement ainsi qu'un planning, - l'impact sur les coûts d'exploitation ou sur les investissements nécessaires en matériel.

Art. 6.Décision préalable aux nouveaux développements Les analyses sont ensuite présentées et discutées dans des groupes fonctionnels dans lesquels sont invités toutes les parties signataires et finalement validées au Comité de pilotage.

Si le développement a un impact sur les autres parties signataires, leur accord préalable est nécessaire.

La répartition du financement des développements, entre les parties signataires, est définie au sein du Comité de pilotage.

Art. 7.Planification du développement Les développements de l'applicatif sont répartis dans des « releases » planifiés au sein du Comité de pilotage.

Le Comité de pilotage adaptera le planning global des développements pour insérer les nouveaux développements le cas échéant.

Le Comité de pilotage déterminera les dates des tests d'acceptance, de la validation et de la mise en production des releases.

Art. 8.Tests, validation et mise en production Après chaque développement, l'équipe de projet informatique réalise des tests de l'applicatif sur l'environnement de test, avant la mise à disposition aux parties signataires, basés sur un plan de test préalablement préparé et livré (responsabilité de l'INAMI avec la coopération de la partie signataire) et des scénarios de test associés (responsabilité de la partie signataire) afin de vérifier que l'applicatif est conforme à l'analyse fonctionnelle et si l'ensemble de l'applicatif fonctionne toujours correctement.

Ensuite, les parties signataires réaliseront les tests d'acceptance business sur l'environnement de validation et fourniront un rapport des tests au chef de projet IT. Après la phase de test et la phase de correction des points bloquants décelés dans cette phase de test, les parties signataires valideront la mise en production de l'applicatif.

Le Comité de pilotage et la Direction ICT détermineront ensemble le moment pour mettre en production la nouvelle version de l'applicatif, en essayant d'avoir le moins d'impact sur la continuité des processus des parties signataires.

Art. 9.Développements spécifiques Pour des développements spécifiques à une partie prenante, une organisation en sous-projet pour ce développement peut être mise en place. Ce type de projet est suivi par un groupe de projet comprenant la ou les parties signataires concernées par ce projet.

Un rapportage régulier vers le Comité de pilotage de l'applicatif RVT doit avoir lieu.

Si le projet a un impact sur les autres parties signataires (fonctionnement de l'applicatif, planning des développements,...), les autres parties signataires doivent être consultés et doivent valider la mise en production et les modifications de la planification des développements. CHAPITRE II. - Responsabilités spécifiques concernant la qualité des développements

Art. 10.Responsabilités du chef de projet IT - gestion de l'équipe informatique et respecter les exigences (requirements) définies par le Comité de pilotage; - vérification de la cohérence des développements; - la coordination des tests d'acceptance business. Un test d'acceptance business consiste en une validation du fonctionnement de l'applicatif modifié après tout nouveau développement.

Art. 11.Responsabilités du Comité de pilotage RaaS (avec des représentants de toutes les parties signataires): - responsabilité finale de l'applicatif RVT; - approuver le contenu des releases; - contrôler si les projets sont sur la bonne voie pour atteindre les objectifs (validation des rapports d'avancement et gestion des risques et évènements); - valider le bon fonctionnement de l'applicatif après la phase de test d'acceptance de tous les partenaires suite à un nouveau développement ou une maintenance dans l'applicatif. Il donne l'autorisation de mise en production des nouveaux développements. Il procède à l'analyse, le suivi et la gestion des risques; - constate et approuve la fin d'un release. CHAPITRE III. - Service Level Agreement, documentation et gestion des litiges

Art. 12.Service Level Agreement La Direction ICT de l'INAMI en concertation avec le Comité de pilotage rédigera un Service Level Agreement (respectant les prescriptions de ce protocole d'accord) avant le 1 Janvier 2019 qui précisera les éléments suivants: - la procédure détaillée pour soumettre une demande d'un nouveau développement; - les modes de décisions; - la procédure de correction d'un point bloquant; - la méthode et le timing pour réaliser les tests et validation; - la qualité des services; - la gestion des environnements d'exploitation de l'applicatif RVT; - la mode de suivi du budget et de l'avancement des projets; - le rapport mensuel sur la disponibilité et les performances de l'applicatif et les incidents survenus; - Surveillance en temps réel de l'applicatif et notification immédiate des interruptions de service.

Art. 13.Documentation L'équipe de projet informatique documente le code source.

La documentation sur les modifications apportées à l'application RVT est à disposition des organisations des parties signataires dans une librairie informatique partagée.

Art. 14.Gestion des litiges et désaccords En cas de désaccord ou litige (sur le planning, les développements,...) au sein du Comité de pilotage, une réunion entre les responsables des différentes administrations des parties signataires doit être prévue pour trouver une solution. CHAPITRE IV. - Autres activités du chef de projet IT

Art. 15.Le chef de projet IT est responsable de la formation de nouveaux utilisateurs des parties signataires (à l'exception des développements spécifiques visés par l'article 9 de ce protocole).

Le chef de projet IT est responsable de la formation des utilisateurs suite à des modifications de l'applicatif RVT. Le chef de projet IT soutiendra les parties signataires dans la gestion du changement lors des modifications de l'applicatif RVT. Le chef de projet informatique doit être capable de communiquer correctement en néerlandais et en français.

Autres responsabilités du chef de projet IT: - contrôler la cohérence des développements, surveiller le budget disponible et faire un rapport régulier; - soutenir la phase de démarrage des projets et entre autre contrôler les délivrables comme une chartre de projet, un scope document,...; - suivre le planning des releases et les plannings des projets contenus dans un release; - faciliter la communication entre les divers acteurs; - assurer la réutilisation des leçons apprises et des solutions de projets déjà réalisés; - surveiller l'utilisation des normes et standards convenus; - guider et contrôler l'analyse business, entre autre fournir de l'input à cette analyse; - coordonner les tests d'acceptance business. CHAPITRE V. - Equipe informatique

Art. 16.L'équipe informatique en charge du développement de l'applicatif RVT fait partie de la Direction ICT de l'INAMI. Sa composition variera en fonction du volume et de la nature des demandes de développements (analyste, architecte, développeur, chef de projet). La composition de l'équipe informatique est transparente pour les parties signataires et conforme à la planification et au budget.

Art. 17.La Direction ICT de l'INAMI: - est responsable de fournir les produits prédéfinis avec la qualité prédéfinie dans un temps et un coût prédéfini; - s'assure que les produits livrés fourniront les bénéfices attendus; - surveille et contrôle l'avancement du projet dans les tolérances définies par le Comité de pilotage; - s'assure que tous les risques, la qualité et les résultats sont enregistrés et contrôlés; - prépare des rapports lorsqu'une situation peut menacer les tolérances définies; - propose un plan d'ajustement si nécessaire.

Art. 18.Les membres de l'équipe informatique impliqués dans le projet remplissent des « timesheets » qui seront utilisés par le chef de projet et le chef de projet IT pour faire un reporting au minimum chaque six semaines en jours-hommes prestés et ETC, auprès des parties signataires et pour chaque projet.

Ce reporting portera également sur la répartition des jours-hommes entre les parties signataires. CHAPITRE VI. - Helpdesk

Art. 19.Pour le support informatique, la Direction ICT de l'INAMI dispose d'un ServiceDesk Informatique.

Une personne dans chaque administration sera la personne unique chargée pour signaler les incidents. Cette personne pourra disposer d'un back-up en cas d'absence. Les notifications sont de préférence effectuées par e-mail et en cas d'urgence également par téléphone.

L'équipe informatique répondra par e-mail.

Les parties signataires fourniront un soutien de première ligne à leurs utilisateurs. Les problèmes avec les tiers (par exemple eHealth) seront également suivis directement par les parties signataires.

Seulement dans le cas où il n'y a pas de solution ou il y a un problème structurel ou un bug dans l'application, appellerons-nous sur le support de deuxième ligne de l'INAMI. La Direction ICT de l'INAMI répondra aux questions ou trouvera une solution dans les meilleurs délais possibles (best effort). La Direction ICT de l'INAMI est active entre 8 heures et 17 heures du lundi au vendredi. CHAPITRE VII. - Financement

Art. 20.Les entités signataires participent au financement de l'exploitation, de la maintenance et des développements de l'applicatif RVT selon les modalités suivantes :

Art. 21.Frais de maintenance et d'exploitation Une petite partie des pouvoirs resteront réservées à l'INAMI, notamment le financement de Coma, MS, ALS et Huntington.

Les coûts liés à la maintenance et l'exploitation de l'applicatif RVT attendus pour 2019 sont de 50.000 Euro et sont répartis entre les parties signataires selon la clé de répartition suivante: Communauté Flamande 1/4 Commission communautaire commune de Bruxelles-Capitale 1/4 Région Wallonne 1/4.

INAMI 1/4 Les coûts d'entretien et d'exploitation comprennent : Coûts de maintenance des infrastructures et logiciels existants (Licences, ...) Maintenance proactive, monitoring et suivi quotidien Gestion et résolution des incidents Déploiement de logiciels (en test et en production) Exécution du back-up Si une partie signataire décide de ne plus utiliser RVT, les coûts seront également repartis entre les autres parties signataires

Art. 22.Financement frais de développements après 2018 Chaque année X avant avril, la Direction ICT de l'INAMI et le chef de projet IT en concertation avec les parties signataires au sein du Comité de pilotage détermineront les coûts nécessaires de maintenance et d'exploitation et de développement pour l'année suivante (X+1).

Pour les frais de développement, chaque communauté fournira un budget correspondant à l'estimation des fonctionnalités demandées pour leur communauté. En principe, chaque communauté finance ses propres développements.

Pour les frais de développement commun, la répartition des frais estimés pour chaque année sera basée sur la clé de répartition précitée: Communauté Flamande 1/4 Commission communautaire commune de Bruxelles-Capitale 1/4 Région Wallonne 1/4 INAMI 1/4 Dans la mesure du possible, les fonctionnalités demandées seront intégrées dans le budget prévu (scope to budget), ce qui signifie que les priorités des fonctionnalités demandées peuvent être modifiées sous réserve de l'approbation du Comité de pilotage.

Si un budget supplémentaire est nécessaire en cours d'année, une proposition d'ajustement budgétaire sera soumise par le Comité de pilotage.

La répartition du financement des développements spécifiques cités dans article 9 de ce protocole est définie par le Comité de pilotage au cas par cas: - soit financement par le budget de développements communs - soit financement par un budget de la ou les administration(s) concernées par ces développements spécifiques.

Art. 23.Mécanisme de financement Les montants estimés par le Comité de pilotage seront inscrits dans les propositions du budget de l'INAMI lors de la confection du budget en avril de l'année X-1 qui précède la réalisation des développements.

Les services d'encadrement B&Cg et ICT de l'INAMI tiendront à jour une comptabilité analytique.

En janvier, avril, juillet et octobre de chaque année X, l'INAMI envoie une facture à la Communauté Flamande, la Commission communautaire commune de Bruxelles-Capitale et la Région Wallonne afin de les inviter à régler les frais fixes et les frais de développement pour chaque 3 mois de cette année.

Si les crédits initiaux prévus pour RaaS inscrits dans le budget de l'INAMI ne sont pas suffisants, un ajustement budgétaire sera à envisager (Concrètement, cela concerne un ajustement du périmètre ou une augmentation du budget à convenir au sein du groupe de pilotage).

Un ajustement du budget est réalisé en général en Avril de chaque année et les crédits acceptés sont mis à disposition de l'INAMI après le vote de la loi d'ajustement par la Chambre et après signature de la loi par le Roi (normalement début Juillet).

Si les crédits initiaux prévus pour RaaS inscrits dans le budget de l'INAMI ne sont pas utilisés entièrement suite à une décision du Comité de pilotage (par exemple, de ne pas mettre en oeuvre certains développements), la facture à concurrence de ce crédit non utilisé ne sera pas envoyée à la Communauté Flamande, la Commission communautaire commune de Bruxelles-Capitale et la Région Wallonne. CHAPITRE VIII. - Protection de la vie privée et responsabilité du traitement des données

Art. 24.Le Comité de pilotage veillera au respect de la législation concernant la protection de la vie privée et sur le traitement des données personnelles.

Réalisé à Bruxelles, le 28 novembre 2018 en 4 exemplaires originaux.

Pour l'Etat fédéral : L'Administrateur-Général de l'INAMI, M. DE COCK Le Directeur ICT, M. N. MARLY Voor de Vlaamse Gemeenschap: De Administrateur-Generaal van VAZG, M. Dirk DEWOLF Pour la Région Wallonne: L'Administratrice-Générale de l'AViQ, Alice BAUDINE Pour le Collège Réuni de la Commission communautaire commune, par la décision du 13 juillet 2017 : Le Comité Général de gestion d'Iriscare Représenté par Tania DEKENS, coordinatrice de l'Office