Bijlage Batch geörienteerde Migratie

Dit hoofdstuk beschrijft de migratie met behulp van een batch bestand

Samenvatting

Detail verwerking

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}

Migratie van de gegevens

Voor het uitvoeren van de migratie wordt er gebruik gemaakt van het Asynchrone communicatie mechanisme. Dit mechanisme is bij de meeste leveranciers al bekend, omdat het ook gebruikt wordt bij VWI sync.

De service wordt geactiveerd door het ontvangen van een BestandAanmakenGereed-bericht door de ZIM. De attributen die zijn opgenomen in het BestandAanmakenGereed-bericht zijn beschreven in Bijlage B van [Ontw Async]. Alleen een bericht waarbij het attribuut Type aangeeft dat het gaat om een bestand met migratie gegevens  van een XIS (MIGRTOES) kan de batch migatie service activeren.

AORTA Bestandssoort (OID 2.16.840.1.113883.2.4.3.111.5.2)

De service zal vervolgens het bestand met lokale toestemmingen en dossiers downloaden bij het XIS. Dit moet binnen een tijd van <asb-min-bewaren-bestand> worden gedaan. Het door het LSP gedownloade bestand bevat de informatie voor migratie aangegeven in onderstaande JSON:

{
  "Migratie": {
    "ID": "<ID>", // unieke Identifier voor het bestand (bv GUID)
    "URA": "<URA>", // URA Van de Zorgaanbieder
    "ApplicatieID": "<ApplicatieID>", // App-ID
    "Patienten": [{ // array van patienten records, een patient (BSN) mag meerdere malen voorkomen
        "ID": "<ID>", // unieke Identifier voor het record (bv GUID)
        "BSN": "<BSN>", // BSN van de patient
        "GeboorteDatum": "yyyy-mm-dd", // geboortedatum (indien bekend in het systeem
        "GegevensSoort": [<"code>"],// Lijst van gegevenssoort codes, leeg indien er geen gevenssoort worden aangemeld
        "BouwsteenType": ["<code>"], // Lijst van bouwsteentype codes, leeg indien er geen bouwstenen worden aangemeld
        "Toestemming": [{ // Array van toestemmingen, leeg indien er geen toestemming gemigreerd worden
            "Code": "<code>", // Toestemmings code
            "Datum": "yyyy-mm-ddT12:00:00+02:00" // Datum waarop de toestemming gegeven is, De tijd is verplicht mee te geven
          }]
      }]
  }

• Er moet minimaal één Gegevenssoort of Bouwsteentype worden aangemeld in een patienten record.
  Zijn beiden leeg, dan wordt het record afgekeurd.

• Het URA wordt gevalideerd

• De ApplicatieID wordt gecontroleerd

• De Bouwstenen en Gegevenssoort Codes worden gevalideerd

• De Toestemmings Code wordt gecontroleerd.

• Als een geboortedatum niet bekend is, wordt het veld leeggelaten

 "GeboorteDatum": "", // geboortedatum

• Het zorgden dat de ID's unique zijn is de verantwoording van de XIS. Hier wordt verder niet op gecontroleerd.

• Tijdens het uitvoeren van de migratie, kan de XIS gewoon inproductie blijven en ook (gewone) aanmeldingen naar het LSP blijven versturen. Deze zullen dan zowel in de AR als in de VWI verwerkt worden.
• het is niet nodig dat alle aanmeldingen in het zelfde bericht zitten. omdat de verwering in een loop is opgenomen, kan altijd een volgend bericht worden ingeschoten, waarbij gevonden fouten worden opgelost en eventueel een volgende groep gemigreerd wordt. Zolang niet aan de ZIM is aangegeven dat de XIS gemigreerd is, kunnen er migratie batches verstuurd worden (het is wel van belang dat deze tijd zo kort mogelijk duurt).
• Het is mogelijk om de migraties te verdelen in groepen, zeker als het aanmaken van het batchbericht te veel tijd kost. Zolang niet aan de ZIM is aangegeven dat de XIS gemigreerd is, kunnen er migratie batches verstuurd worden
• Het is niet nodig om alle aanmeldingen en toestemmingen in één record te zetten. Het is voor de verwerking geen probleem als er een BSN meerdere malen voorkomt.
• De aanmeldingen en toestemmingen zijn onafhankelijk van elkaar, het is dus niet nodig om een medicatie toestemming in het zelfde record te zetten als de aanmelding van medicatie gegevens. het kan wel, maar hoeft niet.
• 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.
• Het is van belang dat ieder JSON records een andere id heeft. Dit is nodig om eventuele fouten te kunnen koppelen aan een record.
• Tijdens de conversie van JSON naar een aanmeldbericht wordt in de Attentionline aangegevens dat er geen signaal moet worden gegeven
• Het is niet mogelijk dat er per zorgaanbieder meerdere batch bestanden te gelijkertijd wordt verwerkt.

Gewijzigd aanmelden Proces

Het aanmeld bericht word afhankelijk van de status van de migrate op een andere manier verwerkt.

1) Het systeem is niet aan het migreren en ook nog niet gemigreerd → Geen verandering

2) Het systeem is gemigreerd → Bijwerken AR

3) Het systeem is aan het migreren → Bijwerken AR en voorwaardelijk bijwerken van de VWI

Niet migrerend en niet gemigreerd

Standaard "oude" aanmeld proces.

Er komt wel een wijziging die de signaal functie gaan beinvloeden.

Al gemigreerd

• Bijwerken actualiteits register

  • Er komt wel een wijziging die de signaal functie gaan beinvloeden.

• Nemen toestemmings abonnement bij Mitz

Aan het migreren

Dit de ingewikkelde vorm, hierbij moeten diverse beslissingen en acties worden uitgevoerd.

Aanmelden bij de VWI

Als wordt aangegeven dat dit bericht een productie bericht is (door de afwezigheid van het veld SIGNAL in de attention line, of door de code YES in veld SIGNAL ), dan wordt dit bericht doorgezet naar de VWI. Hierbij wordt er niet naar de migratie code in het reason veld gekeken (Zodat productie berichten niet aangepast hoeven te worden).

Alle andere berichten worden niet naar de VWI verzonden. Dit zijn dus de berichten met de code NO in het veld SIGNAL. Dit zijn migratie berichten.

Aanmelden bij het AR

Alle berichten worden verwerkt in het AR.

• Bijwerken actualiteits register

• Aanmelden dossier bij Mitz

Aan het migreren en geen migratie code in het reason veld

Als een XIS tijdens het migreren een aanmelding doet, zonder dat er een migratiecode in het reason veld staat, wordt het aangemeld in het AR. En dus wordt er ook een dossier aangemeld bij Mitz.

Deze berichten worden wel in de VWI verwerkt als er aangegeven is dat het een productie bericht is (door de afwezigheid van het veld SIGNALin de attention line, of door de code YES in veld SIGNAL), Zie stap 1.4.3.1

Doorgeven van de toestemming naar Mitz

Als er een migratie code in het reason veld staat, wordt er aan de hand van tabel 1 een toestemmings bericht gemaakt dat naar Mitz verstuurd word.

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.

{}

Error Bestand

Als de ZIM klaar is met het verwerken van de aanmeldingen in het bestand, dan geeft de ZIM aan de XIS aan dat er een error bestand klaar staat. Dit bestand wordt door de XIS opgehaald en verwerkt. Eventuele errors kunnen opgelost worden en in een volgend bestand weer naar de ZIm verstuurd worden. De opgetreden errors worden opgeleverd in een bestand met het volgende formaat.

{
    "MigratieResultaat": {
        "ID": "<ID>", // unieke Identifier van het aangeboden bestand (bv GUID)
        "Patienten": [{ // array van patienten records, een patient (BSN) mag meerdere malen voorkomen
            "ID": "<ID>", // unieke Identifier van het record (bv GUID) uit het aangeboden bestand
            "Result": "NOT_OK", // Resultaat van de migratie
            "Status": "<Status>" // Beschrijving van de reden waarom migratie is mislukt
        }]
    }
}

Voorbeeld van een antwoord bestand:

{
	"MigratieResultaat": {
		"ID": "Mitz_regressietest_batchmigratie_foutpaden",
		"Patienten": [
			{
				"ID": "1",
				"Result": "NOT_OK",
				"Status": "SYN111 : BOGUS reason"
			},
			{
				"ID": "2",
				"Result": "NOT_OK",
				"Status": "SYN111 : BOGUS reason"
			},
			{
				"ID": "3",
				"Result": "NOT_OK",
				"Status": "SYN111 : BOGUS reason"
			},
			{
				"ID": "4",
				"Result": "NOT_OK",
				"Status": "SYN111 : BOGUS reason"
			},
			{
				"ID": "5",
				"Result": "NOT_OK",
				"Status": "SYN111 : BOGUS reason"
			},
			{
				"ID": "6",
				"Result": "NOT_OK",
				"Status": "SYN111 : BOGUS reason"
			},
			{
				"ID": "7",
				"Result": "NOT_OK",
				"Status": "SYN111 : BOGUS reason"
			},
			{
				"ID": "8",
				"Result": "NOT_OK",
				"Status": "SYN111 : BOGUS reason"
			},
			{
				"ID": "9",
				"Result": "NOT_OK",
				"Status": "SYN111 : BOGUS reason"
			},
			{
				"ID": "10",
				"Result": "NOT_OK",
				"Status": "ZIMMIGABO : BOGUS reason"
			}
		]
	}
}

{"enableNumbering":true}

Fout Afhandeling

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

Hoewel fouten via een antwoord bericht 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 verwerkt  De XIS krijgt een errorlijst en moet deze verwerken, tenzij 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)

Nadat alle berichten zijn verwerkt, kan de XIS  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. Het batch bericht kan meerdere malen worden verstuurd.

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.

{}

{"enableNumbering":true}

{}