Skip to main content
Skip table of contents

Uitgewerkte usecases Aanbiedermodule

Functionele use cases

In dit hoofdstuk beschrijven we de functionele use cases voor de functie Module gebruik.

Bij de diverse usecases is er sprake van een lijst met modules. Hoe deze lijst tot stand komt en welke informatie de lijst bevat, wordt uitgewerkt in de Generieke Functie Adressering

We beschrijven functionele use cases door in te gaan op het doel, de pre- en postcondities. Er zijn voor elke use case 3 standaard exceptie scenario's die buiten de beschreven exceptie scenario's bestaan. Deze exceptie scenario’s kunnen voorkomen bij elke vorm van berichtenverkeer tussen systemen. Elk bericht moet voldoen aan de RFC 2616 standaard, zoals die beschreven staan in hoofdstuk 6.1.1 van het RFC 2616 protocol. De volgende 3 exceptie scenario’s kunnen generiek voorkomen in elke use case en tonen we niet bij de individuele use cases:

  1. Verbinding tussen systemen kan niet tot stand worden gebracht. Dit houdt in dat systemen niet kunnen uitwisselen en er geen berichtenverkeer plaatsvindt.

  2. De opbouw van het bericht is niet naar verwachting. Elk bericht bevat velden die op een bepaalde manier gevuld moeten worden. Wanneer er velden ontbreken kan het bericht niet correct verwerkt worden.

  3. De inhoud van het bericht is niet naar verwachting. In dit exceptie scenario zijn de velden in het bericht wel naar verwachting ingericht, maar zijn ze leeg of incorrect.

Daarnaast visualiseren we in een activiteiten diagram de interacties tussen de betrokken rollen. De beschrijving van de rollen en de bijbehorende verantwoordelijkheden is te vinden in het hoofdstuk “Rollen, Functies, verantwoordelijkheden”.

Ophalen en starten Aanbiedermodule

1. Persoon haalt de beschikbare Aanbiedermodules op

Korte beschrijving

Het totale beschikbare aanbod van Aanbiedermodules binnen het MedMij netwerk moet voor de PGO gebruiker toegankelijk worden gemaakt door alleen die Aanbiedermodules te tonen die voor de geselecteerde Zorgaanbieder beschikbaar zijn. Dit betekent dat vanuit het totaal van Aanbiedermodules een deelverzameling wordt gepresenteerd op basis van de Zorgaanbieder selectie door de PGO gebruiker. In de PGO kunnen meerdere Zorgaanbieders zijn opgenomen, waarmee er ook meerdere deelverzamelingen van Aanbiedermodules zijn.

Use case diagram

  • Doel: Voor de PGO gebruiker presenteren van een, voor één specifieke Zorgaanbieder, gefilterd overzicht van Aanbiedermodules.

  • Precondities

    • De PGO gebruiker is ingelogd

    • De PGO gebruiker heeft één Zorgaanbieder geselecteerd

    • De PGO DVP heeft een gefilterd overzicht van Aanbiedermodules voor de geselecteerde zorgaanbieder beschikbaar

  • Postcondities

    • De PGO gebruiker heeft een overzicht met beschikbare Aanbiedermodules die vanuit zijn PGO gestart kunnen worden. Let op: dit overzicht is niet gepersonaliseerd.

    • De (meta)informatie is voor de PGO beschikbaar om een FHIR Smart-App Launch te kunnen uitvoeren

  • Exceptie scenario’s

    • Een zorgaanbieder biedt geen modules aan.

Activity Diagram

Stappen:

  1. De PGO laad de actuele Aanbiedermodule lijst

  2. De Persoon selecteert 'Bekijk Aanbiedermodules' functionaliteit

  3. De Persoon selecteert ‘Zorgaanbieder’ uit het actuele overzicht van Zorgaanbieders in zijn PGO

  4. De DVP filtert op basis van geselecteerde Zorgaanbieder de Aanbiedermodules:

  5. De DVP toont Filter resultaat en toont optie om uit de getoonde resultaten een Aanbiedermodule te starten.

2. Start specifieke Aanbiedermodule bij een Zorgaanbieder

Korte beschrijving

De PGO gebruiker selecteert uit het overzicht van de bij de Zorgaanbieder beschikbare Aanbiedermodules de Aanbiedermodule. Dit initieert de start van de Aanbiedermodule bij de Zorgaanbieder. De DVA faciliteert dit proces op technisch niveau door gebruik te maken van de FHIR smart-app launch standaard. De DVA zorgt hierbij namens de Zorgaanbieder voor authenticatie en autorisatie (toegangsbeheer). Bij afronden/afsluiten van de Aanbiedermodule komt de gebruiker terug in zijn PGO

Use case diagram

  • Doel: Het kunnen gebruiken van de Aanbiedermodule nadat deze vanuit de gebruikers PGO is opgestart.

  • Korte beschrijving: De PGO gebruiker selecteert uit het overzicht van de bij de Zorgaanbieder beschikbare Aanbiedermodules de Aanbiedermodule. Dit initieert de start van de Aanbiedermodule bij de Zorgaanbieder. De DVA faciliteert dit proces op technisch niveau door gebruik te maken van de FHIR smart-app launch standaard. De DVA zorgt hierbij namens de Zorgaanbieder voor authenticatie en autorisatie (toegangsbeheer). Bij afronden/afsluiten van de Aanbiedermodule komt de gebruiker terug in zijn PGO

  • Precondities:

    • Actueel overzicht van Zorgaanbieder Aanbiedermodules beschikbaar in PGO

    • Zorgaanbieder faciliteert Aanbiedermodule FHIR smart-app launch standaard

  • Postcondities:

    • Na beëindiging van Aanbiedermodule gebruik is de PGO gebruiker terug in zijn PGO.

Activity diagram

Stappen:

  1. Persoon selecteert Aanbiedermodule voor gebruik

  2. DVP gebruikt FHIR smart-configuration endpoint om connectie en functionele informatie te verkrijgen

  3. De Dienstverlener aanbieder ontvangt een verzoek tot autorisatie (dit proces verloopt zoals beschreven in het huidige MedMij afsprakenstelsel. Er kan hier dus gebruik gemaakt worden van de langdurige toestemming die bestaat of afgegeven wordt voor de uitwisseling tussen PGO en de DVA-Zorgaanbieder combinatie.

  4. Indien sprake van langdurige toestemming:

    1. gebruik Aanbiedermodule functionaliteit

    2. beëindig Aanbiedermodule functionaliteit

    3. keer terug naar PGO

  5. Indien nog geen sprake is van langdurige toestemming:

    1. De Dienstverlener aanbieder volgt de procesgang van de functie Autoriseren zonder geldige langdurige toestemming en daarna kan de Persoon Aanbiedermodule functionaliteit gebruiken

    2. Autorisatie proces faalt, de Persoon keert terug naar zijn PGO

Loggen

3. Log interacties

Korte beschrijving

De stappen die nodig zijn voor het gebruik van Aanbiedermodules worden door de DVA en de DVP gelogd. Deze loggegegevens dienen door de DVA en de DVP aan het logcomponent aangeboden te worden. Na het ontvangen dient het logcomponent de aangeleverde logdata te verwerken.

Use case diagram

  • Doel: het vastleggen van gebeurtenissen. Details van deze use case staan beschreven in Logging Aanbiedermodule.

  • Precondities

    • Iedere functionele use case heeft logging ingeregeld.

  • Postcondities

    • De logserver heeft de benodigde en afgesproken events ontvangen.

  • Exceptie scenario’s

    • -

  • Alternatieve scenario’s

    • -

Activity Diagram

Stappen:

  1. De actor maakt contact met de loggingscomponent.

  2. De actor autoriseert en authentiseert zichzelf bij het logcomponent om loggegevens te mogen aanbieden.

  3. De actor biedt loggegevens aan aan de loggingscomponent.

  4. De loggingscomponent verwerkt de aangeboden loggingsgegevens.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.