De stekkertjes-mythe: waarom maatwerk SSO niet schaalt

De verleiding van “één keer bouwen”

Het lijkt zo makkelijk: we spreken af hoe de SSO werkt, welke stukjes data er 'over de lijn' moeten, we testen dat en zijn klaar.

Totdat de wereld verandert: nieuwe wensen vragen om extra gegevens, de autorisatie moet net anders, er zijn updates in Nedap Ons® of het gekoppelde systeem. De SSO vereist dat beide systemen 'in sync' blijven.

En dan verandert die stekker ineens in een ketting die beide systemen strak aan elkaar ketent. We moeten samen afstemmen wanneer nieuwe versies online gaan, en de leverancier van de koppeling heeft zich voor zijn doorontwikkeling afhankelijk gemaakt van de roadmap van Nedap Ons® .

Eén foutje en alles ligt eruit

Het lijkt zo handig: als we toch aan de slag gaan met maatwerk, dan kunnen we in één keer navigatie, authenticatie (inloggen), autorisatie (rechten) en gegevensuitwisseling (informatie over medewerker, cliënt, etc.) regelen.

Maar, zoveel tegelijk willen oplossen zorgt voor veel afhankelijkheden. En als één van die afhankelijkheden een storing heeft, dan ligt de hele SSO eruit.

Door elk van die onderdelen individueel op te lossen wordt het hele systeem beter bestand tegen verstoringen.

Maatwerk SSO zit de zorgverlener in de weg

Het lijkt zo mooi: één knop die de zorgverlener naar de juiste plek in een ander systeem brengt en daarnaast ook nog login, rechten en gegevensuitwisseling regelt.

Maar het ideale proces loopt lang niet altijd via die ene knop in Nedap Ons®. Misschien wil de gebruiker:

1. Zijn taak (of zelfs dag) beginnen in het gekoppelde systeem. Maar als de SSO in Nedap Ons® is gebouwd, dan wordt de gebruiker gedwongen om vanuit Nedap Ons® te beginnen. Het zou voor deze gebruiker beter zijn om vanuit het SSO-portaal van de organisatie (bijvoorbeeld Microsoft of Google) in te loggen.

2. Voor zijn taak switchen tussen cliënten binnen het gekoppelde systeem. Omdat de autorisatie gekoppeld is aan het gebruik van de SSO, moet de gebruiker voor elke cliënt opnieuw navigeren vanuit Nedap Ons® - of het gekoppelde systeem moet onze autorisaties nabouwen.

3. Er op kunnen rekenen dat aanpassingen aan gegevens in Nedap Ons® ook in het gekoppelde systeem terechtkomen. Dat gebeurt alleen op het moment dat de medewerker de SSO gebruikt, daarna niet meer.

Door de onderdelen van maatwerk SSO individueel op te lossen, kun je deze ook in een andere volgorde inzetten. Zo kunnen we het zorgproces beter ondersteunen.

Schaalbaarheid is het uitgangspunt

Het lijkt zo'n kleine eenmalige inspanning, een maatwerk SSO. Maar het vraagt doorlopend onderhoud en ondersteuning, en dat remt onze doorontwikkeling op andere gebieden. Daar komt bij dat deze SSO's ook nog eens moeilijker te activeren en beheren zijn voor zorgorganisaties, omdat ze niet in Ons® Podium verschijnen.

In onze ontwikkellijnen "Nedap Ons® als open ecosysteem" en "Standaardisatie van gegevens" willen we zorgmedewerkers zo goed mogelijk helpen om verder te werken in andere applicaties. We doen dat zoveel mogelijk volgens standaarden, zodat het goed schaalbaar en beheerbaar is.

Hoe moet het dan wel?

Om duurzaam en toekomstbestendig te koppelen is het belangrijk dat we ontkoppelen. Niet meer proberen om alles met één component op te lossen, maar voor elk onderdeel de beste oplossing:

1. Navigatie: Om de gebruiker naar de juiste plek in een ander systeem te laten navigeren, ondersteunen we deeplinks.

2. Authenticatie: Voor het inloggen van de gebruiker adviseren we OpenID Connect (OIDC). Dat is een breed gebruikte en toekomstbestendige standaard. Veel zorgorganisaties zitten al in het ecosysteem van Microsoft of Google, of hebben een andere OIDC-geschikte SSO-provider. Die kan gebruikt worden om automatisch mee in te loggen in het gekoppelde systeem.

3. Gegevensoverdracht: Met Ons® API hebben we een API-platform waarmee een gekoppeld systeem gegevens uit Nedap Ons® kan ophalen of bewerken. Zorgorganisaties kunnen via Ons® Podium hun toestemming voor het delen van gegevens beheren.

4. Autorisatie: Via Ons® API kunnen koppelingen een autorisatie-endpoint gebruiken om te bepalen welke cliënten binnen het bereik van een medewerker vallen.

   
   SSO gaat om toegang. Dat moet betrouwbaar zijn. Een SSO die alles doet maakt het voor de andere leverancier heel moeilijk om het gekoppelde systeem weerbaar te maken tegen verstoring. Het is namelijk alles of niets. Door authenticatie, autorisatie en gegevensuitwisseling afzonderlijk van elkaar op te lossen, kun je voor elk van die onderdelen een backup regelen. Door op deze manier te ontkoppelen maken we dingen niet ingewikkelder, maar beter ontworpen. Ontworpen om stabiel te zijn voor de zorgverlener, om onderhoud en innovatie makkelijker te maken voor de leveranciers, en om beheer makkelijker te maken voor de zorgorganisatie.