Einde inhoudsopgave
Privacyrecht is code (R&P nr. ICT1) 2010/6.7.2
6.7.2. De oplossing
drs. J.J.F.M. Borking, datum 26-05-2010
- Datum
26-05-2010
- Auteur
drs. J.J.F.M. Borking
- JCDI
JCDI:ADS580017:1
- Vakgebied(en)
Civiel recht algemeen (V)
Voetnoten
Voetnoten
Klaver, e.a., 2002, p. 51.
Hes & Borking, 2000, p. 40.
Van Blarkom, 1997, p. 29-32.
Van Blarkom, 1998, p. 33.
Van Blarkom, Patent Application Number 9712459.8 (application date le June 1977) 'Figure 1: block diagram showing a computer system incorporating a secure database', p. 12.
Van Blarkom, Patent Application Number 9712459.8 (application date 14
Borking, 2005, p. 25: 'The aim of the pseudo-identity domgin is to make sure the real person involved cannot be traced on the basis of previously obtained personal data, and vice-versa, to make sure the personal data cannot be found on the basis of the obtained identity.'
Een constraint in een database is een vastgelegde voorwaarde, bedoeld om de integriteit of logica van de opgeslagen gegevens te bewaken. Een constraint zorgt ervoor dat er een foutmelding wordt gegeven als de betreffende regel overtreden dreigt te worden.
Referentiële integriteit in een relationele database is het uitgangspunt dat de interne consistentie tussen de verschillende tabellen binnen die database wordt gewaarborgd. Dat betekent dat er altijd een primaire sleutel in een tabel bestaat als er in een sleutelveld in een andere tabel naar wordt verwezen. Het DBMS waarborgt de consistentie en zorgt ervoor dat een transactie die de consistentie doorbreekt niet wordt aangebracht.
Voor de functies van de Identity Protector zie hoofdstuk 5 paragraaf 5.9.
Klaver, e.a., 2002, p. 51.
ICL, Latest Patent Applications: C1372 Secure Database 14-06-97 in Intellectual Property Department, London, Issue 97/2, 1' August 1997, p. 1-18.
Van Blarkom, 1998, p. 33.
Borking, 2003, p. 211-246.
European Patent: EP0884670 (G. van Blarkom, inventor, ICL).
Door naast een sterk toegangcontrolemechanisme, gebaseerd op gebruikersgroepen, een mechanisme te introduceren waarbij groepen van persoonsgegevens in de database van elkaar en van direct identificerende gegevens worden losgekoppeld, wordt oneigenlijk gebruik van persoonsgegevens bemoeilijkt.1 Door middel van de 'Identity Protector' worden domeinen gecreëerd. In het identiteitsdomein (zie paragraaf 5.8) worden de persoonsgegevens inclusief een patiëntnummer opgeslagen. In de pseudo-identiteitsdomeinen worden de diagnostische en behandelgegevens opgeslagen. Hoewel in dit domein een patiëntnummer wordt gebruikt, mogen de patiëntnummers uit het identiteitsdomein en de pseudo-identiteitsdomeinen niet aan elkaar gelijk zijn, omdat iedereen dan de koppeling tussen de identificerende en niet-identificerende gegevens zou kunnen maken. Om de mogelijke koppeling te voorkomen, wordt het patiëntnummer uit het identiteitsdomein versleuteld. Dit versleutelde nummer wordt als patiëntnummer gebruikt in een specifiek pseudo-identiteitsdomein. Met behulp van de 'Identity Protector' kan het versleutelde patiëntnummer worden ontcijferd en wordt de koppeling met het identiteitsdomein gemaakt. Op deze wijze kunnen alleen degenen die de beschikking hebben over de 'Identity Protector', de twee domeinen met elkaar in verband brengen. Er kunnen in de database even zoveel pseudo-identiteiten per patiënt zijn als het aantal tabellen.2 Deze oplossing wordt in figuur 6.8 in de architectuur van model informatie-systeem 2 (vergelijk figuur 5.5 in hoofdstuk 5) als volgt weergegeven. Er zijn vier modulen, namelijk de gebruikersrepresentatie, de dienstverlenerrepresentatie, de diensten en de databank met de bevoegdheden en de audit. Deze modulen zijn verbonden met een interactielijn waarover het dataverkeer gaat. De 'Identity Protector' is geplaatst op de interactielijnen tussen 1. de combinatie gebruikersrepresentatie — dienstverlener representatie — de diensten en 2. de databank met de bevoegdheden en auditfaciliteiten. De 'Identity Protector' zorgt voor de anonimisering c.q. pseudonimisering. In de relatie tussen de zorgverlener, die de diensten aanbiedt, en de patiënt is de identiteit van de patiënt bekend.
Figuur 6.8: Model informatiesysteem 2 met Identity Protector; de kruisridder staat symbolisch voor de Identity Protector. De databank valt binnen het door de Identity Protector gerealiseerde pseudo-identiteits-domein.
Deze aanpak is uitgewerkt door ICL/SIAC in 1996/73 en resulteerde in de X/ Mcare-database gebaseerd op een Oracle relationele database en client-serverstructuur. Teneinde een privacyveilige oplossing te bereiken diende: "The patientidentifying number has to be removed from all tables forming the medical record", aldus Van Blarkom.4 Vervolgens is het ziekenhuis informatiesysteem in twee gescheiden verzamelingen opgedeeld.5 Het ene gedeelte bestaat uit de persoonsgegevens van de ingeschreven patiënten, de zorgrelatie en de vastlegging van de functionele autorisatie. PET steunt namelijk sterk op authenticatie- en autorisatiemanagement. Wanneer het toekennen (autoriseren) en het uitreiken van de authenticatiemiddelen niet zorgvuldig gebeuren, kunnen ongeautoriseerde personen onrechtmatig toegang verkrijgen tot de persoonsgegevens. Hiermee wordt het voordeel van PET geheel tenietgedaan.
Het tweede gedeelte omvat de medische gegevens en de medisch dossiers van de patiënten. Elk dossier bevat onder meer de anamnese, medicatie, behandelplan, afspraken met zorgverleners, chirurgische behandeling, laboratoriumuitslagen, en verstrekkingen van gegevens aan derden (huisarts, tandarts, apotheker, laboratorium etc.).6 Elke tabel in de twee gescheiden verzamelingen is voorzien van een primaire sleutel. Elk onderdeel van het medisch dossier is ondergebracht in een eigen tabel waarbij de waarde van de primaire sleutel per tabel verschilt, ook al heeft zij betrekking op een en dezelfde patiënt, hetzelfde medisch dossier etc.7 In het X/Mcare-systeem zijn alle logisch bij elkaar horende gegevens opgeslagen in aparte tabellen. De tabel 'patiënt' bevat alle persoonsgegevens, de tabel 'aanmelding' alles wat de aanmelding van de patiënt betreft, de tabel `agenda_afspraak' bevat de feiten rond het consult en niet meer dan dat. Tussen de tabellen zijn wel logische verbanden maar niet fysiek aanwezig in de database. Binnen dit systeem bestaan geen `constraints'8 of andere mechanismen die zulke fysieke verbanden kunnen leggen tussen kenmerkgegevens van zorgverleners en patiënten en de zorggerelateerde gegevens.
Om een koppeling te maken tussen de tabellen, moet eerst vastgesteld worden of er een geldige zorgrelatie met een geselecteerde patiënt is. In dat geval is het unieke kenmerk van de betrokken patiënt bekend. De applicatie versleutelt dit vervolgens tot unieke kenmerkgegevens van de gewenste zorggerelateerde tabel. Deze versleutelde kenmerken stellen de toepassing vervolgens in staat de benodigde gegevens in de database te benaderen. In de X/Mcare-database bestaat voor elke tabel een uniek encryptieprotocol. Daarmee is bereikt dat elke zorggerelateerde tabel voor een en dezelfde patiënt een unieke sleutel bezit. De relaties tussen de tabellen worden onderhouden door middel van beschreven `constraints' voor het bewaken van de referentiële integriteit9 van de database om te voorkomen dat gegevens van een bestaande patiënt kunnen worden verwijderd. Het is hierdoor ook niet mogelijk om een behandeling te laten uitvoeren door een niet-geregistreerde zorgverlener.
In figuur 6.9, gebaseerd op figuur 6.7, zijn de relaties tussen de verschillende tabellen vervangen door 'Identity Protectors' (weergegeven door het symbool van de kruisridder), die de pseudo-identiteiten tot stand brengen.10
Figuur 6.9: Basistabellen waarin de relaties zijn vervangen door Identity Protectors; de kruisridders staan symbolisch voor de Identity Protectors.
Om een hacker het niet mogelijk te maken persoonsgegevens te koppelen aan het medisch dossier, dat in tabellen is opgesplitst, zijn tussen de tabellen geen `constraints' gedefinieerd. Ook zijn er geen verborgen tabellen aanwezig waarin een relatie wordt gelegd tussen de primaire sleutel die binnen de twee databankdelen in gebruik zijn. Het medisch dossier omvat tabellen die als startpunt worden gebruikt voor een applicatiefunctie nadat de patiënt is geselecteerd. Deze tabellen zijn voorzien van een extra kolom waarin de pseudo-identificatie wordt vastgelegd, die gebruikt wordt als toegangssleutel tot de gewenste informatie in het medisch dossier.11 Er is hier sprake van de invoering van de 'identity protector', die de identiteit van de zorgverlener en patiënt afschermt.
De client-software biedt de mogelijkheid op basis van de primaire sleutel van een patiënt een pseudo-identificatie samen te stellen met behulp van encryptietechnologie. Het encryptieprotocol kent drie parameters:
de primaire sleutel;
de encryptie sleutel van 128 bits of hoger;
een unieke tabel `identifier'.
Het encryptieprotocol gaat bijvoorbeeld als volgt: de seq_patiënt is 34, de unieke `identifier' voor de tabel 'medicatie' is 47 en de encryptiesleutel is 263447432356645391. De uit deze bewerking resulterende pseudo-identiteit12 wordt opgenomen in een tabel van het medisch dossier en wordt gebruikt voor de toegang tot die tabel. Van Blarkom stelt: "The illegal user accessing the database can't see a relation between the two values, making the database safe against unauthorized access."13 Elke tabel binnen het medisch dossier krijgt zijn eigen pseudo-identificatie toegewezen. Om een afspraak met een zorgverlener te kunnen maken uitgaande van een gegeven in het medisch dossier, bestaat ook de mogelijkheid om softwarematig vanuit de pseudo-identificatie de primaire sleutel van de patiënt te produceren. Door het gebruik van de 'Identity Protectors' worden zoveel als nodig identiteits- en pseudo-identiteitsdomeinen gecreëerd. In figuur 6.10 zijn de gecreëerde domeinen aangeven als rechthoeken, waarbinnen zich de specifieke tabellen bevinden.
Figuur 6.10: Domeinindeling in het ziekenhuisinformatiesysteem. Domein 3 t/m n kan voor wetenschappelijk onderzoek worden gebruikt en bevat geen identificerende gegevens.
De communicatie tussen client en server zorgt voor de geautoriseerde ontsluiting van de tabellen en gegevens. Een client is een applicatie of een computersysteem met toegang tot een ander systeem, de server, via een netwerk. Men spreekt hierbij van een client-servermodel. De client neemt initiatief tot communicatie met de server met als doel bijvoorbeeld het opvragen van gegevens, het overdragen van gegevens of het uitvoeren van een actie op de server. Figuur 6.11 laat de dialoog tussen client (groen) en server (rood) zien:
Figuur 6.11: Dialoog tussen client (groen) en server (rood) Zvl = zorgverlener; seq = sequentie; pid = pseudo-identiteit.
De gekozen oplossing maakt het mogelijk, dat alleen de behandeld arts, zorgverlener of specialist en de patiënt inzage in het hele dossier hebben. De administratie, het laboratorium en de verpleegkundigen hebben slechts inzage in die gegevens uit het patiëntendossier die van belang zijn voor het uitvoeren van hun functies.14 Deze toepassing is als de 'Privacy Incorporated Database' geoctrooieerd.15 De in deze toepassing te gebruiken encryptiesleutels dienen te worden beheerd door middel van een TTP (Trusted Third Party), want voorkomen moet worden, dat als een hacker zich toegang zou kunnen verschaffen tot de computers, dat hij de sleutel op de 'client' van de zorgverlener zou kunnen ophalen en dan alsnog het systeem zou kunnen binnendringen.