Samenvatting
| Waarom is deze RFC nodig? | Het afsprakenstelsel ging voor release1.3.0 uit van dat foutafhandeling rondom authenticatie zonder gebruikersinteractie kon worden afgehandeld bij de DVZA. In de praktijk echter leiden eisen van authenticatievoorzieningen ertoe dat authenticatie en foutafhandeling door de DVZA worden afgehandeld. Om een eenduidige gebruikersinterface naar de zorggebruiker te krijgen zijn daarom in release 1.3.0 een landings- en annuleringsscherm toegevoegd. Foutmeldingen bij authenticatie worden zo opgevangen binnen de userinterface van de autorisatieserver. Met de huidige implementatie krijgt de DVP geen signaal bij het uitblijven of mislukken van authenticatie. De gebruikerservaring in de PGO kan daarmee negatief worden beïnvloed omdat nodeloos gewacht wordt op een autorisatie. Een tweede issue die moet worden opgelost is de situatie waarin een ontvankelijkheidstoets of een beschikbaarheidstoets in de autorisatieserver negatief is. In dit geval wordt in het huidige afsprakenstelsel de gebruiker met een "access denied" teruggestuurd naar haar PGO. DigiD vereist echter dat eerst een pagina moet worden getoond vanaf het domein van de autorisatieserver. Een dergelijke pagina zou de volgende tekst kunnen bevatten:
|
|---|---|
| Oplossingsrichting | Op zowel de landingspagina en annuleringspagina een knop toevoegen waarmee de gebruiker terug kan keren naar de PGO zonder zich geauthentiseerd te hebben. Dit resulteert dan in uitzonderingssituatie 2 op het Authorization Interface. |
| Aanpassing van | Verplichte schermen (in het Afsprakenstelsel) |
| Impact op rollen | DVZA (met name), DVP |
| Impact op beheer | geen |
| Impact op RnA | geen |
| Impact op Acceptatie | Ja, nieuwe flow heeft impact op testscripts |
| Gerelateerd aan (Andere RFCs, PIM issues) | |
| Eigenaar | |
| Implementatietermijn | 1.4.0 |
| Motivatie verkorte RFC procedure (patch) |
Goedkeuring
| Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
|---|---|---|---|---|---|
| Productmanager Stichting MedMij | Productmanager Beheerorganisatie | ||||
| Leadarchitect Stichting MedMij | Leadarchitect Beheerorganisatie | ||||
| Ontwerpteam | |||||
| Deelnemersraad | Eigenaarsraad |
Principe's
| Principe | Principe | ||
|---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | NvT | 11 Stelselfuncties worden vanaf de start ingevuld | NvT |
| 2 Dienstverleners zijn transparant over de gegevensdiensten | NvT | 12 Het afsprakenstelsel is een groeimodel | Neutraal |
| 3 Dienstverleners concurreren op de functionaliteiten | NvT | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | Positief |
| 4 Dienstverleners zijn aanspreekbaar door de gebruiker | NvT | 14 Uitwisseling is een keuze | Positief |
| 5 De persoon wisselt gegevens uit met de zorgaanbieder | Positief | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | Neutraal |
| 6 MedMij spreekt alleen af wat nodig is | Neutraal | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | Neutraal |
| 7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | NvT | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | NvT |
| 9 De dienstverleners zijn deelnemers van het afsprakenstelsel | NvT | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | NvT |
| 10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | NvT | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | Positief |
Uitwerking
Vervangen op communicatie → landingspagina van het scherm door:
Vervangen op communicatie → annuleringspagina van het scherm door:
Risico's
Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.
| Dreiging | Kans | Impact | DreigingsID (intern) | Maatregelen |
|---|---|---|---|---|
Bijlagen