Bijlage Standaard Migratieproces

Deze hoofdstuk beschrijft het standaard migratie proces

Samenvatting

Detail Uitwerking

Beginnen met Migreren

Voor het systeem kan beginnem met een standaard migratie. moet het systeem op onderhoud worden gezet. Dit is in tegenstelling tot de andere migraties waarbij het systeem gewoon operationeel blijft.

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}

Toestemmingen worden via de interactie PXAC_IN990020NL01 naar het LSP verzonden. Dit bericht bestaat uit een standaard HL7v3 header, en in de payload een consent resource. Zie de Mitz documentatie ([IH MANR] in  Bijlage Referenties) voor de invulling van deze resource.

Deze interactie wordt gebruikt door de XIS om een toestemming te migreren naar MITZ. Het bericht wordt verzonden naar het LSP, die het bericht omzet naar een FHIR bericht in de richting van MITZ.

Het LSP zal het resultaat van deze verwerking terugkoppelen aan het toestemmingregistrerend systeem.

{}

Versturen Aanmeldingen

De aanmeldingen zijn gelijk aan de aanmeldingen die nodig zijn voor niet gemigreerde XISsen, met de volgende  de volgende verschillen:

• In tegenstelling tot de aanmeldingen bij een niet-gemigeerd systeem, moeten alle gegevens worden aangemeld en niet alleen de gegevens waar toestemming voor is.
• In de attentionline moeten de geboortedatum en een indicatie voor het niet versturen van een signaal worden meegegeven
• Tijdens "standaard"migratie word de inhoud van het reason veld genegeerd.
  • De test op "normale" migratie is kijken of het systeem in onderhoud staat.
• tevens moet worden aangegeven of er een signaal verstuurd moet worden.
• Voor Eisen Zie Aanmelden Gegevens

Gebruik Attentionline

<attentionLine>
        <!-- Patient.birthTime -->
        <keyWordText code="PATGEB" codeSystem="2.16.840.1.113883.2.4.15.1"></keyWordText>
        <value xsi:type="TS" value="19611121"/>
</attentionLine>

<attentionLine>  
        <keyWordText code="SIGNAL" codeSystem="2.16.840.1.113883.2.4.15.1"></keyWordText>
        <value xsi:type="ST" value="false"/>
</attentionLine>

In de attentionline worden twee gegevens mee gegeven:

De geboortedatum

Voor Mitz is het nodig dat de geboortedatum wordt meegegeven een aan het aanmaak bericht voor de toestemmingsnotificatie. Om deze bij het LSP te krijgen wordt deze in iedere aanmelding meegegeven in een attentionline.

Het formaat van de geboortedatum is yyyymmdd. Indien de Maand en Dag onbekend zijn, kan daar de waarde 01 voor gebruikt worden.

Signaal indicatie

Bij iedere wijziging in het AR kan er in principe een signaal worden gestuurd naar de XISsen die daarom gevraagd hebben. Door in de attentionline een indicatie op "false" te zetten wordt aan het LSP aangegeven dat er voor deze aanmelding geen signaal hoeft te worden verstuurd.

Is deze indicatie niet aanwezig of staat hij op "true", dan kan er door het LSP wel een signaal worden verstuurd.

{}

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.

{}

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.

{}

Samenvatting

• status ‘migrerend’ wordt alleen bij standaardmigratie gebruikt (dus niet bij Scenario C en niet bij batchmigratie)

• status ‘migrerend’ wordt door beheer gezet in applicatieregister en door hen ook weer teruggezet (naar ‘actief’ bijvoorbeeld)

• status ‘migrerend’ wordt gezet voordat de applicatie het TKID Mitz_Migrating inschiet en wordt pas teruggezet nadat de applicatie het TKID TDS heeft. Dit is een handmatig proces, er hoeft dus geen check op ingebouwd te worden (anders werken scenario C en de batchmigratie ook niet meer)

• met de status ‘migrerend’ is het enkel toegestaan om de volgende interacties te versturen:

  • PRPM_IN908500NL

  • MFMT_IN002302NL

  • PXAC_IN990020NL01

{"enableNumbering":true}