Session Management

Bij het inloggen (sessie) op de externe eGezondheidsdiensten, zoals de ziekenhuisnetwerken, MyCareNet, Recip-e of het Gedeeld Farmaceutisch Dossier, authentiseert de zorgverlener zich normaal aan de hand van zijn elektronische identiteitskaart (eID) en de bijbehorende pincode of aan de hand van zijn certificaat en bijbehorend wachtwoord. 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 zorgverleners zich kunnen blijven authentiseren. U vindt hierna meer informatie over deze procedures.

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 zorgverleners van kracht is?

Als gezondheidsprofessional moet u hiervoor niets doen. De dienst Session Management (Secure Token Service) bevindt zich voortaan op een “high availability” infrastructuur, bestaande uit twee onafhankelijke zones. De activering en desactivering van de noodprocedure gebeurt automatisch wanneer het eHealth-platform hiertoe een elektronische opdracht geeft. De software van de gezondheidsprofessional schakelt automatisch over naar een functionele zone van het eHealth-platform.

Ondersteunt mijn softwarepakket de noodprocedure?

De noodprocedure wordt ondersteund door alle softwarepakketten.

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:

1. Pas het “sliding window”-principe toe.
2. 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 softwarepakket de procedure voor de hernieuwing van de token?

Niet alle softwareleveranciers hebben reeds hun softwarepakket gecertificeerd voor de procedure van hernieuwing van de authenticatie-token. Bovendien beschikken niet alle zorgverleners 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):

• Prodoc (CEGEKA)
• Medinect (Offimed)

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

/

Fallback-procedure voor de authenticatie 

Uitzonderlijk kan de zorgverlener tijdelijk een beroep doen op een fallback-procedure door manueel zijn wachtwoord 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 derden te vermijden.

Uitzonderlijk betekent dat de zorgverlener 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 zorgverlener zich opnieuw moet aanmelden en authentiseren.

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

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