Dynamic Online Diagnostic System (DODS) - Hanze University

Dynamic Online Diagnostic System

W. Hofsta & C. Jager

Datum: 18 januari 2006Instituut: LabNoord HuisartsenlaboratoriumPlaats: Groningen



Datum: 18 januari 2006Instituut: LabNoord HuisartsenlaboratoriumPlaats: GroningenOpdrachtgever: J.H. NumanOpdrachtnemer: W.T. Hofstra & C.A. JagerBedrijfsbegeleider: G. KroonStagebegeleider: J.H. BosSchool: HanzehogeschoolAfdeling: Informatica

Voorwoord

In het kader van onze afstudeerstage, van de studie Informatica aan de Han-zehogeschool Groningen, hebben wij onderzoek verricht naar de mogelijkheidbij LabNoord om het afnemen, beoordelen en verwerken van functieonder-zoeken op de functieafdeling te automatiseren. Dit verslag is ontstaan alsgevolg van de afstudeerstage die wij binnen LabNoord hebben gelopen vanaugustus 2005 tot februari 2006. Via een student van de Hanzehogeschooldie bij LabNoord zijn afstudeerstage voltooid had, zijn wij in contact geko-men met heer Numan. De heer Numan is hoofd van de ICT afdeling binnende organisatie en had deze interessante afstudeeropdracht voor ons.

Naast het verrichte onderzoek, dat in dit verslag is opgenomen, hebben wijtijdens deze periode, aan de hand van het onderzoek, een oplossing voorLabNoord gerealiseerd. Deze bestond uit het aandragen van een maatwerkoplossing welke de functieonderzoeken op de functieafdeling automatiseert.

In eerste instantie is dit verslag gericht aan de organisatie van LabNoord.Vooral voor diegenen binnen de ICT afdeling, die na ons vertrek het pro-ject overnemen. Daarnaast is het ook bedoeld voor onze bedrijfsmentor, deheer Kroon, en de heer Numan. Dit verslag kan namelijk een verhelderendbeeld geven van de verschillende processen en informatiestromen binnen deorganisatie. Tenslotte is dit verslag ook bedoeld voor onze stagebegeleider,die aan de hand hiervan een beeld krijgt van de geleverde prestaties tijdensdit afstudeertraject.

Graag zouden wij de heer Numan bedanken voor het mogelijk maken vandeze stage. Daarnaast zouden wij de heer Kroon en de heer Bos willen be-danken voor hun begeleiding tijdens dit project. Onze dank gaat ook uitnaar de medewerkers van de ICT afdeling, die ons geholpen hebben het voor-gestelde doel te bereiken. Als laatste zouden wij ook de medewerkers van defunctieafdeling willen bedanken voor hun medewerking en het beantwoordenvan onze vragen.

Wieger Hofstra en Chris Jager,Groningen, 18 januari 2006

i

Inhoudsopgave

Voorwoord i

Samenvatting viii

1 Inleiding 1

2 Bedrijf 22.1 Organisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.4 ICT afdeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.4.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . 42.4.2 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4.3 Werkzaamheden . . . . . . . . . . . . . . . . . . . . . 4

2.5 Applicaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.5.1 LABOSYS . . . . . . . . . . . . . . . . . . . . . . . . 52.5.2 Schuursoft . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Opdrachtomschrijving 63.1 Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Huidige Situatie 74.1 Huidige proces . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.1.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . 74.1.2 Betrokkenen . . . . . . . . . . . . . . . . . . . . . . . 94.1.3 Visualisatie . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2 Statistieken proces . . . . . . . . . . . . . . . . . . . . . . . . 104.3 Remote Diagnostic System . . . . . . . . . . . . . . . . . . . 12

4.3.1 OptiLink . . . . . . . . . . . . . . . . . . . . . . . . . 124.3.2 DataLink . . . . . . . . . . . . . . . . . . . . . . . . . 124.3.3 Webapplicatie . . . . . . . . . . . . . . . . . . . . . . . 124.3.4 Beveiliging . . . . . . . . . . . . . . . . . . . . . . . . 134.3.5 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Gewenste situatie 155.1 Richtlijnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2 Requirements and recommendations . . . . . . . . . . . . . . 16

5.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 165.2.2 Recommendations . . . . . . . . . . . . . . . . . . . . 175.2.3 Verificatie . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.3 Gewenst proces . . . . . . . . . . . . . . . . . . . . . . . . . . 175.3.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . 17

ii

5.3.2 Onderzoek . . . . . . . . . . . . . . . . . . . . . . . . 185.3.3 Beoordeling . . . . . . . . . . . . . . . . . . . . . . . . 185.3.4 Publicatie . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.4 Visualisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.5 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6 Advisering 226.1 Mogelijkheden . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.1.1 Ontwikkeling intern . . . . . . . . . . . . . . . . . . . 226.1.2 Aanwenden bestaande oplossing . . . . . . . . . . . . 236.1.3 Ontwikkeling extern . . . . . . . . . . . . . . . . . . . 246.1.4 Mogelijke combinaties . . . . . . . . . . . . . . . . . . 24

6.2 Overzicht mogelijkheden . . . . . . . . . . . . . . . . . . . . . 246.3 Besparingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.4 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 Ontwerp 287.1 Functioneel Ontwerp . . . . . . . . . . . . . . . . . . . . . . . 28

7.1.1 Het proces . . . . . . . . . . . . . . . . . . . . . . . . 287.1.2 Beschrijving applicatie . . . . . . . . . . . . . . . . . . 297.1.3 Doel applicatie . . . . . . . . . . . . . . . . . . . . . . 307.1.4 Gebruikers applicatie . . . . . . . . . . . . . . . . . . . 307.1.5 Koppelingen applicatie . . . . . . . . . . . . . . . . . . 317.1.6 Visualisatie applicatie . . . . . . . . . . . . . . . . . . 317.1.7 Gebruikersproces applicatie . . . . . . . . . . . . . . . 327.1.8 Logbestanden . . . . . . . . . . . . . . . . . . . . . . . 337.1.9 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.2 Technisch Ontwerp . . . . . . . . . . . . . . . . . . . . . . . . 357.2.1 Applicatie omgeving . . . . . . . . . . . . . . . . . . . 357.2.2 Applicatie structuur . . . . . . . . . . . . . . . . . . . 357.2.3 Applicatie onderdelen . . . . . . . . . . . . . . . . . . 387.2.4 Client-side applicatie . . . . . . . . . . . . . . . . . . . 417.2.5 Afhankelijkheden . . . . . . . . . . . . . . . . . . . . . 43

8 Evaluatie 448.1 Organisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448.2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458.3 Techniek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8.3.1 Generiek karakter . . . . . . . . . . . . . . . . . . . . 458.3.2 Platformonafhankelijk . . . . . . . . . . . . . . . . . . 468.3.3 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8.4 Kennis opleiding . . . . . . . . . . . . . . . . . . . . . . . . . 47

iii

9 Conclusie en aandachtspunten 489.1 Waar automatiseren . . . . . . . . . . . . . . . . . . . . . . . 489.2 Hoe automatiseren . . . . . . . . . . . . . . . . . . . . . . . . 489.3 Kosten automatiseren . . . . . . . . . . . . . . . . . . . . . . 499.4 Aandachtspunten . . . . . . . . . . . . . . . . . . . . . . . . . 49

10 Literatuuropgave 50

A Appendix vooronderzoek 1A.1 Procedures functieonderzoeken (huidige situatie) . . . . . . . 1

A.1.1 DFD echo onderzoek . . . . . . . . . . . . . . . . . . . 1A.1.2 Procedure echo onderzoek . . . . . . . . . . . . . . . . 2A.1.3 DFD ergo onderzoek . . . . . . . . . . . . . . . . . . . 3A.1.4 Procedure ergo onderzoek . . . . . . . . . . . . . . . . 4A.1.5 DFD fundus onderzoek . . . . . . . . . . . . . . . . . 5A.1.6 Procedure fundus onderzoek . . . . . . . . . . . . . . . 6A.1.7 DFD bio onderzoek . . . . . . . . . . . . . . . . . . . 7A.1.8 Procedure bio onderzoek . . . . . . . . . . . . . . . . . 8A.1.9 DFD dexa onderzoek . . . . . . . . . . . . . . . . . . . 9A.1.10 Procedure dexa onderzoek . . . . . . . . . . . . . . . . 10

A.2 Opdrachtomschrijving . . . . . . . . . . . . . . . . . . . . . . 11

B Appendix ontwikkelomgeving 12B.1 Ontwikkelmethode . . . . . . . . . . . . . . . . . . . . . . . . 12

B.1.1 Waterfall . . . . . . . . . . . . . . . . . . . . . . . . . 12B.1.2 RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12B.1.3 Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13B.1.4 Keuze . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

B.2 Programeeromgeving . . . . . . . . . . . . . . . . . . . . . . . 13B.2.1 Serverside omgevingen . . . . . . . . . . . . . . . . . . 14B.2.2 Licenties . . . . . . . . . . . . . . . . . . . . . . . . . . 15B.2.3 Kosten . . . . . . . . . . . . . . . . . . . . . . . . . . . 15B.2.4 Clientside . . . . . . . . . . . . . . . . . . . . . . . . . 16B.2.5 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

B.3 Webserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17B.3.1 Internet Information Services . . . . . . . . . . . . . . 17B.3.2 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . 18B.3.3 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

B.4 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18B.4.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . 19B.4.2 Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 19B.4.3 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

B.5 Beveiliging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20B.5.1 Cryptografie . . . . . . . . . . . . . . . . . . . . . . . 20

iv

B.5.2 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . 21B.5.3 Autorisatie . . . . . . . . . . . . . . . . . . . . . . . . 21B.5.4 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22B.5.5 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

B.6 Kwaliteitsbewaking . . . . . . . . . . . . . . . . . . . . . . . . 22B.6.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23B.6.2 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23B.6.3 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

B.7 Versiebeheer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23B.7.1 CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24B.7.2 SVN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24B.7.3 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

B.8 Documentatie . . . . . . . . . . . . . . . . . . . . . . . . . . . 25B.8.1 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25B.8.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25B.8.3 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . 25B.8.4 Wiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

C Appendix ontwerp 27C.1 Schermontwerp . . . . . . . . . . . . . . . . . . . . . . . . . . 27

C.1.1 Inlogscherm . . . . . . . . . . . . . . . . . . . . . . . . 27C.1.2 Rechtenscherm . . . . . . . . . . . . . . . . . . . . . . 28C.1.3 Overzichtsscherm . . . . . . . . . . . . . . . . . . . . . 29C.1.4 Onderzoeksscherm . . . . . . . . . . . . . . . . . . . . 30C.1.5 Koppelscherm . . . . . . . . . . . . . . . . . . . . . . . 31C.1.6 Beoordelingsscherm . . . . . . . . . . . . . . . . . . . 32C.1.7 Settingsscherm . . . . . . . . . . . . . . . . . . . . . . 33

C.2 Functioneel ontwerp . . . . . . . . . . . . . . . . . . . . . . . 34C.2.1 Beheerder . . . . . . . . . . . . . . . . . . . . . . . . . 34C.2.2 Laborant . . . . . . . . . . . . . . . . . . . . . . . . . 35C.2.3 Specialist . . . . . . . . . . . . . . . . . . . . . . . . . 36

C.3 Technisch ontwerp . . . . . . . . . . . . . . . . . . . . . . . . 38C.3.1 DODS modules en services . . . . . . . . . . . . . . . 38C.3.2 Capaciteit . . . . . . . . . . . . . . . . . . . . . . . . . 40C.3.3 ERD database model . . . . . . . . . . . . . . . . . . . 41C.3.4 Database structure . . . . . . . . . . . . . . . . . . . . 41C.3.5 DODS-scriptlist . . . . . . . . . . . . . . . . . . . . . . 42C.3.6 DODS-script . . . . . . . . . . . . . . . . . . . . . . . 43C.3.7 XML werkformulier . . . . . . . . . . . . . . . . . . . 44

D Appendix organisatie 45D.1 Plan van aanpak . . . . . . . . . . . . . . . . . . . . . . . . . 45

D.1.1 Betrokkenen . . . . . . . . . . . . . . . . . . . . . . . 45D.1.2 Taken . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

v

D.1.3 Planning . . . . . . . . . . . . . . . . . . . . . . . . . 46D.1.4 Milestones . . . . . . . . . . . . . . . . . . . . . . . . . 47

D.2 Kosten project . . . . . . . . . . . . . . . . . . . . . . . . . . 48

E Appendix onwikkeldocumentatie MagicLinker 49E.1 Applicatie Overzicht . . . . . . . . . . . . . . . . . . . . . . . 50

E.1.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . 50E.1.2 Onderdelen . . . . . . . . . . . . . . . . . . . . . . . . 50

E.2 Applicatie Bouwen . . . . . . . . . . . . . . . . . . . . . . . . 52E.2.1 Sleutel genereren . . . . . . . . . . . . . . . . . . . . . 52E.2.2 Compileren . . . . . . . . . . . . . . . . . . . . . . . . 52E.2.3 Uitvoeren . . . . . . . . . . . . . . . . . . . . . . . . . 53

E.3 Applicatie Uitbreiden . . . . . . . . . . . . . . . . . . . . . . 54E.3.1 Functieonderzoek toevoegen . . . . . . . . . . . . . . . 54E.3.2 Foutmelding toevoegen . . . . . . . . . . . . . . . . . 55E.3.3 Conversie toevoegen . . . . . . . . . . . . . . . . . . . 56

E.4 Applicatie Testen . . . . . . . . . . . . . . . . . . . . . . . . . 57E.4.1 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 57E.4.2 Unit-testen . . . . . . . . . . . . . . . . . . . . . . . . 57E.4.3 Uitvoeren . . . . . . . . . . . . . . . . . . . . . . . . . 57

E.5 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58E.5.1 Voorbeeld HTML . . . . . . . . . . . . . . . . . . . . . 58E.5.2 Voorbeeld onderzoeksfilter . . . . . . . . . . . . . . . . 60

F Appendix DODS CD-ROM 62F.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62F.2 Documentatie . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

vi

Lijst van figuren

1 Organogram LabNoord . . . . . . . . . . . . . . . . . . . . . . 32 Tijd/actie diagram van een functieonderzoek (huidige situatie) 113 Tijd/actie diagram van een functieonderzoek (gewenste situatie) 194 Globale opzet venster binnen DODS. . . . . . . . . . . . . . . 305 Schematische weergave applicatie omgeving . . . . . . . . . . 356 Abstracte weergave oplossing . . . . . . . . . . . . . . . . . . 367 Schematische weergave scriptlist. . . . . . . . . . . . . . . . . 378 Schematische weergave interne structuur. . . . . . . . . . . . 389 Schematische weergave rechten structuur. . . . . . . . . . . . 4010 Schematische weergave DODS MagicLinker. . . . . . . . . . . 4211 DFD echo onderzoek . . . . . . . . . . . . . . . . . . . . . . . 112 DFD ergo onderzoek . . . . . . . . . . . . . . . . . . . . . . . 313 DFD fundus onderzoek . . . . . . . . . . . . . . . . . . . . . . 514 DFD bio onderzoek . . . . . . . . . . . . . . . . . . . . . . . . 715 DFD dexa onderzoek . . . . . . . . . . . . . . . . . . . . . . . 916 Schematische weergave asymmetrische encryptie. . . . . . . . 2117 Impressie van het inlogscherm. . . . . . . . . . . . . . . . . . 2718 Impressie van het rechtenscherm. . . . . . . . . . . . . . . . . 2819 Impressie van het overzichtsscherm. . . . . . . . . . . . . . . . 2920 Impressie van het onderzoeksscherm voor de laborant. . . . . 3021 Impressie van het koppelscherm met daarin de MagicLinker

applicatie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3122 Impressie van het beoordelingsscherm voor de specialist. . . . 3223 Impressie van het settingsscherm. . . . . . . . . . . . . . . . . 3324 Schematisch overzicht modules en services . . . . . . . . . . . 3925 ERD database model . . . . . . . . . . . . . . . . . . . . . . . 4126 Overzicht van betrokkenen project. . . . . . . . . . . . . . . . 45

vii

Samenvatting

LabNoord is een organisatie welke in opdracht van huisartsen en specialis-ten verscheidene onderzoeken afneemt. Een van die type onderzoeken binnenLabNoord, zijn functieonderzoeken.

Een functieonderzoek is een onderzoek naar een bepaalde lichaamsfunctie;bijvoorbeeld naar de longen of de fundus van een patient. Momenteel wor-den de functieonderzoeken nog op papier afgenomen en is de verwerking vande resultaten naar het elektronische patientendossier handmatig. Bovendienworden de afgenomen functieonderzoeken per bode van LabNoord naar hetMartiniziekenhuis gebracht ter beoordeling door een specialist.

Vanuit de organisatie was er de behoefte aan een oplossing waarmee hetproces voor alle functieonderzoeken geautomatiseerd kon worden. Door on-derzoek te verrichten naar het proces binnen de functieafdeling, kon de vol-gende probleemstelling afgeleid worden:

“Waar, hoe en tegen welke kosten kan het afnemen, beoordelen en verwerkenvan onderzoeken op de functieafdeling worden geautomatiseerd?”

Dit verslag biedt een antwoord op deze centrale probleemstelling door:

• een omgevingsschets van de organisatie te geven

• het huidige proces van een functieonderzoek te analyseren

• een mogelijke oplossing voor te stellen

• de mogelijkheden tot de realisatie van deze oplossing te bespreken

• om zo uiteindelijk een advies op te stellen

Na overleg met de opdrachtgever binnen het bedrijf, is vervolgens beslotenom ook de oplossing uit te werken en te realiseren voor LabNoord. Dezeuitwerking is opgenomen in de vorm van een ontwerp. Aan de hand van hetontwerp is uiteindelijk de oplossing gerealiseerd; het DODS systeem.

DODS is een webapplicatie waarmee functieonderzoeken elektronisch afge-nomen, beoordeeld en verwerkt kunnen worden. Het generieke DODS fra-mework biedt deze mogelijkheid voor elk van de verschillende functieon-derzoeken. De organisatie zal op deze manier in de toekomst zelf nieuwefunctieonderzoeken kunnen toevoegen en wijzigen.

viii

1 Inleiding

Het nieuwe zorgstelsel; een van de maatregelen die door het kabinet genomenis om de marktwerking in de zorgsector te verbeteren. Door meer concur-rentie te creeren hopen zij zorginstellingen te kunnen dwingen efficienter teopereren. Als gevolg hiervan zouden de kosten van de zorg omlaag gaan ende kwaliteit van de service stijgen. De praktijk zal uitmaken of dit nobeledoel uiteindelijk bereikt zal worden.

Om deze verhoogde efficientie te kunnen realiseren, is automatiseringbinnen organisaties een van de favorieten. Zo is er ook binnen LabNoord debehoefte aan automatisering. LabNoord houdt zich bezig met het afnemenvan onderzoeken in opdracht van huisartsen en specialisten. LabNoord wilde onderzoeken die bij de functieafdeling van deze organisatie afgenomenworden, automatiseren. Hiertoe is er voor de organisatie eerst een onder-zoek verricht, aan de hand van de onderstaande probleemstelling:


In dit verslag zal, door de probleemstelling in verschillende deelproblemenop te splitsen, in de komende hoofdstukken een antwoord geformuleerd wor-den op deze vraag. Het verslag kan in twee fases opgedeeld worden: eenonderzoeksfase en een realisatiefase. Naast het verrichte onderzoek is ernamelijk ook een project opgezet. Binnen dit project is een applicatie ge-realiseerd waarmee de onderzoeken op de functieafdeling geautomatiseerdkunnen worden.

Het verslag begint met het onderzoek. In dit onderzoek zal eerst de orga-nisatie omschreven worden, om op deze manier een beeld te vormen van deomgeving. Daarna is de opdrachtomschrijving opgenomen zoals deze vanuitLabNoord is uitgegeven. Hierop volgt een omschrijving van de huidige situ-atie, daarna die van de gewenste situatie. Aan het eind van het onderzoekwordt er tenslotte een advies gegeven.

Hierna volgt het gedeelte betreffende de realisatie van een oplossing voorhet beschreven probleem. Hiertoe is een project opgezet naar aanleiding vanhet onderzoek. In deze hoofdstukken is ten eerste het ontwerp opgenomen.Ook zijn er beslissingen opgenomen met betrekking tot de ontwikkelme-thodiek en de toe te passen technieken. Daarna volgt de evaluatie van hetdoorlopen project, en is tenslotte de conclusie opgenomen. Hierin wordt uit-eindelijk een antwoord gegeven op de hierboven staande probleemstelling.

1

2 Bedrijf

In dit hoofdstuk wordt een beeld geschetst van LabNoord. Eerst wordt eenbeschrijving gegeven van de organisatie, vervolgens de historie van de orga-nisatie, gevolgd door een organogram. Daarna wordt specifiek ingegaan opde ICT afdeling en tenslotte worden de belangrijkste applicaties besproken.

2.1 Organisatie

LabNoord is de overkoepelende naam voor de Stichting Huisartsen Labora-torium Noord (SHLN), de Stichting Trombosedienst Groningen en de Stich-ting Medisch Laboratorium Noord (SMLN). Binnen LabNoord zijn bijnavijfhonderd mensen werkzaam. LabNoord werkt vanuit een centraal labo-ratorium, dat gehuisvest is aan het Damsterdiep in Groningen en vanuitlaboratoria in de regio. Dit zijn het Martini ziekenhuis in Groningen, hetSt. Lucasziekenhuis in Winschoten, het Refaja ziekenhuis in Stadskanaal ende Geestelijke Gezondheidszorg (GGZ) in Assen.

Het Huisartsen Laboratorium verzorgt bloed-, urine-, sperma- en faeces-onderzoeken in opdracht van huisartsen. Tevens verzorgt het laboratoriumverschillende functieonderzoeken. Enkele voorbeelden hiervan zijn:

• Een zwangerschapsecho

• Een inspannings ECG

• Een botdichtheidsmeting

De Trombosedienst doet bloedonderzoek voor ongeveer 10.000 patienten inde regio. Vanuit een netwerk van 110 prikpunten, worden er monsters af-genomen die binnen enkele uren getransporteerd, bepaald en beoordeeldkunnen worden.

Tevens is er binnen de organisatie een commerciele tak; Stichting WebNoord.Stichting WebNoord staat los van LabNoord en biedt een pakket aan voorhet realiseren van elektronisch recepten verkeer tussen huisartsen en apothe-kers. Bij WebNoord zijn verschillende huisartsen en apothekers in de regioaangesloten, die maandelijks voor deze dienst betalen. De applicatie wordtdoor een medewerker binnen de ICT afdeling van LabNoord onderhoudenen uitgebreid.

2.2 Historie

Het fundament voor LabNoord is gelegd toen het Laboratorium voor Kli-nisch Chemisch Onderzoek (LKCO) en de Trombosedienst samengevoegdzijn in 1957. In 1989 is het LKCO overgegaan in de Stichting HuisartsenLaboratorium Noord. Het SHN hield zich in die tijd uitsluitend bezig met

2

laboratoriumdiagnostiek. De Trombosedienst hield zich bezig met het bege-leiden van patienten. Toen het SHLN ging uitbreiden, door de mogelijkheidte bieden ECG’s af te nemen, werd er een Functieafdeling gevormd. Doorfusies met enkele laboratoria in het noorden ontstonden meerdere plekkenwaar onderzoeken verricht konden worden. Uiteindelijk zijn deze laborato-ria samengebracht toen deze in 1992 verplaatst zijn naar het Damsterdiep.In 1998 is de SHLN gefuseerd met het laboratorium van het St. Lucasziekenhuis en de GGZ. De locatie aan het Damsterdiep is in 2000 na eenverbouwing DamsterDomus genoemd. Sindsdien zijn de laboratoria van hetMartini en het Refaja ziekenhuis opgenomen in de organisatie.

2.3 Overzicht

In deze paragraaf wordt de gehele organisatie weergegeven aan de hand vaneen organogram:

Figuur 1: Organogram LabNoord

Uit het organogram kan worden afgeleid dat de kern van de organisatie isopgebouwd uit vier stichtingen. Dit zijn WebNoord, de Trombosedienst,het Huisartsen Laboratorium Noord en het Medisch Laboratorium Noord.De drie laatstgenoemde maken deel uit van LabNoord. Daarnaast vallenonder LabNoord de verschillende stafdiensten, zoals in de figuur af te lezenis. Deze stafdiensten ondersteunen alle vier de stichtingen en zijn eigenlijkgeıntegreerd in de stichtingen. Het komt voor dat sommige medewerkersbinnen de ICT afdeling werkzaam zijn voor het Huisartsen LaboratoriumNoord, en andere voor het Medisch Laboratorium Noord. Om het organo-gram overzichtelijk te houden, zijn de stafdiensten echter in een aparte takopgenomen.

Aan het hoofd van de organisatie staat de directie, bestaande uit tweedirectieleden. Deze zijn directeur van alle bovengenoemde stichtingen en

3

hebben een achtergrond in het ziekenhuiswezen.

2.4 ICT afdeling

Deze paragraaf schetst ten eerste een algemeen beeld van de ICT afdelingvan LabNoord (zie ook organogram uit paragraaf 2.3). Vervolgens wordende historie van de afdeling en tenslotte de huidige werkzaamheden binnende ICT afdeling beschreven.

2.4.1 Algemeen

De ICT afdeling ondersteunt de processen en activiteiten die binnen Lab-Noord plaatsvinden. De ICT afdeling is gevestigd in de DamsterDomus enmomenteel zijn er 13 medewerkers werkzaam op de afdeling.

2.4.2 Historie

De ICT afdeling is in 1990 ontstaan toen door LabNoord een medewerkeris aangetrokken om zich voltijd bezig te houden met het onderhouden vanenkele servers binnen het bedrijf. In de loop der jaren zijn er steeds meerICT gerelateerde activiteiten bijgekomen, en daarom is in 1997 nog eenmedewerker aangetrokken.

Na de verbouwing van het Damsterdiep complex in 2000, is het aantalmedewerkers van de ICT afdeling drastisch verhoogd. In korte tijd is deICT afdeling uitgegroeid tot de huidige 13 medewerkers, die zich fulltimebezighouden met de ICT binnen de organisatie.

2.4.3 Werkzaamheden

De werkzaamheden van de ICT afdeling zijn in te delen in de volgendegroepen:

• Systeembeheer

• Applicatiebeheer

• Werkplekondersteuning

• Projecten

De systeembeheer activiteiten van de ICT afdeling bestaan uit het opzet-ten, onderhouden en inrichtten van systemen en netwerken. Er kan hierbijgedacht worden aan database servers, werkstations en VPN netwerken.

Het applicatiebeheer bestaat uit het onderhouden van de applicaties diebinnen de organisatie draaien ter ondersteuning van de bedrijfsprocessen.

4

Er kan hier bijvoorbeeld gedacht worden aan het instellen van gebruikers-rechten, het uitvoeren van updates, het aanpassen van instellingen en hetopschonen van databases.

Voor de werkplekondersteuning is er een medewerker van de ICT afdelingvoltijd werkzaam. Deze helpt medewerkers binnen de organisatie met hunwerkstations, wanneer deze niet naar behoren functioneren. Dit kan voor-komen in het geval van een defect, storing of door een veranderend pakketaan eisen binnen de organisatie.

Naast de bovenstaande activiteiten, komen er ook losse projecten voorop de afdeling. Zo vindt er momenteel een overschakeling plaats naar eenander patientendossier systeem (zie paragraaf 2.5). Daarnaast wordt er voorsommige software problemen zelf een oplossing ontwikkeld. Meestal is ditin combinatie met nieuwe hardware die geınstalleerd moet worden. Menkan hierbij bijvoorbeeld denken aan een apparaat dat stickers uitprint metdaarop barcodes van labnummers. Om een koppeling te maken met hetsysteem, is een maatwerkoplossing gerealiseerd.

2.5 Applicaties

Binnen LabNoord zijn er enkele belangrijke applicaties en omgevingen dienader toegelicht dienen te worden:

2.5.1 LABOSYS

LABOSYS is ontwikkeld door Philips, en speciaal ontwore om ingezet teworden binnen een laboratorium. LABOSYS maakt gebruik van een Cache.LABOSYS maakt het mogelijk patientgegevens bij te houden, onderzoekenin te plannen, uitslagen op te slaan en te factureren naar de patient. Ookbiedt het de functionaliteit om volledig te integreren in analyseapparatuurdoor middel van het data acquisitie systeem L 25. LABOSYS is in 1998door LabNoord in gebruik genomen en ondersteunt de functieonderzoekenop de functieafdeling.

2.5.2 Schuursoft

Schuursoft is het softwarepakket dat nu nog gedeeltelijk op de functieafde-ling wordt gebruikt. Dit pakket was voor de introductie van LABOSYS al ingebruik voor het verzorgen van de planning, dataopslag en facturering vanfunctieonderzoeken. De applicatie is bij de start van het laboratorium dooreen directeur van LabNoord gemaakt. Veel van de functieonderzoeken wor-den momenteel nog door Schuursoft verwerkt. Op het moment van schrijvenis de ICT-afdeling echter bezig met het omzetten van alle functieonderzoe-ken naar LABOSYS. Als de volledige omzetting heeft plaatsgevonden, zalhet Schuursoft pakket uit de roulatie worden gehaald.

5

3 Opdrachtomschrijving

In dit hoofdstuk wordt in het kort de opdrachtomschrijving van LabNoordbesproken. Deze opdrachtomschrijving is opgenomen in bijlage A.2. Daar-naast zullen de doelstelling en de probleemstelling worden besproken.

In de opdrachtomschrijving wordt eerst een beeld geschetst van het hui-dige proces voor een functieonderzoek, in dit geval een echoscopie. Hierinwordt beschreven hoe de onderzoeken per bode, voor beoordeling, heen enweer worden gependeld. De resultaten worden hierna met de hand inge-voerd. Vervolgens wordt een omschrijving gegeven van de te realiseren op-lossing. Hieruit komt naar voren dat er gezocht wordt naar een applicatie.De kern van de opdracht is kort samengevat:

• Automatiseren van afname en beoordeling van functieonderzoeken.

• Beoordeling door specialist moet met behulp van een webapplicatie.

• Maak de applicatie veilig.

• Maak de applicatie gebruikersvriendelijk.

• Een advies opstellen ten behoeve van hardware en netwerkeisen inrelatie met bestaande faciliteiten en met betrekking op de applicatie.

Deze door LabNoord omschreven eisen zijn op vele verschillende manieren teinterpreteren en bieden daarom geen goede basis om mee verder te werken.Ook blijkt uit het laatste deel van de opdrachtomschrijving dat er vanuitLabNoord veel onduidelijkheden zijn en dat nadere analyse noodzakelijk is.Met dit doel zal er in de komende hoofdstukken eerst de huidige situatieweergegeven worden, vervolgens de gewenste situatie, de mogelijkheden enuiteindelijk het advies omtrent een duidelijk geformuleerd probleem. Aan dehand daarvan zal besloten worden of een vervolgtraject kan worden ingezet.

3.1 Doelstelling

Vanuit de opdrachtomschrijving en overleg met de betrokkenen kan de vol-gende doelstelling worden geformuleerd:

“Het verhogen van de effectiviteit en de efficientie op de functieafdeling,om op deze manier kosten, tijd en fouten tot een minimum te beperken.”

3.2 Probleemstelling

Aan de hand van deze doelstelling en de opdrachtomschrijving kan de vol-gende probleemstelling gedefinieerd worden:


6

4 Huidige Situatie

In dit hoofdstuk wordt de huidige situatie binnen de functieafdeling nadergeanalyseerd, om zodoende een beter beeld te kunnen schetsen van de om-geving en het proces. Om dit goed in kaart te kunnen brengen is er tweeweken meegelopen op de functieafdeling.

In de volgende paragraaf wordt een beeld gegeven van het huidige proces,eerst in het algemeen en daarna per functieonderzoek. De tweede paragraafgaat in op de verschillende statistieken die bekend zijn omtrent functieon-derzoeken. Hierbij kan gedacht worden aan de frequentie, de doorlooptijden de kosten. De derde paragraaf gaat in op het Remote Diagnostic System(RDS), een systeem waarmee reeds een functieonderzoek is geautomatiseerd.

4.1 Huidige proces

In deze paragraaf wordt eerst een voorbeeld gegeven van het gehele procesdat doorlopen wordt bij een functieonderzoek. Daarna worden alle betrok-ken partijen bij een dergelijk functieonderzoek op een rij gezet. Tenslotteis er per functieonderzoek binnen LabNoord een weergave van het procesopgenomen, aan de hand van DFD’s (Data Flow Diagrams).

4.1.1 Algemeen

Op basis van de opdrachtomschrijving van LabNoord is duidelijk gewordendat de organisatie behoefte heeft aan een oplossing die de verschillende ge-gevensstromen op de functieafdeling kan automatiseren. Om een beeld tegeven van hoe een functieonderzoek verloopt, volgt hier een voorbeeld.

Een patient komt op afspraak bij zijn/haar eigen huisarts. De huisarts on-derzoekt de patient en in het geval hij diepgaander onderzoek gepast vindt,zal hij een papieren LabNoord aanvraagformulier invullen. Op dit aan-vraagformulier kan de huisarts aangeven welke onderzoeken hij de patientwil laten ondergaan. Ook aanvullende informatie, zoals medicatie die depatient inneemt, of de klachten die de patient ondervindt, kan hij hieropkwijt.

Dit ingevulde aanvraagformulier wordt aan de patient meegegeven, waar-na de huisarts een afspraak voor de patient maakt bij LabNoord. De mede-werker van LabNoord roostert de afspraak, afhankelijk van het betreffendeonderzoek, handmatig (Schuursoft) dan wel automatisch (LABOSYS) in.

Vervolgens gaat de patient op het afgesproken tijdstip naar LabNoord.Een laborant van LabNoord krijgt een kopie mee van de planning, en weethierdoor welke patienten hij/zij die dag kan verwachten. Deze laborant ont-vangt de patient in de onderzoekskamer op de functieafdeling. De patientoverhandigt het LabNoord aanvraagformulier aan de laborant. Vervolgens

7

loopt de laborant de ingevulde gegevens (adresgegevens, verzekering, medi-catie etcetera) na. Om er zeker van te zijn dat het vervolg van de procedurejuist verloopt, is het van belang dat deze gegevens correct zijn.

Als de gegevens kloppen, kan het functieonderzoek afgenomen worden.Voor het gemak gaan we uit van een blaasechoscopie. Zodra de patientplaats neemt op de onderzoekstafel, neemt de laborant vervolgens plaatsachter het echoscopie apparaat. Vervolgens neemt de laborant met behulpvan het apparaat foto’s van de blaas. Aan de foto’s, voegt de laborantmet behulp van de software van het onderzoeksapparaat extra informatietoe. Deze informatie kan bijvoorbeeld de naam en de afmetingen van hetgefotografeerde lichaamsdeel zijn. Op deze manier is het voor een specialistmakkelijker om een beoordeling te doen. Deze foto’s worden vervolgens opA6 formaat faxpapier afgedrukt. In totaal gaat het bij een echoscopie omongeveer 15 afgedrukte foto’s per onderzoek. Nadat alle foto’s zijn genomenis het onderzoek voor de patient voltooid en kan deze weer naar huis.

De laborant vult de waarnemingen gestructureerd in op een papierenwerklijst. Als de laborant deze werklijst heeft ingevuld, bundelt hij het ge-heel van aanvraagformulier, foto’s en de werklijst. Daarna overhandigt delaborant, aan het einde van de dag, de onderzoeksgegevens aan de admi-nistratieve medewerkers van de functieafdeling. Deze administratieve me-dewerkers voegt aan deze gegevensverzameling nog een papieren werklijsttoe, van het type Schuursoft of LABOSYS. Dit formulier wordt gebruiktdoor specialisten om de beoordeling op in te vullen. Een administratiefmedewerker van de functieafdeling legt de onderzoeksgegevens klaar, welkevervolgens door een bode worden opgehaald.

Een bode neemt dagelijks alle klaarliggende onderzoeken van LabNoordmee en brengt deze naar het Martini Ziekenhuis waar specialisten deze beoor-delen. De specialisten bekijken het aanvraagformulier, de foto’s, de werklijstvan de laborant, en vullen hun beoordeling met de hand in op de specialistenwerklijst.

Alle beoordeelde onderzoeken komen op een stapel te liggen en wordeneens per dag door de bode weer naar LabNoord gebracht. De bode geeft deonderzoeken af bij de administratie van de functieafdeling. De administratievult de gegevens (werklijst specialist), afhankelijk van waar het in wordtbijgehouden, handmatig in Schuursoft of LABOSYS in.

Elk uur worden de nieuw ingevoerde beoordelingen gecontroleerd dooreen medewerker van de ICT afdeling van LabNoord. In het geval dat hijgeen onregelmatigheden signaleert, zal hij de beoordeling definitief in hetsysteem doorvoeren. Mocht er zich wel een probleem voordoen, dan wordter contact gezocht met de betreffende specialist.

Aan het einde van de dag, worden alle nieuw ingevoerde beoordelingenuitgeprint en met de post naar de huisarts gestuurd. Tevens wordt afhanke-lijk van het type onderzoek, een kopie van de onderzoekgegevens zelf mee-gestuurd. De originele onderzoeksgegevens gaan bij de functieafdeling in

8

het archief. Als de huisarts een dag later de resultaten van het onderzoekbinnen heeft gekregen, zal hij de uitslag met de patient bespreken.

4.1.2 Betrokkenen

In deze paragraaf worden alle betrokken partijen bij een functieonderzoekop een rij gezet:

HuisartsDe huisarts initieert een functieonderzoek bij LabNoord, en maakt de uit-eindelijk uitslag weer bekend bij de patient.

PatientDe patient is de persoon waar het uiteindelijk allemaal om draait; de zorg-afnemer. De patient is erbij gebaat dat hij/zij snel en correct geınformeerdwordt.

LaborantDe laborant neemt het functieonderzoek af bij de patient. De laborant iseen medewerker van LabNoord.

SpecialistDe specialist beoordeelt het afgenomen functieonderzoek en is in dienst vaneen van de aangesloten ziekenhuizen.

Administratief medewerker functieafdelingDe administratief medewerker van de functieafdeling voert de beoordeeldefunctieonderzoeken in het Schuursoft of LABOSYS systeem in.

Administratief medewerker postafdelingDe administratief medewerker van de postafdeling van LabNoord verwerkthet binnenkomend telefoonverkeer. Deze medewerker verzorgt tevens deplanning van de functieonderzoeken en zorgt ervoor dat de uitslagen vanhet onderzoek via de post naar de huisarts worden verstuurd.

BodeDe bode pendelt de functieonderzoeken fysiek tussen LabNoord en het Mar-tini Ziekenhuis heen en weer.

ICTBeheert de software, werkplekken en technische infrastructuur waar de la-boranten gebruik van maken.

9

4.1.3 Visualisatie

Om een beter beeld te verkrijgen van de verschillende gebevens stromenbinnen de functieafdeling, zijn deze door middel van DFD’s per functieon-derzoek in kaart gebracht. Deze diagrammen zijn opgenomen in bijlage A.1.Hierin zijn goed de verschillende handelingen en informatiestromen te ziendie doorlopen worden per functieonderzoek.

Zoals uit de diagrammen is af te lezen, wordt er bij sommige onderzoekennog gebruik gemaakt van de Schuursoft. In de loop van 2005 zullen deonderzoeken allemaal worden omgezet naar LABOSYS. In overleg met hethoofd van de ICT afdeling van LabNoord is besloten om geen rekening tehouden met Schuursoft voor de toekomstige situatie.

Daarnaast is te zien, dat er op de applicaties die gebruikt worden bij defunctieonderzoeken, ook patientendossiers bijgehouden worden in de lokaledatabases. Deze lokale databases worden ten eerste gebruikt voor back-updoeleinden door de laboranten. In het geval van een anomaliteit, kan hetdesbetreffende onderzoek er nog bij worden gezocht. Nog belangrijker is datde opgeslagen onderzoeken, in het geval van een nieuw onderzoek, gebruiktworden voor een vergelijking. Op deze manier kan het ziektebeeld van eenpatient over een bepaald tijdsbestek bekeken worden. Aan de hand hiervankan bijvoorbeeld een vooruitgang, dan wel stagnatie geconstateerd worden.De specialist kan vervolgens beslissen om de behandeling aan te passen.

Momenteel worden alle gegevens in de lokale databases opgeslagen metbehulp van een ‘unieke’ patientcode. Deze is meestal gebaseerd op de eerstevier letter van de achternaam, gecombineerd met de geboortedatum. Hier-door komt het nog wel eens voor dat patientgegevens met elkaar verstrengeldraken omdat twee patienten dezelfde ‘unieke’ code blijken te hebben.

4.2 Statistieken proces

Hier zal een korte analyse worden gemaakt van de gemiddelde volumes enfrequenties van onderzoeken. In de volgende tabel staat een overzicht vanhet gemiddeld aantal functieonderzoeken per maand.

Onderzoek Aantal

Bioprogramma 493

Dexa 130

Echo 252

Ergometrie 224

Fundus 206

In totaal levert dit ongeveer 1305 functieonderzoeken per maand op. In detoekomst kan dit aantal licht groeien.

De gemiddelde tijdsduur van een functieonderzoek wordt in het schema (fi-

10

guur 2) weergegeven. Dit schema geldt voor de onderzoeken die reeds ge-realiseerd worden met behulp van LABOSYS. Voor de andere onderzoekenzijn stappen zeven, acht en negen iets anders, maar kosten ongeveer even-veel tijd. Het proces in het schema dat gestippeld staat weergegeven, is eenproces dat extern wordt uitgevoerd.

Figuur 2: Tijd/actie diagram van een functieonderzoek (huidige situatie)

1. Een huisarts of specialist vraagt een onderzoek aan bij LabNoord metbehulp van een LabNoord aanvraagformulier en maakt telefonisch eenafspraak.

2. De patient komt op het afgesproken tijdstip naar LabNoord voor hetonderzoek.

3. Een medewerker van LabNoord neemt het onderzoek af.

4. De resultaten van het onderzoek worden per bode verzonden naar hetMartini ziekenhuis.

5. Een externe specialist beoordeelt de gegevens en stelt aan de hand vanzijn beoordeling een advies op.

6. Het onderzoek, de beoordeling en het advies worden per bode verzon-den naar LabNoord.

7. De beoordeling en het advies worden handmatig ingevoerd in LABO-SYS.

8. Ongeveer eens per uur worden al de ingevoerde beoordelingen hand-matig gecontroleerd.

9. Beoordeling definitief opnemen in LABOSYS.

10. Beoordeling wordt uitgeprint en per post opgestuurd naar de betref-fende huisarts of specialist. Ook kunnen deze elektronisch wordenaangeboden via WebNoord.

De totale minimale doorlooptijd is 10 dagen, 1 uur en 42 minuten. Geziener geen afspraken zijn met specialisten, kan de tijd die de specialist nodigheeft voor het beoordelen varieren. Dit is minimaal een werkdag.

11

4.3 Remote Diagnostic System

Het Remote Diagnostic System (RDS) is een systeem dat in 2004 door tweestagiaires gerealiseerd is, en gebruikt wordt voor de automatisering van hetfundusonderzoek. Het fundusonderzoek is momenteel het enig geautoma-tiseerde functieonderzoek binnen LabNoord. Deze applicatie is tot standgekomen als oplossing voor hetzelfde probleem als staat beschreven in deopdrachtomschrijving (bijlage A.2).

De reden dat deze applicatie wordt behandeld, is omdat hij een beter in-zicht kan geven in de manier waarop de functieonderzoeken geautomatiseerdkunnen worden. Omdat deze applicatie reeds een jaar binnen de organisatieoperationeel is, kan er veel waardevolle informatie van afgeleid worden.

In het vervolg van deze paragraaf wordt er eerst ingegaan op de onder-zoeksspecifieke applicatie, OptiLink. Daarna wordt de RDS client applicatiebehandeld, gevolgd door het elektronische beoordelingsgedeelte van RDS.Vervolgens wordt de beveiliging van RDS behandeld. Tot slot worden dezwakke en sterke punten van RDS op een rijtje gezet.

4.3.1 OptiLink

TopCon OptiLink is een onderzoeksspecifieke applicatie waarmee de fundus-foto’s opgehaald worden van het fundus fotoapparaat. De gegevens kunnenvervolgens met behulp van OptiLink geexporteerd worden naar een mapop de lokale hardeschijf, in elk gangbaar afbeeldingsformaat. De applica-tie maakt geen deel uit van RDS, maar is nodig om onderzoeksgegevens tegenereren.

4.3.2 DataLink

DataLink is een voor RDS ontwikkelde client applicatie, die de patientgegevens(als XML) koppelt met de fundusfoto’s (uit OptiLink) en deze vervolgensdoorstuurt naar de server op het Martini Ziekenhuis ter beoordeling. Dezeapplicatie staat lokaal op elk van de onderzoekscomputers geınstalleerd enhaalt de foto’s uit de map waar ze door OptiLink naartoe geexporteerd zijn.

4.3.3 Webapplicatie

Voor het beoordelen van de onderzoeken door de specialist, is ervoor gekozeneen webapplicatie te schrijven in Perl. Met behulp van een inlogscherm kaneen oogarts zich identificeren (zie paragraaf ‘beveiliging’ voor aanvullendeinformatie), om hierna openstaande fundus onderzoeken te beoordelen. Na-dat een onderzoek is beoordeeld, zal er een EDIFACT bericht van wordengegenereerd dat op het filesysteem wordt opgeslagen. Elke minuut logt eenscript op de LABOSYS server, in op een FTP-server van LabNoord. Ditscript kijkt of er nieuwe EDIFACT berichten klaar staan, welke vervolgens

12

worden gedownload en opgenomen in LABOSYS. Om het uur worden dezenieuwe beoordelingen handmatig bekeken. Mits deze beoordelingen wordengoedgekeurd, worden ze definitief ingevoerd en zullen in uitgeprinte vormvia de post verstuurd worden naar de betreffende huisarts of specialist.

4.3.4 Beveiliging

Een medewerker van LabNoord kan zonder in te loggen gebruik maken vanDataLink en hiermee patient gegevens opvragen en onderzoeksresultatenopsturen. Deze onderzoeksgegevens worden via een onbeveiligde FTP ver-binding over een VPN lijn verstuurd naar de FTP-server. Een specialistkan in het ziekenhuis, een met een sleutel beveiligde kamer binnenlopen eninloggen op de applicatie. Vanaf daar kan hij via een onbeveiligde HTTPverbinding onderzoeken te beoordelen. De gebruikersgegevens worden bijge-houden in een XML bestand en de onderzoeksgegevens worden opgeslagenop het filesysteem van de webserver. De onderzoeksgegevens staan op eenpubliekelijk toegankelijk gedeelte van de webserver. Hier kan dus direct naargelinkt worden zonder dat een gebruiker ingelogd hoeft te zijn.

4.3.5 Evaluatie

De fundusapplicatie heeft voor- en nadelen. Hieronder volgt een opsomming.

Nadelen:

• De applicatie is specifiek gebouwd voor het fundus onderzoek en kandus niet ingezet worden voor andere, soortgelijke onderzoeken zonderde gehele applicatie aan te passen.

• Er moet per computer een client applicatie geınstalleerd worden, dieontworpen is voor een specifiek besturingssysteem, in het huidige gevalWindows 98. Als er overgestapt wordt op een nieuw besturingssys-teem, zal de clientapplicatie niet meer functioneren.

• De applicatie is niet uitbreidbaar, om ingezet te worden over het in-ternet, vanwege de onbeveiligde FTP verbindingen die de applicatiemaakt. Alleen binnen het VPN van LabNoord kan de applicatie ge-bruikt worden.

• Als er een verandering in de werklijst (lijst voor waarnemingen enadvisering) doorgevoerd wordt, zal een programmeur in de code vande applicatie moeten duiken om het aan te passen.

• De schaalbaarheid van de RDS applicatie is niet groot. Maar gezienhet aantal onderzoeken dat per maand afgenomen wordt (zie para-graaf 4.2) binnen LabNoord, levert dit niet direct problemen op. Ook

13

als dit aantal zou verdubbelen, zou dat geen moeilijkheden opleverenvoor de RDS applicatie. Wel neemt de responstijd van de applicatieaf, naarmate er meer onderzoeken mee afgenomen worden. Dit komtdoordat RDS geen gebruik maakt van een database, en alle te beoor-delen onderzoeken in een map geplaatst worden. Bij het opvragen vaneen onderzoek, zal in het slechtste geval de gehele verzameling vanentries (bestanden) doorlopen moeten worden.

Voordelen:

• Door de koppeling die RDS heeft met de fundusapplicatie OptiLink,worden de patientgegevens automatisch ingevuld, en kunnen gelijk inde lokale database gebruikt worden.

• De applicatie zorgt ervoor dat er minder fouten worden gemaakt methet overnemen van onderzoeksgegevens.

• De applicatie zorgt voor een significante vermindering in de tijd enkosten voor het afnemen van een fundusonderzoek. Dit vanwege hetverlagen van de benodigde tijd, om een onderzoek af te nemen en hetverminderen van het aantal fouten.

• De patient heeft theoretisch sneller de uitslag van een functieonderzoekdan de papieren methode.

14

5 Gewenste situatie

In dit hoofdstuk wordt de gewenste situatie geschetst. Bij het formuleren vandeze situatie is de haalbaarheid van de oplossing uiteraard een belangrijkefactor. Er wordt rekening gehouden met onder andere de scope, de require-ments, de recommendations, de dependancies en de huidige infrastructuur.Ook is er voor het opstellen van de gewenste situatie rekening gehouden metde voorschriften die vastgesteld zijn vanuit de overheid. Tenslotte is dezegewenste situatie gevormd aan de hand van de wensen en eisen van de klanten de opdrachtgever.

In de eerste paragraaf worden de geldende richtlijnen kort behandeld.De tweede paragraaf stelt globaal de gewenste situatie voor. In de derde pa-ragraaf wordt een visualisatie hiervan gegeven. Daarna volgt een paragraafmet een lijst van alle requirements en recommendations. Tenslotte is in delaatste paragraaf een conclusie opgenomen.

5.1 Richtlijnen

Bij het bepalen van de opties voor het formuleren van de gewenste situatie, isde afbakening van mogelijkheden door de overheid van cruciaal belang. Eenbelangrijk aspect is bijvoorbeeld, dat vanaf een januari 2006 de NEN7510[12], met verdere uitwerkingen in de NEN7511 [13] en NEN7512 [16], alsofficiele richtlijn geldt voor ICT in de zorg. In de toekomst zullen zorg-verzekeraars van de zorginstellingen eisen, dat aan deze richtlijnen wordtvoldaan. Hier dient dus rekening mee gehouden te worden in het ontwerp.Enkele belangrijke punten van deze richtlijnen zijn:

• Gedocumenteerde bedieningsprocedures.

• Beheer van wijzigingen.

• Scheiden van omgeving.

• Volgen en bewaken van de omgeving.

• Beheer van capaciteit.

Naast de NEN richtlijnen moet er ook rekening worden gehouden met devolgende wetten:

• Wet geneeskundige behandelingsovereenkomst vindplaats: BurgerlijkWetboek, Boek 7, artikelen 446-468.

• Wet bescherming persoonsgegevens.

• Wet computercriminaliteit.

• Wet identificatie bij dienstverlening.

15

5.2 Requirements and recommendations

Aan de hand van de overheidsrichtlijnen, die hierboven beschreven staan, ende eisen vanuit de organisatie, kan er een lijst van requirements en recom-mendations gedefinieerd worden waaraan de oplossing moet voldoen. Dezelijst is hieronder opgenomen.

De eisen en wensen vanuit de organisatie zijn opgesteld aan de hand vaninterviews onder de betrokkenen en op basis van bestaande documentatiebinnen LabNoord.

5.2.1 Requirements

• Webapplicatie realiseren ter verhoging van de efficientie, minimaal toe-pasbaar op het ECG onderzoek.

• Webapplicatie moet betrouwbaar en veilig zijn, conform de richtlijnengedefinieerd in de NEN7510 en gerelateerde documenten.

• Webapplicatie moet uitbreidbaar zijn naar het internet.

• Gebruikersvriendelijke en intuıtieve interface.

• Webapplicatie moet gemakkelijk te onderhouden en door te ontwikke-len zijn.

• Webapplicatie vormgegeven conform de huisstijl van WebNoord.

• Webapplicatie moet passen binnen de huidige LabNoord omgeving.

• Onderzoek dient elektronisch beoordeeld te kunnen worden door eenspecialist.

• Er moet een log bijgehouden worden van alle gebruikersacties.

• Rapportage van de beoordelingen dient in EDIFACT formaat aange-leverd te worden.

• Er dient een gebruikershandleiding gerealiseerd te worden.

• Er dient een systeemhandleiding gerealiseerd te worden.

• Advisering omtrent hardware en netwerk eisen opstellen met betrek-king tot de te realiseren oplossing.

16

5.2.2 Recommendations

• Webapplicatie realiseren die toepasbaar is voor alle functieonderzoe-ken.

• Mogelijkheid bieden voor huisartsen om de uitslagen elektronisch be-schikbaar te stellen.

• Koppeling met externe onderzoeksapplicaties, waarbij patientgegevensautomatisch in de onderzoeksapplicatie worden ingevuld (vanuit LA-BOSYS).

• Elektronische aanvraag van functieonderzoeken (huidig LabNoord aan-vraagformulier).

• Functionaliteit bieden tot het factureren van specialisten.

• De data en logica van de applicatie dient gescheiden te zijn.

5.2.3 Verificatie

Deze lijst van requirements en recommendations is aan het hoofd van deICT afdeling gepresenteerd op woensdag 21 september 2005 en aangenomenals definitief.

5.3 Gewenst proces

In deze paragraaf zal de gewenste situatie per onderdeel kort worden behan-deld. De reeds gerealiseerde RDS applicatie is meegenomen in deze analy-se. Verder is uiteraard rekening gehouden met eerder beschreven richtlijnenvanuit de overheid en de requirements en recommendations vanuit de orga-nisatie.

5.3.1 Planning

Voor het ondersteunen van de functieonderzoeken is de Schuursoft appli-catie volledig vervangen door LABOSYS. Hierdoor kan de modelplanningvolledig via LABOSYS verlopen, en hoeft niet meer met de hand opgesteldte worden, zoals bij sommige onderzoeken het geval was. Als een patienteen afspraak maakt bij de functieafdeling, wordt dit ingepland met behulpvan LABOSYS. Zodra de afspraak is ingepland, gegenereert LABOSYS au-tomatisch een labnummer. Dit labnummer is de unieke code waarmee hetbetreffende onderzoek tijdens het gehele proces geıdentificeerd kan worden.

17

5.3.2 Onderzoek

Op de dag van het onderzoek krijgt de laborant voor het functieonderzoekwaar hij die dag werkzaam is, een planning mee. De patient komt naar Lab-Noord om het onderzoek af te nemen. De laborant ontvangt de patient enneemt plaats achter een computer waarop de onderzoeksspecifieke softwareis geınstalleerd en vanaf waar de generieke webapplicatie benaderbaar is.Een clientside applicatie wordt “gepushed”1 vanaf de server naar de gebrui-ker. Deze applicatie vult de patientgegevens uit LABOSYS automatisch inin de onderzoeksspecifieke applicatie, zonder tussenkomst van de gebruiker.

De laborant kan vervolgens het onderzoek afnemen met de software vanhet desbetreffende functieonderzoek, en exporteert de onderzoeksresultatennaar een map. Hierna benadert de laborant de webapplicatie en neemt hetlabnummer over van de planning. Aan de hand van dit labnummer kan deapplicatie de patientgegevens uit LABOSYS erbij halen. Nu vult de labo-rant zijn/haar bevindingen in op de digitale werklijst. Door middel van eenclient-side applicatie, die overgezonden wordt vanaf de server en leesrechtenheeft op de lokale schijf van de client, worden de onderzoeksresultaten auto-matisch gekoppeld aan de patientgegevens. Dit geheel wordt ter beoordelingaangeboden aan specialisten.

5.3.3 Beoordeling

Periodiek maakt een specialist, via een beveiligde verbinding, contact met dewebapplicatie om te controleren of er onderzoeken beschikbaar gesteld zijnter beoordeling. Gezien de hoge frequentie waarmee onderzoeken aangebo-den worden, is het onpraktisch om de specialist te notificeren van de nieuwbinnengekomen onderzoeken. De specialist beoordeelt de onderzoeken elek-tronisch. De resultaten worden direct, zonder tussenkomst van menselijkhandelen, in LABOSYS gezet.

5.3.4 Publicatie

De huisarts en/of specialisten ontvangen de resultaten elektronisch of via depost. Door middel van het inloggen op een WebNoord faciliteit, kunnen deonderzoeksgegevens elektronisch benaderd worden.

5.4 Visualisatie

In deze paragraaf wordt een beknopt overzicht gegeven van het proces datdoorlopen wordt bij een functieonderzoek in de gewenste situatie. Dit over-zicht is vergelijkbaar met figuur 2 in paragraaf 4.2, waarin de huidige situatieweergegeven wordt. De nummering van de twee figuren komt overeen, zodat

1Met het “pushen” van een applicatie, wordt bedoeld dat de gebruiker de applicatieontvangt, zonder dat deze er expliciet om vraagt.

18

deze makkelijk vergeleken kunnen worden. In de gewenste situatie is de bodeoverbodig geworden omdat alle gegevens digitaal verzonden worden. Daar-om is er bij deze stappen geen tijdsaanduiding meer nodig. Dit resulteert inhet volgende tijd/actie diagram.

Figuur 3: Tijd/actie diagram van een functieonderzoek (gewenste situatie)

1. Een huisarts of specialist beslist tot het uitvoeren van een onderzoek.Hierbij wordt een LabNoord aanvraagformulier ingevuld en telefonischeen afspraak gemaakt.

2. De patient komt op het afgesproken tijdstip naar LabNoord voor hetonderzoek.

3. Een LabNoord medewerker neemt een onderzoek af en onderzoeksge-gevens worden gestuurd naar DODS.

4. Een externe specialist beoordeelt de onderzoeksresultaten en geeft aande hand van deze beoordeling een advies. De applicatie genereert aande hand van deze gegevens een EDIFACT bericht.

5. Eens per minuut worden EDIFACT berichten opgehaald en automa-tisch verwerkt en in LABOSYS gezet.

6. Ongeveer eens per uur worden al de ingevoerde beoordelingen hand-matig gecontroleerd en mits goedgekeurd, definitief opgenomen.

7. Beoordeling definitief opnemen in LABOSYS.

8. Beoordeling wordt door een administratief medewerker van de functie-afdeling uitgeprint en per post opgestuurd naar de betreffende huisartsof specialist.

19

Deze geschetste situatie heeft een minimale doorlooptijd van 8 dagen, 1 uuren 42 minuten. Het elektronisch overzenden van de onderzoeken via DODSzorgt voor een tijdwinst van twee dagen.

In deze nieuwe situatie verloopt een groot gedeelte van het proces elek-tronisch en komt er vrijwel geen papier meer aan te pas. Helaas is hetmomenteel nog niet realiseerbaar alle huisartsen de uitslagen elektronischaan te bieden. De huisartsen zijn niet verplicht een internetverbinding tenemen en zullen dus op een andere manier de uitslagen moeten ontvangen.De uitslagen die in LABOSYS geplaatst worden, zullen dus alsnog uitge-print en opgestuurd worden naar de desbetreffende huisarts. Om deze redenzal ook het aanvragen van een onderzoek voorlopig met formulieren blijvenverlopen.

5.5 Conclusie

In deze paragraaf worden de belangrijkste eigenschappen van de voorgesteldeoplossing op rij gezet en kort behandeld.

• In de eerste plaats moet de oplossing een generiek karakter hebben,zodat deze toepasbaar is op alle functieonderzoeken. In de toekomstmoet de applicatie makkelijk aan te passen zijn als een functieonder-zoek veranderd of bijkomt. Dit is noodzakelijk omdat het buitensporigveel tijd en geld zou kosten om voor elk functieonderzoek een aparteapplicatie te bouwen. Aangezien voor elk onderzoek een vergelijkbareprocedure geldt met minieme verschillen, is dit realiseerbaar.

• Ten tweede moet de generieke applicatie compatible zijn met de meestuiteenlopende software en hardware configuraties. Het moet niet zozijn dat de applicatie afhankelijk wordt van een bepaalde configuratie,waardoor de applicatie onbruikbaar zou kunnen worden.

• Ten derde moet er gebruik gemaakt worden van beveiligingstechnie-ken waarmee de applicatie ook uitbreidbaar is voor gebruik over hetinternet, en welke conform zijn met de richtlijnen zoals gesteld in deNEN7510. Op deze manier kunnen er in de toekomst eenvoudig andereziekenhuizen op het systeem aangesloten worden.

• Ten vierde moet de data en logica van de applicatie gescheiden worden.Op deze manier kunnen ook niet-programmeurs aanpassingen makenaan de werking van de applicatie. Zo zou er een applicatie gemaaktkunnen worden om werklijsten makkelijk aan te maken en/of te mute-ren. Deze werklijsten zouden dan door de applicatie ingelezen kunnenworden.

• Ten vijfde dient het project duidelijk afgebakend te worden. Geziende beperkte tijd waarin dit project uitgevoerd dient te worden, zullen

20

sommige aspecten buiten beschouwing gelaten worden. Het belang-rijkste is het opzetten van een generiek framework, waarin het mo-gelijk is de verschillende functieonderzoeken te implementeren. Ditframework moet in ieder geval de functionaliteit bieden om functie-onderzoeken elektronisch af te nemen, te beoordelen en te verwerken.Het is wenselijk dat er uiteindelijk, binnen het tijdsbestek van ditproject, twee functieonderzoeken via de generieke webapplicatie geau-tomatiseerd gaan worden. Op deze manier kan de werking van hetgenerieke framework gedemonstreerd worden. Het maken van afspra-ken voor functieonderzoeken en het terugrapporteren naar de huisartsvallen buiten dit project. Enerzijds vanwege het genoemde gebrek aantijd, anderzijds omdat het automatiseren van deze processen met debestaande technische infrastructuur nog niet te realiseren is. Wel zou,gebruikmakende van het generieke framework, een oplossing hiervoorbinnen handbereik moeten zijn.

21

6 Advisering

In dit hoofdstuk wordt een analyse gegeven van de mogelijkheden omtrenthet verwezenlijken van het doel, dat beschreven staat in de opdrachtom-schrijving. Hieruit volgt het uiteindelijke advies voor LabNoord.

6.1 Mogelijkheden

Bij het opstellen van een lijst met de verschillende mogelijkheden, kan grof-weg gesteld worden dat er vier verschillende richtingen zijn waarin gezochtkan worden. Ten eerste mogelijkheid is binnen de organisatie een oplossingte ontwikkelen, danwel de RDS applicatie aan te passen zodat deze vol-doet aan de eisen. Ten tweede is er de mogelijkheid het aankopen van eenbestaande applicatie. De derde mogelijkheid is het out-sourcen van de ont-wikkeling aan een derde partij en de vierde mogelijkheid is een combinatievan de drie.

6.1.1 Ontwikkeling intern

Gezien LabNoord gebruik maakt van afstudeerders als ontwikkelaars, vereistdit een relatief lage investering. Wel moet er rekening gehouden worden datde oplossing niet volledig afgemaakt kan worden binnen de looptijd van destage. Het project zal dus over moeten worden gedragen aan of een nieuwestagiair, of LabNoord personeel. Daarnaast is LabNoord verantwoordelijkvoor het functioneren van de oplossing, en zal LabNoord zelf, de problemendie kunnen voorkomen moeten oplossen. Dit zal tijd en dus geld kosten.Voor deze risico’s krijgt LabNoord wel een maatwerk oplossing terug. Dezeoplossing zal voldoen aan elk van de door LabNoord opgestelde eisen. Tevenszal de oplossing makkelijk te integreren en toe te passen zijn in de bestaandeomgeving.

Er kan gekozen worden een compleet nieuwe applicatie te bouwen, of deRDS applicatie te modificeren. De laatste lijkt de meest voor de hand lig-gende optie, maar er zijn enkele beperkingen. Argumenten die RDS mindergeschikt maken zijn:

• De omgevingsvariabelen staan statisch in de applicatie en zijn hierdoorlastig aan te passen.

• De applicatie is niet gericht op aanbieden van meerdere onderzoeken.

• De applicatie voldoet niet aan de richtlijnen opgesteld in de NEN7510specificatie.

• Datalink is platform afhankelijk.

• Datalink moet worden aangepast voor elk onderzoek.

22

• De vragenlijsten staan statisch in de applicatie en zijn hierdoor moei-lijk aanpasbaar.

• De applicatie biedt geen koppelmethodes met externe applicaties.

• De applicatie voldoet niet aan de eisen omtrent veiligheid van per-soonsgegevens.

• De code van de applicatie is niet gedocumenteerd.

Deze beperkingen maken het complex om de applicatie aan de eisen te latenvoldoen. Dit ook vanwege het ontbreken van documentatie van de RDSsoftware. Deze punten in overweging nemend, zal het uiteindelijk minder tijdkosten een nieuwe applicatie te verwezenlijken. Daarom wordt geadviseerdom bij de bouw van een applicatie binnen LabNoord, te kiezen voor deontwikkeling van een compleet nieuw product. Het is aan te raden de RDSoplossing uitgebreid te analyseren voordat de nieuwe oplossing ontworpenwordt, zodat de fouten die zijn gemaakt bij de ontwikkeling van RDS nietnogmaals worden gemaakt.

6.1.2 Aanwenden bestaande oplossing

Het aanwenden van een bestaande oplossing is eveneens een mogelijkheid.Daarom is gekeken naar bestaande pakketten die wellicht kunnen voldoenaan de eisen van LabNoord. Er zijn veel bedrijven die automatiserings-oplossingen aanbieden voor de medische wereld. Enkele daarvan zijn Unit4 Agresso, E.Novation B.V. en ORACLE. Het is interessant te vermelden,dat E.Novation B.V. een concurrent van WebNoord is. Het gaat hierbij omhet elektronisch recepten verkeer (erv), een dienst voor het uitwisselen vanrecepten tussen huisartsen en apothekers.

Het probleem bij deze aangeboden pakketten is dat ze deeloplossingenaanbieden voor het beschreven probleem. Zo heeft een pakket bijvoorbeeldde mogelijkheid om onderzoeksbestanden in vele formaten tussen verschil-lende systemen uit te wisselen, maar biedt het niet de faciliteiten om on-derzoeken af te nemen of te beoordelen. Er is geen pakket op de markt dattegemoet kan komen aan de opgestelde eisen. Dit betekent dat er meerderepakketten moeten worden aangeschaft of een bestaand pakket ingrijpendeaan te passingen om aan de specifieke eisen van de organisatie te voldoen,dit vergt een grote investering. Deze investering biedt nog geen garantiesdat de oplossing alle wensen dekt. Hiernaast is het aanpassingsvermogenvan deze oplossing gering, wat in de toekomst tot nog meer investeringenkan leiden. Hieronder worden de voor- en nadelen van de aanschaf van eenbestaande oplossing op rij gezet:

23

Voordelen Nadelen

Eigen ICT afdeling niet belast Relatief kostbaar in aanschaf

Risico’s liggen bij derde partij Kosten gemoeid aanpassen applicatie

Applicatie goed doorontwikkeld Oplossing waarschijnlijk niet ideaal

Geen interne expertise nodig

Goede aansluiting bij derden

Een voordeel is dat de ICT afdeling van LabNoord niet wordt belast als hetproject wordt uitbesteed. Daarnaast draagt de derde partij alle risico’s dieeen dergelijk omvangrijk project met zich meebrengt. Omdat een bestaandeapplicatie een bewezen concept is, kan men vrijwel zeker van zijn dat hetop een voorspelbare manier zal functioneren. Mocht dit niet het geval zijn,dan kan de externe partij daarop aangesproken worden. Daarnaast is bij deaanschaf van een extern pakket geen ontwikkelexpertise nodig.

6.1.3 Ontwikkeling extern

Ook is er de mogelijkheid om de ontwikkeling van de oplossing uit te bestedenaan een externe partij. Dit vergt een grote investering maar heeft buitendit punt alleen maar voordelen. Extern laten ontwikkelen legt vrijwel geenextra werkdruk op LabNoord ICT personeel en de risico’s van het correctfunctioneren van de applicatie zijn geheel voor de externe partij. Tevens kanworden opgegeven waar de applicatie allemaal aan moet voldoen. Zo moetdeze naadloos in de LabNoord omgeving passen en moet de oplossing elkvan de requirements dekken. Tenslotte kunnen afspraken worden gemaaktmet de externe partij voor onderhoud en toekomstige veranderingen.

6.1.4 Mogelijke combinaties

Als laatste is er de mogelijkheid om een combinatie te zoeken tussen hetuitbesteden van de ontwikkeling, het aanwenden van een bestaand pakketen het intern ontwikkelen. Hierbij kan bijvoorbeeld gedacht worden aan hetaanwenden van een of meer bestaande pakketten, waarbij de ontbrekendefunctionaliteit door LabNoord of door een externe partij wordt gerealiseerd.Deze oplossing zal een grote investering vergen en zal niet een perfecte maat-werk oplossing worden. Er kunnen geen garanties worden gegeven voor eenvolledige integratie dan wel niet een volledige oplossing.

6.2 Overzicht mogelijkheden

In deze paragraaf worden de bovenstaande mogelijkheden schematisch weer-gegeven en wordt er per onderdeel een waarde toegekend. Dit waarde oordeelwordt bepaald vanuit het oogpunt van LabNoord, waarbij een gunstige si-tuatie een + krijgt en een ongunstige een -.

24

Onderdeel Intern Extern Bestaande Combi

Kosten voor LabNoord ++ - - - - - -

Belasting ICT personeel +- ++ + +-

Risico voor LabNoord + ++ ++ +

Integratie omgeving ++ ++ +- +

Controle over traject ++ +- +- +

Volledigheid oplossing ++ ++ +- +

Benodigde expertise - + + +-

Aanpassing in toekomst - + +- +-

Totaal + + +- +-

Uit dit schema is af te leiden dat de oplossing te laten realiseren door eenextern bedrijf de beste optie is, het intern ontwikkelen van de oplossing komtals een na beste naar voren.

6.3 Besparingen

In deze paragraaf worden de besparingen besproken die mogelijk gemaaktkunnen worden in het geval dat de voorgestelde oplossing gerealiseerd wordtop een van de bovenstaande manieren. Er zal gekeken worden naar de tijddie op de functieafdeling bespaard kan worden, als het versturen, afnemenen verwerken van functieonderzoeken digitaal verloopt. Op deze manier kande impact op de werklast van de voorgestelde oplossing worden bepaald.Ook wordt hierbij gekeken naar de bijbehorende kosten.

Omdat LabNoord niet een duidelijk beeld heeft van de totale kostenper functieonderzoek, wordt in dit overzicht alleen ingegaan op de kostenvan de medewerkers binnen de functieafdeling. In de onderstaande tabelwordt eerst een overzicht gegeven van de verschillende medewerkers binnende functieafdeling, met daarbij het uurloon en het aantal minuten dat de-ze medewerkers in de huidige situatie per werkdag aan tijd kwijt is aanfunctieonderzoeken. Bij de berekeningen wordt uitgegaan van 1305 functie-onderzoeken per maand (zie paragraaf 4.2).

Functie Uurloona Benodigde tijd per werkdag

Bode e 37,- 60 min.

Admin. medewerker e 18,- 325 min.

Laborant e 23,- 1300 min.

aBedragen medewerkers inclusief werkgeverslasten.

Aan de hand van het uurloon en het aantal functieonderzoeken dat de func-tieafdeling afneemt en verwerkt, kunnen de huidige kosten per maand voorde verschillende functies binnen de afdeling in de huidige situatie berekendworden. Omdat op de functieafdeling geen overzichten worden bijgehouden

25

van het aantal fouten dat maandelijks voorkomt, wordt een aanname van20 fouten per maand per functieonderzoek gebruikt. De meeste fouten zijndoor een administratief medewerker van de functieafdeling binnen 15 minu-ten op te lossen. Er zijn echter ook problemen waar men gemiddeld tot eenuur voor nodig heeft om op te lossen. Dit komt drie maal per maand voor.De tijd en kosten die het verbeteren van deze fouten met zich meebrengt, isopgenomen onder de noemer: “Admin. medewerker fouten”.

Functie Benodigde tijd/maand Kosten(e)

Bode 20 uur 740,-

Admin. medewerker invoer a 109 uur 1.958,-

Admin. medewerker fouten b 36 uur 648,-

Laborant 435 uur 10.005,-

Totaal 600 uur 13.351,-

aAdministratief medewerker bezig met invoeren van onderzoekenbAdministratief medewerker bezig met verbeteren van fouten

Aan de hand van de gewenste situatie, zoals weergegeven in hoofdstuk 5,kunnen ook de manuren van de functieafdeling berekend worden voor denieuwe situatie. In deze situatie is de bode overbodig geworden. Aange-zien de invoer van onderzoeken automatisch gaat, zal een administratiefmedewerker minder tijd nodig hebben voor het verwerken van onderzoeken.Daarnaast kunnen er geen overtyp fouten meer voorkomen. Voor de labo-ranten zal de nieuwe situatie per onderzoek een tijdwinst van 3 minuten peronderzoek opleveren (zie paragraaf 5.4).

Functie Benodigde tijd/maand Kosten(e)

Bode 0 uur 0,-

Admin. medewerker invoer 22 uur 392,-

Admin. medewerker fouten 0 uur 0,-

Laborant 370 uur 8.510,-

Totaal 392 uur 8.902,-

Door de manuren van de huidige en gewenste situatie met elkaar te verge-lijken, kan er een berekening gemaakt worden van het aantal manuren datop jaarbasis wordt bespaard.

Bespaarde uren = (20 + 87 + 36 + 65) uur x 12 maanden = 2496 uur

Naast de besparing die gerealiseerd kan worden door het versturen, afne-men en verwerken van functieonderzoeken te digitaliseren, kan de organisa-tie door middel van de analyse van de procedures van de functieonderzoeken,een duidelijk beeld krijgen van de taken die de verschillende afdelingen ver-richten. Dit is waardevol omdat zo de verschillende afdelingen een beter

26

beeld krijgen welke taken ze uitvoeren, hoe lang deze taken duren, waar deknelpunten kunnen liggen, hoe deze opgelost kunnen worden en welke puntener nog verbeterd kunnen worden aan het proces. Zo zijn er sommige onder-delen van de procedures onbekend bij de medewerkers zelf, en weten nietwaarom ze worden uitgevoerd. Door deze procedures goed onder de loepte nemen, kunnen in de huidige situatie al maatregelen genomen wordendie het afnemen en verwerken van functieonderzoeken op de functieafdelingefficienter maken.

6.4 Conclusie

Aan de hand van de voorgaande hoofdstukken, waarbij een duidelijk beeld isgeschetst van het probleem, de oplossing en de verschillende mogelijkhedentot het bewerkstelligen van deze oplossing, wordt nu een advies gegeven metbetrekking tot de te volgen stappen. Zoals in de doelstelling staat beschre-ven gaat dit onderzoek over hoe LabNoord de effectiviteit en de efficientie opde functieafdeling kan verhogen, om op deze manier kosten, tijd en foutentot een minimum te beperken. Elk van de genoemde oplossingen kosten geldom te realiseren. Maar gezien de fouten die nu worden gemaakt zorgen voorverlies van tijd, moet de oplossing worden gezien als een investering welkeop termijn geld gaat besparen. Deze kostenbesparing is terug te vinden inparagraaf 6.3. Hieruit blijkt dat op jaarbasis 2496 manuur kan worden be-spaard. Daarnaast leidt het verminderen van fouten tot een hogere kwaliteitvan zorgverlening.

Na al de alternatieven te hebben overwogen, is het advies het extern latenontwikkelen van de oplossing aan de hand van het in dit verslag opgeno-men onderzoek. LabNoord krijgt op deze manier een oplossing die aan alde wensen voldoet zonder dat dit extra risico’s met zich mee brengt. Daar-naast wordt op deze manier vermeden dat de ICT afdeling van LabNoordextra belast wordt. Mochten in de toekomst ingrijpende veranderingen aande gerealiseerde oplossing gedaan moeten worden, bijvoorbeeld ten gevolgevan nieuwe wetgeving, zal dit door de externe partij bewerkstelligd kunnenworden. Dit heeft niet direct impact op de werklast van de ICT afdeling.

Dit advies, met bijbehorende analyse, is aan de opdrachtgever van LabNoordgepresenteerd. Deze heeft ervoor gekozen de oplossing voor het probleem,dat beschreven staat in hoofdstuk 3, de opdrachtomschrijving, vanwege fi-nanciele redenen intern te laten realiseren. In bijlage D.1.1 is een overzichtopgenomen van de betrokkenen bij het geınitieerde project.

In de volgende hoofdstukken zal de gekozen oplossing verder worden uitge-werkt en vervolgens worden gerealiseerd. Tenslotte zal het gehele proces vananalyse tot realisatie worden geevalueerd.

27

7 Ontwerp

In dit hoofdstuk zijn het functionele en het technische ontwerp opgenomen.In het functioneel ontwerp wordt ingegaan op wat de te vervaardigen appli-catie moet gaan doen. In het technisch ontwerp wordt ingegaan op hoe dezeapplicatie gerealiseerd kan worden.

In het vervolg, als er gerefereerd wordt naar de applicatie, is dat onder denaam DODS. Dit is de naam die de te realiseren applicatie heeft gekregen.DODS staat voor Dynamic Online Diagnostic System.

7.1 Functioneel Ontwerp

Het functioneel ontwerp bestaat uit de beschrijving van de omgeving, de be-schrijving van de applicatie, het doel van de applicatie, de visualisatie vande applicatie, de koppelingen van de applicatie, de gebruikers van de appli-catie en de gebruikersprocessen binnen de applicatie. Daarnaast wordt ernog ingegaan op specifieke onderdelen; namelijk het logproces en de backupfaciliteiten.

De onderdelen spreken in principe voor zichzelf. Bij de koppelingen vande applicatie, worden de koppelingen bedoeld die DODS heeft met andereapplicaties (voor import en export).

7.1.1 Het proces

Een functieonderzoek zal in de toekomst aan de hand van een gewijzigd pro-ces doorlopen worden. Het proces zoals hier beschreven, is gelijk aan figuur3 in paragraaf 5.4, zoals deze werd voorgesteld voor de gewenste situatie.Daarnaast is hieronder ook een volledige opsomming van het vernieuwdeproces weergegeven:

• Een patient komt op afspraak bij de huisarts.

• De huisarts onderzoekt de patient.

• In het geval dat de huisarts diepgaander onderzoek verricht wil zien,vult deze een LabNoord aanvraagformulier.

• Dit aanvraagformulier wordt aan de patient meegegeven.

• De dokter, assistent of patient zelf maakt een afspraak bij LabNoordvoor het onderzoek (telefonisch).

• De postafdeling van LabNoord roostert deze afspraken via LABOSYSin.

• De patient overhandigt aan de aanwezige laborant van LabNoord hetaanvraagformulier.

28

• Laborant neemt functieonderzoek af bij patient.

• De onderzoeksgegevens worden bewaard in de lokale database van debetreffende functieapplicatie.

• De laborant exporteert de onderzoeksgegevens naar een map op delokale schijf.

• DODS koppelt de onderzoeksgegevens uit de applicatie met de pa-tientgegevens.

• De laborant vult een elektronische werklijst voor waarnemingen in metDODS.

• De laborant verstuurt met DODS de onderzoeksgegevens naar de ser-ver.

• Een specialist logt in op het DODS systeem en bekijkt de nieuweonderzoeken die op de DODS server staan.

• Specialist stelt elektronisch een beoordeling op.

• DODS genereert van een beoordeeld onderzoek een EDIFACT berichten stuurt dit digitaal naar de LABOSYS query server van LabNoord.

• De query server verwerkt en controleert de EDIFACT berichten envoert deze automatisch in LABOSYS in.

• Elk uur worden alle nieuwe beoordelingen in LABOSYS handmatiggecontroleerd en definitief ingevoerd.

• Eens per dag worden alle nieuwe beoordelingen door LabNoord fysiekuitgeprint door de administratieve krachten binnen de functieafdeling.

• De beoordelingen worden naar de postafdeling gebracht om vervolgensin een envelop naar de huisarts gestuurd te worden met kopie vanonderzoek.

• Huisarts ontvangt uitslag functieonderzoek LabNoord via de post enbericht de patient. Uitslagen kunnen ook via een WebNoord verbin-ding elektronisch bekeken worden door de huisarts.

7.1.2 Beschrijving applicatie

De webapplicatie dient gebruiksvriendelijk en intuıtief te zijn, zodat (eind)gebruikers er gemakkelijk mee kunnen werken. Daarnaast moet het uiterlijkvan de webapplicatie passen binnen de LabNoord huisstijl.

De globale opzet van het hoofdvenster binnen DODS is een onderverde-ling in drie delen (zie afbeelding voor impressie). Het grootste oppervlak

29

van het venster wordt gebruikt om de eigenlijke inhoud van de huidige pa-gina weer te geven (1). Hier worden tijdens een onderzoek de bevindingeningevoerd (werklijst) en bijvoorbeeld de labcode opgegeven. Tijdens hetbeoordelen door de specialist worden hier alle onderzoeksgegevens gepresen-teerd, inclusief de bijbehorende afbeeldingen. Links hiervan bevindt zich dealgemene navigatiebalk (2) waarmee alle stappen in de huidig geselecteerdeprocedure overzien en geselecteerd kunnen worden. Onderaan het vensteris een andere navigatiebalk aanwezig (3) waar de knoppen “volgende” en“vorige” weergegeven worden. Hiermee kan tussen de verschillende stappenvan de procedure gesprongen worden.

Figuur 4: Globale opzet venster binnen DODS.

7.1.3 Doel applicatie

Het doel van de te realiseren applicatie is het verminderen van het aantalfouten dat gemaakt wordt tijdens het doorlopen van het proces, en hetverminderen van de benodigde tijd voor het afnemen en verwerken van eenonderzoek. Uiteindelijk zou dit ook tot een reductie van de operationelekosten moeten leiden.

7.1.4 Gebruikers applicatie

Binnen het systeem zijn er vier verschillende gebruikersgroepen te definieren.

• Applicatiebeheerders

• Systeembeheerders

• Laboranten

• Specialisten

30

De applicatiebeheerders van DODS kunnen onder andere nieuwe gebruikerstoevoegen, muteren en verwijderen. Daarnaast kunnen ze logbestanden be-kijken en instellingen binnen de applicatie wijzigen. Hierbij kan gedachtworden aan de verschillende locaties waar de werklijsten opgeslagen staan,waar de resultaten geplaatst moeten worden en wat de verschillende instel-lingen voor de verbinding met LABOSYS zijn.

De werkplekken van de laboranten, de technische infrastructuur en hetserver beheer zal worden uitgevoerd en onderhouden door een systeembe-heerder.

Medewerkers van LabNoord die de daadwerkelijke onderzoeken uitvoe-ren op de functieafdeling vallen binnen de Laboranten groep. Deze groepvult bevindingen in op de elektronische werklijst en koppelt de gegenereerdeonderzoeksbestanden aan het betreffende onderzoek.

De specialisten beoordelen de onderzoeken die door de laboranten zijnafgenomen. Dit doen zij aan de hand van de bevindingen en onderzoeksbe-standen die de laboranten hebben opgesteld. De specialist vult het advies-gedeelte van de werklijst in.

In de toekomst kan er een vierde groep gedefinieerd worden, namelijk op-drachtgevers. Deze groep bestaat uit huisartsen en specialisten. Huisartsenen specialisten zullen in eerste instantie alleen de resultaten ontvangen. Ditis mogelijk op papier of als EDIFACT bericht. In de toekomst kunnen huis-artsen en specialisten ook aangesloten worden op de digitale diensten vanLabNoord en kan deze groep ook via DODS de onderzoeksgegevens inzien.

7.1.5 Koppelingen applicatie

DODS heeft verschillende koppelingen met externe applicaties. Voor elk vande functieonderzoeken worden er verschillende softwarepakketten gebruiktom onderzoeksbestanden te genereren. Hieronder staat een overzicht perfunctieonderzoek met de naam en ontwikkelaar van het pakket:

Functieonderzoek Applicatie Ontwikkelaar

Echoscopie Technos Partner ImageLab Esaote

Ergometrie Cardio Control Workstation Welch Allyn

Fundus OptiLink TopCon

Long MasterScope PC Erich Jaeger GmbH

Dexametrie Delphi C Hologic

7.1.6 Visualisatie applicatie

In bijlage C.1 zijn impressies van verschillende applicatieschermen opgeno-men. Het inlogscherm, opgenomen in bijlage C.1.1, dient iedere gebruikerzich moet identificeren om toegang te verkrijgen tot het systeem. Deze

31

gebruikers kunnen ingedeeld worden in drie hoofdgroepen: beheerders, la-boranten en specialisten. Beheerders zijn onder te verdelen in operationeel-en systeembeheerders. Door middel van een koppeling van de gebruiker aanbepaalde rechten, verkrijgt deze toegang tot bepaalde delen van het sys-teem. Deze rechten zijn door een beheerder van het systeem instelbaar (zieapplicatiescherm C.1.2).

Nadat de gebruiker zich heeft geıdentificeerd, krijgt deze een overzichtte zien van alle toegangelijke functies, te zien op applicatiescherm C.1.3.De laborant kiest het onderzoek uit het gepresenteerde overzicht. Daarnavolgt voor een functieonderzoek het onderzoeksscherm C.1.4. Zoals te zienis op dit scherm, zijn in de linker navigatiebalk alle stappen van de te doorlo-pen procedure afgebeeld. Deze procedure is soortgelijk voor de verschillendeonderzoeken. Eerst wordt het labnummer ingevoerd dat op de planning aan-gegeven staat. Hierna worden de gekoppelde patientgegevens weergegeven.De volgende stap is het invoeren van de bevindingen op de werklijst. Ver-volgens worden de digitale onderzoeksbestanden (van de externe applicatie)gekoppeld (C.1.5). Daarna volgt een overzicht van alle ingevoerde gegevensen tenslotte is er een bevestigingsscherm.

De afgenomen onderzoeken komen in een lijst te staan, zoals staat afge-beeld op het beoordelingsscherm C.1.6. De specialist werkt dan deze lijstvan onderzoeken af, door per onderzoek een beoordeling en een advies tegeven. Tenslotte stelt DODS deze uitslagen ter beschikking aan LABOSYS,dat ze vervolgens automatisch verwerkt.

7.1.7 Gebruikersproces applicatie

In deze paragraaf wordt tot in detail ingegaan op het gebruikersproces datdoorlopen wordt per gebruikersgroep. Dit is een uitbreiding op de vorige pa-ragraaf en beschrijft daarbij ook alle functionaliteit die voor deze gebruikers-groepen benodigd zijn. Alleen de belangrijkste punten worden opgenoemd.Voor de complete beschrijving wordt doorverwezen naar bijlage C.2.

Beheerder

Hieronder wordt puntsgewijs een opsomming gegeven van de belangrijkstehandelingen van een beheerder binnen DODS (zie ook bijlage C.2.1).

• beheerder logt in.

• beheerder krijgt een lijst te zien met de onderdelen waarvoor hij be-voegt is en maakt hieruit een keuze (omgevingsvariabelen, logbestan-den, gebruikersmanagement).

• beheerder bekijkt en/of wijzigt een van de onderdelen van het beheers-gedeelte.

32

• beheer logt uit.

Laborant

Hieronder wordt puntsgewijs een opsomming gegeven van de belangrijkstehandelingen van een laborant binnen DODS (zie ook bijlage C.2.2).

• laborant logt in.

• laborant kiest onderdeel van overzichtsscherm waarvoor hij bevoegt is(ECG-, botdichtheids-, echo-, fundus- of longonderzoek).

• laborant neemt onderzoek af en doorloopt DODS script bestaande uitde volgende schermen: selecteer labnummer, patientgegevens, werklijst,koppel foto, bevestig gegevens, bevestig verzenden.

• laborant logt uit.

Specialist

Hieronder wordt puntsgewijs een opsomming gegeven van de belangrijkstehandelingen van een specialist binnen DODS (zie ook bijlage C.2.3).

• specialist logt in.

• specialist kiest onderdeel van overzichtsscherm waarvoor hij bevoegd-heid heeft gekregen (ECG-, botdichtheids-, echo-, fundus- of longon-derzoek) om te beoordelen.

• specialist stelt beoordeling op door het DODS script te doorlopen, be-staande uit de schermen: onderzoekslijst, analyse, bevestig onderzoek,bevestig verzenden.

• specialist logt uit.

7.1.8 Logbestanden

Logbestanden zijn belangrijk voor het achteraf analyseren, aan de hand vanwelke acties, fouten of problemen hebben kunnen plaatsvinden. Ook onge-oorloofd gebruikersgedrag is hiermee te traceren en te bewijzen. Om dezereden moet elke gebruikersactie worden gelogd. Daarnaast moet ook elkedoor het systeem gegenereerde foutmelding gelogd worden. Deze foutmel-dingen kunnen automatisch worden gerapporteerd aan een beheerder doormiddel van e-mail, zodat deze direct op de hoogte is van de problematiek.Een log-entry bestaat uit de melding, gekoppeld aan een gebruiker ID, hetIP adres van de gebruiker en een timestamp. Een speciaal toegewezen au-ditor bezit de rechten deze logbestanden te kunnen inzien en doorzoeken.

33

Deze auditor is bewust een ander persoon dan de beheerders van het sys-teem; dit in verband met veiligheidsoverwegingen. Geen enkele gebruiker,ook niet auditoren, kunnen deze loggegevens muteren of verwijderen. Defunctionaliteit is onder andere afhankelijk van de correctheid van de time-stamp. Hierdoor is het van belang dat er gebruik wordt gemaakt van eentimeserver zoals staat voorgeschreven in de NEN7510 richtlijnen.

7.1.9 Backup

De oplossing zal zich bevinden in een productieomgeving waarin beschik-baarheid en betrouwbaarheid de speerpunten zijn. Om bij geval van cala-miteiten de downtime zo laag mogelijk te houden, is er onder andere eengoede backup voorziening nodig. De onderzoeksgegevens en de resultatenworden opgeslagen en gebackuped in ofwel de onderzoeksapparaten zelf, ofLABOSYS, heeft DODS als enige wettelijke verplichting de logbestanden,gedurende de wettelijke bewaartermijn, te bewaren.

34

7.2 Technisch Ontwerp

In het technisch ontwerp zal dieper op het eigenlijke ontwerp van de appli-catie worden ingegaan. Eerst zal de applicatieomgeving worden behandeld,hierna de hoofdapplicatie en vervolgens de client-side applicatie. Tenslottezal naar de benodigde capaciteiten en afhankelijkheden worden gekeken.

In bijlage B worden de verschillende keuzes besproken omtrent het op-zetten van de ontwikkelomgeving. Bij het technisch ontwerp, komen dezegemaakte keuzes naar voren.

7.2.1 Applicatie omgeving

De hoofdapplicatie zal object georienteerd worden geschreven in PHP5, enworden toegepast als webapplicatie. De client-side applicatie wordt gereali-seerd in JAVA. Onderzoeksgegevens en omgevingsvariabelen worden opge-slagen in een MySQL database en de onderzoeksresultaten worden bewaardop een filesysteem. De structuur van de database is terug te vinden in debijlage C.3.3. De motivatie voor het gebruik van deze omgeving is terug tevinden in de bijlage B.

Figuur 5: Schematische weergave applicatie omgeving

7.2.2 Applicatie structuur

In de vorige hoofdstukken is vastgesteld dat de applicatie een generiek karak-ter moet hebben, gericht moet zijn op security en makkelijk onderhoudbaarmoet zijn. Om het generieke karakter te kunnen garanderen zal de oplossingbestaan uit kleine eenvoudige bouwstenen. Met behulp van deze bouwstenenkunnen complexe structuren worden gemaakt. De bouwstenen hebben alle-maal de zelfde basisstructuur. Deze structuur is afgeleid vanuit de gewenstesituatie. Uit deze situatie het volgende abstractiemodel worden opgesteld:

• Er is informatie, namelijk onderzoeksvragen en onderzoeksgegevens.

• Er wordt een actie uitgevoerd op basis van deze informatie, namelijkeen beoordeling.

• Deze beoordeling levert informatie op.

35

Figuur 6: Abstracte weergave oplossing

Dit abstractemodel is de kern van de oplossing en kan worden toegepastop elk van de onderdelen. Het model zal worden toegepast onder de naamDODS-script. Een DODS-script is niet een compilebare applicatie maar eenaantal afspraken waaraan het model moet voldoen. Dit kan gerealiseerdworden in elke willekeurige taal. De applicatie bestaat uit een combinatievan deze bouwstenen. De volgorde van de bouwstenen wordt bepaald dooreen scriptlist. Een scriptlist is niets meer dan een lijstje met namen vanDODS-scripts met eventuele parameters. De afspraken zijn gemaakt met devolgende punten in gedachte:

• Een DODS-script voert een specifieke simpele actie uit.

• Een DODS-script is configureerbaar met parameters van de scriptlist.

• Een DODS-script kan op elke willekeurige plek in een scriptlist staan.

• Een DODS-script richt zich op het weergeven van gegevens, en hetafvangen van gebruikersinvoer.

• Een DODS-script werkt zijn eigen gebruikersinvoer af.

• Een DODS-script heeft zelf minimale functionaliteit, de eigenlijke func-tionaliteit wordt aangeboden door de diverse DODS-modules.

Naast deze afspraken is er ook een structuur gedefinieerd aan welke elkDODS-script moet voldoen. Een script moet twee basis functies hebben,namelijk Display en PostProcess. In de Display functie worden informa-tie en/of vragen weergeven op het scherm. De PostProcess functie zal degebruikersinvoer afvangen en doorgeven aan de modules. Als PostProcessfunctionaliteit nodig is zal het script dit aanmelden bij het systeem, zodatde PostProcess functie van het script bij de volgende iteratie van DODSzal worden aangeroepen. Gezien de aard van een website is deze structuurnoodzakelijk. De gebruikersinput kan immers pas worden afgevangen als degebruiker op een link of submit knopt drukt. De volgende pagina weet nietwat de vorige pagina inhield en kan daarom geen acties hierover uitvoeren.

De Display en PostProcess functies kunnen worden gezien als de tweeinformatie stromen in het model. Display, links, is daarbij de inkomendestroom en PostProcess, rechts, is de uitgaande stroom. De acties wordenuitgevoerd door modules. Deze modules bieden DODS functionaliteit aan,

36

en geven zelf geen output op het scherm. Een voorbeeld van een module isde Lobosys module. Deze module handelt de communicatie met LABOSYSaf. Naast de modules zijn er services. Services bieden DODS diensten aan.Een voorbeeld is de Debug service, die elke debugwaarde bijhoudt en des-gewenst op het scherm zet. Naast de Debug service zijn er de Error en Logservice. Een overzicht van de gebruikte modules en services is te vinden inbijlage C.3.1.

De genoemde afspraken maken een DODS-script erg krachtig, en beter inzet-baar. Zo kan er nu een DODS-script worden gemaakt voor het controlerenvan de logingegevens, of voor het veranderen van een interne setting. Ookkan het script de gebruiker een vraag stellen over een bepaald onderzoek.Een voorbeeld van een DODS-script is terug te vinden in bijlage C.3.6.

Scriptlist

Een scriptlist bestaat uit een lijst, van een of meer DODS-scripts, met nul ofmeer parameters. Zo kan bijvoorbeeld een parameter aan een scriptlist wor-den meegegeven, welke ervoor zorgt dat de navigatie niet zichtbaar is. EenDODS-scripts kan ook parameters meekrijgen vanuit de scriptlist. Hierinstaat bijvoorbeeld naar welk fileformaat gezocht moet worden bij het zoe-ken naar onderzoeksbestanden. Een DODS-script voert een specifieke actieuit, bijvoorbeeld het weergeven van patient gegevens, een scriptlist voert eenspecifieke procedure uit, bijvoorbeeld een fundus onderzoek. DODS-scriptsworden afgewerkt aan de hand van de volgorde waarin ze staan in de script-list. Een DODS-script mag meerdere malen voorkomen in een scriptlist.

Figuur 7: Schematische weergave scriptlist.

Bij een scriptlist kan gekozen worden om ‘trajectcontrole’ aan of uit te zet-ten. Trajectcontrole zorgt ervoor dat een scriptlist maar op een manierdoorlopen kan worden. Dit is nodig bij het afnemen van een onderzoek waareerst een patient gekozen moet worden voor er gegevens aan gekoppeld kun-nen worden (zie figuur C.1.4 in de bijlage). Dit is echter niet bruikbaar bijhet beheren van gebruikers, waar de beheerder kan kiezen tussen het aan-maken of het muteren van een gebruiker (zie figuur C.1.2 in de bijlage). Eenvoorbeeld van een scriptlist is terug te vinden in bijlage C.3.5.

37

De hoofdapplicatie is door gebruik van DODS-scripts erg eenvoudig. Dezefunctioneert alleen als een soort linker die kiest welke actie uit een scriptlistgeladen en uitgevoerd moet worden. Een programma iteratie gaat als volgt:

• Start services.

• Vang navigatiegegevens af.

• Als er een PostProcess functie geregistreerd is, werk deze af.

• Laad een scriptlist aan de hand van de navigatiegegevens.

• Voert het script uit. Dit script gebruikt eventueel een of meer modulesen kan een PostProcess functie registreren.

Figuur 8: Schematische weergave interne structuur.

7.2.3 Applicatie onderdelen

In deze paragraaf worden de belangrijkste onderdelen van de hoofdapplicatiebesproken. Eerst zal er gekeken worden naar de interface, vervolgens naarde beveiliging en toegangsrechten. Daarna wordt de implementatie van dewerklijsten besproken, tenslotte wordt dieper in gegaan op gegevens expor-tatie mogelijkheden.

Interface

Het uiterlijk van de applicatie staat geheel los van de applicatie. Het uiter-lijk hangt af van het gekozen thema. Voor het standaard thema wordt dehuisstijl van WebNoord gebruikt. In de hoofdapplicatie zullen de methodes:‘header, menu en footer’ worden aangevraagd. Deze drie methodes handelenhet uiterlijk af. De menu methode geeft een menu weer aan de hand vande gekozen scriptlist. De onderdelen van het menu zijn de in de scriptlistaanwezige DODS-scripts.

Omgevingsvariabelen

Binnen DODS wordt er gebruik gemaakt van globale environment settings.Deze variabelen worden opgeslagen in de database (zie C.3.3) en wordengeladen bij de initialisatie van DODS. Elk script en module erft deze set-tings en kan hier gemakkelijk gebruik van maken. Een setting bestaat uit

38

een modulenaam, een eigennaam, een waarde en een omschrijving. Zo iser bijvoorbeeld de variabele in de module ‘Labosys’, met als naam ‘hostna-me’ met als waarde een IPadres. In het beschrijvingsveld staat een kortebeschrijving welke zichtbaar is op settings beheerpagina (zie C.1.7) waar devariabelen makkelijk aantepassen zijn. In DODS is deze variabele overalbeschikbaar onder $settings[”labosys”][”hostname”].

Beveiliging

Om de veiligheid en de geheimhouding van de onderzoeks- en persoons-gegevens te bevorderen zal elke verbinding met de webserver via een SSLverbinding gaan. LabNoord kan zelf een Certificate Authority (CA) wor-den of gebruik maken van door een internet browser erkende publieke CA’s,hier zijn dan wel extra kosten aan verbonden. De gebruikers krijgen vanLabNoord een persoonlijke key welke ze moeten installeren in hun internetbrowser. Zowel de server als de gebruiker kan vanaf dat moment de authen-ticiteit van de ander controleren. Alleen als beide partijen het hier over eenszijn kan er gebruik worden gemaakt van de diensten.

Zodra een gebruiker DODS benadert zal deze zich moeten identificerenaan de hand van een gebruikersnaam en een wachtwoord. Het wachtwoor-den systeem zal zich gedragen conform de richtlijnen opgesteld in NEN-EN12251 [10] (“Health informatics Secure User Identification for Health Ca-re Management and Security of Authentication by Passwords”) specificatie.Er is maar een gebruiker per gebruikersnaam. De SHA-256 hash van hetwachtwoord van een gebruiker wordt opgeslagen in de database, daardoor isde informatie niet terug te leiden naar het oorspronkelijk wachtwoord.

In de security module staan de encryptie algoritmes en functies. Mochter in de toekomst worden gekozen voor een andere encryptie methode, danhoeft slechts op een plaats aanpassingen gerealiseerd worden.

Toegangsrechten

Toegangsbeveiliging moet ervoor zorgen dat geautoriseerde gebruikers toe-gang krijgen tot voorzieningen en gegevens, terwijl anderen worden geweerd.Toegangsbeveiliging heeft tot doel dat het raadplegen, veranderen, toevoe-gen en verwijderen van gegevens alleen gecontroleerd kan gebeuren. In eersteinstantie zal DODS te maken hebben met drie gebruikersgroepen: labo-ranten, specialisten en beheerders. Dankzij het generieke karakter van descriptomgeving is een degelijk rechtensysteem mogelijk. Met behulp van derechtenstructuur kan per gebruiker worden ingesteld welke rechten hij heeft.

De rechtenstructuur is opgedeeld in delen, ‘sections’ genaamd. Een sec-tion heeft nul of meer subsections, die op hun beurt weer nul of meer sub-subsections hebben. Zo is er de Section ‘Onderzoek’ (niveau 1) met de

39

subsection ‘Echoscopie’ (niveau 2) met de subsubsection ‘Schildklier’ (ni-veau 3). Een subsubsection is gekoppeld aan een scriptlist. In dit voorbeeldzal een schildklier echoscopie onderzoek worden weergegeven. Gebruiker-stoegang wordt uitgedeeld op het subsection niveau (niveau 2). Zo kan eenbeheerder een gebruiker toegang geven tot elke subsubsection die onder desubsection ‘Echoscopie’ vallen.

Figuur 9: Schematische weergave rechten structuur.

Werklijsten

Tijdens een onderzoek worden een aantal vragen gesteld aan de onderzoeker,de zogenaamde werklijst. De specialist die het onderzoek zal beoordelen veltzijn oordeel aan de hand van de antwoorden en de onderzoeksgegevens. Deapplicatie biedt de specialist een aantal mogelijkheden voor advies, en demogelijkheid tot het maken van een opmerking. De vragen zijn gekoppeldaan een bepaald onderzoek. De antwoorden op deze vragen moeten wordenopgeslagen als een EDIFACT bericht en de antwoorden moeten worden ge-koppeld aan de LABOSYS fieldtag zodat het systeem weet bij welke vraageen antwoord hoort. Ook is de wens vanuit LabNoord dat deze vragen mak-kelijk aan te passen of uit te breiden zijn.

Om aan deze behoeften te kunnen voldoen wordt de informatie opge-slagen in XML formaat. Als de onderzoeksvragen op deze manier wordenopgeslagen staan ze geheel los van het systeem, waardoor geen kennis vanhet systeem nodig is om onderzoeksvragen aan te passen. Een tweede voor-deel is dat XML files dankzij de duidelijke structuur makkelijk te veranderenzijn en het geen vereiste is om het hele systeem te kennen. Daarnaast kande structuur worden gecontroleerd aan de hand van de Document Type De-finition (DTD) zodat de vragenlijst altijd in een correct formaat staat.

Het XML bestand zal zowel de vragen als de koppelwaarden voor LABO-SYS bevatten. Ook zal het algemene gegevens zoals de naam, datum waaropde laatste verandering is doorgevoerd en het versie nummer bevatten. Ant-woorden op de vragen kunnen horizontaal of verticaal worden weergegeven.De keuze van uitlijnen kan worden aangegeven in de ‘alignment’ tag. Een

40

simpel voorbeeld van dit XML bestand is te vinden in de bijlage: C.3.7.De antwoorden op de werklijsten worden opgeslagen in de database in

array formaat, waarbij de tree index van het XML bestand overeenkomt metde index van de array. Hierbij moet er wel rekening worden gehouden, datals de structuur van het XML bestand verandert, deze mapping niet meerovereenkomt, en mogelijk fouten zal genereren. Om dit probleem te voor-komen moeten veranderingen in de structuur van het XML bestand wordenopgeslagen onder een andere versie. Bij het opslaan van de antwoorden opde vragen in de database, moet het versienummer van het XML bestandworden opgeslagen, zodat deze gegevens aan elkaar gekoppeld zijn.

Gegevens exportatie

Zoals in de gewenste situatie is geschetst, is er de wens om de onderzoeksre-sultaten direct, zonder tussenkomst van menselijk handelen, in LABOSYSte exporteren. Helaas kan LabNoord door een gebrek aan mankracht dezemogelijkheid niet aanbieden en zal dit via een omweg moeten worden ge-realiseerd. De onderzoeksgegevens kunnen alleen worden aangeboden alsEDIFACT bericht. EDI, Electronic Data Interchange, wordt binnen Lab-Noord gebruikt als communicatie medium voor onderzoeksgegevens. Voorhet oversturen van rapporten wordt er gebruik gemaakt van de in 1993 gede-finieerde MEDRPT standaard. Nadat een specialist de onderzoeksgegevensheeft gezien en zijn werkformulier heeft ingevuld, wordt een EDIFACT be-richt gegenereerd. Dit bericht wordt gegenereerd aan de hand van het XMLbestand en de antwoorden van de onderzoeker en de specialist. Dit EDI-FACT bericht wordt op het filesysteem van de server opgeslagen. Op deLABOSYS server draait een script dat elke minuut deze folder controleerten de EDIFACT berichten ophaalt en verwerkt. De berichten worden eenmaal per uur handmatig gecontroleerd en goedgekeurd. Daarna wordt deuitslag digitaal of per post naar de huisarts verzonden.

7.2.4 Client-side applicatie

Zoals in paragraaf B.2.4 staat beschreven, is er naast het server-side gedeelteook een client-side gedeelte nodig. Hier wordt deze applicatie, MagicLinkergenoemd, verder uitgelicht.

Algemeen

De naam MagicLinker is gebaseerd op het feit dat de applicatie onderzoeks-bestanden, die gegenereerd worden tijdens een functieonderzoek, automa-tisch koppelt aan patientgegevens. Dit houdt in dat eerst de onderzoeksbe-standen (meestal foto’s) van de lokale harde schijf van de client verzameldworden, en vervolgens doorgestuurd worden naar de DODS server.

41

Doordat het koppelen van de onderzoeksbestanden automatisch verlooptdoor de MagicLinker, kunnen fouten vermeden worden en zal de gebruikers-vriendelijkheid van de applicatie verbeterd worden. Dit is een grote verbe-tering tenopzichte van de oude situatie. Om de werking van de MagicLinkeruit te leggen, is hieronder een schematische weergave opgenomen:

Figuur 10: Schematische weergave DODS MagicLinker.

Ten eerste neemt de laborant het onderzoek af bij de patient met behulp vanhet software pakket dat speciaal voor het functieonderzoek bedoeld is. De-ze applicatie genereert onderzoeksbestanden welke in een map op de lokaleschijf opgeslagen worden. De clientside applicatie MagicLinker haalt dezelokaal opgeslagen bestanden vervolgens automatisch op, aan de hand vanvooraf opgegeven parameters. MagicLinker wijzigt eventueel het formaat,comprimeert de bestanden en verstuurt ze naar een DODS module aan dekant van de server. Deze ontvangt de bestanden en slaat ze op de server op.

Techniek

Voor de implementatie van de MagicLinker applicatie is ervoor gekozen omgebruik te maken van JAVA technologie. Voor de MagicLinker applicatiespecifiek zal er gebruik gemaakt worden van een JAVA applet.

Door gebruik te maken van server-side “push” wordt de applicatie naarde gebruiker verzonden. Dit betekent dat de applicatie niet bij de gebruikergeınstalleerd hoeft te zijn. De applicatie is alleen aanwezig op de server.Op deze manier kan de software makkelijk ge-update worden en hebben degebruikers altijd de nieuwste versie. De applicatie zal in de vorm zijn vaneen JAVA Applet. De Applet draait binnen de omgeving van de webbrowser.Omdat een JAVA Applet standaard geen rechten heeft om een lokale schijfte raadplegen, zal er gebruik gemaakt worden van een certificaat.

Het generieke karakter van de applicatie blijkt uit de mogelijkheid om deapplicatie volledig aan te sturen met behulp van parameters. Hierin wordenbijvoorbeeld de syntax van het te vinden onderzoeksbestand opgegeven, hetpad van de te doorzoeken map en het type functieonderzoek. De applicatieis daarnaast volledig opgebouwd uit modules. Op deze manier kan gemak-kelijk een nieuw onderzoek aan de applicatie worden toegevoegd. Ook zijner standaardmodules aanwezig die door elk van de geımplementeerde func-tieonderzoeken gebruikt kunnen worden. Zo is er functionaliteit voor hetconverteren van gegevens formaten, functionaliteit voor het comprimeren

42

van data en functionaliteit voor het verzenden van data.De applicatie maakt gebruik van een HTTPS POST methode om de data

over te zenden van de MagicLinker software naar de DODS server. De ‘S’ inHTTPS staat voor secure en maakt gebruik van SSL om gegevens met Ma-gicLinker beveiligd te verzenden. De reden voor het gebruik van een HTTPSPOST methode is dat dit verkeer door de meeste firewalls toegelaten wordt.Omdat voor het normale gebruik van internet HTTPS benodigd is, bijvoor-beeld voor het lezen van webmail, voor webwinkelen of internetbankieren,zal DODS voor de mensen met een internetverbinding te gebruiken zijn.

7.2.5 Afhankelijkheden

Voor de realisatie van de oplossing zijn er enkele afhankelijkheden waar re-kening mee gehouden dient te worden. Het gaat hierbij om procedureleveranderingen en het inrichten van een omgeving waarbinnen de oplossingkan functioneren. Nadat deze afhankelijkheden afgehandeld zijn, kan de ge-realiseerde oplossing geımplementeerd worden.

Patientcodes omzetten

Zoals in paragraaf 4.1.3 beschreven staat, worden er momenteel binnen delokale databases van de onderzoeksspecifieke applicaties, patientcodes ge-hanteerd die niet uniek zijn. Met behulp van deze patientcodes wordenafgenomen onderzoeken geındexeerd. Het terugzoeken van onderzoeken, ge-beurt aan de hand van deze “unieke” sleutel. Hierdoor kan het voorkomendat onderzoeken van patienten verstrengeld raken, en de patienten dezelfde“unieke” patientcode blijken te hebben.

Om dit proces te automatiseren zal er uniform gebruik moeten wordengemaakt van een identificatie nummer per patient. Daarom is het eerst nood-zakelijk dat de codes in de lokale databases vervangen worden door echt unie-ke patientcodes zoals deze in LABOSYS bekend zijn. Deze patientnummersgelden alleen binnen het LabNoord domein. Buiten de organisatie wordtgebruik gemaakt van NAW gegevens in combinatie met geboortedata. In tetoekomst zal hier het burgerservicenummer voor gebruikt worden.

Opzetten en inrichten server

Verder moet een server ter beschikking gesteld worden waarop DODS kandraaien. Een analyse voor de benodigde capaciteit van deze server is te-rug te vinden in bijlage C.3.2. Tevens moeten enkele software pakkettengeınstalleerd worden, zoals deze in bijlage B, de ontwikkelomgeving, be-sproken worden. De server moet binnen het VPN van LabNoord geplaatstworden zodat deze benaderbaar is vanaf zowel de functieafdeling, als despecialisten in het ziekenhuis.

43

8 Evaluatie

Dit hoofdstuk beschrijft de evaluatie van het project. In deze evaluatie wor-den alle punten behandeld die wellicht beter op een andere manier aangepakthadden kunnen worden. Tevens schenken we aandacht aan de punten diewel voor herhaling vatbaar zijn, en waardevol kunnen zijn voor medewerkersbinnen de ICT afdeling van LabNoord.

Het hoofdstuk gaat ten eerste in op de organisatorische aspecten vanhet project, vervolgens op de planning van het project en tenslotte op detoegepaste technieken.

8.1 Organisatie

De toegepaste organisatie van het project heeft over het algemeen goed ge-functioneerd. Omdat de opdracht voor LabNoord zelf nog niet duidelijkwas, is het verstandig geweest te kiezen voor een “agile” ontwikkelmetho-de. De verwachting was namelijk dat de requirements tijdens het projectnog zouden veranderen. Dit gebeurde inderdaad en door middel van dezeontwikkelmethodiek kon daar goed op worden ingespeeld. Een ander voor-deel van “agile” ontwikkelen, is de integratie van testen gedurende het heleproces. Door veel te testen, konden moeilijkheden snel geıdentificeerd enaangepakt worden. Als de modules de testen hebben doorlopen, kan de ge-teste functionaliteit met verlaagde kans op bugs worden aangeboden. Hetgebruik van unittests verhoogt dus de kwaliteit van de code en resulteertdus in een betere oplossing.

Daarnaast kunnen de opdrachtnemers aanraden, gebruik te maken vanhulpfaciliteiten zoals CVS en Wiki. Met behulp van een CVS konden debronbestanden van het project overzichtelijk en makkelijk tussen de ont-wikkelaars gedeeld worden. Zelfs als er bij een project maar een enkeleontwikkelaar betrokken is, is het aan te raden gebruik te maken van eenCVS implementatie. Zo kunnen bijvoorbeeld eerder ontwikkelde modules ineen later stadium door een andere ontwikkelaar binnen LabNoord gebruiktworden voor de realisatie van een andere applicatie. Het gebruik van Wikiis ook aan te raden. Wiki is een softwareapplicatie waarmee webdocumen-ten gezamelijk kunnen worden bewerkt. Wiki is tijdens dit project gebruiktom een logboek bij te houden, de voortgang te bewaken en om overzicht tehouden op de verschillende taken binnen het project.

Tijdens de organisatie van het project is te weinig aandacht besteed aande afhankelijkheden die voor het project van belang waren. Een voorbeeldis het omzetten van de patientcodes in de databases die voor de functieon-derzoeken geraadpleegd worden. Een ander voorbeeld is het plaatsen van deserver op lokatie in het Martini ziekenhuis. Hoewel deze problemen al in eenvroeg stadium gemeld zijn, was het wellicht verstandiger geweest deze voorde betrokkenen uit te werken op papier. Door mondeling deze problemen te

44

bespreken is extra tijd verloren gegaan.

8.2 Planning

De planning die voor de goedkeuring van het project aan LabNoord gepre-senteerd (zie bijlage D.1.3) is, bleek uiteindelijk te optimistisch. In de plan-ning is de gehele realisatie en implementatie opgenomen. De voorgestelderealisatie houdt in dat tenminste twee functieonderzoeken geautomatiseerdzijn en volledig geımplementeerd zijn in het systeem. Uiteindelijk heeft devoorgestelde implementatie geen vorm kunnen krijgen vanwege een gebrekaan tijd.

Tijdens het project zijn diverse requirements toegevoegd, welke extraontwikkeltijd veroorzaakten. Er is te weinig rekening gehouden met de tijddie nodig was om het stageverslag te schrijven. Dit was in zijn geheel nietin de planning opgenomen.

Om toch de werking van de oplossing te bewijzen, een “proof of concept”,is in overleg met de stagebegeleider besloten de projectduur te verlengen.Hierdoor is er alsnog de tijd om een testomgeving op te zetten waarin deapplicatie kan schaduwdraaien. Op deze manier kan de werking van deoplossing gedemonstreerd worden. Tevens kan dan nog aandacht wordenbesteed aan de taken die voltooid moeten worden om het project correct tekunnen overdragen aan de ICT afdeling van LabNoord. Nadat het project isovergedragen, is het de bedoeling dat twee medewerkers van de ICT afdelinghet project zullen voortzetten. De medewerkers zullen de DODS applicatieuitbreiden zodat deze voor alle functieonderzoeken toegepast kan worden.

Om in de toekomst een betere planning te maken, is het verstandig extraruimte open te laten tussen activiteiten. Op deze manier kan de planningbeter gehandhaafd blijven. De opgestelde planning was tamelijk strikt enliet geen ruimte voor vertraging.

8.3 Techniek

De technieken die toegepast zijn voor het realiseren van de DODS applicatie,hebben goed gefunctioneerd. In deze paragraaf zullen verschillende aspectenvan de techniek besproken worden.

8.3.1 Generiek karakter

Er is vanaf het begin rekening gehouden met het generieke karakter vande applicatie. Hierdoor werden de mogelijkheden van de applicatie zeerbreed. Tevens spoort dit generieke karakter de opdrachtnemers aan omde applicatie los te bekijken van de oplossing waarvoor deze specifiek isgerealiseerd. Zo is er naast het gebruik van DODS voor functieonderzoeken,ook de mogelijkheid DODS aan te wenden om andere onderzoeken binnende organisatie te automatiseren.

45

Een van de nadelen van een generieke applicatie, is dat hij voor zoveeldoeleinden toegepast kan worden, dat het makkelijk is van de daadwerkelijkekern van de opdracht af te dwalen. Zodra duidelijk werd wat er mogelijk wasmet DODS, kwamen er veel nieuwe wensen naar voren vanuit de betrokkenenbij het project. Voorbeelden zijn het raadplegen van functieonderzoeksre-sultaten door de huisarts en het automatiseren van de aanvraagformulierenvoor de huisarts. Vanwege de korte duur van het afstudeerproject, was hetrealiseren van deze deelprocessen niet haalbaar. In het gepresenteerde pro-jectplan waren deze zaken dan ook reeds afgedekt.

8.3.2 Platformonafhankelijk

Naast de generiekheid van DODS, is de applicatie geheel platform onafhan-kelijk. Dit is bewerkstelligd door te kiezen voor een server-side applicatiein PHP, die via een webbrowser geraadpleegd kan worden. Door gebruik temaken van een JAVA Applet voor de client-side, is nog een extra dimensieaan het systeem toegevoegd.

Deze platformonafhankelijkheid werd ook nog bewezen door de overzet-ting van de DODS applicatie van de ontwikkelserver naar een testserver.Tijdens de ontwikkeling van DODS is gebruik gemaakt van een WindowsXP systeem met IIS 5.0. Toen in een later stadium van het project deapplicatie overgezet is op een Linux testserver met Apache, bleek dit geenproblemen op te leveren. Binnen een uur was deze overzetting gerealiseerd.Voor de DODS gebruiker is er geen sprake van enig verschil.

8.3.3 SSL

Het beveiligen van de applicatie met SSL bleek relatief makkelijk te reali-seren. Voor het PHP server-side gedeelte was dit met IIS of Apache eenkwestie van het doorlopen van een simpele wizard. Door DODS te koppelenaan een servercertificaat van een CA, was de procedure voltooid.

Door de keuze voor JAVA technologie, waren er legio mogelijkheden voorde client-side kant van DODS. Door middel van een zogenaamde SSLSocketkon er eenvoudig een verbinding gerealiseerd worden met een beveiligdeDODS module.

Uiteindelijk is er besloten, voor extra veiligheid, om ook clientcertificatente gaan gebruiken. Hierbij zal de server zich moeten identificeren bij de clienten visa versa. Om dit zo kostenloos mogelijk te realiseren, zal bij voorkeureen LabNoord CA server ingericht moeten worden.

Voor de ICT afdeling van LabNoord is het verstandig om te kijken naarde veiligheid van elk van de door LabNoord gebruikte applicaties. Zoals inde NEN7510 beschreven staat, is het veilig overzenden van patientgegevenseen van de richtlijnen. Als deze richtlijnen in de toekomst definitief verplichtworden, is het een voordeel dat hier al goed over nagedacht is.

46

8.4 Kennis opleiding

Vanuit de opleiding zijn veel aspecten aan bod gekomen die toegepast kondenworden binnen het project. Zo was er op het gebied van de techniek veeltoepasbare kennis. Hierbij kan gedacht worden aan het ontwerpen van eendatabase, het modelleren van een systeem, gebruikersinteractie visualiserendoormiddel van UML diagrammen en het toepassen van design patterns. Deopleiding gaat goed in op de techniek en het is te merken dat veel gegeventhema’s binnen de opleiding goed aansluiten bij de bedrijfssituatie.

Aan de andere kant waren er wel organisatorische en verslagtechnischeaspecten waar vanuit de opleiding weinig aandacht aan besteed was. Eenhiervan was het opstellen van een analyse voor een klant. Binnen een bedrijfzal er meestal eerst een analyse verricht moeten worden om te achterhalen ofhet zinvol is een bepaald project op te zetten. Hierbij is het heel belangrijkzicht te hebben op de situatie, te kunnen identificeren waar de problemenliggen en mogelijkheden te kunnen aandragen om deze problemen op telossen. Ook is het hierbij belangrijk de klant ervan te kunnen overtuigendat het project de moeite is om uit te gaan voeren.

In de projecten tijdens de opleiding is de analyse meestal gegeven. Erkan gelijk overgegaan worden tot de realisatie van de oplossing voor de klant.Nu is het duidelijk dat dit vanwege een gebrek aan tijd binnen een projectzo wordt aangepakt, maar er zou bijvoorbeeld een apart kwartaal gewijdtkunnen worden aan dit onderwerp. Dit kan in combinatie gedaan wordenmet presentatietechnieken waarbij verschillende projectgroepen een analyseopstellen en deze presenteren aan de klant. Deze kiest dan uiteindelijk vooreen van de partijen. Het zou waardevol zijn om meer van dit soort vakkente kunnen volgen binnen de opleiding. Dit zou bijvoorbeeld aangebodenkunnen worden als keuzethema vanuit Bedrijfskundige Informatica.

De concurrentie binnen het bedrijfsleven is hevig, waarbij er tussen ver-schillende participanten gestreden wordt om een klant. Nu kan het zijn dateen bepaald bedrijf de beste oplossing aandraagt, maar als het niet goed oppapier overgezet kan worden, is de kans klein dat voor deze oplossing geko-zen wordt. Uit ervaring blijkt dat het bedrijf met de beste presentatie deopdracht toegewezen krijgt, ondanks dat het niet de beste oplossing hoeftte zijn voor het probleem.

47

9 Conclusie en aandachtspunten

In de conclusie van dit verslag zal een antwoord gegeven worden op de cen-trale onderzoeksvraag:


Door middel van het behandelen van de drie deelvragen waaruit de pro-bleemstelling is opgebouwd, zal deze in zijn geheel worden beantwoord.Vervolgens zal ook een conclusie met betrekking tot de realisatie wordengegeven en zullen enkele algemene aandachtspunten worden genoemd. Hier-onder zullen de belangrijkste punten kort genoemd worden.

9.1 Waar automatiseren

Uit het onderzoek is gebleken dat de automatisering van een functieonder-zoek in drie varianten realiseerbaar was. Er is gekozen voor de simpelstevariant, waarbij alleen binnen de organistatie van LabNoord het proces ge-automatiseerd is. De twee andere varianten boden ook nog de mogelijkheidvoor huisartsen om de aanvraag, en het raadplegen van de resultaten vaneen functieonderzoek elektronisch te kunnen verrichten. Hiermee zou hetgehele proces van een functieonderzoek geautomatiseerd zijn. Binnen hettijdsbestek van dit project bleek dit niet haalbaar.

Het doorvoeren van procedurele veranderingen binnen een organisatieblijft een lastige zaak, en om ook de huisartsen en specialisten daarbij tebetrekken bleek een te grote opgave. Een deel van de procedure blijft dusvooralsnog met de hand verlopen.

9.2 Hoe automatiseren

Voor deze automatiseringsoplossing is er gekozen voor een applicatie met eengeneriek karakter. DODS is het resultaat van deze opzet. Hierdoor kunnenmet DODS alle functieonderzoeken binnen LabNoord geautomatiseerd wor-den. Maar biedt het ook de mogelijkheid om breder ingezet te worden. Zo iser reeds voor de Diabetesdienst een statisch model voor diabetes patientenin het systeem geımplementeerd, die door huisartsen gebruikt kan wordenom gezondheidsrisico’s te berekenen.

DODS is volledig gerealiseerd met open-source programmatuur, waar-door er geen licentiekosten aan verbonden zijn. Door de platformonafhan-kelijkheid van DODS, is het voor een brede groep gebruikers toegankelijk.DODS bestaat voor het grootste deel uit een server-side applicatie die doorde gebruiker via een webbrowser benaderd kan worden. DODS gebruikt eenbeveiligde verbinding en verstuurd de onderzoeksgegevens via een HTTPS

48

POST methode. Dit houdt in dat ook gebruikers achter een firewall metDODS kunnen werken. Voor het overzenden van deze onderzoeksgegevensis een client-side module gerealiseerd. De client-side applicatie verkrijgt lees-en schrijfmachtigingen en kan op deze manier voor de gebruiker automatischde onderzoeksgegevens koppelen.

9.3 Kosten automatiseren

De kosten die het automatiseringsproject met zich mee hebben gebracht zijnlaag gebleven in vergelijking tot een gemiddeld, soortgelijk project (zie bij-lage D.2). Vooral door het onderzoek en de realisatie van de oplossing uitte besteden aan afstudeerders, zijn de kosten relatief laag gebleven. Door-dat DODS nog niet geımplementeerd is binnen de gestelde projecttermijn,zal DODS waarschijnlijk overgedragen worden aan twee vaste medewerkersvan LabNoord. Deze zullen het product implementeren binnen LabNoorden uitbreiden voor gebruik bij alle functieonderzoeken. Hierdoor zullen dekosten toenemen. Daarnaast zal binnen LabNoord nog een applicatie- ensysteembeheerder aangewezen moeten worden, om de uiteindelijke applicatiete onderhouden.

De investering zal worden terugverdient doordat op de functieafdelingkosten bespaart worden (zie ook paragraaf 6.3). Dit besparen van kostenis tweedelig; enerzijds worden er kosten bespaard omdat het invoeren vanonderzoeken geautomatiseerd wordt, anderzijds worden er kosten bespaardomdat de automatisering overtyp fouten voorkomt.

9.4 Aandachtspunten

Door de bouw van DODS is de technische kant van de oplossing groten-deels gerealiseerd. Het is aan te raden in een vervolgtraject de procedurelekant verder uit te werken. Het advies is om voor de verschillende betrokkenpartijen overeenkomsten vast te leggen in de vorm van Service Level Agree-ments (SLA). Een SLA is een contract tussen een klant en een leverancierover het te leveren niveau en het type service. Aan de hand van een SLA kanworden bijgehouden of een klant ook daadwerkelijk krijgt waar hij voor be-taalt. Omdat dergelijke overeenkomsten door LabNoord niet zijn opgesteld,is het niet mogelijk een maximale doorlooptijd van een functieonderzoekte bepalen. Deze informatie is echter van belang voor zowel de patient alsLabNoord.

De opdrachtnemers dragen hierbij het project over aan het hoofd van deICT afdeling. Wij kunnen het aanbevelen de implementatie van de aange-dragen oplossing voort te zetten. Uiteindelijk zal DODS namelijk kostenbesparen en daarnaast bijdragen aan het verbeteren van de kwaliteit van dedienstverlening.

49

10 Literatuuropgave

Hierin zijn alle bronnen opgenomen die tijdens het maken van dit verslaggeraadpleegd zijn.

Referenties

[1] LabNoord <[email protected]>, “Wie en wat is LabNoord?”, LabNoord -Medisch Centrum, 2005, <http://www.labnoord.nl.> (11 oktober 2005).

[2] Nederhoed, P., Helder Rapporteren, 7e herziene dr., Houten enz., 2000.

[3] Numan, H., Plan van Aanpak: Digitale holteruitslagen, Groningen, ver-sie 0.3.

[4] One Stop Shopping bv. <[email protected]>, “Wat iseen Service Level Agreement”. ICT for your Business, 2005.<http://www.ictforyourbusiness.nl/index.asp?ContentId=1098> (13-12-2005).

[5] Bosch, J., Design & Use of Software Architectures: Adopting and evol-ving a product-line approach, 1e dr., Addison-Wesley., 2000.

[6] Sommerville, I., Software Engineering, 6th edn., Addison-Wesley., 2001.

[7] Schilder, J.,Handleiding afstudeerproject, Groningen, versie oktober2003.

[8] Greving, H.J. en Harris, V., Eindverslag RDS: Remote Diagnostic Sy-stem, Groningen, 2005.

[9] Netcraft <[email protected]>. “October 2005 Web Server Sur-vey”. Netcraft, 2005.<http://news.netcraft.com/archives/2005/10/04/october 2005 web server survey.html> (11-11-2005).

[10] Nederlands Normalisatie-instituut, NEN-EN 12251: Health informatics- Secure User Identification for Health Care - Management and Securityof Authentication by Passwords, Delft, 2004

[11] Nederlands Normalisatie-instituut, Handboek NEN 7510, Delft, versie1.0, 2005

[12] Nederlands Normalisatie-instituut, NEN-NL 7510: Medische informa-tica - Informatiebeveiliging in de zorg - Algemeen, Delft, april 2004

[13] Nederlands Normalisatie-instituut, NEN-NL 7511-1: Medische infor-matica - Informatiebeveiliging in de zorg - Toetsbaar voorschrift bij NEN7510 voor complexe organisaties, Delft, oktober 2005

50

[14] Nederlands Normalisatie-instituut, NEN-NL 7511-2: Medische infor-matica - Informatiebeveiliging in de zorg - Toetsbaar voorschrift bij NEN7510 voor samenwerkingsverbanden, Delft, oktober 2005

[15] Nederlands Normalisatie-instituut, NEN-NL 7511-3: Medische infor-matica - Informatiebeveiliging in de zorg - Toetsbaar voorschrift bij NEN7510 voor solopraktijken, Delft, oktober 2005

[16] Nederlands Normalisatie-instituut, NEN-NL 7512: Medische informa-tica - Informatiebeveiliging in de zorg - Vertrouwensbasis voor gegevens-uitwisseling, Delft, oktober 2005

51


Bijlagen


Datum: 18 januari 2006Instituut: LabNoord HuisartsenlaboratoriumPlaats: Groningen

A Appendix vooronderzoek

A.1 Procedures functieonderzoeken (huidige situatie)

A.1.1 DFD echo onderzoek

Figuur 11: DFD echo onderzoek

1

A.1.2 Procedure echo onderzoek

1. De patient krijgt van de huisarts een LabNoord aanvraagformuliermee, waarop deze de gewenste onderzoeken aankruist.

2. De patient maakt een telefonische afspraak met LabNoord voor eenechoscopie.

3. De patient komt met het aanvraagformulier op het afgesproken tijdstipnaar LabNoord voor het onderzoek.

4. De laborant controleert voor het onderzoek de adresgegevens en degeplande met de aangevraagde onderzoeken. Vervolgens neemt de la-borant met de hand de patientgegevens over in het echoscopie pro-gramma.

5. Het onderzoek wordt afgenomen. Er worden per onderzoek ongeveer12 foto’s gemaakt die alleen afgedrukt worden.

6. Nadat het onderzoek is voltooid, zal de laborant op een zogenaamdewerklijst zijn/haar bevindingen noteren.

7. Dit geheel (aanvraagformulier, foto’s en werklijst), zal per bode naarhet Martini ziekenhuis gebracht worden waar de radioloog een diagnosezal stellen (op werklijst).

8. Het aanvraagformulier, de foto’s en de werklijst met diagnose gaanvervolgens weer per bode terug naar LabNoord.

9. De werklijst wordt handmatig in de LABOSYS database ingevoerdvoor de desbetreffende patient.

10. De uitslag van het onderzoek gaat per post naar de huisarts. Dewerklijst en het aanvraagformulier worden opgenomen in het archiefbij de Functieafdeling.

2

A.1.3 DFD ergo onderzoek

Figuur 12: DFD ergo onderzoek

3

A.1.4 Procedure ergo onderzoek

1. De patient krijgt van de huisarts een LabNoord aanvraagformuliermee, waarop deze de gewenste onderzoeken aankruist.

2. De patient maakt een telefonische afspraak met LabNoord voor eenergometrieonderzoek.

3. De patient komt met het aanvraagformulier op het afgesproken tijdstipnaar LabNoord toe voor het onderzoek.

4. De laborant controleert voor het onderzoek de adresgegevens en degeplande met de aangevraagde onderzoeken. Vervolgens neemt de la-borant met de hand de patientgegevens over in het ergometrie pro-gramma.

5. Eerst wordt een rust ECG afgenomen, daarna een inspannings ECG(op fiets) waarbij ook de bloeddruk gemeten wordt.

6. Nadat het onderzoek is voltooid, zal de laborant de rust- en inspan-nings ECG’s op papier uitprinten (16 bladen).

7. Dit geheel (aanvraagformulier en ECG’s), zal samen met een werk-lijst uit het SchuurSoft systeem, per bode naar het Martini ziekenhuisgebracht worden, waar de cardioloog een diagnose zal stellen (op werk-lijst).

8. Het aanvraagformulier, ECG’s en de werklijst met diagnose gaan ver-volgens weer per bode terug naar LabNoord.

9. De werklijst wordt handmatig in de SchuurSoft database ingevoerdvoor de desbetreffende patient.

10. De uitslag van het onderzoek gaat per post naar de huisarts. Dewerklijst en het aanvraagformulier worden opgenomen in het archiefbij de Functie afdeling.

4

A.1.5 DFD fundus onderzoek

Figuur 13: DFD fundus onderzoek

5

A.1.6 Procedure fundus onderzoek

1. De patient krijgt van de huisarts een LabNoord aanvraagformuliermee, waarop deze de onderzoeken aankruist.

2. De patient maakt een telefonische afspraak met LabNoord voor eenfundus onderzoek.

3. De patient komt met het aanvraagformulier op het afgesproken tijdstipnaar LabNoord voor het onderzoek.

4. De laborant controleert voor het onderzoek de gegevens van de patient.Als er iets niet klopt, zal de laborant dit op de afspraaklijst noteren.

5. De laborant leest vervolgens met een barcode apparaat het labnummeruit (van de afspraaklijst), waarna de patientgegevens automatisch uithet LABOSYS systeem ingevuld worden in de fundus software.

6. Er worden een paar standaard vragen gesteld, waarna de foto’s van deogen genomen worden (twee per oog).

7. Nadat het onderzoek is voltooid, zal de laborant via FTP de foto’sen de bijbehorende gegevens naar een server sturen op het Martiniziekenhuis. De foto’s worden ook op het echo apparaat zelf opgeslagen.

8. De oogarts van het Martini ziekenhuis bekijkt via een web applicatiedeze onderzoeken en stelt de diagnose.

9. De uitslag wordt automatisch opgehaald en aan het LABOSYS sys-teem aangeboden als zogenaamd EDIFACT bericht (een data stan-daard).

10. LABOSYS verwerkt dan automatisch de EDIFACT berichten en plaatstde gegevens in de database.

11. De uitslag van het onderzoek gaat per post naar de huisarts. Het aan-vraagformulier wordt opgenomen in het archief bij de Functie afdeling.

6

A.1.7 DFD bio onderzoek

Figuur 14: DFD bio onderzoek

7

A.1.8 Procedure bio onderzoek

1. De patient krijgt van de huisarts een LabNoord aanvraagformuliermee, waarop deze de gewenst uit te voeren onderzoeken op aankruist.

2. De patient maakt een telefonische afspraak met LabNoord voor eenlong onderzoek.


4. De laborant controleert voor het onderzoek de adresgegevens en degeplande met de aangevraagde onderzoeken. Vervolgens neemt de la-borant met de hand de patient gegevens over in het long programma.

5. Vervolgens wordt het onderzoek afgenomen, waarbij de bevindingengeregistreerd worden.

6. Nadat het onderzoek is voltooid, zal de laborant de uitslagen uitprin-ten.

7. Dit geheel (aanvraagformulier en uitslagen), zal samen met een werk-lijst uit het SchuurSoft systeem, per bode naar het Martini ziekenhuisgebracht worden, waar de longarts een diagnose zal stellen (op werk-lijst).

8. Het aanvraagformulier, uitslagen en de werklijst met diagnose gaanvervolgens weer per bode terug naar LabNoord.

9. De werklijst wordt handmatig in de SchuurSoft database ingevoerdvoor de desbetreffende patient.


8

A.1.9 DFD dexa onderzoek

Figuur 15: DFD dexa onderzoek

9

A.1.10 Procedure dexa onderzoek

1. De patient krijgt van de huisarts een LabNoord aanvraagformuliermee, waarop deze de gewenst uit te voeren onderzoeken op aankruist.

2. De patient maakt een telefonische afspraak met LabNoord voor eenDEXA onderzoek.


4. De laborant controleert voor het onderzoek de adresgegevens en degeplande met de aangevraagde onderzoeken. Vervolgens neemt de la-borant met de hand de patient gegevens over in het DEXA programma.Waar mogelijk haalt de laborant eerdere DEXA onderzoeken erbij uithet archief.

5. Vervolgens worden de benodigde rontgen foto’s genomen.

6. Nadat het onderzoek is voltooid, zal de laborant de foto’s uitprinten.Ook worden de foto’s opgeslagen op de lokale database van het rontgenapparaat.

7. Dit geheel (aanvraagformulier, foto’s en oude onderzoeken), zullen sa-men met een werklijst uit het LABOSYS systeem, per bode naar hetMartini ziekenhuis gebracht worden, waar de radioloog een diagnosezal stellen (op werklijst).

8. Het aanvraagformulier, foto’s, oude onderzoeken en de werklijst metdiagnose gaan vervolgens weer per bode weer terug naar LabNoord.

9. Dit geheel (aanvraagformulier, foto’s en oude onderzoeken, radioloogingevulde werklijst), zal per bode naar het Martini ziekenhuis gebrachtworden, waar de internist een diagnose zal stellen (op werklijst).

10. Het aanvraagformulier, foto’s, oude onderzoeken en de werklijst metcomplete diagnose gaan vervolgens weer per bode weer terug naarLabNoord.

11. De werklijst wordt handmatig in de LABOSYS database ingevoerdvoor de desbetreffende patient.


10

A.2 Opdrachtomschrijving

OMSCHRIJVING CORE BUSSINESElektronisch berichtenverkeer/medisch laboratorium

OMSCHRIJVING KONTEKST OPDRACHTOp dit moment worden door specialisten (Radiologen) onderzoeken beoordeeld voor Lab-Noord (echo beelden). Deze beoordeling wordt op dit moment uitgevoerd doormiddel vanpapieren aanvragen van onderzoek, printjes van foto’s en werklijsten (lijst waarop de dia-gnose kan worden ingevuld). Een bode brengt de onderzoeksresultaten naar de specialistin het Martini Ziekenhuis die vervolgens het onderzoek op papier evalueert. Dit papierwordt per bode weer aan LabNoord geleverd waar vervolgens op het Functielab de resul-taten in een oude ’Schuursoft’ applicatie worden ingetypt. Daarna wordt een papierenuitdraai naar de huisarts gestuurd. Er is op dit moment behoefte aan een applicatie diede resultaten van de onderzoeken kan tonen en waarbij de specialisten de beoordeling vanhet onderzoek kunnen invoeren. De resultaten zullen in de door het LabNoord gebruiktecache database worden geplaatst, waardoor vervolgens het resultaat in EDI formaat naarde huisarts kan worden gestuurd of kan worden uitgeprint (de mogelijkheid van elektroni-sche rapportage is reeds gemplementeerd).

OMSCHRIJVING STAGE OPDRACHTBouw een generieke applicatie die via een webbrowser via een VPN verbinding de resulta-ten van onderzoeken kan tonen en waarbij de specialist de beoordeling in kan typen. Houdtrekening met gebruikersgemak van de applicatie. Er kan gebruik worden gemaakt van eenapplicatie die een vergelijkbaar proces ondersteunt voor fundusfotografie. Bij de ontwik-keling van de applicatie dient expliciet het generieke karakter van de te bouwen applicatiete worden benadrukt zoals schaalgrootte en bestandsgrootte. Naast het ontwikkelen vande applicatie is het van belang dat de afstudeerders een advies opstellen omtrent hardwareen netwerkeisen. Hierbij dient aandacht te worden besteed aan onderwerpen zoals net-werkcapaciteit en opslagcapaciteit in relatie met bestandsgrootte, bestaande netwerken enaansluitingen etc.

GEVRAAGDE BELANGSTELLING / AANDACHTSGEBIEDENDeze opdracht is uitgebreider dan alleen een programmeer opdracht. Omdat nog nietgeheel duidelijk is hoe de applicatie precies zal moeten gaan werken (Dicom of JPEGformaat) zal grote nadruk komen te liggen op de analyse vaardigheden van de stagiairs.Dezen zullen intensief moeten analyseren wat de behoefte is van de gebruikers en zullenuitspraken moeten doen over programmeertalen en databases die gebruikt moeten wor-den. Vervolgens zullen de stagiairs goede conceptuele analytische vaardigheden dienente bezitten om de relatie te kunnen leggen tussen organisatie, proces en programmatuur,maar ook in staat dienen te zijn om de applicatie tot in detail te programmeren. Alslaatste dienen de stagiairs zich goed in te kunnen leven in de eindgebruiker zodat demens-computer component goed wordt uitgewerkt en er een gebruikersvriendelijke inter-face wordt gebouwd.

GEVRAAGDE PERSOONLIJKE EIGENSCHAPPENGoede conceptuele, analytische en contactuele vaardigheden.

11

B Appendix ontwikkelomgeving

In dit hoofdstuk zullen de verschillende onderdelen van de ontwikkelom-geving uitgediept worden. Hier zal onder andere behandeld worden welkeontwikkelmethode en ontwikkeltools er beschikbaar zijn en wat de voor- ennadelen daar van zijn ten opzichte van de randvoorwaarden van het project.Ook zal er naast de hard- en software eisen van de omgevingen naar delicentiemodellen en de eventuele kosten worden gekeken.

Gezien de applicatie zich zal bevinden in een productieomgeving en ervertrouwelijke patient gegevens worden weergegeven en opgeslagen is het vanbelang dat in deze omgeving veiligheid, betrouwbaarheid en beschikbaarheidvoorop staan. Hiernaast moet de omgeving makkelijk aan te passen zijn,aangezien er in de toekomst nieuwe onderzoeken kunnen bijkomen of huidigeonderzoeken veranderen van methodiek of apparatuur. Tevens is er de eisdat de omgeving makkelijk moet zijn te beheren. In paragraaf 4.2 is te lezendat de volumes nu en in de toekomst relatief laag zijn, hierdoor is hogeschaalbaarheid niet direct een vereiste maar wel een pre.

B.1 Ontwikkelmethode

Een ontwikkelmethode bepaalt hoe, wat en op welke manier je op welk mo-ment gaat ontwikkelen dan wel testen of herontwerpen. In het hier volgendegedeelte zullen enkele ontwikkelmethodes worden behandeld.

B.1.1 Waterfall

Waterfall is een software ontwikkelmodel waarin het ontwikkelproces gezienkan worden als een stroom voor de verschillende stadia namelijk: ontwikkel-stadia, requirements analysis, design, implementation, testing (validation),integration, en maintenance. De term is geintroduceerd door W. W. Roycein 1970, een grote voorstander van iterative ontwikkelprocessen.

B.1.2 RUP

RUP, Rational Unified Processis een iteratief software development procesontworpen door de Rational Software Corporation, tegenwoordig een divisievan IBM. RUP beschrijft manieren om effectief software te ontwikkelen doorgebruik te maken van bewezen methodes. Hierbij worden methoden gezochtdie goed passen bij het project en het bedrijf. RUP wordt veel toegepast bijgrote bedrijven met grote ontwikkelteams die tegelijkertijd meerdere groteprojecten uitvoeren.

12

B.1.3 Agile

Extreme programming is een moderne manier van het inrichten, plannen enuitvoeren van software ontwikkelingstrajecten. Het uitgangspunt van XPis dat de eisen ten aanzien van software in de loop der tijd zullen wijzigenten gevolge van wijzigende inzichten bij zowel opdrachtgever als opdracht-nemer. XP is erop gericht het risico van wijzigende eisen te minimaliseren.Technieken die onder andere worden gebruikt zijn:

• Regelmatige en open communicatie binnen het team en daarbuiten.

• Werken met korte cycli.

• Kennis delen met hele team(geen key-developers).

• Veel testen.

• Per tweetal ontwikkelen.

B.1.4 Keuze

Bij de aanvang van het project zijn nog niet al de randvoorwaarden geheelvastgelegd. Om hier rekening mee te houden en er snel op in te kunnenspringen is gekozen voor een Agile ontwikkel methode.

B.2 Programeeromgeving

In hoofdstuk 3 is te lezen dat vanuit LabNoord besloten is om een webap-plicatie te realiseren. Deze applicatie moet functioneren en beheerd wordenbinnen de LabNoord omgeving, door LabNoord ICT personeel.

Er zal een combinatie moeten worden gezocht van een serverside webap-plicatie met een clientside applicatie welke toegang heeft tot de gebruikerzijn PC, om van die PC onderzoeksgegevens te verzamelen en te versturennaar de server. Alleen gebruikers die onderzoeksgegevens toevoegen hebbente maken met de clientside applicatie.

Binnen LabNoord maakt men gebruik van de volgende technieken om we-bapplicaties te maken en te onderhouden.

• ASP.NET

• Perl

• PHP

13

B.2.1 Serverside omgevingen

In het hier volgende gedeelte zullen in het kort de serverside programmeer-omgevigen worden behandeld.

ASP.NET

Active Server Pages .NET (ASP.NET) is een verzameling van ontwikkeltechnologien ontwikkeld door Microsoft. Het kan worden gebruikt voor dy-namische websites en XML webservices. ASP.NET is onderdeel van Mi-crosoft’s .NET platform. Ook al is de naam hetzelfde als de oude web de-velopment technologie, Active Server Pages (ASP) technologie, zijn er tweebelangrijke verschillen. Microsoft heeft ASP.NET helemaal opnieuw opge-trokken, gebaseerd op Common Language Runtime (CLR) welke al de .NETtalen ondersteunen. Programmeurs kunnen ASP.NET code schrijven doorgebruik te maken van een van de door het .NET framework ondersteundetalen. Zoals Visual Basic.NET, JScript.NET, of (standardized) C#. Daar-naast kunnen deze ook gebruik maken van een open-source taal als Perl enPython. Een voordeel ten opzichte van script talen is dat ASP.NET gecom-pileerd wordt naar een of meer DLL’s wat de prestaties ten goede komt.

Perl

Practical Extraction and Reporting Language (Perl) is een open-sourcegeneral-purpose programmeeromgeving origineel ontwikkeld voor tekst ma-nipulatie. Tegenwoordig wordt Perl voor een grote verscheidenheid van ta-ken gebruikt zoals systeemtools, web development, network programmingen vele andere. De opzet van de taal is hoofdzakelijk gericht om praktisch(efficient en gemakkelijk in het gebruik) te zijn in plaats van mooi (klein,elegant en minimalistisch). Belangrijke features zijn dat het geen grote pro-grammeer kennis vereist om mee te beginnen. Men kan zowel procedureelen objectgeorienteerd programmeren, biedt krachtige interne support voortext processing en beschikt over een erg grote database met modules vanderde partijen.

PHP

PHP Hypertext Preprocessor (PHP) is een open-source, reflective programeer-taal. PHP wordt hoofdzakelijk gebruikt voor server-side applicaties en dy-namische web content. De taal is de laatste jaren enorm populair gewordenen wordt door de meeste hosting bedrijven standaard beschikbaar gesteldals webscript taal.

14

B.2.2 Licenties

De verschillende programmeeromgevingen hebben elk een ander licentie mo-del wat kosten en eventueel distributieproblemen met zich mee kan brengen.In het hier volgende gedeelte zullen de licentiemodellen kort worden behan-deld.

ASP.NET

Microsoft APS.NET word uitgebracht onder de “Microsoft .NET FrameworkRedistributable EULA” licentie. Microsoft biedt een versie van het .NETframework aan voor UNIX omgevingen onder de naam “Shared source CLI”,maar verbiedt expliciet het gebruik van dit pakket voor commerciele doelein-den. Mono is een open-source project, opgezet door Ximian (tegenwoordigNovell), om een .NET omgeving te maken die aan de ECMA standaard vol-doet. Mono bied onder andere een C# compiler en een Common LanguageRuntime. Mono draait op GNU/LINUX, UNIX, OS X en Microsoft Win-dows, en bied volledige ondersteuning voor ASP.NET 1.0 en 1.1. Er zijnveel discussies over Mono omtrent de licenties, men is er niet over uit ofMicrosoft, als ze dat wil, Mono kan verbieden doordat Mono gebruik maaktvan door Microsoft gepatenteerde ideeen.

Perl

Perl wordt uitgebracht onder de “The Artistic License” licentie. Dit houdin dat je Perl gratis mag gebruiken en distribueren.

PHP

PHP valt onder de “PHP License version 3.0” Dit houdt in dat je PHPgratis mag gebruiken en distribueren. Producten afgeleid of gebaseerd opPHP mogen niet zomaar de naam PHP gebruiken.

B.2.3 Kosten

De directe en indirecte kosten van de programmeeromgevingen zullen in hetvolgende gedeelte worden behandeld.

ASP.NET

Voor het gebruik van ASP.NET is een licentie op het .NET framework nodigen een licentie voor het OS. Of er kan gebruik worden gemaakt van Mono,met de mogelijkheid dat er in de toekomst moeilijkheden met licenties kun-nen voorkomen.

15

Perl

Perl is FLOSS2, dus zijn er geen extra kosten aan verbonden.

PHP

Ook PHP is FLOSS1, ook hier zijn geen extra kosten aan verbonden.

B.2.4 Clientside

Een webapplicatie is server-side, alleen gezien het feit dat er gegevens moe-ten worden verzonden vanaf de gebruiker kant zonder dat de gebruiker hiereen actie voor hoeft te ondernemen, is er ook een clientside applicatie nodig.Deze applicatie zal aan de hand van de opgegeven opdrachten van de server,onderzoeksgegevens moeten zoeken, verwerken en versturen naar de server.Gezien de structuur van het server-side aanbieden, is er de wens dat dezeclientside applicatie ook “gepushed” kan worden richting de gebruiker. Hier-door kan elke willekeurige PC onderzoeken afnemen. Voor deze doeleindenzijn de volgende omgevingen geschikt:

• Java Applet

• ActiveX

Deze omgevingen zullen kort worden behandeld.

Java Applet

Een Java Applet is een embedded Java programma voor internet browsersen werd geıntroduceerd in 1995 door Sun. Java Applets worden ondersteunddoor vrijwel elke browser, mits er op de client een JRE is geınstalleerd. Ap-plets draaien doorgaans in een ‘sandbox’ binnen een browser, door gebruikte maken van een certificaat kan de Applet meer toegang tot het systeemverschaffen.

ActiveX

ActiveX, vroeger OLE, is een technologie van Microsoft, gemaakt ten behoe-ve van de communicatie tussen verschillende componenten. ActiveX, alleenbeschikbaar voor Internet Explorer, heeft, als de gebruiker accepteert omhet component te gebruiken, volledige toegang tot de gebruiker zijn sys-teem. Deze technologie wordt door veel beveiligingsexperts als een van degrootste veiligheid problemen binnen Internet Explorer gezien.

2Free/Libre and Open Source Software

16

Vergelijking

ActiveX biedt veel mogelijkheden binnen een vastgelegde omgeving; een Mi-crosoft Windows omgeving in combinatie met Internet Explorer. Wijkt deomgeving hiervan af is het niet meer te gebruiken. Een Java Applet daaren-tegen is cross-platform, en biedt toegangsrestricties dankzij het gebruik vancertificaten wat het gebruik veiliger kan maken.

B.2.5 Advies

Hieronder volgt het advies voor de programmeeromgeving. Zowel de server-side als de clientside zal worden behandeld.

Serverside

Zowel ASP.NET als Perl en PHP zijn geschikt voor de serverside applicatie.Een belangrijk verschil is dat ASP.NET extra kosten met zich mee brengt.Aangezien de opdrachtnemers al ruime ervaring hebben met PHP en deprojectduur maar 19 weken is, komt het de snelheid ten goede om te ont-wikkelen in een bekende omgeving. Bij de ICT medewerkers van LabNoord,welke in de toekomst de applicatie gaan beheren, is er hoofdzakelijk PHPkennis aanwezig. Hierdoor gaat dan ook de voorkeur uit naar het gebruikvan PHP.

Client-side

In tegenstelling tot ActiveX is een Java Applet cross-platform, gratis ommee te ontwikkelen en te gebruiken, en biedt Java veel extra mogelijkhedenvoor beveiliging. De voorkeur gaat dan ook uit naar het gebruik van eenJava Applet als client-side omgeving.

B.3 Webserver

Omdat er vanuit LabNoord is gekozen om een server-side webapplicatie terealiseren(zie hoofdstuk 3 en logische gevolgtrekking paragraaf B.2), is hetgebruik van een webserver voor de server-side webapplicatie nodig. De vol-gende webservers zullen hier worden behandeld:

• Microsoft Internet Information Services

• Apache

B.3.1 Internet Information Services

Microsoft Internet Information Services (IIS) is een verzameling internet-gebaseerde diensten voor op het Microsoft platform. In oktober 2005 had

17

IIS een marktaandeel van 20.55% [9] en is daarmee de op een na populairstewebserver.

In het verleden was IIS regelmatig het slachtoffer van wormen, zoals de‘Code Red worm’ en andere zogenaamde exploits. Tot versie 6 draaide IISonder een systeem account, wat een mogelijke exploit alle rechten op hetsysteem geeft. Veel van deze problemen zijn opgelost in versie 6.0 van dewebserver. IIS valt onder de “Microsoft EULA”.

B.3.2 Apache

Apache HTTP Server is een gratis open-source HTTP webserver voor UNIX,GNU/LINUX, Microsoft Windows, Novell Netware en nog veel meer plat-formen. Apache was in het begin gebaseerd op de NCSA HTTPd 1.3 uit1994. Versie 2 van Apache is geheel opnieuw geschreven en bezit geen ori-ginele code meer van de NCSA. In oktober 2005 werd 69.89% [9] van deinternet sites geserved door Apache, wat Apache de absolute marktleider opde webservermarkt maakt. Apache valt onder de “Apache License, Version2.0” licentie.

Apache bied een breed scala aan mogelijkheden en is goed configureer-baar. Daarnaast is er een grote hoeveelheid aan modules beschikbaar die defunctionaliteit van Apache nog verder kunnen vergroten. Binnen LabNoordwordt er gebruik gemaakt van Apache 2.0.55.

B.3.3 Advies

Als er wordt gekeken naar de nieuwste versies, bieden de HTTP serversbeide de vereiste functionaliteit voor de webapplicatie. Ze ondersteunende programmeeromgevingen en bieden SSL functionaliteit. Als er wordtgekeken naar het veiligheidsaspect, heeft Apache een betere reputatie. Sindsversie 6.0 heeft IIS hier wat aan kunnen bijspijkeren maar de beveiliging blijftvoornamelijk de verantwoordelijkheid van de systeembeheerders. Als dezegroep de systemen goed onderhoudt en update, moeten zowel IIS als Apachekunnen voldoen aan de eisen. Op het punt van licenties heeft Apache eengroot voordeel, het is geheel gratis tegenover de kosten van een MicrosoftWindows 2003 licentie. Daarnaast is Apache ook nog eens cross-platform.Gezien deze argumenten gaat de voorkeur uit naar een Apache omgeving.

B.4 Database

Databases maken het gemakkelijk gegevens op te slaan en deze gegevenslater weer terug te halen aan de hand van een van de eigenschappen welkeeerder zijn gedefinieerd. LabNoord beschikt over twee database omgevingenwelke ze zelf beheren en kunnen onderhouden, deze zijn:

• MySQL

18

• Cache

B.4.1 MySQL

MySQL is een open-source multi-threaded, multi-user, Structured QueryLanguage (SQL) Database Management System(DBMS). Bij LabNoord wordter gebruik gemaakt van MySQL 4.1. MySQL dankt veel van de geavanceer-de database functionaliteit aan het gebruik van de InnoDB database engine.MySQL wordt uitgebracht onder de “GNU General Public License” (GPL)licentie, maar er zijn ook licentie modellen beschikbaar voor als het productniet compatible is met de GPL licentie. Begin oktober 2005 heeft Oracle In-nobase gekocht, het bedrijf achter de InnoDB technologie. MySQL zal in detoekomst een fork uitbrengen van de huidige InnoDB code welke ook onderGPL is uitgebracht. MySQL is enorm populair geworden dankzij de com-binatie van MySQL met PHP, dat door veel hosting bedrijven aangebodenwordt.

B.4.2 Cache

Cache is een database management systeem van InterSystems, gebaseerd opMassachusetts general hospital Utility Multi-Programming System (MUMPS)technologie. InterSystems noemt Cache een postrelationele database, hier-mee wordt gedoeld op SQL, Object en hierarchische toegang op dezelfdegegevens. Er zijn versies van Cache beschikbaar voor Microsoft Windows,UNIX, Mac OS X en OpenVMS platformen. Binnen LabNoord wordt Cachegebruikt door LABOSYS. Licenties voor Cache worden verkocht per vijf,voor e 370 per maand exclusief BTW. Daarnaast is men verplicht om ereen onderhoudscontract bij te kopen, dit kost op jaarbasis 22% van de aan-schafprijs. Per licentie wordt dit dan het eerste jaar een aanschaf prijs vane 4440 plus e 976,80 aan onderhoudskosten.

B.4.3 Advies

Het product zal gerealiseerd worden op een nog in te richten demilitarizedzone (DMZ). Vanaf deze DMZ is er geen toegang tot de Cache databaseservers van LabNoord. MySQL daarentegen kan binnen de DMZ draaien,de keuze voor MySQL is hierdoor ook makkelijk gemaakt. Er zijn ande-re RDBMS’en welke misschien beter geschikt zijn om toegepast te wordenbinnen deze omgeving. Hierbij kan bijvoorbeeld gedacht worden aan Post-greSQL, deze biedt functionaliteit die binnen een professionele omgeving inde gebruikte versie van MySQL niet beschikbaar zijn.

19

B.5 Beveiliging

Beveiliging is een belangrijk onderdeel waar voor de bouw van de webap-plicatie rekening mee gehouden dient te worden. Er worden vertrouwelijkepatientgegevens over het internet verzonden. Het is naıef om te denkendat een systeem 100% veilig kan zijn, maar er zijn een hoop maatrege-len die genomen kunnen worden, welke het erg onaantrekkelijk maken vooreen eventuele inbreker, om te proberen informatie te ontvreemden. In desubparagrafen die volgen zal er dieper ingegaan worden op deze mogelijkemaatregelen.

B.5.1 Cryptografie

Cryptografie houdt zich bezig met het versleutelen van informatie om tevoorkomen dat deze informatie in handen komt van een derde partij. In decryptografie wordt encryptie gebruikt om informatie te versleutelen (enco-deren), gebaseerd op een bepaald algoritme. Encryptie over het internet isin te delen in symmetrisch en asymmetrisch. Symmetrische encryptie maaktgebruik van een zogenaamde geheime sleutel. Deze geheime sleutel is alleenbekend bij de verzender en de ontvanger, en wordt gebruikt om de informa-tie te coderen en weer te decoderen. Het nadeel van dit type encryptie isdat de sleutel op een of andere manier eerst veilig uitgewisseld moet wordentussen de ontvanger en verzender. Daarnaast is het zo dat als de sleuteleenmaal onderschept is, alle verzonden data vanaf dat moment ontcijferdkan worden.

Een andere manier van encryptie, is asymmetrische encryptie. Asym-metrische encryptie maakt naast het gebruik van een geheime sleutel, ookgebruik van een publieke sleutel. Als twee partijen informatie naar elkaarwillen verzenden, zal de ontvanger eerst aan de hand van een geheime sleu-tel, een publieke sleutel genereren. Deze publieke sleutel is gerelateerd aande geheime sleutel en kan door de verzender gebruikt worden om de infor-matie te versleutelen. Deze publieke sleutel wordt dan vervolgens naar deverzender verstuurd. De verzender versleutelt dan de informatie met behulpvan de publieke sleutel van de ontvanger en verstuurt dan de data terug.De ontvanger kan dan met behulp van zijn geheime sleutel de data weerontcijferen. Zie figuur 16 voor een schematische weergave van asymmetri-sche encryptie. Omdat de geheime sleutel nooit mee verzonden wordt, is heterg moeilijk voor een derde partij de verzonden data terug te voeren naarde oorspronkelijke informatie. Daarnaast kan er voor elke transmissie eennieuw sleutelpaar gegenereerd worden. Hiermee wordt het voor een even-tuele kraker een buitengewoon onrendabele zaak. Nauurlijk is de encryptieuiteindelijk nog wel te doorbreken met de zogenaamde “brute force” me-thode, alleen duurt dit erg lang. Indien er een krachtig encryptie algoritmegehanteerd wordt met een grote sleutel, is de kans dat een ongewenste partij

20

bruikbare informatie ontvreemd buitengewoon klein.

Figuur 16: Schematische weergave asymmetrische encryptie.

B.5.2 Firewall

Binnen het gehele netwerk van LabNoord wordt er gebruik gemaakt vanmeerdere firewalls. Al het verkeer dat plaats vindt tussen LabNoord enhet internet, gaat via deze firewalls. Deze beveiliging dient om inbraken opLabNoord systemen te voorkomen.

B.5.3 Autorisatie

Om te voorkomen dat iedereen toegang kan krijgen tot de te realiserenwebapplicatie, is het nodig om gebruik te maken van autorisatie. Iederegebruiker die zichzelf toegang tot het systeem wil verschaffen, zal zich daneerst moeten identificeren. Dit gaat door middel van een gebruikersnaammet wachtwoord.

Voor de opslag van wachtwoorden in de op te zetten gebruikersdatabase,is het van belang in acht te nemen dat het veel gebruikte MD5 hash algoritme

21

recentelijk gekraakt is. Het hashen van wachtwoorden door middel van MD5wordt dan ook ten strengste afgeraden. In plaats daarvan zou bijvoorbeeldgebruik gemaakt kunnen worden van SHA-256 hashing.

B.5.4 SSL

Voor het beveiligen van de gehele applicatie, kan gebruik worden gemaaktvan SSL (Secure Socket Layer). SSL is een encryptie protocol voor het be-veiligen van webcommunicatie over het internet. SSL wordt door de meestewebservers ondersteunt, en kan daardoor gemakkelijk geımplementeerd wor-den. SSL maakt gebruik van asymmetrische encryptie zoals het hierbovenreeds behandeld is (zie paragraaf B.5.1). Door middel van certificaten, wel-ke uitgegeven worden door derde partijen, kan de identiteit van de servergeverifieerd worden. Deze derde partij, bijvoorbeeld Thawte of VeriSign,waarborgt de authenticiteit van het certificaat in kwestie. Nadat de iden-titeit van de server is bevestigd, worden er publieke sleutels naar elkaarverzonden. Vanaf dat moment zal alle communicatie tussen de browser ende server versleuteld plaats vinden.

B.5.5 Advies

Het kan aangeraden worden de gehele webapplicatie met SSL te beveiligen.Gezien het een algemeen geaccepteerde standaard is en het erg gemakkelijktoe te passen is. Omdat SSL gebruik maakt van asymmetrische encryptie,is het relatief veilig om toegepast te worden over het internet. Wel wordtaangeraden de benodigde server certificaten aan te schaffen via een Certifi-cate Authority (CA). Ondanks dat certificaten ook zelf aangemaakt kunnenworden, zijn deze minder makkelijk in het gebruik, omdat er per gebruikerde browser instellingen aangepast moeten worden om de eigen CA als be-trouwbaar aan te merken. Een AES 128-bits certificaat met een geldigheidvan 1 jaar is verkrijgbaar voor ongeveer 100 dollar.

Daarnaast is het aan te raden naast de server identificatie, ook gebruikte maken van gebruiker identificatie. Dit door middel van het uitgeven vancertificaten voor de gebruiker. Ook zal er nog gebruiker identificatie toege-past moeten worden door middel van het gebruik van een gebruikersnaamen wachtwoord. Ook een firewall is een goede maatregel om inbrekers te we-ren, en gezien deze reeds aanwezig is bij LabNoord, hoeven hier geen extrainvesteringen gemaakt te worden.

B.6 Kwaliteitsbewaking

Belangrijke elementen van een incrementele ontwikkelmethode zijn de korteontwikkelcycli en het testen van elke increment. Speciaal hiervoor moet ereen degelijke testopstelling worden gemaakt waarbij het gemakkelijk is omsnel en correct het (tussen) product te kunnen testen.

22

B.6.1 Java

JUnit is een unit testing framework voor Java, gemaakt door Kent Beck endErich Gamma. JUnit is de meest gebruikte Unit test omgeving voor Java enis erg uitgebreid. JUnit is geport voor andere omgevingen zoals C# (NUnit)en C++ (CppUnit), deze familie van unit test frameworks wordt ook wel dexUnit genoemd.

B.6.2 PHP

Voor PHP zijn er talrijke unit test omgevingen, helaas wordt er maar eenenkele onderhouden en bieden nog minder goede ondersteuning voor PHP 5.Vrijwel elke PHP unit test is gebaseerd op JUnit en heeft dezelfde werkstijl.

SimpleTest

SimpleTest is een unit test framework voor PHP, welke ook support biedvoor PHP 5. SimpleTest is goed gedocumenteerd, biedt veel mogelijkhedenen het wordt goed en regelmatig onderhouden.

PhpUnit

PhpUnit was een populair unit test framework, geschreven voor PHP 3 in2000, en bied sinds het van dat jaar ook PHP 4 support. PHP 5 support isaanwezig.

B.6.3 Advies

Voor Java wordt geadviseerd om JUnit te gebruiken, deze bied uitsteken-de integratie en veel mogelijkheden. Daarnaast is het gratis te gebruiken.Voor PHP bied SimpleTest veel mogelijkheden en wordt goed onderhouden.Daarnaast biedt het goede ondersteuning voor PHP 5 en is het geheel gratiste gebruiken. Het advies gaat uit voor het gebruiken van een combinatievan bovengenoemde omgevingen.

B.7 Versiebeheer

Een gestructureerde ontwikkelomgeving maakt gebruik van versiebeheer, ze-ker als er meerdere mensen aan hetzelfde project werken. Versiebeheer zorgter niet alleen voor dat er makkelijk meer dan een persoon tegelijk aan het-zelfde onderdeel kan werken, maar ook voor een duidelijker beeld van wateen ander doet. Zo bieden versiebeheeromgevingen de mogelijkheid om com-mentaar te geven bij de verandering die de ontwikkelaar heeft doorgevoerd.

23

Ook biedt het de mogelijkheid om terug te gaan in de tijd en eerdere ver-sies van de programmatuur te bekijken en te vergelijken met de huidige ofwillekeurige ander versie van het programma.

Er zal hier worden gekeken naar de twee meest gebruikte beheermetho-des, namelijk CVS en SVN omdat beide versiebeheermethodes veel wordentoegepast, beschikbaar zijn voor ons ontwikkel platform en er handige plug-ins beschikbaar zijn voor onwikkeltools die het beheren en gebruik makke-lijker en overzichtelijker maken.

B.7.1 CVS

Concurrent Versions System (CVS), sinds 1986 beschikbaar voor iedereen,is een versiebeheermethode die werkt via een client-server architectuur. Deserver bewaart de huidige versie en al de voorgaande versies. Een client haalteen versie op, voert mutaties uit en stuurt deze later weer terug. Als ditgoed gaat wordt het versienummer van de bestanden automatisch verhoogten wordt de gebruikersnaam en zijn commentaar opgeslagen. Mocht hetfout gaan, als bijvoorbeeld iemand anders al eerder hetzelfde gedeelte vande file heeft aangepast, moet de gebruiker eerst handmatig het verschil goedzetten voor deze ‘gecommit’ kan worden.

De CVS methode is niet altijd handig, zo is het niet mogelijk om een be-stand in een CVS repository te hernoemen. Dit bestand zal moeten wordenverwijdert en opnieuw moeten worden toegevoegd onder de nieuwe naam.Daarnaast mist CVS enkele functionaliteit die ontwikkelaars van tegenwoor-dig wel eisen, zoals de support voor Unicode en niet ASCII bestandsnamen.Een groep ontevreden CVS gebruikers is begonnen aan een vervanging vanCVS genaamd CVSNT waarvan de eerste versie in 1999 uitkwam voor hetWindows platform en in 2002 beschikbaar was voor GNU/LINUX en UNIXomgevingen.

B.7.2 SVN

Een aantal belangrijke ontwikkelaars van CVS zijn verantwoordelijk voorSubversion (SVN), waarvan de eerste versie in 2004 uitkwam. SVN heeft alsdoel de vervanging te zijn van CVS door alle functionaliteit van CVS aan tebieden en in te springen op de wensen van de ontwikkelaars.

B.7.3 Advies

CVSNT of Subversion hebben beide hun voor- en nadelen, deze problemenzijn hoofdzakelijk aanwezig bij grote projecten waar niet elke ontwikkelaarroot toegang heeft op de repository. Dit is in dit project niet direct vanbelang, het gaat hier om een relatief klein project en de ontwikkelaars hebbenvolledige toegang. Gezien de opdrachtnemers ervaring hebben met CVS

24

is dat het belangrijkste argument om de voorkeur te laten uitgaan naarCVSNT.

B.8 Documentatie

Documentatie is cruciaal voor het onderhouden, doorontwikkelen en over-erven van een project. Daarnaast maakt het goed documenteren van eenprogramma het overzichtelijk en is het voor derden makkelijker te begrijpen.Voor zowel PHP als Java zijn er door de loop der jaren veel documentatieprojecten gestart, elk met voor- en nadelen. In dit hoofdstuk zullen de ver-scheidene documentatie generators behandeld worden aan de hand van deomgeving waarin ze zullen worden gebruikt.

B.8.1 PHP

Voor PHP zijn er veel documentatie projecten die op dit moment niet meerworden onderhouden. Dit betekent dat ze nieuwe eigenschappen en functiesvan PHP niet goed ondersteunen. De support van deze documentatie projec-ten is vooral een probleem geworden sinds de uitgave van PHP 5, waarin detaal grondig is geherstructureerd. De twee grootste PHP documentatie ge-nerators, namelijk phpdocumentator, een documentatie project van PEAR(laatste versie april 2004) en phpdoc (laatste versie december 2000) werkendan ook niet meer 100%, wat het nut van de documentatie ondermijnt.

De enige documentatie generator welke de nieuwste versies van PHPondersteunt en goed configureerbaar is, is Doxygen. Doxygen is een do-cumentatie generator voor C++, C, C#, Java, Objective-C, Python, IDL,PHP en D. Het is beschikbaar voor zowel UNIX systemen als Windows enMac OS X. De eerste publieke versie kwam uit in oktober 1997 en is nunaast JavaDoc een van de meest gebruikte documentatie generators.

B.8.2 Java

Voor Java documentatie zijn er maar twee producten welke de benodigdekwaliteit en mogelijkheden bieden die nodig zijn binnen dit project. Ditzijn Javadoc en Doxygen, beide worden goed onderhouden en bieden veelmogelijkheden.

B.8.3 Advies

Voor het documenteren van de PHP code is Doxygen het enige productwelke aan de eisen van het project kan voldoen. Het goed documenterenvan de Java code kan zowel met Doxygen als met Javadoc. Voor het gemaken efficientie gaat de voorkeur uit naar Doxygen zodat er maar met eenprogramma gewerkt hoeft te worden.

25

B.8.4 Wiki

Naast het documenteren van de sourcecode is het van belang dat de algemenekennis over het project wordt gedocumenteerd. Onderwerpen als waar staatde structuur van de gebruikte methode tot welke setting in de webserver isnodig om het geheel goed te laten functioneren. Om al deze gegevens bij tehouden zal er actief gebruik worden gemaakt van een wiki.

26

C Appendix ontwerp

C.1 Schermontwerp

C.1.1 Inlogscherm

Figuur 17: Impressie van het inlogscherm.

27

C.1.2 Rechtenscherm

Figuur 18: Impressie van het rechtenscherm.

28

C.1.3 Overzichtsscherm

Figuur 19: Impressie van het overzichtsscherm.

29

C.1.4 Onderzoeksscherm

Figuur 20: Impressie van het onderzoeksscherm voor de laborant.

30

C.1.5 Koppelscherm

Figuur 21: Impressie van het koppelscherm met daarin de MagicLinker ap-plicatie.

31

C.1.6 Beoordelingsscherm

Figuur 22: Impressie van het beoordelingsscherm voor de specialist.

32

C.1.7 Settingsscherm

Figuur 23: Impressie van het settingsscherm.

33

C.2 Functioneel ontwerp

C.2.1 Beheerder

De beheerder van het DODS systeem logt in door middel van een gebrui-kersnaam en een wachtwoord. Dit inlogscherm (zie impressie bijlage C.1.1)is het eerste scherm dat een gebruiker ziet als hij/zij verbinding maakt metde website. Door middel van een bevestigingsknop, worden de gegevens ge-controleerd en verschaft de beheerder zich toegang tot een openingsschermwaarop een welkomst boodschap is weergegeven. Eventueel staan hier ooknog nieuwsberichten met ontwikkelingen omtrent het DODS systeem. Doorgebruik te maken van de secundaire navigatiebalk, kan de beheerder zijnproces vervolgen naar het overzichtsscherm (bijlage C.1.3). Op dit over-zichtsscherm heeft de beheerder de mogelijkheid te kiezen uit een drietal sub-schermen: omgevingsvariabelen, logbestanden en gebruikersmanagement.

In het omgevingsvariabelen scherm kunnen er instellingen gedaan wor-den waarmee DODS volledig geconfigureerd kan worden. Alles wat makke-lijk zou kunnen zijn voor de beheerder, kan als variabele opgenomen worden.Het gaat hierbij om directory paden (bijvoorbeeld voor de onderzoeksresul-taten of EDIFACT), het uiterlijk van de applicatie, de connectie instellingenmet LABOSYS en voor het plaatsen van een nieuwsbericht. Per onderdeelmoeten de verschillende variabelen weergegeven worden, met daarachter eeninvoerveld om deze een waarde te geven. Daarachter staat weer een icoon-tje, waar eventuele extra informatie onder weergegeven kan worden als debeheerder met de muiscursor eroverheen beweegt. Met de “volgende” knopvan de secundaire navigatiebalk kunnen de gewijzigde instellingen opgesla-gen worden, waarna de pagina ververst wordt.

Het logbestanden venster is een venster waarmee alle gebruikersacties enfouten mee bekeken kunnen worden. In het venster kan een selectie gemaaktworden door middel van een drop-down box. Er kan gekozen worden omalle log entries te bekijken, alle fouten, alleen alle gebruikersacties of alleentries van een specifieke gebruiker. Daarnaast kan er met twee andereinvoervelden de begindatum en de einddatum geselecteerd worden van degewenste logacties. Met de “volgende” knop van de secundaire navigatiebalkkunnen de log entries opgevraagd worden, en zal er binnen het hoofdvenstereen tabel weergegeven worden met alle informatie. In deze tabel zijn devolgende velden opgenomen: datum, tijd, gebruiker, bericht, eventuele extrainformatie, type (gebruiker of systeem) en het IP adres van de entiteit diedeze actie ondernomen heeft.

In het gebruikersmanagement venster zijn er drie schermen. Een schermom gebruikers te muteren, een scherm om gebruikers aan te maken en eenscherm om gebruikersrechten in te stellen. De eerste twee schermen heb-ben de dezelfde velden, namelijk: loginnaam (bij het mutatiescherm nietwijzigbaar), gebruikersnaam, email, LABOSYS id, medewerkerscode en een

34

wachtwoord. Daarnaast zijn er nog twee checkboxes waarmee aangegevenkan worden of het hier om een specialist gaat en of deze gebruiker ingescha-keld of uitgeschakeld is. Het gebruikersrechtenscherm (zie bijlage C.1.2) isbedoeld om de toegang van de gebruiker te regelen binnen de DODS appli-catie. Hierin kan door middel van checkboxes rechten toegezegd worden tothet: algemene gedeelte, beheer, onderzoek(en) en analyse(s). Al deze actieskunnen bevestigd worden aan de hand van de “volgende” knop onderaan depagina.

C.2.2 Laborant

De laborant binnen de DODS applicatie logt in door middel van het inlog-scherm. Dit werkt voor alle gebruikers van het systeem gelijk (zie beheerder).Nadat de laborant zich langs het welkomstscherm heeft genavigeerd, zal dezeeen overzicht te zien krijgen van alle onderzoeken waartoe deze laborant be-voegd is om af te nemen bij een patient (impressie in bijlage C.1.3). BinnenLabNoord is er momenteel de keuze uit: ergometrie, dexametrie, echosco-pie, fundus- en long onderzoeken. Nadat een laborant met behulp van deonderzoeksspecifieke software een onderzoek bij een patient heeft afgeno-men en gekozen heeft voor het betreffende onderzoek, kan deze het DODSsysteem gebruiken om waarnemingen op de elektronische werklijst te note-ren en om de onderzoeksbestanden te koppelen. De navigatieopties met heteerste hoofdscherm van een onderzoek, zijn te zien in bijlage C.1.4. Zoalsop de navigatiebalk af te lezen is, bestaat het afnemen van een onderzoekmet DODS uit de volgende stappen: selecteer labnummer, patientgegevens,werklijst, koppel foto, bevestig gegevens en bevestig verzenden.

Op het eerste scherm wordt een labnummer ingevuld die bij de laborantbekend is vanuit de planning van LABOSYS. Door op de “volgende” knopte klikken, gaat de laborant naar het volgende scherm.

Het tweede scherm, het patientgegevensscherm, staan de patientgegevensafgebeeld van de patient die gekoppeld zijn aan het opgegeven labnummer.Aan de hand hiervan kan de laborant controleren of de juiste persoon isopgevraagd, of dat er informatie niet kloppend is. In dit venster zijn devolgende gegevens opgenomen: de patientnaam, het patientnummer, hetgeslacht, de straat, postcode, woonplaats, geboortedatum en labnummer.Als de laborant akkoord is met de gegevens, kan deze zijn weg vervolgennaar het volgende scherm.

Het derde scherm, het onderzoeksscherm, is de elektronische werklijstwaarop de laborant al zijn bevindingen kan noteren. Deze bevindingen ver-schillen per onderzoek en zijn dus compleet variabel. Er bevinden zich op dewerklijst combo-boxen, invoervelden, checkboxen en option-boxen. Zo kaner bij een echoscopie van de onderbuik, bijvoorbeeld genoteerd worden watde vulling van de blaas is. Door middel van een option-box kan er gekozenworden tussen: gering, matig en goed. Tenslotte kan er een specifieke spe-

35

cialist uit een lijst gekozen worden, die het onderzoek dient te beoordelen.Hierdoor wordt het onderzoek specifiek aan deze specialist gekoppeld. Ookkan er door middel van een checkbox, prioriteit aan een onderzoek gegevenworden. Dit kan in het geval dat de laborant waarnemingen tijdens hetonderzoek doet die van dusdanige ernst zijn dat snel handelen gewenst is.Nadat de laborant alle velden ingevuld heeft, zal deze zijn/haar weg kunnenvervolgen naar het vierde scherm.

Het koppelscherm (voor impressie zie bijlage C.1.5), koppelt de onder-zoeksbestanden van de onderzoeksspecifieke applicatie aan de patientgegevensmet de bijbehorende werklijst. Hierbij is de “volgende” knop uitgeschakeld.Dit proces wordt automatisch afgehandeld en vereist geen interactie van delaborant. Zodra de koppel applicatie klaar is met het koppelen van de on-derzoeksbestanden, zal de “volgende” knop van de secundaire navigatiebalkweer ingeschakeld worden, waarna de laborant het onderzoek kan vervolgen.

Het vijfde scherm voor een onderzoek presenteert het geheel nog even opeen rijtje, het geeft de patientgegevens weer (zoals op het tweede scherm)en de gekoppelde onderzoeksgegevens. Deze gekoppelde onderzoeksgege-vens worden weergegeven door middel van een afbeelding (bij ondersteundeafbeeldingsformaten), of als link als het gaat om andere typen onderzoeks-bestanden.

Het zesde en laatste scherm, geeft in het hoofdvenster een bevestigingweer dat het onderzoek verzonden is, en gereed om beoordeeld te worden.Door gebruik te maken van de “volgende” knop, wordt de laborant doorDODS weer terugverwezen naar het eerste onderzoeksscherm en kan er eennieuw onderzoek van dat type afgenomen worden.

C.2.3 Specialist

De specialist beoordeeld de onderzoeken die door de laborant aangebodenzijn. De specialist logt in doormiddel van zijn/haar gebruikersnaam enwachtwoord in te voeren in het inlogscherm (bijlage C.1.1). Dit gaat metprecies hetzelfde scherm als die voor een laborant of een beheerder. Nahet welkomstscherm volgt weer het overzichtsscherm waar de specialist defunctieonderzoeken waartoe deze gerechtigd is, kan selecteren om te gaanbeoordelen. Achter de naam staat een getal met het aantal te beoordelenonderzoeken. Als de specialist op deze te beoordelen functieonderzoeksgroe-pen klikt, zal deze een overzicht krijgen met een lijst van alle te oordelenonderzoeken (zie bijlage C.1.6 voor een impressie). Dit is het eerste schermvoor de beoordeling van een functieonderzoek. Het gehele beoordelen be-staat uit de volgende schermen: onderzoekslijst, analyse, bevestig onderzoek,bevestig verzenden.

In het eerste scherm, dat een lijst weergeeft van de onderzoeken, is op-gebouwd uit een tabel met per onderzoek een datum, een onderzoekstype(onderbuik, bovenbuik, zwangerschap, etcetera) en een prioriteit, die de ur-

36

gentie aangeeft. Onderaan de lijst staat nogmaals het totaal te beoordelenaantal onderzoeken aangegeven. Uit deze lijst kan een specialist een spe-cifiek onderzoek aanklikken, of kan deze de “volgende” knop gebruiken omhet eerstvolgende onderzoek te kiezen (uitgaande van de prioriteit).

In het tweede scherm, het analyse scherm, staan in het hoofdvenstervan DODS opeenvolgend: de patientgegevens, onderzoeksgegevens, onder-zoeksantwoorden en tenslotte het advies. De onderzoeksantwoorden bestaanuit de ingevulde werklijst van de laborant. Het advies is het enige deel datde specialist kan invullen. Dit advies gedeelte gebruikt hetzelfde concept alsde laborant werklijst en bestaat uit verschillende typen invoervelden waar-mee de specialist een diagnose kan opstellen. Deze diagnose kan opgesteldworden aan de hand van deze bovenstaande gegevens.

Nadat de specialist het advies gedeelte van het analyse scherm heeft inge-vuld, kan deze, door op de “volgende” knop te klikken zijn proces vervolgennaar het derde scherm. Dit scherm, het bevestig gegevens scherm, laat hetadvies nog een keer aan de specialist tonen, zodat deze er zeker van kan zijndat de gestelde diagnose de juiste is. De velden zijn nu niet meer te manipu-leren. Mocht de specialist nog wijzigingen willen aanbrengen, zal deze metbehulp van de “vorige” knop naar het analyse scherm terug kunnen gaan.

Het laatste scherm, het bevestig verzenden scherm, geeft aan de specialistnog even een bevestiging dat de beoordeling door het DODS systeem isverwerkt. Door gebruik te maken van de “volgende” knop, zal de specialistnaar het volgende onderzoek worden verwezen.

37

C.3 Technisch ontwerp

C.3.1 DODS modules en services

DODS maakt gebruikt van de volgende modules en services, hier kunnen inde toekomst nog meer bijkomen.

DODS modules:

• EDI - Genereert EDI berichten.

• ResourceFile - Zorgt voor file manipulatie voor plaatjes, PDF bestan-den en algemene bestanden.

• LABOSYS - Handelt communicatie met de LABOSYS server af.

• MySQL - Zorgt voor interactie tussen de database.

• Patient - Bied patient gegevens aan.

• Redirect - Zorgt voor een veilige link naar de gegevens op het filesys-teem.

• Remote post - Zorgt voor de interactie met de externe applicaties.

• User - Biedt de user functionaliteit.

• XML - XML parcer voor de onderzoeksgegevens.

• Security - Biedt binnen de applicatie encryptie mogelijkheden aan.

DODS services:

• Debug - Biedt binnen de applicatie de mogelijkheid om debug berich-ten toe te voegen aan het systeem.

• Error - Biedt binnen de applicatie de mogelijkheid om error of warningberichten de casten.

• Log - Biedt binnen de applicatie de mogelijkheid acties te loggen.

38

Figuur 24: Schematisch overzicht modules en services

39

C.3.2 Capaciteit

Een onderzoek zal capaciteit van het systeem vereisen. Hier volgt een over-zicht van de benodigde capaciteit.

Naam Size Locatie

Log entry (5x) 1.5 KB Database

Onderzoek 1.5 KB Database

Onderzoek filelink 0.1 KB Database

EDI bericht 1 KB Filesystem

Onderzoeksbestand 1024 KB Filesystem

Zoals in paragraaf 4.2 Statistieken proces valt te lezen, worden er ongeveer1305 onderzoeken per maand afgehandeld. Een gemiddeld onderzoek ge-negeerd gemiddeld vijf logentries, eenmaal onderzoeksgegevens en eenmaalantwoorden op de vragen. De benodigde capaciteit van het systeem vooreen onderzoek komt op een totaal van gemiddeld 1028.1 KB. Met een 1305onderzoeken per maand wordt dit 1310 MB per maand.

Een gemiddeld onderzoek bestaat uit het elf maal weergeven van een web-pagina, namelijk zeven functieonderzoek webpagina’s en een vier beoordeelwebpagina’s. Gemiddeld is een webpagina 8 KB groot. Een onderzoeks-bestand wordt driemaal verstuurd namelijk, tijdens het uploaden naar deserver, tijdens het bevestigen van het onderzoeksbestand en tijdens het be-oordelen. Gemiddeld is een onderzoeksbestand 1024 KB groot. Daarnaastgenereert DODS, als een onderzoek is afgerond, een EDIFACT bericht van1 KB groot. Hieruit kan worden afgeleid dat een compleet onderzoek ge-middeld 3161 KB aan traffic veroorzaakt. Met 1305 onderzoeken per maandwordt de trafic 4028 MB per maand. Daarnaast worden er per maand on-geveer 200 beheerpagina’s aangeroepen welke in deze tijdsperiode 1600 KBaan trafic genereren.

De functie afdeling bied ruimte aan maximaal 80 onderzoeken per dag,dit getal wordt gebruikt als piekbelasting. Op deze piek dag zal er een 247MB aan verkeer worden gegenereerd.

40

C.3.3 ERD database model

Figuur 25: ERD database model

C.3.4 Database structure

PATIENT(Patientid,surname,initial,birthdate,sex,address,housenr,postalcode,city,name hisband)

RESEARCH(rid,patientid,labnr,date,research date,answers,advice,research section,researcher,

specialist,priority,status,xml, reqdatetime)

UPLOAD(file,rid,extention,sid,date)

USER(id,username,password,creation date,email,loginname,labosysid,specialist,medewerkercode,enabled)

USERRIGHTS(userid,subsectionid)

SECTIONS(id,name)

SUBSECTIONS(id,sectionid,name)

SUBSUBSECTIONS(id,subsectionid,name,script)

SETTINGS(modulename,name,value,description)

LOG(date,owner,msg,title,ip,type)

41

C.3.5 DODS-scriptlist

Voorbeeld van een scriptlist voor een echo onderzoek waarbij de navigatiezichtbaar is en traject controle aanstaat. De variable ‘page’ linkt naar defilelist. In deze lijst staat de eigenlijke locatie van het DODS-script.

$scriptname = "echo_onderbuik_man";

$script[$scriptname]["name"] = "Echo onderbuik man";

$script[$scriptname]["display_linklist"] = true;

$script[$scriptname]["traject_controll"] = true;

$script[$scriptname]["linklist"][0]["name"] = "Selecteer Labnr";

$script[$scriptname]["linklist"][0]["page"] = "select_labnr";

$script[$scriptname]["linklist"][1]["name"] = "Patient gegevens";

$script[$scriptname]["linklist"][1]["page"] = "patient_details";

$script[$scriptname]["linklist"][2]["name"] = "Werklijst";

$script[$scriptname]["linklist"][2]["page"] = "worklist";

$script[$scriptname]["linklist"][2]["params"]["file"] = "echo_onderbuik_man.xml";

$script[$scriptname]["linklist"][3]["name"] = "Koppel foto";

$script[$scriptname]["linklist"][3]["page"] = "link_magical";

$script[$scriptname]["linklist"][3]["params"]["filter"] = "^\w+_PATIENTID_(\d+)_\{\S+\}.\w+";

$script[$scriptname]["linklist"][3]["params"]["location"] = "c:\testfiles";

$script[$scriptname]["linklist"][4]["name"] = "Bevestig gegevens";

$script[$scriptname]["linklist"][4]["page"] = "confirm_data";

$script[$scriptname]["linklist"][5]["name"] = "Bevestig verzenden";

$script[$scriptname]["linklist"][5]["page"] = "confirm_send";

42

C.3.6 DODS-script

Een versimpeld voorbeeld van een DODS-script waar een paar patient ge-gevens worden weergegeven. Tijdens de PostProcess worden de patient ge-gevens opgeslagen en wordt hier een log entry over gemaakt.

<?

class confirmdataScript extends Script{

public function confirmdataScript(){

parent::Script();

}

public function Display(){

$this->Title("Patient Gegevens");

echo" <table class=\"group\" border=\"0\" cellpadding=\"0\" cellspacing=\"0\">";

echo" <tr>";

echo" <td class=\"contentname\">Patient naam</td>";

echo" <td class="content">: ".$_SESSION["script"]["patient"]->name()."</td>";

echo" </tr>";

echo" <tr>";

echo" <td class=\"contentname\">Patient nr</td>";

echo" <td class=\"content\">: ".$_SESSION["script"]["patient"]->patientnr()."</td>";

echo" </tr>";

echo" </table>";

}

public function PostProcess(){

$this->database->savePatient($_SESSION["script"]["patient"]);

$this->log->report("Saved research: ".$_SESSION["script"]["rid"],

"Behandelde patient: ".$_SESSION["script"]["patient"]->name());

}

}

?>

43

C.3.7 XML werkformulier

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE research SYSTEM "werklijst.dtd">

<research>

<info>

<title>Echo onderbuik man</title>

<version>0.1</version>

<labosysid>EOBM</labosysid>

<lastchange>20-10-2005</lastchange>

</info>

<questions>

<questiongroup>

<alignment>vertical</alignment>

<question>

<name value="FE55">Blaaswand:</name>

<type>

<name>checkbox</name>

<checkbox_choise value="/NOR">Normaal</checkbox_choise>

<checkbox_choise value="/LVD">Licht verdikt</checkbox_choise>

<checkbox_choise value="/TU">Tumor</checkbox_choise>

</type>

</question>

</questiongroup>

</questions>

<advice>

<questiongroup>

<alignment>vertical</alignment>

<question>

<name value="FE63">Advies</name>

<type>

<name>checkbox</name>

<checkbox_choise value="/AD07">Geen afwijkingen vastgeteld.</checkbox_choise>

<checkbox_choise value="/AD13">Nadere diagnostiek noodzakelijk.</checkbox_choise>

</type>

</question>

<question>

<name value="FE64">Opmerking:</name>

<type>

<name>open</name>

</type>

</question>

</questiongroup>

</advice>

</research>

44

D Appendix organisatie

D.1 Plan van aanpak

Deze bijlage gaat in op de organisatorische aspecten van dit project. Teneerste wordt een overzicht gegeven van de betrokkenen binnen het project.Ten tweede worden alle taken binnen het project gegeven. Ten derde zijnde afhankelijkheden opgenomen die belangrijk zijn voor het plannen van hetproject. Ten vierde is de planning opgenomen en ten slotte de verschillendemilestones binnen het project.

D.1.1 Betrokkenen

In de figuur hieronder zijn de betrokkenen binnen het project schematischweergegeven.

Figuur 26: Overzicht van betrokkenen project.

D.1.2 Taken

Aan de hand van het pakket aan requirements en recommendations, zoalsdeze beschreven staan in hoofdstuk 5 , kunnen de volgende taken voor hetproject gedefinieerd worden:

• Uitvoeren analyse.

• Opstellen projectplan.

45

• Bouw prototype.

• Presentatie prototype en projectplan.

• Goedkeuring project(in overleg met opdrachtgevers en gebruikers).

• Bouw framework (inclusief beheermodule).

• Bouw onderzoeksmodules.

• Bouw beoordelingsmodules.

• Implementatie applicatie in huidig systeem.

• Test applicatie.

• Schrijven documentatie.

• Inbruikname applicatie.

D.1.3 Planning

Hieronder is de planning van het project opgenomen, zoals deze geschat isaan de hand van de verschillende taken die gedefinieerd zijn.

Week Taak Fase

1 Meelopen functieafdeling Analyse

2 Meelopen functieafdeling Analyse

3 Bouw Prototype/opstellen projectplan Ontwerp



6 Presenteren prototype/projectplan Ontwerp

7 Definitief functioneel ontwerp/technisch ontwerp Ontwerp

8 Bouw framework (inclusief beheermodule) b Realisatie

9 Bouw framework (inclusief beheermodule) Realisatie

10 Bouw framework (inclusief beheermodule) Realisatie

11 Bouw onderzoeksspecifieke modulen Realisatie

12 Bouw beoordelingsmodulen Realisatie

13 Integratie applicatie huidig systeem Integratie

14 Integratietest applicatie Intregratietest

15 Integratietest applicatie Intregratietest

16 Opstellen gebruikersdocumentatie Documentatie

17 Opstellen beheer- ontwikkeldocumentatie Documentatie

18 Gebruikerstest applicatie Gebruikerstest

19 Inbruikname applicatie Implementatie

bHet uitvoeren van testen is onderdeel van deze activiteit.

46

D.1.4 Milestones

Aan de hand van de planning, kunnen milestones gedefinieerd worden. Hier-onder staan deze milestones opgesomd met de datum van de deadline:

Datum Milestone

23 september 2005 Voltooiing prototype.

07 oktober 2005 Compleet projectplan.

28 oktober 2005 Applicatie framework voltooid.

04 november 2005 Voltooing onderzoeksmodules.

11 november 2005 Voltooing beoordelingsmodules.

02 december 2005 Afronding integratie.

13 januari 2006 Inbruikname.

47

D.2 Kosten project

Deze bijlage geeft de kosten van het project weer. Deze berekeningen zijngebaseerd op een projectduur van 21 werkweken. Zoals in de onderstaandetabel af te lezen is, zijn de totale kosten voor dit project beraamd op e10.500,-.

Kosten

Omschrijving Uren Prijs/Eenheid Kosten

Faciliteiten

2 x Werkplek 1680 e 3,- p/u e 5.040,-

Medewerkers

H. Numan 21 e 30,- p/u e 630,-

G. Kroon 42 e 20,- p/u e 840,-

M. Roelfsema 42 e 15,- p/u e 630,-

Projectteam

2 x Afstudeerder 1680 e 2,- p/u e 3.360,-

Totaal - - e 10.500,-

48

E Appendix onwikkeldocumentatie MagicLinker

MagicLinkerOntwikkeldocumentatie


Datum:................. 18 januari 2006Instituut: LabNoord HuisartsenlaboratoriumPlaats: GroningenVersie: 1.0

49

E.1 Applicatie Overzicht

In dit hoofdstuk wordt eerst een beeld geschetst van de MagicLinker Appli-catie. Vervolgens worden de verschillende onderdelen van de applicatie kortbeschreven.

E.1.1 Algemeen

MagicLinker is een applicatie binnen het DODS systeem waarmee data vaneen client naar server kan worden verstuurd. Momenteel wordt het gebruiktom onderzoeksbestanden die gegenereerd worden tijdens een functieonder-zoek, automatisch te koppelen met de patientgegevens binnen DODS.

MagicLinker wordt door een DODS module aangeroepen met een aantalparameters. Deze parameters bepalen bijvoorbeeld naar welke bestandengezocht moet worden, of er gebruik gemaakt moet worden van een bevei-ligde verbinding, welk onderzoek er afgenomen wordt en waarnaartoe debestanden verstuurd moeten worden. Aan de hand van deze gegevens kanMagicLinker vervolgens automatisch de schijf van de client afzoeken naar debestanden behorende bij het huidige onderzoek. Als deze bestanden geloca-liseerd zijn, maakt MagicLinker verbinding met de DODS server en verzenddeze over. Als het proces succesvol doorlopen is, zal MagicLinker de gebrui-ker notificeren, en kan deze het onderzoek vervolgen. In het geval van eenfout, wordt dit in de GUI van MagicLinker aan de gebruiker gepresenteerd.Tevens zal MagicLinker trachten deze foutmelding naar de DODS server teverzenden.

E.1.2 Onderdelen

De MagicLinker applicatie bestaat uit verschillende onderdelen. Deze onder-delen worden in deze paragraaf stuk voor stuk kort beschreven. De namenvan de onderdelen komen overeen zoals ze binnen de applicatie bekend zijn.

MagicLinker

Dit is het hoofdobject binnen de applicatie. Deze wordt als eerst aangeroe-pen als de applicatie geexecuteerd wordt. Tevens worden hier vanuit alleandere programma logica aangeroepen (onderstaande onderdelen).

Eerst worden de parameters die meegegeven zijn door de DODS module, in-gelezen. Daarna vindt er zich initialisatie plaats en worden de verschillendeonderdelen in de juiste volgorde aangeroepen.

MagicLinkerRSM

50

Het MagicLinkerRSM object is bedoelt om alle functieonderzoeken binnende afdeling in te implementeren. Voor elk van de geımplementeerde func-tieonderzoeken is er een filter methode opgenomen, die speciaal bestandenfiltert voor een bepaald functieonderzoek. Zo is er momenteel bijvoorbeeldeen filter opgenomen voor ECG onderzoeksbestanden die gegenereerd zijndoor Cardio Control Workstation.

GZipper

Het GZipper object comprimeert data aan de hand van de GZIP methode.Een GZIP bevat geen header informatie en kan daarom maar 1 bestandbevatten. De bestandsnaam is gelijk aan het orgineel met het toegevoegde”.gz“ aan de extensie.

MagicLinkerGUI

De MagicLinkerGUI bevat alle functionaliteit voor de visuele weergave vande applicatie. Het bevat methoden om afbeeldingen in te laden, voortgangs-balken weer te geven en de huidige status van de applicatie te laten zien aande gebruiker.

MagicLinkerConverter

De MagicLinkerConverter biedt de mogelijkheid om het formaat van eenbestand te wijzigen. Momenteel kunnen bijvoorbeeld TIF afbeeldingsbe-standen omgezet worden naar PDF formaat. In de toekomst zouden dezefaciliteiten verder uitgebreid kunnen worden door nog meerdere conversieste implementeren.

51

E.2 Applicatie Bouwen

Voor het bouwen van de applicatie is tijdens het project gebruik gemaaktvan de JDK versie 1.5.0 build 05.

E.2.1 Sleutel genereren

MagicLinker heeft standaard geen lees en schrijfrechten op de schijf vande client. Dit komt omdat de applicatie binnen een webbrowser wordt ge-start. Hierdoor wordt de applicatie om veiligheidsredenen in een soort van”sandbox“ uitgevoerd. Om toch lees en schrijfrechten te verkrijgen, maaktMagicLinker gebruik van een certificaat. In deze paragraaf wordt uitgelegdhoe dit certificaat, doormiddel van het genereren van een sleutel, aange-maakt kan worden.

Om een sleutel te genereren, wordt gebruik gemaakt van de KeyTool vanSun Microsystems. Deze wordt standaard meegeleverd met JDK versie 1.4 ofhoger. De KeyTool kan een sleutel genereren aan de hand van het volgendecommando:

keytool -genkey -validity 1825 -keyalg rsa -alias labkey

In dit voorbeeld wordt een sleutel gegenereerd met een geldigheid van 1825dagen, gebruik makende van een rsa sleutel algoritme en een alias met denaam ”labkey“. Elke keer als een sleutel onder een nieuw alias gegenereerdwordt, zal er verschillende informatie van de organisatie gevraagd worden.Als laatste zal er een paswoord gevraagd worden waaronder de sleutel op-geslagen wordt. Als dit eenmaal gedaan is, wordt de sleutel opgenomen inhet lokale Java ”.keystore“ bestand. Deze is in Windows te vinden in degebruikersmap binnen ”Documents and Setttings“. Als men alle sleutels wilweghalen, hoeft men alleen dit bestand te verwijderen.

E.2.2 Compileren

Om de applicatie te compileren, kan gebruik gemaakt worden van het vol-gende commando:

javac -cp .\itext-1.3.jar;.\plugin.jar MagicLinker.java

-Xlint:unchecked

De twee libraries die voor het compileren erbij gehaald worden, zijn voor hetgenereren van PDF bestanden en voor de communicatie met een javascriptobject.

Nu de applicatie gecompileerd is, kan deze, met alle bijbehorende data toteen ”Java Archive“ gemaakt worden met het volgende commando:

52

jar cvf MagicLinker.jar MagicLinker.class MagicLinkerGUI.class

MagicLinkerRSM.class MagicLinkerConverter.class GZipper.class

ml_logo.gif com sun netscape

Zoals te zien is, worden alle .class bestanden van de applicatie opgenomenbinnen het archief. Ook worden de lokale mappen ”com“, ”sun“ en ”nets-cape“ in het archief opgenomen.

Nu de hele applicatie in een Java archief is opgenomen, kan het archiefgekoppeld worden met de gegenereerde sleutel:

jarsigner MagicLinker.jar labkey

Zoals te zien is wordt de sleutel weer aangeroepen aan de hand van hetalias waaronder het bekend is binnen het systeem. Nadat het commando isuitgevoerd, zal de jarsigner vragen om het paswoord wat tijdens de creatievan de sleutel is opgegeven. Als dit paswoord ingevoerd is, wordt de sleutelbinnen het archief opgenomen en kan het de applicatie uitgevoerd worden.

E.2.3 Uitvoeren

Om de compleet opgebouwde MagicLinker applicatie uit te voeren, zal de-ze aangeroepen moeten worden vanuit een HTML pagina. Het simpelstevoorbeeld hiervan:

<html>

<head>

<script type="text/javascript" src="MagicLinker.js"></script>

</head>

<body>

<center>

<applet bgcolor=#FFFCDF code="MagicLinker.class"

archive="MagicLinker.jar" width="300" height="80" MAYSCRIPT>

</center>

</body>

<html>

Helaas zal MagicLinker niet correct functioneren, omdat er geen parame-ters worden meegegeven aan de hand waarvan de applicatie opereert. Inde bijlage E.5.1 is een compleet voorbeeld HTML bestand met parametersopgenomen.

53

E.3 Applicatie Uitbreiden

E.3.1 Functieonderzoek toevoegen

Om MagicLinker uit te breiden met een nieuw functieonderzoek, moetener enkele stappen doorlopen worden. Deze stappen worden allemaal in hetMagicLinkerRSM object binnen MagicLinker uitgevoerd:

1. Creeer een nieuwe public static final int index waarde ter identificatievan het nieuwe onderzoek.Voorbeeld

ECG=1;

of

DEXA=2;

2. Implementeer een nieuwe methode binnen het object met een filtervoor het nieuwe onderzoek, of herbruik een van de oude, reeds geımplementeerdefilters. Zie bijlage E.5.2 voor een voorbeeldmethode van een onder-zoeksfilter.Voorbeeld

private String[] ECGFilter(String[] files);

3. Plaats een referentie naar deze nieuwe filtermethode door een methodeaanroep te plaatsen in de public String[] filter() methode, binnen deswitch.Voorbeeld

case ECG : RSMFilteredFiles = ECGFilter(files); break;

4. Plaats een referentie naar deze nieuwe filtermethode door de naamvan het onderzoek in de public String getResearchString() switch teplaatsen.Voorbeeld

case ECG: researchString = "ECG"; break;

5. Nu de nieuwe filter in het MagicLinkerRSM object is opgenomen, hoeftdeze alleen nog maar aangeroepen te worden vanuit het hoofdobjectMagicLinker.Voorbeeld

\\Create a new filter object with the desired filter

MagicLinkerRSM ml_rsm = new MagicLinkerRSM(

filteredfiles,fileregex,research);

\\Call the newly implemented filter method

String [] RSMFilteredFiles = ml_rsm.filter();

54

E.3.2 Foutmelding toevoegen

De volgende stappen dienen doorlopen te worden binnen het MagicLinker-GUI object om een nieuwe foutmelding toe te voegen:

1. Creeer een nieuwe public static final int error index waarde ter identi-ficatie van de nieuwe error.Voorbeeld

ERROR10=16;

of

ERROR1=3;

2. Voeg onderaan de private String[] errorStringsDutch en de privateString[] errorStringsEnglish een tekstregel toe die de gebruikers vanMagicLinker te zien krijgen als deze nieuwe fout zich voordoet.Voorbeeld

"Transmission failed!" + newline + "Could not convert file to PDF!"

3. Voeg nu in de public void paint(Graphics g) methode, de nieuwe error-melding aan het lijstje toe, boven de regel:

g.drawString("MAGIC LINKER - Fatal Error",25,15);

Voorbeeld

if(status == ERROR1 || status == ERROR10){

g.drawString("MAGIC LINKER - Fatal Error",25,15);

}

4. Plaats in de public void setStatus(int progressstatus, boolean repaint)methode, binnen de switch, de nieuwe errormelding.Voorbeeld

case ERROR10: status_string = errorStrings[language][16];

error_stat_set = true; break;

5. Nu de nieuwe errormelding in het MagicLinkerGUI object is opgeno-men, kan deze, nadat het object is aangemaakt, gezet worden met hetonderstaande commando.Voorbeeld

ml_gui.setStatus(MagicLinkerGUI.ERROR10,true);

55

E.3.3 Conversie toevoegen

Nieuwe conversies dienen in het MagicLinkerConverter object geplaatst teworden. Ideaal gezien bestaat een nieuwe conversie uit een enkele methode.De volgende stappen moeten doorlopen worden binnen dit object:

1. Plaats bovenin het MagicLinkerConverter object de extensie toe vanhet invoerbestand en de extensie van het uitvoerbestand.Voorbeeld

public final static String EPS = ".eps";

public final static String JPG = ".jpg";

2. Implementeer een nieuwe conversiemethode binnen het MagicLinker-Converter object.Voorbeeld

public boolean convertEPS2JPG(

String inputFile, String outputFile){};

3. Nu de conversiemethode geımplementeerd is, kan deze, nadat het Ma-gicLinkerConverter object is aangemaakt, aangeroepen worden.Voorbeeld

boolean fail = cnv.build("c:\input.eps", "c:\output.jpg");

56

E.4 Applicatie Testen

E.4.1 Parameters

Om de applicatie te testen, zal deze aangeroepen moeten worden aan dehand van de benodigde parameters. Door deze parameters aan te passen,kan er het een en ander getest worden. Als een van de parameters onjuist is,zal er een foutmelding gegenereerd worden. Voor uitleg bij de verschillendeparameters wordt er doorverwezen naar bijlage E.5.1; het voorbeeld HTMLbestand.

E.4.2 Unit-testen

Binnen de code van het project, is er ook het MagicLinkerTestUnit.java be-stand opgenomen. Dit is een JUnit bestand en kan gebruikt en uitgebreidworden om de functionaliteit van MagicLinker te testen. Momenteel bevathet bestand 8 verschillende tests die uitgevoerd worden op MagicLinker. Inde toekomst kunnen deze tests natuurlijk uitgebreid worden om ook nieuwtoegevoegde functionaliteit makkelijk te kunnen testen.

Om een nieuwe test toe te voegen, zal de testmethode binnen het JUnitbestand moeten beginnen met ”test“. Het makkelijkste is om daarachterdan gewoon de naam van vermelden van de methode van MagicLinker diehiermee getest wordt. Bijvoorbeeld de naam ”testZipFile()“ voor de Magi-cLinker methode ”zipFile()“.

E.4.3 Uitvoeren

Om uiteindelijk de applicatie te kunnen testen, nadat deze gecompileerdis, kan het voorbeeld HTML bestand gebruikt worden. Door de inhoud ineen HTML bestand te plaatsen, kan het met een internetbrowser geopendworden. Binnen deze HTML pagina zal dan de applicatie geladen worden,en uitgevoerd.

57

E.5 Appendix

E.5.1 Voorbeeld HTML



<html>

<head>

<title>Magic Linker Test</title>

<script type="text/javascript" src="MagicLinker.js"></script>

</head>

<body bgcolor=#F5F5D5>

<p>&nbsp</p>

<p>&nbsp</p>

<p>&nbsp</p>

<center>





<applet bgcolor=#FFFCDF code="MagicLinker.class" archive="MagicLinker.jar"

width="300" height="80" MAYSCRIPT>





<param name="gui_bar_top_color" value="475172">



<param name="gui_font_color" value="000000">



<param name="gui_bar_color" value="63709D">



<param name="gui_language" value="1">



<param name="gui_font" value="Arial">



<param name="gui_bar_back_color" value="FFFCDF">





<param name="ssl_enable" value="1">





<param name="filter_research_id" value="1">

<!-- "filter_syntax" sets the required syntax for the research file.

Syntax is specified using a so called JAVA specific regular

expression(REGEX).

58

Consult the JAVA documentation for more on the subject:

"http://java.sun.com/j2se/1.5.0/docs/api/"

The patient_id is inserted in the regex, and the expression

between brackets(date)

will be returned as a group for filtering. |XXX| -->

<param name="filter_regex" value="^\w+_IDEM55071001_(\d+)_\{\S+\}.\w+">





<param name="location_research_files" value="d:\\testfiles">



<param name="location_research_tempfiles" value="temp">





<param name="location_server_port" value="80">



<param name="location_post_address"

value="https://dods/magic_linker/post.php">

</applet>



<p>&nbsp</p>

<p>&nbsp</p>

<p>&nbsp</p>

<DIV id="next_disabled"><font color="#BBBBBB"> Volgende</font>

<img src="disabled_next.bmp" width="19" height="18"></DIV>

<DIV id="next_enabled" style="display:none">

<font color="#000000">Volgende</font>

<a href="http://www.europeanhero.com">

<img src="enabled_next.bmp" width="19" height="18" border="0"></a></DIV>

</center>

</body>

</html>

59

E.5.2 Voorbeeld onderzoeksfilter

/**

* A filter method(ECG).

*

* This method filters exported ECG research files.

*

* @param files List of ECG export filenames to filter.

* @param selectToken The token of the filename where the

* files should be filtered on.

* @return RSMFilteredFiles An array of strings which contain

* the names of all the files that passed the research

* filter. Returns null if no file passes the filter.

*/

private String[] ECGFilter(String[] files){

Vector<String> file_vector = new Vector<String>();

Vector<String> tofilter = new Vector<String>();

Pattern pattern = Pattern.compile(regex);

for(int i=0;i<files.length;i++){

Matcher matcher = pattern.matcher(files[i]);

while (matcher.find()) {

file_vector.add(""+i);

tofilter.add(matcher.group(1));

}

}

String[] RSMtofilter = new String[tofilter.size()];

tofilter.copyInto(RSMtofilter);

long highest_value = 0L;

//Search for highest value(latest research).

for(int i=0;i<RSMtofilter.length;i++){

long value = Long.parseLong(RSMtofilter[i]);

if(value>highest_value){

highest_value = value;

}

}

//Search for values equal to the highest

//value(multiple files for a research).

Vector<String> RSMFilteredFilesVector = new Vector<String>();

for(int i=0;i<RSMtofilter.length;i++){

long value = Long.parseLong(RSMtofilter[i]);

if(value==highest_value){

RSMFilteredFilesVector.add(""+file_vector.elementAt(i));

}

}

//Place filenames with highest value(s) in array.

String value_str="";

60

String[] RSMFilteredFiles = new String[RSMFilteredFilesVector.size()];

for(int i=0;i<RSMFilteredFilesVector.size();i++){

value_str = (String)(RSMFilteredFilesVector.elementAt(i));

RSMFilteredFiles[i] = (String)(files[Integer.parseInt(value_str)]);

}

return RSMFilteredFiles;

}//ECGFilter

61

F Appendix DODS CD-ROM

Deze bijlage geeft een overzicht van de onderdelen die op de meegeleverdeCD-ROM zijn opgenomen:

F.1 Software

• Het DODS systeem, bestaande uit:

- Server-side PHP gedeelte

- Client-side JAVA gedeelte (MagicLinker)

F.2 Documentatie

• Doxygen gegenereerde API’s voor DODS (HTML formaat).

• Het DODS verslag (PDF formaat).

• Het RDS verslag (DOC formaat).

• De NEN7510: Informatiebeveiliging binnen de zorg (PDF formaat).

• Handleiding - Wet bescherming persoonsgegevens (PDF formaat).

• Specificatie van de basisinfrastructuur in de zorg versie 2.2 (PDF for-maat).

62

Dynamic Online Diagnostic System (DODS) - Hanze University

Documents

Transcript of Dynamic Online Diagnostic System (DODS) - Hanze University