Samenvatting
Opmerking vooraf | Deze RFC bouwt voort op RFC0021, die gaat over het uitbreiden van de soorten Aanbieders die, naast Zorgaanbieders, actief kunnen zijn op het MedMij-netwerk. Voor Modulediensten, het onderwerp van deze RFC, geldt dat ook. Ook die moeten kunnen worden aangeboden op het MedMij-netwerk door niet alleen Zorgaanbieders, maar bijvoorbeeld ook door specifieke Module-aanbieders. Daarom maakt deze RFC alvast gebruik van de terminologiewijzigingen die door RFC0021 worden voorgesteld. Het gaat om bijvoorbeeld:
Deze RFC bouwt ook voort op RFC0028, die gaat over verwijzingen in Gegevensdiensten. Dat komt doordat in veel gebruikscontexten van Modulediensten de Persoon van een (Zorg)aanbieder in het kader van een behandeling de taak zal krijgen (Verzamelen) om een Moduledienst te gebruiken. De Gegevensdienst waarmee die taak wordt Verzameld zal dan moeten verwijzen naar de Moduledienst. Naar aanleiding van de lessen uit de consultatiesessie van 10 juli 2020, is besloten deze RFC niet in release 1.3.0 op te nemen, maar op een nader te bepalen later tijdstip te behandelen. |
---|---|
Waarom is deze RFC nodig? | Er is een stijgende vraag naar het omgaan, in MedMij-kader, met Diensten die verder gaan dan alleen het Verzamelen en Delen van gezondheidsgegevens, zoals het aanroepen en gebruiken van e-health-modules voor blended care (in de GGZ en elders), of een e-consultapplicatie. Daarmee kunnen Modulediensten ook bouwen op het vertrouwen en de interoperabiliteit die het MedMij-merk borgt. Bovendien zijn Modulediensten functioneel sterk verbonden met Gegevensdiensten. Om een Moduledienst te kunnen laten werken worden immers gezondheidsgegevens gedeeld met, en/of verzameld van die Moduledienst. Deze wensen zijn actuele items op de strategische roadmap van MedMij. Waar Gegevensdiensten gezondheidsgegevens laten Verzamelen of Delen, doen Modulediensten ook iets met de gegevens. De functionaliteit van een Moduledienst kan geboden worden in de vorm van een app, een website, of anderszins, zolang die functionaliteit maar elektronisch te benaderen is, in de vertrouwenscontext van MedMij. Het gebruik van een Moduledienst door een Persoon levert persoonlijke outputgegevens op, die ook onder de regie van de Persoon moeten vallen. Daarom moet ook het Verzamelen van die outputgegevens door de Aanbieder worden aangeboden, hetzij in de betreffende Moduledienst zelf, hetzij ernaast. Hoewel deze RFC een wezenlijke versterking van het stelsel betreft, verandert het niets aan de posities van de huidige Deelnemers en Zorgaanbieders in het stelsel. Het betreft een wezenlijke uitbreiding van de mogelijkheden, maar geen nieuwe of gewijzigde verplichtingen. Voor de Deelnemers betekent deze RFC bovendien geen implementatie-inspanningen. Die zijn pas aan de orde wanneer een Deelnemer of een Aanbieder een zekere Moduledienst zou willen (laten) implementeren. Dat blijft geheel diens eigen keus. |
Oplossingsrichting | Voor het mogelijk maken van Modulediensten moet het allereerst mogelijk zijn Aanbieders van deze Modulediensten in het stelsel op te nemen, ook als dit geen Zorgaanbieders zijn, en hen te laten bijstaan door Dienstverleners. Hiervoor zij verwezen naar RFC0021. Ten behoeve van Modulediensten stelt deze RFC voor de volgende uitbreidingen op het afsprakenstelsel door te voeren.
|
Aanpassing van |
|
Impact op rollen | Impact op Dienstverleners en AanbiedersVoor de positie van Dienstverleners en Aanbieders in het MedMij Afsprakenstelsel biedt deze RFC nieuwe mogelijkheden en is er alleen sprake van nieuwe verplichtingen voor zover men deze mogelijkheden, naar geheel eigen keus, zou willen benutten. De winst daarvan is dat het aanbieden en afnemen van deze Modulediensten valt onder de vertrouwen- en interoperabiliteitsborging van MedMij. Dat kan een substantiële impuls geven aan zowel het aanbod als het gebruik van kwalitatief hoogwaardige Modulediensten. Dat komt het zorgproces ten goede, maar ook de propositie van Dienstverleners. Dat Modulediensten onder het vertrouwen- en interoperabiliteitskader van MedMij vallen, betekent echter ook dat zij de functionaliteit ervan mogelijk ter beschikking komt voor meerdere Aanbieders en/of Dienstverleners. Dat kan een flinke impact hebben op de concurrentiepositie van een mogelijke Aanbieder of Dienstverlener die deze functionaliteit al inzet als een van de concurrentie onderscheidend element. Vooral menig Dienstverlener persoon zal zich willen onderscheiden met specifieke functionaliteit voor de Persoon. Voor een goed ontwikkelperspectief voor de PGO-markt zal MedMij dergelijke competitie ook kunnen toejuichen. Anderzijds kan de ontwikkeling van deze markt ook stagneren als er vanuit vertrouwen- en interoperabiliteitsperspectief niet in wordt geïntervenieerd. MedMij zal dan dus, met alle betrokkenen, passend beleid moeten (laten) voeren aangaande de opname van specifieke Modulediensten, gebaseerd op actueel inzicht in vertrouwens- en interoperabiliteitsobstakels in de markt. Dat beleid komt tot uiting in het beheer van de Catalogi en de daarin opgenomen Modulediensten (zie RFC0021). Dat beleid moet voortdurend keuzes maken om:
Overigens vindt momenteel, maar dan via Gegevensdiensten, in MedMij al standaardisatie plaats inzake vragenlijsten. Ook deze raakt de bovengenoemde aspecten. |
Impact op beheer | Catalogus-beheer wordt geraakt. |
Impact op RnA | Geen |
Impact op Acceptatie | Geen |
Gerelateerd aan (Andere RFCs, PIM issues) | |
Eigenaar | Paul Oude Luttighuis |
Implementatietermijn | Later dan release 1.3.0 |
Motivatie verkorte RFC procedure (patch) | N.v.t. |
Compliance aan principes van MedMij
Principe | Principe | ||
---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | Positief | 11 Stelselfuncties worden vanaf de start ingevuld | Neutraal |
2 Dienstverleners zijn transparant over de gegevensdiensten | Positief | 12 Het afsprakenstelsel is een groeimodel | Positief |
3 Dienstverleners concurreren op de functionaliteiten | Positief | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | Neutraal |
4 Dienstverleners zijn aanspreekbaar door de gebruiker | Positief | 14 Uitwisseling is een keuze | Positief |
5 De persoon wisselt gegevens uit met de zorgaanbieder | Positief | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | Positief |
6 MedMij spreekt alleen af wat nodig is | Positief | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | Positief |
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | Positief | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | Neutraal |
9 De dienstverleners zijn deelnemers van het afsprakenstelsel | Positief | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | Neutraal |
10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | Positief | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | Positief |
Uitwerking
Ontvangen opmerkingen van Frank Ploeg, d.d. 2 juli 2020
- Het aspect van gegevensintegriteit over domeinen heen en over aanbieders geen zou moeten worden beschouwd.
- De RFC wint aan duidelijkheid als enige use cases, bijvoorbeeld uit Koppeltaal, worden toegevoegd ter illustratie.
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 |
---|---|---|---|---|
Geen |