Bijlage Migratie met aanmeld bericht

Dit hoofdstuk beschrijft de migratie met behulp van het aanmeld bericht

Samenvatting

Detail Overzicht

Inleiding

Op deze pagina wordt een alternative manier van migreren uitgewerkt. Deze manier heeft 2 voordelen:

1. het is niet nodig om een nieuw migratie bericht te maken

2. Het proces kan op de achtergrond lopen, zonder dat het de huidige bedrijfsvoering stoort.

Aangeven beginnen met Migreren

Voordat een systeem op migrerend kan worden gezet, wordt er eerst gecontroleerd of de zorgaanbieder (URA) wel een nieuw contract heeft getekend.
Die wordt rechtstreeks gecontroleerd in het dienstenportaal (is nog in ontwikkeling)

Whitelist

Zolang het niet mogelijk is om een controlle te doen bij het ZORG-AB, moet er wel een mechanisme worden opgezet om deze controlle te kunnen uitvoeren.

Hiervoor wordt er gebruik gemaakt van een whitelist tabel, die per dag wordt bijgewerkt vanuit de contract administratie.

De whitelist tabel bevat de volgende gegevens:

1) URA

2) Contractcode

Omdat er meerdere contracten (kunnen) worden afgesloten kan de URA meerdere malen voorkomen met verschillende contract codes.

Met het SIC moet worden afgestemd op wat voor manier de gegevens kunnen worden aangeleverd, zodat ze op een eenvoudige (automatische) manier in de whitelist kunnen komen.

Aanmelden systeemrol "Toestemming migrerend Systeem"

Als er een error optreed bij het zetten van de systeemrol  "Toestemming Migrerend systeem", moet er in de omschrijving worden aangegeven wat het probleem is:

1. Systeem is al gemigreerd, kan niet via een TKID terug worden gezet (ALREADYMIGRATED)
   
2. Er is geen contract gevonden voor deze URA (NOTCONTRACTED)
   
3. Systeem is al bekend als "Toestemming Migrerend systeem" (ALREADYMIGRATING)
   

Aanmelden systeemrol "Toestemming Delegerend Systeem"

Als er een error optreed bij het zetten van systeemrol "Toestemming Delegerend Systeem", moet er in de omschrijving worden aangegeven wat het probleem is:

1. Systeem staat niet in "Toestemming Migrerend Systeem" (NOTMIGRATING)

Vergeten "Toestemming Delegerend Systeem" als Systeem Gemigreerd is

Als een systeem de systeemrol  "Toestemming Delegerend Systeem" heeft en er wordt een update van de TKID gedaan waar deze systeemrol niet in staat, dan moet er een melding worden gegeven:

1. Systeem is al gemigreerd, kan niet via een TKID terug worden gezet (ALREADYMIGRATED)
   

{"enableNumbering":true}

Aanmelden gegevens XIS

Voor iedere patient worden alle gegevens opnieuw (her)aangemeld.

• Alle gegevensoorten en/of bouwstenen die voorkomen in het dossier van de betreffende BSN moeten opnieuw worden aangemeld. Bouwstenen en/of gegevensoorten die niet in het dossier staan mogen niet aangemeld worden.

• In het (her)aanmeld bericht kunnen meerdere gegevenssoorten/bouwstenen  en toestemmingen worden meegegeven.

In het reason veld kunnen de volgende waarden worden meegegeven:

Tabel 1. Toestemmings Migratie Code  Vertaling code naar toestemming  (Maak dit een configureerdbare tabel, zodat er zonder al te veel moeite code bij kunnen komen)

( *)Door de aanpassing van de PS toestemming is het niet langer nodig om onderscheid te maken tussen een "gewone" huisarts toestemming en een ketenzorg toestemming,Deze moeten beiden vertaald worden naar en HPS-J code.

Naast de toestemmingscode, wordt er ook de datum waarop de toestemming is gegeven meegegeven. Indien de code "onbekend" aangeeft (of de datum onbekend is) , moet er geen datum worden doorgegeven.

Het reason veld ziet er als volgt uit:

  <reason> 
         <justifyingDetectedIssueEvent> 
            <code codeSystem="2.16.840.1.113883.2.4.3.111.5.10.2" code="HPS-J"></code> 
            <value xsi:type="TS" value=”2019-03-11T13:39:05+02:00”/>  
         </justifyingDetectedIssueEvent> 
  </reason> 

Indien de code een "onbekend" code is (geen -J of -N code), dan kan de datum (value tag) achterwegen gelaten worden.

      <reason> 
         <justifyingDetectedIssueEvent> 
            <code codeSystem="2.16.840.1.113883.2.4.3.111.5.10.2" code="HPS"></code> 
         </justifyingDetectedIssueEvent> 
      </reason> 

Het is op deze manier niet mogelijk om meerdere toestemmingen te gelijk door te geven. Ieder bericht kan maximaal 1 toestemmingen bevatten.

Toestemings Code bij "gewone"aanmelding

Note: Als dit "reason" veld wordt meegegeven terwijl de applicatie al gemigreerd is, dan wordt dit gezien als een fout bericht. Indien de applictaie nog niet gemigreerd is, dan wordt het genegeerd.

Gewijzigd aanmelden Proces

Nemen Mitz Toestemmings Abonnement

Het nemen van een ToestemmingsAbonnement wordt door het LSP automatsch gedaan na een (her)aanmelding.

Bij iedere aanmelding wordt er door het LSP gekeken of er al al een ToestemmingsAbonnement is aangemeld voor de combinatie BSN en APP-ID. Is dit niet het geval, dan wordt er een ToestemmingsAbonnement genomen bij Mitz.

Hier hoeft de XIS dus niets voor te doen.

{}

Fout Afhandeling

In principe worden fouten op de standaard manier afgehandeld en wordt het proces niet afgebroken.

Hoewel fouten op de normale manier worden doorgegeven aan de XIS, is er wel een scenario dat actief wordt als er overmatig veel fouten optreden:

• Als er in de eerste 100 berichten meer dan 10 fouten optreden dan afbreken
• Daarna bij ieder 1000ste bericht kijken of er niet meer dan 1% fouten zijn opgetreden, anders afbreken

Als er een fout wordt geconstateerd, dan wordt dat door het LSP aan de XIS gestuurd. De XIS moet deze opvangen en verwerken nadat de laatste patient is aangemeld of het proces is afgebroken met een ZIMMIGABO error code.

Op het moment dat een [ZIMMIGABO ] error optreed, moet er ook een bericht naar Ketenregie worden gestuurd.

Afbreken door het LSP

Indien het LSP heeft geconstateerd dat er teveel fouten zijn opgetreden (bv doordat Mitz niet reageerd, dn heeft het geen zin verder te gaan), dan wordt er een code ZIMMIGABO in het retour bericht gestuurd.

Hierop moet de XIS de migratie afbreken. (als de XIS dat niet doet is het mogelijk dat er problemen kunnen ontstaan in de XIS door het vollopen van berichtboxen)

Fout Verwerking

Nadat alle berichten zijn ingeschoten, kan de XIS (GBZ beheer) kijken hoeveel fouten er zijn opgetreden en bepalen of deze opnieuw moeten worden aangeboden (eventueel na aanpassingen).

Het systeem kan in migrerend blijven staan, tenzij de XIS zelf besluit dat dat het te veel tijd gaat kosten en de migratie afbreekt.

Zeker als het process is afgebroken met een ZIMMIGABO error, wordt aangeraden de migratie af te breken en op een ander tijdstip nogmaal te proberen.

{}

Aanmelden Gemigreerd

De laatste stap in de migratie is het aanmelden dat een systeem (alleen nog maar) gebruik maakt van Mitz.

Dit wordt gedaan door het systeem via een TKID aan te melden als een "Toestemming Delegerend Systeem".

Daarvoor wordt de volgende procedure gebruikt:

XIS

1. Stuur een TKID bericht met daarin de standaard TKID's en de TKID voor "Toestemming Delegerend Systeem", de TKID voor "Toestemming Migrerend Systeem" moet niet meegegeven worden.
2. Wacht totdat het antwoord terug komt (step 9).
3. Als er een error (STILLMIGRATING) optreed (step 5), dan is Mitz nog niet klaar met het verwerken van de berichten. Stuur het TKID bericht opnieuw in

LSP

1. Check of de applicatie aan het migreren is
   1. Zo niet verwerking afbreken
2. check of de verwerking queue naar Mitz leeg is voor deze URA
   1. Indien niet, probeer het na 10 seconden nog eens
   2. Geef na 4 pogingen de error (STILLMIGRATING) terug.
3. Zet de TKID's
   1. Geef een bericht terug dat het gelukt is.

Als het LSP het bericht terug heeft gestuurd dat de applicatie nu herkent wordt als een "Toestemming Delegerend Systeem", dan moet in de XIS de OPT-IN registratie en de locale toestemmingscontrolle worden uitgezet.

{}

Overgebleven migraties

Tijdens de migrate van de gegeven skan besloten worden om een aantal records niet te migreren. Daar kunnen verschillende redenen voor zijn, maar de belangrijkste reden kan zijn dat het te lang duurt om evenetuele fouten uit het record te halen en om de migratie niet te lang te laten duren, wordt er besloten om de paar records op een later tijdstip te migreren.

De migratie wordt afgesloten door de systeem rol "Toestemming Delegerend Systeem (TDS)" in te schieten. het is niet eenvoudig mogelijk om deze rol weer terug te draaien.

Om nu toch nog uitstaande records te "migreren" moet er een versnelde toestemming (Bron) worden ingeschoten. Hierbij moet wel worden opgemerkt dat deze teostemming breder is dan de toestemming uit de migratie, dus is het noodzakelijk om aan alle voorwaarden van de versnelde toestmming (Bron) te voldoen, bv door bij de patient na te vragen of ze toestemming geven.

{}

{}