Thanks for the request Georgi, How to set up and maintain such complex access schemes is still exceedingly tricky, and I think guidance and probably improved user interfaces to handle this is one of the key areas that needs strengthening. There should probably be a task force set up around it - unfortunately that is not likely to happen right now that the summer holidays are approaching, so hopefully experienced members of the community will be able to chip in with tips. I hope this will be a lively thread.
Knut On Mon, Jun 12, 2017 at 1:01 PM, Georgi Chakarov <geo...@logicaloutcomes.net > wrote: > Hi DHIS 2 community! > > > > We have the following case and your advice will be highly appreciated! > > We have a client that works with vulnerable children and vulnerable > adults. Our client has 6 (six) partners that provide a long list of > services based on the needs of the beneficiaries. Among these services are > HIV testing, HIV status determination and HIV related service. Each partner > needs to protect HIV information for its beneficiaries from the other > partners. > > Here are a few requirements, posed by our client: > > 1) All partners use the same tool for capturing data (we have > configured tracker capture program to register beneficiaries and track > service provision) > > 2) Partners are able to see each other’s data, EXCEPT FOR HIV > related data > > 3) There is this one partner whose data should not be seen by > anybody else (this partner can see other partners’ data, though) > > 4) There are area overlaps, meaning that partners might work in the > same village, e.g. > > We have a design problem, in which we cannot figure out how to enable all > partners to use the same tracker program, but at the same time to satisfy > the requirements above. This is what we have tried so far: > > A) Data element sharing. We tried to share HIV data elements with a > few partners only, to test whether the rest of the partners can see those > data elements in data entry. Yes, they were able to see them, so this > option would not work for us. Sharing data elements determines what users > will see in reports, not in data entry. > > B) We tried creating Attribute categories and sharing them, with > selected partners. This didn’t work for the same reason as above. Sharing > restricts access in reporting but not in data entry. > > C) We can create six different tracker programs for each partner, > but we have so many program indicators to build for reporting that 6 > separate programs will increase our work by 6. It will also be hard to our > client to manage 6 programs for a number of reasons. > > Our question is: Does anyone have an idea how to design our system so that > we enable partners to work on the same tracker program, but be able to > see/enter data pertaining only to them? > > > > Thanks in advance for your time and attention! > > > > Regards, > > > > Georgi > > > > > > > Georgi Chakarov, CIA | geo...@logicaloutcomes.net | +1-647-478-5634 x 104 > <(647)%20478-5634> | LogicalOutcomes c/o Centre for Social Innovation, > 720 Bathurst Street, Toronto Canada M5S 2R4 | *You may unsubscribe from > receiving commercial electronic messages from LogicalOutcomes by emailing * > *i...@logicaloutcomes.net* <i...@logicaloutcomes.net> > > > > _______________________________________________ > 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 > > -- Knut Staring Dept. of Informatics, University of Oslo Norway: +4791880522 Skype: knutstar http://dhis2.org
_______________________________________________ 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