Use Cases Resource Client

Overzicht Resource Client

Een Resource Client is een GBx-applicatie. Een GBZ-applicatie kan zowel fungeren in de rol van Resource Server als in de rol van Resource Client. Een GBP-applicatie en een GBK-applicatie fungeren slechts in de rol van Resource Client.

Een Resource Client initieert interacties. Een Resource Server reageert op interacties die worden geïnitieerd middels een interface. Een Resource Client biedt zelf geen in principe geen interfaces. Uitzondering hierop zijn callback interfaces, bijvoorbeeld t.b.v. notificaties.

Onderstaande figuur toont een overzicht van de interfaces en services van de Resource Client.

Services zijn toegankelijk via interfaces en worden beschreven in de vorm van use cases. De Resource Client maakt gebruik van een aantal interfaces, in het bijzonder van de AORTA FHIR RB Interface.

Een aantal services maken gebruik van onderliggende services. Een dergelijk onderliggende service wordt dan beschreven in de vorm van een use case inclusion of als een use case extension.

Services behoren tot een bepaalde functie. Onderstaande figuur toont een overzicht van de services en functies van de Resource Client.

Generieke use cases

Activeren TKID

Primaire actor	GBx-beheerder
Systeem	<GBx-systeemrol>
Secundaire actor	Resource Broker APR
Code	AOF.UC.RC.100.v1

Pre-condities

Het systeem is aangesloten op de secundaire actor(en).

De kwalificaties van de Resource Client/Server zijn reeds geaccepteerd door VZVZ en zijn ook geregistreerd in de secundaire actor.

De primaire actor beschikt over de juiste TKID's (ID's die zijn uitgereikt n.a.v. acceptatie van succesvol doorlopen kwalificaties) van alle te activeren AORTA systeemrollen.

Het systeem beschikt over een voldoende actueel AORTA Stelseltoken die het via de AORTA Stelsel Metadata Interface heeft verkregen.

Triggers

De primaire actor wil één of meerdere TKID's activeren.

Main flow

Stap

Omschrijving

Uitkomst

1

De primaire actor kiest de optie om één of meerdere TKID's te activeren voor een bepaalde resource server.

2

Het systeem activeert één of meerdere TKID’s middels de Applicatie Register Interface.

3

<exit>

Het systeem ontvangt en verwerkt een response.

Post-condities

Postconditie bij succes:

De verzonden TKID's zijn verwerkt door de secundaire actor, waardoor de Resource Client/Server nu is gekoppeld aan de bijbehorende AORTA systeemrollen. Hiermee zijn tevens eventueel eerder doorlopen TKID activaties ongedaan gemaakt.

Post-conditie bij falen:

De bestaande koppelingen tussen AORTA systeemrollen met de Resource Client/Server is ongewijzigd gebleven.

Het systeem heeft van het verzonden request, de volgende attributen gelogd:

datum en tijd van ontvangst
request-id
initial-request-id
sender-id (app-id van de GBx-applicatie die het request verzendt)
receiver-id (role-id van de VZVZ component die het request ontvangt)

Het systeem heeft van de ontvangen response, de volgende attributen gelogd:

datum en tijd van response
request-id van het bijbehorende request
initial-request-id van het bijbehorende request
sender-id (role-id van de VZVZ component die de response heeft verzonden)
receiver-id (app-id van de GBx-applicatie die de response ontvangt)
HTTP statuscode en eventueel geretourneerde foutinformatie

Initieren AORTA FHIR-interactie

Primaire actor	Gebruiker of Time
Systeem	<GBx-systeemrol>
Secundaire actor	Resource Broker ZA-in, Autorisatie Server ZA, Adressering Server
Code	AOF.UC.RC.200.v1

Pre-condities

Het systeem is aangesloten op de secundaire actor(en).

Het systeem beschikt over een voldoende actueel AORTA Stelseltoken die het via de AORTA Stelsel Metadata Interface heeft verkregen.

Triggers

De primaire actor wil gegevens opvragen of versturen.

Main flow

Stap	Omschrijving	Uitkomst
1	Optioneel: het systeem vraagt routeringsinformatie op middels de Routing Info Interface.
2	Het systeem verkrijgt autorisatie middels de AORTA Token Exchange Interface.
3	Het systeem initieert een FHIR-interactie middels de AORTA FHIR Resource Broker Interface. Bij instance level interacties, bijv. een FHIR-read, dient het systeem het appID van de Resource Server (GBZ-applicatie of Resource Broker GTK) toe te voegen aan de URL. Het juiste appID kan zijn verkregen in stap 1 van de use case, maar kan ook zijn opgenomen in een query_string binnen een Notified-Pull Task.
4 <exit>	Het systeem ontvangt en verwerkt een response.

Bij het opvragen van gegevens zijn ook de generieke, d.w.z. niet HL7v3-specifieke, eisen van toepassing die gelden voor een Patiëntgegevens raadplegend systeem, zoals gespecificeerd in het PvE Infrastructurele Systeemrollen.

Bij het versturen van gegevens zijn ook de generieke, d.w.z. niet HL7v3-specifieke, eisen van toepassing die gelden voor een Gegevens versturend systeem, zoals gespecificeerd in het PvE Infrastructurele Systeemrollen.

Post-condities

De response is correct verwerkt in het systeem.

Het systeem heeft van het verzonden request, de volgende attributen gelogd:

datum en tijd van ontvangst
request-id
initial-request-id
sender-id (app-id van de GBx-applicatie die het request verzendt)
receiver-id (role-id van de VZVZ component die het request ontvangt)

Het systeem heeft van de ontvangen response, de volgende attributen gelogd:

datum en tijd van response
request-id van het bijbehorende request
initial-request-id van het bijbehorende request
sender-id (role-id van de VZVZ component die de response heeft verzonden)
receiver-id (app-id van de GBx-applicatie die de response ontvangt)
HTTP statuscode en eventueel geretourneerde foutinformatie

Initiëren notified-pull

Primaire actor	Gebruiker of Time
Systeem	<GBx-systeemrol>
Secundaire actor	Adressering Server
Code	AOF.UC.RC.300.v1

Pre-condities

Het systeem is aangesloten op de secundaire actor(en).

Het systeem beschikt over een voldoende actueel AORTA Stelseltoken die het via de AORTA Stelsel Metadata Interface heeft verkregen.

Triggers

De primaire actor wil een notified-pull initieren.

Main flow

Stap

Omschrijving

Uitkomst

1

Optioneel: het systeem vraagt routeringsinformatie op middels de Routing Info Interface.

2

Het systeem genereert een AORTA consent_token.

3

<exit>

Het systeem creëert, t.b.v. de uitvoering van een notified-pull, een AORTA Task, middels de use case Initieren AORTA-FHIR-interactie.

Post-condities

De response is correct verwerkt in het systeem.

Het systeem heeft van het verzonden request, de volgende attributen gelogd:

datum en tijd van ontvangst
request-id
initial-request-id
sender-id (app-id van de GBx-applicatie die het request verzendt)
receiver-id (role-id van de VZVZ component die het request ontvangt)

Het systeem heeft van de ontvangen response, de volgende attributen gelogd:

datum en tijd van response
request-id van het bijbehorende request
initial-request-id van het bijbehorende request
sender-id (role-id van de VZVZ component die de response heeft verzonden)
receiver-id (app-id van de GBx-applicatie die de response ontvangt)
HTTP statuscode en eventueel geretourneerde foutinformatie

ACT/VWI use cases

Aanleveren mutaties ACT/VWI

Primaire actor	Gebruiker of Time
Systeem	<GBx-systeemrol>
Secundaire actor	Resource Broker ZA-in
Code	AOF.UC.RC.400.v1

Pre-condities

Het systeem is aangesloten op de secundaire actor(en).

Het systeem beschikt over de juiste kwalificaties om deze use case te mogen uitvoeren.

Het systeem beschikt over een voldoende actueel AORTA Stelseltoken die het via de AORTA Stelsel Metadata Interface heeft verkregen.

Triggers

De primaire actor wil het actualiteitsregister of de verwijsindex bijwerken.

Main flow

Stap	Omschrijving	Uitkomst
1	De primaire actor kiest de optie om haar ACT/VWI registratie bij te werken.
2	Het systeem verkrijgt autorisatie middels de AORTA Token Exchange Interface. Deze interactie mag worden uitgevoerd op vertrouwensniveau “Laag” (of hoger). Zie ook de “toelichting vertrouwensniveaus”. De contextcode die moet worden meegegeven in de scope van het token exchange request is altijd “VWIMGT”, ongeacht welke gegevens worden aangemeld of afgemeld.
3	Het systeem maakt, wijzigt of verwijdert, via de AORTA FHIR Resource Broker Interface, één of meerdere ACT/VWI entries, inhoudelijk op de wijze zoals beschreven in de Actualiteitsregister Interface.
4 <exit>	Het systeem ontvangt en verwerkt een response.

Post-condities

De response is correct verwerkt in het systeem.

Het systeem heeft van het verzonden request, de volgende attributen gelogd:

datum en tijd van ontvangst
request-id
initial-request-id
sender-id (app-id van de GBx-applicatie die het request verzendt)
receiver-id (role-id van de VZVZ component die het request ontvangt)

Het systeem heeft van de ontvangen response, de volgende attributen gelogd:

datum en tijd van response
request-id van het bijbehorende request
initial-request-id van het bijbehorende request
sender-id (role-id van de VZVZ component die de response heeft verzonden)
receiver-id (app-id van de GBx-applicatie die de response ontvangt)
HTTP statuscode en eventueel geretourneerde foutinformatie

Opvragen ACT/VWI

Primaire actor	Gebruiker of Time
Systeem	<GBx-systeemrol>
Secundaire actor	Resource Broker ZA-in
Code	AOF.UC.RC.500.v1

Pre-condities

Het systeem is aangesloten op de secundaire actor(en).

Het systeem beschikt over de juiste kwalificaties om deze use case te mogen uitvoeren.

Het systeem beschikt over een voldoende actueel AORTA Stelseltoken die het via de AORTA Stelsel Metadata Interface heeft verkregen.

Triggers

De primaire actor wil het actualiteitsregister of de verwijsindex raadplegen.

Main flow

Stap	Omschrijving	Uitkomst
1	De primaire actor kiest de optie om te zoeken in haar ACT/VWI registratie.
2	Het systeem verkrijgt autorisatie middels de AORTA Token Exchange Interface. Deze interactie mag worden uitgevoerd op vertrouwensniveau “Midden” (of hoger). Zie ook de “toelichting vertrouwensniveaus”. De contextcode die moet worden meegegeven in de scope van het token exchange request is, voor patiënten die opvragen via het GBP, gelijk aan “PATVWI”.
3	Het systeem vraagt, via de AORTA FHIR Resource Broker Interface, ACT/VWI entries op, inhoudelijk op de wijze zoals beschreven in de Actualiteitsregister Interface.
4 <exit>	Het systeem ontvangt en verwerkt een response.

Post-condities

De response is correct verwerkt in het systeem.

Het systeem heeft van het verzonden request, de volgende attributen gelogd:

datum en tijd van ontvangst
request-id
initial-request-id
sender-id (app-id van de GBx-applicatie die het request verzendt)
receiver-id (role-id van de VZVZ component die het request ontvangt)

Het systeem heeft van de ontvangen response, de volgende attributen gelogd:

datum en tijd van response
request-id van het bijbehorende request
initial-request-id van het bijbehorende request
sender-id (role-id van de VZVZ component die de response heeft verzonden)
receiver-id (app-id van de GBx-applicatie die de response ontvangt)
HTTP statuscode en eventueel geretourneerde foutinformatie

Abonneren use cases

Initieren Abonnement Interactie

Primaire actor	Gebruiker
Systeem	<GBx-systeemrol>
Secundaire actor	Zie use case extensions
Code	AOF.UC.RC.600.v1

Pre-condities

Het systeem is aangesloten op de secundaire actor(en).

Het systeem beschikt over de juiste kwalificaties om deze use case te mogen uitvoeren.

Het systeem beschikt over een voldoende actueel AORTA Stelseltoken die het via de AORTA Stelsel Metadata Interface heeft verkregen.

Triggers

De primaire actor wil een interactie initieren m.b.t. het Abonnement Register.

Main flow

Stap

Omschrijving

Uitkomst

1

Het systeem

neem een Abonnement, OF
verlengt een Abonnement , OF
beëindigt een Abonnement, OF
zoekt naar bestaande Abonnementen

dit verloopt middels de use case Initieren AORTA-FHIR-interactie, en inhoudelijk op de wijze zoals beschreven in de Abonnement Interface.

Deze interactie mag worden uitgevoerd op vertrouwensniveau “Midden” (of hoger). Zie ook de “toelichting vertrouwensniveaus”.

De contextcode die moet worden meegegeven in de scope van het token exchange request is voor

het zoeken naar abonnementen gelijk aan “OPVABR”;
de andere interacties gelijk aan de contextcode die wordt gehanteerd in het betreffende abonnement zelf.

Post-condities

De response is correct verwerkt in het systeem.

Het systeem heeft van het verzonden request, de volgende attributen gelogd:

datum en tijd van ontvangst
request-id
initial-request-id
sender-id (app-id van de GBx-applicatie die het request verzendt)
receiver-id (role-id van de VZVZ component die het request ontvangt)

Het systeem heeft van de ontvangen response, de volgende attributen gelogd:

datum en tijd van response
request-id van het bijbehorende request
initial-request-id van het bijbehorende request
sender-id (role-id van de VZVZ component die de response heeft verzonden)
receiver-id (app-id van de GBx-applicatie die de response ontvangt)
HTTP statuscode en eventueel geretourneerde foutinformatie

Verwerken Abonnement Notificatie

Primaire actor	ABR Server
Systeem	<GBx-systeemrol>
Code	AOF.UC.RC.700.v1

Pre-condities

Het systeem is aangesloten op de secundaire actor(en).

Het systeem beschikt over de juiste kwalificaties om deze use case te mogen uitvoeren.

Main flow

Stap

Omschrijving

Uitkomst

1

Het systeem ontvangt een notificatie

2

Het systeem verwerkt de notificatie.

Ongeldig verzoek

statuscode 400 Bad Request

3

<exit>

Het systeem retourneert een response naar de primaire actor.

Verwerking succesvol

statuscode 200 OK

Post-condities

Het systeem heeft van het ontvangen request, de volgende attributen gelogd:

datum en tijd van ontvangst
request-id
initial-request-id
receiver-id (app-id van de GBx-applicatie die het request ontvangt)

Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:

datum en tijd van response
request-id van het bijbehorende request
initial-request-id van het bijbehorende request
sender-id (app-id van de GBx-applicatie die de response verzendt)
HTTP statuscode en eventueel geretourneerde foutinformatie

Register synchronisatie use cases

Om een register synchronisatie uit te voeren heeft de GBx-beheerder een verschillenrapportage nodig.

Verkrijgen Verschillenrapportage

Primaire actor	GBx-beheerder
Systeem	<GBx-systeemrol>
Secundaire actor	Resource Broker ZA-in, Synchronisatie Afhandelaar
Code	AOF.UC.RC.900.v1
Realiseert Feature	GetInputDocument, DocumentPickUpNotification, RequestDocumentPickUp

Pre-condities

Het systeem is aangesloten op de secundaire actor(en).

Het systeem beschikt over de juiste kwalificaties om deze use case te mogen uitvoeren.

Het systeem beschikt over een voldoende actueel AORTA Stelseltoken die het via de AORTA Stelsel Metadata Interface heeft verkregen.

Triggers

De primaire actor wil een register synchronisatie uitvoeren.

Main flow

Deze use case flow bestaat uit 6 opeenvolgende interacties met ieder een verzoek en respons.

Na iedere interactie geldt dat het systeem, voor de betreffende interactie, moet voldoen aan de gespecificeerde post-condities m.b.t. logging.

1. Aanvragen verschillenrapportage

Stap	Omschrijving	Uitkomst
1.1	De primaire actor kiest ervoor om een register synchronisatie aan te vragen.
1.2	Het systeem heeft het op te halen register synchronisatie Inputbestand gereed via de Feature GetInputDocument, en houdt deze beschikbaar gedurende de datum/tijd aangegeven in het verzoek. Het register synchronisatie inputbestand voldoet aan Formaat Inputbestand Register Synchronisatie.
1.3	Het systeem verkrijgt autorisatie middels de AORTA Token Exchange Interface. Deze interactie mag worden uitgevoerd op vertrouwensniveau “Laag” (of hoger). Zie ook de “toelichting vertrouwensniveaus”. De contextcode die moet worden meegegeven in de scope van het token exchange request is altijd `REGSYNC`.
1.4	Het systeem verzendt via de AORTA FHIR Resource Broker Interface, een aanvraag voor een register synchronisatie, inhoudelijk op de wijze zoals beschreven in de Feature RequestDocumentPickup (Proxy). Het Type-register-sync wordt gevuld met het AORTA register die gesynchroniseerd dient te worden (bijv. VWI, ACT of ABR).
1.4 <exit>	Het systeem ontvangt en verwerkt een response. Indien een foutmelding was ontvangen beeindigd het systeem de flow. In alle andere gevallen gaat het systeem door naar stap 2.1.

2. Uitwisselen inputbestand

Stap	Omschrijving	Uitkomst
2.1	Het systeem wacht op het asynchrone ophalen van het Inputbestand volgens de Feature GetInputDocument. Indien de beschikbaarhaarheids periode van het inputbestand (Document-beschikbaar-tot van de RequestDocumentPickup in stap 1.4) verstreken is, beeindigd de flow.	Beschikbaarheids periode verstreken Eindigd de flow
2.2	Het systeem ontvangt een verzoek en start de verwerking.
2.3	Het systeem toetst of het verzoek voldoet aan de interface specificatie.	Verwerking succesvol statuscode 200 OK
		Ongeldig verzoek statuscode 400 Bad Request
		URL onbereikbaar statuscode 401 Unauthorized
		Bestand is al verwijderd statuscode 404 Not Found
		Het systeem genereert de vereiste response en gaat verder met exit stap van de 2e interactie.
2.4 <exit>	Het systeem retourneert een response naar de primaire actor. Het systeem gaat door naar stap 3.1.

3. Melden inputbestand opgehaald

Stap	Omschrijving	Uitkomst
3.1	Het systeem wacht op een notificatie volgens de Feature DocumentPickupNotification (Client) over de status van het opgehaalde inputbestand. Indien een periode van 3 dagen verstreken is sinds stap 2.4 beindigd het systeem de flow.	Time Out Eindigd de flow
3.2	Het systeem ontvangt een verzoek en start de verwerking.
3.3	Het systeem toetst of het verzoek voldoet aan de interface specificatie.	Verwerking succesvol statuscode 200 OK
		Ongeldig verzoek statuscode 400 Bad Request
		Het systeem genereert de vereiste response en gaat verder met exit stap van de 3e interactie.
3.4	Het systeem toetst of de Referentie-gerelateerde-RequestDocumentPickup gelijk is aan de Verzoek-id van de RequestDocumentPickup uit stap 1.3).	Onbekende Register Sync Notificatie statuscode 400 Bad Request
3.4		Het systeem genereert de vereiste response en gaat verder met exit stap van de 3e interactie.
3.5 <exit>	Het systeem retourneert een response naar de primaire actor. Indien een foutmelding (zie Toetsing RequestDocumentPickup en Toesting Inputbestand) was ontvangen beëindigd het systeem de flow. In alle andere gevallen gaat het systeem door naar stap 4.1.

4. Melden verschillenrapportage gereed

Stap	Omschrijving	Uitkomst
4.1	Het systeem wacht op een notificatie volgens de Feature RequestDocumentPickup (Client), welke aangeeft dat de verschillenrapportage gereed is om op te halen. Indien een periode van 3 dagen verstreken is sinds stap 3.5 beindigd het systeem de flow.	Time Out Eindigd de flow
4.2	Het systeem ontvangt een verzoek en start de verwerking.
4.3	Het systeem toetst of het verzoek voldoet aan de interface specificatie.	Verwerking succesvol statuscode 200 OK
		Ongeldig verzoek statuscode 400 Bad Request
		Het systeem genereert de vereiste response en gaat verder met exit stap van de 4e interactie.
4.4 <exit>	Het systeem retourneert een response naar de primaire actor.
4.5	Het systeem voert een inhoudelijke toets uit op het ontvangen RequestDocumentPickup zoals omschreven in de sectie Toetsing RequestDocumentPickup Als er geen inhoudelijke fout is geconstateerd wordt gaat het systeem door met stap 5.1. Indien er een fout is gevonden gaat het systeem door met stap 6.1 met de geconstateerde foutcode.

5. Uitwisselen verschillenrapportage

Stap

Omschrijving

Uitkomst

5.1

Het systeem haalt het verschillenrapportage op, m.b.v. Feature GetVerschillenrapportage. Het verschllenrapportage voldoet aan het Formaat Verschillenrapportage Register Synchronisatie.

5.2

<exit>

Het systeem ontvangt en verwerkt een response.

5.3

Het systeem voert een inhoudelijke toets uit op het opgehaalde document zoals omschreven in de sectie Toetsing Verschillenrapportage.

Het systeem gaat door met stap 6.1. Indien er een fout is geconstateerd wordt de geconstateerde foutcode meegenomen.

6. Melden verschillenrapportage opgehaald

Stap	Omschrijving	Uitkomst
6.1	Het systeem verkrijgt autorisatie middels de AORTA Token Exchange Interface. Deze interactie mag worden uitgevoerd op vertrouwensniveau “Laag” (of hoger). Zie ook de “toelichting vertrouwensniveaus”. De contextcode die moet worden meegegeven in de scope van het token exchange request is altijd `REGSYNC`.
6.2	De te verzenden notificatie wordt opgesteld volgens het DocumentPickupNotification datamodel Indien een foutcode is meegenomen vanuit stap 4.5 of 5.3. wordt de notificatie-status gevuld met `not-done`, en de Foutmelding-reden gevuld met de foutcode.
6.3	Het systeem verzendt via de AORTA FHIR Resource Broker Interface, een notificatie over de status van het ophalen van de verschillenrapportage, inhoudelijk op de wijze zoals beschreven in DocumentPickupNotifcation (Proxy).
6.4 <exit>	Het systeem ontvangt en verwerkt een response.

Post-condities

Deze post-condities gelden na het doorlopen van alle interacties in deze flow. De stappen waarvoor dit geldt wordt expliciet genoemd.

De response is correct verwerkt in het systeem.

Het systeem verwerkt de verschillenrapportage. Alle opgenomen verschillen worden verwerkt zoals gespecifideerd in verwerken verschillen.

Het systeem heeft van het verzonden request, de volgende attributen gelogd:

datum en tijd van ontvangst
request-id
initial-request-id
sender-id (app-id van de GBx-applicatie die het request verzendt)
receiver-id (role-id van de VZVZ component die het request ontvangt)

Aanvullend daarop heeft het systeem van het verzonden request de volgende attributen gelogd (indien aanwezig):

Verzoek-id
Referentie-gerelateerde-RequestDocumentPickup
Register-sync-id

Het systeem heeft van de ontvangen response, de volgende attributen gelogd:

datum en tijd van response
request-id van het bijbehorende request
initial-request-id van het bijbehorende request
sender-id (role-id van de VZVZ component die de response heeft verzonden)
receiver-id (app-id van de GBx-applicatie die de response ontvangt)
HTTP statuscode en eventueel geretourneerde foutinformatie

Aanvullend daarop heeft het systeem van het verzonden request de volgende attributen gelogd (indien aanwezig):

Verzoek-id
Referentie-gerelateerdd-RequestDocumentPickup
Register-sync-id

Formaat Inputbestand Register Synchronisatie

Het inputbestand bevat de gegevens die nodig zijn om alle registraties te identificeren. Tijdens transport is het bestand gecomprimeerd met gzip. Het inputbestand is een csv bestand. Dit betekent dat er per verwijzing één regel wordt gebruikt en de regel wordt beëindigd met een CR/LF (US-ASCII 13,10). Alle onderstaande attributen worden van elkaar gescheiden door een komma (“,”). De volgorde van de attributen geeft de volgorde van de gegevens in de csv.

Afhankelijk van het te synchroniseren register (VWI, ACT, of ABR) zijn er verschillende eisen voor het inputbestand. Afhankelijk van het Type-register-sync uit de RequestDocumentPickup gelden de register specifieke eisen voor het inputbestand zoals hieronder beschreven.

Inputbestand VWI synchronisatie

Attribuut	Cardinaliteit	Formaat
Patiënt-id	1..1	BSN formaat
Gegevenssoort-of-bouwsteentype	1..1	Dit is een waarde uit het codesysteem 2.16.840.1.113883.2.4.15.4 of 2.16.840.1.113883.2.4.3.111.15.3
Bijwerktijd-in-lokale-administratie	1..1	Timestamp, in het formaat YYYYMMDDHHMMSS bijvoorbeeld 20110417161004
Applicatie-id	1..1	Het applicatie-id van het XIS. Dit is een waarde uit het codesysteem 2.16.840.1.113883.2.4.6.6
Zorgaanbieder-id	1..1	Het UZI-registerabonneenummer(URA) van de verantwoordelijke zorgaanbieder. Dit is een waarde uit het codesysteem 2.16.528.1.1007.3.3. De URA in het bestand dient uit 8 cijfers te bestaan en dient indien nodig met voorloopnullen te worden aangevuld.

Inputbestand ACT synchronisatie

Dit moet nog uitgewerkt worden.

Inputbstand ABR synchronisatie

Dit moet nog uitgewerkt worden.

Formaat Verschillenrapportage Register Synchronisatie

De verschillenrapportage bevat de gegevens die nodig zijn om alle verwijzingen te identificeren en te groeperen. Tijdens transport is het bestand gecomprimeerd met gzip. De verschillenrapportage is een csv bestand. Dit betekent dat er per verwijzing een regel wordt gebruikt en de regel wordt beëindigd met een CR/LF (US-ASCII 13,10). Alle onderstaande attributen worden van elkaar gescheiden door een komma (“,”). Elke registratie in het betreffende AORTA register welke afwijkt van het inputbestand wordt in de verschillenrapportage opgenomen als een regel. De volgorde van de attributen geeft de volgorde van de gegevens in de csv.

Afhankelijk van het te synchroniseren register (VWI, ACT, of ABR) zijn er verschillende eisen voor de verschillenrapportage. Afhankelijk van het Type-register-sync uit de RequestDocumentPickup gelden de register specifieke eisen voor de verschillenrapportage zoals hieronder beschreven.

Verschillenrapportage VWI sync

Attribuut	Cardinaliteit	Formaat
Patiënt-id	1..1	BSN formaat
Gegevenssoort of bouwsteentype	1..1	Dit is een waarde uit het codesysteem 2.16.840.1.113883.2.4.15.4 of 2.16.840.1.113883.2.4.3.111.15.3
Bijwerktijd in de VWI	0..1	Indien de verwijzing in de VWI staat wordt deze gevuld met de timestamp van de laatse wijziging van de verwijzing. Bevat een timestamp, in het formaat YYYYMMDDHHMMSS bijvoorbeeld 20110417161004.
Applicatie-id	1..1	Het applicatie-id van het XIS. Dit is een waarde uit het codesysteem 2.16.840.1.113883.2.4.6.6
Zorgaanbieder-id	1..1	Het UZI-registerabonneenummer(URA) van de verantwoordelijke zorgaanbieder. Dit is een waarde uit het codesysteem 2.16.528.1.1007.3.3. De URA in het bestand dient uit 8 cijfers te bestaan en dient indien nodig met voorloopnullen te worden aangevuld.
Categorie	1..1	Indien de vergelijking succesvol was bevat deze categorie een van de volgende codes: `KEY205` De verwijzing staat wel in de VWI, maar niet in het inputbestand. `KEY204` De verwijzing staat wel in het inputbestand , maar staat niet in de VWI. `KEY206` De verwijzing staat in het inputbestand, en in de VWI. Echter, de bijwerktijd van deze verwijzing in de VWI is meer dan 6 seconden eerder dan de bijwerktijd die is geregistreerd in het inputbestand. Indien een verwijzing niet succesvol kan worden vergeleken bevat deze categorie de volgende code: `SYN105`: Een attribuut van de verwijzing is leeggelaten in het inputbestand.

Verschillenrapportage ACT synchronisatie

Dit moet nog uitgewerkt worden.

Verschillenrapporage ABR synchronisatie

Dit moet nog uitgewerkt worden.

Verwerken verschillen

De verschillenrapportage bevat een verzameling met alle door het XIS opgestuurde registraties in het register, en alle in AORTA opgeslagen registraties. Per registratie wordt met de Categorie aangegeven wat de status van deze registratie is. Afhankelijk van de Categorie moeten bepaalde controles worden uitgevoerd.

Afhankelijk van het te synchroniseren register (VWI, ACT of ABR) gelden er verschillende eisen over hoe de verschillen uit de verschillenrapportage moet worden verwerkt. Deze zijn hieronder gespecificeerd.

Verwerken verschillen VWI synchronisatie

Categorie 1 - KEY205

Deze verwijzing is aanwezig in de VWI maar niet aanwezig in het inputbestand.

Is er lokaal opt-in geregistreerd voor deze verwijzing?
- Ja: Is de lokale bijwerktijd van de verwijzing later dan de Document- beschikbaar-vanaf van de initiele RequestDocumentPickup?
  - Ja: Stuur deze verwijzing op mbv de Aanleveren mutaties ACT/VWI use case.
  - Nee: Creëer de verwijzing lokaal en stuur deze op mbv de Aanleveren mutaties ACT/VWI use case. Dit zorgt ervoor dat de bijwerktijd op in de VWI later komt te staan dan de bijwerktijd lokaal in het XIS.
- Nee: Meld de verwijzing af mbv de Aanleveren mutaties ACT/VWI use case. Gebruik de gegevens uit de verschillenrapportage.

Categorie 2 - KEY204

Deze verwijzing is aanwezig in het inputbestand maar niet aanwezig in de VWI.

Categorie 3 - KEY206

Deze verwijzing is aanwezig in het inputbestand en in de VWI. Echter de bijwerktijd van deze verwijzing in de VWI is eerder dan de bijwerktijd gemeld in het inputbestand. Deze verwijzing moet door de XIS worden bijgewerkt in de VWI mbv de Aanleveren mutaties ACT/VWI use case

Is er lokaal opt-in geregistreerd voor deze verwijzing?
- Ja: Stuur deze lokale verwijzing op mbv de Aanleveren mutaties ACT/VWI use case.
- Nee: Verwijder de verwijzing lokaal.

Categorie 4 - SYN105

Deze verwijzing mist een attribuut in het inputbestand. Er moet in het XIS worden gecontroleerd waarom een van de verplichte attributen (zie Formaat Inputbestand Register Synchronisatie) niet is meegenomen in het inputbestand.

Toetsing RequestDocumentPickup

Het systeem toetst:

Of het ontvangen Document-url geldig is. Als deze niet geldig is wordt de foutcode SYN102 geregisteerd voor de te verzenden DocumentPickupNotification.
Of de Document-url niet eerder is ontvangen. Als deze eerder is ontvangen is wordt de foutcode ALREADYUSEDDOCUMENTID geregisteerd voor de te verzenden DocumentPickupNotification.
Of de Document-id bekend is. Als deze niet bekend is wordt de foutcode UNKNOWNDOCUMENTID geregisteerd voor de te verzenden DocumentPickupNotification.
Of het Document-type ondersteund is. Als deze niet ondersteund is wordt de foutcode Syn103 geregisteerd voor de te verzendenDocumentPickupNotification .

Toetsing Verschillenrapportage

Het systeem toetst:

Of het document een Applicatie-id of een Zorgaanbieder-id bevat. Als dit niet het geval is wordt de foutcode NS101 geregistreerd voor de te verzenden DocumentPickupNotification.
Of de Zorgaanbieder-id (URA) in het document overeenkomt met die van de secundaire actor. Als dit niet het geval is wordt de foutcode INVALCERT geregistreerd voor de te verzenden DocumentPickupNotification.
Of de Applicatie-id in het document onder de URA valt van de secundaire actor. Als dit niet het geval is wordt de foutcode SYN102 geregistreerd voor de te verzenden DocumentPickupNotification.
Of het document de juiste syntax bevat. Als dit niet het geval is wordt de foutcode SYNgeregistreerd voor de te verzenden DocumentPickupNotification.

Mitz use cases

Verwerken Toestemming Notificatie

Primaire actor	Notificatie Broker
Systeem	<GBx-systeemrol>
Code	AOF.UC.RC.800.v1

Pre-condities

Het systeem is aangesloten op de secundaire actor(en).

Het systeem beschikt over de juiste kwalificaties om deze use case te mogen uitvoeren.

Main flow

Stap

Omschrijving

Uitkomst

1

Het systeem ontvangt een notificatie

2

<exit>

Het systeem retourneert een response naar de primaire actor.

Verwerking succesvol

statuscode 200 OK

Post-condities

Het systeem heeft van het ontvangen request, de volgende attributen gelogd:

datum en tijd van ontvangst
request-id
initial-request-id
receiver-id (app-id van de GBx-applicatie die het request ontvangt)

Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:

datum en tijd van response
request-id van het bijbehorende request
initial-request-id van het bijbehorende request
sender-id (app-id van de GBx-applicatie die de response verzendt)
HTTP statuscode en eventueel geretourneerde foutinformatie