GDPR and OpenMRS?

Community
1

GDPR, the EU law on data protection, takes effect today, and I realize that we probably need to do some things on the organizational side of OpenMRS to comply with it.

This is an interesting non-authoritative summary of what we might need to do:

Some things we might need to do:

  • Determine whether our (non-)privacy policy is consistent with GDPR, and maybe make changes
  • Introduce a consent form on id.openmrs.org
  • write an SOP for what to do if an EU citizen asks for access to all their own personal data
  • determine how to delete an OpenMRS ID (“right to be forgotten”) and write an SOP around this
  • start to keep a formal register with detailed descriptions of all procedures, purposes etc for which we process personal data

None of this sounds “fun”, but it’s important! Who is interested to help look into this further and/or to start implementing some solutions?

2 Likes
2

Looking at the scope of this for OpenMRS, presumably it applies to OpenMRS Talk, Addons, Atlas, but I wonder if it applies to everything else an OpenMRS ID provides access to (i.e. Atlassian tools like Jira, Confluence, Bamboo), and if it also applies to other tools the OpenMRS community uses like Github, Telegram, IRC - or are those independent of this?

Taking a page from what Discourse have done to address GDPR (there’s some debate on how compliant this is, but it seems a good start):

The Discourse privacy policy has some nice, simply worded sections that could be leveraged for the OpenMRS policy. Atlassian have also updated their privacy policy and explained the updates they’ve made towards GDPR compliance.

Another point to mention - the GDPR guidelines calls for the assignment of a data protection officer (DPO) to oversee the data protection strategy and implementation for an org/company (i.e. who will action out the SOPs when there is a GDPR-related request). I don’t see the need for a dedicated person, and presumably this will fall on those supporting the OpenMRS Help Desk, but it might be worthwhile adding the functions of a DPO to existing community role(s) to make sure this is covered, and that relevant people have levels of access required to action this out (e.g. they might need admin access on Jira to manage users, but don’t necessarily need access to any projects).

3

I couldn’t answer this topic before, but thanks so much for doing it :slight_smile:

Burke raised the ticket to add the user agreement to ID a long time ago: Log in with Atlassian account If someone is willing to change ID dashboard, please let me know.

So.

We don’t have a lot of personal data with OpenMRS ID, I suppose we are sensible people :smiley: We have username, emails, full name. We do maintain any historical data on changes. We do not aggregate, generate metrics. Avatars come from gravatar. We do not store IPs or anything. We do not have gender, preferences, address or country.

We know that Atlassian apps will store the last time the person logged in.

Helpdesk is a little bit tricky, not sure if anything there could be considered PII.

Exception is Atlas. Atlas is submitted via OpenMRS module I believe most of the time, but we have a lot of public PII there. The data is sort of stored forever, the only way to delete is to hack our way on the database and delete it. Not only that, the endpoint to recover all data is a public endpoint…

So, deleting an OpenMRS ID should* be easy, it’s exactly the same screen we add ldap groups. But it won’t delete the data from any atlassian product: you’ll see the username only, not sure if that’s enough. In talk you can see everything just as before, but I believe we should have the option to anonymize the user if that’s what we want.

*should, because formage sometimes doesn’t find a user that exists… but we should fix it soon.

It could be either in the internal wiki or confluence, both should be fine.

cc @dkayiwa

1 Like
4

It just so happens that I sent out a note to @lrosen about this very thing. We’ll see what he might have to say. The real question is whether we can continue to claim all volunteered information as “public” and whether that will satisfy EU.

Regarding the rest. I agree that we need to be mindful about disclosure to all because there are projects like Burke is contemplating that will be reusing individual community member data to do aggregate rollups (only to better the community of course).

I just don’t know whether the burden is on us to say what we plan to do with public data. The only data we keep that’s private is passwords at the moment.

5

Paul Biondich asked:

The real question is whether we can continue to claim all volunteered information as “public” and whether that will satisfy EU.

Of course, despite privacy rules, a person can still freely identify – with a copyright notice or other personal information – that he is the author or promoter of a written work (e.g., software, email). The OpenMRS privacy policy does not require more disclosure than that, but it does expect at least that much disclosure.

Darius wrote:

We don’t have a lot of personal data with OpenMRS ID,

We require that every participant in the community identify him/herself with an OpenMRS account registration that allows us to identify the real human being who uses a nickname in his/her email communications. That is personal information. I don’t believe that this is prevented by GDPR or else the entire world’s account systems would fail.

This is also a typical academic requirement. For example, every scientific paper copied at arXiv.com contains the name and affiliation (and sometimes more voluntary information) about each author. That is an academic standard of personal disclosure that is not restricted or limited by GDPR.

I presume that the OpenMRS privacy policy is similarly open – in this academic disclosure sense. Do we store otherwise “private” information about OpenMRS participants other than real name and affiliation, along with a verified email address?

There is also the “right to be forgotten,” which presumably allows a person to delete his/her OpenMRS account. That is probably fairly easy to implement.

/Larry

6

On your talk.openmrs.org profile (discourse) a user can enter a bunch of things: About Me, Location, Website, Github ID, Community Role (contributor/customer/both). These, as well as all of your activity and badges on talk.openmrs.org are world-viewable. (For a quick example see Profile - darius - OpenMRS Talk and https://talk.openmrs.org/u/darius/activity.)

At the very least we should indicate this explicitly on the page where you create your talk account.

Let me ask this another way…

Our policy is basically that any information anyone shares with us, and their activity within OpenMRS’s community tools, will be treated as public information, and it may be viewed by anyone in the world at any point without any login or tracking.

So, I guess we are still allowed to do this under GDPR, as long as people explicitly opt into it when creating an account. Right @lrosen?

PS- This is the privacy policy as written at https://openmrs.org/privacy/:

OpenMRS is an open source project organized under the auspices of a public benefit corporation. Our challenges and goals are large. For that reason, we have a very permissive (non) privacy policy that mirrors our public mission.

Please assume that everything you contribute intentionally to OpenMRS is public. This includes emails on public lists, wikis, online discussions of all sorts, and software or documentation that you post to this website.

Because we follow an academic model that expects mutual personal respect, disclosure of interests and openness of expression, even your OpenMRS profile is public information. There will be cases where you are invited to share private information for various purposes, and denote that information as such. In those cases, we commit to only disclosing that information without your permission upon receipt of a valid subpoena and following notice from OpenMRS to you.

Although what you disclose here is public, we are all limited by copyright and patent law in how we may use your contributions. Therefore, OpenMRS only accepts voluntary contributions of software and documentation that are expressly licensed to OpenMRS under an approved open source license. Refer to the OpenMRS Contribution Policy for additional details.

OpenMRS welcomes your questions or comments regarding this Privacy Policy. Send them to community@openmrs.org.

7

Yes, we should indicate explicitly on the registration page that personal information is optional to be entered, but will be treated as public information if entered. Registration information will not be confidential, so if you don’t want anyone to see it, don’t enter that optional information when registering.

Not-optional are nickname, real name, and email address. The nickname and email address will be captured automatically with every electronic contribution to OpenMRS. All contributions will be accepted under the CC-0 (or other open source) license and are free for OpenMRS and others to redistribute to the public. All contributions to OpenMRS can be tracked back to a “real name,” and are not confidential.

That is how I currently understand it.

/Larry

P.S. On rereading it, I rather like our non-privacy policy! I hope you do too. I don’t believe in confidentiality in public benefit organizations.

8

I am not so sure that is so easy. There are lots of links to that ID in the record. I think we said that we could expunge the name, perhaps the email that is attached to the ID, but there are probably archives and places where data is copied. We probably need a plan for that.

9

Andres Kanter: I think you are overreading that requirement to allow people to be forgotten. Here is how OpenMRS Talk already handles this:

  "To unsubscribe from these emails, click here."

Nowhere in the GDPR regulations does it say that voluntarily donated history must be erased.