Klinisch Redeneren in het Universitair Lijnonderwijs

Transcriptie

1 Klinisch Redeneren in het Universitair Lijnonderwijs Voortgangsrapportage Penvoerende instelling: LUMC, Universiteit Leiden Participerende instellingen: AMC, Universiteit van Amsterdam UMCN, Katholieke Universiteit Nijmegen UMCU, Universiteit Utrecht

2 Inhoudsopgave Inhoudsopgave...2 Samenvatting Projectdoelstelling Historie Voortgang per fase Fase 1 Aanpassing DPS Fase 2 Opzetten WBT server Fase 3 Inwerken ICT-ers in DPS Fase 4 Helpdesk DPS Fase 5 Inventarisatie onderwerpen Fase 6 Productie casussen Fase 7 Beoordeling casussen Fase 8 Evaluatie onderwijs Knelpunten Standlijnen overzicht Kennis disseminatie Kosten overzicht Fase 1 Aanpassing DPS...15 De juiste werking van de Klinische Probleem Analyse...15 De layout en de logica van de interactie...21 Het onderscheiden van de moeilijkheid / niveaus...25 Bijlage Fase 2 Opzetten WBT server...26 Citrix niet meer van deze tijd?...26 De Citrix-killer...29 Bijlage Fase 6 Productie casussen...32 Casus 01L Fase A...32 Casus 01A Fase A...43 Casus 01N Fase A...47 Bijlage Kennisdisseminatie...58 Klinisch Redeneren in het Universitair Lijnonderwijs...58 Learning Clinical Reasoning with a new interactive Dynamic Patient Simulation program Computer ondersteund oplossen van Klinische Problemen

3 Samenvatting In het tweede kwartaal voor dit project is een complete interface voor het Klinisch Redeneren met de Dynamic Patient Simulator ontworpen, waarin geïmplementeerd een aangepaste standaard-patiënt. Met commandline parameters kan DPS worden opgestart in een modus die geschikt is voor het Klinisch Redeneren en is het mogelijk tevoren de gewenste moeilijkheidsgraad in te stellen. Geheel nieuw is het Activerende Gegevens-scherm, het Interpreteer Gegevens-scherm en het opvraagbare Probleemboom-overzicht. De KRUL-interface zal in de komende maanden verder worden vormgegeven. Het project geeft een positieve stimulering aan de betrokken faculteiten om het Klinisch Redeneren in een digitale omgeving vorm te geven en meningen over de onderwijskundige aanpak voor Klinisch Redeneren uit te wisselen. Op 11 april en op 18 juni 2003 hebben de deelnemende instellingen overleg gevoerd. Zie hiervan de notulen op de project website (). De productie van de casussen is gestart. Het draaiboek voor de eerste casus van iedere instelling is terug te vinden onder Bijlage Projectdoelstelling In het project wordt een nieuwe onderwijswerkvorm ontwikkeld voor het aanleren van systematisch medisch probleemoplossen, in casu het Klinisch Redeneren. De nieuwe werkvorm past binnen het Raamplan 2001 waarin een belangrijk uitgangspunt is het aanleren van vaardigheden voor het benaderen en oplossen van gezondheidsproblemen van patiënten. De huidige groepsgerichte benadering is echter suboptimaal. Door de bestaande Dynamische Patiënt Simulator (DPS) aan te passen en uit te breiden met een kennismodel voor het systematisch analyseren van patiëntproblemen kan de student meer individueel begeleid worden. Daarvoor wordt een database ontwikkeld voor de opslag van voortgangsgegevens van het klinisch redeneren van de student. De concrete verwachte resultaten zijn: een constantere kwaliteit van het onderwijs, vermindering van de druk op het docentenkorps, efficiëntere inzet van docenten, eenvoudiger en effectiever opsporen van lacunes bij studenten, betere controle over participatie aan het onderwijs. 2. Historie Het project is het begin van dit jaar gestart. De kickoff meeting heeft op 16 januari 2003 plaats gevonden. Het is de deelnemende instellingen gelukt op tijd nieuw personeel te werven, waardoor het project op volle kracht van start kon gaan. Op bepaalde fases loopt het project iets voor en op andere fases iets achter. Het project is goed op gang gekomen. De aanschaf van de nieuwe WBT server is wat later gestart dan in het controlling document aangegeven, maar dit zal het verdere beloop van het project niet beïnvloeden. De aanpassingen aan DPS vinden plaats. 3

4 Aangezien dit een ontwikkeltraject betreft is het heel moeilijk om aan te geven of deze fase op schema ligt. Het ligt in de lijn der verwachtingen dat door voortschrijdend inzicht deze fase langer kan gaan duren dan voorzien. Zowel voor de productie van de casussen als voor de andere fases in dit project heeft dit geen consequenties. 3. Voortgang per fase 3.1. Fase 1 Aanpassing DPS De deelnemende instellingen hebben in voorafgaande bijeenkomsten, een opzet gemaakt van aanpassingen die de DPS applicatie geschikt maken voor onderwijs in het Klinisch Redeneren. In het afgelopen kwartaal is er begonnen met de bouw van de eerste casussen. Dit laatste gaf de mogelijkheid vanuit de praktijk een nieuwe impuls te geven aan de Klinisch Redeneren interface, zoals tot nu toe ontwikkeld. Om helder te krijgen wat er aan de programmatuur zou moeten worden gedaan zijn er door Prof. Dr. P. F, de Vries Robbé, drie typen onderscheiden waaraan aanpassingen verricht moeten worden: 1. De layout en de logica van de interactie 2. De juiste werking van de Klinische Probleem Analyse 3. Het onderscheiden van de moeilijkheid / niveaus. Ad 1. De layout en de logica van de interactie Dit deel gaat over meer algemene user-interface zaken. De interface van DPS is door Dr. M.J. Quaak van UMC Utrecht, met Ilya Zitter (Postdoc User- System Interaction TU Eindhoven) beoordeeld. In Bijlage1 zijn de bevindingen toegevoegd. Veel van de gemaakte opmerkingen voor wat betreft de algemene userinterface lijken relevant, maar kunnen ook in een later stadium, desgewenst, nog doorgevoerd worden. Binnen het Project team is besloten dat alle deelnemende faculteiten verwoorden wat ze in de interface aangepast willen hebben en een voorstel doen hoe het er voor dit Project uit moet komen zien. In het eerstvolgende projectteam overleg (26 september 2003), wordt besloten welke aanpassingen doorgevoerd worden. Ad 2. De juiste werking van de Klinische Probleem Analyse Voor wat betreft het deel van de interface, met hierin de stappen die het Klinisch Probleem Analyse ondersteunt, is geprobeerd helder te krijgen hoe de relatie tussen de structuur van de databank en de probleemboom is en daarmee ook de wijze waarop elementen op het scherm komen. Het is helderder geworden waarom bepaalde zaken, zoals het selecteren van de echte activerende gegevens, in de huidige opzet lastig is. Een aantal stappen van het klinisch redeneren, zoals het genereren van hypotheses, is nog in ontwikkeling. 4

5 Voor het maken van casusmateriaal is het essentieel dat de structuren (en de daarmee gepaard gaande instructies voor de ontwikkelaars van casussen) zo snel mogelijk helder en goed vastligt. Hierover zal nader overleg gevoerd worden. Ad 3. Het onderscheiden van de moeilijkheid / niveaus. In dit onderdeel gaat het om twee verschillende aspecten: a. de wijze van klinisch redeneren en b. de gevorderdheid van de student. Mogelijk dat tussen beide aspecten een zekere overlap bestaat. De discussie met Dr. H.G.L.M. Grundmeijer van het AMC, onderdeel van de Meeting van de projectgroep 18 juni jl., geeft aanknopingspunten die wellicht verder worden ontwikkeld met dit project. De resultaten van diverse activiteiten rondom Fase 1 zijn te vinden in de Fase 2 Opzetten WBT server Fase 2 ondervindt wat vertraging. Hierover is aan SURF een officieel verzoek uitgegaan. Rapportage bij Fase 2 is terug te vinden in Bijlage 2. Aanpassing Fase 2 KRUL project Bij het schrijven van het controlling document van het KRUL project werd er vanuit gegaan dat de applicaties die ontwikkeld moeten worden binnen dit project ter beschikking zouden worden gesteld op een WBT server uitgaande van de Citrix metaframe software. Tijdens de duur van het project is Windows 2003 advanced server uitgebracht door Microsoft. Deze server software generatie bevat het RDP5 protocol, waardoor eisen die aan de door ons gebruikte software gesteld worden (true color en geluid), ineens tot de mogelijkheden behoren. De kosten voor het gebruik van deze software zijn echter veel lager dan bij het gebruik van Citrix software, waar voor extra licenties moet worden betaald. Het in gebruik nemen van nieuwe server software vraagt echter wel om onderzoek van de automatiseringsafdeling Fase 3 Inwerken ICT-ers in DPS Deze fase is in de eerste rapportage periode afgerond en reeds gerapporteerd. Ten behoeve van het Klinisch Redeneren zijn door de DPS ontwikkelaars van het LUMC, een aantal veranderingen doorgevoerd in de programmatuur van DPS. Die zijn gedocumenteerd in de DPS handleiding (versie 6 maart 2003) die vanaf het KRUL web kan worden ingezien en gedownload. Bij de ontwikkelingen aan het KRUL-DPS-interface (Fase 1), is gebleken dat zowel voor ICT'ers als voor diegene die de casussen gaan gebruiken 5

6 (studenten), instructie met betrekking tot het Klinische Redeneren in DPS, ontwikkeld en toegevoegd zal moeten worden Fase 4 Helpdesk DPS Software-technische problemen zijn zoveel mogelijk ter sprake gebracht in de Meetings voor dit project. De casus-ontwikkelaars krijgen een als er een aangepaste DPS-versie is. Het versie nummer is terug te vinden in de properties Indien nodig wordt gebeld met de helpdesk. Recent ingewerkte ICT-ers voor DPS overleggen ook telefonisch met elkaar. Na het zomer reces en in een wat verder onwikkel stadium van het KRUL- DPS interface, zal er aandacht worden besteed aan de nieuwe- en de huidige vormgeving in DPS (herhalings-oefeningen) Fase 5 Inventarisatie onderwerpen Deze fase is tijdens de eerste rapportage-periode afgerond en gerapporteerd. In vervolg hierop zullen in januari 2004 de rapporterende instellingen de casus onderwerpen voor dat jaar indienen Fase 6 Productie casussen Voor de eerste casus van elke instelling, is het draaiboek terug te vinden in Bijlage 2 van deze voortgangsrapportage. De productie ligt op schema. Uitgangspunt bij deze casussen is een statische versie voor wat betreft het klinisch redeneren. In Nijmegen onderwijst Prof. Dr. P. F, de Vries Robbé de, door hem ontwikkelde methode Klinische Probleem Analyse, in het curriculumblok Praktisch Klinisch Onderwijs I. Dit onderwijs wordt vanaf september, maandelijks vijf keer, aan kleine groepen gegeven. In afstemming met de onderwijscoördinator zal, zodra de interface voor het Klinisch Redeneren tot een representatief stadium ontwikkeld is, een eerste praktische proefgebruik 6

7 van DPS-KRUL-casussen gedraaid worden naast de huidige papieren manier van lesgeven Fase 7 Beoordeling casussen Valt buiten de rapportage periode. In de eerstvolgende voortgangsrapportage zal de kwaliteitscontrole voor de eerste casussen worden toegevoegd. Hiervoor is een template beschikbaar. Vanuit het UMCU; Universiteit Utrecht, zal Dr. M.J. Quaak deze beoordeling verzorgen Fase 8 Evaluatie onderwijs Valt buiten de rapportage periode. 7

8 4. Knelpunten Om een goede keuze te maken tussen W Citrix en W2003 en te onderzoeken of een keuze voor W2003 binnen het LUMC door de automatiseringsafdeling gedragen kan worden, heeft de projectleider tot 1 oktober 2003 de tijd gevraagd. Het is zinloos om over te gaan tot de aanschaf van hardware voordat deze keuze gemaakt is. De consequentie hiervan is dat de server pas in januari 2004 in gebruik kan worden genomen. Dit betekent dat de lessen die in het najaar 2003 opgeleverd worden, zolang via fileshares, opgezet door de verschillende partners, gedistribueerd moeten worden. Dit is onhandig, maar geeft geen onoverkomelijke problemen. Voor andere fasen in het project geeft uitstel van fase 2 geen problemen. De kosten van fase 2 blijven gelijk over het gehele project. Het lijkt zinvol om eventuele onderzoekskosten betreffende Windows 2003 te verrekenen met de besparingen van het niet aanschaffen van extra Citrix licenties. Ofschoon in de oorspronkelijke planning de KRUL-interface gereed zou zijn per juni 2003, zal deze datum verschoven worden naar ten minste oktober Er is inmiddels consensus bereikt over het ontwerp van de interface, en dat ontwerp zal in september worden gerealiseerd door Drs P. M. Bloemendaal, waarbij in de zomerperiode minimale aanpassingen zullen worden voorgesteld binnen deze consensus. In de tussenliggende periode zal de productie van de DPS-casussen verder gaan, zodat het geplande aantal casussen voor dit jaar gehaald zal worden. De bijbehorende interface voor het Klinisch redeneren zal dan de casus complementeren in de periode na 1 oktober

9 5. Standlijnen overzicht Jan-03 Feb-03 Mar-03 Apr-03 May-03 Jun-03 Jul-03 Aug-03 Sep-03 Oct-03 Nov-03 Dec-03 Fase 1 Aanpassing DPS Fase 2 Server beheer Opzetten WBT server Client en casus ondersteuning Fase 3 Inwerken ICT-ers Fase 4 Helpdesk DPS Fase 5 Inventarisatie onderwerpen 01t/m12 Fase 6 01a 02a 03a 04a 05a 06a 07a 08a 09a 10a Productie casussen 01b 02b 03b 04b 05b 06b 07b 08b 09b Fase 7 Beoordeling casussen 01c 02c 03c 04c 05c 06c 07c Fase 8 Evaluatie onderwijs Jan-04 Feb-04 Mar-04 Apr-04 May-04 Jun-04 Jul-04 Aug-04 Sep-04 Oct-04 Nov-04 Dec-04 Fase 1 Aanpassing DPS Fase 2 Server beheer Opzetten WBT server Client en casus ondersteuning Fase 3 Inwerken ICT-ers Fase 4 Helpdesk DPS Fase 5 Inventarisatie onderwerpen 13t/m25 Fase 6 11a 12a 13a 14a 15a 16a 17a 18a 19a 20a 21a 22a 23a 24a 25a Productie casussen 10b 11b 12b 13b 14b 15b 16b 17b 18b 19b 20b 21b 22b 23b 24b 25b Fase 7 Beoordeling casussen 08c 09c 10c 11c 12c 13c 14c 15c 16c 17c 18c 19c 20c 21c 22c 23c 24c 25c Fase 8 Evaluatie onderwijs Legenda Gepland Gereed Naam fase 9

10 6. Kennis disseminatie Tijdens een bijeenkomst van landelijke bijeenkomst voor Computer Ondersteunend Onderwijs ontwikkelaars van het NVMO (werkgroep COO), in april 2003 te Nijmegen, is het KRUL-DPS project gepresenteerd aan de aanwezigen. De abstract ingezonden voor de Online-Educa Berlin 2003, bij de Section: Innovative Learning Approaches, met als titel "Learning Clinical Reasoning with a new interactive Dynamic Patient Simulation program" is geaccepteerd en zal worden gepresenteerd in een demonstration session. De definitieve abstract, die halverwege september 2003 wordt aangeleverd, wordt gepubliceerd in de conference Book of Abstracts. Aan het NVMO congres, 19 november 2003, is een abstract uitgegaan door Drs P.M.Bloemendaal met als titel Computer ondersteund oplossen van Klinische Problemen In Nijmegen is mogelijkheid tot digitaal onderwijs middels DPS gepresenteerd aan de onderwijscoördinatoren voor klinisch en preklinisch onderwijs, en aan de klinisch docenten die de casussen ontwerpen en implementeren in het onderwijs. Zie voor rapportage Bijlage 4. 10

11 7. Kosten overzicht 4 April-03 Begroting Gerealiseerde kosten In rapportage periode t/m rapportage periode Restant op begroting Materiële kosten Fase 1 en 2 45, , Fase 3 en 4 7, , , , Fase 5, 6 en 7 11, , Fase 8 en Diversen 37, , , , Totaal Materiële kosten 102, , , , , Personele kosten Fase 1 en 2 39, , , , , Fase 3 en 4 32, , , , Fase 5, 6 en 7 640, , , , , Fase 8 en Diversen 14, , , , , Overige personele kosten Projectleiding 47, , , , , Financieel beheer 43, , , , , Accountantscontrole 6, , Subtotaal Personele kosten inc.overhead 823, , , , , Maximale subsidie 453, Restant subsidie tot rapportage periode 336, Opgevraagde subsidie -t/m voorgaande periode 59, in rapportage periode 20, deel LUMC 12, deel AMC 2, deel UMCU deel KUN 4, t/m rapportage periode 79, Restant op te vragen subsidie 256,

12 5 May-03 Begroting Gerealiseerde kosten In rapportage periode t/m rapportage periode Restant op begroting Materiële kosten Fase 1 en 2 45, , Fase 3 en 4 7, , , , Fase 5, 6 en 7 11, , Fase 8 en Diversen 37, , , , Totaal Materiële kosten 102, , , , , Personele kosten Fase 1 en 2 39, , , , , Fase 3 en 4 32, , , , Fase 5, 6 en 7 640, , , , , Fase 8 en Diversen 14, , , , Overige personele kosten Projectleiding 47, , , , , Financieel beheer 43, , , , , Accountantscontrole 6, , Subtotaal Personele kosten inc.overhead 823, , , , , Maximale subsidie 453, Restant subsidie tot rapportage periode 256, Opgevraagde subsidie -t/m voorgaande periode 79, in rapportage periode 18, deel LUMC 11, deel AMC 1, deel UMCU deel KUN 5, t/m rapportage periode 98, Restant op te vragen subsidie 158,

13 6 June-03 Begroting Gerealiseerde kosten In rapportage periode t/m rapportage periode Restant op begroting Materiële kosten Fase 1 en 2 45, , Fase 3 en 4 7, , , , Fase 5, 6 en 7 11, , Fase 8 en Diversen 37, , , , , Totaal Materiële kosten 102, , , , , Personele kosten Fase 1 en 2 39, , , , , Fase 3 en 4 32, , , , , Fase 5, 6 en 7 640, , , , , Fase 8 en Diversen 14, , , , Overige personele kosten Projectleiding 47, , , , , Financieel beheer 43, , , , , Accountantscontrole 6, , Subtotaal Personele kosten inc.overhead 823, , , , , Maximale subsidie 453, Restant subsidie tot rapportage periode 158, Opgevraagde subsidie -t/m voorgaande periode 98, in rapportage periode 20, deel LUMC 11, deel AMC 3, deel UMCU deel KUN 4, t/m rapportage periode 119, Restant op te vragen subsidie 39,

14 De totale kosten over de periode 1 april t/m 30 juni 2003 LUMC 35, ABN/AMRO bankrekeningnummer tnv AZL LUMC divisie 1, te Leiden onder vermelding van SAPnummer AMC 8, Instituut AMC medical research. Rekeningnummer projectcode SS UMCU 1, Crediet- en Effectenbank UMC no onder vermelding van Onderwijsinstituut en kostenplaatsnummer J938 UMCN 14, Fortis Bank KUN-UMCN, rekeninghouder Stg. KU FWB gnk ten gunste van projectnummer KRUL-DPS-project cluster BEG/Poels 14

15 Fase 1 Aanpassing DPS Met deze fase wordt het mogelijk gemaakt dat het onderwijs zoals dat in de Klinische Probleem Analyse werkgroepen wordt gegeven, met casussen in de Dynamische Patient Simulator kan worden onderwezen. De juiste werking van de Klinische Probleem Analyse In de eerste voortgangsrapportage is aangegeven: 1. hoe de database structuur is aangepast ten behoeve van de bouw van invoer programmatuur waardoor een probleemboom in een casus verwerkt kan worden. 2. Ook is er een aanzet gegeven met betrekking tot de aanpassingen in de studenten-interface, waardoor een student gebruik kan maken van de door de docent ingebrachte probleemboom. Huidige KRUL-DPS interface Er zijn door de DPS ontwikkelaars van het LUMC, een aantal veranderingen doorgevoerd in de programmatuur, ten behoeve van het Klinisch Redeneren in DPS: a. KRUL Standaard Patient Er is voor KRUL een aangepaste versie van de standaard patient gemaakt (KRUL Standaard Patient). In deze standaard patiënt zijn alle cito aanvragen verwijderd en bestaan van alle aanvragen alleen nog maar niet-cito versies. Dit is noodzakelijk om de probleemboom hanteerbaar te houden. Anders zou de student via het aanvragen van of de cito of de niet-cito bepaling tot één activerend gegeven kunnen komen. Voorbeeld: Zowel de uitslag Bloed BSE 50 mm als de uitslag Bloed BSE cito 50 mm leiden in principe tot hetzelfde activerende gegeven, namelijk BSE verhoogd. Dit zou je dan in de probleemboom helemaal moeten gaan ondervangen. 15

16 b. Commandline parameters Wanneer DPS zonder commandline parameters wordt gestart, gaat het programma ervan uit dat het zich in student modus bevindt en vraagt om een '*.MDB' bestand als casusnaam. Het is ook mogelijk om DPS met de commandline parameters op te starten: Ten behoeve van het klinisch redeneren zijn de volgende nieuwe commandline parameters aangemaakt -P<0 1> Klinisch Redeneren modus Deze kan de waarde 0 of 1 meekrijgen. Default waarde is 0. Bij de waarde 1 wordt DPS opgestart in een modus die geschikt is voor Klinisch Redeneren. Deze modus genereert een andere interface met buttons die betrekking hebben op het Klinisch Redeneren. Tevens ontbreekt dan in alle labformulieren de mogelijkheid om cito aanvragen te selecteren. - K<Value> Moeilijkheidsgraad waarin DPS opstart Met behulp van deze parameter is het mogelijk de moeilijkheidsgraad van een casus vooraf in te stellen zonder dat er wat aan de casus zelf hoeft te worden hergeprogrammeerd. De moeilijkheidsgraad komt vooral tot uitdrukking tijdens het klinische redeneren. c. Specifieke buttons Klinisch Redeneren interface Aan de interface zijn specifieke knoppen toegevoegd om de student de casus te laten doorlopen op het gebied van Klinisch Redeneren. In de in- en uitvoer interface kunnen commando s worden doorgegeven aan het DPS systeem, door verandering van de niet zichtbare- status balk. Deze statusbalk kan worden beïnvloed met JavaScript of VBScript. 16

17 Buttons KRUL-interface Foto d. Commands De volgende commando s zijn geïmplementeerd ten behoeve van de KRUL- DPS interface: d.1. ACTIVEFINDINGS: toont het activerende gegevens formulier Opent het activerende gegevens formulier. Op dit formulier kunnen studenten de activerende gegevens die ze hebben gevonden in de casus selecteren. Dit formulier wordt gebruikt bij het Klinisch Diagnostisch Redeneren. Activerende Gegevens d.2. INTERPRETFINDINGS: toont het interpreteer gegevens formulier Opent het interpreteer gegevensscherm. In dit formulier kunnen studenten de door hun geselecteerde activerende gegevens koppelen aan/bundelen tot 17

18 problemen of hypotheses. Dit formulier wordt gebruikt bij het Klinisch Diagnostisch Redeneren. Interpreteer Gegevens Op deze manier is het integreren van courseware in een specifieke casus mogelijk, omdat de HTML pagina's gebruik kunnen maken van javascript, vbscript, Java en Active X. Tevens kan er gecommuniceerd worden met de DPS casus door de bovenstaande commando's door te geven naar de status (niet zichtbaar voor de student). Naast de invoerpagina s voor de student maakt DPS een aantal uitvoerbestanden aan tijdens het runnen van de casus die gevuld worden met informatie doordat de student bepaalde handelingen verricht in de casus. 18

19 Ten behoeve van de KRUL-DPS interface is dat de KPA button die de opgebouwde probleemboom tot op dat moment weergeeft. Overzicht Probleemboom die student tot dat moment maakte Versiebeheer Casusontwikkeling Voor het versiebeheer is een.ver bestand ontwikkeld. Die wordt bij de.mbd file geplaatst en daarin wordt gelogd wat er door wie, wanneer met de database gedaan is. Te ontwikkelen KRUL-DPS interface Liefst zou je zien dat de student, tijdens het afnemen van de anamnese en het lichamelijk onderzoek, actief de activerende gegevens kan selecteren. Deze worden vervolgens aan de student aangeboden om ze te clusteren en er een Probleem bij te benoemen. Hier ligt het leeraccent. Vervolgens zal het scherm waarbij per probleem een hypothese gegenereerd wordt, verder worden ontwikkeld. En er wordt ontwikkeld hoe de student aan 19

20 de hand van de lijst benoemde hypotheses, het actieplan opstelt, onderzoek toetst, diagnoses stelt en therapiëen kiest. 20

21 De layout en de logica van de interactie User-System Interaction DPS-interface De interface van Dynamische Patiënt Simulatie (zoals te vinden op is, in opdracht Dr. M.J. Quaak van UMC Utrecht, door studente Ilya Zitter, van de 2 jarige postdoctorale opleiding User-System Interaction TU Eindhoven, beoordeeld. Er is een korte heuristische evaluatie uitgevoerd (door één persoon, doorgaans worden heuristische evaluaties door meerdere personen verricht). NB: er is alleen kort aandacht besteed aan aspecten rond de user-system interaction (mens-systeem interactie) en de usability (gebruikersvriendelijkheid). De inhoudelijke basis van het DPS is volledig buiten beschouwing gelaten. Ter ondersteuning is gebruik gemaakt van de tien heuristieken van Jakob Nielsen (zie onderstaand Web-adres); deze heuristieken zijn gangbaar in het mens-systeem interactie/usability-domein. De heuristieken zijn te vinden aan het einde van dit document, in de tekst wordt verwezen naar nummer(s) van relevante heuristiek(en). Meer informatie over heuristische evaluaties kan worden gevonden op volgende Web-adressen: Resultaten korte evaluatie De Dynamische Patiënt Simulatie is complex op twee manieren: inhoudelijk (klinisch/medisch) en op interactie-niveau. Het oplossen van een casus is nog geen routine voor studenten, dus inhoudelijk is het een lastige taak. Op interactie-niveau is het ook een lastige taak, in het DPS moeten er veel verschillende taken worden uitgevoerd, zoals bijvoorbeeld: acties op patiënt ondernemen, tijd vooruit spoelen (in minuten/uren/dagen/maanden/jaren), aanvragen die niet direct zijn uitgevoerd expliciet doervoeren, tussentijdse aantekeningen maken; terwijl er intussen continu nieuwe patiënt en inhoudelijke informatie bij komt de student moet verwerken (opnemen als nieuwe kennis of meenemen in klinisch denkproces). Er kan worden opgemerkt dat de taken onderlinge afhankelijkheden hebben (zowel inhoudelijk als volgordelijk). Het uitvoeren van deze taken wordt niet optimaal ondersteund door de interface. Volgende punten kunnen ondermeer worden opgemerkt: [4] DPS gebruikt geen gangbare standaarden (zoals Web-standaarden of Office/Microsoft standaarden). De student moet uitzoeken wat de verschillende soorten buttons en iconen betekenen, een student vraagt zichzelf bewust of onbewust dan bijvoorbeeld de volgende zaken af: waarom zijn de buttons gegroepeerd zoals ze zijn gegroepeerd? Horen deze functies bij elkaar? Betekent een rijtje buttons dat ik het in die volgorde moet uitvoeren? Wat is het verschil tussen de buttons links-boven en de langgerekte buttons daaronder? De terug-button op rechterkant van het scherm, werkt die als de undo in Word? Na het invullen (d.m.v. intypen in commando-veld) van een foutieve/onvolledige opdracht verschijnt een lijst, hoe kan ik uit deze lijst selecteren? 21

22 [1] [4] Het is niet altijd duidelijk voor een gebruiker wat er mogelijk is of wat er gebeurt wanneer hij/zij een button selecteert, bijvoorbeeld: buttons van het hoofdmenu en boven rechter-scherm lichten op als gebruiker er met muis overheen gaat, dit is niet het geval bij de iconen en de andere buttons; Ofwel het linker-scherm verandert en dan verandert de titel van dat stuk van het scherm, ofwel er verschijnt nieuwe informatie op het rechterscherm, maar niet altijd wordt de titel op het rechterscherm herhaald. Bij buttons lichamelijk onderzoek komen er nieuwe plaatjes wanneer gebruiker over buttons scrolled, maar als er op button wordt geklikt dan verschijnt tevens nieuwe informatie aan rechterzijde (button vertoont ander gedrag dan andere buttons). [2] [5] Als er wordt geklikt op een button anamnese/onderzoek/metingen/lab, dan verschijnt dit op de status van de patiënt. Er is geen onderscheid tussen eerst iets bekijken/informatatie verzamelen/bladeren door mogelijkheden en dan pas beslissen. Dit sluit niet aan bij belevingswereld student, bijvoorbeeld op het Web kan overal worden gebladerd, zonder dat een beslissing wordt genomen; maar ook in het echt is er een duidelijk onderscheid tussen iets bekijken of daadwerkelijk beslissen. [2] [6] Er verschijnt bijvoorbeeld de tekst: voordat u me oproept voor een consult, moet u meer weten over.. : een student kan zich dan afvragen: hoe kan ik meer te weten komen over? werkt het pas als de info op de status staat? Moet de info op een bepaalde plaats in de status staan? Moet ik nu de tijd vooruit spoelen? [1] [6] De informatie op de status staat allemaal onder elkaar en heeft verschillende soorten opmaak, het is niet goed meer te zien om wat voor soort informatie het gaat, student vraagt zich af: welke onderzoeken heb ik nu al gedaan? [1] De student kan de tijd vooruit spoelen of in de toekomst een afspraak maken, het is niet geheel duidelijk wat het effect is, student vraagt zich bijvoorbeeld af: gaat de casus nu alleen in de toekomst verder? Kan ik alleen nog onderzoeken doen die logischerwijs alleen in de toekomst kunnen worden gedaan? Hoe kan ik terug in de tijd als ik alsnog een onderzoek wil doen dat logischerwijs eerder verricht had moeten worden? [2] De simulatie verschilt op verschillende punten van de werkelijkheid, de interface biedt niet veel aanknopingspunten die herkenbaar kunnen zijn voor studenten (behalve bijvoorbeeld de buttons anamnese/onderzoek/metingen/lab, deze buttons sluiten direct aan bij belevingswereld van een student geneeskunde). [8] Interface heeft veel verschillende soorten buttons, iconen, kleuren, foto s va n verschillende formaten, plaatjes en verschillende soorten schermen (o.a. links menuachtig deel + invul-veld, tijd-gedeelte bovenaan, status/informatie-scherm met informatie die verschillend is opgemaakt en alleen geordend is op volgorde van acties, scherm problemen in casus met selectie/deselectie-buttons, inklap/uitklap-scherm wanneer opdracht niet wordt herkend). Het geheel doet onrustig aan voor een gebruiker, hetgeen gezien de complexiteit van de taak, de uitvoering waarschijnlijk niet ten goede komt. Aanbevelingen Er zijn verschillende opties om de mens-systeem interactie c.q. de usability van het systeem te verbeteren. Welke keuze wordt gemaakt hangt af van tijd en budget dat kan worden geïnvesteerd. Er dient te worden opgemerkt dat deze aanbevelingen zijn gebaseerd op een korte evaluatie, er is geen uitputtende evaluatie verricht. Wannneer er weinig tijd en budget kan worden geïnvesteerd, kan het een goed idee zijn om een grafisch ontwerper naar de interface te laten kijken. Grafische verbeteringen kunnen ervoor zorgen dat de schermen wat rustiger en begrijpelijker worden voor de gebruiker. Grafische verbeteringen kunnen ook helpen om de interface een couranter uiterlijk te geven, de huidige schermen komen voor de studenten van nu (die meer gewend zijn aan het Web, geavanceerde software, games e.d.) waarschijnlijk gedateerd over. Wanneer er meer tijd en budget kan worden geïnvesteerd kan het een idee zijn om de interface helemaal te veranderen. Eerst zal een grondige evaluatie moeten plaatsvinden. Op basis van deze resultaten kan een nieuw, haalbaar 22