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?
···
On 4 March 2015 at 16:46, Abyot Gizaw abyota@gmail.com 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@gmail.com 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.
harsh
Thank You
On 4 March 2015 at 14:24, Pierre Dane pierre@jembi.org 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@gmail.com 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.
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
Thank you,
Abyot.
On Wed, Mar 4, 2015 at 9:20 AM, Harsh Atal harsh.atal@gmail.com 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@gmail.com 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@gmail.com 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)
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
–
Morten
On Wed, Mar 4, 2015 at 3:04 PM, Harsh Atal harsh.atal@gmail.com 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp