autorisatieverzoek proposal

SUMMARY.md

@@ -2,6 +2,11 @@
 
 * [Bolts](README.md)
 
+## Autorisatieverzoek
+
+* [Overzicht](autorisatie-request/overzicht.md)
+* [Technical description](autorisatie-request/specification.md)
+
 ## eOverdracht
 
 * [Leveranciersspecificatie](eoverdracht/leveranciersspecificatie.md)

autorisatie-request/overzicht.md

@@ -0,0 +1,54 @@
+# Functionele beschrijving autorisatieverzoek
+
+![](../.gitbook/assets/by-sa.png)
+
+_Dit werk valt onder een_ [_Creative Commons Naamsvermelding-GelijkDelen 4.0 Internationaal-licentie_](https://creativecommons.org/licenses/by-sa/4.0/)_._
+
+## 1. Inleiding
+
+Een veel voorkomende vraag bij het uitwerken van een Bolt is of het ook mogelijk is om een patiënt toestemming te laten verlenen op de plek en het moment wanneer dat nodig is. De patiënt zit bijvoorbeeld bij de huisarts en op dat moment is er behoefte om toegang te krijgen tot de gegevens van bijvoorbeeld het ziekenhuis. In het proces moet de patiënt toestemming geven en moet het ziekenhuis een aanvraag tot gegevensdeling beoordelen en, indien er geen bezwaren zijn, inwilligen.
+
+Deze Bolt heeft als doel dat te beschrijven. Dit kan als losstaande use-case gebruikt worden, maar zal meestal onderdeel zijn van een andere Bolt. Deze beschrijving heeft dan ook als doel om als standaard te dienen zodat dit stuk in ieder geval niet voor elke Bolt uitgedacht hoeft te worden. Deze Bolt is alleen bruikbaar voor de gevallen waar expliciete toestemming van de patiënt nodig is.
+
+Dit document is primair bedoeld voor softwareleveranciers die gezamenlijk een Bolt ontwikkelen, en ten behoeve daarvan een implementatietraject gaan starten. Voor hen biedt dit document de noodzakelijke inzichten om tot een succesvolle koppeling te komen. Daarnaast beoogt dit document leesbaar te zijn voor betrokken zorginstellingen, zodat helder wordt of het proces van toestemming vragen zoals dat hier beschreven staat voldoet aan hun wensen.
+
+Dit document is niet volledig. Het is op dit moment een levend document om tussen leveranciers tot werkende afspraken en technische oplossingen te komen. Er zal dus nog het één en ander in gaan veranderen in de komende maanden. Daarnaast is dit document ook vooral een index: op veel plekken zal het refereren naar bestaande standaarden en andere documentatie. Zo houden we dit document beknopt en leesbaar, en kunnen we de documentatie waar we naar verwijzen ook weer hergebruiken voor andere Bolts.
+
+### 1.1 Verklarende woordenlijst
+
+* Nuts — Een samenwerkingsverband van partijen in de zorg om tot een breed gedragen, open, decentrale infrastructuur te komen voor de uitwisseling van gegevens in de zorg en het medische domein. Zie [www.nuts.nl](http://www.nuts.nl).
+* Bolt — Een praktische toepassing van het Nuts gedachtegoed en open technologie om een tastbare usecase in de zorg mogelijk te maken.
+* Bronhouder — De zorginstelling die gegevens over de patiënt heeft en de aanvraag voor gegevensdeling moet controleren.
+* Aanvrager — De zorginstelling die gegevens over de patiënt wil inzien en een autorisatie verzoek indient.
+* Grondslag — Een wettelijke basis voor het mogen doorbreken van het beroepsgeheim van de bronhouder.
+
+## 2. Procesbeschrijving
+
+Met deze specificatie ondersteunen we het proces dat een zorgverlener in naam van een zorgorganisatie een andere zorgorganisatie kan verzoeken om gegevens van een bepaalde patiënt te delen. De patiënt heeft hiertoe toestemming gegeven aan de aanvrager. De bronhouder dient deze aanvraag te beoordelen en kan daarna besluiten om over te gaan tot gegevensdeling.
+
+### 2.1 Het geven van toestemming
+
+Een aanvrager kan niet een verzoek indienen zonder daarvoor de goedkeuring van de patiënt te hebben gekregen. De manier waarop een patiënt toestemming kan geven is vastgelegd in de WGBO. De aanvrager zal de wijze van toestemming moeten vastleggen in het dossier van de patiënt. Dit kan bijvoorbeeld een document zijn dat door de patiënt is ondertekend, de welbekende natte handtekening. De vorm is hierbij ondergeschikt aan de inhoud. Het is belangrijk dat de reden voor de aanvraag van toestemming en beschrijving van hoe er toestemming is verleend opgeslagen wordt in het dossier. De aanvrager moet bij het vragen van toestemming ook duidelijk aangeven wat de scope van de toestemming is. Deze moet proportioneel zijn en aansluiten bij een of meerdere specifieke Bolts.
+
+### 2.2 Indienen autorisatieverzoek
+
+Wanneer de zorgverlener de toestemming heeft verkregen is het de taak van het systeem van de aanvrager om deze toestemming om te zetten naar een technisch verzoek aan het systeem van de bronhouder. De [technische specificatie](specification.md) beschrijft hoe de systemen dit moeten implementeren. Een verzoek wordt altijd in de context van één bepaalde Bolt gedaan.
+
+### 2.3 Beoordelen
+
+De bronhouder zal elk autorisatieverzoek moeten beoordelen. Dit kan automatisch gedaan worden o.b.v. bepaalde regels, maar het zou ook kunnen dat een zorgverlener er naar moet kijken. Dit is van veel factoren afhankelijk. Wanneer een Bolt gebruik wil maken van deze specificatie, dan zal het een apart hoofdstuk moeten opnemen over onder welke condities automatisch of handmatig een verzoek goedgekeurd kan worden. Enkele voorbeelden ter illustratie:
+
+* een patiënt is tussen de 12 en 16 jaar, dit vereist toestemming van zowel patiënt als ouder/voogd.
+* er is een mentorschap toegewezen door de rechtbank.
+* het dossier bevat gegevens die schadelijk kunnen zijn voor derden.
+* de patiënt is niet wilsbekwaam voor het geven van toestemming.
+
+Hoe het systeem van de bronhouder omgaat met deze condities is aan de zorgorganisatie en zijn leverancier. Een mogelijke oplossing is dat het systeem van de bronhouder altijd automatisch een verzoek goedkeurt tenzij een zorgverlener dit uitgeschakeld heeft.
+
+### 2.4 Afronden
+
+Nadat het verzoek is goedgekeurd zal het systeem van de bronhouder een autorisatie aanmaken binnen de scope die gevraagd is. De benodigde technische gegevens worden automatisch verstuurd naar de aanvrager via het Nuts netwerk. 
+
+## 3. Intrekken
+
+Het kan natuurlijk voorkomen dat de patiënt zijn toestemming intrekt. Wanneer de patiënt de aanvrager verzoekt om de toestemming in te trekken, zal deze een intrekking versturen over het Nuts netwerk waarin de oorspronkelijke toestemming (verwijzing naar) ingetrokken wordt. Het systeem van de bronhouder wordt op de hoogte gesteld van deze intrekking door het Nuts netwerk. De uitgegeven autorisatie zal dan ook ingetrokken worden door de bronhouder. Omdat de toestemming via een papieren proces is afgehandeld bij de aanvrager, vereist dit wel medewerking van de aanvrager. Er blijft natuurlijk ook altijd de mogelijkheid voor de patiënt om rechtstreeks bij de bronhouder aan te geven gegevens niet meer te willen delen.

autorisatie-request/specification.md

@@ -0,0 +1,138 @@
+# Technical specification authorization request
+
+![](../.gitbook/assets/by-sa.png)
+
+_This work is licensed under a_ [_Creative Commons Attribution-ShareAlike 4.0 International Licence_](https://creativecommons.org/licenses/by-sa/4.0/)_._
+
+## 1. Introduction
+
+The [functional description (nl)](overzicht.md) describes the process around an authorization request. This document aims to be a complete specification for developers to implement an authorization request.
+
+### 1.1 Terminology
+
+* Nuts — A community in Dutch healthcare for creating an open, decentralized infrastructure for the transfer of data in the medical domain. See [www.nuts.nl](http://www.nuts.nl).
+* Bolt — A practical application of Nuts ideology and open standards to facilitate a use-case in healthcare.
+* Custodian — The care organization that has patient data
+* Subject — The patient giving consent.
+* Actor — The care organization that requests access to patient data.
+
+## 2. Service registration
+
+A care organization that wants to process an authorization request MUST register a service according to [RFC006](https://nuts-foundation.gitbook.io/drafts/rfc/rfc006-distributed-registry) of the Nuts specification:
+
+```javascript
+{
+  "id": "did:nuts:organization_identifier#F1Dsgwngfdg3SH6TpDv0Ta1aOE",
+  "type": "authorization-request", 
+  "serviceEndpoint": {
+    "oauth": "https://nuts.example.com/n2n/auth/v1/accesstoken",
+    "consent": "https://api.example.com/requests"
+  }
+}
+```
+
+The `type` must be `authorization-request`. The `id` must be set according to RFC006. The `serviceEndpoint` must contain the fields `oauth` and `consent`. 
+The `oauth` field must refer to an endpoint where the `serviceEndpoint` points to the `accesstoken` endpoint of an OAuth authentication server. The `consent` field must refer to an endpoint where the `serviceEndpoint` points to a URL that accepts the http POST message as specified in [§4](specification.md#4-consent-processing). Service references may be used instead of absolute endpoints as specified in [§4.1 of RFC006](https://nuts-foundation.gitbook.io/drafts/rfc/rfc006-distributed-registry#4.1-service-references).
+
+## 3. Consent registration
+
+### 3.1 NutsConsentCredential
+The actor MUST create a Verifiable Credential containing the requested scope and proof of the consent. The exact contents of the credential is described in RFC018. Below is an example of a `NutsConsentCredential`.
+
+```javascript
+{
+  "@context": [
+    "https://www.w3.org/2018/credentials/v1",
+    "https://nuts.nl/credentials/v1"
+  ],
+  "id": "did:nuts:EgFjg8zqN6eN3oiKtSvmUucao4VF18m2Q9fftAeANTBd#90382475609238467",
+  "type": ["VerifiableCredential", "NutsConsentCredential"],
+  "issuer": "did:nuts:EgFjg8zqN6eN3oiKtSvmUucao4VF18m2Q9fftAeANTBd",
+  "issuanceDate": "2010-01-01T19:53:24Z",
+  "expirationDate": "2010-02-01T19:53:24Z",
+  "credentialSubject": {
+    "id": "did:nuts:EgFjg8zqN6eN3oiKtSvmUucao4VF18m2Q9fftAeANTBd",
+    "custodian": "did:nuts:SjkuVHVqZndMVVJwcnUzbjhuZklhODB1M1M0LW9LcWY0WUs5S2",
+    "purposeOfUse": "zorginzage",
+    "subject": "123456780"
+  },
+  "proof": [
+    {
+      "proof": {
+      "type": "EcdsaSecp256k1Signature2019",
+      "created": "2010-01-01T19:53:24Z",
+      "verificationMethod": "did:nuts:EgFjg8zqN6eN3oiKtSvmUucao4VF18m2Q9fftAeANTBd#234906587jfglout",
+      "proofPurpose": "assertionMethod",
+      "proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndSayn1PzZs6ZjWp1CktyGesjuTSwRdoWhAfGFCF5bppETSTojQCrfFPP2oumHKtz"
+    },
+    {
+      "type": "NutsPaperProof2022",
+      "created": "2010-01-01T19:53:24Z",
+      "expires": "2010-02-01T19:53:24Z",
+      "description": "client signed document, filed under #803465."
+    }
+  ]
+}
+```
+
+The DID of the actor MUST both be present in the `issuer` and `credentialSubject.id` fields. The `credentialSubject.custodian` field contains the DID of the custodian, which is also the endpoint owner the request will be sent to. The `purposeOfUse` field MUST correspond to one of the purposes of use stated by Bolts. The `subject` MUST contain the citizen service number. The credential contains two proofs. One is a regular proof from the issuer, the other is a `NutsPaperProof2022` which contains the `description` on how consent is given by the patient.  
+
+The credential MAY NOT be published on the Nuts network. It stays at the Nuts node of the issuer.
+
+### 3.2 VerifiablePresentation
+
+The credential from the previous paragraph can be used by the actor to create a verifiable presentation. This presentation may contain additional credentials if needed. The presentation will be the body of the request. The request MUST be sent to the URL registered under the `consent` field of the `authorization-request` service of the `custodian`. 
+
+The endpoint MUST be protected with mTLS as described by [RFC008](https://nuts-foundation.gitbook.io/drafts/rfc/rfc008-certificate-structure) of the Nuts specification. It also requires an access token as described in [RFC003](https://nuts-foundation.gitbook.io/drafts/rfc/rfc003-oauth2-authorization). When requesting an access token, the `usi` and `vcs` fields are not needed. `authorization-request` MUST be entered in the `purposeOfUse` field. The access token request endpoint is registered under `oauth` in the  `authorization-request` service registration.
+
+## 4. Consent processing
+
+The custodian that receives the request MUST check the access token and the verifiable presentation validity. It can use the information in the `NutsConsentCredential` to identify the correct dossier and use the available information to determine if the request should be granted. This could also be a human process.
+
+If the request is granted, the custodian MUST create a `NutsAuthorizationCredential` like the one below:
+
+```javascript
+{
+  "@context": [
+    "https://www.w3.org/2018/credentials/v1",
+    "https://nuts.nl/credentials/v1"
+  ],
+  "id": "did:nuts:SjkuVHVqZndMVVJwcnUzbjhuZklhODB1M1M0LW9LcWY0WUs5S2#903824934578638467",
+  "type": ["VerifiableCredential", "NutsAuthorizationCredential"],
+  "issuer": "did:nuts:SjkuVHVqZndMVVJwcnUzbjhuZklhODB1M1M0LW9LcWY0WUs5S2",
+  "issuanceDate": "2010-01-01T19:54:24Z",
+  "expirationDate": "2010-02-01T19:54:24Z",
+  "credentialSubject":
+  {
+    "id": "did:nuts:EgFjg8zqN6eN3oiKtSvmUucao4VF18m2Q9fftAeANTBd",
+    "legalBase": {
+      "consentType": "explicit",
+      "consentRef": "did:nuts:EgFjg8zqN6eN3oiKtSvmUucao4VF18m2Q9fftAeANTBd#90382475609238467"
+    },
+    "purposeOfUse": "zorginzage",
+    "subject": "123456780"
+  },
+  "proof": {
+    "type": "EcdsaSecp256k1Signature2019",
+    "created": "2010-01-01T19:73:24Z",
+    "verificationMethod": "did:nuts:SjkuVHVqZndMVVJwcnUzbjhuZklhODB1M1M0LW9LcWY0WUs5S2#234906587jfglout",
+    "proofPurpose": "assertionMethod",
+    "proofValue": z58DAdFfa9SkqZMVPxAQpic7ndSayn1PzZs6ZjWp1CktyGesjuTSwRdoWhAfGFCF5bppETSTojQCrfFPP2oumHKtz"
+}
+```
+
+The following table shows how fields from the `NutsAuthorizationCredential` are mapped from the `NutsConsentCredential`:
+
+| NutsAuthorizationCredential             | NutsConsentCredential          |
+|-----------------------------------------|--------------------------------|
+| issuer                                  | credentialSubject.custodian    |
+| expirationDate                          | expirationDate                 |
+| credentialSubject.id                    | issuer                         |
+| credentialSubject.legalBase.consentType | explicit                       |
+| credentialSubject.legalBase.consentRef  | id                             |
+| credentialSubject.purposeOfUse          | credentialSubject.purposeOfUse |
+| credentialSubject.subject               | credentialSubject.subject      |
+
+The issuer of the `NutsAuthorizationCredential` may also limit the resources the credential gives access to using the `credentialSubject.resources` field. This is specific for a Bolt on how to do this.
+
+The resulting credential is published by the issuer, the actor identified by `credentialSubject.id` MUST be one of the recipients. The node of the actor will receive the credential and will then be able to notify users.