Middleware in zorg is bewezen selectieaanpak

Het selecteren van een middleware-oplossing is geen eenvoudige opdracht. Toch zijn er genoeg argumenten om ervoor te kiezen: sturen op integrale betrouwbare data, realtime-management- en stuurinformatie, dashboarding, portaalontwikkeling, ontsluiting van cliëntgegevens naar Persoonlijk Gezondheidsdossiers en externe informatie-uitwisseling. De vraag is hoe de juiste oplossing te selecteren. Dit artikel presenteert een in de praktijk bewezen selectieaanpak.

Voor het selecteren van een middleware-oplossing of een enterprise service bus (ESB) is een model ontwikkeld dat aandacht levert aan acht dimensies waarmee een compleet en concreet beeld ontstaat. De dimensies zijn it-overstijgend en bestaan uit sub-dimensies. Het doel van het model is het bepalen van informatiebehoeften, doelstellingen, doelgroepen, scope en risico’s zodat het goed aansluit bij de zorginstelling.

Ter voorbereiding biedt het model een hulpmiddel voor de it-architect, procesarchitect, security-officer, functioneel en technisch applicatiebeheer om vanuit hun eigen vakgebied de vragen, wensen en eisen in kaart te brengen en concreet te maken.

De wensen en eisen worden vervolgens per dimensie vastgelegd in een vragenlijst die uitgestuurd wordt naar de leveranciers.

De selectie van een middleware-oplossing met de hulp van dit model levert een voor de organisatie juiste focus op en voorkomt het starten van een project vanuit alleen een ict- perspectief.

Bedrijfsinformatie

De dimensie ‘bedrijfsinformatie’ richt zich op het aansluiten bij de strategie van de zorginstelling. Thema’s binnen de zorg zijn op dit moment administratieve lastenverlichting, afname van de werkdruk bij de zorgmedewerkers en kostenbesparingen. Daarnaast wordt gezocht naar het ontkoppelen van de bedrijfsprocessen met de onderliggende it-systemen zodat wijzigingen in bedrijfsprocessen minimale impact hebben op it en vice versa.

De continuïteit van de zorginstelling is ook een thema. Een middleware-oplossing sluit aan bij de api-economie en bij het toenemende gebruik van mobiele apparaten en het werken met cloud-oplossingen. In dit specifieke geval moet de middleware aansluiten op de standaarden in de zorg, bijvoorbeeld HL7 en Edifact. Verder is de vraag of de zorginstelling alleen met bewezen technologie werkt of een risico durft te nemen. Door het stellen van de juiste vragen ontstaat een compleet beeld of de aangeboden middleware-oplossing aansluit bij de strategie van de zorginstelling.

Functionaliteiten

De tweede dimensie richt zich op ‘functionaliteiten’ van de middleware. Middleware zorgt voor een ontkoppeling tussen de vragende en ontvangende applicatie waardoor het aansluiten van nieuwe en wijzigen van bestaande services eenvoudiger wordt. Het gaat hier om soorten connectoren als XML, csv, ftp, http, Web services, Soap, File enzovoort.

Daarnaast is belangrijk op welke manier de middleware vertaalslagen tussen de data kan uitvoeren, bijvoorbeeld via een grafische mapper of een programmeertaal.

De implementatie van een mapping of een messageflow is over het algemeen in enkele dagen gereed. Echter, elke applicatie heeft haar eigen gebruiksaanwijzing: de servicedefinities van de systemen, de implementatie om de data te ‘handlen’ levert vertraging op (fouten in de data, fouten in de software), datastructuren verschillen of data is verschillend. De ontvangende systemen zijn niet altijd flexibel in het ontvangen van data. Het kan zijn dat er meer data over te zetten is dan de api aankan. Op dat moment is overleg met de leveranciers noodzakelijk en kan dat een aanpassing op de api tot gevolg hebben.

De middleware-oplossing moet een duidelijke logging voor de herleidbaarheid van de data hebben zodat dit is te gebruiken voor audit-doeleinden. Verder is het handig om publish & subscribe-mechanismen voor logging en error-handling beschikbaar te hebben zodat er een email gestuurd wordt naar iemand op een moment van uitval.

Niet onderscheidend maar het gebruik van een versiebeheersysteem werkt kwaliteitverhogend en medewerkers kunnen onafhankelijk van elkaar ontwikkelen. 

Koppelingen

De derde dimensie betreft ‘koppelingen’ met bestaande systemen en externe systemen. Het maken van nieuwe koppelingen wordt versneld door hergebruik van (onderdelen van) de gerealiseerde koppelingen echter de onhebbelijkheden van de targetapplicaties blijven een punt van aandacht. Dit gaat niet veranderen door gebruik te maken van een andere tool, een andere aanpak of een andere systeemintegratie specialist.

Het product moet de gangbare standaarden rondom authenticatie, autorisatie, encryptie en security ondersteunen.

Om overbelasting van de doelsystemen te voorkomen, wordt er gewerkt met workloadmanagement (per systeem instellen hoeveel berichten per seconde aangeboden worden). Daarnaast worden queues gebruikt om berichten te bufferen. De betrouwbaarheid wordt verhoogd door te werken met een transactionele messaging-infrastructuur.

Door data te loggen naar een bestand of database en het gebruik van queues om berichten op te vangen, wordt geborgd dat er geen data verloren gaat binnen de koppelingen.

Helpdesk & ondersteuning

De dimensie ‘helpdesk & ondersteuning’ inventariseert de beheerorganisatie, releasemanagement, autorisatie en documentatie en ondersteuning. Het beheer van een middleware-oplossing is lastig in te schatten. Als de koppelingen goed ontwikkeld zijn, is het beheer minimaal. De it-competenties binnen de meeste zorginstellingen liggen op beheren en niet op ontwikkelen en ontwikkelaars zijn niet eenvoudig te vinden. Fix packs en grote releases van de leverancier vergen aandacht bij de aansluiting op het bestaande releasemanagement. Documentatie en ondersteuning middels een supportorganisatie, libraries, digitale handleidingen en wellicht websites is noodzakelijk voor ontwikkelaars.

Techniek

De dimensie ’techniek’ heeft betrekking op infrastructuur en beveiliging. De infrastructuur moet passend zijn voor de middleware-oplossing (Otap). In beginsel is dataopslag alleen voor logging en monitoring nodig maar schaalbaarheid moet mogelijk zijn om performance-issues te voorkomen.

De autorisaties van medewerkers, zowel systeem- als applicatiebeheer, moeten aansluiten bij het beleid van de organisatie. Draait de middleware-oplossing in een trusted zone, dan kan deze meeliften op de security van deze zone. Houd bovendien rekening met firewall en antivirussoftware.

Kosten

Met de dimensie ‘kosten’ worden de licentiekosten, onderhoud en ondersteuning in kaart gebracht. Een middleware-oplossing kost geld en het vergt concentratie om de licentiemodellen inclusief onderhoud en ondersteuning te doorgronden en de juiste waardering te geven. Vaak is een licentie nodig voor een acceptatie-omgeving en een productieomgeving. Daarnaast vergt het ontwikkelen van koppelingen, opbouwen van de ontwikkelomgeving en het opbouwen van het generieke datamodel kennis en tijd van een systeemintegratie specialist en dat kost geld.

Gebruiksvriendelijkheid

De ‘gebruiksvriendelijkheid’ van de middleware-oplossing heeft betrekking op de helpfunctionaliteit en de gebruikersinterface. Een middleware-oplossing is complex maar de mate van hergebruik van de verschillende generieke componenten versnellen de ontwikkelwerkzaamheden naar gelang de toename van het aantal koppelingen omdat er minder gecodeerd moet worden. Bij het realiseren van elke koppeling, bouwt de ‘ibrary verder uit. Een gebruiksvriendelijke, grafische ontwikkelomgeving ondersteunt dit proces.

Rapportages

Een middleware-oplossing genereert statistische informatie, ‘rapportages’, met betrekking tot het functioneren van het systeem en de verwerkingen van de berichtenstromen. De informatie wordt real-time op grafische wijze weergegeven via een administratieve web console en maakt het eenvoudig om het systeem te bewaken. Het doel is de middleware-oplossing aan te sluiten op de bij ICT al in gebruik zijnde applicatie monitoring tool.

Het resultaat van de selectie op basis van de acht dimensies leidt tot de hier afgebeelde spindiagram. De acht dimensies zijn bij de start van het toolselectie traject voorzien van een weging. In dit geval is gekozen om de dimensies Functionaliteiten en Gebruiksvriendelijkheid het meeste gewicht te geven. Het resultaat van deze selectie heeft geleid tot de keuze van middleware-oplossing nummer vier.

Conclusie en aanbevelingen

Zonder uitputtend te willen zijn, tracht dit artikel een bijdrage te leveren aan het verder ontwikkelen van een instrument om een zorginstelling, met de ambitie om te vernieuwen en te automatiseren, te ondersteunen bij het selecteren van een middleware-oplossing.

Door zorg te dragen voor een gedegen middleware-toolselectie zijn risico’s, mogelijkheden en beperkingen van de middleware-oplossing van te voren in beeld en wordt een tool gekozen die aansluit bij de wensen en cultuur van de organisatie.

Maarten de Lange, zelfstandig ict-specialist in de zorgsector