How does DHIS2 protect personal information? (The tech details)

Hi all -

Sara Gaudon from LogicalOutcomes, looking for up to date info on DHIS2 technology and security.

Now that many are considering/moving towards GDPR compliance, it’s timely for those in the community to provide up to date information to their clients/governments: on how DHIS2 will safely guard personal information.

Does any one have an information packet to share, on the technical features that DHIS2 has within to help with protecting personal information? Note: we aren’t using encrypted fields.

This information will be part of a pitch for cloud hosting to an environmental project committee in Africa, with information we’ve gathered from the DHIS2 website and BAO systems (on the AWS/vendor responsibility side); i.e. it 's more than just servers…

Deploying a reliable and scalable system includes at least these aspects:

  • Human resources with skills in relevant technologies such as web servers and database systems.
  • Reliable backup of your system including safe storage at a remote server.
  • Use of SSL (HTTPS / encryption) to keep private information like passwords secure.
  • Monitoring of server resources and application performance.
  • Stable and high-speed Internet connectivity.
  • Stable power supply including a backup power solution.
  • Secure server environment to avoid unauthorized access, theft and fire.
  • Powerful hardware with potential for scaling together with increased system usage.

https://www.dhis2.org/hosting

I would be happy to share our finished product with the community / on the upcoming DHIS2 Community of practice for others to use.

Thank you,

···

Sara


Sara Gaudon, Executive Director LogicalOutcomes

Skype: sara@logicaloutcomes.net | Toronto 647-478-5634 x103 Washington 202-779-9634 x103

Hi @sgaudon ,

I don’t have the complete and detailed description for you, but I will share what I know. The information is based on the recent versions of DHIS (2.30+).

  • User accounts have stricter requirements for password, requiring a mix of characters, and can block users from using the same password they recently used.
  • DHIS2 implements different layers of security/access:
    • Authorities
    • Organisation Units ( including “Breaking the glass”)
    • Metadata and data read/write

Authorities
Authorities can be split into two types: M_* authorities and F_* authorities. The M_* authorities decides whether you have access to a specific module or not. That effectively means apps. Without the appropriate authority the server will not save the app. The F_* authorities on the other hand, are based on actions (I usually refer to them as feature or functional authorities). These are required for special operations that should be reserved to specific users. Some examples include starting server-jobs, approving data and more. The authorities are mainly a layer of access for interacting with the software itself, but may in some cases provide additional access to data as well. The one important exception is the “ALL” authority, which grants the users a total override for access check. This is however not an authority normal users should have. A final note about authorities: Authorities are attached to a user roles, so you can design roles and assign them to users.

Organisation Units
The second layer of access is the organisation units. All data and some metadata is associated with an organisation unit. The users are also associated with organisation units: "Data capture and maintenance organisation units” (Capture), “Data output and analytic organisation units” (Analytics) and “Search Organisation Units” (Search). We often refer to these organisation units are “scopes”, so we have the capture scope, analytics scope and the search scope. The core idea is that for any given scope, we only have access to the selected organisation units for that scope and any children of that organisation unit.

Assuming you know the different data-models we have in DHIS2, tracker/events and aggregate data, I will just briefly point out how they affect each model. For tracker data, that means where the tracked entity instance(TEI) is associated, for event it where the event is associated and for aggregate data it’s where the data set/data value is associated.

The capture scope decides whether or not the user have access to add or edit data associated with a given organisation unit. This means users are only able to work with TEIs or create TEIs that is associated with a organisation unit within their capture scope, and similarly for events and aggregate, where the events or data sets are associated.

The search scope decides whether a users can see the existence of data or not. I believe this don’t apply for aggregate data, where viewing and editing is determined by the same scope, but for tracker data especially, that means you can have a bigger search scope than capture scope, to be able to find TEIs that might be associated with a different organisation unit. By default, users with search scope access to a TEI will be able to view any information for that TEI.

Since some information attached to a TEI and a program/enrolment might be sensitive outside the owning organisation unit, we have introduced a concept called “breaking the glass”. This feature allows a program to restrict access to it’s data on 4 levels: Open, Audited, Protected and Closed. Open is the default, which means anyone can read the data. Audited means any reads through the search-scope (Implying the TEI is outside the users capture scope, but within the search scope) will be recorded. Protected means the user have to actively confirm they want to access the data, state a reason and will be granted a time-limited access to read the data. This access is also recorded. The final option, closed, means you can only read the data if you have the organisation unit of the TEI in your capture scope.

A final note about TEI organisation units and “breaking the glass” before we go to the analytics scope: Since a TEI can have enrolments in different organisation units, other than the organisation unit it was first enrolled in, we introduced the concept of “ownership”. So an organisation unit will “own” a TEI and Program tuple. This means the tuple can move between organisation units without changing the factual data, but also means that when we check for search scope access, the TEI can belong to multiple organisation units. So if any owning organisation unit is within the search scope, the user can see them.

The final organisation unit scope, analytics, determines what analytical data the users are allowed to see. So a user who might only be able to enter data for a few organisation units, might be able to see the reported data for a bigger scope of organisation units. For aggregate data, this is pretty straight forward - however for tracker and event data, all analytical data processed by the backend is currently based on enrolments and events, so “ownership” is not affecting the data seen from this perspective.

Metadata and data read/write
The last layer of access control we enforce, is based on the metadata. Metadata itself can be public or private, or shared with specific users or user groups. Each of these rules are accompanied with 5 levels of access: No access, Metadata read, Metadata write, Data read and Data write. No access seems self explanatory, while metadata read and write simply restricts a users to either only being able to read the metadata, or also edit it. Data read and Data write on the other hand, refers to the data described by the metadata. For example a data element “Lab result” can have data read for everyone who needs to see the lab results of a test, while lab workers might have the data write access to be able to edit the value of the data element to match the test results. However, the result of the test might be sensitive, so other users might only have metadata read or even no access, implicitly removing the data element and associated values from their view.

This is a very shallow explanation of the concepts, and there is a lot more detail if required, but it should give you some core ideas on how we deal with access and privacy.

Here are some key documentation about the concepts I described as well. Some of the information is located in other sections as well, for example when configuring metadata.

@Lars @morten @Markus @mike feel free to correct me on any wrong assumptions or descriptions.

7 Likes

Thank you for sharing this; at the time I had summarized some of the information to share with others.

Security is a tricky topic, to both understand the many dimensions (technical and not), and to communicate to people that may not have technical background. I am most interested in being able to provide an overview of the full picture:, a summary of the main features within DHIS2 that support security, and also the hosting and people components (procedures, policies).

Is there a group working on communicating this information? I would be interested in participating, to create an output/fact sheet/slide deck to share with an audience that includes funders/decision makers (who want to know, can DHIS2 meet our needs/GDPR compliance?).

Happy to be in touch, thanks again,
Sara

4 Likes

Thanks again Sara - definitely agree that security is an important topic, and that we want to make sure we communicate what DHIS2 does to maintain security and privacy.

I am retagging @mike, as well as @Johan_Ivar_Saebo and @bobj as they might know more about what the current priorities within the security domain of DHIS2 currently is.

2 Likes

Hi all,
Thanks for this discussion. I read through Stian’s write-up and I’m looking for confirmation that it’s not possible to restrict TEI access within the same OU and program. For example, if an agent enrolls a client in a tracker program within a certain district, and there is another agent assigned to the same tracker program and district, both agents can see all of that TEI’s information. You can’t, for example, somehow restrict that TEIs can only be seen by the agent who enrolls them. I think this is true but wanted to confirm. Thanks!

1 Like

@bobj @Karoline - Has any one done a Privacy Impact Assessment on DHIS2? Or any external review related to protecting privacy of PII? A Canadian public health entity is looking to adopt the software (Yes!) And are asking us to do a PIA on DHIS2 - which we would not be in a position to do. I figure, big funders have to have done something like this already (hiring an external consultant, or something GDPR related?). Please Share with colleagues so we might get our hands on documentation to encourage new adopters of DHIS2. THANK YOU

1 Like

@maxk @stevie @jackregnart Looking for some insight on this: Has a firm created a Privacy Impact Assessment on DHIS2 / or similar that we could get access to? See comment above, Please share what you know…

1 Like

Thanks for your question. I know there were some things done around assessing privacy/security when Norway was adopting DHIS2 for COVID-19 contact tracing. Not sure if this information is available in English but tagging some people that might be aware!

@Johan_Ivar_Saebo @Markus @olatitle @AnneThorseng @Enzo @YuryR @bobj

During the Norwegian implementation there were several assessments of DHIS2 tracker and GDPR compliance which had positive outcome, but I didn’t go through that aspect of the process myself. I will see what I can find!

2 Likes

Hi,
we have a work in progress document that started out as a quick answer to GDPR law’s compliance for the Norwegian gov. assessment of the Covid-19 tracker. This is made by me and a couple of other engineers and there are no lawyers involved, so this should be only seen as a quick overview of the system capabilities.
I know there has been a lot of work on the Norwegian municipalities to document according to Norwegian privacy laws, they are pretty similar to GDPR. Most of this are written in Norwegian, but if it is of interest you can get access to this I guess. Just email me if you are interested.GDPR compliance in DHIS2 (emphasis on Covid-19 packages) (2).pdf (65.7 KB)

2 Likes

Hey Sara - sorry didn’t see you tag me in this. As part of the AMR One Health Project. We have done a number of pen tests against the platform, this includes DHIS2. Drop me a line when you’re back and I should be able to share the reports. All in all, the application itself is pretty robust and there were only a few small things flagged like using older versions of a few js libraries.

We’re also putting together a digital security handbook for implementers to inform on the many security decisions that should be taken into consideration. Bit of a work in progress at the moment and concerns the wider AoS Platform rather than just DHIS2. But, still pretty relevant.

I am hoping we can put together a bit of a ‘security feature request’ list for UiO. Last thing I recall discussing with the our sec team is using a password blacklist in production environments for example, it would be a great addition to stop users from being able to use known weak passwords. Lots of possible improvements there I think.

1 Like

Hi Jack – appreciate your help and response. I am Kevin, a colleague of Sara working on DHIS2 implementation, and would like to obtain more information on PIA and security around it. Would you be able to share the penetration testing report with me? Also, a security handbook would be very helpful as well. Appreciate your help and will wait for your response. Thanks, Kevin

1 Like

Hello Morten,
I hope you are doing well.
I am working on DHIS2 implementation for public client here in Canada.
One of the question from the client was “is DHIS a safe system to store and process personal information or sensitive information?” I saw the document attached from you and wanted to see if there were additional updates to topic of security.
Any feedback would be highly appreciated. Thanks, Kevin

1 Like