Samenvatting
| Waarom is deze RFC nodig? | Vaste URL's beschikbaar maken voor zowel de verplichte als de gepubliceerde versie van het afsprakenstelsel. |
|---|---|
| Oplossingsrichting | Introductie van Confluence plug-in waarmee revisie en publicatie beheer, door het ontwikkelteam, gemanaged wordt. |
| RACI |
|
| Aanpassing van | Interne procedure van het MedMij stelseldocumentatie revisie en publicatie proces. |
| Impact op rollen | N.V.T. |
| Impact op beheer | Vaste locatie (URL) voor verplichte en optionele MedMij stelseldocumentatie. |
| Impact op RnA | N.V.T. |
| Impact op Acceptatie | Vaste locatie (URL) voor verplichte en optionele MedMij stelseldocumentatie |
| PIA noodzakelijk | N.V.T. |
| Gerelateerd aan (Andere RFCs, PIM issues) | https://pim.vzvz.nl/browse/AF-1378 |
| Implementatietermijn | Standaard release interval, vanaf versie 1.6 beschikbaar |
| Motivatie verkorte RFC procedure (patch) | N.V.T. |
Uitwerking
Probleem:
Bij nieuwe versies van het afsprakenstelsel veranderen ook de links. De links worden zowel gebruikt in MedMij eigen documentatie als documentatie van deelnemers. Daarmee moet de documentatie bij elke nieuwe versie worden aangepast wat een onnodige beheerlast meebrengt.
Oplossingsrichting
Introductie van Confluence plug-in: Scroll Versions om versie beheer en gecontroleerde publicatie (naar vaste locatie) mogelijk te maken.
Het opzetten van 3 confluence spaces waar vanuit een 'ontwikkelomgeving' gepubliceerd wordt naar de verplichte en optionele MedMij stelsel locaties. (Vaste URL voor Verplicht en Optioneel)
De drie confluence spaces:
- MMontwikkeling, dit is de revisie beheerde ontwikkel omgeving. In deze omgeving kan altijd terug gekeken worden (en opnieuw gepubliceerd worden) naar voorgaande versies)
- MMverplicht, dit is de huidige verplichte versie van het MedMij afsprakenstelsel
- MMoptioneel, dit is de huidige optionele versie van het MedMij afsprakenstelsel
Bij een volgende release van het afsprakenstelsel wordt opnieuw vanuit de MMontwikkeling gepubliceerd naar MMverplicht en MMoptioneel om invulling te geven aan het dakpan release model.
Optioneel: Impact op foutafhandeling (zie https://confluence.vzvz.nl/display/MMAS/Foutmeldingen+MedMij )
Principe's
| Principe | Principe | ||
|---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | 11 Stelselfuncties worden vanaf de start ingevuld | ||
| 2 Dienstverleners zijn transparant over de gegevensdiensten | 12 Het afsprakenstelsel is een groeimodel | ||
| 3 Dienstverleners concurreren op de functionaliteiten | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | ||
| 4 Dienstverleners zijn aanspreekbaar door de gebruiker | 14 Uitwisseling is een keuze | ||
| 5 De persoon wisselt gegevens uit met de zorgaanbieder | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | ||
| 6 MedMij spreekt alleen af wat nodig is | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | ||
| 7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | ||
| 9 De dienstverleners zijn deelnemers van het afsprakenstelsel | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | ||
| 10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | ||
| Toelichting | |||
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
Goedkeuring
| Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
|---|---|---|---|---|---|
| Productmanager Stichting MedMij | Productmanager Beheerorganisatie | ||||
| Leadarchitect Stichting MedMij | Leadarchitect Beheerorganisatie | ||||
| Ontwerpteam | |||||
| Deelnemersraad | Eigenaarsraad |