View Source

note

Acronymes

H2 - HNQIS version 2.0 et plus récente

OU - Organisational Unit (unité organisationnelle)

PCA - Program Configuration App

TEI - Tracked Entity Instance (Instance d'entité suivie)

TEA - Attribut d'entité suivie

Pour une liste complète de tous les acronymes et mots, cliquez sur /wiki/spaces/documentation/pages/14024762

Acronymes

H2 - HNQIS version 2.0 et plus récente

OU - Organisational Unit (unité organisationnelle)

PCA - Program Configuration App

TEI - Tracked Entity Instance (Instance d'entité suivie)

TEA - Attribut d'entité suivie

Pour une liste complète de tous les acronymes et mots, cliquez sur ici

H2 a été configuré pour utiliser le modèle de données de suivi DHIS2.

H2 peut être utilisé soit sur l'application de capture du traceur DHIS2, soit avec l'application Android standard DHIS2, contrairement à H1, qui nécessite l'utilisation d'une application Android personnalisée.

En option, l'accès à la fonctionnalité de retour d'information est disponible en utilisant l'application androïde PSI's fork. (liens, liens, liens)

Modèle et options des données de suivi du DHIS2

Une évaluation est constituée de plusieurs types d'événements (étapes du programme DHIS2).

L'évaluation proprement dite (une étape qui ne peut être répétée), qui contient toutes les questions (il peut y en avoir des centaines).
Actions (une étape répétable). Chaque entrée est une action corrective qui est convenue après la supervision.
la phase du programme de retour d'information, sous la forme d'"événements gérés".. Cette fonctionnalité n'existe pas encore, mais elle est prévue par UiO. Elle pourrait donner lieu à de nombreuses entrées, une par question échouée.

Unité d'Org Travail : Établissements et prestataires

Lorsqu'un programme H2 est créé, il existe différents niveaux auxquels vous pouvez l'activer à l'aide de la fonction d'affectation des unités d'organisation du programme.

La plupart des serveurs DHIS2 ont déjà des structures d'unités organisationnelles dont le niveau le plus bas est celui de l'établissement.

Seuls quelques pays utilisent un niveau ultérieur pour enregistrer le prestataire de soins réel, par son nom, ce qui permet l'enregistrement et l'analyse de données spécifiques à la performance de l'agent de santé.

Nous présentons ci-dessous les différentes façons dont vous pouvez effectuer la mission de l'unité Org des listes d'évaluation H2, avec les avantages et les inconvénients.

Option 1 : Le fournisseur est l'OU (recommandé)

Infranational (OU)
- Installation (OU)
  - Fournisseur (OU) --> Affectation de l'OU du programme
    - Cycle d'évaluation (TEI) : Début/fin, données de notation
      - Retour d'information (événements gérés - futurs)
      - Actions (événement répétable)

Avantages

UX : chaque TEI est une évaluation unique, avec l'ensemble d'actions et de retours d'information requis.
Compatible avec l'avenir d'UiO événements gérés la conception de la fonctionnalité de retour d'information - chaque question échouée crée un événement géré, ce qui se traduit par des entrées multiples.
Permet d'assigner des listes de contrôle spécifiques à chaque fournisseur (comme s'il s'agissait d'une OU).
Analyse : en plein essor, au niveau des fournisseurs

Inconvénients

Pour que l'évaluation puisse avoir lieu, il faut que le fournisseur soit défini comme une unité d'org.

Option 2 : l'établissement est l'OU / le prestataire est l'AET

Il s'agit d'une variante de l'option 1, qui introduit l'utilisation d'une AET permettant d'enregistrer le nom du prestataire (texte libre).

NotePour cette option, vous devrez modifier les paquets de métadonnées fournis par l'ISP. Vous devrez créer un nouveau TEA pour le fournisseur et l'ajouter à l'évaluation TEI.

Infranational (OU)
- Installation (OU) --> Affectation de l'OU du programme
  - Cycle d'évaluation (TEI) : Début/fin, données de notation.
    THÉ : PRESTATAIRE
    - Évaluation (événements uniques)
    - Retour d'information (événements gérés - à l'avenir, il pourrait y en avoir des centaines)
    - Actions (événement répétable - 1 à 5 par évaluation)

Avantages

Il est rare qu'une liste complète de prestataires soit disponible à l'avance pour la mise en place des UO. L'utilisation de la TEA permet d'enregistrer le nom du prestataire au moment de l'évaluation.

Inconvénients

Les analyses ne peuvent être générées que par l'établissement, et NON par le prestataire (le prestataire n'affiche que des analyses de listes de lignes).
Le partage du retour d'information se fait au niveau de l'unité organique, et non au niveau du prestataire.

Option 3 : l'établissement est l'OU / le fournisseur est l'ITE

L'idée est d'"inscrire" un prestataire en tant qu'entité suivie, puis d'effectuer toutes les évaluations dans cette entité suivie.

NotePour cette option, vous devrez modifier les paquets de métadonnées fournis par PSI. Vous devrez créer un nouveau type d'entité suivie et modifier l'ACP.

Infranational (OU)
- Facility (OU) --> Program OU Assignment
  - Fournisseur (TEI)
    - Évaluation (événement répétable, un par évaluation)
    - Retour d'information (événements gérés - à l'avenir. Il pourrait y en avoir des centaines)
    - Actions (événement répétable - 1 à 5 par évaluation)

Avantages

Il est rare qu'une liste complète de prestataires soit disponible à l'avance pour être mise en place en tant qu'OU. L'utilisation de l'ITE pour inscrire un prestataire pendant la visite est plus réaliste pour la mise en œuvre sur le terrain.

Inconvénients:

Mélange d'évaluations/actions et d'événements de retour d'information (événements gérés pour le retour d'information)
Le retour d'information actuel sur la fourche ne fonctionne pas
Le retour d'information futur (événements gérés) sera une longue liste, difficile à visualiser.
Non compatible avec l'ACP de PSI.

Option 4 : le prestataire est l'IET, l'évaluation est l'inscription

Non pris en compte - l'analyse n'est pas possible : nous ne pouvons pas utiliser les inscriptions comme DHIS2 avec la version actuelle (2.38) qui n'a pas d'analyse des inscriptions.