ambiguety regarding the use of pseudo for long fields and more guidance required for implementations.

[Ethoxyethaan]

We understand that the major difference with the current release is that any String meta-information about the patient can be pseudonymized, not only the patient's ID.

A minor remark, probably caused by our lack of knowledge: why is the term pseudonymization used for long fields instead of the term encryption? The sheer fact that this is about information that may be used to easily identify the patient does not seem sufficient reason to use a term that is usually associated with static information about the patient, such as name or ID (not address of occupation).

A major remark: if our impression is correct that, at least in the examples, the resource type is just indicated as 'patient', there should be a dedicated profile that indicates that additional metadata fields, apart from the Belgian ID, can be encrypted/pseudonymized. Software implementations can then use that type to decide when the usual software libraries cannot be used directly. So this extension should only be used in resources that have profiles that reference that the resource can contain an encrypted field.

A major remark: it must be indicated which exact metadata elements in the resource that use the Profile (example) 'BelgianPatientWithSomeEncryptedMetadata' are encrypted. Motivation for this is that guidance is needed for software implementators about which elements are sufficiently sensitive to warrant encryption. If such precise guidelines are not provided there will be implementations that do not adhere to the security expectations while other implementations will encrypt each and every element. In practice, software and procedures (such as for inspecting error or audit logs) will then have to assume that all elements are encrypted - you cannot rely on the citizen's preferred language to be readily available. If this is indeed the intention of this working group - and the consequences of this decision have been studied and discussed -, why not just encrypt the complete message?

Regards,
UZL Leuven Development Team