I want to build a tracker based on the form below and Iam wondering if you could help me meet the logic in 1, 2 and 3 in relation to program stages and validation.
CHWs visit patients for follow up visits and tracing in the community.
If, on the first visit, the chw finds the patient, they tick the positive prevention package they have talked about with the patient and schedules the next visit. There will seven (7) visits and in each of them the chw will talk about the packages (pp1, pp2, pp3, pp4, pp5, pp6 and pp7).
If the patient is not found, the chw ticks the reason for not finding them. If the patient has died or has not been found in three search/tracing visits, the chw must close the case.
If the patient is found in each of the three tracing visits, then he/she will receive seven visits and seven prevention packages as described in point 1
Hello @hernandezmachava
There are always many ways of doing the same thing, however, from my experience it all turned down to how you want to show the analytics in DHIS2.
If you are using an external tool to show analytics and dashboard then you have the total freedom to design the tracker based program without any restrictions.
The biggest restriction i face these days is cross-stage analytics; so in your case, if you need this, you might want to do 1 stage instead of 2 as I’m suggesting bellow:
(I’m happy to discuss it more and looking forward to hearing others)
The way I see it is that you need:
-A tracked Entity with attributes:
-NID
-Name
-Phone Number
-A Program called “Positive Prevention” with 2 stages
-a stage called “Tracing Visit” (repeatable) with fields:
-“was patient found”
-“reason for visit”
-“reason for failed visit”
-a stage called “CHW Package”(repeatable) with 1 field called “package type” which is a drop down menu
This way if the patient is not found the chw will only fill 1"tracing visit" stage per failed visit; if found they need to additionally fill the “chw package” stage per each package delivered
This will definitely mean the CHWs are trained well before it.
One thing to notice is that it is better to enter the traced entity data in the system while having Internet before going on a visit in order to make sure of no duplicates.
You have provided valuable input into this use case. I didn’t know where to start. I am not using an external tool to show analytics. Iam using DHIS 2 analytics App.
Two more questions:
A) If a patient was not found because he died, the enrollment must be closed/hidden, i.e, the chw should not allowed to enter data for this patient. Is it possible to configure this in DHIS 2?
B) If a patient was not found after three visits, the chw should not be allowed to enter data for this patient either. Is there a way to have a counter for the repeatable stage so that the chw is forced to close the enrollment if he/she has reached the number of visits?
NB: the CHW must be prompted to close the whole enrolment and not allow them to accidentally enter more data if the number of visits has been reached.
Hello @hernandezmachava
Q A: if you are using multiple stages, i am afraid it is not possible except with the help of a webdeveloper/frontender that could write some javascripts (but i haven’t tried this solution and i’m not 100% sure it will work) ; if you are using only one stage, you can set program rules based on data/attributes values that could hide or show certain sections in the same stage.
Q B: some parts of this could be done by the webdeveloper (not 100% sure)
in both cases, whatever you do externally via javascripts won’t be available in the android app.
The CHW package program stage is hidden only if untick auto-generate checkbox. Any reasons behind that?
From your experience, is it possible to automatically disable an enrollment if reason for failed visit is death? Because if a patient has died, it is no longer necessary to enter data for this person in particular. This way we ensure that the user won’t enter data anymore,
Something manual has to be done. So in order to signal death it has to be done afterwards which is only after you have enrolled the person.
I suggest not to enroll the person if they are dead.
If you need to do so then once signalled dead, you will need to manually unenroll them.
As for the autogenerate it is normal because the system will automatically create the stage or the id for it.
No u won’t but then maybe you shouldn’t delete the enrollment.
Maybe you can put the dead field in the stage and hide the rest of the stage if dead is true.
