Terug

De Klinisch Informaticus als Enterprise Architect
Rob Malschaert

11 februari 2020

(Laatst aangepast: 22-12-2020)

De Klinisch Informaticus als Enterprise Architect

Dit jaar bestaat de opleiding tot Klinisch Informaticus 10 jaar. Dat betekent dat er inmiddels ook al een behoorlijk aantal klinisch informatici actief zijn in het veld. De klinisch informaticus acteert altijd op het snijvlak van zorg, IT en management. Maar met zo’n veelomvattend vakgebied betekent dit ook dat de klinisch informaticus heel veel verschillende rollen aan kan nemen. Het varieert van adviseur, tot projectleider en manager. Vandaag licht klinisch informaticus Rob Malschaert (opgeleid in 2011-2012) zijn rol als Enterprise Architect toe. Rob werkt als freelancer voor verschillende ziekenhuizen waaronder VieCuri Medisch Centrum in Venlo en Sint-Maartenskliniek te Nijmegen.

Enterprise Architectuur is een nog betrekkelijk jong vakgebied binnen de IT, gepositioneerd tussen bedrijfskunde, informatiekunde en informatica. Het heeft als doel om richting te geven aan ontwerp en realisatie van processen, organisatorische inrichting, informatievoorziening en technische (IT) infrastructuur. Maar hoe doe je dat nu in de praktijk? Vanuit mijn ervaring is de Enterprise Architect er vooral om:

 

  1. inzicht te brengen in het hier en nu
  2. richting te geven aan de toekomst

Inzicht brengen

Veel organisatie worstelen met digitalisering en IT. Het op een goede manier bij elkaar brengen van vraag en aanbod blijft een lastige klus. Een van de redenen hiervoor is dat veel organisaties geen goed beeld hebben van hun bestaande IT-landschap, en vooral niet van de relaties die alle componenten met elkaar hebben. Een Enterprise Architect helpt hierbij door inzicht en structuur te bieden. Op maat gemaakte visualisaties geven dat inzicht op het complexe IT landschap wat gedurende vele jaren is ontstaan. VieCuri Medisch Centrum maakt gebruik van een metamodel. Onderstaande afbeelding is hier een versimpelde weergave van. Het model laat zien welke verschillende objecten we kennen in de architectuur en hoe deze met elkaar samenhangen. Deze objecten en hun relaties zijn gebaseerd op de internationale architectuur standaard: Archimate. Archimate onderscheidt drie architectuurlagen: 

 

  1. Bedrijfsarchitectuur, gevisualiseerd in geel. In het metamodel staan de objecten Actor (kan een rol zijn, maar ook een afdeling) en het object Proces
  2. Informatiearchitectuur, gevisualiseerd in blauw. In het metamodel staat het object Applicatie
  3. Technische architectuur, gevisualiseerd in groen. In het metamodel staat het object server en cluster.

 

In onderstaande versimpelde weergave van het metamodel zien we dit als volgt terug: de nefroloog (actor) schrijft medicatie voor (proces) en gebruikt hiervoor twee applicaties; Diamant en HiX (applicatie). De applicatie Diamant maakt gebruik van vier verschillende servers (server). In dit simpele voorbeeld is dus te zien hoe de architectuur wordt uitgewerkt door alle lagen heen, van werkproces tot techniek. De meerwaarde van het metamodel zit vooral in het ‘in samenhang beschrijven’ van alle objecten. In een meer traditionele aanpak met behulp van excel-lijsten met applicaties en/of servers is het vaak heel lastig om deze samenhang te tonen. Dit metamodel gebruiken we binnen VieCuri vervolgens als een template om de overige architectuur van VieCuri Medisch Centrum te beschrijven. We gebruiken hier de architectuur tool BlueDolphin voor. Wil je zelf eens stoeien met het maken van architectuurmodellen met behulp van Archimate? Dan is de open-source tool Archi geschikt.

Figuur 1Versimpelde weergave metamodel aan de linkerkant een voorbeeld van een uitwerking

Richting geven

Met alleen een beeld van het hier en nu ben je er nog niet. De Enterprise Architect heeft ook een grote rol bij het geven van richting aan de toekomst. Architectuurprincipes zijn daarbij belangrijk. Architectuurprincipes zijn richtinggevende principes en zijn een afgeleide van de algemene missie, visie en strategie van de organisatie. Ze zijn daarmee het fundament van iedere Enterprise Architectuur. Van ieder principe wordt omschreven wat de reden (de rationale) van het principe is en wat de implicaties van het principe zijn. Hieronder een voorbeeld:

 

  • Architectuurprincipe: ziekenhuisbelang gaat voor afdelingsbelang
  • Statement: we geven voorkeur aan de aanschaf (en/of ontwikkeling) van applicaties die ziekenhuisbreed kunnen worden ingezet, boven het aanschaffen/ontwikkelen van applicaties met vergelijkbare of gelijke functionaliteit die slechts voor een deel van het ziekenhuis bruikbaar zijn
  • Rationale: meervoudig aanwezige functionaliteit is kostbaar en werkt conflicterende gegevens/informatie in de hand. 

 

Implicaties: organisatieonderdelen in het ziekenhuis mogen niet zelf voorzieningen ontwikkelen voor eigen gebruik als die voorzieningen gelijk of gelijkwaardig zijn aan ziekenhuisbrede voorzieningen. Op deze wijze wordt de inzet van schaarse middelen voor het ontwikkelen van min of meer vergelijkbare capaciteit vermeden.

Bedrijfsprocessen die eerder ondersteund werden door meervoudig aanwezige gelijke of gelijkwaardige voorzieningen zullen geharmoniseerd en gestandaardiseerd worden.

 

Idealiter heeft een organisatie een beperkt aantal architectuurprincipes. Denk aan 15 . Het principe hierboven is toe te schrijven aan de bedrijfslaag, maar er dienen ook principes te zijn voor de informatie- en technische laag. Deze principes worden vervolgens gebruikt in de initiatiefase van ieder project. Daar wordt een toets gedaan of een project wel voldoet aan de architectuurprincipes, en indien niet, wat de reden hiervoor is. Het kan immers zo zijn dat er een goede reden bestaat om van het principe af te wijken. Het is dan van belang om dit te onderbouwen en er een beargumenteerd besluit over te nemen. Hierdoor komt in de initiatiefase van het project al de juiste discussie op gang: draagt het project wel bij aan de strategische doelstellingen van de organisatie, en past de voorgestelde oplossing wel binnen het technische landschap van de organisatie, etc.

 

De architectuurprincipes worden voor het dagelijkse werk op de IT afdeling nog verder vertaald naar richtlijnen, criteria en standaarden. Bijvoorbeeld het architectuurprincipe: ‘hanteer standaarden’, wordt dan concreet gemaakt in welke standaarden vervolgens worden gehanteerd. In dit voorbeeld ‘we gebruiken HL7 v2.x voor op berichten gebaseerde uitwisseling tussen applicaties’, of ‘beelden worden opgeslagen in DICOM’ etc.

Figuur 2Architectuurprincipes en hun gebruik

Enterprise Architectuur is geen oplossing voor een versnipperd IT landschap op de korte termijn, of een oplossing voor al het achterstallig onderhoud. Werken onder architectuur is een manier van werken en denken. Het brengt plannen en initiatieven in lijn met de strategie van de organisatie en draagt hiermee bij aan het verkleinen van de kloof tussen de organisatie en IT. Voor vragen en/of opmerkingen hierover, neem gerust contact op.

 

Rob Malschaert

Klinisch Informaticus en Enterprise Architect

rob@malschaertadvies.nl

Toon alle referenties

Auteur

Lees meer over