Event data transfer between Org Units

Hello DHIS2 team,

We would like to know more about event data transfer across org units. Case: We have a Tracker Program with a tracked entity “Teacher”. The enrollment hold attributes for the Teacher and the subsequent events hold information about teacher training and other activities. The Org Units for capturing this information are “Schools”. Our questions are: What happens in DHIS2 when a Teacher changes the school? How are these event/data items transferred from one Otg Unit to another?

Kind regards,



It’s an interesting use case, because it breaks with the scenario assumed with current tracker design.

Firstly, note that you CAN move/transfer TEIs temporarily or permanently to another orgunit - you do this by clicking the curved arrow icon on the Tracker Dashboard. Doing so will also “force” you to open another event (which you subsequently can delete without capturing any data).

Secondly, NOTE that a permanent transfer - which I presume is what you are mostly interested in - will move the Teacher to another school BUT all existing events will remain linked to the previous school. Only new events generated after the permanent transfer will be linked to the new school.

Thirdly, it is important to understand that the transfer functionality is predicated on a rather narrow use case scenario: that of the TEI being a patient that temporarily or permanently is referred to, or prefers to shift too, another health facility. With that relatively narrow (but in health terms common) scenario, any previous events will normally be a health service provided and it thus “naturally” belong with the health facility providing it and not with the patient’s “new” facility. Or to say it differently: The current Tracker Design is 80-90% determined by the perspectives and “systems view” emanating from the Palestinian Mother & Child instance, which has been driving a lot of development (the Tracker team leader and Deputy Team leader have both been heavily involved in that project).

Fourthly, in your use case - and other similar use cases - the events are only indirectly linked to the orgunit in the sense that a school can benefit from a teacher’s training and skills, but obtaining said training and skills will typically be independent of any specific school. Or in other words, the data in those events are in reality a form of “extended” Tracked Entity Attributes and primarily linked to the teacher and not the school. So ideally you want to move the teacher AND all her/his training etc to the new school.

This is very similar to use cases where the TEI is a health worker - most skills, training, etc are then also not on-the-job but a result of continuous education, courses, and the like. There MIGHT be countries where courses and distance education etc are paid for by the health facility - and thus you want such events to remain with that facility so that they can report on them and link those events to their expenditure - but I think those are exceptions: in most cases health workers will be funding courses and education etc from other sources. Which means they are in the same position as teachers - all the events “belong” with the worker and not the workplace.

Fifthly, I recognised the limitations of the current transfer approach some time back also in relation to cases where e.g. data capturers by mistake capture cases under the wrong orgunit (happens regularly), or capture events under the wrong orgunit (VERY easy to do because of the way the search function has been designed, it will open any case found even if the currently “active” orgunit is another orgunit, and then enable the user to capture new events under that other orgunit) - and wrote two JIRA issues for it:
DHIS2-5951 (permanent transfer of TEI with all enrollments/events)
DHIS2-5952 (opening cases from search causes incorrect event capturing).

Nothing has happened with these two issues (but I discussed it with Markus and he agrees in principle). So please add your use case to the above and vote for it etc.

In the meantime, you CAN use the permanent transfer functionality - cumbersome as it is - to move teachers from school A to School B, which in reality means that the “organisationunit” field in the table “programinstance” will be updated. There must be some “available” stage for you to add, but you can immediately delete that again after the transfer.

In order to ensure that all existing events belonging to that teacher is also moved, you can set up the following script as a daily script:

Daily Script: Fixing TEIs with differing event orgunits:

UPDATE programstageinstance psi
SET organisationunitid = pi.organisationunitid
FROM programinstance pi
WHERE pi.programinstanceid=psi.programinstanceid AND psi.organisationunitid <> pi.organisationunitid;

The script will ensure that all events are linked to the same orgunit as the main enrollment (= TEI in your case).

Best regards


Thank you Calle for your great response! I will digest and see if these steps work in our case. Will get back to you!

Kind regards,

1 Like


It might be easier to think of continuous education & training + skills (certificates; professional memberships; experience scores; manager assessments; conference participation; etc etc) as in reality a sort of “profile stages”. They all form part of the “profile” that in the DHIS2 system perspective are what we would normally capture during enrollment as Tracked Entity Attribute values. But in the case of HR profiles (whether teachers or health workers) you start out with one basic profile after being licensed as a health worker or teacher, then add to it over your 30-40 year work life in a range of ways.

You CAN of course create a horribly long list of TEAs that covers all dates, levels, content and achievements related to such skills development and then fill in attributes bit by bit - what we in DBMS terms would call a non-normalised data set - but it would be extremely unwieldy to do so (there are literally hundreds if not thousands of options and courses for continuous education).

So you end up panel-beating those round skills developments into the square (repeatable) stage event holes instead.

I am definitely interested in info about the model you end up with.

Just note that in South Africa, we’ve had major challenges using Tracker as a platform for special types of health workers and will be using a different, multi-information-system approach for the health sector HR Registry


1 Like