Infrastructure iTafaray
Documentation textuelle de l’infrastructure
Élément |
Description |
|---|---|
Objet du document |
Décrire les couches, les composants et les flux de données de l’infrastructure iTAFARAY à partir du schéma d’architecture. |
Version |
Version mise à jour après ajout des légendes de flux. |
Périmètre |
Couche d’entrée et stockage, couche d’interopérabilité, couche d’échange et couche de visualisation. |
Hypothèse structurante |
Les composants HAPI FHIR, serveur de sécurité, X-Road et couche de visualisation communiquent au moyen d’échanges bidirectionnels. |
1. Objet et périmètre de l’infrastructure
L’infrastructure iTAFARAY a pour objectif de mettre en relation des systèmes sources de collecte et de stockage, une chaîne d’interopérabilité fondée sur HAPI FHIR, un mécanisme d’échange sécurisé via X-Road et des plateformes de visualisation destinées à l’exploitation des données. Le schéma introduit explicitement les légendes permettant d’identifier la nature des flux entre les composants.
Le périmètre couvert comprend CommCare HQ pour le secteur humain, animal et ultérieurement, des outils du secteur environnemental, l’API Gateway, l’instance HAPI FHIR, le serveur de sécurité, X-Road, DHIS2 et les autres plateformes de visualisation. Les bases PostgreSQL représentées dans le schéma sont considérées comme des mécanismes de persistance associés aux composants qui les utilisent.
Les échanges entre HAPI FHIR, le serveur de sécurité, X-Road et la couche de visualisation sont considérés comme bidirectionnels, car chaque composant peut à la fois émettre des requêtes et recevoir des réponses dans le cadre des services exposés.
2. Vue d’ensemble de la configuration mise à jour
L’architecture s’organise autour de quatre couches principales. La couche d’entrée et stockage sert les données brutes et expose les services sources. La couche d’interopérabilité reçoit ces services, les normalise et les rend exploitables selon une logique FHIR. La couche d’échange assure la publication et la consommation sécurisée des services interopérables. La couche de visualisation interroge l’infrastructure et restitue les informations sous forme de tableaux de bord, d’indicateurs ou de vues métiers.
Couche |
Rôle principal |
Composants visibles |
|---|---|---|
Entrée et stockage |
Servir les données brutes, exposer les services sources et conserver certaines données opérationnelles. |
CommCare HQ, PostgreSQL, autres outils du secteur environnemental |
Interopérabilité |
Normaliser les données et services vers FHIR, puis sécuriser et échanger les services. |
API Gateway, HAPI FHIR, serveur de sécurité, X-Road |
Échange |
Organiser les échanges inter systèmes au moyen d’une couche dédiée et sécurisée. |
X-Road |
Visualisation |
Consulter, restituer et exploiter les données via des plateformes métiers. |
DHIS2, PostgreSQL, autres plateformes de visualisation |
3. Description des couches fonctionnelles
3.1 Couche d’entrée et stockage
Cette couche constitue le point d’origine des données et services. CommCare HQ est positionné comme système source pour le secteur humain et animal. Les autres outils représentés dans la partie environnementale jouent un rôle équivalent pour les données environnementales. La base PostgreSQL associée à CommCare HQ permet de représenter la persistance ou la disponibilité de données structurées côté source.
La relation entre cette couche et l’API Gateway correspond à l’exposition des données brutes et services sources. Les systèmes sources ne sont donc pas uniquement des bases de données passives. Ils servent des données et peuvent exposer des interfaces ou services consommés par la passerelle d’API.
3.2 Couche d’interopérabilité
La couche d’interopérabilité constitue le noyau technique de l’infrastructure. Elle commence par l’API Gateway, qui joue le rôle de point d’entrée technique pour les services sources. Cette passerelle centralise les appels, facilite le routage et peut porter des fonctions de contrôle telles que l’authentification, le filtrage ou la limitation des appels.
L’instance HAPI FHIR reçoit les données et services transmis depuis la passerelle. Son rôle est de traiter, structurer et normaliser ces éléments afin de les rendre conformes au modèle d’interopérabilité retenu. Dans le schéma mis à jour, ce flux est identifié comme un flux de normalisation et conformité FHIR.
Le serveur de sécurité et X-Road complètent cette chaîne. Ils permettent de sécuriser les échanges, de gérer les appels entre producteurs et consommateurs de services, et de fournir un cadre d’échange contrôlé entre les briques techniques et les plateformes de visualisation.
3.3 Couche d’échange
La couche d’échange est représentée par X-Road. Elle agit comme un mécanisme d’intermédiation pour les services interopérables. Elle permet à des plateformes autorisées de consommer les services publiés, tout en conservant une logique d’échange sécurisé, traçable et gouverné.
3.4 Couche de visualisation
La couche de visualisation comprend DHIS2, une base PostgreSQL associée et d’autres plateformes de restitution. Elle n’est pas uniquement destinataire d’un flux descendant. Elle peut envoyer des requêtes vers X-Road, recevoir les réponses correspondantes, afficher les informations, produire des indicateurs et éventuellement déclencher des demandes de rafraîchissement ou de synchronisation.
4. Description des composants techniques
Composant |
Position dans le schéma |
Fonction attendue |
|---|---|---|
CommCare HQ |
Couche d’entrée et stockage |
Système source du secteur humain et animal. Il sert les données brutes et expose les services nécessaires à l’intégration. |
Autres outils environnementaux |
Couche d’entrée et stockage |
Sources de données du secteur environnemental. Ils alimentent l’architecture avec des données brutes ou des services spécifiques. |
PostgreSQL côté sources |
Associé aux systèmes sources |
Base relationnelle utilisée pour conserver des données structurées ou faciliter l’exposition des informations. |
API Gateway |
Entrée de la couche d’interopérabilité |
Point d’entrée technique qui reçoit les services sources et les transmet vers HAPI FHIR selon les règles définies. |
HAPI FHIR |
Traitement FHIR |
Moteur de normalisation, structuration et exposition de ressources ou services conformes à FHIR. |
Serveur de sécurité |
Entre HAPI FHIR et X-Road |
Composant de contrôle, protection et médiation des échanges entre services FHIR et X-Road. |
X-Road |
Couche d’échange |
Plateforme d’échange sécurisé assurant la publication, la consommation et le routage des services interopérables. |
DHIS2 |
Couche de visualisation |
Plateforme de visualisation et exploitation des données, notamment sous forme d’indicateurs et tableaux de bord. |
Autres plateformes de visualisation |
Couche de visualisation |
Applications complémentaires de reporting, analyse, suivi ou restitution métier. |
5. Légendes et flux de données
Le schéma corrigé distingue trois natures principales de flux. Le premier concerne les données brutes et services sources. Le second concerne la normalisation et la conformité FHIR. Le troisième concerne les échanges sécurisés des services FHIR, avec une orientation bidirectionnelle entre les briques centrales.
Relation |
Sens |
Terme recommandé |
Interprétation |
|---|---|---|---|
Couche d’entrée et stockage vers API Gateway |
Principalement entrant vers la passerelle |
Données brutes et services sources |
Les systèmes sources servent les données brutes et exposent les services consommés par l’API Gateway. |
API Gateway vers HAPI FHIR |
Flux de traitement vers HAPI FHIR |
Normalisation et conformité FHIR |
La passerelle transmet les services ou données à HAPI FHIR pour transformation, validation et structuration selon FHIR. |
HAPI FHIR avec serveur de sécurité |
Bidirectionnel |
Échanges sécurisés des services FHIR |
HAPI FHIR expose ou consomme des services, tandis que le serveur de sécurité contrôle les requêtes et réponses. |
Serveur de sécurité avec X-Road |
Bidirectionnel |
Échanges sécurisés des services FHIR |
Le serveur de sécurité et X-Road échangent les appels et réponses des services interopérables. |
X-Road avec couche de visualisation |
Bidirectionnel |
Échanges sécurisés des services FHIR |
Les plateformes de visualisation interrogent X-Road et reçoivent les données, indicateurs ou ressources nécessaires. |
6. Chaîne fonctionnelle de bout en bout
La chaîne fonctionnelle commence par la mise à disposition des données brutes et services sources. CommCare HQ et les outils environnementaux exposent les informations à travers les mécanismes techniques disponibles. L’API Gateway joue ensuite le rôle de point de concentration et d’orientation des appels vers l’instance HAPI FHIR.
HAPI FHIR assure la transformation fonctionnelle de ces données et services vers une forme interopérable. Cette étape doit intégrer les règles proposées par l’UGD, notamment les exigences de structuration, de cohérence, de validation et de conformité des ressources échangées.
Après la normalisation, les services FHIR transitent vers le serveur de sécurité et X-Road. Ces briques permettent aux consommateurs autorisés, notamment les instances DHIS2 et les autres plateformes de visualisation, d’interroger les services et de recevoir les réponses. Les flux sont bidirectionnels, car la visualisation repose sur un cycle requête réponse plutôt que sur une simple alimentation descendante.
7. Sécurité, contrôle et conformité
La sécurité de l’infrastructure repose sur la limitation de l’exposition directe des systèmes sources, la centralisation des appels au niveau de la passerelle, la normalisation contrôlée par HAPI FHIR, puis l’échange sécurisé via le serveur de sécurité et X-Road. Chaque composant doit disposer de règles d’accès propres, adaptées à son rôle dans la chaîne.
Les règles proposées par l’UGD doivent être traduites en exigences techniques. Cela concerne notamment la validation des formats, la gestion des droits, la traçabilité des échanges, la conservation des journaux, la protection des secrets, le chiffrement des communications et le contrôle des consommateurs autorisés.
Élément |
Description |
|---|---|
Authentification |
Les appels vers les services doivent être associés à des identités techniques ou applicatives clairement définies. |
Autorisation |
Les droits doivent préciser quels systèmes peuvent appeler quels services et quelles données peuvent être consultées. |
Traçabilité |
Les requêtes, réponses, erreurs et changements de configuration doivent produire des journaux exploitables. |
Confidentialité |
Les communications exposées doivent être protégées par TLS et les secrets doivent être stockés dans un mécanisme adapté. |
Conformité FHIR |
Les ressources ou services générés par HAPI FHIR doivent respecter les profils, mappings et règles définis par la gouvernance. |
8. Données, stockage et sauvegarde
PostgreSQL apparaît dans plusieurs zones du schéma. Cela indique que l’infrastructure peut s’appuyer sur des bases relationnelles à différents niveaux : conservation des données sources, persistance de l’instance HAPI FHIR, stockage applicatif lié aux plateformes de visualisation ou gestion de données nécessaires aux services métier.
La stratégie de sauvegarde doit couvrir les bases PostgreSQL, les configurations des services, les certificats, les secrets techniques, les journaux critiques et les éléments nécessaires à la reprise de service. La restauration doit être testée régulièrement afin d’éviter une sauvegarde théorique mais inexploitable.
9. Exploitation, supervision et maintenance
L’exploitation doit permettre de surveiller la disponibilité des composants, la qualité des échanges, les erreurs de normalisation, les latences entre services et les échecs de consultation depuis les plateformes de visualisation. Les journaux de l’API Gateway, de HAPI FHIR, du serveur de sécurité et de X-Road constituent des sources essentielles pour diagnostiquer les incidents.
Zone à surveiller |
Indicateurs utiles |
Objectif |
|---|---|---|
API Gateway |
Taux d’erreur, temps de réponse, volume d’appels, appels rejetés |
Identifier les problèmes d’accès, de routage ou de surcharge. |
HAPI FHIR |
Erreurs de validation, ressources créées, requêtes FHIR, latence |
Mesurer la qualité de la normalisation et la disponibilité des services FHIR. |
Serveur de sécurité |
Requêtes autorisées ou refusées, certificats, erreurs de contrôle |
Garantir la protection et la gouvernance des échanges. |
X-Road |
Disponibilité des services, erreurs d’échange, journaux de consommation |
Contrôler la publication et la consommation des services interopérables. |
Visualisation |
Échecs de requêtes, fraîcheur des données, disponibilité des tableaux de bord |
Garantir la restitution fiable des informations aux utilisateurs métier. |
10. Points d’attention et recommandations
10.1 Formaliser les contrats d’échange
Les relations entre les systèmes sources, l’API Gateway, HAPI FHIR, le serveur de sécurité, X-Road et les plateformes de visualisation doivent être décrites par des contrats d’API ou des spécifications techniques. Ces contrats doivent préciser les formats, les méthodes, les paramètres, les codes d’erreur, les règles d’authentification et les responsabilités de chaque composant.
10.2 Définir les mappings vers FHIR
Les données issues de CommCare HQ et des outils environnementaux doivent être associées aux ressources FHIR attendues. Cette étape doit être documentée dans une matrice de mapping afin de relier chaque champ source à son équivalent cible, tout en précisant les transformations, validations et règles de conformité.
10.3 Clarifier les échanges bidirectionnels
Les échanges entre HAPI FHIR, le serveur de sécurité, X-Road et la couche de visualisation doivent être explicitement décrits comme des échanges bidirectionnels. Cette précision évite de considérer la couche de visualisation comme un simple récepteur passif et confirme son rôle de consommateur actif de services.
10.4 Prévoir un environnement de test
Un environnement de test doit reproduire la chaîne complète, depuis les systèmes sources jusqu’aux plateformes de visualisation. Il doit permettre de valider les flux de données brutes, la normalisation FHIR, les échanges sécurisés, la conformité aux règles UGD et la restitution dans DHIS2 ou dans les autres plateformes.
10.5 Mettre en place une gouvernance de sécurité
Les certificats, comptes de service, clés API, règles de pare feu, secrets techniques et droits d’accès doivent être inventoriés. Toute modification de configuration doit être tracée, validée et documentée afin de préserver la cohérence de l’infrastructure.
11. Annexes
11.1 Diagramme textuel simplifié
CommCare HQ / Outils environnementaux
|
v
API Gateway -> HAPI FHIR
<-> Serveur de sécurité
<-> X-Road
<-> DHIS2 / Autres plateformes de visualisation
11.2 Schéma de référence mis à jour
Le schéma ci-dessous constitue la référence visuelle de cette version de la documentation. Il intègre les légendes des flux et la représentation bidirectionnelle des échanges sécurisés entre les briques centrales.
Figure 1 : Architecture iTAFARAY mise à jour avec légendes des flux.