Procesbeschrijving migratie naar Mitz voor GBZ-beheerders
Inleiding
Mitz is een online toestemmingsvoorziening waarmee burgers zelf de regie hebben over hun toestemmingskeuzes. Via MijnMitz kunnen zij eenvoudig hun keuzes vastleggen en beheren. Met toestemming kunt u het medisch dossier delen met andere zorgverleners, waardoor de continuïteit van zorg wordt gewaarborgd.
Om gebruik te kunnen maken van Mitz, zijn enkele aanpassingen nodig in het uitwisselingssysteem (US) en in het informatiesysteem (XIS) dat de zorgaanbieder gebruikt. Het LSP is inmiddels aangepast en als de leverancier van een XIS de benodigde aanpassingen heeft doorgevoerd én is gekwalificeerd voor de uitwisseling via Mitz, dan kan deze versie worden uitgerold naar de zorgaanbieder klanten. De zorgaanbieder bepaalt in overleg met hun GBZ-servicedesk het moment waarop het GBZ overgaat naar Mitz. Zodra een zorgaanbieder aangesloten is op Mitz, dan kunnen de patiënten van die zorgaanbieder hun toestemmingskeuzes beheren via http://MijnMitz.nl .
Doelstelling en doelgroep
Dit document beschrijft de procedure die ervoor zorgt dat elke GBZ-beheerder de juiste migratiestappen uitvoert. Deze procedure is primair bedoeld voor GBZ-beheerders. Voor XIS-leveranciers en LSP-beheerders is dit document ter informatie.
Wanneer migreren?
In afstemming met de Migratiemanager kan de GBZ-beheerder met de zorgaanbieders bepalen wanneer een GBZ applicatie gemigreerd kan worden naar een nieuwe versie met Mitz ondersteuning.
Ingangsvoorwaarden voor Migratie naar Mitz
De gebruikte XIS is gekwalificeerd voor Mitz en geïnstalleerd bij de zorgaanbieder
De benodigde TKID wijzigingsberichten zijn aangemaakt en zijn klaar om verstuurd te worden
De zorgaanbieder heeft de ingevulde toestemmingsformulieren en de e-mailberichten in de Vecozo-berichtenbox met betrekking tot toestemmingen vanuit VolgJeZorg verwerkt in de XIS (nb: in Supportal kan, na aanvraag bij Ketenregie, een rapport beschikbaar gesteld worden waarin de status van de getekende contracten per URA nagegaan kan worden)
De zorgaanbieder heeft de betreffende (verwerkers)overeenkomsten getekend met VZVZ
Verantwoordelijkheid zorgaanbieder: de patiënten zijn geïnformeerd over de veranderingen die gaan plaatsvinden in de toestemmingsregistratie http://MijnMitz.nl
Migratie naar Mitz
Hieronder de migratiestappen op hoofdlijnen. Voor de detailbeschrijving zie:
batch
aanmeldberichten
Als aan de ingangsvoorwaarden zijn voldaan dan moeten de volgende stappen worden doorlopen om een bestaande applicatie te migreren:
Versturen van de TKID "Toestemming Migrerend Systeem"
Versturen van alle dossiers inclusief de toestemmingskeuzes
Versturen van de TKID "Toestemming Delegerend Systeem”
Uitzetten van het checken van de lokale toestemmingscontrole en toestemmingsregistratie
Aanzetten aanmelding alle dossiers (in plaats van alleen opt-in dossiers)
Uitvoeren van een Actualiteiten Register synchronisatie (AR-sync)
Beschrijving processtappen
Nb: afhankelijk van de wijze waarop de migratie naar Mitz is ingebouwd in het XIS-pakket zullen sommige van onderstaande stappen geautomatiseerd worden uitgevoerd. Vraag dit indien nodig na bij uw leverancier!
Stap 1: versturen TKID “Toestemming Migrerend Systeem”
Door middel van het versturen van een TKID wordt aangegeven welke systeemrollen een XIS-versie ondersteunt. In het gebruik geeft de TKID aan wat de GBZ (Applicatie-ID) technisch en functioneel kan. Met behulp van TKID “Toestemming Migrerend Systeem” wordt de applicatie in de migratiestand gezet en wordt in de keten bekend gemaakt dat een GBZ bezig is met de overgang naar Mitz.
Nb: bij het wijzigen TKID-bericht dienen altijd al de te registreren TKID’s ingestuurd te worden in hetzelfde bericht!
Als een TKID wissel naar “Toestemming Migrerend Systeem” mislukt (het responsbericht bevat een foutcode) dan kan niet worden gemigreerd. De GBZ-beheerder dient na te gaan waarom de TKID-wissel is fout gegaan en het probleem (laten) oplossen.
Stap 2: versturen toestemmingen en aanmelden gegevens
Alle relevante patiëntdossiers in de GBZ inclusief de lokaal geregistreerde toestemmingen worden verstuurd naar het LSP (Eisen voor welke records mogen worden aangemeld ). Nb: houd rekening met de aanmeldcriteria voor dossiers:
de patiënt toestemmingen worden aangemeld bij Mitz
de patiëntendossiers worden aangemeld in het Actualiteiten Register op het LSP
Tevens wordt een notificatie abonnement bericht verstuurd naar Mitz, in het geval er nog geen abonnement is
Tijdens de migratie wordt een klein aantal fouten geaccepteerd. De migratie kan doorgang vinden zolang het aantal fouten onder de normaantallen blijft.
ZIMMIGABO: Als het aantal records dat niet verwerkt kan worden (fouten in de aanmelding, communicatie met Mitz of toestemming) de normaantallen overschrijdt, dan wordt de migratie automatisch afgebroken en wordt een ZIMMIGABO foutcode teruggestuurd (ziehttps://vzvz.atlassian.net/wiki/x/5Ne_AQ) . Actie: de GBZ-beheerder dient na te gaan waarom de ZIMMIGABO is opgetreden en het probleem (laten) oplossen. Kan het probleem worden opgelost, dan kan de migratie opnieuw worden opgestart. Anders dient de migratie afgebroken te worden.
Stap 3: versturen TKID ‘Toestemming Delegerend Systeem’
Als stappen 2 en 3 foutloos zijn verlopen, dan moet het TKID ‘Toestemming Delegerend Systeem’ worden verstuurd. Als dit TKID op het LSP verwerkt is, dan zal bij al de bevragingen van het betreffende bronsysteem, de toestemming worden gecontroleerd in Mitz. Vanaf dit moment is Mitz leidend.
Als een TKID wissel naar “Toestemming Delegerend Systeem” mislukt (het responsbericht bevat een foutcode) dan wordt de status op het LSP niet op Mitz gemigreerd gezet en mag de lokale applicatie ook niet de status gemigreerd krijgen. De lokale toestemmingscontrole moet dus actief blijven. Actie: de GBZ-beheerder dient na te gaan waarom TKID-wissel mislukt is en het probleem (laten) oplossen. Kan het probleem worden opgelost, dan kan het TKID wijzigingsbericht opnieuw opnieuw verstuurd worden.
Nb1: Als een XIS applicatie de optie heeft ingebouwd om notificaties te ontvangen, dan kan de GBZ-beheerder voor een specifieke applicatie het TKID “Notificaties verwerkend Systeem” meegeven in het wijzigingsbericht. In dat geval worden voor al de dossiers in het GBZ notificaties verstuurd vanuit Mitz, als hier een toestemmingswijziging is doorgevoerd.
Nb2: als een XIS applicatie de dossierhoudersknop heeft ingebouwd, dan kan de GBZ-beheerder voor een specifieke applicatie het TKID “Toestemming Gevend Systeem” meegeven in het wijzigingsbericht. In dat geval kan een zorgaanbieder – samen met de patiënt - toestemming vastleggen voor zichzelf als dossierhouder. Het is een eenvoudige manier van toestemming geven voor het delen van gegevens met andere zorgaanbieders.
Stap 4: uitzetten van het checken van de lokale toestemmingscontrole en van de toestemmingsregistratie
Als het GBZ is gemigreerd naar Mitz dan wordt vanaf dat moment de toestemmingscontrole uitgevoerd in Mitz. De lokale toestemmingscontrole en -registratie dient uitgezet te worden. Het is niet langer toegestaan om gebruik te maken van de lokale toestemmingscontrole. Mitz is vanaf dat moment leidend.
Stap 5: In het XIS de functionaliteit aanzetten voor het aan- en afmelden van nieuwe en gewijzigde dossiers
Als de zorgaanbiederapplicatie is gemigreerd, dan dienen vanaf dat moment al de dossiers (her)aangemeld te worden vanuit het zorgproces. Dus ook de dossiers zonder specifieke opt-in.
Stap 6: uitvoeren van de Actualiteiten Register synchronisatie
De laatste stap in het migratieproces is het uitvoeren van een Actualiteiten Register synchronisatie (AR-Sync). De GBZ-beheerder stuurt al de lokale dossiers naar het LSP waar wordt nagegaan of deze ook allemaal staan geregistreerd in het Actualiteiten Register. Het LSP stuurt een verschilbestand terug welke door de lokale GBZ verwerkt dient te worden. In het geval er verschillen zijn, dan dienen dossiers aan- of afgemeld te worden. (GBX.SYNC.e4010.10 Synchroniseren van de lokale administratie met het ActualiteitenRegister )
stroomschema
Hieronder staan visueel op hoofdlijnen de stappen, acties, beslissingen en de controlestroom beschreven voor het uitvoeren van de migratie voor bestaande applicaties op het LSP