PeekIQAnalyse DHIS2Blueprint produit
Analyse opérationnelle

Ce qu'il faut retenir de DHIS2 pour concevoir une plateforme de collecte en santé publique

Construire une alternative plus lisible à DHIS2, sans perdre sa puissance métier.

La décision structurante est simple: un formulaire mensuel agrégé et une fiche de consultation médicale ne relèvent pas du même moteur. DHIS2 l'illustre déjà. L'app PeekIQ doit donc partir d'un noyau metadata-first, puis exposer deux expériences de collecte distinctes, un moteur d'indicateurs explicite, une hiérarchie géographique gouvernée et des droits combinant rôle, périmètre et partage.

Copier les concepts DHIS2, pas son ergonomie historique.
Séparer clairement agrégé et événementiel dès la modélisation.
Traiter l'arbre géographique comme une dépendance critique du produit.
Rendre les formules et les droits auditables par défaut.

Lecture de DHIS2

Quatre briques à reprendre proprement

La valeur du produit viendra de la clarté de ces fondations, pas d'une accumulation de menus d'administration.

Collecte

DHIS2 sépare déjà deux familles de formulaires

Pour l'agrégé, le modèle tourne autour des Data Elements, Data Sets, Sections et Category Combos. Pour une fiche de consultation médicale individuelle, la logique DHIS2 bascule vers Tracker, Event et Program Stage.

  • Un champ métier doit rester un objet réutilisable, versionné et documenté.
  • Un formulaire agrégé sert surtout aux remontées périodiques et aux validations par lot.
  • Une consultation clinique demande un flux orienté événement ou dossier, pas une simple grille mensuelle.

Indicateurs

Le calcul est un moteur métier, pas un widget

DHIS2 traite les indicateurs comme des métadonnées calculées. La logique standard combine numérateur, dénominateur, facteur et type d'indicateur; côté Tracker, on retrouve les Program Indicators.

  • Le produit doit exposer un builder guidé et une représentation exécutable de formule.
  • Les indicateurs doivent pouvoir cibler l'agrégé, l'événementiel ou les deux.
  • Le recalcul doit être asynchrone et traçable pour éviter des dashboards incohérents.

Territoire

La hiérarchie géographique structure tout

L'Organisation Unit tree n'est pas seulement un annuaire. Il porte l'affectation des utilisateurs, la saisie, le reporting, l'agrégation et les filtres analytiques.

  • Le modèle doit gérer pays, région, district et centre de santé comme un arbre administré.
  • Chaque nœud doit pouvoir avoir un code, un type, un parent et une période de validité.
  • Les changements de découpage territorial doivent être prévus dès le départ.

Accès

Les droits combinent rôle, périmètre et partage

DHIS2 combine authorities, user roles, user groups et partage d'objet. Reproduire uniquement du RBAC classique serait trop court pour un produit de santé publique.

  • Un droit fonctionnel n'est pas suffisant sans rattachement organisationnel.
  • Les formulaires, indicateurs et jeux de données doivent aussi supporter des règles de partage ciblées.
  • L'audit des actions administratives doit être natif.

Architecture cible

Ce qu'il faut réellement construire

Studio de formulaires

Un back-office pour composer des formulaires de collecte à partir d'objets métiers réutilisables.

  • Bibliothèque de champs: texte, nombre, date, liste, booléen, catégorie, pièce jointe.
  • Deux modes de sortie: formulaire agrégé périodique et fiche événementielle de consultation.
  • Règles de validation, sections, masquage conditionnel et versioning de formulaire.

Laboratoire d'indicateurs

Une couche de définition analytique où les indicateurs sont indépendants de l'interface de saisie.

  • Builder numérateur / dénominateur / facteur avec aperçu de formule.
  • Dimensions standard: période, organisation, sexe, âge, vaccin, statut.
  • Planification de recalcul et stockage des résultats pour tableaux de bord rapides.

Administration géographique

Une console dédiée à la hiérarchie pays → région → district → centre de santé.

  • Arbre éditable avec import CSV, validation des doublons et codes uniques.
  • Types d'unités d'organisation et rattachement aux jeux de données ou programmes.
  • Historique des fermetures, fusions et changements de périmètre.

IAM + gouvernance

Un modèle d'accès en trois couches pour éviter les droits implicites et opaques.

  • Rôles métier pour les authorities globales.
  • Portée organisationnelle pour limiter la zone d'action d'un utilisateur.
  • Partage d'objet pour déléguer un formulaire, un indicateur ou un programme à un groupe précis.

Ligne directrice

Produit à deux vitesses

Agrégé

Rapports périodiques, campagnes, supervision.

Builder proche d'un Data Set, avec sections, périodes, règles de validation et ventilation par catégories.

Événementiel

Consultation médicale, patient, suivi individuel.

Flux de saisie proche d'un Program Stage ou d'un Event, avec chronologie clinique et validations contextuelles.

Feuille de route

Séquence conseillée

Phase 1

Noyau metadata-first

Créer les entités de base: champs, catégories, formulaires, unités d'organisation, rôles, groupes et journal d'audit.

Phase 2

Collecte agrégée + calcul batch

Livrer les formulaires périodiques, les validations, le moteur d'indicateurs agrégés et les premiers tableaux de bord nationaux.

Phase 3

Consultation médicale événementielle

Ajouter les formulaires de consultation de type événement avec historique patient minimal, équivalents de Program Stages et indicateurs cliniques.

Phase 4

Partage avancé et administration distribuée

Introduire la délégation par groupe, les droits d'objet fins et l'administration régionale sans ouvrir tout le pays.