Noodprocedures Session Management

Bij het inloggen (sessie) op de externe eGezondheidsdiensten, zoals MyCareNet, Recip-e of het Gedeeld Farmaceutisch Dossier, authentiseert de apotheker zich normaal aan de hand van zijn elektronische identiteitskaart (eID) en de bijbehorende pincode. Op die manier bewijst hij dat hij wel degelijk de betrokken persoon is en niemand anders. Dit is wat men authenticatie noemt.

Het eHealth-platform beschikt over een noodprocedure of een “Business Continuity Procedure” in geval van verstoring van zijn diensten, waardoor de apothekers zich kunnen blijven authentiseren.

Noodprocedure voor authenticatie

Deze procedure bestaat erin de dienst session management (Secure Token Service), op basis waarvan een authenticatie-token gegenereerd wordt, te laten overschakelen naar het derde datacenter van het eHealth-platform.

Hoe kan men weten wanneer de noodprocedure voor de apotheken van kracht is?

Als apotheker hoeft u niets te doen. De activering en desactivering van de noodprocedure gebeurt automatisch. Het eHealth-platform schakelt zijn dienst session management (Secure Token Service) over naar zijn derde datacenter en de software van de apotheker leidt de oproep van deze dienst automatisch om.

Ondersteunt mijn software de noodprocedure?

Niet alle softwareleveranciers hebben reeds hun software gecertificeerd voor de noodprocedure. Bovendien beschikken niet alle apothekers over een softwareversie die voldoende recent is om deze procedure te integreren. Om gebruik te kunnen maken van de noodprocedure dient u dus een softwareversie te gebruiken waarin deze noodprocedure geïntegreerd is.

Op basis van de informatie waarover we beschikken, is de noodprocedure geïntegreerd in de laatste versie van de volgende softwarepakketten (tussen haakjes staat de naam van de leverancier indien die verschilt van de naam van het pakket):

NextPharm
Officinal
Pharmony
ViaNova
Ultimate (Pharmagest)
Farmad Twin
CareConnect Pharmacist (Corilus)

Voor de volgende softwarepakketten hebben we geen bevestiging dat de noodprocedure al geïmplementeerd is en uitgerold bij de gebruikers (tussen haakjes staat de naam van de leverancier indien die verschilt van de naam van het pakket):

EPC
IPharma

Procedure voor de hernieuwing van de authenticatie-token:

Voor de leveranciers die de noodprocedure (nog) niet geïmplementeerd hebben of in geval van storing ondanks de activering van de noodprocedure, raden wij aan om de volgende instructies te volgen met betrekking tot de dienst I.AM STS

Pas het “sliding window”-principe toe.
Bewaar de huidige authenticatie-token op de schijf.

Een authenticatie-token is maximum 24 uur geldig. Gedurende die tijd kan hij meerdere keren hergebruikt worden en is het niet nodig telkens een nieuwe aan te vragen. Indien er problemen zijn met I.AM STS en er geen nieuwe token uitgereikt kan worden, zou de gebruiker nog steeds toegang moeten krijgen tot zijn gebruikelijke diensten zolang zijn token geldig is.

Indien de randapparatuur van de zorgverlener heropstart, moet de eerder verkregen authenticatie-token worden hergebruikt.

Het “sliding window”-principe kan enkel worden toegepast met een geldige authenticatie-token. Op die manier kunnen problemen van korte duur met I.AM STS vermeden worden.

Indien de gebruiker een geldige authenticatie-token heeft, dient hij

na een bepaalde periode (= X / 2) een nieuwe token aan te vragen.
- Indien I.AM STS een nieuwe token levert, dan zal die vanaf dat moment X uren geldig zijn.
- Indien storingen de uitreiking van een nieuwe token door I.AM STS verhinderen, moet de gebruiker na X / 4 uur opnieuw proberen om er een te verkrijgen.
- ...

Het “sliding window”-principe veronderstelt dat de gebruiker meerdere keren zijn eID-pincode ingeeft gedurende deze periode.

Ondersteunt mijn software de procedure voor de hernieuwing van de token?

Niet alle softwareleveranciers hebben reeds hun software gecertificeerd voor de procedure van hernieuwing van de authenticatie-token. Bovendien beschikken niet alle apothekers over een softwareversie die voldoende recent is om deze procedure te integreren. Om gebruik te kunnen maken van de procedure dient u dus een softwareversie te gebruiken waarin deze procedure geïntegreerd is.

Op basis van de informatie waarover we beschikken, is de procedure van hernieuwing van de authenticatie-token geïntegreerd in de laatste versie van de volgende softwarepakketten (tussen haakjes staat de naam van de leverancier indien die verschilt van de naam van het pakket):

EPC
NextPharm
Officinall
Pharmony
ViaNova
CareConnect Pharmacist (Corilus)
Ultimate (Pharmagest)

Voor de volgende softwarepakketten hebben we geen bevestiging dat de procedure van hernieuwing van de authenticatie-token al geïmplementeerd is en uitgerold bij de gebruikers (tussen haakjes staat de naam van de leverancier indien die verschilt van de naam van het pakket):

Ipharma
Farmad Twin

Fallback-procedure voor de authenticatie

Uitzonderlijk kan de apotheker tijdelijk een beroep doen op een fallback-procedure door manueel zijn paswoord van de eHealth-keystore (certificaat) in te voeren. Het is niet toegelaten systematisch gebruik te maken van deze methode, teneinde elk misbruik en fraude door derde te vermijden.

Uitzonderlijk betekent dat de apotheker niet over zijn eID beschikt, bijvoorbeeld in geval van verlies van zijn eID, of dat het onmogelijk is om aan te melden met de eID en pincode door technische problemen.

Tijdelijk houdt in dat de connectie (sessie) beperkt is tot een periode van 12 uur, waarna de apotheker zich opnieuw moet aanmelden en authentiseren.

De concrete werking van de fallback-procedure kan verschillen naargelang het softwarepakket. Indien de apotheker hier vragen over heeft, kan hij terecht bij de helpdesk van zijn softwareleverancier.

Het is belangrijk dat de apotheker zijn paswoord bewaart om te kunnen aanmelden zonder eID (d.w.z. het paswoord van de eHealth-keystore (certificaat)) en dit paswoord gemakkelijk kan terugvinden. In geval van verlies van zijn paswoord kan hij zich richten tot de helpdesk van zijn softwareleverancier.