Page Comparison

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).

...

• eHealth. Het gebruik van informatie- en communicatietechnologie ter ondersteuning of verbetering van de gezondheid en de gezondheidszorg.

• Anchor
  Client Client

  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.

Anchor
ApplicatieRollen ApplicatieRollen

(Basis) rollen voorstel voor Koppeltaal v2.0

Voor de toegangscontrole zijn de volgende basis (systeem) rollen gedefinieerd voor applicaties (LET OP: Draft):

...

• Een rol kan pas aan een applicatie instantie toegekend worden, als de applicatie zich geregistreerd is en een client_id gekregen heeft.
• 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 verwijderen van resources en het primair uitgeven/activeren van 'Subscription' (abonnementen).  De reden waarom dit alleen bij de rol 'Beheerderportaal wordt gelegd zijn:
  • Overzicht houden van alle resources 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. 
  • Deze bevat het veld "sub": Subject -  de (technische) identifier van een gebruiker". Hiermee kan een applicatie instantie (Device) bepaalde logica uitvoeren, afhankelijk van het subject.
• 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.
• Zowel een applicatie in de rol van 'Beheerportaal' als in de rol van 'eHealth Module' kan een ActivityDefinition resource publiceren. Echter de voorkeur gaat uit dat een applicatie in de rol van 'eHealth Module' zijn eigen ActivityDefinition publiceert. 
• Indien een applicatie in de rol van  'eHealth Module'  geen verbinding kan opzetten met de FHIR Resource Server, kunnen de interacties uitgevoerd worden door een applicatie met de rol van 'Beheerportaal', die tevens dan de originele eigenaar is van de aangemaakte resources.
• Een applicatie in de rol van 'eHealth Module' kan geen CRU interacties uitvoeren op de ActivityDefinition resource als deze applicatie niet de originele eigenaar is.
• AuditEvent's mogen NOOIT aangepast en/of verwijderd worden. Wordt een aparte procedure voor gemaakt die ervoor zorgt dat AuditEvents gearchiveerd kunnen worden.

{}