Autorisatie structuren
Hoe kan binnen een ziekenhuis informatiesysteem (ZIS) de toegang tot de informatie zodanig worden geregeld dat alleen personen met een behandelrelatie/contact met de patient deze mogen inzien, toevoegen, wijzigen of zelfs verwijderen? De autorisatiesstructuur binnen het ZIS moeten dusdanig zijn dat dit eenvoudige van opgezet is als ook overzichtelijk beheer eromheen. Indien ZIS autorisaties in een groepenstructuur zijn onder te brengen is dit realiseerbaar.
In een autorisatiegroep wordt aangegeven welke rechten en functionaliteiten aan een groep gebruikers worden gegeven. Als voorbeeld wordt hier een poli-medewerker van het specialisme Algemene Chirurgie (ACH) gebruikt. Deze medewerker maakt over het algemeen gebruik van het plannen en afwerken van een agenda met patientafspraken. De medewerkers zal toegang krijgen tot het agendasysteem om afspraken te mogen boeken. Het is noodzakelijk om hier de behandelrelatie/contact tot uitdrukking te laten komen. Dit betekent dat de medewerker alleen toegang krijgt tot die agenda(s) waarin de patienten worden geboekt die voor het betreffende specialisme gelden. De rechten die de medewerker binnen de agenda krijgt zal minimaal het plannen en het verplaatsen van een afspraak zijn. Het verwijderen van een afspraak kan mogelijk niet tot haar profiel worden gerekend maar juist aan de leidinggevende binnen de poli.
Een groot voordeel is als een ZIS de mogelijkheid biedt om rechten over te erven. D.w.z.: De rechten binnen een IZIS worden in verschillende groepen (autorisatiegroepen) ondergebracht). Wanneer een nieuwe groep 'lid' wordt gemaakt van een reeds bestaande groep, worden automatisch de rechten van de oudere groep door de nieuwe groep overgenomen (overge-erft). Door deze mogelijkheden kan de implementatie van de autorisatie volgens het drie lagen model worden toegepast:
1) De benodigde functionaliteiten;
2) De werkcontext waarbinnen toegepast;
3) De gebruikers.
In de eerste laag wordt een groep gemaakt waarin alle benodigde functionaliteiten zijn ondergebracht. Zoals in het bovenstaande voorbeeld het plannen en verplaatsen van een afspraak. Deze laag is dusdanig van opzet dat deze functionaliteiten bevat die door alle polimedewerkers kan worden gebruikt. Dus niet alleen voor ACH maar ook voor Inwendige geneeskunde (INT), Orthopedie (ORT), Cardiologie (CAR) etc..
Laag twee is bedoeld om de context te regelen waarbinnen de in de eerste laag gedefinieerde functionaliteiten worden gebruiken. Laag twee maakt dus gebruik van laag een (overerven) en maakt gebruik van plannen en verplaatsen. Echter voor ACH mag alleen gebruik worden gemaakt van die agenda's die voor ACH van toepassing zijn. Dus de werkcontext waarbinnen de eerder opgegeven functionaliteiten mag worden gebruik dient op ACH te worden afgestemd. Naast dat er een groep wordt gemaakt voor ACH zal ook een aparte groep voor INT, ORT en CAR worden gemaakt.
De derde laag zijn de gebruikers die toegang krijgen tot de functionaliteiten binnen de werkcontext door hun lid te maken van de in de tweede laag gedefinieerde groep.
Deze opzet is flexibel doordat eenvoudig nieuwe groepen op werkcontext laag kunnen worden gemaakt en dat een groep gebruikers dezelfde functionaliteit binnen de juiste werkcontext krijgen. Verder dienen de gebruikers alleen aan een groep te worden toegevoegd waarna ze meteen de juiste werkontext bezitten. Aan de andere kant kan deze opzet ook bewerkelijk worden indien in de eerste laag een functionaliteit wordt toegevoegd. Dit betekent dat in alle groepen in laag twee voor de nieuwe functionaliteit de werkcontext moet worden ingesteld. Maar de ervaring leert dat eenmaal ingestelde functionaliteit bijna niet zal veranderen en dat de inspanning eenmalig is.
Terug