HELP NEEDED: DHIS2 design issue

Support - Assistance technique
1

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@logicaloutcomes.net | +1-647-478-5634 x 104 | 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@logicaloutcomes.net

2

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

  1.  Partners are able to see each other’s data, EXCEPT FOR HIV related data

  1.  There is this one partner whose data should not be seen by anybody else (this partner can see other partners’ data, though)

  1.  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@logicaloutcomes.net | +1-647-478-5634 x 104 | 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@logicaloutcomes.net

Mailing list: https://launchpad.net/~dhis2-users

Post to : dhis2-users@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

3

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

···

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

  1.  Partners are able to see each other’s data, EXCEPT FOR HIV related data

  1.  There is this one partner whose data should not be seen by anybody else (this partner can see other partners’ data, though)

  1.  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@logicaloutcomes.net | +1-647-478-5634 x 104 | 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@logicaloutcomes.net

Mailing list: https://launchpad.net/~dhis2-users

Post to : dhis2-users@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

4

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

This message and any attachments are subject to a disclaimer published at 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@hisp.org 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.

···

On Tue, Jun 13, 2017 at 11:45 AM, Georgi Chakarov georgi@logicaloutcomes.net 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@gmail.com]

Sent: Monday, June 12, 2017 2:25 PM

To: Georgi Chakarov georgi@logicaloutcomes.net

Cc: DHIS 2 Developers list dhis2-devs@lists.launchpad.net; DHIS Users dhis2-users@lists.launchpad.net

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

  1.  Partners are able to see each other’s data, EXCEPT FOR HIV related data

  1.  There is this one partner whose data should not be seen by anybody else (this partner can see other partners’ data, though)

  1.  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@logicaloutcomes.net | +1-647-478-5634 x 104 | 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@logicaloutcomes.net

Mailing list: https://launchpad.net/~dhis2-users

Post to : dhis2-users@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-users

Post to : dhis2-users@lists.launchpad.net

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

5

PS: I know Calle has been tackling this in his disease surveillance work. His update may be useful.

This message and any attachments are subject to a disclaimer published at 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@hisp.org 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.

···

On Tue, Jun 13, 2017 at 11:49 AM, Sean Broomhead sean@hisp.org wrote:

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@logicaloutcomes.net 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@gmail.com]

Sent: Monday, June 12, 2017 2:25 PM

To: Georgi Chakarov georgi@logicaloutcomes.net

Cc: DHIS 2 Developers list dhis2-devs@lists.launchpad.net; DHIS Users dhis2-users@lists.launchpad.net

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

  1.  Partners are able to see each other’s data, EXCEPT FOR HIV related data

  1.  There is this one partner whose data should not be seen by anybody else (this partner can see other partners’ data, though)

  1.  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@logicaloutcomes.net | +1-647-478-5634 x 104 | 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@logicaloutcomes.net

Mailing list: https://launchpad.net/~dhis2-users

Post to : dhis2-users@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-users

Post to : dhis2-users@lists.launchpad.net

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

Dr Sean Broomhead

Director ICT

HISP-SA

+27 79 496 1993

Skype: getsean

6

Hi all,

Different users entering to the same endpoints and protecting the data visibility between them I think it is a common use case and a needed one definitely. We are sroting out this kind of feature with the Sharing settings of the category options, I think some previous emails described it.

We have a data set A where we want three users 1, 2, 3 enter data but none of them to see the data from the others. So we create 3 category options “Source 1”, “Source 2”, “Source 3”, gather them into a category “Data source” and into a category combination as well. And then we finally linked this “Data source cc” category combination with the data set A.

This provided us with the extra dimension to enable each user enter their data, so from an admin view when entering to data entry app, selecting orgUnit, dataset A, period, then a dropdwon with sources1,2,3 is appearing (emphasizing from an admin point of view).

Now the desired feature is that the user 1 only can see in the dropdown the “Source 1” option. This is possible creating a User group “Users from Source 1”, adding User 1 to this group and editing the Sharing settings of “Source 1” as follows:

  • Public access cannot edit.

  • Public access cannot view.

  • Share with user group “Users from Source 1” (can view mandatory, and can edit depends on each use case).

If we repeat the same configuration with the different users we end up with the desired feature where for example user 3 can only see “Source 3” option in the Data Entry App and in Analytics apps as well.

I hope this helps! Looking for feedback and recommendations too.

Thanks

Marc Garnica

···

2017-06-13 11:49 GMT+02:00 Sean Broomhead sean@hisp.org:

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

This message and any attachments are subject to a disclaimer published at 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@hisp.org 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.

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

On Tue, Jun 13, 2017 at 11:45 AM, Georgi Chakarov georgi@logicaloutcomes.net 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@gmail.com]

Sent: Monday, June 12, 2017 2:25 PM

To: Georgi Chakarov georgi@logicaloutcomes.net

Cc: DHIS 2 Developers list dhis2-devs@lists.launchpad.net; DHIS Users dhis2-users@lists.launchpad.net

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

  1.  Partners are able to see each other’s data, EXCEPT FOR HIV related data

  1.  There is this one partner whose data should not be seen by anybody else (this partner can see other partners’ data, though)

  1.  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@logicaloutcomes.net | +1-647-478-5634 x 104 | 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@logicaloutcomes.net

Mailing list: https://launchpad.net/~dhis2-users

Post to : dhis2-users@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-users

Post to : dhis2-users@lists.launchpad.net

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

7

Hi,

See JIRA issue DHIS2-427: User access control down to single tracker case level

For Disease Surveillance - and I suspect a variety of other cases where Tracker is used as a “niche EMR” - that is what we need to implement to have full control over exactly who can see what patient data.

Marc’s use case/solution is also important, but it solves a more “structural” problem where you have distinct and relatively permanent sub-divisions in your data.

IDSR, and other use cases where e.g.

  • patients are referred back and forth;

  • non-clinical staff like case investigators and/or managers need patient-level data access for specific period;

will require patient-level access granularity.

And NOTE: that is all system-determined access. A whole other kettle of fish is the arena of patient-approval for each case of access, which might be relevant for some applications. This is NOT relevant for e.g. disease surveillance because privacy cannot trump the need for rapid and precise public health interventions, but it is highly relevant for other use cases - at least in countries where a patient record by law belongs to the patient.

Regards

calle

···

On 13 June 2017 at 12:02, Marc Garnica marcgarnica13@gmail.com wrote:

Hi all,

Different users entering to the same endpoints and protecting the data visibility between them I think it is a common use case and a needed one definitely. We are sroting out this kind of feature with the Sharing settings of the category options, I think some previous emails described it.

We have a data set A where we want three users 1, 2, 3 enter data but none of them to see the data from the others. So we create 3 category options “Source 1”, “Source 2”, “Source 3”, gather them into a category “Data source” and into a category combination as well. And then we finally linked this “Data source cc” category combination with the data set A.

This provided us with the extra dimension to enable each user enter their data, so from an admin view when entering to data entry app, selecting orgUnit, dataset A, period, then a dropdwon with sources1,2,3 is appearing (emphasizing from an admin point of view).

Now the desired feature is that the user 1 only can see in the dropdown the “Source 1” option. This is possible creating a User group “Users from Source 1”, adding User 1 to this group and editing the Sharing settings of “Source 1” as follows:

  • Public access cannot edit.
  • Public access cannot view.
  • Share with user group “Users from Source 1” (can view mandatory, and can edit depends on each use case).

If we repeat the same configuration with the different users we end up with the desired feature where for example user 3 can only see “Source 3” option in the Data Entry App and in Analytics apps as well.

I hope this helps! Looking for feedback and recommendations too.

Thanks

Marc Garnica

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

–

2017-06-13 11:49 GMT+02:00 Sean Broomhead sean@hisp.org:

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

This message and any attachments are subject to a disclaimer published at 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@hisp.org 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.

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

On Tue, Jun 13, 2017 at 11:45 AM, Georgi Chakarov georgi@logicaloutcomes.net 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@gmail.com]

Sent: Monday, June 12, 2017 2:25 PM

To: Georgi Chakarov georgi@logicaloutcomes.net

Cc: DHIS 2 Developers list dhis2-devs@lists.launchpad.net; DHIS Users dhis2-users@lists.launchpad.net

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

  1.  Partners are able to see each other’s data, EXCEPT FOR HIV related data

  1.  There is this one partner whose data should not be seen by anybody else (this partner can see other partners’ data, though)

  1.  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@logicaloutcomes.net | +1-647-478-5634 x 104 | 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@logicaloutcomes.net

Mailing list: https://launchpad.net/~dhis2-users

Post to : dhis2-users@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-users

Post to : dhis2-users@lists.launchpad.net

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

Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@gmail.com

Skype: calle_hedberg

8

Hi Calle

Good points. The issue of informed consent and access for clinically relevant time period is certainly important for many EMR use cases.

There are of course many more issues relating to handling, storing and sharing patient data. For example transport security and node authentication (eg ATNA) which we don’t currently support but may be possible to emulate outside of DHIS2 at the network level with VPN.

The case being discussed here touches on the inadequacy in general of role based access control for patient data. An issue which nearly sank a massive NHS contract a few years ago in the UK. The point being that is insufficient to have a role of doctor, nurse or whatever. At issue is then which doctor, which nurse. I believe in EMR parlance they refer to modelling a professional clinical relationship. So users not only need to have the correct role, but also need to have a professional clinical relationship with the subject of care. That is something which might be possible to emulate/model using our “sharing” semantics, I am not sure.

I will checkout DHIS2-427 to see whether this is pointing to a similar concern.

Cheers

Bob

···

On 13 June 2017 at 14:51, Calle Hedberg calle.hedberg@gmail.com wrote:

Hi,

See JIRA issue DHIS2-427: User access control down to single tracker case level

For Disease Surveillance - and I suspect a variety of other cases where Tracker is used as a “niche EMR” - that is what we need to implement to have full control over exactly who can see what patient data.

Marc’s use case/solution is also important, but it solves a more “structural” problem where you have distinct and relatively permanent sub-divisions in your data.

IDSR, and other use cases where e.g.

  • patients are referred back and forth;
  • non-clinical staff like case investigators and/or managers need patient-level data access for specific period;

will require patient-level access granularity.

And NOTE: that is all system-determined access. A whole other kettle of fish is the arena of patient-approval for each case of access, which might be relevant for some applications. This is NOT relevant for e.g. disease surveillance because privacy cannot trump the need for rapid and precise public health interventions, but it is highly relevant for other use cases - at least in countries where a patient record by law belongs to the patient.

Regards

calle

Mailing list: https://launchpad.net/~dhis2-users

Post to : dhis2-users@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-users

More help : https://help.launchpad.net/ListHelp

On 13 June 2017 at 12:02, Marc Garnica marcgarnica13@gmail.com wrote:

Hi all,

Different users entering to the same endpoints and protecting the data visibility between them I think it is a common use case and a needed one definitely. We are sroting out this kind of feature with the Sharing settings of the category options, I think some previous emails described it.

We have a data set A where we want three users 1, 2, 3 enter data but none of them to see the data from the others. So we create 3 category options “Source 1”, “Source 2”, “Source 3”, gather them into a category “Data source” and into a category combination as well. And then we finally linked this “Data source cc” category combination with the data set A.

This provided us with the extra dimension to enable each user enter their data, so from an admin view when entering to data entry app, selecting orgUnit, dataset A, period, then a dropdwon with sources1,2,3 is appearing (emphasizing from an admin point of view).

Now the desired feature is that the user 1 only can see in the dropdown the “Source 1” option. This is possible creating a User group “Users from Source 1”, adding User 1 to this group and editing the Sharing settings of “Source 1” as follows:

  • Public access cannot edit.
  • Public access cannot view.
  • Share with user group “Users from Source 1” (can view mandatory, and can edit depends on each use case).

If we repeat the same configuration with the different users we end up with the desired feature where for example user 3 can only see “Source 3” option in the Data Entry App and in Analytics apps as well.

I hope this helps! Looking for feedback and recommendations too.

Thanks

Marc Garnica

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

–

Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@gmail.com

Skype: calle_hedberg

2017-06-13 11:49 GMT+02:00 Sean Broomhead sean@hisp.org:

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

This message and any attachments are subject to a disclaimer published at 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@hisp.org 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.

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

On Tue, Jun 13, 2017 at 11:45 AM, Georgi Chakarov georgi@logicaloutcomes.net 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@gmail.com]

Sent: Monday, June 12, 2017 2:25 PM

To: Georgi Chakarov georgi@logicaloutcomes.net

Cc: DHIS 2 Developers list dhis2-devs@lists.launchpad.net; DHIS Users dhis2-users@lists.launchpad.net

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

  1.  Partners are able to see each other’s data, EXCEPT FOR HIV related data

  1.  There is this one partner whose data should not be seen by anybody else (this partner can see other partners’ data, though)

  1.  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@logicaloutcomes.net | +1-647-478-5634 x 104 | 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@logicaloutcomes.net

Mailing list: https://launchpad.net/~dhis2-users

Post to : dhis2-users@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-users

Post to : dhis2-users@lists.launchpad.net

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