Implementaties van het elektronisch cliënten dossier (ecd) kenmerken zich door een lange doorlooptijd met veel kosten met daarbij een grote belasting van de organisatie. Het rendement van dit soort implementaties laat vaak sterk te wensen over. Hiervoor zijn vele redenen aan te wijzen, die organisatorisch en technisch van aard zijn. Een belangrijke technische reden is dat een technische implementatiestrategie ontbreekt.
Een belangrijke organisatorische reden is dat de primaire processen die worden ondersteund door het ecd onvoldoende in kaart zijn gebracht. Verder is het zo dat vaak in care instellingen de ict-functie sterk is ondervertegenwoordigd in de belangenafweging en vaak pas zeer laat wordt betrokken in de implementatie. Dit zorgt ervoor dat er onvoldoende aandacht is voor de technische implementatie en technische infrastructuur die de implementatie ondersteunt. Dat is een grote valkuil in dit soort projecten.
Een voorbeeld is bij een zorginstelling in het oosten van het land. Zij hadden totaal geen implementatiestrategie. Dit resulteerde in het terugdraaien van een implementatie omdat onvoldoende getest was en daarmee onvoldoende bekendheid met de wijzigingen die een systeem in de organisatie te weeg brengt. In de organisatie was totaal geen draagvlak voor het aanbrengen van de wijzigingen. Er was geen zicht op wat er gebeurt bij een implementatie op het netwerk. Kenmerken van veel tijd verdoen met onvoldoende resultaat.
OTABO-strategie
Door goed te kijken naar waar het aan schort is besloten een echte technische implementatiestrategie te ontwikkelen die de functionele implementatie in de organisatie ondersteund. Het is de bekende Otap-strategie, uitgebreid met een back-out-omgeving en ontwikkelomgeving, de zogenaamde Otapbo-strategie.
Otapbo staat voor ontwikkelomgeving, testomgeving, acceptatietestomgeving, productieomgeving, back-out-omgeving en opleidingsomgeving. Dit zijn zes verschijningsvormen van een applicatie die het totale proces van implementatie ondersteunen. Om dit voor elkaar te krijgen dient er wel een goede infrastructuur aan servers en opslag aanwezig te zijn. Een ecd kan namelijk meerder GB aan data opslag vergen.
De Otapbo-strategie wordt weergegeven in nevenstaand schema. Software implementaties en/of releasewijzigingen (rode pijlen) volgen de richting O–> T–> A–> P. Data ( groene pijlen) daarentegen volgen de tegengestelde richting P–> A–> T–> O.
Ontwikkelomgeving. De ontwikkelomgeving is bedoeld voor systeemontwikkeling en samenhangende unit- of moduletests. Zodra de ontwikkelaars het geheel of delen van het systeem gereed melden en daarvoor de benodigde documenten geaccordeerd overleggen, kan er besloten worden deze set over te hevelen naar de testomgeving.
Testomgeving. De testomgeving bevat in eerste instantie alleen de testobjecten van het betreffende project (wijziging) om de technische en functionele aspecten daarvan standalone te testen en te beoordelen. Afhankelijk van de gestelde testdoelen, kunnen andere objecten toegevoegd worden zodat specifieke relaties en interfaces kunnen worden getest. Zodra deze tests zijn afgerond en het totale systeem gereed gemeld is door de verantwoordelijke medewerker (ownership) kan het systeem worden aangeboden voor acceptatietest en overgeheveld worden naar de acceptatieomgeving.
Acceptatietestomgeving. De acceptatietestomgeving is zodanig ingericht en onderhouden dathet een representatieve afspiegeling is van de productieomgeving. Nieuwe functionaliteiten en/of releases worden beoordeeld in hun relatie tot de overige systemen binnen de organisatie waar het ziekenhuis informatiesysteem (zis) wordt geïmplementeerd, zonder dat de productieomgeving zelf wordt belast en er risico’s ontstaan voor de dagelijkse bedrijfsvoering. Aangezien er slechts één acceptatieomgeving bestaat zullen verschillende deelprojecten en releases het gebruik ervan onderling dienen af te stemmen. De aangeboden testobjecten dienen uiteraard ook zodanig van kwaliteit te zijn dat een beoordeling in de acceptatieomgeving mogelijk is.
Op grond van de resultaten van een acceptatietest besluit de eigenaar in overleg met de functioneel beheer het al dan niet in productie nemen van het systeem of release. In het geval van acceptatie promoveert het systeem of release naar de productieomgeving. De acceptatieomgeving blijft onveranderd. Bij een No-Go wordt het systeem of de release uit de acceptatieomgeving verwijderd en teruggezet naar de testomgeving. Afhankelijk van de situatie wordt de acceptatieomgeving teruggebracht in de toestand van vóór de overdracht of in de toestand vergelijkbaar met de productieomgeving.
Productieomgeving. De productieomgeving wijzigt nadat vanuit acceptatie een promotie plaatsvindt. Dit geldt uiteraard alleen voor software, systeemcomponenten en/of stuurbestanden of structuur van de programmatuur.
Back-out omgeving. Nadat een releasewijziging is gepromoveerd en in productie wordt genomen en naar behoren functioneert, dient het back-out-systeem na twee weken dezelfde release te bevatten. Tijdpad van twee weken is gekozen om bij majorverstoringen terug te kunnen vallen op een goed functionerend back-out-systeem.
Opleidingsomgeving. De opleidingsomgeving heeft dezelfde data en functionaliteit als de back-out-omgeving na implementatie. Voor de implementatie heeft de opleidingsomgeving dezelfde data en functionaliteit als de acceptatietestomgeving. De opleidingsomgevingj is volledig onafhankelijk van de productieomgeving en alle andere omgevingen. Deze omgeving wordt gebruikt om de mensen op te leiden.
Gezamenlijk platform
Door Otapbo te introduceren is er binnen de organisatie het besef gekomen dat de business verantwoordelijk is voor de wijziging, dat systeembeheer onderdeel is van de implementatie en dat de sturing vanuit applicatiebeheer plaatsvindt. De samenwerking tussen de verschillende partijen in de organisatie zorgt ervoor dat de implementatie van grote wijzigingen gecontroleerd gebeurt, waarbij de gehele organisatie is betrokken. Hiermee wordt een gezamenlijk platform gecreëerd (zowel technisch als organisatorisch) dat zorgt voor het slagen van een implementatie.
Techniek, functie en organisatie wordt meegenomen in het implementatieproces. Hiermee is de faalfactor techniek uit het implementatieproces gebannen.
Pleidooi
Een ecd-implementatie is een organisatieverandering. Om maximaal de vruchten te kunnen plukken van een dergelijke wijziging is het noodzakelijk dat de organisatie optimaal is ingericht, dat er een stevige ict-functie is in de organisatie, dat de primaire processen in de organisatie zijn geborgd en dat er een goede technische implementatiestrategie is.
Bespaar hierbij niet op de technische infrastructuur in een implementatie. Zorg dat er een implementatiestrategie is die de verschillende functies binnen de implementatie ondersteunt.
Uiteraard zal een business consultant roepen dat implementatie vooral een organisatieverandering is, hierover heb ik eerder specifiek een opinie geschreven welke begon met: “Magistrale verkooptruc is zoals Jort Kelder de werking van de markt uitlegde door aan Matthijs van Nieuwkerk zijn pen, iets van weinig waarde te vragen. En toen Jort deze had vroeg hij aan Matthijs om zijn naam op te schrijven. En hoe verrassend had Matthijs daar een pen voor nodig die Jort hem wel wilde verhuren, voor een belachelijk hoge prijs uiteraard.”
https://www.computable.nl/artikel/opinie/datacenters/4984339/4907128/help-de-dokter-verzuipt.html
In deze opinie ging ik in op de kip-en-het-ei discussie aangaande de storage problematiek welke met name in de zorgsector voor een constante stroom van budgetwijzigingen zorgt omdat iets simpels als capaciteitsmanagement niet op orde is. Zoals ik in die opinie uitlegde kost diskcapaciteit zelf niet zoveel maar is de opslag heel wat meer dan een rekensommetje van GB’s aangezien alle data ook beveiligd moet worden tegen verlies. Stellen dat een ecd meerdere GB’s aan dataopslag kan vergen is dan ook tekort door de bocht want het gaat hier met name om de bewaartijden, de kosten van opslag nemen hierdoor al snel expontioneel toe als je niet vanaf het begin nadenkt over de archivering. En vergeet hierbij zeker niet de ‘opt-out’ want het recht om vergeten te worden zal er ook vanaf het begin ingebouwd moeten worden.
Kortom, datamanagement gaat wat verder dan de gebruikelijke kortzichtige blik van business consultants die niet verder komen dan een service naar de gebruiker. Nu zullen meeste in de keus van het oplossen van een slagaderlijke bloeding of de digitale equivalent ervan in het lekken van 300.000 patiëntgegevens de zure vruchten voor lief nemen maar het is niet ondenkbaar dat dit vroeg of laat gaat wijzigen. Wie geen zicht heeft op wat er gebeurt bij een implementatie op het netwerk zal mogelijk ook dus nog veel meer moeite hebben om te voldoen aan compliance eisen rond informatiebeveiliging.
Heel vreemd:
“de organisatie waar het ziekenhuis informatiesysteem (zis) wordt geïmplementeerd, zonder dat de productieomgeving zelf wordt belast en er risico’s ontstaan voor de dagelijkse bedrijfsvoering”
Een ziekenhuis run je met een zis welke “produktie-omgeving” bedoel je dan?
5 omgevingen opbouwen lijkt me ook niet de oplossing want dat kost het nodige aan resources en dus ook geld. Daarnaast hebben de medewerkers (verpleging en artsen) echt geen tijd voor dit soort trajekten.