Skip to main content
Skip table of contents

Inleiding Aanbiedermodule

Inleiding

Het Solution Design (SD) vormt het startpunt voor het Ontwikkelteam om de vanuit het Project Start Architectuur (PSA) gevraagde functionaliteit verder te concretiseren. Het SD geeft hierbij een eerste invulling aan de oplossing die binnen de kaders van het PSA verder moet worden uitgewerkt.

Deze uitwerking bevat een aantal stappen om zo zorg te dragen voor de juistheid en volledigheid van het ontwerp.

  • Oplossingsarchitectuur

  • Gedetailleerd ontwerp

Het uiteindelijke gedetailleerde ontwerp beschrijft op detail niveau alle ontwerp-artefacten.

Deze vormen de basis voor de functionele en technische validatie. Het totaal vormt in de Beta-fase de bron voor de uit te schrijven Service Requests.

Doel

Dit document is bedoeld om een gedetailleerd blauwdruk te leveren voor de ontwikkeling en implementatie van Aanbiedermodules Fase 1: binnen de context van het MedMij Afsprakenstelsel.

Het bevat achtergrondinformatie over Fase 1: Aanbiedermodules , identificeert de belangrijkste stakeholders en beschrijft hun verantwoordelijkheden en de raakvlakken binnen het MedMij Afsprakenstelsel. De basis hiervoor ligt vast in de requirements (Business, Functioneel, Non-Functioneel en Beveiliging) en de scope. Verder zijn de belangrijkste architectuur- en ontwerpbesluiten vastgelegd. Dit dient als rode draad voor het high-level design en de gedetailleerde uitwerking zoals opgenomen in dit document.

Dit document is leidend voor de verdere implementatie binnen het afsprakenstelsel. De scope van deze uitwerking is beperkt tot:

  • Fase 1 van de Aanbiedermodules

  • Binnen de context van de Alpha Fase: uitwerking bevat niet de teksten benodigd voor publicatie in het Afsprakenstelsel. Het maken van de benodigde teksten vindt plaats in de Beta Fase.

  • Het versienummer bij deze fase is versie 0.8.

Achtergrond

Het aanbod van (eHealth) modules in de gezondheidszorg is enorm en ontwikkelt zich razendsnel, maar de (technische) mogelijkheden blijven vaak onbenut. Een generieke module interface (leverancier onafhankelijk) zou de zorg helpen om grip te krijgen op de mogelijkheden van de aanbieders (eHealth) modules binnen de gezondheidszorg. Het doel van de (eHealth) modules is om zorgaanbieder/zorgverlener en patiƫnten te helpen om verantwoordelijk de eHealth modules te gebruiken.

De functionaliteiten die worden aangeboden in de aanbiedersmodules die buiten de PGO's staan, maar die wel werken volgens de standaarden die beschreven, worden in het MedMij afsprakenstelsel. Daarmee kunnen de aanbieder modules ook bouwen op het vertrouwen en de interoperabiliteit die MedMij borgt.

Voor het starten van aanbieder modules en het uitwisselen van gezondheidsgegevens moeten nieuwe use cases worden toegevoegd. Hierbij moet ook rekening gehouden worden met de verschillende typen aangeboden modules. 

We beschouwen een (eHealth) module van een zorgaanbieder als een aanbiedersmodule.

De zorgaanbieder ontsluit zijn (eHealth) modules als modulediensten.

Bijvoorbeeld een "Afspraak module" die door een zorgaanbieder wordt aangeboden aan een persoon om een afspraak te kunnen maken bij die zorgaanbieder door een zorgverlener en/of zorgafnemer.

De aanbieder modules zullen op dezelfde manier in MedMij als gegevensdiensten worden gecoƶrdineerd en gepubliceerd. Dat wil zeggen dat zij worden opgenomen in een soort aanbiedersmodule lijst (via generieke functie Adressering), zodat deze op een gestandaardiseerde manier integraal worden opgenomen in het aanbod.

JavaScript errors detected

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

If this problem persists, please contact our support.