Waarom bestaat CTcue? 

Wanneer ik aan bekenden uitleg wat CTcue is (“Een zoekmachine waarmee je snel patiënten in het EPD kan vinden”) dan volgt steevast de vraag waarom zoiets nog nodig is. “Kan het EPD dat zelf niet?” Voordat ik bij CTcue kwam werken had ik waarschijnlijk precies hetzelfde gereageerd. Bij de overstap van een papieren archief naar een digitale database verwacht je dat één van de grootste voordelen is dat je informatie veel sneller boven water kan halen. Een goede zoekfunctie klinkt alsof het inherent aan een digitale database zou moeten zijn, net zoals het ontbreken van bedrading inherent aan een mobieltje is.

Skeuomorfisme

Dat dit niet het geval is kan deels worden uitgelegd met het begrip ‘skeuomorfisme’. Dit begrip komt uit de archeologie en verwijst naar het fenomeen dat een nieuw ontwerp vaak (ornamentele) eigenschappen of verwijzingen bevat van/naar datgene wat het vervangt. Een illustratief voorbeeld van dit fenomeen is de tractor die in 1901 door het bedrijf Phelps werd ontworpen. Hoewel een besturing in de vorm van een stuur, pedalen en een versnellingspook al bekend was in die tijd, ‘mende’ je deze tractor- net als een paard – met leidsels. Achteraf bekeken lijkt dit wellicht een komisch ontwerp, maar vanuit het oogpunt van de ontwerpers is de rationale wel te begrijpen; boeren hoefden praktisch niets nieuws te leren en dat maakte de drempel om van paard naar machine over te stappen erg laag.

De Phelps tractor

Skeuomorfisme kan je dus zien als een design-methode die ervoor zorgt dat ‘het nieuwe’ gemakkelijker geaccepteerd wordt. Door associaties op te roepen met een context die bij gebruikers al bekend is, minimaliseer je het risico dat ‘het nieuwe’ geen kans wordt gegeven.

Toch is het inzetten van skeuomorfisme niet altijd even effectief. Ook hier is de Phelps tractor een goed voorbeeld van. Hoewel het leren omgaan met een stuur, versnellingspook en pedalen in eerste instantie misschien een te hoge drempel vormde voor potentiële gebruikers, had je met deze ‘interface’ wel meer controle over het motorvoertuig dan met leidsels. De leidsels – het skeuomorfe design – waren dus eigenlijk een belemmerende factor voor de innovativiteit van de tractor.

Een computer als bureaublad

Bij de transitie die we in de laatste decennia gemaakt hebben van een analoge naar een grotendeels digitale wereld heeft skeuomorfisme een belangrijke rol gespeeld. Dit valt natuurlijk goed te verklaren doordat de digitale wereld in zijn beginselen zo abstract is dat het niet direct associaties oproept met de wereld die we elke dag zien en manipuleren. Voor de ontwikkelaars van de eerste Personal Computer (PC) was het om deze reden een uitdaging om een ontwerp te bedenken dat voor het grote publiek desalniettemin intuïtief in gebruik zou zijn.

Xerox en Apple waren de eerste bedrijven die bedachten dat veel computerfuncties geassocieerd konden worden met processen die binnen de context van een kantoor of een bureau vallen. Zo ontstond het bureaublad-ontwerp waarbij computerbestanden net als papieren op een bureau neergelegd konden worden of weer weggestopt in een mapje of een prullenbak. Het succes van dit skeuomorfe design is bekend: vandaag de dag maken we er nog steeds deels gebruik van.

Bij deze interface van Magic Cap uit de jaren ’90 was het skeuomorfisme wel erg extreem.

Toch bleek ook het skeuomorfe ontwerp van de PC als bureaublad uiteindelijk te beperkt. Sinds de jaren ’90 zijn er talloze computerfuncties bijgekomen die compleet buiten de context van het bureau vallen en ook geen fysiek equivalent hebben. Dit verklaart waarom je in moderne interfaces juist weer meer abstractie ziet. De PC is inmiddels zo’n ingeburgerd en opzichzelfstaand product geworden dat skeuomorfisme overbodig of zelfs beperkend is.

Het EPD en skeuomorfisme

Met het voorbehoud dat mijn ervaring met EPD’s zich beperkt tot de databases die erachter hangen en niet met de interface zelf, denk ik dat we bij EPD’s eenzelfde ‘skeuomorf proces’ kunnen herkennen als bij de Phelps tractor en de PC. Bij de introductie van het EPD leken skeuomorfe elementen wenselijk – een herkenbare ‘besturing’ was in dit geval letterlijk van levensbelang – maar nu we steeds meer gewend zijn geraakt aan de digitale wereld, worden de beperkingen ervan steeds duidelijker.

Waar het skeuomorfisme van de eerste PC’s er uit bestond dat ze de context van een bureaublad gebruikten, bestaat het skeuomorfisme van de eerste EPD’s er uit dat ze de logica van hun voorganger, het papieren medische dossier, hebben gebruikt. Je navigeert het EPD, net zoals het papieren archief, door eerst een medisch dossier van een bepaalde patiënt op te zoeken, en door vervolgens in dat dossier onder het juiste tabblad te kijken waar de informatie staat die je zoekt.

Hoewel deze ‘papieren logica’ wellicht intuïtief was voor de eerste gebruikers, kopieert dit ook het probleem van papier, namelijk dat informatie aan een bepaalde locatie gebonden is. In plaats van dat informatie ergens in de database zit, en dat deze op vele verschillende manieren uit de database getrokken kan worden, is het nu zo dat informatie in een bepaalde database zit, en dat deze er alleen maar uitgehaald kan worden door de goede plek in de interface te bezoeken. Dit maakt het EPD erg statisch, terwijl het voordeel van een digitale database nou juist moet zijn dat data op allerlei verschillende manieren gepresenteerd en hergebruikt zou moeten kunnen worden. Nu is het bijvoorbeeld praktisch onmogelijk om voor een cardioloog met een hele andere interface te werken dan een onderzoeker of een verpleegkundige. Het EPD is namelijk ingericht met het idee dat iedereen in hetzelfde dossier, en dezelfde archiefkast werkt.

Waarom bestaat CTcue?

Het korte antwoord op de vraag waarom CTcue bestaat is dus dat EPD’s in hun skeuomorfe fase teveel de structuur van een dossiermap hebben aangenomen, waardoor zoiets als een geavanceerde zoek-optie niet een functionaliteit was die je direct met een EPD associeerde. In de eerste gebruiksjaren van het EPD was dit misschien niet zo opvallend, maar nu we steeds meer naar een ‘data-tijdperk’ toe bewegen wordt ook steeds duidelijker dat we misschien op een andere manier naar de functie van het EPD moeten kijken.

Het zal dan ook interessant zijn om te zien of we in de nabije toekomst zullen afstappen van het EPD als een dossiermap, en dat we overstappen naar een architectuur die meer ‘eigen’ is aan de digitale wereld. Een voorproefje hiervan vind je in ieder geval in dit interessante artikel van Ruud Koolen en Daan Dohmen, waarin ze concluderen: “Het EPD van de toekomst is geen EPD”.