Etapes de Mise en Place d'openIMIS

Le diagramme ci-dessous présente les étapes de mise en œuvre recommandées et l’ordre dans lequel elles sont utiles. Les huit étapes sont décrites avec plus de détails ci-dessous.

Etape 1 : Conceptualisation du régime d’assurance

openIMIS est un système informatique qui prend en charge le traitement des régimes d’assurance santé. C’est donc un préalable important que le régime d’assurance soit clairement défini, notamment son fonctionnement et les besoins requis du système d’informations. Si cela n’est pas clair, il y a un risque que le régime d’assurance s’adapte à ce que peut faire le système d’information plutôt que l’inverse. Savoir comment le système fonctionne (les procédures), qui sont les acteurs clés (la structure), quelles prestations sont offertes et comment les bénéficiaires seront gérés, donne un aperçu de ce que le logiciel doit pouvoir faire.

La conception globale du système est donc une condition préalable importante à la mise en œuvre d’openIMIS. Les éléments de conception suivants doivent être clairement établis avant la mise en œuvre :

Politiques directrices et réglementations
Structure organisationnelle
Procédures opérationnelles
Ensemble de prestations
Mécanisme de paiement des prestataires
Critères et processus de recrutement des prestataires

Dans certains contextes, des conditions préalables supplémentaires sont requises, telles que garantir l’établissement ou la modification d’actes/lois d’assurance qui réglementent ou établissent l’entité d’assurance. Le processus impliqué dans cette étape doit être de nature consultative et impliquer les acteurs concernés de l’organisme d’assurance, les ministères concernés (Santé et Finances) et d’autres parties prenantes clés impliquées et directement liées à la mise en œuvre de l’assurance. L’évaluation et la planification de l’introduction du logiciel devraient idéalement être effectuées vers la fin de cette étape (une fois les aspects de conception clarifiés), sinon l’évaluation reste incomplète et sujette à des lacunes ou à des changements ultérieurs conduisant à un système inadéquat.

Etape 2 : Opérationnalisation du régime d’assurance

Une fois les conditions préalables mentionnées ci-dessus remplies, il existe des procédures qui se dérouleraient idéalement parallèlement au processus de personnalisation. Ces processus comprennent :

Identification et contractualisation des :

o Prestataire de santé

o Fournisseur de télécommunications (pour les services de transfert de données)

o Passerelle SMS (le cas échéant)

o Fournisseur de services de paiement mobile/passerelle de paiement (le cas échéant)

Approvisionnement des:

o Forfaits de transfert de données du fournisseur de télécommunications (cartes SIM avec internet)

o Services de passerelle SMS (forfaits SMS)

o Formulaires (y compris carte d’identification) et laminages pour cartes

o Matériels informatiques (téléphones et ordinateurs)

o Environnement d’hébergement approprié selon les recommandations de la communauté openIMIS

Recrutement du personnel organisationnel (à tous niveaux)

Pour favoriser une opérationnalisation sans heurts du programme, des accords avec des partenaires externes pertinents pour le programme doivent être établis. Alors que les prestataires de santé sont essentiels à un régime d’assurance santé, le fournisseur de télécommunications (pour utiliser les applications mobile), le fournisseur de passerelle SMS (pour envoyer des confirmations/communications SMS) et le fournisseur de services de paiement mobile/passerelle de paiement (pour activer la connectivité de paiement mobile) sont facultatifs, en fonction de l’étendue de la mise en œuvre d’openIMIS. L’absence de partenariats externes pertinents peut entraîner des retards dans le déploiement d’openIMIS.

Partenaires et processus techniques

Les contrats passés avec les prestataires de santé établissent les modalités d’engagement, l’échelle de déploiement et garantissent que l’infrastructure de soutien sera en place pour permettre à openIMIS de fonctionner. Les implémentations sur papier, sans applications mobiles, ou utilisant des applications de smartphone en mode hors ligne, peuvent être prises en charge mais ne sont pas des configurations idéales. De préférence, des dispositions devraient être prises avec les fournisseurs de télécommunications pour obtenir un service de données permettant une utilisation complète des applications de téléphonie mobile. Les options de forfaits de données disponibles varient selon les pays et doivent être investiguées localement. Un exemple de package de données utile est un package de connectivité de données en boucle fermée qui peut permettre un suivi séparé des données mobiles utilisées autant pour les transactions openIMIS que les transactions non-openIMIS, et les facturer séparément.

Toutes les applications mobile openIMIS peuvent être utilisées en mode hors ligne pour la collecte de données mais nécessiteront une connexion internet pour télécharger les informations collectées dans la base de données. L’envoie de communication par SMS et la gestion des paiements par téléphone mobile sont des tâches externes à openIMIS et sont prises en charge par des solutions de partenaires externes disponible localement dans différent pays. Les régimes qui souhaitent utiliser la communication SMS au sein de leur régime d’assurance peuvent se procurer un service de passerelle SMS local (bundles SMS, gestion de l’envoi et du suivi des SMS) ainsi que des forfaits SMS et l’intégrer à openIMIS pour envoyer des confirmations et des rappels de renouvellement aux clients. De même, les systèmes qui acceptent les paiements mobiles peuvent utiliser des solutions locales pour la gestion de ces paiements et les intégrer à openIMIS pour échanger des données sur les paiements et activer automatiquement les polices.

L’achat de matériels (téléphones, ordinateurs, cartes mémoire, etc.), la configuration du serveur ainsi que différents formulaires, cartes d’assurances, laminage, etc. peuvent également souvent retarder le déploiement du système. Une fois acquis, le développement des inventaires et la gestion de ces inventaires sont également cruciaux. Différentes configurations pour le l’installation du server sont possibles en fonction de l’utilisation et des ressources disponibles, mais l’idéal est d’avoir des environnements séparés pour le développement, les tests, la formation, la sauvegarde et un environnement dédié au système en direct.

Enfin, tout personnel doit être recruté et en place. Une question clé à laquelle l’assureur doit répondre concerne le développement et la maintenance d’openIMIS. Bien que la solution soit disponible gratuitement, la maintenance de l’application nécessite une certaine structure support et en plus, si l’assureur souhaite entreprendre des développements ultérieurs de l’application localement, il a un besoin de capacité supplémentaire. A ce stade, l’assureur doit décider si tout cela est fait en interne ou s’il est (entièrement ou partiellement) sous-traité, et par conséquent, il devra disposer du personnel approprié en place.

Etape 3 : Personnalisation du logiciel

Idéalement, une fois la conception du programme terminée, la tâche de personnalisation du système pour la mise en œuvre devrait commencer. Les aspects suivant sont cruciaux :

Evaluation des spécifications du système par rapport aux procédures opérationnelles du régime d’assurance.
Modification des procédure opérationnelles ou des spécifications des systèmes, selon le besoin
Personnalisation de la langue (fichiers de ressources et documentation à l’appui).
Modification du logiciel selon la modification apportée aux spécifications du système (le cas échéant)
Configuration du server de test (installation et téléchargement de la base de données teste)
Intégration avec le service de paiement mobile/passerelle de paiement (le cas échéant)
Test des développements
Finalisation des développements du système sur la base des résultats des tests

Le logiciel openIMIS a déjà une certaine flexibilité intégrée dans son code source, mais cela peut également être modifié pour répondre aux besoins supplémentaires des utilisateurs. Ces besoins peuvent parfois être simplement le changement de la terminologie pour refléter les termes ou nom des acteurs utilisés par l’assureur.

Cependant, ces besoins peuvent être plus étendus et nécessitent le développement du logiciel. La comparaison des spécifications du système avec les procédures du régime d’assurance permet d’identifier les lacunes pour la modification du logiciel et, une fois identifiées, conduit à un changement dans les spécifications du système, et par conséquent, à la modification du logiciel. Quelle que soit l’étendue de la personnalisation nécessaire, les modifications doivent être correctement documentées et acceptées avant d’entreprendre toute autre modification. Lors de la planification des modifications, il est utile de consulter le groupe de produit openIMIS pour vérifier le pipeline de développement afin d’éviter les efforts en double et de trouver des synergies et des moyens de coordonner les efforts de développement.

L’intégration avec des composants externes (par exemple, SMS et passerelles de paiement mobile) est facultative et dépendante du contexte. Il est très important de tester le logiciel openIMIS dans votre contexte. Il faut prévoir suffisamment de temps pour tester le logiciel, en particulier lorsque des modifications importantes ont été apportées au logiciel.

Etape 4 : Configuration du système

Après la personnalisation du logiciel, l’étape suivante consiste à configurer le logiciel pour qu’il soit en utilisation. Les aspects suivants sont importants :

La mise en place de:

o Serveur de formation (installation avec la base de données factice)

o Serveur de production

o Mesures de sécurité côté serveur

o Serveur de sauvegarde et routine de sauvegarde

Configuration des registres sur le serveur de production
Installation des applications mobiles et téléchargement d’extraits sur téléphones mobiles

Etape de configuration du serveur

Différentes configurations sont possibles selon le contexte de l’implémentation, mais en générale, une configuration doit établir un serveur live et un serveur de formation séparé (chargé avec des données factices ou de test). Les configurations d’une installation doivent être ajustées en fonction de l’envergure et peuvent nécessiter une révision régulière. L’examen doit être basé sur le suivi de la charge du système et des problèmes d’optimisation. Par exemple, dans le contexte de l’augmentation à l’échelle nationale en Tanzanie, les composants d’application, de base de données et de rapports agrégés ont été placés sur des serveurs séparés pour gérer une charge de transaction plus élevée. En plus des mesures de sécurité au sein de l’application, il est important de mettre en place des mesures de sécurité côté serveur qui protègent le serveur hébergeant l’application et qui doivent être revues régulièrement pour aider à combler les failles de sécurité.

Il existe différentes options lors de l’établissement d’une routine de sauvegarde appropriée, en fonction des limites des ressources disponibles, des temps d’arrêt acceptables, des capacités RH et/ou des préférences locales. Un processus de sauvegarde clair, y compris les responsabilités, doit être rédigé et exécuté. Les coûts de prise en charge de l’infrastructure de sauvegarde peuvent être importants et, par conséquent, des justifications appropriées (pour ou contre) doivent être élaboré si des compromis sont faits. L’approche idéale serait de faire une grille d’évaluation des risques pour différents scénarios et d’établir quel risque l’assureur est prêt à prendre.

Etape de configuration du logiciel

La configuration des registres (éléments constitutifs du régime – liste des services, liste des prix, etc.) à l’aide de l’interface accessible par l’administrateur du système, fournit les données initiales avant que tout processus ne puisse être commencé. Un protocole doit être établi pour documenter les décisions prises (sur les prix, la liste des prestataires, les utilisateurs etc.), comment elles sont initialement mise en œuvre et comment elles sont ensuite mises à jour/gérées. L’administrateur peut entreprendre cette tâche, mais des procédures doivent être en place pour lancer cette action et la surveiller, car généralement les décideurs qui initient le changement (par exemple la décision d’ajouter une nouvelle installation ou de modifier les prix) ne sont pas faite par les personne qui mettent en œuvre le changement.

Etape d’installation du logiciel

Les premières installations d’applications mobile et le chargement d’extraits sur les appareils respectifs sont des tâches qui prennent du temps si le déploiement est à grande échelle. Elles doivent donc aussi être prise en compte dans la planification.

Etape 5 : Formation

L’étape suivante après la mise en place du système consiste à former différents acteurs sur comment utiliser le logiciel pour accomplir leurs tâches. L’ensemble d’acteurs suivant doit être formé :

Administrateur(s) du serveur
Administrateur(s) du système
Personnel du régime d’assurance
Agents de distribution
Personnel de l’établissement de santé

Les formations devraient idéalement être réparties entre différents groupes d’acteurs (selon la structure de mise en œuvre choisie) couvrant les aspects pertinents pour chaque groupe. Idéalement, l’approche serait de combiner la formation des acteurs sur les processus et sur l’utilisation de l’outil/logiciel.

La formation à l’administration du serveur doit inclure une formation sur la gestion du serveur sur lequel l’application s’héberge (y compris les problèmes de sécurité, la gestion des services web etc.) ainsi que la maintenance de la configuration choisie.

L’administration du système concerne des aspects de configuration tels que la gestion des registres clés (services couverts, changement de prix, installation couvertes, comptes d’utilisateurs etc.), ainsi que des aspects tels que la gestion des extraits hors ligne etc.

La formation du personnel du régime d’assurance dépendrait également des rôles à entreprendre par différents acteurs, y compris les cala/agents de distribution (internes ou externes, basés sur des commissions etc.)

Les établissements de santé sont clés et généralement impliquées dans des tâches telles que l’identification des clients et la soumission des prestations. Selon la configuration choisie, le personnel de l’établissement peut également avoir besoin d’une formation qui doit être prise en compte dans la planification.

Etape 6 : Phase pilote

Toute mise en œuvre devrait commencer par une phase pilote pour tester le système dans un environnement réel avec des acteurs réels à petite échelle. Les leçons retenues des programmes de pilotage sont toujours bénéfique, contribuent à l’amélioration du système et augmente par la suite le taux de réussite de la mise en œuvre. Les aspects suivants sont importants :

Concevoir le pilote
Saisir le feedback des utilisateurs (bugs ou nouvelle demandes)
Convertir les commentaires des utilisateurs en exigence du logicielle/processus
Adapter le logiciel/processus pour intégrer les feedbacks
Tester de nouveaux développement/adaptation
Déployer de nouveaux développement/amélioration

Une planification minutieuse doit être entreprise pour piloter le système, y compris le choix lieus géographiques. Idéalement, il convient de choisir des emplacements offrant la possibilité d’utiliser tous les modules dans différents scénarios, offrant une diversité en termes d’infrastructure et de conditions de mise en œuvre. Une approche structurée et des outils doivent être utilisés pour capturer les demandes des utilisateurs et noter les bugs ou problèmes observés pendant le pilotage qui peuvent être rapidement traité et corrigés.

Dans le cas où le pilote souligne la nécessité d’une personnalisation du logiciel, les exigences exactes doivent être correctement documentées, convenues, puis développées dans le système. Par la suite, des tests approfondis devraient précéder le déploiement des nouveaux développements. Les leçons tirées de la phase pilote devraient être utilisés pour mettre à jour le plan de déploiement et le déploiement à grande échelle.

Etape 7 : Maintenance & actualisation continue

Une fois que le système est opérationnel, un certain nombre de tâches de maintenance régulières peuvent être attendue au fur et à mesure que la configuration du système continuera d’évoluer.

Gestion journalière

o Mise à jour des configurations

o Assurer la sauvegarde du système

o Support de backstopping aux utilisateurs à différents niveaux

o Préparation d’extraits de données pour l’utilisation hors ligne

o Développement des capacités des (nouveaux) utilisateurs

o Saisie continue des besoins des utilisateurs, des lacunes, et des bugs

o Développement locaux (si entrepris)

Lien avec la communauté internationale d’openIMIS

o Feedback à la communauté openIMIS

§ Expérience de mise en oeuvre

§ Développement du logiciel

o Téléchargement de la nouvelle version d’openIMIS

o Mise à niveau de l’environnement test conforme à la version la plus récente d’openIMIS

o Tester la nouvelle version d’openIMIS

o Intégrer les développements locaux (le cas échéant) et tester la personnalisation spécifique du régime dans la nouvelle version

o Mise à niveau de l’environnement principal

La gestion des registres ou la configuration du système est une tâche permanente car au fur et à mesure que les programmes progressent, les paramètres changes (par exemple changement de prix des médicaments, agents d’inscriptions, des prestations, etc.). De même, les sauvegardes, la fourniture d’un soutien aux utilisateurs, la gestion des extraits de données pour les utilisateurs hors ligne, ainsi que les besoins de renforcement des capacités sont en cours pour tout régime d’assurance. La structure de support doit également mettre en place des processus appropriés pour saisir les nouvelles exigences ou les bugs qui pourraient être observés lors de la mise en œuvre du système, ce qui pourrait ensuite conduire à la décision d’entreprendre des développements locaux. Ici, le lien avec la communauté internationale d’openIMIS est utile pour mieux mettre en synergie les efforts de développement. Le partage d’expérience de mise en œuvre et des développements de logiciels (s’ils sont entrepris localement= conduirait à une amélioration supplémentaire de la solution pour les autres développeurs. La gestion de la mise à niveau du logiciel basé sur les version d’openIMIS est également un moyen simple de bénéficier des développements entrepris dans d’autres contexte. La mise à niveau de la version d’openIMIS doit être gérée de manière séquentielle et soumise à une étape de test local pour voir comment les personnalisations locales (le cas échéant) correspondent à la nouvelle version. Ce n’est qu’une fois soigneusement testée que la solution doit être déplacée vers l’environnement réel.

Etape 8 : Mise à l’échelle

Une fois la solution pilotée, la mise à l’échelle doit être planifiée et exécutée sur la base des enseignements tirés. La séquence des événements de la mise à l’échelle doit être visualisée à l’avance et une mise à l’échelle appropriée doit être prise en charge en mettant en place les éléments suivant :

Configuration de serveur appropriée (selon la charge attendue)
Infrastructure (personnel et équipement)
Structure de soutien d’appui
Personnel qualifié

openIMIS