Il 28/03/2019 23:29, Peter J. Holzer ha scritto:
On 2019-03-28 18:36:40 +0100, Moreno Andreo wrote:
Il 26/03/2019 18:08, Adrian Klaver ha scritto:
To me it would seem something like:
Table medications
id user_id med
1 sgkighs98 Medication
2 sghighs98 Ear check
Table users
id surname last name
sgkighs98 John Doe
jkopkl1 Jane Doe
uepoti21 Foo Bar
Where there is no direct link between the two.
Are you sure there isn't?... the key "sgkighs98" is present on both
tables and I can join tables on that field, so the pseudonimysation
does not apply,
Yes. It doesn't matter whether the key is 'sgkighs98' or 1438 or
692da0c1-cf2d-476d-8910-7f82c050f8fe.
it's just "separation" (that was OK with the last privacy act, but not
with GDPR
I doubt that this is correct. The GDPR doesn't prescribe specific
technical means (there may be laws or standards in your country which
prescribe such means for medical data, but that's not the GDPR).
That was told me by a privacy consultant, there was an Italian law
(196/2003) that introduced "minimal security measures", that has been
revoked with the GDPR appliance.
The problem is not on the application side... there you can do almost
anything you want to do. The prolem is that if someone breaks in the
server (data breach) it is easy to join patients and their
medications.
I sure hope that the doctors are able to join patients and their
medications. So at some level that has to be possible.
It would be possible at application level, that resides on another
server (so it would be compliant the separation between the
pseudonimysation and the reverse method)
If you assume a
break-in into the server, there will always be a level of penetration at
which the attacker will be able to access any data an authorized user
can access.
That's not what I got reading the GDPR article... but I may have
misunderstood (juridic text is non my cup of tea). My understanding was
that even in a data breach event there should be a mechanism that
prevents (or "mitigate the risk that") the attacker to gain access to
the data in the "joined" form, so he cannot acquire that patient John
Doe has got Alzheimer, for instance, but only that in that database
there is a patient which name is John Doe and someone that has got
Alzheimer.
And I tried to find a solution, and since I did not like that much what
I found (and it seems that neither you do :-) ), I came here hoping that
someone would share his experience to shed some light on the topic.
hp
