HNQIS 2 (H2) has been redeveloped using configured to use the DHIS2 tracker data model, and uses . H2 can be used either on the DHIS2 tracker capture app, or in DHIS2 standard Android app, . This is in contrast to H1, which required the use of a custom Android App. Additionally, H2 can now use either the web-based tracker capture app or the standard DHIS2 android app. Optionally, a for of DHIS2 android app add functionality for providing the feedback functionality.
...
Optionally, access to the feedback functionality is available by using a PSI’s fork android app. (links, links, links)
Rational for the use of DHIS2 tracker data model
...
Doesn’t use event - why?
details of the model
Org Units: Facilities vs Providers
& options
An assessment is forms by multiple type of event (DHIS2 Program Stages)
The actual assessment (A not-repeatable stage), which contain all the questions (could be hundreds)
Action items (a repeatable stage). Each entry is a corrective action that it is agreed after the supervision
Feedback program stage, on the form of managed events. This feature doesn’t exist yet, but it is planned by UiO. It could result in many entries, one per failed question.
Org Units assignment: Facilities vs Providers
When a H2 Program is created, there are different levels at which you can enable it using the Program Org Unit assignment feature. Most DHIS2 server already have their Org Unit structures defined to with the facility level as their lowest level. Only some used use a further subsequent level to register the actual provider (the health health provider, by name, allowing the recording and analysis of data specific to the health officer performance.
We present below the different ways that you can do the Org Unit assignment of H2 assessment lists, and their pros and cons.
Option 1: Provider as the OU (
...
recommended)
Sub-National (OU)
|__ Facility (OU)
|__ Provider (OU) --> Program OU assignment
|__ Assessment Cycle (TEI): Start/ End, Scoring data.
|__ Feedback (Managed events - future)
|__ Actions (Repeatable event)
...
This is a variation of Option 1, which introduces the use of a TEA (Tracked Entity Attribute) that allows to record the provider name (free text).
Note: you will need to modify PSI’s provided metadata packages for this option. You will need to create a new TEA for provider, and add it to the TEI assessment.
Sub-National (OU)
|__ Facility (OU) --> Program OU assignment
|__ Assessment Cycle (TEI): Start/ End, Scoring data.
TEA: PROVIDER
|__ Assessment (single events)
|__ Feedback (Managed events - future. Could be 100s)
|__ Actions (Repeatable event - 1 to 5 per assessment
...
It is rare to have a full list of providers available in advance to set up as OUs. Using TEI to enrol a provider during the visit is more realistic for on-the-ground implementationTEA allows to record the provider name at the time of the assessment.
Disadvantages
Analytics can only be generated by facility, NOT by provider (provider shows only at on line-listing levelanalytics)
FEEDBACK Feedback sharing is at the Org Unit level, not at the provider level.
Option 3: Facility as the OU / Provider as TEI
...
The idea is to ‘enrol’ a provider as a tracked entity, and then conduct all assessments in that Tracked Entity.
Note: you will need to modify PSI’s provided metadata packages for this option. You will need to create a new type of Tracked Entity, and change the PCA.
Sub-National (OU)
|__ Facility (OU) --> Program OU assignment
|__ Provider (TEI)
|__ Assessment (Repeatable event, one per assessment)
|__ Feedback (Managed events - future. Could be 100s)
|__ Actions (Repeatable event - 1 to 5 per assessment
NOTE: we cannot use enrolments as DHIS2 doesn’t yet (2.38) has enrolment analytics.
Main advantages
It is rare to have a full list of providers available in advance to set up as OUs. Using TEI to enrol a provider during the visit is more realistic for on-the-ground implementation.
...
Mixes assessment/ actions and feedback events (manged managed events for feedback)
Current fork feedback will not work
Future feedback (managed events) will be a long list, difficult to visualise.
Not compatible with PSI’s PCA.
Option 4: Provider as TEI, Assessment as Enrolment
Discarded - analytics are not possible: we cannot use enrolments as DHIS2 doesn’t yet (2.38) has enrolment analytics.