Verbind.MedMij (VMM) is een voorziening om personen/patiënten eenvoudig(er) hun zorgaanbieder te laten vinden in MedMij PGO's. Dit wordt bereikt door de Zorgaanbiedernaam via een code opvraagbaar te maken door PGO's en deze code via een QR-code/human-readable url te verspreiden. In de figueren hieronder wordt deze aanpak in twee varianten weergegeven. Het verschil tussen de varianten bestaat uit in hoeverre de VMM componenten deel uit gaan maken van de MedMij backoffice RenA (Registratie en Administratie node), dan wel 'los' worden opgezet.

Uitgangspunten/keuzen (per 20210813):

• Algemeen
  • ZAsleutel:
    • 'Stabiele' identifier voor ZA binnen (en buiten) RenA
  •  ZAcode:
    • ZA 1:N ZAcode
      • VMM component houdt GEEN lijst met 'niet langer valide' ZAcodes vast (geen '410' ondersteuning) (offerte 20210712.002)
        • MVP: GEEN 410 ondersteuning
        • Later wel?
      • Alle onbekende ZAcodes geven 400
    • code kan wel eerder beschikbaar zijn dan 'ZAL entry' (want ZAL kent ingangsdatum)
      • DVZA moet ZAnaam invoeren in RenA voordat deze in VMM gebruikt kan worden
    • ZA moet DVZA hebben én DVZA moet ZA ingevoerd hebben
    • Formaat ZAcode moet nog uitgewerkt:
      • 'google formaat'
      • zoeken naar bibliotheken of open source hiervoor? Voor MVP gaan we uit van cijferreeks conform voorstel offerte 42
  • URL/Code
    • Eénstapsmodel (ZAcode in url/QRcode, GEEN inwisselcode)
• RenA administratie
  • Proces/voorziening om DVP/PGO die binnen MedMij 'inactief' is ook binnen VMM 'inactief' te maken : procesmatig (in ieder geval voor MVP)
  • Er wordt (nog) GEEN gebruik gemaakt van informatie in de RenA over PGO–gegevensdienstkwalificaties
  • Er wordt (nog) GEEN gebruik gemaakt van informatie in de RenA over Zorgaanbieder–gegevensdienstaanbod (ZAL)
  • ZAsleutel
    • identifier voor ZA naast ZAnaam
    • toekomstvaste identifier voor ZA 
  • ZAcode wordt beheerd/aangemaakt in RenA
• VMM component
  • VMM krijgt losse component naast RenA
    • RenA krijgt nieuwe interface voor VMM
    • VMM levert inwisselservice naar PGO's en VMM website
    • VMM levert terugwisselservice naar Bestelportaal (en Beheersite)
  • VMM is verantwoordelijk voor correcte link naar VMM site: ZAurl
    • levert deze door naar Webshop
  • Inwisselservice: PGO toegang
    • Er vindt geen filtering van PGO's plaats (alle MedMij PGO's hebben toegang tot de inwisselservice)
  • ZAurl
    • ZAurl moet via config/menu aanpasbaar zijn in VMM component
    • Alternatieven:
      • verbind.medmij.nl/code/<ZAcode>
      • verbind.medmij.nl/008chars (is probleem voor website bouwer!)
      • Former user (Deleted) gaat uitzoeken welke variant voorkeur heeft
• Webshop
  • Ontvangt via terugwisselservice gegevens (ZAcode, ZAnaam, ZAurl)
  • Genereert QRcode (met daarin VMMwebsite + ZAcode) (CHECK!?)
    • ZAurl (verwijst naar VMM website wordt via terugwisselservice geleverd)
    • ZAurl moet via config/menu aanpasbaar zijn in VMM component
• VMM website  (verbind.medmij.nl)
  • Code/QR inwisseldeel
  • PGO etalage deel
  • PGO beheer (KEUZE: Hoe wordt dit beheer ingericht)
  • Link naar 'PGO keuzehulp' (KEUZE: gaat PGO keuzehulp zelf linken naar PGO's of loopt dit via VMM website)
    • ZAcode wordt meegegeven
  • Link(s) naar PGO
    • ZAcode wordt meegegeven
    • Inlog url
    • Enroll url
  • VRAAG: Wat te doen bij gebruikers met een account in een PGO dat niet aan VMM mee doet?
  • Toegang Controleservice
    • VMM website
    • Afscherming: geen(!), mitigatie dds
  • Toegang inwisselservice
    • DVP's:
      • Basic AUTH/ip whitelisting
      • Later: Op basis van WHL/OCL (Extra vraag aan 42)
    • VMM website: Niet meer (eigen service)
  • Toegang terugwisselservice
    • VMM webshop: Op basis configuratie (basic auth/IP whitelisting/certificaat)
• Rapportage 
  • VMM website gebruik
    • Google analytics
  • Inwisselservice
    • Log-bestanden: Welke ZAcode/ZA door welke DVP/welke ZAcode door de websiste
  • Webshop
    • Google analytics  en/of log-bestand opgevraagd materiaal
  • DVP (buiten scope?)
    • Managementrapportage: Toevoegen aantal AuthReq op basis VMM

Uitwerking

Benodigde componenten/interfaces:

RenA omgeving:

VMM api:

Afweging: 

• ZAcode beheert in RenA
  • Voordeel: Mogelijkheid deze later aan ZAL en ZKL toe te voegen
  • Nadeel: Aanpassingen in RenA nodig 

Verbind.MedMij component

Controleservice

Inwisselservice

Terugwisselservice: lijst

Terugwisselservice: individueel

UC: Als Shop wil ik bij een specifieke  ZorgaanbiederNaam de QR-code/human readable url opvragen, zodat ik een QR-code en human readable url op VMM materialen kan zetten.
Endpoint	Body	Http	Response	Opmerkingen	Moscow
GET <base>/ zorgaanbieders/<ZAnaam>		200 400 (bad request) 404 (not found)	<zorgaanbieder>     <ZAcode>     <ZAnaam>     <VMMurl>	Eén VMMurl ipv twee ZAurl's	M
Toegang
Voor Terugwisselservice wordt webshop 'hard' geconfigureerd; combinatie van: afscherming zelfde methode als inwisselservice: basic auth/ip

Benodigd (in backoffice):

• Registreren van url's (2 per PGO):  inlog-url/aanmeld-url (beide pagina's moeten met de code kunnen werken): HOE KOMEN DIE IN VMM website?
  • Bespreken met Jungle Minds/Product owner
• Informatie voor op de VMM website
• Moet InwisselService bewaken dat alleen 'VMM PGO's' code in kunnen wisselen? NEEN

Nog te doen:

• Uitwerken ontwerp na keuzen
• Valideren of alle 'Must' use cases afgedekt worden
• Uitwerken ontwerp (met name beveiliging) met 42
• Ureninschatting door 42
• Human readable url: hoe kunnen we verbind.medmij/code/abcde laten werken
  • 'code' is nodig om andere paden te kunnen blijven bedienen
  • (mogelijk) tweede variant verbind.medmij/qr/abcde (tbv statistieken)
• Statistieken
  • Website
    • analytics?
  • Webshop
    • analytics?
  • Inwisselservice
    • log van aanroepen (aanroepende partij, ZAcode, response)
  • Terugwisselservice
    • log van aanroepen (aanroepende partij, ZAnaam, response) (overleggen met 42 over slim formaat)
  • DVP
    • Keuze: 
      • optie toevoegen aan managementrapportage in AS
      • aparte log 
      • anders/niet?
  • Na MVP kijken of er behoefte is aan integratie ism CCDA?

Omgevingen (OTAP & such)

• TAP: Nodig voor eigen acceptatie/test-proces
• Integratie-omgeving: Beschikbaar voor deelnemers/webshop leverancier/website leverancier om tegen aan te testen (Inwisselservice, Terugwisselservice)
  • Zandbak: Biedt PGO voordelen om zelf te testen (klein nadeel: PGO kan niet zelf ZA's aanmaken)
  • Aparte I-omgeving
• OpenApi definitie file beschikbaar stellen voor 
  • Inwisselservice
  • Terugwisselservice

Worse case scenario's

Scenario's:

1. ZAnaam wijzigt, PGO kan ZAL niet ophalen (24 uur gat)
2. ZAnaam weg -> code kan niet ingewisseld
   1. Door eigen administratie VMM component kan hier aparte fout voor worden gegeven (410)
3. Code en ZAnaam ok, geen ZAL entry (meer) (moet PGO op kunnen vangen)
   1. Door eigen administratie VMM component kan hier aparte fout voor worden gegeven (410)