You are on page 1of 124

Dynamic Online Diagnostic System

W. Hofsta & C. Jager

Datum: 18 januari 2006


Instituut: LabNoord Huisartsenlaboratorium
Plaats: Groningen
Dynamic Online Diagnostic System

W. Hofsta & C. Jager

Datum: 18 januari 2006


Instituut: LabNoord Huisartsenlaboratorium
Plaats: Groningen
Opdrachtgever: J.H. Numan
Opdrachtnemer: W.T. Hofstra & C.A. Jager
Bedrijfsbegeleider: G. Kroon
Stagebegeleider: J.H. Bos
School: Hanzehogeschool
Afdeling: Informatica
Voorwoord
In het kader van onze afstudeerstage, van de studie Informatica aan de Han-
zehogeschool Groningen, hebben wij onderzoek verricht naar de mogelijkheid
bij LabNoord om het afnemen, beoordelen en verwerken van functieonder-
zoeken op de functieafdeling te automatiseren. Dit verslag is ontstaan als
gevolg van de afstudeerstage die wij binnen LabNoord hebben gelopen van
augustus 2005 tot februari 2006. Via een student van de Hanzehogeschool
die bij LabNoord zijn afstudeerstage voltooid had, zijn wij in contact geko-
men met heer Numan. De heer Numan is hoofd van de ICT afdeling binnen
de organisatie en had deze interessante afstudeeropdracht voor ons.

Naast het verrichte onderzoek, dat in dit verslag is opgenomen, hebben wij
tijdens deze periode, aan de hand van het onderzoek, een oplossing voor
LabNoord gerealiseerd. Deze bestond uit het aandragen van een maatwerk
oplossing 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, de
heer Kroon, en de heer Numan. Dit verslag kan namelijk een verhelderend
beeld geven van de verschillende processen en informatiestromen binnen de
organisatie. Tenslotte is dit verslag ook bedoeld voor onze stagebegeleider,
die aan de hand hiervan een beeld krijgt van de geleverde prestaties tijdens
dit afstudeertraject.

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

Wieger Hofstra en Chris Jager,


Groningen, 18 januari 2006

i
Inhoudsopgave
Voorwoord i

Samenvatting viii

1 Inleiding 1

2 Bedrijf 2
2.1 Organisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4 ICT afdeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4.2 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4.3 Werkzaamheden . . . . . . . . . . . . . . . . . . . . . 4
2.5 Applicaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5.1 LABOSYS . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5.2 Schuursoft . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Opdrachtomschrijving 6
3.1 Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Huidige Situatie 7
4.1 Huidige proces . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2 Betrokkenen . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.3 Visualisatie . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Statistieken proces . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Remote Diagnostic System . . . . . . . . . . . . . . . . . . . 12
4.3.1 OptiLink . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.2 DataLink . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.3 Webapplicatie . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.4 Beveiliging . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.5 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Gewenste situatie 15
5.1 Richtlijnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 Requirements and recommendations . . . . . . . . . . . . . . 16
5.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.2 Recommendations . . . . . . . . . . . . . . . . . . . . 17
5.2.3 Verificatie . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3 Gewenst proces . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . 17

ii
5.3.2 Onderzoek . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.3 Beoordeling . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.4 Publicatie . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4 Visualisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.5 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6 Advisering 22
6.1 Mogelijkheden . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1.1 Ontwikkeling intern . . . . . . . . . . . . . . . . . . . 22
6.1.2 Aanwenden bestaande oplossing . . . . . . . . . . . . 23
6.1.3 Ontwikkeling extern . . . . . . . . . . . . . . . . . . . 24
6.1.4 Mogelijke combinaties . . . . . . . . . . . . . . . . . . 24
6.2 Overzicht mogelijkheden . . . . . . . . . . . . . . . . . . . . . 24
6.3 Besparingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.4 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 Ontwerp 28
7.1 Functioneel Ontwerp . . . . . . . . . . . . . . . . . . . . . . . 28
7.1.1 Het proces . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1.2 Beschrijving applicatie . . . . . . . . . . . . . . . . . . 29
7.1.3 Doel applicatie . . . . . . . . . . . . . . . . . . . . . . 30
7.1.4 Gebruikers applicatie . . . . . . . . . . . . . . . . . . . 30
7.1.5 Koppelingen applicatie . . . . . . . . . . . . . . . . . . 31
7.1.6 Visualisatie applicatie . . . . . . . . . . . . . . . . . . 31
7.1.7 Gebruikersproces applicatie . . . . . . . . . . . . . . . 32
7.1.8 Logbestanden . . . . . . . . . . . . . . . . . . . . . . . 33
7.1.9 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2 Technisch Ontwerp . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2.1 Applicatie omgeving . . . . . . . . . . . . . . . . . . . 35
7.2.2 Applicatie structuur . . . . . . . . . . . . . . . . . . . 35
7.2.3 Applicatie onderdelen . . . . . . . . . . . . . . . . . . 38
7.2.4 Client-side applicatie . . . . . . . . . . . . . . . . . . . 41
7.2.5 Afhankelijkheden . . . . . . . . . . . . . . . . . . . . . 43

8 Evaluatie 44
8.1 Organisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.3 Techniek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.3.1 Generiek karakter . . . . . . . . . . . . . . . . . . . . 45
8.3.2 Platformonafhankelijk . . . . . . . . . . . . . . . . . . 46
8.3.3 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.4 Kennis opleiding . . . . . . . . . . . . . . . . . . . . . . . . . 47

iii
9 Conclusie en aandachtspunten 48
9.1 Waar automatiseren . . . . . . . . . . . . . . . . . . . . . . . 48
9.2 Hoe automatiseren . . . . . . . . . . . . . . . . . . . . . . . . 48
9.3 Kosten automatiseren . . . . . . . . . . . . . . . . . . . . . . 49
9.4 Aandachtspunten . . . . . . . . . . . . . . . . . . . . . . . . . 49

10 Literatuuropgave 50

A Appendix vooronderzoek 1
A.1 Procedures functieonderzoeken (huidige situatie) . . . . . . . 1
A.1.1 DFD echo onderzoek . . . . . . . . . . . . . . . . . . . 1
A.1.2 Procedure echo onderzoek . . . . . . . . . . . . . . . . 2
A.1.3 DFD ergo onderzoek . . . . . . . . . . . . . . . . . . . 3
A.1.4 Procedure ergo onderzoek . . . . . . . . . . . . . . . . 4
A.1.5 DFD fundus onderzoek . . . . . . . . . . . . . . . . . 5
A.1.6 Procedure fundus onderzoek . . . . . . . . . . . . . . . 6
A.1.7 DFD bio onderzoek . . . . . . . . . . . . . . . . . . . 7
A.1.8 Procedure bio onderzoek . . . . . . . . . . . . . . . . . 8
A.1.9 DFD dexa onderzoek . . . . . . . . . . . . . . . . . . . 9
A.1.10 Procedure dexa onderzoek . . . . . . . . . . . . . . . . 10
A.2 Opdrachtomschrijving . . . . . . . . . . . . . . . . . . . . . . 11

B Appendix ontwikkelomgeving 12
B.1 Ontwikkelmethode . . . . . . . . . . . . . . . . . . . . . . . . 12
B.1.1 Waterfall . . . . . . . . . . . . . . . . . . . . . . . . . 12
B.1.2 RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
B.1.3 Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
B.1.4 Keuze . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
B.2 Programeeromgeving . . . . . . . . . . . . . . . . . . . . . . . 13
B.2.1 Serverside omgevingen . . . . . . . . . . . . . . . . . . 14
B.2.2 Licenties . . . . . . . . . . . . . . . . . . . . . . . . . . 15
B.2.3 Kosten . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
B.2.4 Clientside . . . . . . . . . . . . . . . . . . . . . . . . . 16
B.2.5 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
B.3 Webserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
B.3.1 Internet Information Services . . . . . . . . . . . . . . 17
B.3.2 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . 18
B.3.3 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
B.4 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
B.4.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . 19
B.4.2 Caché . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
B.4.3 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
B.5 Beveiliging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
B.5.1 Cryptografie . . . . . . . . . . . . . . . . . . . . . . . 20

iv
B.5.2 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . 21
B.5.3 Autorisatie . . . . . . . . . . . . . . . . . . . . . . . . 21
B.5.4 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
B.5.5 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
B.6 Kwaliteitsbewaking . . . . . . . . . . . . . . . . . . . . . . . . 22
B.6.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B.6.2 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B.6.3 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B.7 Versiebeheer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B.7.1 CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.7.2 SVN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.7.3 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.8 Documentatie . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.8.1 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.8.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.8.3 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.8.4 Wiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

C Appendix ontwerp 27
C.1 Schermontwerp . . . . . . . . . . . . . . . . . . . . . . . . . . 27
C.1.1 Inlogscherm . . . . . . . . . . . . . . . . . . . . . . . . 27
C.1.2 Rechtenscherm . . . . . . . . . . . . . . . . . . . . . . 28
C.1.3 Overzichtsscherm . . . . . . . . . . . . . . . . . . . . . 29
C.1.4 Onderzoeksscherm . . . . . . . . . . . . . . . . . . . . 30
C.1.5 Koppelscherm . . . . . . . . . . . . . . . . . . . . . . . 31
C.1.6 Beoordelingsscherm . . . . . . . . . . . . . . . . . . . 32
C.1.7 Settingsscherm . . . . . . . . . . . . . . . . . . . . . . 33
C.2 Functioneel ontwerp . . . . . . . . . . . . . . . . . . . . . . . 34
C.2.1 Beheerder . . . . . . . . . . . . . . . . . . . . . . . . . 34
C.2.2 Laborant . . . . . . . . . . . . . . . . . . . . . . . . . 35
C.2.3 Specialist . . . . . . . . . . . . . . . . . . . . . . . . . 36
C.3 Technisch ontwerp . . . . . . . . . . . . . . . . . . . . . . . . 38
C.3.1 DODS modules en services . . . . . . . . . . . . . . . 38
C.3.2 Capaciteit . . . . . . . . . . . . . . . . . . . . . . . . . 40
C.3.3 ERD database model . . . . . . . . . . . . . . . . . . . 41
C.3.4 Database structure . . . . . . . . . . . . . . . . . . . . 41
C.3.5 DODS-scriptlist . . . . . . . . . . . . . . . . . . . . . . 42
C.3.6 DODS-script . . . . . . . . . . . . . . . . . . . . . . . 43
C.3.7 XML werkformulier . . . . . . . . . . . . . . . . . . . 44

D Appendix organisatie 45
D.1 Plan van aanpak . . . . . . . . . . . . . . . . . . . . . . . . . 45
D.1.1 Betrokkenen . . . . . . . . . . . . . . . . . . . . . . . 45
D.1.2 Taken . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

v
D.1.3 Planning . . . . . . . . . . . . . . . . . . . . . . . . . 46
D.1.4 Milestones . . . . . . . . . . . . . . . . . . . . . . . . . 47
D.2 Kosten project . . . . . . . . . . . . . . . . . . . . . . . . . . 48

E Appendix onwikkeldocumentatie MagicLinker 49


E.1 Applicatie Overzicht . . . . . . . . . . . . . . . . . . . . . . . 50
E.1.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . 50
E.1.2 Onderdelen . . . . . . . . . . . . . . . . . . . . . . . . 50
E.2 Applicatie Bouwen . . . . . . . . . . . . . . . . . . . . . . . . 52
E.2.1 Sleutel genereren . . . . . . . . . . . . . . . . . . . . . 52
E.2.2 Compileren . . . . . . . . . . . . . . . . . . . . . . . . 52
E.2.3 Uitvoeren . . . . . . . . . . . . . . . . . . . . . . . . . 53
E.3 Applicatie Uitbreiden . . . . . . . . . . . . . . . . . . . . . . 54
E.3.1 Functieonderzoek toevoegen . . . . . . . . . . . . . . . 54
E.3.2 Foutmelding toevoegen . . . . . . . . . . . . . . . . . 55
E.3.3 Conversie toevoegen . . . . . . . . . . . . . . . . . . . 56
E.4 Applicatie Testen . . . . . . . . . . . . . . . . . . . . . . . . . 57
E.4.1 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 57
E.4.2 Unit-testen . . . . . . . . . . . . . . . . . . . . . . . . 57
E.4.3 Uitvoeren . . . . . . . . . . . . . . . . . . . . . . . . . 57
E.5 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
E.5.1 Voorbeeld HTML . . . . . . . . . . . . . . . . . . . . . 58
E.5.2 Voorbeeld onderzoeksfilter . . . . . . . . . . . . . . . . 60

F Appendix DODS CD-ROM 62


F.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
F.2 Documentatie . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

vi
Lijst van figuren
1 Organogram LabNoord . . . . . . . . . . . . . . . . . . . . . . 3
2 Tijd/actie diagram van een functieonderzoek (huidige situatie) 11
3 Tijd/actie diagram van een functieonderzoek (gewenste situatie) 19
4 Globale opzet venster binnen DODS. . . . . . . . . . . . . . . 30
5 Schematische weergave applicatie omgeving . . . . . . . . . . 35
6 Abstracte weergave oplossing . . . . . . . . . . . . . . . . . . 36
7 Schematische weergave scriptlist. . . . . . . . . . . . . . . . . 37
8 Schematische weergave interne structuur. . . . . . . . . . . . 38
9 Schematische weergave rechten structuur. . . . . . . . . . . . 40
10 Schematische weergave DODS MagicLinker. . . . . . . . . . . 42
11 DFD echo onderzoek . . . . . . . . . . . . . . . . . . . . . . . 1
12 DFD ergo onderzoek . . . . . . . . . . . . . . . . . . . . . . . 3
13 DFD fundus onderzoek . . . . . . . . . . . . . . . . . . . . . . 5
14 DFD bio onderzoek . . . . . . . . . . . . . . . . . . . . . . . . 7
15 DFD dexa onderzoek . . . . . . . . . . . . . . . . . . . . . . . 9
16 Schematische weergave asymmetrische encryptie. . . . . . . . 21
17 Impressie van het inlogscherm. . . . . . . . . . . . . . . . . . 27
18 Impressie van het rechtenscherm. . . . . . . . . . . . . . . . . 28
19 Impressie van het overzichtsscherm. . . . . . . . . . . . . . . . 29
20 Impressie van het onderzoeksscherm voor de laborant. . . . . 30
21 Impressie van het koppelscherm met daarin de MagicLinker
applicatie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
22 Impressie van het beoordelingsscherm voor de specialist. . . . 32
23 Impressie van het settingsscherm. . . . . . . . . . . . . . . . . 33
24 Schematisch overzicht modules en services . . . . . . . . . . . 39
25 ERD database model . . . . . . . . . . . . . . . . . . . . . . . 41
26 Overzicht van betrokkenen project. . . . . . . . . . . . . . . . 45

vii
Samenvatting
LabNoord is een organisatie welke in opdracht van huisartsen en specialis-
ten verscheidene onderzoeken afneemt. Eén van die type onderzoeken binnen
LabNoord, zijn functieonderzoeken.

Een functieonderzoek is een onderzoek naar een bepaalde lichaamsfunctie;


bijvoorbeeld naar de longen of de fundus van een patiënt. Momenteel wor-
den de functieonderzoeken nog op papier afgenomen en is de verwerking van
de resultaten naar het elektronische patiëntendossier handmatig. Bovendien
worden de afgenomen functieonderzoeken per bode van LabNoord naar het
Martiniziekenhuis gebracht ter beoordeling door een specialist.

Vanuit de organisatie was er de behoefte aan een oplossing waarmee het


proces 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 verwerken
van 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 besloten


om ook de oplossing uit te werken en te realiseren voor LabNoord. Deze
uitwerking is opgenomen in de vorm van een ontwerp. Aan de hand van het
ontwerp 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 nieuwe
functieonderzoeken kunnen toevoegen en wijzigen.

viii
1 Inleiding
Het nieuwe zorgstelsel; een van de maatregelen die door het kabinet genomen
is om de marktwerking in de zorgsector te verbeteren. Door meer concur-
rentie te creëren hopen zij zorginstellingen te kunnen dwingen efficiënter te
opereren. Als gevolg hiervan zouden de kosten van de zorg omlaag gaan en
de kwaliteit van de service stijgen. De praktijk zal uitmaken of dit nobele
doel uiteindelijk bereikt zal worden.
Om deze verhoogde efficiëntie te kunnen realiseren, is automatisering
binnen organisaties één van de favorieten. Zo is er ook binnen LabNoord de
behoefte aan automatisering. LabNoord houdt zich bezig met het afnemen
van onderzoeken in opdracht van huisartsen en specialisten. LabNoord wil
de onderzoeken die bij de functieafdeling van deze organisatie afgenomen
worden, automatiseren. Hiertoe is er voor de organisatie eerst een onder-
zoek verricht, aan de hand van de onderstaande probleemstelling:

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

In dit verslag zal, door de probleemstelling in verschillende deelproblemen


op te splitsen, in de komende hoofdstukken een antwoord geformuleerd wor-
den op deze vraag. Het verslag kan in twee fases opgedeeld worden: een
onderzoeksfase en een realisatiefase. Naast het verrichte onderzoek is er
namelijk ook een project opgezet. Binnen dit project is een applicatie ge-
realiseerd waarmee de onderzoeken op de functieafdeling geautomatiseerd
kunnen 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 de
omgeving. Daarna is de opdrachtomschrijving opgenomen zoals deze vanuit
LabNoord is uitgegeven. Hierop volgt een omschrijving van de huidige situ-
atie, daarna die van de gewenste situatie. Aan het eind van het onderzoek
wordt er tenslotte een advies gegeven.
Hierna volgt het gedeelte betreffende de realisatie van een oplossing voor
het beschreven probleem. Hiertoe is een project opgezet naar aanleiding van
het 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 het
doorlopen 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 een
beschrijving gegeven van de organisatie, vervolgens de historie van de orga-
nisatie, gevolgd door een organogram. Daarna wordt specifiek ingegaan op
de 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 bijna
vijfhonderd mensen werkzaam. LabNoord werkt vanuit een centraal labo-
ratorium, dat gehuisvest is aan het Damsterdiep in Groningen en vanuit
laboratoria in de regio. Dit zijn het Martini ziekenhuis in Groningen, het
St. Lucasziekenhuis in Winschoten, het Refaja ziekenhuis in Stadskanaal en
de Geestelijke Gezondheidszorg (GGZ) in Assen.
Het Huisartsen Laboratorium verzorgt bloed-, urine-, sperma- en faeces-
onderzoeken in opdracht van huisartsen. Tevens verzorgt het laboratorium
verschillende functieonderzoeken. Enkele voorbeelden hiervan zijn:

• Een zwangerschapsecho

• Een inspannings ECG

• Een botdichtheidsmeting

De Trombosedienst doet bloedonderzoek voor ongeveer 10.000 patiënten in


de regio. Vanuit een netwerk van 110 prikpunten, worden er monsters af-
genomen die binnen enkele uren getransporteerd, bepaald en beoordeeld
kunnen worden.

Tevens is er binnen de organisatie een commerciële tak; Stichting WebNoord.


Stichting WebNoord staat los van LabNoord en biedt een pakket aan voor
het realiseren van elektronisch recepten verkeer tussen huisartsen en apothe-
kers. Bij WebNoord zijn verschillende huisartsen en apothekers in de regio
aangesloten, die maandelijks voor deze dienst betalen. De applicatie wordt
door één medewerker binnen de ICT afdeling van LabNoord onderhouden
en uitgebreid.

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

2
laboratoriumdiagnostiek. De Trombosedienst hield zich bezig met het bege-
leiden van patiënten. Toen het SHLN ging uitbreiden, door de mogelijkheid
te bieden ECG’s af te nemen, werd er een Functieafdeling gevormd. Door
fusies met enkele laboratoria in het noorden ontstonden meerdere plekken
waar 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. Lucas
ziekenhuis en de GGZ. De locatie aan het Damsterdiep is in 2000 na een
verbouwing DamsterDomus genoemd. Sindsdien zijn de laboratoria van het
Martini en het Refaja ziekenhuis opgenomen in de organisatie.

2.3 Overzicht
In deze paragraaf wordt de gehele organisatie weergegeven aan de hand van
een organogram:

Figuur 1: Organogram LabNoord

Uit het organogram kan worden afgeleid dat de kern van de organisatie is
opgebouwd 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 vallen
onder LabNoord de verschillende stafdiensten, zoals in de figuur af te lezen
is. Deze stafdiensten ondersteunen alle vier de stichtingen en zijn eigenlijk
geı̈ntegreerd in de stichtingen. Het komt voor dat sommige medewerkers
binnen de ICT afdeling werkzaam zijn voor het Huisartsen Laboratorium
Noord, en andere voor het Medisch Laboratorium Noord. Om het organo-
gram overzichtelijk te houden, zijn de stafdiensten echter in een aparte tak
opgenomen.
Aan het hoofd van de organisatie staat de directie, bestaande uit twee
directieleden. 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 afdeling
van LabNoord (zie ook organogram uit paragraaf 2.3). Vervolgens worden
de historie van de afdeling en tenslotte de huidige werkzaamheden binnen
de 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 en
momenteel zijn er 13 medewerkers werkzaam op de afdeling.

2.4.2 Historie
De ICT afdeling is in 1990 ontstaan toen door LabNoord een medewerker
is aangetrokken om zich voltijd bezig te houden met het onderhouden van
enkele servers binnen het bedrijf. In de loop der jaren zijn er steeds meer
ICT gerelateerde activiteiten bijgekomen, en daarom is in 1997 nog een
medewerker aangetrokken.
Na de verbouwing van het Damsterdiep complex in 2000, is het aantal
medewerkers van de ICT afdeling drastisch verhoogd. In korte tijd is de
ICT afdeling uitgegroeid tot de huidige 13 medewerkers, die zich fulltime
bezighouden met de ICT binnen de organisatie.

2.4.3 Werkzaamheden
De werkzaamheden van de ICT afdeling zijn in te delen in de volgende
groepen:

• 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 hierbij
gedacht worden aan database servers, werkstations en VPN netwerken.
Het applicatiebeheer bestaat uit het onderhouden van de applicaties die
binnen 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 het
opschonen van databases.
Voor de werkplekondersteuning is er één medewerker van de ICT afdeling
voltijd werkzaam. Deze helpt medewerkers binnen de organisatie met hun
werkstations, wanneer deze niet naar behoren functioneren. Dit kan voor-
komen in het geval van een defect, storing of door een veranderend pakket
aan eisen binnen de organisatie.
Naast de bovenstaande activiteiten, komen er ook losse projecten voor
op de afdeling. Zo vindt er momenteel een overschakeling plaats naar een
ander patiëntendossier systeem (zie paragraaf 2.5). Daarnaast wordt er voor
sommige software problemen zelf een oplossing ontwikkeld. Meestal is dit
in combinatie met nieuwe hardware die geı̈nstalleerd moet worden. Men
kan hierbij bijvoorbeeld denken aan een apparaat dat stickers uitprint met
daarop barcodes van labnummers. Om een koppeling te maken met het
systeem, is een maatwerkoplossing gerealiseerd.

2.5 Applicaties
Binnen LabNoord zijn er enkele belangrijke applicaties en omgevingen die
nader toegelicht dienen te worden:

2.5.1 LABOSYS
LABOSYS is ontwikkeld door Philips, en speciaal ontwore om ingezet te
worden binnen een laboratorium. LABOSYS maakt gebruik van een Caché.
LABOSYS maakt het mogelijk patiëntgegevens bij te houden, onderzoeken
in te plannen, uitslagen op te slaan en te factureren naar de patiënt. Ook
biedt het de functionaliteit om volledig te integreren in analyseapparatuur
door middel van het data acquisitie systeem L 25. LABOSYS is in 1998
door LabNoord in gebruik genomen en ondersteunt de functieonderzoeken
op 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 in
gebruik voor het verzorgen van de planning, dataopslag en facturering van
functieonderzoeken. De applicatie is bij de start van het laboratorium door
een directeur van LabNoord gemaakt. Veel van de functieonderzoeken wor-
den momenteel nog door Schuursoft verwerkt. Op het moment van schrijven
is de ICT-afdeling echter bezig met het omzetten van alle functieonderzoe-
ken naar LABOSYS. Als de volledige omzetting heeft plaatsgevonden, zal
het Schuursoft pakket uit de roulatie worden gehaald.

5
3 Opdrachtomschrijving
In dit hoofdstuk wordt in het kort de opdrachtomschrijving van LabNoord
besproken. 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. Hierin
wordt beschreven hoe de onderzoeken per bode, voor beoordeling, heen en
weer 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 in
relatie met bestaande faciliteiten en met betrekking op de applicatie.
Deze door LabNoord omschreven eisen zijn op vele verschillende manieren te
interpreteren en bieden daarom geen goede basis om mee verder te werken.
Ook blijkt uit het laatste deel van de opdrachtomschrijving dat er vanuit
LabNoord veel onduidelijkheden zijn en dat nadere analyse noodzakelijk is.
Met dit doel zal er in de komende hoofdstukken eerst de huidige situatie
weergegeven worden, vervolgens de gewenste situatie, de mogelijkheden en
uiteindelijk het advies omtrent een duidelijk geformuleerd probleem. Aan de
hand 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 efficiëntie 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:

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

6
4 Huidige Situatie
In dit hoofdstuk wordt de huidige situatie binnen de functieafdeling nader
geanalyseerd, 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 twee
weken 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 paragraaf
gaat in op de verschillende statistieken die bekend zijn omtrent functieon-
derzoeken. Hierbij kan gedacht worden aan de frequentie, de doorlooptijd
en 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 proces
dat doorlopen wordt bij een functieonderzoek. Daarna worden alle betrok-
ken partijen bij een dergelijk functieonderzoek op een rij gezet. Tenslotte
is er per functieonderzoek binnen LabNoord een weergave van het proces
opgenomen, aan de hand van DFD’s (Data Flow Diagrams).

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

Een patiënt komt op afspraak bij zijn/haar eigen huisarts. De huisarts on-
derzoekt de patiënt 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 patiënt
wil laten ondergaan. Ook aanvullende informatie, zoals medicatie die de
patiënt inneemt, of de klachten die de patiënt ondervindt, kan hij hierop
kwijt.
Dit ingevulde aanvraagformulier wordt aan de patiënt meegegeven, waar-
na de huisarts een afspraak voor de patiënt maakt bij LabNoord. De mede-
werker van LabNoord roostert de afspraak, afhankelijk van het betreffende
onderzoek, handmatig (Schuursoft) dan wel automatisch (LABOSYS) in.
Vervolgens gaat de patiënt op het afgesproken tijdstip naar LabNoord.
Een laborant van LabNoord krijgt een kopie mee van de planning, en weet
hierdoor welke patiënten hij/zij die dag kan verwachten. Deze laborant ont-
vangt de patiënt in de onderzoekskamer op de functieafdeling. De patiënt
overhandigt 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 procedure
juist 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 patiënt
plaats neemt op de onderzoekstafel, neemt de laborant vervolgens plaats
achter het echoscopie apparaat. Vervolgens neemt de laborant met behulp
van het apparaat foto’s van de blaas. Aan de foto’s, voegt de laborant
met behulp van de software van het onderzoeksapparaat extra informatie
toe. Deze informatie kan bijvoorbeeld de naam en de afmetingen van het
gefotografeerde lichaamsdeel zijn. Op deze manier is het voor een specialist
makkelijker om een beoordeling te doen. Deze foto’s worden vervolgens op
A6 formaat faxpapier afgedrukt. In totaal gaat het bij een echoscopie om
ongeveer 15 afgedrukte foto’s per onderzoek. Nadat alle foto’s zijn genomen
is het onderzoek voor de patiënt voltooid en kan deze weer naar huis.
De laborant vult de waarnemingen gestructureerd in op een papieren
werklijst. Als de laborant deze werklijst heeft ingevuld, bundelt hij het ge-
heel van aanvraagformulier, foto’s en de werklijst. Daarna overhandigt de
laborant, 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 werklijst
toe, van het type Schuursoft of LABOSYS. Dit formulier wordt gebruikt
door specialisten om de beoordeling op in te vullen. Een administratief
medewerker van de functieafdeling legt de onderzoeksgegevens klaar, welke
vervolgens door een bode worden opgehaald.
Een bode neemt dagelijks alle klaarliggende onderzoeken van LabNoord
mee en brengt deze naar het Martini Ziekenhuis waar specialisten deze beoor-
delen. De specialisten bekijken het aanvraagformulier, de foto’s, de werklijst
van de laborant, en vullen hun beoordeling met de hand in op de specialisten
werklijst.
Alle beoordeelde onderzoeken komen op een stapel te liggen en worden
eens per dag door de bode weer naar LabNoord gebracht. De bode geeft de
onderzoeken af bij de administratie van de functieafdeling. De administratie
vult de gegevens (werklijst specialist), afhankelijk van waar het in wordt
bijgehouden, handmatig in Schuursoft of LABOSYS in.
Elk uur worden de nieuw ingevoerde beoordelingen gecontroleerd door
een medewerker van de ICT afdeling van LabNoord. In het geval dat hij
geen onregelmatigheden signaleert, zal hij de beoordeling definitief in het
systeem doorvoeren. Mocht er zich wel een probleem voordoen, dan wordt
er contact gezocht met de betreffende specialist.
Aan het einde van de dag, worden alle nieuw ingevoerde beoordelingen
uitgeprint 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 onderzoek
binnen heeft gekregen, zal hij de uitslag met de patiënt bespreken.

4.1.2 Betrokkenen
In deze paragraaf worden alle betrokken partijen bij een functieonderzoek
op een rij gezet:

Huisarts
De huisarts initieert een functieonderzoek bij LabNoord, en maakt de uit-
eindelijk uitslag weer bekend bij de patiënt.

Patiënt
De patiënt is de persoon waar het uiteindelijk allemaal om draait; de zorg-
afnemer. De patiënt is erbij gebaat dat hij/zij snel en correct geı̈nformeerd
wordt.

Laborant
De laborant neemt het functieonderzoek af bij de patiënt. De laborant is
een medewerker van LabNoord.

Specialist
De specialist beoordeelt het afgenomen functieonderzoek en is in dienst van
één van de aangesloten ziekenhuizen.

Administratief medewerker functieafdeling


De administratief medewerker van de functieafdeling voert de beoordeelde
functieonderzoeken in het Schuursoft of LABOSYS systeem in.

Administratief medewerker postafdeling


De administratief medewerker van de postafdeling van LabNoord verwerkt
het binnenkomend telefoonverkeer. Deze medewerker verzorgt tevens de
planning van de functieonderzoeken en zorgt ervoor dat de uitslagen van
het onderzoek via de post naar de huisarts worden verstuurd.

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

ICT
Beheert 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 stromen
binnen 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 zien
die doorlopen worden per functieonderzoek.
Zoals uit de diagrammen is af te lezen, wordt er bij sommige onderzoeken
nog gebruik gemaakt van de Schuursoft. In de loop van 2005 zullen de
onderzoeken allemaal worden omgezet naar LABOSYS. In overleg met het
hoofd van de ICT afdeling van LabNoord is besloten om geen rekening te
houden met Schuursoft voor de toekomstige situatie.
Daarnaast is te zien, dat er op de applicaties die gebruikt worden bij de
functieonderzoeken, ook patiëntendossiers bijgehouden worden in de lokale
databases. Deze lokale databases worden ten eerste gebruikt voor back-up
doeleinden door de laboranten. In het geval van een anomaliteit, kan het
desbetreffende onderzoek er nog bij worden gezocht. Nog belangrijker is dat
de opgeslagen onderzoeken, in het geval van een nieuw onderzoek, gebruikt
worden voor een vergelijking. Op deze manier kan het ziektebeeld van een
patiënt over een bepaald tijdsbestek bekeken worden. Aan de hand hiervan
kan 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 met
behulp van een ‘unieke’ patiëntcode. Deze is meestal gebaseerd op de eerste
vier letter van de achternaam, gecombineerd met de geboortedatum. Hier-
door komt het nog wel eens voor dat patiëntgegevens met elkaar verstrengeld
raken omdat twee patiënten dezelfde ‘unieke’ code blijken te hebben.

4.2 Statistieken proces


Hier zal een korte analyse worden gemaakt van de gemiddelde volumes en
frequenties van onderzoeken. In de volgende tabel staat een overzicht van
het 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 de


toekomst 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 onderzoeken
zijn stappen zeven, acht en negen iets anders, maar kosten ongeveer even-
veel tijd. Het proces in het schema dat gestippeld staat weergegeven, is een
proces 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 met
behulp van een LabNoord aanvraagformulier en maakt telefonisch een
afspraak.

2. De patiënt komt op het afgesproken tijdstip naar LabNoord voor het


onderzoek.

3. Een medewerker van LabNoord neemt het onderzoek af.

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

5. Een externe specialist beoordeelt de gegevens en stelt aan de hand van


zijn 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 worden
aangeboden via WebNoord.

De totale minimale doorlooptijd is 10 dagen, 1 uur en 42 minuten. Gezien


er geen afspraken zijn met specialisten, kan de tijd die de specialist nodig
heeft voor het beoordelen variëren. Dit is minimaal één werkdag.

11
4.3 Remote Diagnostic System
Het Remote Diagnostic System (RDS) is een systeem dat in 2004 door twee
stagiaires gerealiseerd is, en gebruikt wordt voor de automatisering van het
fundusonderzoek. Het fundusonderzoek is momenteel het enig geautoma-
tiseerde functieonderzoek binnen LabNoord. Deze applicatie is tot stand
gekomen als oplossing voor hetzelfde probleem als staat beschreven in de
opdrachtomschrijving (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 geautomatiseerd
kunnen worden. Omdat deze applicatie reeds een jaar binnen de organisatie
operationeel 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 applicatie
behandeld, gevolgd door het elektronische beoordelingsgedeelte van RDS.
Vervolgens wordt de beveiliging van RDS behandeld. Tot slot worden de
zwakke 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 kunnen
vervolgens met behulp van OptiLink geëxporteerd worden naar een map
op de lokale hardeschijf, in elk gangbaar afbeeldingsformaat. De applica-
tie maakt geen deel uit van RDS, maar is nodig om onderzoeksgegevens te
genereren.

4.3.2 DataLink
DataLink is een voor RDS ontwikkelde client applicatie, die de patiëntgegevens
(als XML) koppelt met de fundusfoto’s (uit OptiLink) en deze vervolgens
doorstuurt naar de server op het Martini Ziekenhuis ter beoordeling. Deze
applicatie staat lokaal op elk van de onderzoekscomputers geı̈nstalleerd en
haalt de foto’s uit de map waar ze door OptiLink naartoe geëxporteerd zijn.

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

12
worden gedownload en opgenomen in LABOSYS. Om het uur worden deze
nieuwe beoordelingen handmatig bekeken. Mits deze beoordelingen worden
goedgekeurd, worden ze definitief ingevoerd en zullen in uitgeprinte vorm
via 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 van
DataLink en hiermee patiënt gegevens opvragen en onderzoeksresultaten
opsturen. Deze onderzoeksgegevens worden via een onbeveiligde FTP ver-
binding over een VPN lijn verstuurd naar de FTP-server. Een specialist
kan in het ziekenhuis, een met een sleutel beveiligde kamer binnenlopen en
inloggen op de applicatie. Vanaf daar kan hij via een onbeveiligde HTTP
verbinding onderzoeken te beoordelen. De gebruikersgegevens worden bijge-
houden in een XML bestand en de onderzoeksgegevens worden opgeslagen
op het filesysteem van de webserver. De onderzoeksgegevens staan op een
publiekelijk toegankelijk gedeelte van de webserver. Hier kan dus direct naar
gelinkt 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 kan


dus niet ingezet worden voor andere, soortgelijke onderzoeken zonder
de gehele applicatie aan te passen.

• Er moet per computer een client applicatie geı̈nstalleerd worden, die


ontworpen is voor een specifiek besturingssysteem, in het huidige geval
Windows 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 applicatie
maakt. Alleen binnen het VPN van LabNoord kan de applicatie ge-
bruikt worden.

• Als er een verandering in de werklijst (lijst voor waarnemingen en


advisering) doorgevoerd wordt, zal een programmeur in de code van
de applicatie moeten duiken om het aan te passen.

• De schaalbaarheid van de RDS applicatie is niet groot. Maar gezien


het 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 opleveren
voor de RDS applicatie. Wel neemt de responstijd van de applicatie
af, naarmate er meer onderzoeken mee afgenomen worden. Dit komt
doordat RDS geen gebruik maakt van een database, en alle te beoor-
delen onderzoeken in één map geplaatst worden. Bij het opvragen van
een onderzoek, zal in het slechtste geval de gehele verzameling van
entries (bestanden) doorlopen moeten worden.

Voordelen:

• Door de koppeling die RDS heeft met de fundusapplicatie OptiLink,


worden de patiëntgegevens automatisch ingevuld, en kunnen gelijk in
de lokale database gebruikt worden.

• De applicatie zorgt ervoor dat er minder fouten worden gemaakt met


het overnemen van onderzoeksgegevens.

• De applicatie zorgt voor een significante vermindering in de tijd en


kosten voor het afnemen van een fundusonderzoek. Dit vanwege het
verlagen van de benodigde tijd, om een onderzoek af te nemen en het
verminderen van het aantal fouten.

• De patiënt heeft theoretisch sneller de uitslag van een functieonderzoek


dan de papieren methode.

14
5 Gewenste situatie
In dit hoofdstuk wordt de gewenste situatie geschetst. Bij het formuleren van
deze situatie is de haalbaarheid van de oplossing uiteraard een belangrijke
factor. 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 met
de voorschriften die vastgesteld zijn vanuit de overheid. Tenslotte is deze
gewenste situatie gevormd aan de hand van de wensen en eisen van de klant
en 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 paragraaf
met een lijst van alle requirements en recommendations. Tenslotte is in de
laatste paragraaf een conclusie opgenomen.

5.1 Richtlijnen
Bij het bepalen van de opties voor het formuleren van de gewenste situatie, is
de afbakening van mogelijkheden door de overheid van cruciaal belang. Een
belangrijk aspect is bijvoorbeeld, dat vanaf één januari 2006 de NEN7510
[12], met verdere uitwerkingen in de NEN7511 [13] en NEN7512 [16], als
officiële richtlijn geldt voor ICT in de zorg. In de toekomst zullen zorg-
verzekeraars van de zorginstellingen eisen, dat aan deze richtlijnen wordt
voldaan. 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 de


volgende wetten:

• Wet geneeskundige behandelingsovereenkomst vindplaats: Burgerlijk


Wetboek, 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, en
de eisen vanuit de organisatie, kan er een lijst van requirements en recom-
mendations gedefinieerd worden waaraan de oplossing moet voldoen. Deze
lijst is hieronder opgenomen.
De eisen en wensen vanuit de organisatie zijn opgesteld aan de hand van
interviews onder de betrokkenen en op basis van bestaande documentatie
binnen LabNoord.

5.2.1 Requirements
• Webapplicatie realiseren ter verhoging van de efficiëntie, minimaal toe-
pasbaar op het ECG onderzoek.

• Webapplicatie moet betrouwbaar en veilig zijn, conform de richtlijnen


gedefinieerd 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 een


specialist.

• 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 patiëntgegevens


automatisch 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 de
ICT afdeling gepresenteerd op woensdag 21 september 2005 en aangenomen
als 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 richtlijnen
vanuit 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 modelplanning
volledig via LABOSYS verlopen, en hoeft niet meer met de hand opgesteld
te worden, zoals bij sommige onderzoeken het geval was. Als een patiënt
een afspraak maakt bij de functieafdeling, wordt dit ingepland met behulp
van LABOSYS. Zodra de afspraak is ingepland, gegenereert LABOSYS au-
tomatisch een labnummer. Dit labnummer is de unieke code waarmee het
betreffende 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 functieonderzoek
waar hij die dag werkzaam is, een planning mee. De patiënt komt naar Lab-
Noord om het onderzoek af te nemen. De laborant ontvangt de patiënt en
neemt plaats achter een computer waarop de onderzoeksspecifieke software
is 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 patiëntgegevens uit LABOSYS automatisch in
in de onderzoeksspecifieke applicatie, zonder tussenkomst van de gebruiker.
De laborant kan vervolgens het onderzoek afnemen met de software van
het desbetreffende functieonderzoek, en exporteert de onderzoeksresultaten
naar een map. Hierna benadert de laborant de webapplicatie en neemt het
labnummer over van de planning. Aan de hand van dit labnummer kan de
applicatie de patiëntgegevens uit LABOSYS erbij halen. Nu vult de labo-
rant zijn/haar bevindingen in op de digitale werklijst. Door middel van een
client-side applicatie, die overgezonden wordt vanaf de server en leesrechten
heeft op de lokale schijf van de client, worden de onderzoeksresultaten auto-
matisch gekoppeld aan de patiëntgegevens. Dit geheel wordt ter beoordeling
aangeboden aan specialisten.

5.3.3 Beoordeling
Periodiek maakt een specialist, via een beveiligde verbinding, contact met de
webapplicatie om te controleren of er onderzoeken beschikbaar gesteld zijn
ter beoordeling. Gezien de hoge frequentie waarmee onderzoeken aangebo-
den worden, is het onpraktisch om de specialist te notificeren van de nieuw
binnengekomen onderzoeken. De specialist beoordeelt de onderzoeken elek-
tronisch. De resultaten worden direct, zonder tussenkomst van menselijk
handelen, in LABOSYS gezet.

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

5.4 Visualisatie
In deze paragraaf wordt een beknopt overzicht gegeven van het proces dat
doorlopen wordt bij een functieonderzoek in de gewenste situatie. Dit over-
zicht is vergelijkbaar met figuur 2 in paragraaf 4.2, waarin de huidige situatie
weergegeven wordt. De nummering van de twee figuren komt overeen, zodat
1
Met het “pushen” van een applicatie, wordt bedoeld dat de gebruiker de applicatie
ontvangt, zonder dat deze er expliciet om vraagt.

18
deze makkelijk vergeleken kunnen worden. In de gewenste situatie is de bode
overbodig geworden omdat alle gegevens digitaal verzonden worden. Daar-
om is er bij deze stappen geen tijdsaanduiding meer nodig. Dit resulteert in
het 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 telefonisch
een afspraak gemaakt.
2. De patiënt komt op het afgesproken tijdstip naar LabNoord voor het
onderzoek.
3. Een LabNoord medewerker neemt een onderzoek af en onderzoeksge-
gevens worden gestuurd naar DODS.
4. Een externe specialist beoordeelt de onderzoeksresultaten en geeft aan
de hand van deze beoordeling een advies. De applicatie genereert aan
de 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 huisarts
of specialist.

19
Deze geschetste situatie heeft een minimale doorlooptijd van 8 dagen, 1 uur
en 42 minuten. Het elektronisch overzenden van de onderzoeken via DODS
zorgt 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 het
momenteel nog niet realiseerbaar alle huisartsen de uitslagen elektronisch
aan te bieden. De huisartsen zijn niet verplicht een internetverbinding te
nemen 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 reden
zal ook het aanvragen van een onderzoek voorlopig met formulieren blijven
verlopen.

5.5 Conclusie
In deze paragraaf worden de belangrijkste eigenschappen van de voorgestelde
oplossing 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 toekomst
moet de applicatie makkelijk aan te passen zijn als een functieonder-
zoek veranderd of bijkomt. Dit is noodzakelijk omdat het buitensporig
veel tijd en geld zou kosten om voor elk functieonderzoek een aparte
applicatie te bouwen. Aangezien voor elk onderzoek een vergelijkbare
procedure geldt met minieme verschillen, is dit realiseerbaar.

• Ten tweede moet de generieke applicatie compatible zijn met de meest


uiteenlopende software en hardware configuraties. Het moet niet zo
zijn 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 het
internet, en welke conform zijn met de richtlijnen zoals gesteld in de
NEN7510. Op deze manier kunnen er in de toekomst eenvoudig andere
ziekenhuizen 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 maken
aan de werking van de applicatie. Zo zou er een applicatie gemaakt
kunnen worden om werklijsten makkelijk aan te maken en/of te mute-
ren. Deze werklijsten zouden dan door de applicatie ingelezen kunnen
worden.

• Ten vijfde dient het project duidelijk afgebakend te worden. Gezien


de 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. Dit
framework 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 dit
project, twee functieonderzoeken via de generieke webapplicatie geau-
tomatiseerd gaan worden. Op deze manier kan de werking van het
generieke framework gedemonstreerd worden. Het maken van afspra-
ken voor functieonderzoeken en het terugrapporteren naar de huisarts
vallen buiten dit project. Enerzijds vanwege het genoemde gebrek aan
tijd, anderzijds omdat het automatiseren van deze processen met de
bestaande technische infrastructuur nog niet te realiseren is. Wel zou,
gebruikmakende van het generieke framework, een oplossing hiervoor
binnen handbereik moeten zijn.

21
6 Advisering
In dit hoofdstuk wordt een analyse gegeven van de mogelijkheden omtrent
het 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 gezocht
kan worden. Ten eerste mogelijkheid is binnen de organisatie een oplossing
te ontwikkelen, danwel de RDS applicatie aan te passen zodat deze vol-
doet aan de eisen. Ten tweede is er de mogelijkheid het aankopen van een
bestaande applicatie. De derde mogelijkheid is het out-sourcen van de ont-
wikkeling aan een derde partij en de vierde mogelijkheid is een combinatie
van de drie.

6.1.1 Ontwikkeling intern


Gezien LabNoord gebruik maakt van afstudeerders als ontwikkelaars, vereist
dit een relatief lage investering. Wel moet er rekening gehouden worden dat
de oplossing niet volledig afgemaakt kan worden binnen de looptijd van de
stage. Het project zal dus over moeten worden gedragen aan of een nieuwe
stagiair, of LabNoord personeel. Daarnaast is LabNoord verantwoordelijk
voor het functioneren van de oplossing, en zal LabNoord zelf, de problemen
die kunnen voorkomen moeten oplossen. Dit zal tijd en dus geld kosten.
Voor deze risico’s krijgt LabNoord wel een maatwerk oplossing terug. Deze
oplossing zal voldoen aan elk van de door LabNoord opgestelde eisen. Tevens
zal de oplossing makkelijk te integreren en toe te passen zijn in de bestaande
omgeving.
Er kan gekozen worden een compleet nieuwe applicatie te bouwen, of de
RDS applicatie te modificeren. De laatste lijkt de meest voor de hand lig-
gende optie, maar er zijn enkele beperkingen. Argumenten die RDS minder
geschikt maken zijn:

• De omgevingsvariabelen staan statisch in de applicatie en zijn hierdoor


lastig aan te passen.

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

• De applicatie voldoet niet aan de richtlijnen opgesteld in de NEN7510


specificatie.

• 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 laten


voldoen. Dit ook vanwege het ontbreken van documentatie van de RDS
software. Deze punten in overweging nemend, zal het uiteindelijk minder tijd
kosten een nieuwe applicatie te verwezenlijken. Daarom wordt geadviseerd
om bij de bouw van een applicatie binnen LabNoord, te kiezen voor de
ontwikkeling van een compleet nieuw product. Het is aan te raden de RDS
oplossing uitgebreid te analyseren voordat de nieuwe oplossing ontworpen
wordt, zodat de fouten die zijn gemaakt bij de ontwikkeling van RDS niet
nogmaals 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 voldoen
aan de eisen van LabNoord. Er zijn veel bedrijven die automatiserings-
oplossingen aanbieden voor de medische wereld. Enkele daarvan zijn Unit
4 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 om
het elektronisch recepten verkeer (erv), een dienst voor het uitwisselen van
recepten tussen huisartsen en apothekers.
Het probleem bij deze aangeboden pakketten is dat ze deeloplossingen
aanbieden voor het beschreven probleem. Zo heeft een pakket bijvoorbeeld
de 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 dat
tegemoet kan komen aan de opgestelde eisen. Dit betekent dat er meerdere
pakketten moeten worden aangeschaft of een bestaand pakket ingrijpende
aan te passingen om aan de specifieke eisen van de organisatie te voldoen,
dit vergt een grote investering. Deze investering biedt nog geen garanties
dat de oplossing alle wensen dekt. Hiernaast is het aanpassingsvermogen
van deze oplossing gering, wat in de toekomst tot nog meer investeringen
kan leiden. Hieronder worden de voor- en nadelen van de aanschaf van een
bestaande 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 het
project wordt uitbesteed. Daarnaast draagt de derde partij alle risico’s die
een dergelijk omvangrijk project met zich meebrengt. Omdat een bestaande
applicatie een bewezen concept is, kan men vrijwel zeker van zijn dat het
op een voorspelbare manier zal functioneren. Mocht dit niet het geval zijn,
dan kan de externe partij daarop aangesproken worden. Daarnaast is bij de
aanschaf 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 besteden
aan een externe partij. Dit vergt een grote investering maar heeft buiten
dit punt alleen maar voordelen. Extern laten ontwikkelen legt vrijwel geen
extra werkdruk op LabNoord ICT personeel en de risico’s van het correct
functioneren van de applicatie zijn geheel voor de externe partij. Tevens kan
worden opgegeven waar de applicatie allemaal aan moet voldoen. Zo moet
deze naadloos in de LabNoord omgeving passen en moet de oplossing elk
van de requirements dekken. Tenslotte kunnen afspraken worden gemaakt
met 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 het
uitbesteden van de ontwikkeling, het aanwenden van een bestaand pakket
en het intern ontwikkelen. Hierbij kan bijvoorbeeld gedacht worden aan het
aanwenden van één of meer bestaande pakketten, waarbij de ontbrekende
functionaliteit 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 een
volledige 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 oordeel
wordt 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 een
extern bedrijf de beste optie is, het intern ontwikkelen van de oplossing komt
als één na beste naar voren.

6.3 Besparingen
In deze paragraaf worden de besparingen besproken die mogelijk gemaakt
kunnen worden in het geval dat de voorgestelde oplossing gerealiseerd wordt
op één van de bovenstaande manieren. Er zal gekeken worden naar de tijd
die op de functieafdeling bespaard kan worden, als het versturen, afnemen
en verwerken van functieonderzoeken digitaal verloopt. Op deze manier kan
de 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 kosten
per functieonderzoek, wordt in dit overzicht alleen ingegaan op de kosten
van de medewerkers binnen de functieafdeling. In de onderstaande tabel
wordt eerst een overzicht gegeven van de verschillende medewerkers binnen
de functieafdeling, met daarbij het uurloon en het aantal minuten dat de-
ze medewerkers in de huidige situatie per werkdag aan tijd kwijt is aan
functieonderzoeken. 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.
a
Bedragen 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 voor
de verschillende functies binnen de afdeling in de huidige situatie berekend
worden. Omdat op de functieafdeling geen overzichten worden bijgehouden

25
van het aantal fouten dat maandelijks voorkomt, wordt een aanname van
20 fouten per maand per functieonderzoek gebruikt. De meeste fouten zijn
door een administratief medewerker van de functieafdeling binnen 15 minu-
ten op te lossen. Er zijn echter ook problemen waar men gemiddeld tot een
uur 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, is
opgenomen 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,-
a
Administratief medewerker bezig met invoeren van onderzoeken
b
Administratief 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 de
nieuwe situatie. In deze situatie is de bode overbodig geworden. Aange-
zien de invoer van onderzoeken automatisch gaat, zal een administratief
medewerker 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 per
onderzoek 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 dat
op 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 de
knelpunten kunnen liggen, hoe deze opgelost kunnen worden en welke punten
er nog verbeterd kunnen worden aan het proces. Zo zijn er sommige onder-
delen van de procedures onbekend bij de medewerkers zelf, en weten niet
waarom ze worden uitgevoerd. Door deze procedures goed onder de loep
te nemen, kunnen in de huidige situatie al maatregelen genomen worden
die het afnemen en verwerken van functieonderzoeken op de functieafdeling
efficiënter maken.

6.4 Conclusie
Aan de hand van de voorgaande hoofdstukken, waarbij een duidelijk beeld is
geschetst van het probleem, de oplossing en de verschillende mogelijkheden
tot het bewerkstelligen van deze oplossing, wordt nu een advies gegeven met
betrekking tot de te volgen stappen. Zoals in de doelstelling staat beschre-
ven gaat dit onderzoek over hoe LabNoord de effectiviteit en de efficiëntie op
de functieafdeling kan verhogen, om op deze manier kosten, tijd en fouten
tot een minimum te beperken. Elk van de genoemde oplossingen kosten geld
om te realiseren. Maar gezien de fouten die nu worden gemaakt zorgen voor
verlies van tijd, moet de oplossing worden gezien als een investering welke
op termijn geld gaat besparen. Deze kostenbesparing is terug te vinden in
paragraaf 6.3. Hieruit blijkt dat op jaarbasis 2496 manuur kan worden be-
spaard. Daarnaast leidt het verminderen van fouten tot een hogere kwaliteit
van zorgverlening.

Na al de alternatieven te hebben overwogen, is het advies het extern laten


ontwikkelen van de oplossing aan de hand van het in dit verslag opgeno-
men onderzoek. LabNoord krijgt op deze manier een oplossing die aan al
de wensen voldoet zonder dat dit extra risico’s met zich mee brengt. Daar-
naast wordt op deze manier vermeden dat de ICT afdeling van LabNoord
extra belast wordt. Mochten in de toekomst ingrijpende veranderingen aan
de gerealiseerde oplossing gedaan moeten worden, bijvoorbeeld ten gevolge
van nieuwe wetgeving, zal dit door de externe partij bewerkstelligd kunnen
worden. Dit heeft niet direct impact op de werklast van de ICT afdeling.

Dit advies, met bijbehorende analyse, is aan de opdrachtgever van LabNoord


gepresenteerd. Deze heeft ervoor gekozen de oplossing voor het probleem,
dat beschreven staat in hoofdstuk 3, de opdrachtomschrijving, vanwege fi-
nanciële redenen intern te laten realiseren. In bijlage D.1.1 is een overzicht
opgenomen 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 van
analyse tot realisatie worden geëvalueerd.

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 deze
applicatie gerealiseerd kan worden.
In het vervolg, als er gerefereerd wordt naar de applicatie, is dat onder de
naam 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 van
de applicatie, de koppelingen van de applicatie, de gebruikers van de appli-
catie en de gebruikersprocessen binnen de applicatie. Daarnaast wordt er
nog ingegaan op specifieke onderdelen; namelijk het logproces en de backup
faciliteiten.
De onderdelen spreken in principe voor zichzelf. Bij de koppelingen van
de applicatie, worden de koppelingen bedoeld die DODS heeft met andere
applicaties (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 figuur
3 in paragraaf 5.4, zoals deze werd voorgesteld voor de gewenste situatie.
Daarnaast is hieronder ook een volledige opsomming van het vernieuwde
proces weergegeven:

• Een patiënt komt op afspraak bij de huisarts.

• De huisarts onderzoekt de patiënt.

• In het geval dat de huisarts diepgaander onderzoek verricht wil zien,


vult deze een LabNoord aanvraagformulier.

• Dit aanvraagformulier wordt aan de patiënt meegegeven.

• De dokter, assistent of patiënt zelf maakt een afspraak bij LabNoord


voor het onderzoek (telefonisch).

• De postafdeling van LabNoord roostert deze afspraken via LABOSYS


in.

• De patiënt overhandigt aan de aanwezige laborant van LabNoord het


aanvraagformulier.

28
• Laborant neemt functieonderzoek af bij patiënt.

• De onderzoeksgegevens worden bewaard in de lokale database van de


betreffende functieapplicatie.

• De laborant exporteert de onderzoeksgegevens naar een map op de


lokale schijf.

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


tiëntgegevens.

• De laborant vult een elektronische werklijst voor waarnemingen in met


DODS.

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


ver.

• Een specialist logt in op het DODS systeem en bekijkt de nieuwe


onderzoeken die op de DODS server staan.

• Specialist stelt elektronisch een beoordeling op.

• DODS genereert van een beoordeeld onderzoek een EDIFACT bericht


en stuurt dit digitaal naar de LABOSYS query server van LabNoord.

• De query server verwerkt en controleert de EDIFACT berichten en


voert deze automatisch in LABOSYS in.

• Elk uur worden alle nieuwe beoordelingen in LABOSYS handmatig


gecontroleerd en definitief ingevoerd.

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

• De beoordelingen worden naar de postafdeling gebracht om vervolgens


in een envelop naar de huisarts gestuurd te worden met kopie van
onderzoek.

• Huisarts ontvangt uitslag functieonderzoek LabNoord via de post en


bericht de patiënt. 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 uiterlijk
van 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 bevindingen
ingevoerd (werklijst) en bijvoorbeeld de labcode opgegeven. Tijdens het
beoordelen door de specialist worden hier alle onderzoeksgegevens gepresen-
teerd, inclusief de bijbehorende afbeeldingen. Links hiervan bevindt zich de
algemene navigatiebalk (2) waarmee alle stappen in de huidig geselecteerde
procedure overzien en geselecteerd kunnen worden. Onderaan het venster
is een andere navigatiebalk aanwezig (3) waar de knoppen “volgende” en
“vorige” weergegeven worden. Hiermee kan tussen de verschillende stappen
van 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 aantal
fouten dat gemaakt wordt tijdens het doorlopen van het proces, en het
verminderen van de benodigde tijd voor het afnemen en verwerken van een
onderzoek. Uiteindelijk zou dit ook tot een reductie van de operationele
kosten moeten leiden.

7.1.4 Gebruikers applicatie


Binnen het systeem zijn er vier verschillende gebruikersgroepen te definiëren.

• Applicatiebeheerders

• Systeembeheerders

• Laboranten

• Specialisten

30
De applicatiebeheerders van DODS kunnen onder andere nieuwe gebruikers
toevoegen, muteren en verwijderen. Daarnaast kunnen ze logbestanden be-
kijken en instellingen binnen de applicatie wijzigen. Hierbij kan gedacht
worden 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 het
server 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 groep
vult bevindingen in op de elektronische werklijst en koppelt de gegenereerde
onderzoeksbestanden aan het betreffende onderzoek.
De specialisten beoordelen de onderzoeken die door de laboranten zijn
afgenomen. 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. Huisartsen
en specialisten zullen in eerste instantie alleen de resultaten ontvangen. Dit
is mogelijk op papier of als EDIFACT bericht. In de toekomst kunnen huis-
artsen en specialisten ook aangesloten worden op de digitale diensten van
LabNoord en kan deze groep ook via DODS de onderzoeksgegevens inzien.

7.1.5 Koppelingen applicatie


DODS heeft verschillende koppelingen met externe applicaties. Voor elk van
de functieonderzoeken worden er verschillende softwarepakketten gebruikt
om onderzoeksbestanden te genereren. Hieronder staat een overzicht per
functieonderzoek 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 gebruiker
zich 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 aan
bepaalde rechten, verkrijgt deze toegang tot bepaalde delen van het sys-
teem. Deze rechten zijn door een beheerder van het systeem instelbaar (zie
applicatiescherm C.1.2).
Nadat de gebruiker zich heeft geı̈dentificeerd, krijgt deze een overzicht
te zien van alle toegangelijke functies, te zien op applicatiescherm C.1.3.
De laborant kiest het onderzoek uit het gepresenteerde overzicht. Daarna
volgt voor een functieonderzoek het onderzoeksscherm C.1.4. Zoals te zien
is op dit scherm, zijn in de linker navigatiebalk alle stappen van de te doorlo-
pen procedure afgebeeld. Deze procedure is soortgelijk voor de verschillende
onderzoeken. Eerst wordt het labnummer ingevoerd dat op de planning aan-
gegeven staat. Hierna worden de gekoppelde patiëntgegevens 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 gegevens
en 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 lijst
van onderzoeken af, door per onderzoek een beoordeling en een advies te
geven. 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 dat
doorlopen 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 belangrijkste


handelingen 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 één van de onderdelen van het beheers-
gedeelte.

32
• beheer logt uit.

Laborant

Hieronder wordt puntsgewijs een opsomming gegeven van de belangrijkste


handelingen 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 uit


de volgende schermen: selecteer labnummer, patiëntgegevens, werklijst,
koppel foto, bevestig gegevens, bevestig verzenden.

• laborant logt uit.

Specialist

Hieronder wordt puntsgewijs een opsomming gegeven van de belangrijkste


handelingen 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 van
welke acties, fouten of problemen hebben kunnen plaatsvinden. Ook onge-
oorloofd gebruikersgedrag is hiermee te traceren en te bewijzen. Om deze
reden moet elke gebruikersactie worden gelogd. Daarnaast moet ook elke
door het systeem gegenereerde foutmelding gelogd worden. Deze foutmel-
dingen kunnen automatisch worden gerapporteerd aan een beheerder door
middel 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, het
IP 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. De
functionaliteit is onder andere afhankelijk van de correctheid van de time-
stamp. Hierdoor is het van belang dat er gebruik wordt gemaakt van een
timeserver 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 een
goede backup voorziening nodig. De onderzoeksgegevens en de resultaten
worden opgeslagen en gebackuped in ofwel de onderzoeksapparaten zelf, of
LABOSYS, 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. Tenslotte
zal 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 deze
gemaakte keuzes naar voren.

7.2.1 Applicatie omgeving


De hoofdapplicatie zal object georiënteerd worden geschreven in PHP5, en
worden 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 bewaard
op een filesysteem. De structuur van de database is terug te vinden in de
bijlage C.3.3. De motivatie voor het gebruik van deze omgeving is terug te
vinden 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 onderhoudbaar
moet zijn. Om het generieke karakter te kunnen garanderen zal de oplossing
bestaan uit kleine eenvoudige bouwstenen. Met behulp van deze bouwstenen
kunnen complexe structuren worden gemaakt. De bouwstenen hebben alle-
maal de zelfde basisstructuur. Deze structuur is afgeleid vanuit de gewenste
situatie. 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, namelijk


een beoordeling.

• Deze beoordeling levert informatie op.

35
Figuur 6: Abstracte weergave oplossing

Dit abstractemodel is de kern van de oplossing en kan worden toegepast


op elk van de onderdelen. Het model zal worden toegepast onder de naam
DODS-script. Een DODS-script is niet een compilebare applicatie maar een
aantal afspraken waaraan het model moet voldoen. Dit kan gerealiseerd
worden in elke willekeurige taal. De applicatie bestaat uit een combinatie
van deze bouwstenen. De volgorde van de bouwstenen wordt bepaald door
een scriptlist. Een scriptlist is niets meer dan een lijstje met namen van
DODS-scripts met eventuele parameters. De afspraken zijn gemaakt met de
volgende punten in gedachte:

• Een DODS-script voert één 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 het


afvangen 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 elk
DODS-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 de
gebruikersinvoer afvangen en doorgeven aan de modules. Als PostProcess
functionaliteit nodig is zal het script dit aanmelden bij het systeem, zodat
de PostProcess functie van het script bij de volgende iteratie van DODS
zal worden aangeroepen. Gezien de aard van een website is deze structuur
noodzakelijk. De gebruikersinput kan immers pas worden afgevangen als de
gebruiker op een link of submit knopt drukt. De volgende pagina weet niet
wat de vorige pagina inhield en kan daarom geen acties hierover uitvoeren.
De Display en PostProcess functies kunnen worden gezien als de twee
informatie stromen in het model. Display, links, is daarbij de inkomende
stroom en PostProcess, rechts, is de uitgaande stroom. De acties worden
uitgevoerd door modules. Deze modules bieden DODS functionaliteit aan,

36
en geven zelf geen output op het scherm. Een voorbeeld van een module is
de Lobosys module. Deze module handelt de communicatie met LABOSYS
af. 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 Log
service. Een overzicht van de gebruikte modules en services is te vinden in
bijlage 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 controleren
van de logingegevens, of voor het veranderen van een interne setting. Ook
kan 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 één of meer DODS-scripts, met nul of
meer parameters. Zo kan bijvoorbeeld een parameter aan een scriptlist wor-
den meegegeven, welke ervoor zorgt dat de navigatie niet zichtbaar is. Een
DODS-scripts kan ook parameters meekrijgen vanuit de scriptlist. Hierin
staat bijvoorbeeld naar welk fileformaat gezocht moet worden bij het zoe-
ken naar onderzoeksbestanden. Een DODS-script voert één specifieke actie
uit, bijvoorbeeld het weergeven van patiënt gegevens, een scriptlist voert één
specifieke procedure uit, bijvoorbeeld een fundus onderzoek. DODS-scripts
worden 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 één manier
doorlopen kan worden. Dit is nodig bij het afnemen van een onderzoek waar
eerst een patiënt gekozen moet worden voor er gegevens aan gekoppeld kun-
nen worden (zie figuur C.1.4 in de bijlage). Dit is echter niet bruikbaar bij
het 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). Een
voorbeeld van een scriptlist is terug te vinden in bijlage C.3.5.

37
De hoofdapplicatie is door gebruik van DODS-scripts erg eenvoudig. Deze
functioneert alleen als een soort linker die kiest welke actie uit een scriptlist
geladen 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 één of meer modules
en 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 hoofdapplicatie
besproken. Eerst zal er gekeken worden naar de interface, vervolgens naar
de beveiliging en toegangsrechten. Daarna wordt de implementatie van de
werklijsten 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 de
huisstijl van WebNoord gebruikt. In de hoofdapplicatie zullen de methodes:
‘header, menu en footer’ worden aangevraagd. Deze drie methodes handelen
het uiterlijk af. De menu methode geeft een menu weer aan de hand van
de gekozen scriptlist. De onderdelen van het menu zijn de in de scriptlist
aanwezige 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 worden
geladen 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 is
er bijvoorbeeld de variabele in de module ‘Labosys’, met als naam ‘hostna-
me’ met als waarde een IPadres. In het beschrijvingsveld staat een korte
beschrijving welke zichtbaar is op settings beheerpagina (zie C.1.7) waar de
variabelen makkelijk aantepassen zijn. In DODS is deze variabele overal
beschikbaar 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 SSL
verbinding 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 van
LabNoord een persoonlijke key welke ze moeten installeren in hun internet
browser. Zowel de server als de gebruiker kan vanaf dat moment de authen-
ticiteit van de ander controleren. Alleen als beide partijen het hier over eens
zijn kan er gebruik worden gemaakt van de diensten.
Zodra een gebruiker DODS benadert zal deze zich moeten identificeren
aan de hand van een gebruikersnaam en een wachtwoord. Het wachtwoor-
den systeem zal zich gedragen conform de richtlijnen opgesteld in NEN-EN
12251 [10] (“Health informatics Secure User Identification for Health Ca-
re Management and Security of Authentication by Passwords”) specificatie.
Er is maar één gebruiker per gebruikersnaam. De SHA-256 hash van het
wachtwoord van een gebruiker wordt opgeslagen in de database, daardoor is
de informatie niet terug te leiden naar het oorspronkelijk wachtwoord.
In de security module staan de encryptie algoritmes en functies. Mocht
er in de toekomst worden gekozen voor een andere encryptie methode, dan
hoeft slechts op één 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 eerste
instantie zal DODS te maken hebben met drie gebruikersgroepen: labo-
ranten, specialisten en beheerders. Dankzij het generieke karakter van de
scriptomgeving is een degelijk rechtensysteem mogelijk. Met behulp van de
rechtenstructuur 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 voorbeeld
zal een schildklier echoscopie onderzoek worden weergegeven. Gebruiker-
stoegang wordt uitgedeeld op het subsection niveau (niveau 2). Zo kan een
beheerder een gebruiker toegang geven tot elke subsubsection die onder de
subsection ‘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 velt
zijn oordeel aan de hand van de antwoorden en de onderzoeksgegevens. De
applicatie biedt de specialist een aantal mogelijkheden voor advies, en de
mogelijkheid tot het maken van een opmerking. De vragen zijn gekoppeld
aan één bepaald onderzoek. De antwoorden op deze vragen moeten worden
opgeslagen als een EDIFACT bericht en de antwoorden moeten worden ge-
koppeld aan de LABOSYS fieldtag zodat het systeem weet bij welke vraag
een 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 worden
opgeslagen staan ze geheel los van het systeem, waardoor geen kennis van
het systeem nodig is om onderzoeksvragen aan te passen. Een tweede voor-
deel is dat XML files dankzij de duidelijke structuur makkelijk te veranderen
zijn en het geen vereiste is om het hele systeem te kennen. Daarnaast kan
de 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 waarop
de 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 met
de index van de array. Hierbij moet er wel rekening worden gehouden, dat
als de structuur van het XML bestand verandert, deze mapping niet meer
overeenkomt, en mogelijk fouten zal genereren. Om dit probleem te voor-
komen moeten veranderingen in de structuur van het XML bestand worden
opgeslagen onder een andere versie. Bij het opslaan van de antwoorden op
de vragen in de database, moet het versienummer van het XML bestand
worden 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 LABOSYS
te exporteren. Helaas kan LabNoord door een gebrek aan mankracht deze
mogelijkheid niet aanbieden en zal dit via een omweg moeten worden ge-
realiseerd. De onderzoeksgegevens kunnen alleen worden aangeboden als
EDIFACT bericht. EDI, Electronic Data Interchange, wordt binnen Lab-
Noord gebruikt als communicatie medium voor onderzoeksgegevens. Voor
het oversturen van rapporten wordt er gebruik gemaakt van de in 1993 gede-
finieerde MEDRPT standaard. Nadat een specialist de onderzoeksgegevens
heeft gezien en zijn werkformulier heeft ingevuld, wordt een EDIFACT be-
richt gegenereerd. Dit bericht wordt gegenereerd aan de hand van het XML
bestand en de antwoorden van de onderzoeker en de specialist. Dit EDI-
FACT bericht wordt op het filesysteem van de server opgeslagen. Op de
LABOSYS server draait een script dat elke minuut deze folder controleert
en de EDIFACT berichten ophaalt en verwerkt. De berichten worden één
maal per uur handmatig gecontroleerd en goedgekeurd. Daarna wordt de
uitslag 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 gedeelte
ook een client-side gedeelte nodig. Hier wordt deze applicatie, MagicLinker
genoemd, 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 patiëntgegevens. Dit houdt in dat eerst de onderzoeksbe-
standen (meestal foto’s) van de lokale harde schijf van de client verzameld
worden, en vervolgens doorgestuurd worden naar de DODS server.

41
Doordat het koppelen van de onderzoeksbestanden automatisch verloopt
door 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 MagicLinker
uit te leggen, is hieronder een schematische weergave opgenomen:

Figuur 10: Schematische weergave DODS MagicLinker.

Ten eerste neemt de laborant het onderzoek af bij de patiënt met behulp van
het software pakket dat speciaal voor het functieonderzoek bedoeld is. De-
ze applicatie genereert onderzoeksbestanden welke in een map op de lokale
schijf opgeslagen worden. De clientside applicatie MagicLinker haalt deze
lokaal opgeslagen bestanden vervolgens automatisch op, aan de hand van
vooraf opgegeven parameters. MagicLinker wijzigt eventueel het formaat,
comprimeert de bestanden en verstuurt ze naar een DODS module aan de
kant 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 om


gebruik te maken van JAVA technologie. Voor de MagicLinker applicatie
specifiek zal er gebruik gemaakt worden van een JAVA applet.
Door gebruik te maken van server-side “push” wordt de applicatie naar
de gebruiker verzonden. Dit betekent dat de applicatie niet bij de gebruiker
geı̈nstalleerd hoeft te zijn. De applicatie is alleen aanwezig op de server.
Op deze manier kan de software makkelijk ge-update worden en hebben de
gebruikers altijd de nieuwste versie. De applicatie zal in de vorm zijn van
een JAVA Applet. De Applet draait binnen de omgeving van de webbrowser.
Omdat een JAVA Applet standaard geen rechten heeft om een lokale schijf
te raadplegen, zal er gebruik gemaakt worden van een certificaat.
Het generieke karakter van de applicatie blijkt uit de mogelijkheid om de
applicatie volledig aan te sturen met behulp van parameters. Hierin worden
bijvoorbeeld de syntax van het te vinden onderzoeksbestand opgegeven, het
pad van de te doorzoeken map en het type functieonderzoek. De applicatie
is daarnaast volledig opgebouwd uit modules. Op deze manier kan gemak-
kelijk een nieuw onderzoek aan de applicatie worden toegevoegd. Ook zijn
er standaardmodules aanwezig die door elk van de geı̈mplementeerde func-
tieonderzoeken gebruikt kunnen worden. Zo is er functionaliteit voor het
converteren 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’ in
HTTPS staat voor secure en maakt gebruik van SSL om gegevens met Ma-
gicLinker beveiligd te verzenden. De reden voor het gebruik van een HTTPS
POST 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 procedurele
veranderingen en het inrichten van een omgeving waarbinnen de oplossing
kan functioneren. Nadat deze afhankelijkheden afgehandeld zijn, kan de ge-
realiseerde oplossing geı̈mplementeerd worden.

Patiëntcodes omzetten

Zoals in paragraaf 4.1.3 beschreven staat, worden er momenteel binnen de


lokale databases van de onderzoeksspecifieke applicaties, patiëntcodes ge-
hanteerd die niet uniek zijn. Met behulp van deze patiëntcodes worden
afgenomen onderzoeken geı̈ndexeerd. Het terugzoeken van onderzoeken, ge-
beurt aan de hand van deze “unieke” sleutel. Hierdoor kan het voorkomen
dat onderzoeken van patiënten verstrengeld raken, en de patiënten dezelfde
“unieke” patiëntcode blijken te hebben.
Om dit proces te automatiseren zal er uniform gebruik moeten worden
gemaakt van één identificatie nummer per patiënt. Daarom is het eerst nood-
zakelijk dat de codes in de lokale databases vervangen worden door echt unie-
ke patiëntcodes zoals deze in LABOSYS bekend zijn. Deze patiëntnummers
gelden alleen binnen het LabNoord domein. Buiten de organisatie wordt
gebruik gemaakt van NAW gegevens in combinatie met geboortedata. In te
toekomst zal hier het burgerservicenummer voor gebruikt worden.

Opzetten en inrichten server

Verder moet een server ter beschikking gesteld worden waarop DODS kan
draaien. Een analyse voor de benodigde capaciteit van deze server is te-
rug te vinden in bijlage C.3.2. Tevens moeten enkele software pakketten
geı̈nstalleerd worden, zoals deze in bijlage B, de ontwikkelomgeving, be-
sproken worden. De server moet binnen het VPN van LabNoord geplaatst
worden zodat deze benaderbaar is vanaf zowel de functieafdeling, als de
specialisten 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 aangepakt
hadden kunnen worden. Tevens schenken we aandacht aan de punten die
wel voor herhaling vatbaar zijn, en waardevol kunnen zijn voor medewerkers
binnen de ICT afdeling van LabNoord.
Het hoofdstuk gaat ten eerste in op de organisatorische aspecten van
het project, vervolgens op de planning van het project en tenslotte op de
toegepaste 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 duidelijk
was, is het verstandig geweest te kiezen voor een “agile” ontwikkelmetho-
de. De verwachting was namelijk dat de requirements tijdens het project
nog zouden veranderen. Dit gebeurde inderdaad en door middel van deze
ontwikkelmethodiek kon daar goed op worden ingespeeld. Een ander voor-
deel van “agile” ontwikkelen, is de integratie van testen gedurende het hele
proces. Door veel te testen, konden moeilijkheden snel geı̈dentificeerd en
aangepakt worden. Als de modules de testen hebben doorlopen, kan de ge-
teste functionaliteit met verlaagde kans op bugs worden aangeboden. Het
gebruik van unittests verhoogt dus de kwaliteit van de code en resulteert
dus in een betere oplossing.
Daarnaast kunnen de opdrachtnemers aanraden, gebruik te maken van
hulpfaciliteiten zoals CVS en Wiki. Met behulp van een CVS konden de
bronbestanden van het project overzichtelijk en makkelijk tussen de ont-
wikkelaars gedeeld worden. Zelfs als er bij een project maar een enkele
ontwikkelaar betrokken is, is het aan te raden gebruik te maken van een
CVS implementatie. Zo kunnen bijvoorbeeld eerder ontwikkelde modules in
een later stadium door een andere ontwikkelaar binnen LabNoord gebruikt
worden voor de realisatie van een andere applicatie. Het gebruik van Wiki
is ook aan te raden. Wiki is een softwareapplicatie waarmee webdocumen-
ten gezamelijk kunnen worden bewerkt. Wiki is tijdens dit project gebruikt
om een logboek bij te houden, de voortgang te bewaken en om overzicht te
houden op de verschillende taken binnen het project.
Tijdens de organisatie van het project is te weinig aandacht besteed aan
de afhankelijkheden die voor het project van belang waren. Een voorbeeld
is het omzetten van de patiëntcodes in de databases die voor de functieon-
derzoeken geraadpleegd worden. Een ander voorbeeld is het plaatsen van de
server op lokatie in het Martini ziekenhuis. Hoewel deze problemen al in een
vroeg stadium gemeld zijn, was het wellicht verstandiger geweest deze voor
de 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 voorgestelde
realisatie houdt in dat tenminste twee functieonderzoeken geautomatiseerd
zijn en volledig geı̈mplementeerd zijn in het systeem. Uiteindelijk heeft de
voorgestelde implementatie geen vorm kunnen krijgen vanwege een gebrek
aan tijd.
Tijdens het project zijn diverse requirements toegevoegd, welke extra
ontwikkeltijd veroorzaakten. Er is te weinig rekening gehouden met de tijd
die nodig was om het stageverslag te schrijven. Dit was in zijn geheel niet
in 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 de
applicatie kan schaduwdraaien. Op deze manier kan de werking van de
oplossing gedemonstreerd worden. Tevens kan dan nog aandacht worden
besteed aan de taken die voltooid moeten worden om het project correct te
kunnen overdragen aan de ICT afdeling van LabNoord. Nadat het project is
overgedragen, is het de bedoeling dat twee medewerkers van de ICT afdeling
het project zullen voortzetten. De medewerkers zullen de DODS applicatie
uitbreiden zodat deze voor alle functieonderzoeken toegepast kan worden.
Om in de toekomst een betere planning te maken, is het verstandig extra
ruimte open te laten tussen activiteiten. Op deze manier kan de planning
beter gehandhaafd blijven. De opgestelde planning was tamelijk strikt en
liet 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 aspecten
van de techniek besproken worden.

8.3.1 Generiek karakter


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

45
Eén van de nadelen van een generieke applicatie, is dat hij voor zoveel
doeleinden toegepast kan worden, dat het makkelijk is van de daadwerkelijke
kern van de opdracht af te dwalen. Zodra duidelijk werd wat er mogelijk was
met DODS, kwamen er veel nieuwe wensen naar voren vanuit de betrokkenen
bij het project. Voorbeelden zijn het raadplegen van functieonderzoeksre-
sultaten door de huisarts en het automatiseren van de aanvraagformulieren
voor de huisarts. Vanwege de korte duur van het afstudeerproject, was het
realiseren 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 applicatie
in PHP, die via een webbrowser geraadpleegd kan worden. Door gebruik te
maken van een JAVA Applet voor de client-side, is nog een extra dimensie
aan 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 Windows
XP systeem met IIS 5.0. Toen in een later stadium van het project de
applicatie overgezet is op een Linux testserver met Apache, bleek dit geen
problemen 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 een
kwestie van het doorlopen van een simpele wizard. Door DODS te koppelen
aan een servercertificaat van een CA, was de procedure voltooid.
Door de keuze voor JAVA technologie, waren er legio mogelijkheden voor
de client-side kant van DODS. Door middel van een zogenaamde SSLSocket
kon er eenvoudig een verbinding gerealiseerd worden met een beveiligde
DODS module.
Uiteindelijk is er besloten, voor extra veiligheid, om ook clientcertificaten
te gaan gebruiken. Hierbij zal de server zich moeten identificeren bij de client
en visa versa. Om dit zo kostenloos mogelijk te realiseren, zal bij voorkeur
een LabNoord CA server ingericht moeten worden.
Voor de ICT afdeling van LabNoord is het verstandig om te kijken naar
de veiligheid van elk van de door LabNoord gebruikte applicaties. Zoals in
de NEN7510 beschreven staat, is het veilig overzenden van patiëntgegevens
één van de richtlijnen. Als deze richtlijnen in de toekomst definitief verplicht
worden, 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 konden
worden binnen het project. Zo was er op het gebied van de techniek veel
toepasbare kennis. Hierbij kan gedacht worden aan het ontwerpen van een
database, het modelleren van een systeem, gebruikersinteractie visualiseren
doormiddel van UML diagrammen en het toepassen van design patterns. De
opleiding gaat goed in op de techniek en het is te merken dat veel gegeven
thema’s binnen de opleiding goed aansluiten bij de bedrijfssituatie.
Aan de andere kant waren er wel organisatorische en verslagtechnische
aspecten waar vanuit de opleiding weinig aandacht aan besteed was. Eén
hiervan was het opstellen van een analyse voor een klant. Binnen een bedrijf
zal er meestal eerst een analyse verricht moeten worden om te achterhalen of
het zinvol is een bepaald project op te zetten. Hierbij is het heel belangrijk
zicht te hebben op de situatie, te kunnen identificeren waar de problemen
liggen en mogelijkheden te kunnen aandragen om deze problemen op te
lossen. Ook is het hierbij belangrijk de klant ervan te kunnen overtuigen
dat het project de moeite is om uit te gaan voeren.
In de projecten tijdens de opleiding is de analyse meestal gegeven. Er
kan 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 project
zo wordt aangepakt, maar er zou bijvoorbeeld een apart kwartaal gewijdt
kunnen worden aan dit onderwerp. Dit kan in combinatie gedaan worden
met presentatietechnieken waarbij verschillende projectgroepen een analyse
opstellen en deze presenteren aan de klant. Deze kiest dan uiteindelijk voor
één van de partijen. Het zou waardevol zijn om meer van dit soort vakken
te kunnen volgen binnen de opleiding. Dit zou bijvoorbeeld aangeboden
kunnen 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 dat
een bepaald bedrijf de beste oplossing aandraagt, maar als het niet goed op
papier overgezet kan worden, is de kans klein dat voor deze oplossing geko-
zen wordt. Uit ervaring blijkt dat het bedrijf met de beste presentatie de
opdracht toegewezen krijgt, ondanks dat het niet de beste oplossing hoeft
te 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:

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

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 worden
gegeven 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 simpelste
variant, waarbij alleen binnen de organistatie van LabNoord het proces ge-
automatiseerd is. De twee andere varianten boden ook nog de mogelijkheid
voor huisartsen om de aanvraag, en het raadplegen van de resultaten van
een functieonderzoek elektronisch te kunnen verrichten. Hiermee zou het
gehele proces van een functieonderzoek geautomatiseerd zijn. Binnen het
tijdsbestek van dit project bleek dit niet haalbaar.
Het doorvoeren van procedurele veranderingen binnen een organisatie
blijft een lastige zaak, en om ook de huisartsen en specialisten daarbij te
betrekken bleek een te grote opgave. Een deel van de procedure blijft dus
vooralsnog met de hand verlopen.

9.2 Hoe automatiseren


Voor deze automatiseringsoplossing is er gekozen voor een applicatie met een
generiek karakter. DODS is het resultaat van deze opzet. Hierdoor kunnen
met DODS alle functieonderzoeken binnen LabNoord geautomatiseerd wor-
den. Maar biedt het ook de mogelijkheid om breder ingezet te worden. Zo is
er reeds voor de Diabetesdienst een statisch model voor diabetes patiënten
in het systeem geı̈mplementeerd, die door huisartsen gebruikt kan worden
om 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 door
de gebruiker via een webbrowser benaderd kan worden. DODS gebruikt een
beveiligde verbinding en verstuurd de onderzoeksgegevens via een HTTPS

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

9.3 Kosten automatiseren


De kosten die het automatiseringsproject met zich mee hebben gebracht zijn
laag gebleven in vergelijking tot een gemiddeld, soortgelijk project (zie bij-
lage D.2). Vooral door het onderzoek en de realisatie van de oplossing uit
te 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 medewerkers
van LabNoord. Deze zullen het product implementeren binnen LabNoord
en uitbreiden voor gebruik bij alle functieonderzoeken. Hierdoor zullen de
kosten toenemen. Daarnaast zal binnen LabNoord nog een applicatie- en
systeembeheerder aangewezen moeten worden, om de uiteindelijke applicatie
te onderhouden.
De investering zal worden terugverdient doordat op de functieafdeling
kosten bespaart worden (zie ook paragraaf 6.3). Dit besparen van kosten
is tweedelig; enerzijds worden er kosten bespaard omdat het invoeren van
onderzoeken geautomatiseerd wordt, anderzijds worden er kosten bespaard
omdat 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 procedurele
kant verder uit te werken. Het advies is om voor de verschillende betrokken
partijen overeenkomsten vast te leggen in de vorm van Service Level Agree-
ments (SLA). Een SLA is een contract tussen een klant en een leverancier
over het te leveren niveau en het type service. Aan de hand van een SLA kan
worden 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 functieonderzoek
te bepalen. Deze informatie is echter van belang voor zowel de patiënt als
LabNoord.

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

49
10 Literatuuropgave
Hierin zijn alle bronnen opgenomen die tijdens het maken van dit verslag
geraadpleegd zijn.

Referenties
[1] LabNoord <info@labnoord.nl>, “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. <info@businessissues.nl>, “Wat is
een 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 oktober
2003.
[8] Greving, H.J. en Harris, V., Eindverslag RDS: Remote Diagnostic Sy-
stem, Groningen, 2005.
[9] Netcraft <webmaster@netcraft.com>. “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 Security
of Authentication by Passwords, Delft, 2004
[11] Nederlands Normalisatie-instituut, Handboek NEN 7510, Delft, versie
1.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 NEN
7510 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 NEN
7510 voor samenwerkingsverbanden, Delft, oktober 2005

[15] Nederlands Normalisatie-instituut, NEN-NL 7511-3: Medische infor-


matica - Informatiebeveiliging in de zorg - Toetsbaar voorschrift bij NEN
7510 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
Dynamic Online Diagnostic System

Bijlagen

W. Hofsta & C. Jager

Datum: 18 januari 2006


Instituut: LabNoord Huisartsenlaboratorium
Plaats: 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 patiënt krijgt van de huisarts een LabNoord aanvraagformulier
mee, waarop deze de gewenste onderzoeken aankruist.

2. De patiënt maakt een telefonische afspraak met LabNoord voor een


echoscopie.

3. De patiënt komt met het aanvraagformulier op het afgesproken tijdstip


naar LabNoord voor het onderzoek.

4. De laborant controleert voor het onderzoek de adresgegevens en de


geplande met de aangevraagde onderzoeken. Vervolgens neemt de la-
borant met de hand de patiëntgegevens over in het echoscopie pro-
gramma.

5. Het onderzoek wordt afgenomen. Er worden per onderzoek ongeveer


12 foto’s gemaakt die alleen afgedrukt worden.

6. Nadat het onderzoek is voltooid, zal de laborant op een zogenaamde


werklijst zijn/haar bevindingen noteren.

7. Dit geheel (aanvraagformulier, foto’s en werklijst), zal per bode naar


het Martini ziekenhuis gebracht worden waar de radioloog een diagnose
zal stellen (op werklijst).

8. Het aanvraagformulier, de foto’s en de werklijst met diagnose gaan


vervolgens weer per bode terug naar LabNoord.

9. De werklijst wordt handmatig in de LABOSYS database ingevoerd


voor de desbetreffende patiënt.

10. De uitslag van het onderzoek gaat per post naar de huisarts. De
werklijst en het aanvraagformulier worden opgenomen in het archief
bij de Functieafdeling.

2
A.1.3 DFD ergo onderzoek

Figuur 12: DFD ergo onderzoek

3
A.1.4 Procedure ergo onderzoek
1. De patiënt krijgt van de huisarts een LabNoord aanvraagformulier
mee, waarop deze de gewenste onderzoeken aankruist.

2. De patiënt maakt een telefonische afspraak met LabNoord voor een


ergometrieonderzoek.

3. De patiënt komt met het aanvraagformulier op het afgesproken tijdstip


naar LabNoord toe voor het onderzoek.

4. De laborant controleert voor het onderzoek de adresgegevens en de


geplande met de aangevraagde onderzoeken. Vervolgens neemt de la-
borant met de hand de patiëntgegevens 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 ziekenhuis
gebracht 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 ingevoerd


voor de desbetreffende patiënt.

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

4
A.1.5 DFD fundus onderzoek

Figuur 13: DFD fundus onderzoek

5
A.1.6 Procedure fundus onderzoek
1. De patiënt krijgt van de huisarts een LabNoord aanvraagformulier
mee, waarop deze de onderzoeken aankruist.

2. De patiënt maakt een telefonische afspraak met LabNoord voor een


fundus onderzoek.

3. De patiënt komt met het aanvraagformulier op het afgesproken tijdstip


naar LabNoord voor het onderzoek.

4. De laborant controleert voor het onderzoek de gegevens van de patiënt.


Als er iets niet klopt, zal de laborant dit op de afspraaklijst noteren.

5. De laborant leest vervolgens met een barcode apparaat het labnummer


uit (van de afspraaklijst), waarna de patiëntgegevens automatisch uit
het LABOSYS systeem ingevuld worden in de fundus software.

6. Er worden een paar standaard vragen gesteld, waarna de foto’s van de


ogen genomen worden (twee per oog).

7. Nadat het onderzoek is voltooid, zal de laborant via FTP de foto’s


en de bijbehorende gegevens naar een server sturen op het Martini
ziekenhuis. De foto’s worden ook op het echo apparaat zelf opgeslagen.

8. De oogarts van het Martini ziekenhuis bekijkt via een web applicatie
deze 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 plaatst


de 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 patiënt krijgt van de huisarts een LabNoord aanvraagformulier
mee, waarop deze de gewenst uit te voeren onderzoeken op aankruist.

2. De patiënt maakt een telefonische afspraak met LabNoord voor een


long onderzoek.

3. De patiënt komt met het aanvraagformulier op het afgesproken tijdstip


naar LabNoord toe voor het onderzoek.

4. De laborant controleert voor het onderzoek de adresgegevens en de


geplande met de aangevraagde onderzoeken. Vervolgens neemt de la-
borant met de hand de patiënt gegevens over in het long programma.

5. Vervolgens wordt het onderzoek afgenomen, waarbij de bevindingen


geregistreerd 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 ziekenhuis
gebracht worden, waar de longarts een diagnose zal stellen (op werk-
lijst).

8. Het aanvraagformulier, uitslagen en de werklijst met diagnose gaan


vervolgens weer per bode terug naar LabNoord.

9. De werklijst wordt handmatig in de SchuurSoft database ingevoerd


voor de desbetreffende patiënt.

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

8
A.1.9 DFD dexa onderzoek

Figuur 15: DFD dexa onderzoek

9
A.1.10 Procedure dexa onderzoek
1. De patiënt krijgt van de huisarts een LabNoord aanvraagformulier
mee, waarop deze de gewenst uit te voeren onderzoeken op aankruist.

2. De patiënt maakt een telefonische afspraak met LabNoord voor een


DEXA onderzoek.

3. De patiënt komt met het aanvraagformulier op het afgesproken tijdstip


naar LabNoord toe voor het onderzoek.

4. De laborant controleert voor het onderzoek de adresgegevens en de


geplande met de aangevraagde onderzoeken. Vervolgens neemt de la-
borant met de hand de patiënt gegevens over in het DEXA programma.
Waar mogelijk haalt de laborant eerdere DEXA onderzoeken erbij uit
het archief.

5. Vervolgens worden de benodigde röntgen 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 röntgen
apparaat.

7. Dit geheel (aanvraagformulier, foto’s en oude onderzoeken), zullen sa-


men met een werklijst uit het LABOSYS systeem, per bode naar het
Martini ziekenhuis gebracht worden, waar de radioloog een diagnose
zal stellen (op werklijst).

8. Het aanvraagformulier, foto’s, oude onderzoeken en de werklijst met


diagnose gaan vervolgens weer per bode weer terug naar LabNoord.

9. Dit geheel (aanvraagformulier, foto’s en oude onderzoeken, radioloog


ingevulde werklijst), zal per bode naar het Martini ziekenhuis gebracht
worden, waar de internist een diagnose zal stellen (op werklijst).

10. Het aanvraagformulier, foto’s, oude onderzoeken en de werklijst met


complete diagnose gaan vervolgens weer per bode weer terug naar
LabNoord.

11. De werklijst wordt handmatig in de LABOSYS database ingevoerd


voor de desbetreffende patiënt.

12. De uitslag van het onderzoek gaat per post naar de huisarts. De
werklijst en het aanvraagformulier worden opgenomen in het archief
bij de Functie afdeling.

10
A.2 Opdrachtomschrijving
OMSCHRIJVING CORE BUSSINES
Elektronisch berichtenverkeer/medisch laboratorium

OMSCHRIJVING KONTEKST OPDRACHT


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

OMSCHRIJVING STAGE OPDRACHT


Bouw 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. Houdt
rekening met gebruikersgemak van de applicatie. Er kan gebruik worden gemaakt van een
applicatie die een vergelijkbaar proces ondersteunt voor fundusfotografie. Bij de ontwik-
keling van de applicatie dient expliciet het generieke karakter van de te bouwen applicatie
te worden benadrukt zoals schaalgrootte en bestandsgrootte. Naast het ontwikkelen van
de applicatie is het van belang dat de afstudeerders een advies opstellen omtrent hardware
en netwerkeisen. Hierbij dient aandacht te worden besteed aan onderwerpen zoals net-
werkcapaciteit en opslagcapaciteit in relatie met bestandsgrootte, bestaande netwerken en
aansluitingen etc.

GEVRAAGDE BELANGSTELLING / AANDACHTSGEBIEDEN


Deze opdracht is uitgebreider dan alleen een programmeer opdracht. Omdat nog niet
geheel duidelijk is hoe de applicatie precies zal moeten gaan werken (Dicom of JPEG
formaat) 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 zullen
uitspraken moeten doen over programmeertalen en databases die gebruikt moeten wor-
den. Vervolgens zullen de stagiairs goede conceptuele analytische vaardigheden dienen
te 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. Als
laatste dienen de stagiairs zich goed in te kunnen leven in de eindgebruiker zodat de
mens-computer component goed wordt uitgewerkt en er een gebruikersvriendelijke inter-
face wordt gebouwd.

GEVRAAGDE PERSOONLIJKE EIGENSCHAPPEN


Goede 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 welke
ontwikkelmethode en ontwikkeltools er beschikbaar zijn en wat de voor- en
nadelen daar van zijn ten opzichte van de randvoorwaarden van het project.
Ook zal er naast de hard- en software eisen van de omgevingen naar de
licentiemodellen en de eventuele kosten worden gekeken.
Gezien de applicatie zich zal bevinden in een productieomgeving en er
vertrouwelijke patiënt gegevens worden weergegeven en opgeslagen is het van
belang dat in deze omgeving veiligheid, betrouwbaarheid en beschikbaarheid
voorop staan. Hiernaast moet de omgeving makkelijk aan te passen zijn,
aangezien er in de toekomst nieuwe onderzoeken kunnen bijkomen of huidige
onderzoeken veranderen van methodiek of apparatuur. Tevens is er de eis
dat de omgeving makkelijk moet zijn te beheren. In paragraaf 4.2 is te lezen
dat de volumes nu en in de toekomst relatief laag zijn, hierdoor is hoge
schaalbaarheid 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 volgende
gedeelte zullen enkele ontwikkelmethodes worden behandeld.

B.1.1 Waterfall
Waterfall is een software ontwikkelmodel waarin het ontwikkelproces gezien
kan 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. Royce
in 1970, een grote voorstander van iterative ontwikkelprocessen.

B.1.2 RUP
RUP, Rational Unified Processis een iteratief software development proces
ontworpen door de Rational Software Corporation, tegenwoordig een divisie
van IBM. RUP beschrijft manieren om effectief software te ontwikkelen door
gebruik te maken van bewezen methodes. Hierbij worden methoden gezocht
die goed passen bij het project en het bedrijf. RUP wordt veel toegepast bij
grote bedrijven met grote ontwikkelteams die tegelijkertijd meerdere grote
projecten uitvoeren.

12
B.1.3 Agile
Extreme programming is een moderne manier van het inrichten, plannen en
uitvoeren van software ontwikkelingstrajecten. Het uitgangspunt van XP
is dat de eisen ten aanzien van software in de loop der tijd zullen wijzigen
ten 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 geheel
vastgelegd. Om hier rekening mee te houden en er snel op in te kunnen
springen 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 worden
binnen 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 gebruiker
zijn PC, om van die PC onderzoeksgegevens te verzamelen en te versturen
naar de server. Alleen gebruikers die onderzoeksgegevens toevoegen hebben
te 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 ontwikkel


technologien̈ 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 twee
belangrijke verschillen. Microsoft heeft ASP.NET helemaal opnieuw opge-
trokken, gebaseerd op Common Language Runtime (CLR) welke al de .NET
talen ondersteunen. Programmeurs kunnen ASP.NET code schrijven door
gebruik te maken van één van de door het .NET framework ondersteunde
talen. Zoals Visual Basic.NET, JScript.NET, of (standardized) C#. Daar-
naast kunnen deze ook gebruik maken van een open-source taal als Perl en
Python. Een voordeel ten opzichte van script talen is dat ASP.NET gecom-
pileerd wordt naar één of meer DLL’s wat de prestaties ten goede komt.

Perl

Practical Extraction and Reporting Language (Perl) is een open-source


general-purpose programmeeromgeving origineel ontwikkeld voor tekst ma-
nipulatie. Tegenwoordig wordt Perl voor een grote verscheidenheid van ta-
ken gebruikt zoals systeemtools, web development, network programming
en vele andere. De opzet van de taal is hoofdzakelijk gericht om praktisch
(efficiënt 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 procedureel
en objectgeorienteerd programmeren, biedt krachtige interne support voor
text processing en beschikt over een erg grote database met modules van
derde 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 geworden
en wordt door de meeste hosting bedrijven standaard beschikbaar gesteld
als 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 Framework


Redistributable EULA” licentie. Microsoft biedt een versie van het .NET
framework aan voor UNIX omgevingen onder de naam “Shared source CLI”,
maar verbiedt expliciet het gebruik van dit pakket voor commerciële doelein-
den. Mono is een open-source project, opgezet door Ximian (tegenwoordig
Novell), om een .NET omgeving te maken die aan de ECMA standaard vol-
doet. Mono bied onder andere een C# compiler en een Common Language
Runtime. 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 zijn
veel discussies over Mono omtrent de licenties, men is er niet over uit of
Microsoft, als ze dat wil, Mono kan verbieden doordat Mono gebruik maakt
van door Microsoft gepatenteerde ideeën.

Perl

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

PHP

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

B.2.3 Kosten
De directe en indirecte kosten van de programmeeromgevingen zullen in het
volgende gedeelte worden behandeld.

ASP.NET

Voor het gebruik van ASP.NET is een licentie op het .NET framework nodig
en 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 hier
een 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 deze
clientside applicatie ook “gepushed” kan worden richting de gebruiker. Hier-
door kan elke willekeurige PC onderzoeken afnemen. Voor deze doeleinden
zijn 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 browsers
en werd geı̈ntroduceerd in 1995 door Sun. Java Applets worden ondersteund
door vrijwel elke browser, mits er op de client een JRE is geı̈nstalleerd. Ap-
plets draaien doorgaans in een ‘sandbox’ binnen een browser, door gebruik
te maken van een certificaat kan de Applet meer toegang tot het systeem
verschaffen.

ActiveX

ActiveX, vroeger OLE, is een technologie van Microsoft, gemaakt ten behoe-
ve van de communicatie tussen verschillende componenten. ActiveX, alleen
beschikbaar voor Internet Explorer, heeft, als de gebruiker accepteert om
het component te gebruiken, volledige toegang tot de gebruiker zijn sys-
teem. Deze technologie wordt door veel beveiligingsexperts als één van de
grootste veiligheid problemen binnen Internet Explorer gezien.
2
Free/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 de
omgeving hiervan af is het niet meer te gebruiken. Een Java Applet daaren-
tegen is cross-platform, en biedt toegangsrestricties dankzij het gebruik van
certificaten 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 de
projectduur 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 PHP
kennis aanwezig. Hierdoor gaat dan ook de voorkeur uit naar het gebruik
van PHP.

Client-side

In tegenstelling tot ActiveX is een Java Applet cross-platform, gratis om


mee te ontwikkelen en te gebruiken, en biedt Java veel extra mogelijkheden
voor beveiliging. De voorkeur gaat dan ook uit naar het gebruik van een
Java Applet als client-side omgeving.

B.3 Webserver
Omdat er vanuit LabNoord is gekozen om een server-side webapplicatie te
realiseren(zie hoofdstuk 3 en logische gevolgtrekking paragraaf B.2), is het
gebruik 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 één na populairste
webserver.
In het verleden was IIS regelmatig het slachtoffer van wormen, zoals de
‘Code Red worm’ en andere zogenaamde exploits. Tot versie 6 draaide IIS
onder een systeem account, wat een mogelijke exploit alle rechten op het
systeem geeft. Veel van deze problemen zijn opgelost in versie 6.0 van de
webserver. 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 uit
1994. 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 de
internet sites geserved door Apache, wat Apache de absolute marktleider op
de webservermarkt maakt. Apache valt onder de “Apache License, Version
2.0” licentie.
Apache bied een breed scala aan mogelijkheden en is goed configureer-
baar. Daarnaast is er een grote hoeveelheid aan modules beschikbaar die de
functionaliteit van Apache nog verder kunnen vergroten. Binnen LabNoord
wordt er gebruik gemaakt van Apache 2.0.55.

B.3.3 Advies
Als er wordt gekeken naar de nieuwste versies, bieden de HTTP servers
beide de vereiste functionaliteit voor de webapplicatie. Ze ondersteunen
de programmeeromgevingen en bieden SSL functionaliteit. Als er wordt
gekeken naar het veiligheidsaspect, heeft Apache een betere reputatie. Sinds
versie 6.0 heeft IIS hier wat aan kunnen bijspijkeren maar de beveiliging blijft
voornamelijk de verantwoordelijkheid van de systeembeheerders. Als deze
groep de systemen goed onderhoudt en update, moeten zowel IIS als Apache
kunnen voldoen aan de eisen. Op het punt van licenties heeft Apache een
groot voordeel, het is geheel gratis tegenover de kosten van een Microsoft
Windows 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 gegevens
later weer terug te halen aan de hand van een van de eigenschappen welke
eerder zijn gedefinieerd. LabNoord beschikt over twee database omgevingen
welke ze zelf beheren en kunnen onderhouden, deze zijn:

• MySQL

18
• Caché

B.4.1 MySQL
MySQL is een open-source multi-threaded, multi-user, Structured Query
Language (SQL) Database Management System(DBMS). Bij LabNoord wordt
er 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 product
niet compatible is met de GPL licentie. Begin oktober 2005 heeft Oracle In-
nobase gekocht, het bedrijf achter de InnoDB technologie. MySQL zal in de
toekomst een fork uitbrengen van de huidige InnoDB code welke ook onder
GPL is uitgebracht. MySQL is enorm populair geworden dankzij de com-
binatie van MySQL met PHP, dat door veel hosting bedrijven aangeboden
wordt.

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

B.4.3 Advies
Het product zal gerealiseerd worden op een nog in te richten demilitarized
zone (DMZ). Vanaf deze DMZ is er geen toegang tot de Caché database
servers 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 worden
binnen deze omgeving. Hierbij kan bijvoorbeeld gedacht worden aan Post-
greSQL, deze biedt functionaliteit die binnen een professionele omgeving in
de 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 vertrouwelijke
patiëntgegevens over het internet verzonden. Het is naı̈ef om te denken
dat een systeem 100% veilig kan zijn, maar er zijn een hoop maatrege-
len die genomen kunnen worden, welke het erg onaantrekkelijk maken voor
een eventuele inbreker, om te proberen informatie te ontvreemden. In de
subparagrafen die volgen zal er dieper ingegaan worden op deze mogelijke
maatregelen.

B.5.1 Cryptografie
Cryptografie houdt zich bezig met het versleutelen van informatie om te
voorkomen dat deze informatie in handen komt van een derde partij. In de
cryptografie wordt encryptie gebruikt om informatie te versleutelen (enco-
deren), gebaseerd op een bepaald algoritme. Encryptie over het internet is
in te delen in symmetrisch en asymmetrisch. Symmetrische encryptie maakt
gebruik van een zogenaamde geheime sleutel. Deze geheime sleutel is alleen
bekend 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 is
dat de sleutel op een of andere manier eerst veilig uitgewisseld moet worden
tussen de ontvanger en verzender. Daarnaast is het zo dat als de sleutel
eenmaal onderschept is, alle verzonden data vanaf dat moment ontcijferd
kan worden.
Een andere manier van encryptie, is asymmetrische encryptie. Asym-
metrische encryptie maakt naast het gebruik van een geheime sleutel, ook
gebruik van een publieke sleutel. Als twee partijen informatie naar elkaar
willen verzenden, zal de ontvanger eerst aan de hand van een geheime sleu-
tel, een publieke sleutel genereren. Deze publieke sleutel is gerelateerd aan
de geheime sleutel en kan door de verzender gebruikt worden om de infor-
matie te versleutelen. Deze publieke sleutel wordt dan vervolgens naar de
verzender verstuurd. De verzender versleutelt dan de informatie met behulp
van de publieke sleutel van de ontvanger en verstuurt dan de data terug.
De ontvanger kan dan met behulp van zijn geheime sleutel de data weer
ontcijferen. Zie figuur 16 voor een schematische weergave van asymmetri-
sche encryptie. Omdat de geheime sleutel nooit mee verzonden wordt, is het
erg moeilijk voor een derde partij de verzonden data terug te voeren naar
de oorspronkelijke informatie. Daarnaast kan er voor elke transmissie een
nieuw sleutelpaar gegenereerd worden. Hiermee wordt het voor een even-
tuele kraker een buitengewoon onrendabele zaak. Nauurlijk is de encryptie
uiteindelijk nog wel te doorbreken met de zogenaamde “brute force” me-
thode, alleen duurt dit erg lang. Indien er een krachtig encryptie algoritme
gehanteerd 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 van
meerdere firewalls. Al het verkeer dat plaats vindt tussen LabNoord en
het internet, gaat via deze firewalls. Deze beveiliging dient om inbraken op
LabNoord systemen te voorkomen.

B.5.3 Autorisatie
Om te voorkomen dat iedereen toegang kan krijgen tot de te realiseren
webapplicatie, is het nodig om gebruik te maken van autorisatie. Iedere
gebruiker die zichzelf toegang tot het systeem wil verschaffen, zal zich dan
eerst moeten identificeren. Dit gaat door middel van een gebruikersnaam
met 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 MD5
wordt dan ook ten strengste afgeraden. In plaats daarvan zou bijvoorbeeld
gebruik gemaakt kunnen worden van SHA-256 hashing.

B.5.4 SSL
Voor het beveiligen van de gehele applicatie, kan gebruik worden gemaakt
van SSL (Secure Socket Layer). SSL is een encryptie protocol voor het be-
veiligen van webcommunicatie over het internet. SSL wordt door de meeste
webservers ondersteunt, en kan daardoor gemakkelijk geı̈mplementeerd wor-
den. SSL maakt gebruik van asymmetrische encryptie zoals het hierboven
reeds behandeld is (zie paragraaf B.5.1). Door middel van certificaten, wel-
ke uitgegeven worden door derde partijen, kan de identiteit van de server
geverifieerd 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 elkaar
verzonden. Vanaf dat moment zal alle communicatie tussen de browser en
de 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 gemakkelijk
toe te passen is. Omdat SSL gebruik maakt van asymmetrische encryptie,
is het relatief veilig om toegepast te worden over het internet. Wel wordt
aangeraden de benodigde server certificaten aan te schaffen via een Certifi-
cate Authority (CA). Ondanks dat certificaten ook zelf aangemaakt kunnen
worden, zijn deze minder makkelijk in het gebruik, omdat er per gebruiker
de browser instellingen aangepast moeten worden om de eigen CA als be-
trouwbaar aan te merken. Een AES 128-bits certificaat met een geldigheid
van 1 jaar is verkrijgbaar voor ongeveer 100 dollar.
Daarnaast is het aan te raden naast de server identificatie, ook gebruik
te maken van gebruiker identificatie. Dit door middel van het uitgeven van
certificaten voor de gebruiker. Ook zal er nog gebruiker identificatie toege-
past moeten worden door middel van het gebruik van een gebruikersnaam
en wachtwoord. Ook een firewall is een goede maatregel om inbrekers te we-
ren, en gezien deze reeds aanwezig is bij LabNoord, hoeven hier geen extra
investeringen gemaakt te worden.

B.6 Kwaliteitsbewaking
Belangrijke elementen van een incrementele ontwikkelmethode zijn de korte
ontwikkelcycli en het testen van elke increment. Speciaal hiervoor moet er
een degelijke testopstelling worden gemaakt waarbij het gemakkelijk is om
snel 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 end
Erich Gamma. JUnit is de meest gebruikte Unit test omgeving voor Java en
is erg uitgebreid. JUnit is geport voor andere omgevingen zoals C# (NUnit)
en C++ (CppUnit), deze familie van unit test frameworks wordt ook wel de
xUnit genoemd.

B.6.2 PHP
Voor PHP zijn er talrijke unit test omgevingen, helaas wordt er maar een
enkele 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 bied
voor PHP 5. SimpleTest is goed gedocumenteerd, biedt veel mogelijkheden
en het wordt goed en regelmatig onderhouden.

PhpUnit

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

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 gratis
te gebruiken. Het advies gaat uit voor het gebruiken van een combinatie
van bovengenoemde omgevingen.

B.7 Versiebeheer
Een gestructureerde ontwikkelomgeving maakt gebruik van versiebeheer, ze-
ker als er meerdere mensen aan hetzelfde project werken. Versiebeheer zorgt
er niet alleen voor dat er makkelijk meer dan één persoon tegelijk aan het-
zelfde onderdeel kan werken, maar ook voor een duidelijker beeld van wat
een 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 of
willekeurige 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 worden
toegepast, 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. De
server bewaart de huidige versie en al de voorgaande versies. Een client haalt
een versie op, voert mutaties uit en stuurt deze later weer terug. Als dit
goed gaat wordt het versienummer van de bestanden automatisch verhoogt
en wordt de gebruikersnaam en zijn commentaar opgeslagen. Mocht het
fout gaan, als bijvoorbeeld iemand anders al eerder hetzelfde gedeelte van
de file heeft aangepast, moet de gebruiker eerst handmatig het verschil goed
zetten 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 worden
verwijdert 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 van
CVS genaamd CVSNT waarvan de eerste versie in 1999 uitkwam voor het
Windows platform en in 2002 beschikbaar was voor GNU/LINUX en UNIX
omgevingen.

B.7.2 SVN
Een aantal belangrijke ontwikkelaars van CVS zijn verantwoordelijk voor
Subversion (SVN), waarvan de eerste versie in 2004 uitkwam. SVN heeft als
doel de vervanging te zijn van CVS door alle functionaliteit van CVS aan te
bieden en in te springen op de wensen van de ontwikkelaars.

B.7.3 Advies
CVSNT of Subversion hebben beide hun voor- en nadelen, deze problemen
zijn hoofdzakelijk aanwezig bij grote projecten waar niet elke ontwikkelaar
root toegang heeft op de repository. Dit is in dit project niet direct van
belang, het gaat hier om een relatief klein project en de ontwikkelaars hebben
volledige toegang. Gezien de opdrachtnemers ervaring hebben met CVS

24
is dat het belangrijkste argument om de voorkeur te laten uitgaan naar
CVSNT.

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

B.8.1 PHP
Voor PHP zijn er veel documentatie projecten die op dit moment niet meer
worden onderhouden. Dit betekent dat ze nieuwe eigenschappen en functies
van PHP niet goed ondersteunen. De support van deze documentatie projec-
ten is vooral een probleem geworden sinds de uitgave van PHP 5, waarin de
taal 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) werken
dan ook niet meer 100%, wat het nut van de documentatie ondermijnt.
De enige documentatie generator welke de nieuwste versies van PHP
ondersteunt 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 en
Mac OS X. De eerste publieke versie kwam uit in oktober 1997 en is nu
naast JavaDoc een van de meest gebruikte documentatie generators.

B.8.2 Java
Voor Java documentatie zijn er maar twee producten welke de benodigde
kwaliteit en mogelijkheden bieden die nodig zijn binnen dit project. Dit
zijn Javadoc en Doxygen, beide worden goed onderhouden en bieden veel
mogelijkheden.

B.8.3 Advies
Voor het documenteren van de PHP code is Doxygen het enige product
welke aan de eisen van het project kan voldoen. Het goed documenteren
van de Java code kan zowel met Doxygen als met Javadoc. Voor het gemak
en efficiëntie gaat de voorkeur uit naar Doxygen zodat er maar met één
programma gewerkt hoeft te worden.

25
B.8.4 Wiki
Naast het documenteren van de sourcecode is het van belang dat de algemene
kennis over het project wordt gedocumenteerd. Onderwerpen als waar staat
de structuur van de gebruikte methode tot welke setting in de webserver is
nodig om het geheel goed te laten functioneren. Om al deze gegevens bij te
houden 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 met
de website. Door middel van een bevestigingsknop, worden de gegevens ge-
controleerd en verschaft de beheerder zich toegang tot een openingsscherm
waarop een welkomst boodschap is weergegeven. Eventueel staan hier ook
nog nieuwsberichten met ontwikkelingen omtrent het DODS systeem. Door
gebruik te maken van de secundaire navigatiebalk, kan de beheerder zijn
proces 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 instellingen
met LABOSYS en voor het plaatsen van een nieuwsbericht. Per onderdeel
moeten de verschillende variabelen weergegeven worden, met daarachter een
invoerveld om deze een waarde te geven. Daarachter staat weer een icoon-
tje, waar eventuele extra informatie onder weergegeven kan worden als de
beheerder met de muiscursor eroverheen beweegt. Met de “volgende” knop
van de secundaire navigatiebalk kunnen de gewijzigde instellingen opgesla-
gen worden, waarna de pagina ververst wordt.
Het logbestanden venster is een venster waarmee alle gebruikersacties en
fouten mee bekeken kunnen worden. In het venster kan een selectie gemaakt
worden door middel van een drop-down box. Er kan gekozen worden om
alle log entries te bekijken, alle fouten, alleen alle gebruikersacties of alle
entries van een specifieke gebruiker. Daarnaast kan er met twee andere
invoervelden de begindatum en de einddatum geselecteerd worden van de
gewenste logacties. Met de “volgende” knop van de secundaire navigatiebalk
kunnen de log entries opgevraagd worden, en zal er binnen het hoofdvenster
een tabel weergegeven worden met alle informatie. In deze tabel zijn de
volgende velden opgenomen: datum, tijd, gebruiker, bericht, eventuele extra
informatie, type (gebruiker of systeem) en het IP adres van de entiteit die
deze actie ondernomen heeft.
In het gebruikersmanagement venster zijn er drie schermen. Een scherm
om gebruikers te muteren, een scherm om gebruikers aan te maken en een
scherm om gebruikersrechten in te stellen. De eerste twee schermen heb-
ben de dezelfde velden, namelijk: loginnaam (bij het mutatiescherm niet
wijzigbaar), gebruikersnaam, email, LABOSYS id, medewerkerscode en een

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

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 deze
een overzicht te zien krijgen van alle onderzoeken waartoe deze laborant be-
voegd is om af te nemen bij een patiënt (impressie in bijlage C.1.3). Binnen
LabNoord is er momenteel de keuze uit: ergometrie, dexametrie, echosco-
pie, fundus- en long onderzoeken. Nadat een laborant met behulp van de
onderzoeksspecifieke software een onderzoek bij een patiënt heeft afgeno-
men en gekozen heeft voor het betreffende onderzoek, kan deze het DODS
systeem gebruiken om waarnemingen op de elektronische werklijst te note-
ren en om de onderzoeksbestanden te koppelen. De navigatieopties met het
eerste hoofdscherm van een onderzoek, zijn te zien in bijlage C.1.4. Zoals
op de navigatiebalk af te lezen is, bestaat het afnemen van een onderzoek
met DODS uit de volgende stappen: selecteer labnummer, patiëntgegevens,
werklijst, koppel foto, bevestig gegevens en bevestig verzenden.
Op het eerste scherm wordt een labnummer ingevuld die bij de laborant
bekend is vanuit de planning van LABOSYS. Door op de “volgende” knop
te klikken, gaat de laborant naar het volgende scherm.
Het tweede scherm, het patiëntgegevensscherm, staan de patiëntgegevens
afgebeeld van de patiënt die gekoppeld zijn aan het opgegeven labnummer.
Aan de hand hiervan kan de laborant controleren of de juiste persoon is
opgevraagd, of dat er informatie niet kloppend is. In dit venster zijn de
volgende gegevens opgenomen: de patiëntnaam, het patiëntnummer, het
geslacht, de straat, postcode, woonplaats, geboortedatum en labnummer.
Als de laborant akkoord is met de gegevens, kan deze zijn weg vervolgen
naar het volgende scherm.
Het derde scherm, het onderzoeksscherm, is de elektronische werklijst
waarop de laborant al zijn bevindingen kan noteren. Deze bevindingen ver-
schillen per onderzoek en zijn dus compleet variabel. Er bevinden zich op de
werklijst combo-boxen, invoervelden, checkboxen en option-boxen. Zo kan
er bij een echoscopie van de onderbuik, bijvoorbeeld genoteerd worden wat
de vulling van de blaas is. Door middel van een option-box kan er gekozen
worden 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. Ook
kan er door middel van een checkbox, prioriteit aan een onderzoek gegeven
worden. Dit kan in het geval dat de laborant waarnemingen tijdens het
onderzoek doet die van dusdanige ernst zijn dat snel handelen gewenst is.
Nadat de laborant alle velden ingevuld heeft, zal deze zijn/haar weg kunnen
vervolgen naar het vierde scherm.
Het koppelscherm (voor impressie zie bijlage C.1.5), koppelt de onder-
zoeksbestanden van de onderzoeksspecifieke applicatie aan de patiëntgegevens
met de bijbehorende werklijst. Hierbij is de “volgende” knop uitgeschakeld.
Dit proces wordt automatisch afgehandeld en vereist geen interactie van de
laborant. Zodra de koppel applicatie klaar is met het koppelen van de on-
derzoeksbestanden, zal de “volgende” knop van de secundaire navigatiebalk
weer ingeschakeld worden, waarna de laborant het onderzoek kan vervolgen.
Het vijfde scherm voor een onderzoek presenteert het geheel nog even op
een rijtje, het geeft de patiëntgegevens weer (zoals op het tweede scherm)
en de gekoppelde onderzoeksgegevens. Deze gekoppelde onderzoeksgege-
vens worden weergegeven door middel van een afbeelding (bij ondersteunde
afbeeldingsformaten), of als link als het gaat om andere typen onderzoeks-
bestanden.
Het zesde en laatste scherm, geeft in het hoofdvenster een bevestiging
weer dat het onderzoek verzonden is, en gereed om beoordeeld te worden.
Door gebruik te maken van de “volgende” knop, wordt de laborant door
DODS weer terugverwezen naar het eerste onderzoeksscherm en kan er een
nieuw onderzoek van dat type afgenomen worden.

C.2.3 Specialist
De specialist beoordeeld de onderzoeken die door de laborant aangeboden
zijn. De specialist logt in doormiddel van zijn/haar gebruikersnaam en
wachtwoord in te voeren in het inlogscherm (bijlage C.1.1). Dit gaat met
precies hetzelfde scherm als die voor een laborant of een beheerder. Na
het welkomstscherm volgt weer het overzichtsscherm waar de specialist de
functieonderzoeken waartoe deze gerechtigd is, kan selecteren om te gaan
beoordelen. Achter de naam staat een getal met het aantal te beoordelen
onderzoeken. Als de specialist op deze te beoordelen functieonderzoeksgroe-
pen klikt, zal deze een overzicht krijgen met een lijst van alle te oordelen
onderzoeken (zie bijlage C.1.6 voor een impressie). Dit is het eerste scherm
voor 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 beoordelen
aantal onderzoeken aangegeven. Uit deze lijst kan een specialist een spe-
cifiek onderzoek aanklikken, of kan deze de “volgende” knop gebruiken om
het eerstvolgende onderzoek te kiezen (uitgaande van de prioriteit).
In het tweede scherm, het analyse scherm, staan in het hoofdvenster
van DODS opeenvolgend: de patiëntgegevens, onderzoeksgegevens, onder-
zoeksantwoorden en tenslotte het advies. De onderzoeksantwoorden bestaan
uit de ingevulde werklijst van de laborant. Het advies is het enige deel dat
de specialist kan invullen. Dit advies gedeelte gebruikt hetzelfde concept als
de laborant werklijst en bestaat uit verschillende typen invoervelden waar-
mee de specialist een diagnose kan opstellen. Deze diagnose kan opgesteld
worden 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 vervolgen
naar het derde scherm. Dit scherm, het bevestig gegevens scherm, laat het
advies nog een keer aan de specialist tonen, zodat deze er zeker van kan zijn
dat de gestelde diagnose de juiste is. De velden zijn nu niet meer te manipu-
leren. Mocht de specialist nog wijzigingen willen aanbrengen, zal deze met
behulp van de “vorige” knop naar het analyse scherm terug kunnen gaan.
Het laatste scherm, het bevestig verzenden scherm, geeft aan de specialist
nog even een bevestiging dat de beoordeling door het DODS systeem is
verwerkt. Door gebruik te maken van de “volgende” knop, zal de specialist
naar 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 in
de 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.

• Patiënt - Bied patiënt 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 warning


berichten 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 ongeveer


1305 onderzoeken per maand afgehandeld. Een gemiddeld onderzoek ge-
negeerd gemiddeld vijf logentries, eenmaal onderzoeksgegevens en eenmaal
antwoorden op de vragen. De benodigde capaciteit van het systeem voor
één onderzoek komt op een totaal van gemiddeld 1028.1 KB. Met een 1305
onderzoeken 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 beoordeel
webpagina’s. Gemiddeld is een webpagina 8 KB groot. Een onderzoeks-
bestand wordt driemaal verstuurd namelijk, tijdens het uploaden naar de
server, tijdens het bevestigen van het onderzoeksbestand en tijdens het be-
oordelen. Gemiddeld is een onderzoeksbestand 1024 KB groot. Daarnaast
genereert DODS, als een onderzoek is afgerond, een EDIFACT bericht van
1 KB groot. Hieruit kan worden afgeleid dat één compleet onderzoek ge-
middeld 3161 KB aan traffic veroorzaakt. Met 1305 onderzoeken per maand
wordt de trafic 4028 MB per maand. Daarnaast worden er per maand on-
geveer 200 beheerpagina’s aangeroepen welke in deze tijdsperiode 1600 KB
aan 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 247
MB 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 navigatie
zichtbaar is en traject controle aanstaat. De variable ‘page’ linkt naar de
filelist. 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 patiënt ge-
gevens worden weergegeven. Tijdens de PostProcess worden de patiënt 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. Ten
eerste wordt een overzicht gegeven van de betrokkenen binnen het project.
Ten tweede worden alle taken binnen het project gegeven. Ten derde zijn
de afhankelijkheden opgenomen die belangrijk zijn voor het plannen van het
project. Ten vierde is de planning opgenomen en ten slotte de verschillende
milestones binnen het project.

D.1.1 Betrokkenen
In de figuur hieronder zijn de betrokkenen binnen het project schematisch
weergegeven.

Figuur 26: Overzicht van betrokkenen project.

D.1.2 Taken
Aan de hand van het pakket aan requirements en recommendations, zoals
deze beschreven staan in hoofdstuk 5 , kunnen de volgende taken voor het
project gedefiniëerd 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 is
aan 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
4 Bouw Prototype/opstellen projectplan Ontwerp
5 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
b
Het 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 zijn
gebaseerd op een projectduur van 21 werkweken. Zoals in de onderstaande
tabel af te lezen is, zijn de totale kosten voor dit project beraamd op e
10.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

MagicLinker
Ontwikkeldocumentatie

W. Hofsta & C. Jager

Datum:................. 18 januari 2006


Instituut: LabNoord Huisartsenlaboratorium
Plaats: Groningen
Versie: 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 kort
beschreven.

E.1.1 Algemeen
MagicLinker is een applicatie binnen het DODS systeem waarmee data van
een client naar server kan worden verstuurd. Momenteel wordt het gebruikt
om onderzoeksbestanden die gegenereerd worden tijdens een functieonder-
zoek, automatisch te koppelen met de patiëntgegevens binnen DODS.

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

E.1.2 Onderdelen
De MagicLinker applicatie bestaat uit verschillende onderdelen. Deze onder-
delen worden in deze paragraaf stuk voor stuk kort beschreven. De namen
van 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 geëxecuteerd wordt. Tevens worden hier vanuit alle
andere 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 verschillende
onderdelen in de juiste volgorde aangeroepen.

MagicLinkerRSM

50
Het MagicLinkerRSM object is bedoelt om alle functieonderzoeken binnen
de afdeling in te implementeren. Voor elk van de geı̈mplementeerde func-
tieonderzoeken is er een filter methode opgenomen, die speciaal bestanden
filtert voor een bepaald functieonderzoek. Zo is er momenteel bijvoorbeeld
een filter opgenomen voor ECG onderzoeksbestanden die gegenereerd zijn
door 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 bestand
bevatten. De bestandsnaam is gelijk aan het orgineel met het toegevoegde
”.gz“ aan de extensie.

MagicLinkerGUI

De MagicLinkerGUI bevat alle functionaliteit voor de visuele weergave van


de applicatie. Het bevat methoden om afbeeldingen in te laden, voortgangs-
balken weer te geven en de huidige status van de applicatie te laten zien aan
de gebruiker.

MagicLinkerConverter

De MagicLinkerConverter biedt de mogelijkheid om het formaat van een


bestand te wijzigen. Momenteel kunnen bijvoorbeeld TIF afbeeldingsbe-
standen omgezet worden naar PDF formaat. In de toekomst zouden deze
faciliteiten verder uitgebreid kunnen worden door nog meerdere conversies
te implementeren.

51
E.2 Applicatie Bouwen
Voor het bouwen van de applicatie is tijdens het project gebruik gemaakt
van de JDK versie 1.5.0 build 05.

E.2.1 Sleutel genereren


MagicLinker heeft standaard geen lees en schrijfrechten op de schijf van
de cliënt. 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, maakt
MagicLinker gebruik van een certificaat. In deze paragraaf wordt uitgelegd
hoe dit certificaat, doormiddel van het genereren van een sleutel, aange-
maakt kan worden.

Om een sleutel te genereren, wordt gebruik gemaakt van de KeyTool van


Sun Microsystems. Deze wordt standaard meegeleverd met JDK versie 1.4 of
hoger. De KeyTool kan een sleutel genereren aan de hand van het volgende
commando:

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

In dit voorbeeld wordt een sleutel gegenereerd met een geldigheid van 1825
dagen, gebruik makende van een rsa sleutel algoritme en een alias met de
naam ”labkey“. Elke keer als een sleutel onder een nieuw alias gegenereerd
wordt, 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 in
het lokale Java ”.keystore“ bestand. Deze is in Windows te vinden in de
gebruikersmap binnen ”Documents and Setttings“. Als men alle sleutels wil
weghalen, 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 het
genereren van PDF bestanden en voor de communicatie met een javascript
object.

Nu de applicatie gecompileerd is, kan deze, met alle bijbehorende data tot
een ”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 opgenomen
binnen 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 archief
gekoppeld worden met de gegenereerde sleutel:

jarsigner MagicLinker.jar labkey

Zoals te zien is wordt de sleutel weer aangeroepen aan de hand van het
alias waaronder het bekend is binnen het systeem. Nadat het commando is
uitgevoerd, zal de jarsigner vragen om het paswoord wat tijdens de creatie
van de sleutel is opgegeven. Als dit paswoord ingevoerd is, wordt de sleutel
binnen 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 simpelste
voorbeeld 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. In
de bijlage E.5.1 is een compleet voorbeeld HTML bestand met parameters
opgenomen.

53
E.3 Applicatie Uitbreiden
E.3.1 Functieonderzoek toevoegen
Om MagicLinker uit te breiden met een nieuw functieonderzoek, moeten
er enkele stappen doorlopen worden. Deze stappen worden allemaal in het
MagicLinkerRSM object binnen MagicLinker uitgevoerd:
1. Creeer een nieuwe public static final int index waarde ter identificatie
van het nieuwe onderzoek.
Voorbeeld
ECG=1;
of
DEXA=2;
2. Implementeer een nieuwe methode binnen het object met een filter
voor het nieuwe onderzoek, of herbruik één van de oude, reeds geı̈mplementeerde
filters. 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 methode
aanroep te plaatsen in de public String[] filter() methode, binnen de
switch.
Voorbeeld
case ECG : RSMFilteredFiles = ECGFilter(files); break;
4. Plaats een referentie naar deze nieuwe filtermethode door de naam
van het onderzoek in de public String getResearchString() switch te
plaatsen.
Voorbeeld
case ECG: researchString = "ECG"; break;
5. Nu de nieuwe filter in het MagicLinkerRSM object is opgenomen, hoeft
deze alleen nog maar aangeroepen te worden vanuit het hoofdobject
MagicLinker.
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 private


String[] errorStringsEnglish een tekstregel toe die de gebruikers van
MagicLinker 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 het
onderstaande commando.
Voorbeeld

ml_gui.setStatus(MagicLinkerGUI.ERROR10,true);

55
E.3.3 Conversie toevoegen
Nieuwe conversies dienen in het MagicLinkerConverter object geplaatst te
worden. Ideaal gezien bestaat een nieuwe conversie uit één enkele methode.
De volgende stappen moeten doorlopen worden binnen dit object:

1. Plaats bovenin het MagicLinkerConverter object de extensie toe van


het 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 de
hand van de benodigde parameters. Door deze parameters aan te passen,
kan er het één en ander getest worden. Als één van de parameters onjuist is,
zal er een foutmelding gegenereerd worden. Voor uitleg bij de verschillende
parameters wordt er doorverwezen naar bijlage E.5.1; het voorbeeld HTML
bestand.

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 uitgebreid
worden om de functionaliteit van MagicLinker te testen. Momenteel bevat
het bestand 8 verschillende tests die uitgevoerd worden op MagicLinker. In
de toekomst kunnen deze tests natuurlijk uitgebreid worden om ook nieuw
toegevoegde functionaliteit makkelijk te kunnen testen.

Om een nieuwe test toe te voegen, zal de testmethode binnen het JUnit
bestand moeten beginnen met ”test“. Het makkelijkste is om daarachter
dan gewoon de naam van vermelden van de methode van MagicLinker die
hiermee 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 gecompileerd
is, kan het voorbeeld HTML bestand gebruikt worden. Door de inhoud in
een HTML bestand te plaatsen, kan het met een internetbrowser geopend
worden. Binnen deze HTML pagina zal dan de applicatie geladen worden,
en uitgevoerd.

57
E.5 Appendix
E.5.1 Voorbeeld HTML
<!--
Example HTML using the MagicLinker Applet.
Explains the different parameters used by the Applet.
-->

<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 TAG -->
<!-- Opens the class file "MagicLinker.class" from the JAVA Archive
"MagicLinker.jar" with the specified parameters. The applet is
placed within a JAVA Archive because of the certificate
that needs to be used(for read and write permission). -->
<applet bgcolor=#FFFCDF code="MagicLinker.class" archive="MagicLinker.jar"
width="300" height="80" MAYSCRIPT>
<!-- GUI PARAMETERS -->
<!-- "gui_bar_top_color" sets the color of the top bar(value in HEX) -->
<param name="gui_bar_top_color" value="475172">
<!-- "gui_font_color" sets the color of the font(value in HEX) -->
<param name="gui_font_color" value="000000">
<!-- "gui_bar_color" sets the color of the process bar(value in HEX) -->
<param name="gui_bar_color" value="63709D">
<!-- "gui_language" sets the language of the output(0==DUTCH, 1==ENGLISH) -->
<param name="gui_language" value="1">
<!-- "gui_font" sets the font -->
<param name="gui_font" value="Arial">
<!-- "gui_bar_back_color" sets the color of the backgound(value in HEX) -->
<param name="gui_bar_back_color" value="FFFCDF">

<!-- FUNCTION PARAMETERS -->


<!-- "ssl_enable" sets SSL mode for applet. Make sure SSL is enabled on the
webserver before changing this setting, and visa versa(also adjust
parameters "location_post_address" and "location_server_port"). -->
<param name="ssl_enable" value="1">

<!-- FILTER PARAMETERS -->


<!-- "filter_research_id" sets the research to be processed -->
<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+">

<!-- LOCATION PARAMETERS -->


<!-- "location_research_files" is the name of the directory where the
research files are present (e.g. "d:\\testfiles") -->
<param name="location_research_files" value="d:\\testfiles">
<!-- "location_research_tmpdir" is the name of the directory(based
from the "location_research_files" dir), where the temporary
research files are to be stored(e.g. "d:\\testfiles\\temp") -->
<param name="location_research_tempfiles" value="temp">
<!-- "location_server_port" is the port of the secure SSL server
where the applet needs to connect with -->
<!--<param name="location_server_port" value="443">-->
<param name="location_server_port" value="80">
<!-- "location_post_address" is the HTTPS address to where the research
files need to be posted -->
<param name="location_post_address"
value="https://dods/magic_linker/post.php">
</applet>
<!-- APPLET TAG(END) -->

<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 meegeleverde
CD-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