Anonymising client records, aka ForgetMe
- Rodolfo Melia
- Gaspar
Safeguarding patient/client privacy and anonymising client records in FHIR
Many of the activities that PSI captures on their information systems include PII (Personal Identifiable Information), including names, phone numbers, location (descriptive or coordinates), date of birth, family details, and much more. PSI must offers across all its tools the option for the client to ‘forget me’, which should remove all identifiable data, effectively anonymising the record. We describe on this article the exact steps that we take on the FHIR-based systems to anonymise client’s records.
Usage
A generic service for anonymising ANY client, regardless of project. We do NOT contemplate exemptions on what to remove on a per-project basis.
Definitions
|
|
|---|---|
Client | In this document it refers to either the Patient resource of the Practitioner resource. |
the FHIR resource normally used to keep personal information about a final consumer | |
Practitioner | the FHIR resource normally used to represent health workers, which at PSI are normally referred as IPC or Providers |
Out of scope
Non FHIR-based implementations.
Anonymisation process
As of March 2023, there is a service implemented as a mediator in OpenHIM that when requested it performs the following operations to anonymise a client. This service can be accessed as a API request by any application requiring a record to be anonymised, by simply providing the ID of the Patient or Practitioner to be executed.
1. Patient/Practitioner resource operations
Implemented for v1.0
Property | Action | Notes |
|---|---|---|
identifier(s) | set to ‘REDACTED’ each value. Includes social network logins, national identifiers, |
|
active | set to “false” |
|
name | set |
|
telecom | set ‘N/A’ each value |
|
gender | KEPT |
|
birthDate | only the YEAR is retained (day and month, is present, are removed) |
|
address | for all addresses (home, work, other…)
|
|
photo | removed |
|
contact(s)* | Apply same logic than a Patient or Practicioner. Relationship: 'U’ (unknown code). Need discussion |
|
link* | KEPT |
|
qualification** | KEPT |
|
communication | KEPT |
|
Notes: *applies to patient resource | **applies to practitioner resource
2. QuestionnaireResponse
In most implementations, PII is collected via a series of questions on a registration form, which means that PII data will be saved on an associated QuestionnaireResponse resource. For the “forget me” script being able to remove PII data from the QuestionnaireResponse items that contain such data, the original Questionnaire resource must identify
Property (QResponse resource) | Action | Notes |
|---|---|---|
Item associated to a PII Question | removed | The question is a PII questions, as defined on the questionnaire resource (see questionnaire resource, next table) |
Property (Questionnaire resource) | Action | Notes |
|---|---|---|
item/???? | contains PII??? TBC | a tag that identifies the question as collecting PII, which must be removed during anonymisation process |
3. Communications
Sent or received communications are stored on the communication resource. These communications can be via SMS, social media or email.
Property (Communication resource) | Action | Notes |
|---|---|---|
payload/content | removed | May contain the client name of other PII. Example: “Dear %client_name% you next appointment for…” |
4. CommunicationRequests
PSI uses CommRequest to queue scheduled messages
Property (C.Request resource) | Action | Notes |
|---|---|---|
status | if “active” (meaning scheduled), change to “revoke” |
|
payload/content | removed | May contain the client name or other PII. Example: “Dear %client_name% you next appointment for…” |
5. Other resources
As of February 2023, we have not yet identified other resources that need to be part of the forget me/ anonymised process.
Resource history
Submitting an updated version of the resource without the PII information will only affect the latest version of a resource: FHIR servers maintains a versioned evolution of each resource, creating a new one every time there is an update. So to truly remove all PII from the server, we will need to expunge all history. But the expunge process affects ALL resources, not the individual resource id. To address this gap, we plan to use the “Update with History Rewrite”, a hapiFHIR implementation process that allow to re-write previous versions, allowing us to truly remove all data from the resource.
Shared profile across projects
Most implementations are responsible for avoiding the recreation of a client profile if it already exist, hence a single patient can be used by more than one implementation (sometimes referred as projects). When the operation forget me is invoked, the patient (or practitioner) record will be anonymized as detailed above. hence all other projects will also lose such registration, and the patient will need to be re-registered. Hence, the implementer must notify the client that he/she will also loose access to the other projects.
Special case - clients sharing a phone number
Phone numbers can be shared across various clients, for which we create various profiles using a combination of phone+secret. This is stored as an identifier in the patient resource.
Case 1: A user that shares a phone number identified with its secret word: only the specific patient is affected
Case 2: we get a request from the phone number, without specifying what specific phone+secret the request is for: we anonymised ALL associated patients to that phone number
Data Backups
Previous versions of the resources will be kept on the backups of PSI by the retentions periods. They cannot be updated. This could result in the rate occasion of a restore of a backup copy, on a client record repairing.
To properly address this loop hole, we will need to keep a log of all IDs that has been requested to be anonymised, and in the event of a restore, rerun the anonymisation request between the date of the backup an the present. Backups are normally kept for a minimum of 12 months.