Het specificeren van toegang houdt in dat toegangsregels gedefinieerd worden a.d.h.v. systemen en/of personen welke bevoegdheden (toegangsrechten) ze krijgen met betrekking tot welke gegevens (resource) en interacties (functies). Hierbij kan onderscheid gemaakt worden in de bevoegdheden tot het aanmaken (C=Create), lezen (R=Read), wijzigen (U=Update), en verwijderen (D=Delete).
Let op: Hier zit het kunnen lanceren van een applicatie nog niet als interactie toegevoegd, omdat dit geen FHIR interactie is.
Verder:
- We gaan de toegangsregels voor resources in de FHIR Store koppelen aan een (FHIR)
Deviceidentiteit, in plaats van dit namens een gebruiker te doen. Een Device is een gefabriceerd product (applicatie of systeem) dat bij het verlenen van gezondheidszorg gebruikt wordt, zonder dat het door die activiteit substantieel wordt gewijzigd. - De identiteit (
Device.identifier) wordt gemapt op de client_id van de applicatie. - Bij elke interactie, met de FHIR Resource Provider MOET er een toegangstoken meegestuurd worden. In dit toegangstoken staat aangegeven welk Device, zie het veld "azp"- authorized party in het toegangstoken, toegang vraag tot bepaalde resources.
- Toegangstokens worden alleen toegekend aan vertrouwde (en geïdentificeerde)
Devices, die acteren in een bepaalde systeemrol en hiermee wordt de toegang gecontroleerd tot de FHIR Resource Provider. - Elke resource instantie heeft een (
Device) eigenaar, die in het extensie veld 'resource-origin' van een resource wordt vastgelegd. - Wanneer er geen toegang verleend wordt is de response simpelweg "
Unauthorized". Technische details over waarom iets niet mag wordt in de FHIR Store applicatie logs geregistreerd.
De volgende toegangsrechten (scopes) op resources en de daarbij behorende interacties worden toegekend:
- Iedereen (ALL) - Ongeacht wie de resource-origin is.
- Aan vergunners (GRANTED) (Hierbij moet expliciet vermeld worden wie die vergunners of de resource-origin's zijn)
- Eigenaar van de resource (OWN). (Hierbij moet de resource-origin overeenkomen met de vragende Device, zie veld "azp"- Authorized party in toegangstoken)
Bij Koppeltaal 2.0 willen we alleen gecertificeerde (en vervolgens geregistreerde) applicaties of systemen (Devices) machtigen op bewerkingen op een object (resource) waartoe een consument of 'client' toegang wil hebben. De machtigingen zullen gegroepeerd en vastgelegd worden in (systeem/applicatie) rollen. Een (systeem/applicatie) rol kenmerkt de functies die iedereen, een vergunner of eigenaar kan uitvoeren. (Systeem/Applicatie) rollen kunnen worden toegewezen aan 1 of meerdere consumenten (of clients). Elk consument of 'client' krijgt een rol. Als de rol de juiste machtigingen heeft om toegang te krijgen tot een object, krijgt die gebruiker toegang tot het object om zijn bewerkingen op die objecten uit te voeren.
Let op: Indien de juiste machtigingen niet in de (basis) rol zijn vastgelegd, kan een nieuwe rol (eventueel) gedefinieerd worden, waarin wel de juiste machtigingen zijn gedefinieerd.
Terminologieën
Er zijn verschillende soorten termen en specificaties in Koppeltaal voor systemen en/of applicaties. Het is voor de coherentie van de architectuur belangrijk het gebruik van deze verschillende termen nader te specificeren. De volgende specificaties voor de volgende termen gehanteerd:
eHealth. Het gebruik van informatie- en communicatietechnologie ter ondersteuning of verbetering van de gezondheid en de gezondheidszorg.
Client of Consument. Is een gebruiker (persoon of systeem) die een dienst afneemt bij een dienstverlener.
Platform. Een platform is waarmee een (eind)gebruiker interactie heeft om toegang te krijgen tot een op (afstand) gelanceerde of opgestarte programma, module of app. Het platform kan gebruik maken van, of diensten verlenen aan het programma, module of app.
Dienstverlening (Provider). Een programma, module of app die onderdeel is van een activiteit die informatie verzameld en gebruikt in een (zorg)proces.
Portaal. Een toegangspoort of -(verzamel)punt tot informatie over een bepaald onderwerp. Het kan ook worden beschouwd als een bibliotheek met gepersonaliseerde en gecategoriseerde inhoud voor een groep personen die toegang krijgen tot functionaliteiten over of het gebruik van een activiteit.
EPD. Elektronische Patiënten of Client Dossier die informatie bevat over de participanten die betrokken zijn in het zorgproces en die van belang voor het zorgproces.
ROM. Routine Outcome Measurement worden ingezet om voor, tijdens en na het zorgproces te meten wat de conditie/status is van de patiënt of cliënt.
- Zorgverlener. Omvat alle professionelen of instellingen die geneeskundige verzorging verlenen.
(Basis) rollen voorstel voor Koppeltaal v2.0
Voor de toegangscontrole zijn de volgende basis (systeem) rollen gedefinieerd (LET OP: Draft):
- Clientportaal. Is een beveiligde online omgeving waarin een client (de patiënt of derde) inzage heeft in de 'eigen' gegevens die in het informatiesysteem van één zorgverlener staan.
- Behandelaarsportaal. Is een beveiligde online omgeving waarin een behandelaar (zorgverlener) inzage heeft in de voortgang en resultaten van een uitgezette (zorg)behandeling.
- Zorg ondersteuning. Is een beveiligde product die de ondersteuning levert voor de GGZ instelling, zoals het opvoeren van patiënten en behandelaren.
- eHealth Module. Is een module (eventueel ontsloten via een ander platform) die gebruikt of ingezet wordt voor of tijdens een bepaalde behandeling.
- Beheerportaal. Is een beveiligde online omgeving waarin beheerders (technische) configuraties voor Koppeltaal kunnen doorvoeren en beheren.
Een resourceType kan dus aangemaakt (C-Create) worden, uitgelezen (R-Read) worden, aangepast worden (U-Update) of verwijderd worden (D-Delete), door iedereen (ALL), vergunners (GRANTED) of alleen de resource eigenaars (OWN) .
De volgende matrix is een autorisatie matrix, die per (basis) rol de rechten weergeeft op een resourceType die in Koppeltaal 2.0 gebruikt wordt.
Deze autorisatie matrix kan als basis dienen voor het verlenen van rechten aan nieuwe applicaties door ze aan een basisrol te koppelen, om zo toegang te krijgen tot Koppeltaal 2.0, om het vertrouwen in en tussen partijen en organisaties te bevorderen. Het moet inspelen op de behoeften van een breed scala aan organisaties in de zorg. We proberen hiermee inzicht te krijgen in de soort producten, en de omgang tussen de verschillende producten met risico's, zoals reikwijdte, locatie, bedrijfsmiddelen, afhankelijkheden en infrastructuur van Koppeltaal.
Autorisatie Matrix
(Systeem)rol /resourceType | ActivityDefinition | Task | Patient | Practitioner | RelatedPerson | EndPoint | Subscription | CareTeam | Device | AuditEvent |
|---|---|---|---|---|---|---|---|---|---|---|
| Clientportaal | R(ALL) | C(GRANTED), R(GRANTED), U(GRANTED) | R(ALL) | R(GRANTED) | C(OWN), R(OWN), U(OWN) | R(ALL) | R(ALL) | C(OWN), | ||
| Behandelaarsportaal | R(ALL) | C(OWN), R(GRANTED), U(OWN) | R(ALL) | R(ALL) | R(ALL) | R(ALL) | R(ALL) | C(OWN), | ||
| Beheerportaal | C(ALL), R(ALL), U(ALL), D(ALL) | R(ALL), D(ALL) | R(ALL), D(ALL) | C(ALL), R(ALL), U(ALL), D(ALL) | C(ALL), R(ALL), U(ALL), D(ALL) | C(ALL), R(ALL), U(ALL), D(ALL) | C(OWN), R(ALL) | |||
| Zorg ondersteuning | C(OWN), R(OWN), U(OWN) | C(OWN), R(OWN), U(OWN), D(OWN) | C(OWN), R(OWN), U(OWN) | C(OWN), R(OWN), U(OWN), D(OWN) | C(OWN), R(ALL) | |||||
| eHealth Module | C(OWN), R(OWN), U(OWN) | C(GRANTED), R(GRANTED), U(GRANTED) | R(GRANTED) | R(GRANTED) | R(GRANTED) | R(ALL) | C(OWN), |
- De rol 'Clientportaal' mag hier bijvoorbeeld dus Patient gegevens niet direct aanpassen, dat gebeurt dan via de rol 'Zorg ondersteuning'. Anders moeten we elk veld apart gaan autoriseren, wat het clientportaal wel en niet mag.
- De rol 'Beheerportaal' beheren en geven primair de 'Subscription' (abonnementen) uit. De reden waarom dit alleen bij de rol 'Beheerderportaal wordt gelegd zijn:
- Overzicht houden van alle abonnementen binnen een domein
- Het voorkomen van het lekken van indirect informatie via notificatie berichten. Bijvoorbeeld kennis vergaren van hoe vaak bepaalde gebeurtenissen plaatsvinden
- Controle en beheer van endpoints, waar notificaties heen gestuurd worden
- Voorkomen van performance problemen, afhankelijk van: #subscriptions, subcscription.criteria, #gebeurtenissen per tijdseenheid, data volume, etc. Lawine gevaar, doordat twee partijen op één zelfde gebeurtenis geabonneerd zijn en wat dan tot één zelfde gebeurtenis tot gevolg heeft.
- Bij elke interactie wordt het toegangstoken meegestuurd. Deze bevat het veld "azp: Authorized party - the party to which the ID Token was issued". Hiermee kan men de eigenaar (OWN) of vergunner (GRANTED) bepalen.
- Elke resource bevat zelf de informatie over wie de originele eigenaar is van de resource, via het extended element '
resource-origin'. Deze wordt door de FHIR Resource Provider beheerd. - Bij het uitvoeren van een Read (GRANTED) op Task in het Clientportaal wordt "Search Narrowing" toegepast. Zo kan je als client zeggen "Geef mij alle Taken (Tasks)", en geeft de FHIR Resource Provider enkel die taken (Taks) die jij mag zien. Dit is dus bij de toegangsrechten met scope OWN of GRANTED.
- AuditEvent's mogen NOOIT aangepast en/of verwijderd worden. Wordt een aparte procedure voor gemaakt.