Its an interesting problem. I know the Ghana Health Service has gone through this pain recently enough with substantial district boundary reorganisation. They might want to comment on their experience to date.
One observation worth making is that it is more rare for health facilities (points) to come and go as it is with administrative layers (polygons). So after you have gone through one of those dreaded boundary reshuffles and the dust has settled, usually the facilities are still there but shuffled under new parents. In general it is probably more useful when comparing current with historical trends for example, to be able to generate the analytics tables for the past *as if they existed within the boundaries of the present*. So if 2 districts have become 3 in 2013, it is hard to find a sensible way to look at the current district level data in relation to past performance unless you imagine those districts also existed back then. In terms of rolling back the time machine (and the above exercise could also be done in reverse - how are we doing now on the basis of last years boundaries?) I agree there is not a perfect solution. My own inclination (and Alvin I've briefly discussed this with you) would be to archive the xml metadata in an xml database periodically and also before cataclysmic changes. This way it would be relatively trivial to recall versioned snapshots of, for example, orgunit metadata and import and apply them to current data. We do (I hope we do) routine and automated backups as a matter of course. Perhaps including a metadata snapshot as part of that scheduled job (curl to the /aip/metaData endpoint) piped into an xml database is a useful addition to the general db backup. Caveat: this is completely speculative and I haven't done this anywhere. Bob On 14 October 2013 20:49, Alvin Marcelo <alvin.marc...@gmail.com> wrote: > Hi Paulo, > > We have the same challenges in the Philippines. Once a year (or sometimes > more often), villages will disappear or merge or both. > > To this, there is still no "official solution" although some agencies (not > the one responsible for the disappearances and mergings) have come up with > their own temporary fixes. > > One such solution is to maintain a time-stamped version of the org units. > And creating a separate table (almost like a data warehouse) using UIDs > hashed from the timestamps and the village_ids. > > I believe this solution is far from perfect but we make do with what we > can. Can DHIS2 retain these org unit changes in memory? > > alvin > > > > > On Tue, Oct 15, 2013 at 3:29 AM, Paulo Grácio < > pgra...@criticalsoftware.com> wrote: > >> Hi all,**** >> >> ** ** >> >> Imagine that you have a National Implementation of DHIS2 using 4 levels >> hierarchy Country > Province > District > Health Unit. Suddenly, the law >> changes, and you have to reorganize all the structure, new provinces, new >> districts and some Health Units need to be moved from one District into >> another.**** >> >> ** ** >> >> Create, delete and Updated OU is not a problem, as well as move Health >> Units from one District to another. The problem is how keep Analytics >> history? Is it possible somehow?**** >> >> ** ** >> >> Regards,**** >> >> *Paulo Grácio <*%20your-email%20*>* >> *Technical Manager* >> (+258) 822 544 603 **** >> >> Skype: paulojrgracio**** >> >> *Critical Software Mozambique* <http://www.criticalsoftware.co.uk/> >> *Dependable Technologies for Critical Systems***** >> >> Critical Software Mozambique is a subsidiary of Critical Software, a >> CMMI® Level 5 rated Company <http://cmmiinstitute.com/> >> CMMI® is registered in the USPTO by CMU <http://www.cmu.edu/>**** >> >> Rua Pereira Marinho, 179 >> Bairro de Sommerchield >> Maputo >> Moçambique >> Phone: (+258) 214 951 45 >> Fax: (+258) 214 951 46**** >> >> DISCLAIMER: This message is confidential and may contain privileged >> information. It is for use only by the people or entities to whom it is >> addressed. If you are not an intended recipient, you should not disclose, >> distribute, copy, print, rely on or otherwise make use of this message. If >> an addressing or transmission error has misdirected it to you we would be >> grateful if you would please notify the sender by return, before deleting >> it from your system.**** >> >> ** ** >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~dhis2-users >> Post to : dhis2-us...@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~dhis2-users >> More help : https://help.launchpad.net/ListHelp >> >> > > _______________________________________________ > Mailing list: https://launchpad.net/~dhis2-devs > Post to : dhis2-devs@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dhis2-devs > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
