dhis2-devs team mailing list archive

[Sean Broomhead <sean@xxxxxxxx>]

Hello All - this is a key use case for HIV data and will be for many other
health programmes too. I will be happy to be part of these discussions and
draw in some more of our public health experts as needed.

Best regards,
Sean

On Tue, Jun 13, 2017 at 11:45 AM, Georgi Chakarov <
georgi@xxxxxxxxxxxxxxxxxxx> wrote:

> Thanks Knut!
>
>
>
> I haven’t yet heard from the community. Looking forward to, though! I
> believe there must be someone out there working with HIV programs that
> needs to protect personal client data. Anyone?
>
>
>
> Thanks,
>
>
>
> Georgi
>
>
>
> *From:* Knut Staring [mailto:knutst@xxxxxxxxx]
> *Sent:* Monday, June 12, 2017 2:25 PM
> *To:* Georgi Chakarov <georgi@xxxxxxxxxxxxxxxxxxx>
> *Cc:* DHIS 2 Developers list <dhis2-devs@xxxxxxxxxxxxxxxxxxx>; DHIS Users
> <dhis2-users@xxxxxxxxxxxxxxxxxxx>
> *Subject:* Re: [Dhis2-users] HELP NEEDED: DHIS2 design issue
>
>
>
> 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 <
> georgi@xxxxxxxxxxxxxxxxxxx> 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 | georgi@xxxxxxxxxxxxxxxxxxx | +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 *
> *info@xxxxxxxxxxxxxxxxxxx* <info@xxxxxxxxxxxxxxxxxxx>
>
>
>
>
> _______________________________________________
> 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
>
>
>
>
>
> --
>
> Knut Staring
>
> Dept. of Informatics, University of Oslo
>
> Norway: +4791880522 <+47%20918%2080%20522>
>
> Skype: knutstar
>
> http://dhis2.org
>
> _______________________________________________
> 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
>
>


-- 
Dr Sean Broomhead
Director ICT
HISP-SA
+27 79 496 1993
Skype: getsean

-- 


*This message and any attachments are subject to a disclaimer published at 
http://www.hisp.org/policies.html#comms_disclaimer 
<http://www.hisp.org/policies.html#comms_disclaimer>.  Please read the 
disclaimer before opening any attachment or taking any other action in 
terms of this electronic transmission.  If you cannot access the 
disclaimer, kindly send an email to disclaimer@xxxxxxxx 
<disclaimer@xxxxxxxx> and a copy will be provided to you. By replying to 
this e-mail or opening any attachment you agree to be bound by the 
provisions of the disclaimer.*