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).
> 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. 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.
hp
--
_ | Peter J. Holzer | we build much bigger, better disasters now
|_|_) | | because we have much more sophisticated
| | | hjp@hjp.at | management tools.
__/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
