dhis2-devs team mailing list archive

[Harsh Atal <harsh.atal@xxxxxxxxx>]

One issue that is there with making the user able to see the TEI data at
any orgunit is of confidentiality. Because with this approach the user at
district1 (which let's say handles TB programs) can see the TEIs at
district2(which handles HIV data).This can be a big issue with private data
like that of HIV or name based data in general. Even when facilities are
not categorized based on the programs they offer , still , giving the user
the power to see any TEI data at any org unit is a bit risky.

We are facing a similar requirement as above, that is why we wanted to
change location of the TEI.I understand that doing that will result in loss
of data. But I am not sure how else to fulfill this requirement(perhaps we
have to maintain location history as well)Do you have any idea on how we
can we tackle this issue?

Thank You

On 4 March 2015 at 16:46, Abyot Gizaw <abyota@xxxxxxxxx> wrote:

> 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
>>>>
>>>>
>>>
>>
>