GBX.APR.e4060, GBX.APR.e4170.1 - Wijzigen TKID applicatie
Beginsituatie
De GBZ Beheerder is lokaal ingelogd op vertrouwensniveau laag of hoger.
Trigger
De GBZ Beheerder initieert de functie via het systeem.
Interacties
· Het systeem verzendt een beherenTKID-bericht naar de ZIM conform HL7v3 IH APR.
· Het systeem ontvangt een ontvangstbevestiging conform HL7v3 IH APR.
Resultaat
Het LSP heeft de in het bericht opgenomen TKID’s opgenomen in het applicatieregister.
Uitzonderingen
Uitzonderingen zijn beschreven in de Foutentabel.
Opties
-
Responsetijd
-
Betrouwbaarheid
-
Toelichting
De logische attributen van dit bericht zijn te vinden in het Ontwerp Applicatieregister.
Vanuit het XIS-acceptatieproces wordt er een typekwalificatieID (TKID) gegenereerd. In overleg tussen de XIS-leverancier en het VZVZ-acceptatieteam wordt de granulariteit van een TKID bepaald. Het is mogelijk dat er voor een XIS-applicatie één of meerdere TKID’s worden uitgegeven.
Aan elk TKID zijn één of meerdere specifieke systeemrol(len) gekoppeld. Aan elk systeemrol zijn één of meerdere interactieID’s gekoppeld. Een zorgaanbiederapplicatie (een bij de zorgaanbieder geïnstalleerde versie van een XIS-applicatie) kan meerdere TKID’s ondersteunen. Zie het [ONTW APR] voor het gegevensmodel en een beschrijving m.b.t. TKID’s.
In het geval een zorgaanbiederapplicatie gebruik wil maken van de functionaliteit van een bepaalde systeemrol, dient de zorgaanbiederapplicatie aan de betreffende TKID (behorende bij de specifieke systeemrol(len)) gekoppeld te worden. Vanuit de applicatie dient met het ‘beheren TKID’-bericht, het gewenste TKID ingestuurd te worden.
Er mogen alleen TKID’s ingestuurd worden, die door de afgenomen XIS-applicatiesoftware zijn verkregen naar aanleiding van een positieve acceptatie. De beheerder of het systeem van een bij een zorgaanbieder geïnstalleerde applicatie dient alleen die TKID’s in te sturen waarvan alle systeemrollen ook daadwerkelijk door de geïnstalleerde applicatie ondersteund worden.
Er kunnen meerdere TKID’s in het bericht opgenomen worden. Zodra een TKID niet bekend is, wordt er een foutcode (INVALIDETKID) met bijbehorende foutmelding (zie [Foutentabel]) gegenereerd. De mogelijk overige correcte TKID’s worden niet verwerkt in het applicatieregister. Alle TKID’s dienen opnieuw ingestuurd te worden.
Bij elk door het LSP succesvol ontvangen ‘beheren TKID’-bericht, worden de bestaande TKID-koppelingen met de zorgaanbiederapplicatie verwijderd en worden er koppelingen gemaakt met de in het bericht opgenomen TKID’s. Hierbij geldt dat een bestaande status van reeds aanwezige systeemrollen (gekoppeld aan een TKID) niet wordt veranderd. Koppelingen die nog niet bekend waren binnen het applicatieregister krijgen direct de status ‘actief’.
In principe geldt dat er bij elk nieuw verkregen TKID, als gevolg van een acceptatie van een applicatiewijziging of –uitbreiding, er één of meerdere TKID’s opnieuw ingestuurd moeten worden. Denkbare situaties zijn:
· Installeren nieuwe functionaliteit;
¨ Initiële installatie;
¨ Nieuwe acceptatie van de XIS-applicatie.
Vanuit spreadsheet: TKID: test en configuratie ID. hiermee geef je aan welke performances je hebt. "Ik ondersteun actie X (EU PS)". Verdere beschrijving te vinden in APR (Rob deelt link). IB: is deze nu verwerkt in deze eis?)
Terugzetten oude functionaliteit (met een eerder verkregen TKID).
Identificatiecode | GBX.APR.e4060, GBX.APR.e4170.1 |
Vzvz_Moscow | Verplicht |
Vzvz_Req_Soort | Functional |
Vzvz_Req_Type | Product |
Vzvz_Req_Verificatie | Acceptatietest |
Vzvz_Req_Vertrouwensniveau | Laag |