dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

I see your point.

But, the situation that you have referred a patient from orgunit A to
orgunit B does not change the fact that the patient was registered/enrolled
at orgunit A. By doing migration, we are destroying this information which
for me is wrong.

What we need to probably do is provide a feature for users to decide how to
see a list of patients. Currently, by default, you see those patients
registered under your orgunit - but of course you can go to advanced search
and see those patients from another orgunit.  It would be nice if users can
for example say
- show patients who are enrolled in my orgunit,
- show me patients who are diagnosed (have data recorded) in my orgunit
- ...

---
Thank you,
Abyot.

On Wed, Mar 4, 2015 at 11:51 AM, Harsh Atal <harsh.atal@xxxxxxxxx> wrote:

> By migration I meant the same feature as 'change location' in individual
> records. Now, as abyot said if it is possible to access a TEI at any org
> unit and enter data for any org unit then that is one way to do it but its
> not the same as 'change location' in individual records.
> The need for 'migration' came in case a TEI was referred to another
> orgunit. For eg: a patient diagnosed with HIV is referred to a OU  which
> handles the program for HIV, and now all the enrollment and data entry have
> to be done in that OU i.e. now the patient is in the jurisdiction of the
> user who handles the  OU for HIV based programs, in this case shouldn't
> that patient come under the TEI list of that org unit(in the home page).
> Even when we consider the possibility of having data entered for a TEI at
> any OU, still i feel that the 'change location' feature seems relevant.
>
>
> Thank You
> harsh
>
>
>
>
>
> On 4 March 2015 at 14:24, Pierre Dane <pierre@xxxxxxxxx> wrote:
>
>> I agree.
>> What we are doing is having a placeholder org unit for the TEI, and then
>> registering the events against the actual org unit. Then the event reports
>> and aggregations work against the event org unit .
>>
>> This makes it easy (possible!)  to look the TEI up as you will always
>> know the org unit (api TEI lookup requires know orgunit)
>>
>>
>> On Wed, Mar 4, 2015 at 10:45 AM, Abyot Gizaw <abyota@xxxxxxxxx> wrote:
>>
>>> Ok, you know what your needs are.
>>>
>>> Are you also going to migrate events? What will happen to already
>>> submitted/acted report? You need to carefully look into the migration
>>> requirement. I am strongly against the idea of migration. With migration,
>>> you will lose information. If it is possible to access a TEI and do data
>>> entry at orgunit which is not necessarily the same as the
>>> registration/enrollment orgunit, then I don't think we need migration.
>>>
>>> ---
>>> Thank you,
>>> Abyot.
>>>
>>> On Wed, Mar 4, 2015 at 9:20 AM, Harsh Atal <harsh.atal@xxxxxxxxx> wrote:
>>>
>>>> thanks morten  ,I thought it was a bug........
>>>>
>>>>
>>>> @abyot
>>>> I want to migrate the tracked entity instance into another organisation
>>>> unit. So when the next time i select the orgunit from which i migrated i
>>>> dont want to see the tracked instance there but instead it has to come up
>>>> in the new org unit. This is a functionality that we require for a project.
>>>>
>>>> On 4 March 2015 at 13:39, Abyot Gizaw <abyota@xxxxxxxxx> wrote:
>>>>
>>>>> Hi Harsh,
>>>>>
>>>>> Do you really want to migrate? Or you want to register data in another
>>>>> org unit?
>>>>>
>>>>> -----
>>>>> Thank you,
>>>>> Abyot.
>>>>>
>>>>> (sent from mobile)
>>>>> On Mar 4, 2015 9:07 AM, "Morten Olav Hansen" <mortenoh@xxxxxxxxx>
>>>>> wrote:
>>>>>
>>>>>> Hi Harsh
>>>>>>
>>>>>> You are not allowed to update the orgUnit pointer, this was supposed
>>>>>> to be the point of registration.. and was thought of as being read-only
>>>>>> after initial registration.
>>>>>>
>>>>>> That said, I'm 90% sure we are changing this for 2.19, we are having
>>>>>> discussion about that now (we would rather have the orgUnit pointer on the
>>>>>> enrollment)
>>>>>>
>>>>>> --
>>>>>> Morten
>>>>>>
>>>>>> On Wed, Mar 4, 2015 at 3:04 PM, Harsh Atal <harsh.atal@xxxxxxxxx>
>>>>>> wrote:
>>>>>>
>>>>>>> Dear All
>>>>>>>
>>>>>>> I am trying to shift a trackedentityinstance from one
>>>>>>> organisationunit to another. For this i tried to use the web API resource
>>>>>>> for the updation of trackedEntityInstance.
>>>>>>> This ,i have found, is not working for the organisationunit as it is
>>>>>>> not changed while the changes in other information like attributes etc are
>>>>>>> reflected.
>>>>>>>
>>>>>>> I am not getting any error and the web api response status is
>>>>>>> SUCCESS but the organisationunitid doesn't change in the
>>>>>>> trackedEntityInstance table in the db.
>>>>>>>
>>>>>>> Have you encountered such a problem?
>>>>>>>
>>>>>>> Thank You
>>>>>>> Harsh
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>