dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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.marcelo@xxxxxxxxx> 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 <
> pgracio@xxxxxxxxxxxxxxxxxxxx> 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-users@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-users
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>