het auteursrecht van het afstudeerverslag berust bij de auteur.

Elektronische gegevensregistratie in de zorg

Een ontwerp voor een digitaal operatiedossier

De auteur is verantwoordelijk voor de inhoud van het afstudeerverslag;

het auteursrecht van het afstudeerverslag berust bij de auteur.

:

:

:

:

Auteur J.F. Spanjaard 1306375 Plaats en datum Groningen, 2005

UMCG,

Afd. Oogheelkunde W. Berghuis

drs. S. van ’t Riet

RuG, Faculteit

Bedrijfskunde dr. T.W. de Boer

drs. M.P. van der Steen

Voorwoord

Dit onderzoek is uitgevoerd in het kader van mijn afstudeeropdracht van de opleiding Technische Bedrijfswetenschappen aan de Rijksuniversiteit Groningen (RuG). Het onderzoek heeft plaats gevonden bij de afdeling Oogheelkunde van het Universitair Medisch Centrum Groningen (UMCG). In het onderzoek zijn vele methoden en technieken aan bod gekomen welke mij gedurende mijn opleidingstraject zijn bijgebracht. Het toe kunnen passen van deze kennis in de praktijk is voor mij een leuke en leerzame manier geweest om inzicht te krijgen in de mogelijkheden die de bedrijfskunde biedt en wat werken in de praktijk van het bedrijfsleven precies inhoudt.

Het onderzoek is bedoeld voor een ieder die geïnteresseerd is in informatie- systeemontwikkeling en de toepassing van een ontwerpmethode in de praktijk, maar in het bijzonder voor het Dagelijks Bestuur van de afdeling Oogheelkunde, de personen die mij vanuit Oogheelkunde begeleid hebben gedurende het onderzoek en mijn begeleiders van de RuG.

Tijdens het onderzoek heb ik gemerkt dat je als bedrijfskundige in een ziekenhuis en bijzondere rol bekleedt. Het overgrote deel van de medewerkers bestaat uit medici en verpleegkundigen, collega’s om mee over je vakgebied te praten zijn schaars.

Desondanks heb ik bij Oogheelkunde een leuke tijd gehad en veel geleerd over de wereld binnen de muren van een ziekenhuis.

De volgende personen wil ik bedanken voor hun steun en begeleiding gedurende mijn onderzoek. Stéphanie van ’t Riet, voor het verkrijgen van de opdracht en haar hulp bij het opstarten van het onderzoek. Zij was in eerste instantie mijn begeleidster vanuit Oogheelkunde maar door de geboorte van haar dochter was zij genoodzaakt de begeleiding over te dragen aan Wim Berghuis. Graag bedank ik hem voor zijn begeleiding en voor alle gesprekken die we voerden over velerlei onderwerpen, waarvoor ik altijd graag even langskwam. Mijn begeleiders van de RuG, Thomas de Boer en Martijn van der Steen, wil ik bedanken voor hun tijd en moeite die zij tijdens de begeleiding van mijn onderzoek hebben genomen en voor de interesse in mijn onderwerp. Alle betrokken medewerkers van de afdeling Oogheelkunde en de ontwikkelaars van de ICT afdeling wil ik bedanken voor hun interesse en de tijd die ik van hen vroeg voor alle interviews en overige gesprekken. Hoewel het onderwerp direct verband met hen houdt, is de interesse hiervoor niet vanzelfsprekend. Tot slot wil ik mijn moeder en broer bedanken voor hun steun, vriendschap en belangstelling gedurende mijn onderzoek.

Jeroen Spanjaard

Samenvatting

Binnen de afdeling Oogheelkunde van het UMCG is de wens ontstaan om over te gaan tot digitalisering van het operatiedossier. Dit elf pagina’s tellende oranje operatiedossier bevat de patiënteninformatie van een patiënt die een operatie dient te ondergaan.

Hiermee vormt het operatiedossier een belangrijk document dat gebruikt wordt in het primaire proces van de afdeling, de zorgverlening. In 2004 heeft de afdeling een vooronderzoek laten doen door een student van de RuG en naar aanleiding van de conclusies uit dit onderzoek is besloten het traject tot digitalisering voort te zetten. Dit heeft geleid tot een vervolgonderzoek waarbij het de wens van het Dagelijks Bestuur (DB) is om inzicht te geven in de mogelijkheden voor een digitaal operatiedossier waarbij in het bijzonder gelet wordt op de gebruiker ervan, de medicus of verpleegkundige. De probleemstelling die voor dit vervolgonderzoek gesteld wordt bestaat uit de volgende doelstelling:

“Concreet inzicht bieden in de ICT toepassingsmogelijkheden en werkprocesmatige toepassingsmogelijkheden van een elektronische versie van het huidige operatiedossier door het maken van een ontwerp van een elektronische versie van dit operatiedossier.”

Met concreet wordt in dit geval bedoeld: niet alleen onderzoekend, maar met een toepasbaar resultaat. Met werkprocesmatig wordt bedoeld: de mogelijkheden die er zijn met betrekking tot de reeds aanwezige werkprocessen (zorgketens) binnen Oogheelkunde. De hieruit voortvloeiende vraagstelling is de volgende:

“Hoe ziet een functioneel en logisch ontwerp van een elektronische versie van het Oogheelkundig multidisciplinair operatiedossier er uit?”

Het functionele gedeelte omvat wat het systeem moet doen terwijl het logische gedeelte omvat hoe het systeem dat moet doen.

Om tot een ontwerp voor een digitaal operatiedossier te komen is gekozen voor de Domain Driven IT Systems design ontwerpmethode van T.W. de Boer en J.H. van Uitert.

Deze methode ontwikkelt een ontwerp dat gebaseerd is op de verhalen van gebruikers van het systeem, wat tevens door het DB als eis gesteld wordt. De methode kijkt vanuit drie invalshoeken naar het domein van het informatiesysteem en vormt dit domein om tot een domein model, design model en uiteindelijk tot een ontwerp. De invalshoek statische structuur geeft inzicht in de structuur van het domein en de onderdelen van deze structuur worden in een structuurdiagram weergegeven. De invalshoek communicatie kijkt naar de boodschappen die van en naar de verschillende onderdelen in het domein gaan. De invalshoek processen kijkt naar de werkprocessen. In deze processen wordt in de vorm van use cases structuur gebracht zodat duidelijk wordt welke taken er binnen het domein aanwezig zijn. Naast deze ontwerpmethode is het FURPS+

model gebruikt om inzicht te krijgen in eisen en wensen op technisch en juridisch gebied.

Dit model is gekozen als toevoeging op de hoofdzakelijk functionele eisen en wensen die de Domain Driven IT Systems design levert.

De eerste stap van de gekozen ontwerpmethode is het achterhalen van de verhalen van

de gebruikers, de zogeheten user stories. Hiertoe zijn interviews gehouden met

verschillende medewerkers. De interviews hebben volgens een vooraf ontwikkeld

interviewschema plaatsgevonden en hebben zodoende van iedere geïnterviewde dezelfde

informatie achterhaald. Om te bepalen met welke medewerkers gesproken dient te

worden is voorafgaand aan de interviews een gebruikersanalyse uitgevoerd. Deze

analyse heeft die personen naar voren gebracht die relevant zijn binnen het domein van

het operatiedossier. Op basis van deze interviews is een domein model opgesteld dat

inzicht geeft in de structuur, communicatie en processen van de organisatie.

In de verdere ontwikkeling is de invalshoek communicatie niet meegenomen wegens de geringe meerwaarde die het in dit onderzoek geeft. Het inzicht dat deze invalshoek moet geven in het domein is namelijk voor een groot deel al vastgelegd in de zorgketens. Dit zijn Data Flow Diagrammen die in 2001 ontwikkeld zijn en deze bevatten de communicatiestromen van het primaire proces. Het ontwikkelde domein model is echter geen goede basis voor een ontwerp omdat de invoering van een digitaal operatiedossier vele veranderingen in het domein tot gevolg heeft. Alvorens verder te gaan is daarom eerst een domein model voor het toekomstige domein opgesteld. Hiertoe is geanalyseerd welke medewerkers in dit toekomstige domein relevant zijn voor het digitaal operatiedossier. Met deze medewerkers zijn gesprekken gevoerd die de basis hebben gelegd voor het verdere ontwerp. Uit het nieuwe domein model zijn de onderdelen gekozen die binnen de systeemgrens komen te liggen en op basis daarvan is in de ontwerpfase “design model” van deze onderdelen een klassendiagram opgesteld dat weer de basis voor de datastructuur vormt. Functioneel Ontwerp waarin de functionele systeemeisen (wat het systeem moet doen) zijn opgenomen en waarin wordt beschreven hoe het systeem dient te functioneren.

De ICT infrastructuur zoals deze binnen Oogheelkunde gebruikt wordt kan gebruikt worden voor het digitaal operatiedossier. De beschikbaarheid van computers op alle plaatsen waar het operatiedossier gebruikt wordt is geanalyseerd en toont aan dat er slechts een tweetal probleemlocaties zijn. Deze locaties kunnen met een aantal aanpassingen voorbereid worden op het gebruik van een digitaal operatiedossier waarmee mogelijke problemen voorkomen kunnen worden. Het beheer van het digitaal operatiedossier kan door de afdeling zelf worden gedaan of het kan aan de ICT afdeling over gelaten worden. In het laatste geval dient het systeem ook door de ICT afdeling ontwikkeld te worden. Na afweging van beide alternatieven komt naar voren dat beheer door de ICT afdeling de beste keuze is. Voordelen hiervan zijn de koppeling aan het medisch werkstation Poliplus en mogelijkheden tot koppeling aan andere informatiesystemen. Ook wordt tegemoet gekomen aan de wens van het DB om op de lange termijn het beheer van alle applicaties over te dragen aan de ICT afdeling teneinde de functie van functioneel netwerkbeheerder / technisch medewerker te kunnen schrappen. Nadeel van dit alternatief is echter dat door de grote drukte binnen de ICT afdeling heerst men in 2006 geen tijd zal hebben om tot de ontwikkeling van het digitaal operatiedossier over te gaan. Aangezien de afdeling geen haast heeft met de invoering ervan en het huidige papieren operatiedossier goed voldoet weegt dit probleem niet op tegen de voordelen.

Het huidige papieren operatiedossier kan goed als basis voor een digitale versie dienen.

De lay-out en inhoud van dit operatiedossier zijn daarom opgenomen in het Functioneel Ontwerp. Zo maakt het deel uit van de wensen van de gebruikers om een digitaal operatiedossier te ontwikkelen dat dicht staat bij het huidige papieren operatiedossier.

Een digitaal operatiedossier lost de huidige knelpunten met het papieren operatiedossier voor een groot deel op. Nieuwe mogelijkheden door koppelingen met andere informatiesystemen zijn in de toekomst denkbaar.

De ontwerpmethode die in dit onderzoek gebruikt is biedt voordelen ten opzichte van

klassieke ontwerpmethoden. De vrijheid om te doen wat noodzakelijk is en te laten wat

weinig meerwaarde biedt zorgt ervoor dat onnodige modellering achterwege blijft. De

beperking in de hoeveelheid UML-modellen en diagrammen geven de ontwerper houvast

zodat keuzes over geschikte UML modellering achterwege blijven. Deze beperking

enerzijds en de daarvoor genoemde vrijheid anderzijds geven de ontwerper de

mogelijkheid een ontwerp te ontwikkelen dat goed op de organisatie afgestemd is zonder

daarvoor veel extra werk te moeten verzetten.

Lijst met gebruikte afkortingen

AZG Academisch Ziekenhuis Groningen DB Dagelijks Bestuur

DFD Data Flow Diagram FO Functioneel Ontwerp

ICT Informatie- en Communicatietechnologie K4VA Zone K4 Verpleeg Afdeling

ODBC Operatief Dagbehandelingcentrum

OK Operatiekamer

PH Probleemhebber

PPH Potentiële Probleemhebber RuG Rijksuniversiteit Groningen

UMCG Universitair Medisch Centrum Groningen UML Unified Modelling Language

Wbp Wet Bescherming Persoonsgegevens

ZIS Ziekenhuis Informatiesysteem

Inhoudsopgave

Voorwoord ...3

Samenvatting...6

Lijst met gebruikte afkortingen...8

1 Inleiding...12

1.1 Het UMCG... 12

1.2 Oogheelkunde ... 12

1.2.1 Polikliniek ... 12

1.2.2 Dagbehandeling ... 13

1.2.3 Verpleegafdeling ... 13

1.3 processen ... 13

1.4 Het operatiedossier ... 14

1.4.1 Uiterlijke kenmerken... 14

1.4.2 Inhoudelijke kenmerken... 14

1.4.3 Disciplines:... 14

1.5 introductie probleemveld ... 15

2 Opdracht omschrijving ...16

2.1 Het vooronderzoek... 16

2.2 PH-analyse ... 16

2.3 Conclusies ... 18

2.4 probleemstelling ... 19

2.5 Randvoorwaarden... 19

2.6 Conceptueel model ... 20

2.7 Deelvragen ... 21

3 Systeemontwikkeling ...22

3.1 Ontwerpmethode ... 22

3.1.1 Fase “Domain” ... 23

3.1.2 Fase “Domain model”... 23

3.1.3 Fase “Design model”... 24

3.1.4 Fase “Information system” ... 24

3.2 Unified Modelling Language (UML) ... 24

3.3 Requirements... 24

4 Fase Domain...26

4.1 User stories ... 26

4.2 Gesprekken met de gebruikers ... 30

4.2.1 Oogartsen ... 30

4.2.2 Arts-assistenten ... 30

4.2.3 Opnamecoördinatoren... 31

4.2.4 poliverpleegkundigen ... 31

4.2.5 Verpleegkundigen dagbehandeling (ODBC) ... 31

4.2.6 Verpleegkundigen verpleegafdeling (K4VA)... 31

4.2.7 Anesthesisten ... 31

4.2.8 Zaalartsen ... 32

4.2.9 Recovery verpleegkundigen ... 32

4.3 Conclusies fase “domein”... 32

5 Fase Domein Model...33

5.1 Statische structuur ... 33

5.1.1 Stap 1: Standaardiseer zinnen, selecteer onderwerpen en objecten ... 34

5.1.2 Stap 2: noteer de zelfstandige naamwoorden ... 35

5.1.3 Stap 3 en 4: Elimineer synoniemen, herdefinieer homoniemen... 35

5.1.4 Stap 5: verwijder irrelevante objecten ... 35

5.1.5 Stap 6: identificeer attributen ... 35

5.1.6 Stap 7 en 8: Definieer concepten en klassen en selecteer relevante... 36

5.1.7 Stap 9: definieer relaties ... 36

5.2 Communicatie ... 36

5.3 Processen ... 37

5.4 Synchronisatie ... 38

5.5 Conclusie fase Domein model ... 39

6 Systeem to-be ...40

6.1 Nieuwe bronnen van informatie ... 40

6.1.1 Gebruikersstudie ... 40

6.1.2 Conclusie gebruikersstudie ... 41

6.2 Beheer lokaal of door ICT?... 41

6.2.1 ICT afdeling ... 41

6.2.2 Oogheelkunde... 42

6.2.3 Evalueren van de alternatieven ... 42

6.2.4 Conclusie afweging ... 44

6.3 ICT afdeling ... 44

6.4 Veranderingen... 45

6.4.1 Overschakeling papier naar computer ... 45

6.4.2 Conclusie ... 48

6.5 Veranderingen statische structuur view ... 49

6.6 Veranderingen processenview ... 49

6.7 Communicatie view... 50

6.8 Synchroniseren ... 50

6.9 Keuze van systeemgrens ... 50

6.10 Conclusie systeem to-be... 50

7 Design model en ontwerp ...51

7.1 Design model ... 51

7.1.1 Klassendiagram... 51

7.1.2 Sequentiediagram ... 51

7.1.3 Activiteitendiagram... 51

7.2 Ontwerp ... 51

7.3 Conclusie design en ontwerp ... 52

8 Het FURPS+ model ...53

8.1 Functional... 53

8.1.1 Geautomatiseerde velden. ... 54

8.1.2 Verplichte velden... 54

8.2 Usability ... 54

8.2.1 Menselijke factoren... 54

8.3 Reliability ... 55

8.4 Implementation ... 55

8.5 Legal... 55

8.5.1 Wet Bescherming Persoonsgegevens (Wbp)... 56

8.5.2 Digitale handtekening ... 57

8.6 Conclusies FURPS+ ... 57

9 Conclusies ...58

9.1 Conclusies over het onderzoek ... 58

9.2 Conclusies over de gebruikte ontwerpmethode ... 59

10 Aanbevelingen ...61

10.1 Functioneel Ontwerp ... 61

10.2 Ziekenhuisbrede anamnese... 61

10.3 Anesthesiologie ... 61

10.4 Recovery afdeling ... 62

10.5 Invoering digitaal operatiedossier ... 62

Geraadpleegde literatuur ...63 Bijlagen

Bijlage I: Uitleg use cases

Bijlage II: Ontwikkeling interviewschema Bijlage III: Overzicht invoer/uitvoeracties Bijlage IV: Structuuroverzicht

Bijlage IV-a: Domein van het huidige systeem

Bijlage IV-b: Generalisatie van conceptuele klassen onder “operatiedossier”

Bijlage V: use cases systeem as-is en generalisaties Bijlage V: use cases systeem as-is en generalisaties Bijlage V-a: Use cases

Bijlage V-b: Generalisatie use cases: operatiedossier invullen Bijlage V-c: Generalisatie use cases: operatiedossier bekijken Bijlage V-d: Generalisatie actoren

Bijlage VI: Infrastructuur UMCG Bijlage VI: Infrastructuur UMCG Bijlage VI-a: infrastructuur

Bijlage VI-b: Storage Area Networks (SAN) Bijlage VII: Structuurdiagram systeem to-be Bijlage VIII: use cases systeem to-be

Bijlage IX: Klassendiagram

Bijlage X: Functioneel Ontwerp

1 Inleiding

In dit hoofdstuk wordt een algemene beschrijving gegeven van de organisatie waarbinnen het onderzoek heeft plaatsgevonden alsmede een introductie in het probleemveld.

1.1 Het UMCG

Het Universitair Medisch Centrum Groningen (UMCG) is met zo’n 7.500 medewerkers en 1300 bedden een van de grootste ziekenhuizen in Nederland. Met een gemiddelde bezettingsgraad van ongeveer 70% zijn er dagelijks ongeveer 1000 patiënten opgenomen in deze witte ministad. Jaarlijks zijn 29.000 patiënten opgenomen. Het ziekenhuis biedt naast de “gewone” zorg

ook topreferente

en topklinische zorg

. Hierdoor is het UMCG een grote speler in de Nederlandse, en zeker de Noord- Nederlandse gezondheidszorg. Naast het bieden van zorg heeft het ziekenhuis een belangrijke kernactiviteit in het bieden van onderwijs. Het verzorgt de opleidingen Geneeskunde en Tandheelkunde en in samenwerking met de Hanzehogeschool de opleiding Mondzorgkunde. Daarnaast heeft het UMCG alle opleidingen tot specialist in huis. Naast zorg en onderwijs wordt binnen het UMCG ook veel onderzoek gedaan, bijvoorbeeld naar nieuwe technieken en behandelingen, nieuwe medicijnen en nieuwe vormen van zorg. Om een indicatie te geven: in 2003 waren er 78 promoties binnen het UMCG (http://www.umcg.nl/azg/nl/azg/) .

Voorheen droeg het ziekenhuis de naam Academisch Ziekenhuis Groningen (AZG).

Gezien de nauwe samenwerking tussen het ziekenhuis en de Faculteit der Medische Wetenschappen werd echter besloten tot de vorming van een universitair medisch centrum, waardoor de beide organisaties samen konden gaan tot één organisatie. Per 1 januari 2005 is het UMCG een feit.

1.2 Oogheelkunde

Eén van de 23 medische afdelingen die onder het UMCG gehuisvest zijn is de afdeling Oogheelkunde. Deze afdeling bestaat uit drie onderdelen: de polikliniek, het dagbehandelingcentrum en de verpleegafdeling. In 2004 werd de polikliniek door zo’n 7700 patiënten bezocht (eerste bezoeken). Er werden in dat jaar 816 patiënten opgenomen met een gemiddelde opnameduur van 2,8 dagen (Oogheelkunde, 2004) . Om een indruk te krijgen van de functie van de drie afdelingen zullen ze elk kort besproken worden.

1.2.1 Polikliniek

De polikliniek (poli) van Oogheelkunde is gelegen op de begane grond en is makkelijk toegankelijk voor patiënten. Via verwijzingen door huisartsen of oogartsen komen patiënten bij de poli terecht, alwaar ze op spreekuur komen bij een oogarts. Op de polikliniek zijn naast oogartsen poliverpleegkundigen werkzaam, waarvan sommigen ook belast met de planning van een opname of een ingreep in dagbehandeling. Deze verpleegkundigen assisteren bij kleine ingrepen op de polikliniek zelf en nemen verpleegkundige anamneses af. Ook zijn zij betrokken bij de voorlichting aan de patiënt over een eventuele ingreep.

1

Hiermee wordt bedoeld de zorg die in alle andere 120 ziekenhuizen in Nederland geboden wordt

2

Topreferente zorg is zorg die alleen in universitair medische centra kan worden geboden. Hierbij gaat het om moeilijke, dure of weinig voorkomende vormen van diagnostiek en behandeling.

3

Topklinische zorg is zorg waarvoor zeer geavanceerde apparatuur, zeer bijzondere voorzieningen of zeer

1.2.2 Dagbehandeling

Op het operatieve dagbehandelingcentrum worden, zoals de naam al verraadt, patiënten op één dag behandeld. Deze patiënten worden dus niet opgenomen. Het oogheelkundig team op deze afdeling bestaat uit oogartsen, arts-assistenten, regieverpleegkundigen, seniorverpleegkundigen en verpleegkundigen. Van alle oogheelkundige operaties wordt circa 75 % in dagbehandeling verricht. Dit dagbehandelingcentrum (ODBC) bevindt zich op de derde verdieping. Het daarbij om ongeveer 1750 behandelingen. Voor een ander deel van de operaties wordt gebruik gemaakt van het operatiecentrum gesitueerd op de eerste verdieping.

1.2.3 Verpleegafdeling

De verpleegafdeling (K4VA) heeft de beschikking over 30 bedden. Het is een gecombineerde afdeling voor oogheelkundige patiënten, patiënten van het specialisme kaakchirurgie en patiënten voor het anesthetisch pijncentrum. Deze specialismen nemen respectievelijk 17, 10 en 3 bedden in gebruik. De specialismen liggen gemengd over de afdeling. Voor de oogheelkundige patiënten is kenmerkend dat het vooral opnames voor kortverblijf betreffen, er vinden veel opnames, operaties en ontslagen op de afdeling plaats. Voor de specialismen kaakchirurgie en het anesthetisch pijncentrum is de opname duur variabel van een aantal dagen tot een aantal weken (http://intranet.azg.nl/oogheelkunde/) .

1.3 processen

De patiëntenzorg vormt het belangrijkste bestaansrecht van de afdeling. Hoe kunnen nu de werkprocessen dusdanig ingericht worden dat het zowel de betrokken medewerkers als de patiënt ten goede komt? In 2001 is het project “zorgketens in de Oogheelkunde”

van start gegaan. Het Dagelijks Bestuur wilde de dagbehandeling en kortverblijf opnames voor alle oogheelkundige patiënten bevorderen met verbetering van de kwaliteit (Gouw, 2001) . Hoe zijn deze afdelingen nu met elkaar verbonden en welke taken worden door welke medewerker uitgevoerd? Welke rol speelt de patiënt in dit alles? Dit is vastgelegd in zogenaamde zorgketens. Deze zorgketens bestaan uit uitgebreide flowcharts waarin de weg vastgelegd is die de patiënt bewandelt vanaf het moment dat deze in aanraking met zorg komt (dit kan al extramuraal beginnen, bijvoorbeeld bij een huisarts), tot het laatste moment dat de patiënt hiermee in aanraking komt. Figuur 1.1 geeft een overzicht van de interactie tussen de afdelingen met de patiënt en tussen de afdelingen onderling.

Fig. 1.1: interactie afdelingen en patiënt (Gouw, 2001)

Wanneer de patiënt binnenkomt op de polikliniek wordt in een onderzoek door een oogarts een diagnose gesteld en wordt vastgesteld of de patiënt een operatieve ingreep

patiënt

K4 verpleeg- afdeling

Operatie- centrum

Polikliniek Polikliniek

Anesthesie spreekuur

Operatieve dagbehandeling patiënt

patiënt

zal moeten ondergaan. Wanneer dit het geval is wordt de patiënt doorverwezen naar de opnamecoördinator, alwaar een operatiedossier wordt aangemaakt.

1.4 Het operatiedossier

Alvorens verder te gaan met het introduceren van onderzoeksaspecten is het noodzakelijk kennis te hebben verkregen van het onderwerp van dit onderzoek: het multidisciplinair oogheelkundig operatiedossier, verder te noemen operatiedossier. Dit document vormt de patiënt zijn persoonlijke map met patiëntgegevens en heeft over het algemeen betrekking op één specifieke oogheelkundige operatie. Slechts in een zeer klein aantal gevallen heeft één operatiedossier betrekking op twee operaties, dat wil zeggen op eenzelfde ingreep aan beide ogen.

1.4.1 Uiterlijke kenmerken

Het A4-formaat operatiedossier heeft een oranje kaft en telt 10 pagina’s. Voorheen waren dat er 16, maar door de herziene versie die tijdens het onderzoek langzaam in gebruik genomen wordt (op veel plaatsen wordt op dit moment nog het oude operatiedossier gebruikt), zijn er zes pagina’s uit verwijderd. De voorkant van de kaft is tevens bestemd voor het invullen van informatie dus in totaal bevat het document 11 pagina’s voor gegevensinvoer.

1.4.2 Inhoudelijke kenmerken

Het operatiedossier bevat diverse invulvelden en een aantal vragenlijsten met vragen die veelal te beantwoorden zijn met ja of nee. Aan de bovenkant van een invulveld of vragenlijst staat steeds door welke medewerker het betreffende veld ingevuld dient te worden. Aangezien het document hoofdzakelijk bestemd is voor één operatie, wordt voor elke operatie een nieuw operatiedossier aangemaakt.

1.4.3 Disciplines:

Het operatiedossier wordt “multidisciplinair” genoemd omdat het langs verschillende disciplines gaat. Medewerkers uit de volgende disciplines maken gebruik van het operatiedossier door gegevens in te voeren of gegevens uit te lezen:

- Oogartsen;

- Opnamecoördinatoren;

- Anesthesisten;

- Poliverpleegkundigen;

- Verpleegkundigen verpleegafdeling;

- Verpleegkundigen dagbehandeling;

- Recovery-verpleegkundigen;

- Arts-assistenten;

- Zaalartsen.

Zoals in paragraaf 1.4.1 al genoemd werd is er een nieuwe versie van het operatiedossier

ontwikkeld waarbij het gedeelte dat bestemd is voor de anesthesist er uit is gehaald. Dit

gedeelte omvat zes pagina’s en met het verdwijnen hiervan is de omvang van het

operatiedossier dus aanzienlijk gereduceerd worden. Hoewel het verdwenen gedeelte

onder gebracht is bij de afdeling Anesthesiologie zelf, is de procedure voor de aanvraag

van een screening bij anesthesiologie nog wel aanwezig in het operatiedossier. Hierdoor

heeft de anesthesist nog wel te maken met het operatiedossier.

1.5 introductie probleemveld

Het operatiedossier is al enige tijd in gebruik bij Oogheelkunde. Dit dossier was het resultaat van het in 2001 uitgevoerde project “zorgketens in de Oogheelkunde” en heeft, samen met andere resultaten van dit project, geleid tot meer efficiëntie, doelmatiger en patiëntvriendelijker patiëntenlogistiek (Gouw, 2001) . Een aantal knelpunten bij het gebruik van het operatiedossier hebben het Dagelijks Bestuur (DB) van de afdeling Oogheelkunde echter aan het denken gezet over mogelijke veranderingen. Deze veranderingen zouden zoveel mogelijk een oplossing moeten kunnen bieden voor de volgende problemen:

- Anesthesiologie en Oogheelkunde willen beiden de papieren versie van het operatiedossier in bezit hebben;

- Operatiedossiers kunnen niet snel ingezien worden vanwege de opslaglocatie;

- Operatiedossiers raken zoek;

- De omvang van de operatiedossiers bij patiënten die vaak geopereerd zijn;

- Operatiedossiers worden niet volledig ingevuld;

- Sommige operatiegegevens wijzigen niet maar moeten wel opnieuw ingevuld worden in een nieuw operatiedossier;

- Sommige handschriften zijn onleesbaar;

- Een operatiedossier kan niet tegelijkertijd door meerdere personen ingezien worden.

Veel van deze knelpunten zouden mogelijk opgelost kunnen worden door het invoeren

van een elektronische versie van dit operatiedossier. Samen met vermeende voordelen

van het digitaal beschikbaar hebben van dergelijke patiënteninformatie vormde deze

punten aanleiding voor het DB om de haalbaarheid en zinvolheid van het invoeren van

een digitaal operatiedossier te laten onderzoeken. De resultaten van dit onderzoek

hebben het DB doen besluiten het project voort te zetten in de vorm van een

vervolgonderzoek dat zich concentreert op een ontwerp van een elektronisch

operatiedossier.

2 Opdracht omschrijving

In dit hoofdstuk worden de resultaten van het vooronderzoek kort besproken. Hoewel in dit vooronderzoek het probleemveld verkend is wordt deze verkenning met een probleemhebbers analyse (PH analyse) uitgebreid om te achterhalen welke personen zich binnen dit veld bevinden. Dit resulteert in de probleemstelling en de daarbij behorende randvoorwaarden, conceptueel model en deelvragen.

2.1 Het vooronderzoek

Het vooronderzoek had als doelstelling: inzicht krijgen in de problematiek van digitaliseringprojecten binnen organisaties en het inventariseren van de mogelijkheden en gevolgen van digitalisering van het multidisciplinaire operatiedossier van de afdeling Oogheelkunde, teneinde advies te geven aan het management van de afdeling Oogheelkunde over het vervolg van het digitaliseringproject (Berg, 2004) . Onderzocht is of het zinvol is om over te gaan tot digitalisering van het multidisciplinair operatiedossier.

Hierbij is gekeken naar de invloed van ICT vanuit een drietal perspectieven, te weten:

organisatie, werknemers en omgeving. Met name is onderzocht of binnen elk van deze aspecten belemmeringen aanwezig zijn met betrekking tot de invoering van een elektronisch operatiedossier. De conclusies en aanbevelingen uit dit onderzoek worden (deels) als input gebruikt voor dit onderzoek. Om niet in onnodige herhaling te vervallen volgt hieronder alleen een samenvatting van de eindconclusies van dit onderzoek

. Het onderzoek concludeert dat:

- het “zinvol lijkt om over te gaan tot digitalisering van het operatiedossier”;

- het project “zeer goed lijkt aan te sluiten op de strategie van het UMCG en de afdeling Oogheelkunde”;

- het project een “goede reactie is op de veranderingen in de omgeving”;

- de acceptatie van het project onder de werknemers “er al lijkt te zijn, of met een goed implementatieproces te verhogen is” ;

- het huidige papieren operatiedossier goed als basis kan dienen voor een functioneel ontwerp;

- de knelpunten van het papieren operatiedossier opgelost kunnen worden door de invoering van een elektronisch operatiedossier.

Tijdens het vooronderzoek heeft een enquête plaats gevonden waarin de medewerkers van de afdeling Oogheelkunde ondervraagd zijn over tal van onderwerpen met betrekking tot de invoering van een digitaal operatiedossier. De resultaten van deze enquête vormden deels de onderbouwing van hierboven genoemde conclusies. Uit deze enquête zijn tevens een aantal suggesties / ideeën van medewerkers gekomen die ook mee zullen worden genomen in dit onderzoek. Gaandeweg in het onderzoek zullen deze ter sprake komen.

2.2 PH-analyse

Het vooronderzoek heeft het probleemveld geobserveerd vanuit een drietal perspectieven, namelijk de invloed van ICT op de organisatie (en vice versa), de invloed van ICT op de werknemers (en vice versa) en de invloed door ICT uit de omgeving. De aanbeveling werd gedaan om door middel van een vervolgonderzoek een ontwerp voor een elektronisch operatiedossier te ontwikkelen. Dit ontwerp heeft uiteraard met hetzelfde probleemveld te maken als het vooronderzoek. Gesteld kan echter niet worden

4

Voor de exacte conclusies per aspect wordt verwezen naar het afstudeeronderzoek van A. Van den Berg, zie

dat het probleemveld ook exact hetzelfde er uitziet. Om te onderzoeken welke personen zich binnen dit probleemveld bevinden is een Probleemhebbers analyse (PH-analyse) uitgevoerd. Door te spreken met de betrokkenen die uit de ze analyse naar voren komen kan nieuw inzicht in het probleem verkregen worden. Met probleem wordt in dit geval bedoeld: “een ongewenst verschil tussen het bestaande en het gewenste systeem”

(Leeuw, 1996) .

De PH-analyse levert de volgende probleemhebbers op:

Het DB : Het DB is opdrachtgever en probleemhebber doordat het verantwoordelijk is voor het functioneren van de afdeling.

Stafmedewerker : Zij is bekend met het probleem en begeleider van zowel het vooronderzoek als gedeeltelijk dit vervolgonderzoek en daarmee probleemhebber.

Alle gebruikers van het

operatiedossier : Zij zijn probleemhebber uit hoofde van hun functie.

Met gebruikers wordt bedoeld die medewerkers welke uit hoofde van hun functie gegevens in het operatiedossier invoeren danwel uitlezen. Momenteel krijgt de patiënt in sommige gevallen het operatiedossier tijdelijk in handen wanneer hij van de ene naar een andere afdeling gaat. Hoewel de patiënt dus wel een zekere relatie tot het operatiedossier heeft, wordt deze toch niet als gebruiker aangemerkt omdat deze niet voldoet aan bovenstaande uitleg van “gebruikers”. Momenteel is het zo dat wanneer de patiënt naar de anesthesist moet voor een pre-operatief onderzoek, deze zelf een vragenlijst uit het operatiedossier moet invullen. Omdat het gedeelte voor anesthesie uit het operatiedossier zal verdwijnen valt dit aspect buiten het onderzoek en zal de patiënt dus niet aangemerkt worden als probleemhebber.

Naast deze probleemhebbers kunnen ook potentiële probleemhebbers (PPH’s) belangrijk zijn voor het probleemveld. Dit zijn personen die nu geen probleem hebben maar dat wellicht wel krijgen wanneer het probleem opgelost gaat worden. De volgende actoren zijn aanwijsbaar als PPH:

Medewerkers van de Zij zijn PPH doordat, wanneer het probleem opgelost ICT afdeling gaat worden, zij hiermee te maken zullen krijgen.

De afdeling Anesthesiologie Deze afdeling bevindt zich niet meer binnen het probleemveld door de vernieuwde versie van het papieren operatiedossier. Echter door de ontwikkeling van een elektronisch operatiedossier krijgt de afdeling hier wel mee te maken.

Nu worden per probleemhebber of potentieel probleemhebber behandeld wat hun visie is met betrekking tot het probleem.

Het DB:

Het DB heeft de wens een applicatie te ontwikkelen die het huidige papieren operatiedossier kan vervangen. Het DB hoopt hiermee een aantal knelpunten van dit huidige operatiedossier uit de weg te kunnen ruimen en tegelijkertijd de kwaliteit van patiëntenzorg te verbeteren. Ook vloeit deze wens voort vanuit het toekomstperspectief, waarin ICT een steeds belangrijkere rol zal gaan spelen.

Stafmedewerker:

Zij is begeleider en expert van het onderzoek en heeft daarom de wens dat het

onderzoek naar behoren afgerond wordt. Zij heeft middels het vooronderzoek inzicht

gekregen in de zinvolheid van het ontwikkelen van bovengenoemde applicatie maar geen

inzicht over hoe een dergelijke applicatie er uit zou moeten komen te zien. Zij geeft aan dat ze bij het ontwerp zowel technische als organisatorische aspecten van belang acht en dat de applicatie naast de eigen afdeling ook met andere afdelingen te maken zal krijgen.

Alle gebruikers van het operatiedossier:

De gebruikers ervaren verschillende problemen met het huidige operatiedossier. Het gebeurt bijvoorbeeld regelmatig dat operatiedossiers kwijtraken. Ook de beschikbaarheid van het operatiedossier is soms een probleem, bijvoorbeeld doordat het niet op twee plaatsen tegelijk kan zijn. Verder geeft men aan dat er vaak informatie dubbel ingevoerd moet worden, zeker wanneer een patiënt meerdere operaties heeft ondergaan en dus voor elke operatie weer een nieuw operatiedossier moet worden aangemaakt. Naast deze en andere knelpunten is men wel tevreden over het operatiedossier, het document vervult een nuttige functie en voorziet in de informatiebehoefte. Als laatste wordt aangegeven dat nu het anesthesielogisch gedeelte bij de afdeling anesthesiologie ondergebracht gaat worden, een deel van de controle over de operatieplanning uit handen van Oogheelkunde verdwijnt. Het gaat hierbij om het gedeelte van het plannen van een afspraak voor het pre-operatief onderzoek bij een anesthesist. Hierdoor kunnen informatiestromen langs elkaar heen vloeien met inefficiënties als gevolg.

Medewerkers van de ICT afdeling:

Deze medewerkers hebben nu geen probleem. Wanneer echter het probleem van de probleemhebbers opgelost gaat worden zullen de medewerkers van deze afdeling wel een probleem krijgen doordat de te ontwikkelen applicatie met hun afdeling te maken krijgt.

De afdeling geeft aan dat wanneer de applicatie onder hun beheer zou vallen, de applicatie aan diverse standaarden zal moeten voldoen. Met andere woorden, mochten zij probleemhebber worden, dan zal dus ook rekening met hun wensen en eisen gehouden moeten worden.

De afdeling anesthesiologie:

Deze afdeling is momenteel bezig het anesthesielogisch gedeelte dat zich in het oogheelkundig operatiedossier bevindt, onder te brengen bij hun eigen afdeling. Men geeft aan al in een vergevorderd stadium te zijn van de ontwikkeling van een elektronische variant hiervan. Zij kunnen probleemhebber worden wanneer een digitale versie van het oogheelkundig operatiedossier ontwikkeld wordt omdat de overdracht van patiënteninformatie tussen deze afdeling en de afdeling Oogheelkunde verandert.

2.3 Conclusies

Het grootste onderzoek naar het probleemveld is reeds door het vooronderzoek gedaan.

Uit de visies van de verschillende PH’s en PPH’s kunnen een aantal aspecten met

betrekking tot het probleemveld ontdekt worden. Het probleemveld bestaat uit het

huidige papieren operatiedossier en het functioneren daarvan. ICT speelt ook een

belangrijke rol, zowel binnen de afdeling Oogheelkunde als daarbuiten. De afdeling

anesthesiologie bekleedt een bijzondere positie ten opzichte van het probleemveld,

doordat zij zich er nu eigenlijk nog wel in bevinden, maar wanneer het anesthesielogisch

gedeelte uit het operatiedossier verdwenen is niet meer. Echter de overdracht van

patiënteninformatie blijft wel relevant en kan dus binnen het probleemveld vallen

wanneer hier veranderingen in aangebracht worden. De afdeling ICT vormt onderdeel

van het probleemveld (los van het feit of de afdeling nu wel of niet probleemhebber is)

doordat zij de ziekenhuisbrede applicaties en programma’s beheren. Een te ontwerpen

applicatie voor de afdeling Oogheelkunde zal dus vrijwel zeker met de ICT afdeling te

maken krijgen.

2.4 probleemstelling

Uit zowel het vooronderzoek als de PH-analyse kan geconcludeerd worden dat het probleemveld uit twee delen bestaan: een ICT component en een organisatorische component. Onder de ICT component vallen onder andere de reeds in gebruik zijnde ICT hulpmiddelen binnen het UMCG en de ICT infrastructuur en onder het organisatorische component vallen onder andere de werkprocessen en taakinhouden.

Nu inzicht verkregen is in het probleemveld door het vooronderzoek te analyseren en de visies van betrokkenen van het probleemveld te analyseren kan de doelstelling als volgt geformuleerd worden:

“Concreet inzicht bieden in de ICT toepassingsmogelijkheden en werkprocesmatige toepassingsmogelijkheden van een elektronische versie van het huidige operatiedossier door het maken van een ontwerp van een elektronische versie van dit operatiedossier.”

Met concreet wordt in dit geval bedoeld: niet alleen onderzoekend, maar met een toepasbaar resultaat. Met werkprocesmatig wordt bedoeld: de mogelijkheden die er zijn met betrekking tot de reeds aanwezige werkprocessen (zorgketens) binnen Oogheelkunde. Meer specifiek: het zou bijvoorbeeld kunnen dat een elektronische versie van het operatiedossier een aanpassing vergt in deze processen. Het is dan de vraag of dat tot de mogelijkheden behoort. Hiermee worden indirect ook aspecten als taakinhoud en verantwoordelijkheid bedoeld.

De hieruit voortvloeiende vraagstelling is de volgende:

“Hoe ziet een functioneel en logisch ontwerp van een elektronische versie van het Oogheelkundig multidisciplinair operatiedossier er uit?”

Het functionele gedeelte omvat wat het systeem moet doen en hoe dat binnen de afdeling Oogheelkunde kan worden gerealiseerd. Hieronder vallen bijvoorbeeld de organisatorische aspecten zoals de bedrijfsprocessen en de verschillende mogelijkheden die er zijn voor het gebruik van een digitaal operatiedossier. Het logisch gedeelte omvat hoe het systeem dat moet doen. Hierbij valt te denken aan hoe de werking van het digitaal operatiedossier is en hoe het systeem beheerd moet worden.

Het ontwerp kan als handvat gezien worden dat gebruikt kan worden bij de uiteindelijke implementatie van een dergelijk informatiesysteem.

2.5 Randvoorwaarden

Voor het onderzoek zijn een aantal randvoorwaarden opgesteld, waarvan sommigen door het UMCG en sommigen door de afstudeerder. De randvoorwaarden zijn te verdelen in voorwaarden die betrekking hebben op het ontwerp en voorwaarden die betrekking hebben op het onderzoekstraject.

Voorwaarden betrekking hebbend op ontwerp:

- Het ontwerp dient rekening te houden met:

- de technische infrastructuur van het UMCG;

- relevante juridische aspecten (bijv. Wet Bescherming Persoonsgegevens);

- actuele ICT technieken;

- eisen en wensen van gebruiker;

- werkzaamheden die niet in het huidige operatiedossier zijn opgenomen maar wel

worden opgenomen in de medische status;

- onderzoeksresultaten uit vooronderzoek.

- Er dient aandacht besteed te worden aan eventuele mogelijkheden voor koppelingen met het huidige medisch werkstation Poliplus.

Voorwaarden betrekking hebbend op onderzoekstraject:

- Het onderzoek dient rekening te houden met eisen vanuit zowel het UMCG als de Faculteit Bedrijfskunde;

- Het onderzoek wordt zelfstandig verricht.

2.6 Conceptueel model

Om te visualiseren hoe het probleemveld er uitziet is een conceptueel model opgesteld.

Figuur 2.1 geeft dit conceptueel model weer.

Fig. 2.1: conceptueel model voor onderzoek

De afdeling Oogheelkunde (grijs gemaakt in figuur 2.1) bestaat uit de volgende onderdelen (zie figuur 2.2):

Fig. 2.2: onderdelen afdeling Oogheelkunde Oogheelkunde

Faculteit Bedrijfskunde

UMC OMGEVING

ICT afdeling Oogheelkunde

Anesthesiologie

Technische aspecten Juridische aspecten

Dagelijks Bestuur Operatiedossier

Ontwerp digitaal operatiedossier

Medisch personeel

Patiënten

De gestippelde lijn in figuur 2.1 geeft de systeemgrens weer. Hierdoor is te zien dat het onderzoek te maken heeft met de afdeling Oogheelkunde, de ICT afdeling, de Faculteit Bedrijfskunde en een aantal omgevingsinvloeden. De afdeling Anesthesiologie valt buiten het onderzoek, echter de relaties tussen deze afdeling en de afdeling Oogheelkunde vallen wèl binnen het onderzoek. Dit omdat het anesthesielogisch gedeelte zich momenteel nog in het operatiedossier bevindt. De afdeling is op dit moment zelf bezig met het digitaliseren van dit gedeelte, en hierdoor zal dit onderzoek wel met de koppeling van deze systemen te maken krijgen.

Kijkend naar het conceptueel model en de reeds beschreven opdracht kunnen de volgende afbakeningsbeslissingen genomen worden:

- Het onderzoek blijft beperkt tot het te ontwerpen functioneel model;

- Het ontwikkelen/programmeren van een daadwerkelijk werkend elektronisch operatiedossier valt buiten het bestek van dit onderzoek;

- De interne zaken van de afdeling anesthesiologie en de ontwikkelingen binnen die afdeling vallen buiten het onderzoek;

- Het onderzoek houdt rekening met de ICT infrastructuur van het UMCG maar het daadwerkelijk hierin passen is geen voorwaarde voor het slagen van het onderzoek;

2.7 Deelvragen

Bij de hierboven genoemde vraagstelling is onder te verdelen in een aantal deelvragen:

1) Is de informatie uit het vooronderzoek nog steeds correct?

2) Hoe ziet het de manier van werken met het operatiedossier er nu uit?

3) Welke gegevens (data) worden in het operatiedossier ingevoerd of uitgelezen?

4) Wat zijn de eisen en wensen van de gebruikers?

5) Wat zijn de organisatorische eisen en wensen?

6) Welke processen zijn momenteel te onderscheiden en hoe dienen deze gedigitaliseerd te worden?

7) Op welke manier heeft toekomstige systeem invloed op de werkprocessen van het personeel?

8) Wat zijn de mogelijkheden met betrekking tot de huidige werkprocessen?

9) Wat zijn de beperkingen met betrekking tot de huidige werkprocessen?

10) Wat zijn de ICT mogelijkheden en beperkingen?

11) Wat zijn de juridische beperkingen?

12) Hoe moet het systeem eruit komen te zien

3 Systeemontwikkeling

De weg naar de ontwikkeling van een informatiesysteem vraagt om een ontwerpmethode. In dit hoofdstuk wordt de keuze van de methode besproken en wordt deze toegelicht. Tevens wordt de modelleringstaal toegelicht die in dit onderzoek gehanteerd wordt en wordt het model toegelicht dat gebruikt is voor het achterhalen van eisen en wensen.

3.1 Ontwerpmethode

De literatuur beschrijft vele soorten ontwerpmethoden waarvan een aantal getypeerd kunnen worden als “watervalmethode”. Dergelijke methoden beschrijven een aantal vastomlijnde fasen die telkens na elkaar doorlopen worden. Het resultaat van een fase vormt dan de basis voor de opvolgende fase. Naast de watervalmethoden zijn er methoden met een iteratieve of incrementele strategie waarbij de volgorde van deze fasering niet zo strikt tot uiting komt (Lemmen, 1996) . Gezien de wens van de afdeling om in samenwerking met de gebruikers een ontwerp te maken voor een digitaal operatiedossier is in dit onderzoek besloten niet voor een watervalmethode te kiezen.

Door te keizen voor een minder strikte ontwerpmethode kan het ontwerp aangepast worden aan de bevindingen die tijdens dit onderzoek naar voren komen. Op deze manier staat niet aan het begin al vast wanneer en hoe welk onderdeel ontworpen gaat worden.

Een relatief bekende methode die aan deze eisen voldoet is de Dynamic Systems Development Methode (DSDM). Echter bij DSDM is het doel om sneller systemen te leveren dan bij een watervalmethode haalbaar is (Stapleton, 2002) . Bij dit onderzoek gaat het niet primair om het snel leveren van een systeem maar om het inzicht geven in hoe een functioneel ontwerp er uit ziet (zie de vraagstelling in paragraaf 2.4 op pagina 17).

Gezien de aard van het te ontwikkelen informatiesysteem en zijn relatief eenvoudige structuur gaat de voorkeur uit naar een flexibeler methode die toegespitst is op de ontwikkeling van minder complexe informatiesystemen. Op basis van deze eigenschappen komt de Domain Driven IT Systems design methode van T.W. de Boer en J.H. van Uitert (Boer, 2004) in beeld. Deze methode is speciaal ontwikkeld voor het ontwerpen van niet al te complexe informatiesystemen in samenspraak met de gebruiker. Samen met de auteur ontstond het idee om deze nieuwe methode in de praktijk toe te passen. Dit laatste vormt in combinatie met de vrijheid die de methode biedt meteen ook de grootste reden voor de keuze. Door de eigenschappen van deze methode wordt aan de wens van het DB om een applicatie te ontwikkelen in samenwerking met de medewerkers voldaan.

Op de volgende pagina wordt de methode toegelicht.

De methode kijkt vanuit een drietal perspectieven naar de organisatie. Figuur 3.1 toont een overzicht van de drie invalshoeken en de stappen die leiden tot het ontwerp van het informatiesysteem.

Fig. 3.1: Domain driven IT System Design

Volgens deze methode wordt een ontwerp van een informatiesysteem ontwikkeld op basis van de user stories. Op deze manier staat het ontwerp heel dicht bij de gebruikers en bij de werkprocessen. De methode is geen waterval methode, oftewel het is niet een methode die in een strikte volgorde (bijvoorbeeld van links naar rechts) doorgewerkt dient te worden. Sommige onderdelen kunnen simultaan ontwikkeld worden. De volgorde van het werken aan de drie verschillende views en het werken aan het domain model, design model en information system kan naar de situatie aangepast worden en is hierdoor erg flexibel. De methode is onder te verdelen in een aantal fasen die hieronder een voor een beschreven zullen worden

.

3.1.1 Fase “Domain”

In deze fase worden de zogenaamde user stories verkregen, voornamelijk door interviews met gebruikers maar bijvoorbeeld ook door het verwerken van aanwezige documenten die relevant zijn voor één van de drie views. Aangezien deze user stories de basis van het te ontwerpen informatiesysteem zijn, wordt deze fase zeer zorgvuldig doorlopen. De juiste personen moeten op de juiste manier geïnterviewd worden om de juist informatie te verkrijgen.

3.1.2 Fase “Domain model”

De user stories worden vanuit een drietal perspectieven bekeken, te weten: Statische structuur, Communicatie en Processen. De statische structuur view geeft een afbeelding van hoe de organisatiestructuur in elkaar zit. Vragen als “Welke objecten zijn relevant in de organisatie?” en “welke relaties zijn er tussen die objecten en entiteiten?” vormen de user stories om naar een bruikbare structuur. De communicatie view bekijkt de user stories vanuit communicatief oogpunt. Door te achterhalen welke “boodschappen” van en naar welke entiteiten gaan kunnen Data Flow Diagrams ontwikkeld worden. De processen view tenslotte bekijkt de user stories vanuit procesmatig oogpunt. Met proces wordt hier

5

“Fasen” heeft een chronologische klank maar in dit geval wordt bedoeld onderdelen, die in principe wel telkens na elkaar, maar desgewenst ook simultaan kunnen worden uitgevoerd.

Fig. 3.1: Domain Driven IT Systems design

bedoeld: “een reeks activiteiten die een bepaalde input naar een bepaalde output transformeren”. Zo’n proces resulteert in een use case. In bijlage I wordt een uitleg gegeven van het begrip “use case”. Behalve user stories kan voor deze fase ook andere informatie als input gebruikt worden. In dit geval kan men daarbij denken aan de reeds uitgebreid gedocumenteerde werkprocessen in de vorm van flowdiagrammen (zorgketens) en het papieren operatiedossier.

Deze drie views ontwikkelen de user stories dus elk op hun eigen manier. Deze ontwikkeling kan zowel om beurt als parallel geschieden. Tussen de views dient synchronisatie plaats te vinden. Dit synchronisatiemechanisme is een manier van controle om te zien of aspecten die in één view aanwezig zijn ook echt bestaan. Een dergelijk aspect dient dan namelijk ook in een van de andere views naar voren te komen.

Bijvoorbeeld: Wanneer in de processen view een bepaald proces naar voren komt waarbij artsen en verpleegkundigen betrokken zijn, dienen die personen ook in de statische structuur aanwezig te zijn.

3.1.3 Fase “Design model”

De volgende stap vormt de statische structuur, de dataflow diagrams en de use cases respectievelijk om in klassendiagrammen, sequentiediagrammen en activiteitendiagrammen. Door deze stap ontstaat een design model en dat staat dichter bij het uiteindelijke informatiesysteem. Deze fase van de methode wordt herhaaldelijk teruggekoppeld met de vorige fase, zodat betere afstemming van het systeem op de gebruikers en werkprocessen ontstaat. Deze fase en de vorige fase kunnen hierdoor behoorlijke overlap hebben en min of meer tegelijk ontwikkeld worden.

3.1.4 Fase “Information system”

Wanneer deze afstemming naar wens van de betrokken partijen is, kan de laatste fase ingegaan worden en wordt het uiteindelijke ontwerp van het informatiesysteem ontwikkeld. In deze fase kan een prototype van het informatiesysteem ontwikkeld worden waarmee bekeken kan worden of het systeem ook daadwerkelijk aansluit bij de eisen en wensen van de gebruikers.

3.2 Unified Modelling Language (UML)

Voor het ontwerp wordt gebruik gemaakt van de Unified Modelling Language (UML). Deze ontwerptaal is compatibel met het Object Georiënteerd programmeren. Hoewel nog niet duidelijk is hoe het digitaal operatiedossier geïmplementeerd gaat worden en met behulp van welke tools en programmeertalen dat zal gebeuren, is ervoor gekozen een ontwerptaal te gebruiken die algemeen bekend is en veelvuldig gebruikt wordt door IT- specialisten. De taal bevat modellen en diagrammen die ervoor zorgen dat de ontwerper zijn informatiesysteem kan ontwikkelen tot de laatste stap, het implementeren, aan toe.

De taal vult het gat tussen de organisatorische aspecten van het systeem en het ontwerp van dit systeem en diens modellen en diagrammen zijn begrijpbaar voor zowel de gebruikers van het te implementeren systeem als de IT-specialisten die de implementatie verzorgen.

3.3 Requirements

De hierboven genoemde ontwerpmethode een informatiesysteem begint bij het opstellen

van de eisen en wensen (ook wel requirements genoemd). Het gebruik van de hierboven

beschreven methode bevat een belangrijk deel van de ontwikkeling van requirements,

maar dekt echter niet alle requirements. Het belang van de kwaliteit van deze

requirements dient niet onderschat te worden. Vaak genoeg gebeurt het dat een

softwareproduct problemen vertoont met als oorzaak gebrekkige of steeds veranderende requirements. De user-input houdt hier direct verband mee, ofwel de mate waarin de gebruiker van het toekomstige systeem invloed heeft gehad in het te ontwerpen softwareproduct. Om allereerst het probleem van gebrekkige of incomplete requirements te voorkomen, worden verschillende soorten requirements onderscheiden. Op deze manier wordt de kans verkleind dat bepaalde requirements ondergesneeuwd raken of zelfs helemaal niet aan bod komen. Voor de onderverdeling van de requirements van het ontwerp van een digitaal operatiedossier wordt gebruik gemaakt van het FURPS+ model

(Larman, 2002) . De letters in deze afkorting staan voor verschillende soorten requirements, te weten:

• Functional – mogelijkheden, capaciteiten, beveiliging

• Usability - menselijke factoren, help, documentatie

• Reliability - Uitval, voorspelbaarheid

• Performance - reactietijd, doorvoer, nauwkeurigheid, beschikbaarheid

• Supportability - flexibiliteit, onderhoud + (de “+” staat voor een aantal sub-factoren):

• Implementation - resource beperkingen, tools, hardware

• Interface - beperkingen door interactie met externe systemen

• Operations - systeem management in operationele status

• Packaging

• Legal - juridisch, licenties e.d.

De requirements “Functional” en “Usability” hebben allen grotendeels een organisatorisch karakter. De meeste van deze requirements worden verkregen in de tweede stap van de Domain Driven IT Systems design methode. Met deze stap zal daarom antwoord gegeven kunnen worden op de deelvragen 1 t/m 8. Echter uit het FURPS+ model is te zien dat er nog een aantal andere soorten requirements zijn die aandacht behoeven. Om de deelvragen 9 en 10 te kunnen beantwoorden zullen een aantal andere soorten requirements ook onderzocht moeten worden. De requirements-typen “Reliability”,

“Supportability”, “Implementation”, “interface” en “Legal” zullen in dit onderzoek

behandeld worden om deze deelvragen te kunnen beantwoorden. Ook wordt door

gesprekken met het DB en met relevante partijen buiten Oogheelkunde informatie

betrekking hebbend op het domein achterhaald. Hierbij valt te denken aan

projectmanagers of softwareontwikkelaars van de ICT afdeling die momenteel al diverse

informatiesystemen voor het UMCG leveren. Deelvraag 11 wordt beantwoord door het

opstellen van een functioneel ontwerp.

4 Fase Domain

In deze fase wordt het domein van het toekomstige informatiesysteem verkend. Veelal door gesprekken maar ook door het lezen van alle voor het domein relevante gegevens over structuur, communicatie en processen.

4.1 User stories

De Domain driven IT systems design methode brengt het domein in kaart door zogenaamde user stories, de verhalen van de gebruikers die de basis vormen van het te ontwerpen informatiesysteem. Ook wordt door middel van deze verhalen antwoord gegeven op deelvraag 1: “Is de informatie uit het vooronderzoek nog steeds correct?”.

Om te bepalen met welke medewerkers gesproken dient te worden is een gebruikersstudie uitgevoerd. Deze studie achterhaalt welke gebruikers een relatie met het toekomstige informatiesysteem kunnen hebben. Eriksson en Penker geven in hun boek “De UML Toolkit” een vragenlijst waarmee relevante gebruikers achterhaald kunnen worden (Eriksson, 2000) . Deze lijst wordt binnen de UML in eerste instantie gebruikt om actoren

te achterhalen, maar kan tevens goed gebruikt worden om te achterhalen met welke medewerkers gesproken dient te worden. De lijst bevat een zestal vragen:

1. Wie gebruikt de hoofdfunctionaliteit van het systeem?

2. Wie heeft voor zijn dagelijkse taken ondersteuning van het systeem nodig?

3. Wie moet het systeem onderhouden, de administratie ervan voeren en ervoor zorgen dat het geheel werkt?

4. Met welke hardware moet het systeem werken?

5. Welke interactie moet er plaatsvinden met welke andere systemen?

6. Wie of wat is geïnteresseerd in de resultaten (de waarde) die het systeem produceert?

In de gebruikersstudie worden de verschillende rollen binnen het systeem geanalyseerd.

Als systeem wordt hier het operatiedossier bedoeld, dat onderwerp is van verandering.

De gebruikersstudie levert een lijst met gebruikers op en door de rollen van deze gebruikers te gekoppeld aan het operatiedossier (het achterhalen van instanties

) kan bepaald worden of de betreffende persoon daadwerkelijk met het systeem te maken heeft. Gezien het feit dat het bij de ontwikkeling van dit informatiesysteem gaat om de afstemming van het systeem met de gebruikers, blijft de gebruikersstudie in dit stadium beperkt tot de eerste twee vragen uit de hierboven genoemde vragenlijst. De andere vragen komen in paragraaf 6.1 aan de orde.

6

Dit zijn personen die interacteren met het informatiesysteem

Allereerst wordt een globale lijst samengesteld van personen die om wat voor reden dan ook enige (hoe klein ook) relatie met het operatiedossier hebben. Dit kan bijvoorbeeld al het geval zijn wanneer een persoon alleen maar het document van plaats A naar plaats B vervoert. Deze lijst is tot stand gekomen door de werkprocessen van begin tot eind door te nemen, mee te lopen op de afdelingen en gesprekken te voeren met medewerkers. In subparagraaf 1.4.3 werd al een lijst genoemd van gebruikers van het operatiedossier.

Tabel 4.1 herhaalt deze personen, met een aantal toevoegingen

, met uitleg, te weten:

Geïdentificeerde personen Uitleg

Oogartsen; Noteert gegevens in dossier; leest gegevens

uit dossier;

Arts-assistenten; Noteert gegevens in dossier; leest gegevens uit dossier;

Opnamecoördinatoren; Noteert gegevens in dossier; leest gegevens uit dossier;

Anesthesisten; Noteert gegevens in dossier; leest gegevens

uit dossier;

Poliverpleegkundigen; Noteert gegevens in dossier; leest gegevens uit dossier;

Verpleegkundigen verpleegafdeling; Noteert gegevens in dossier; leest gegevens uit dossier;

Verpleegkundigen dagbehandeling; Noteert gegevens in dossier; leest gegevens uit dossier;

Technisch Oogheelkundig Assistenten (TOA); Verricht voorwerk. Relatie dossier onduidelijk tot dusver.

Zaalartsen Noteert gegevens in dossier; leest gegevens

uit dossier;

Recovery verpleegkundigen Leest gegevens uit het dossier;

Secretariaat ODBC Vervoeren dossiers

Patiënten; Noteert gegevens in dossier; vervoert dossier

Oogheelkundig Archief; Slaat dossiers op

Centraal Medisch Archief. Slaat dossiers op

Vervolgens wordt aan de hand van voornoemde vragenlijst geanalyseerd wie daadwerkelijk gebruiker zijn en wie niet.

Vraag 1: Wie gebruikt de hoofdfunctionaliteit van het systeem?

Onder “hoofdfunctionaliteit” wordt het volgende verstaan: het invoeren en/of uitlezen van gegevens van een bepaalde operatie van een bepaalde patiënt.

De volgende personen voldoen aan deze definitie:

1. Oogartsen;

2. Arts-assistenten;

3. Opnamecoördinatoren;

4. Anesthesisten;

5. Poliverpleegkundigen;

6. Verpleegkundigen verpleegafdeling;

7. Verpleegkundigen dagbehandeling;

8. Patiënten;

9. Zaalartsen;

10. Recovery verpleegkundigen.

8

Deze toevoegingen zijn ontleend aan de zorgketens en omvatten die personen die in het Oogheelkundig

opnameproces betrokken zijn. De zorgketens kwamen ter sprake in paragraaf 1.3.

Ter controle wordt elk van de hierboven genoemde functies in verband gebracht met het operatiedossier en wordt een instantie hiervan achterhaald om te onderzoeken of deze rollen ook daadwerkelijk bestaan.

Ad 1: Oogartsen

Deze persoon (lees: de functie die deze persoon bekleedt)

vult na het stellen van een diagnose gegevens van de patiënt in op de oranje voorkant van het operatiedossier.

Instantie: De oogarts vult in het operatiedossier in of de ingreep die de patiënt dient te ondergaan een status Wachtlijst, Semi-spoed, Urgent, Spoed of een andere vorm is.

Conclusie: De oogarts is een gebruiker.

Ad 2: Arts-assistenten

De arts-assistent vervult gedeeltelijk dezelfde functie als de oogarts (in relatie tot het operatiedossier), met dien verstande dat de arts-assistent onder supervisie van een oogarts staat. Ook neemt de arts-assistent op zaterdagen de post-operatieve belronde over van de verpleegkundigen op de dagbehandeling.

Instantie: De arts-assistent vult in het operatiedossier in of de ingreep die de patiënt dient te ondergaan een status Wachtlijst, Semi-spoed, Urgent, Spoed of een andere vorm is.

Conclusie: De arts-assistent is een gebruiker.

Ad 3: Opnamecoördinatoren

De opnamecoördinator is betrokken bij het plannen van een operatiedatum. Hiervoor gebruikt deze persoon een aantal informatiesystemen, en het operatiedossier.

Instantie: Deze persoon verstrekt naar aanleiding van de resultaten van de gebruikte informatiesystemen een operatiedatum aan patiënt en noteert deze in het operatiedossier. Ook neemt de persoon een gezondheidsvragenlijst af en noteert de resultaten in het operatiedossier.

Conclusie: De opnamecoördinator is een gebruiker.

Ad 4: Anesthesisten

Deze groep personen is eerder al aangemerkt zijnde een bijzondere groep in dit onderzoek. Hoewel de anesthesist momenteel wegens zijn activiteiten zou voldoen aan het predikaat gebruiker, zal het grootste gedeelte van deze persoon in de toekomst uit het operatiedossier verdwijnen. Op de oranje voorkant van het operatiedossier blijft echter een klein veld dat door deze persoon ingevuld dient te worden. De rol van de anesthesist zal verder in het onderzoek nog ter sprake komen. Vooralsnog wordt de anesthesist behandeld als de andere gebruikersgroepen.

Instantie: Anesthesist vult uitslag anesthesie spreekuur in op oranje voorkant.

Conclusie: De anesthesist is een gebruiker.

Ad 5: Poliverpleegkundigen

Deze groep personen is betrokken bij het afnemen van anamneses (een gedeelte in het operatiedossier) en het voorlichten van de patiënt.

Instantie: De poliverpleegkundige kruist in het operatiedossier aan van welke aspecten betreffende de operatie de patiënt op de hoogte is gesteld.

Conclusie: De poliverpleegkundige is een gebruiker.

Ad 6: Verpleegkundigen verpleegafdeling

Deze verpleegkundigen verplegen de patiënten die op de verpleegafdeling liggen. Zij hebben een gedeelte in het operatiedossier wat hiervoor bestemd is.

Instantie: De verpleegkundige noteert voortgangsaantekeningen in het operatiedossier.

Conclusie: De verpleegkundige van de verpleegafdeling is een gebruiker.

9

Dit geldt voor het woord “perso(o)n(en)” in alle volgende punten binnen deze paragraaf, tenzij anders

Ad 7: Verpleegkundigen dagbehandeling

Deze verpleegkundigen verzorgen onder andere de pré- en post-operatieve belronden wanneer een patiënt voor dagbehandeling aangemerkt is. Ook maken zij aantekeningen over de status van de patiënt en nemen zij de ontslagcriteria door.

Instantie: De verpleegkundige kruist de antwoorden in het operatiedossier aan op de vragen die ze tijdens de belronde aan de patiënt stelt.

Conclusie: De verpleegkundige dagbehandeling is een gebruiker.

Ad 8: Patiënten

De patiënt vult zelf de gezondheidsvragenlijst in het operatiedossier in. Deze lijst is echter bestemd voor het anesthesielogisch gedeelte en zal dus in het toekomstige systeem niet meer aanwezig zijn. Er kan dus voor het toekomstige systeem geen instantie bedacht worden van de patiënt die gebruik maakt van de hoofdfunctionaliteit van het systeem.

Instantie: Niet aanwezig.

Conclusie: De patiënt is geen gebruiker.

Ad 9: Zaalartsen

De zaalarts bevindt zich op de verpleegafdeling. Daar wordt door de zaalarts de medicatie voor patiënten op de therapielijst ingevuld.

Instantie: De zaalarts vult medicatie in op de therapielijst Conclusie: De zaalarts is gebruiker.

Ad 10: Recovery verpleegkundigen

De recovery verpleegkundigen zijn werkzaam op de recovery afdeling waar de patiënt na de operatie terechtkomt wanneer deze onder narcose is geweest. De recovery verpleging bewaakt de patiënten tijdens het recoveryproces. Hierbij wordt soms in het oogheelkundig operatiedossier gekeken.

Instantie: De recovery verpleegkundige bekijkt de gezondheidsvragenlijst.

Conclusie: De recovery verpleegkundige is gebruiker.

Vraag 2: Wie heeft voor zijn dagelijkse taken ondersteuning van het systeem nodig?

Het mag natuurlijk duidelijk zijn dat alle reeds geïdentificeerde gebruikers ook onder deze categorie vallen. Deze gebruikers zijn echter al aangemerkt als gebruiker en behoeven dus niet nogmaals behandeld te worden. Interessanter is het om te kijken naar de groep die bij de vorige vraag afvielen. Dat zijn de patiënten.

De groep patiënten heeft twee relaties met het operatiedossier. De eerste is de in te vullen vragenlijst wanneer de patiënt een anesthesielogisch onderzoek dient te ondergaan. De tweede relatie betreft het louter vervoeren van het operatiedossier van plaats A naar B. De eerste relatie komt, zoals gezegd, te vervallen. Tenminste, komt buiten de grens van het onderzoek en daarmee buiten het systeem. De tweede relatie komt te vervallen op het moment dat het operatiedossier digitaal gemaakt is. De gegevens worden dan via het netwerk vervoerd.

Conclusie: De patiënt heeft in het toekomstige systeem geen relatie meer met het

operatiedossier. De patiënt is daarom geen gebruiker.