Het ontwikkelen van een online patiëntendossier

Vertrouwelijk

Het ontwikkelen van een online patiëntendossier Afstudeerverslag

Vertrouwelijk

Afstudeerder:

Martin van der Lubbe

School:

De Haagse Hoge School

Studentnummer:

20040705

Afdeling:

ICT & Media

Bedrijf:

Zorg e-Novatie

Opleiding:

Informatica

Bedrijfsmentor:

R. Hoekstra

Examinatoren:

M. Heijne & H. Weenink

1 aeXist


20040705

Vertrouwelijk

Referaat

Auteur:


Titel:

Het ontwikkelen van een online patiëntendossier

Opleiding:

Hogeschool, Informatica

In dit verslag wordt het proces beschreven van de ontwikkeling van een online patiëntendossier bij de stichting Zorg e-Novatie. De opdracht is uitgevoerd in de periode van februari 2010 tot juni 2010 bij de stichting Zorg e-Novatie te ‘s-Gravenhage. Het doel van dit verslag is om de examinatoren inzicht te verschaffen in de omvang en diepgang van het project.

Descriptoren: HL7 XML XForms XQuery eXist Orbeon Architectuur

2 aeXist


20040705

Vertrouwelijk

Voorwoord. Deze afstudeerperiode, van februari 2010 tot juni 2010, heb ik voor de stichting Zorg e-Novatie een deel van een online patiëntendossier ontwikkeld. Daarnaast heb ik meegewerkt aan het professionaliseren van de ontwikkelstraat binnen de stichting. Ik wil Remko Hoekstra graag bedanken voor het aanbieden van de stageplaats bij de stichting Zorg eNovatie en voor zijn begeleiding tijdens deze periode. Verder wil ik ook de medewerkers van de Zorg e-Novatie bedanken voor hun samenwerken en hulp die ik tijdens mijn afstudeerperiode heb gekregen. Ook wil ik mijn examinatoren bedanken voor de goede begeleiding en feedback die ik ontvangen heb tijdens mijn afstudeerperiode. Tijdens mijn afstudeerstage heb ik veel geleerd en ik ben veel ervaringen rijker geworden. De technieken die gebruikt worden bij dit project zijn vrij onbekend, waardoor de ondersteuning bij deze technieken minder is. Ik wens u veel plezier met het lezen van dit procesverslag. Den Haag 2 juni 2010, Martin van der Lubbe.

3 aeXist


20040705

Vertrouwelijk

Inhoud. 1.

Inleiding. .......................................................................................................................................... 5

2.

De stichting Zorg e-Novatie. ............................................................................................................ 6

3.

Opdrachtomschrijving ..................................................................................................................... 8

4.

Technieken. ................................................................................................................................... 11

5.

Startsituatie. .................................................................................................................................. 14

6.

Werkzaamheden. .......................................................................................................................... 15 6.1

Inwerken. ............................................................................................................................... 15

6.2

Ontwikkelomgeving inrichten. .............................................................................................. 17

6.3

Loginsysteem. ........................................................................................................................ 18

6.4

Database inrichten. ............................................................................................................... 23

6.5

Ontwikkelen XForms. ............................................................................................................ 28

6.6

Patiëntselectie module.......................................................................................................... 32

7.

Evaluatie. ....................................................................................................................................... 38 7.1

Producten. ............................................................................................................................. 38

7.2

Proces. ................................................................................................................................... 39

8.

Conclusie. ...................................................................................................................................... 41

9.

Woordenlijst. ................................................................................................................................. 42

10.

Literatuurlijst. ............................................................................................................................ 43

11.

Overzicht bijlage. ....................................................................................................................... 44

4 aeXist


20040705

Vertrouwelijk

1. Inleiding. Dit document is geschreven naar aanleiding van de afstudeeropdracht van de studie Informatica aan de Haagse Hoge School. In het document wordt een periode van 17 weken beschreven die ik voor de studie aan de afstudeeropdracht heb besteed. Deze afstudeeropdracht is uitgevoerd bij de stichting Zorg e-Novatie te ’s-Gravenhage. Het afstudeerverslag verschaft inzicht in het ontwikkelproces en de gemaakte keuzes die ik tijdens mijn project heb gemaakt. Om het project in een kader te kunnen plaatsen zal eerst het bedrijf worden uitgelicht. Daarna zullen ter verduidelijking van het project de technieken worden uitgelegd. Omdat het project niet volgens de initiële planning is verlopen zal er over de startsituatie van het project worden uitgeweid. De werkzaamheden worden in hoofdstuk 5 beschreven, waarbij per onderdeel de belangrijkste keuzes zullen worden uitgelicht. De evaluatie van de afstudeeropdracht en de conclusie staan respectievelijk in de hoofdstukken 6 en 7 beschreven. Omdat er een aantal termen in het verslag worden benoemd die voor de lezers zonder specifieke vakkennis niet te begrijpen zijn, is er in een woordenlijst in dit document opgenomen.

5 aeXist


20040705

Vertrouwelijk

2. De stichting Zorg e-Novatie. Om de afstudeeropdracht in de juiste context te zetten wordt in dit hoofdstuk het afstudeerbedrijf beschreven. De stichting Zorg e-Novatie is in november 2009 opgezet en is gevestigd in de Caballero fabriek te ’sGravenhage. De stichting houdt zich momenteel met één project bezig, namelijk het Diabetes Zelfzorgdossier. De stichting bevordert innovatie en informatievoorziening in de zorg. Dit doet zij onder andere door de ontwikkeling en het gebruik van Open Source software te stimuleren. Waarbij het de bedoeling is dat er een community wordt opgezet, met als doel het stimuleren van innovatieve open source projecten. De stichting heeft het initiatief genomen voor de ontwikkeling van het Zelfzorgdossier Diabetes. Het Zelfzorgdossier Diabetes kan als innovatief worden beschouwd vanwege de technieken die worden ondersteund zoals HL7, later in dit document zal hier meer hierover worden verteld.

2.1 Organisatie. De stichting Zorg e-Novatie is een startend bedrijf en heeft daardoor (nog) geen klanten, de stichting heeft vooral studenten in dienst. Het organogram van de stichting ziet er als volgt uit:

Remko Hoekstra Directeur

Karim Asserghine Software Engineer

Thijs van Dijk Software Engineer Wim de Wolff Bedrijfskundig adviseur

Peter Hendriks Software Engineer

Michiel Eger Designer

Mark Miedema Designer

Martin van der Lubbe Afstudeerder

Software development

Design team

Figuur 1

De workflow tussen de verschillende leden binnen de stichting zal later in het verslag worden weergegeven zodat de samenwerking duidelijk wordt gemaakt.

6 aeXist


20040705

Vertrouwelijk

2.2 Werkterrein. De stichting Zorg e-Novatie maakt een applicatie die in het denkbeeld van ‘Zorg 2.0’ past. ‘Zorg 2.0’ houdt in dat de relatie tussen patiënt en zorgprofessional verbeterd wordt door middel van nieuwe, innovatieve ideeën of applicaties. Het idee om zorg gedeeltelijk via internet applicaties te laten verlopen is nieuw en er zijn momenteel nog niet veel van dit soort applicaties in gebruik. De raad voor de volksgezondheid heeft hier pas geleden een rapport over uitgebracht. Partijen in de zorg zijn het erover eens dat de patiënt in de zorg centraal hoort te staan, dit is nu vaak niet het geval. Door ‘Zorg 2.0’ te stimuleren kan de patiënt actiever deel nemen in het zorgproces: de patiënt wisselt ervaringen uit met lotgenoten, de patiënt krijgt meer mogelijkheden voor zelfmanagement. Voor de zorgverlener heeft dit als grootste voordeel dat er een beter geïnformeerde patiënt op de spreekuren langskomt. De patiënt zal beter bij het zorgproces worden betrokken omdat de patiënt namelijk beter op zijn/haar gezondheid zal letten en meer bewust met de adviezen omgaan. De kosten in de zorgsector kunnen hierdoor verminderd worden. De patiënt kan meer zelf regelen waardoor er minder druk op de arbeidsmarkt, in de zorg, komt te liggen. (Raad voor de Volksgezondheid en Zorg) Voor het ziektebeeld diabetes is het belangrijk dat de patiënten directer bij hun eigen zorgproces worden betrokken, omdat diabetes oorzaak kan zijn voor andere gezondheidsproblemen. Het zelfzorgdossier biedt een beter inzicht in de oude gemeten waardes en gegevens van de patiënt. De patiënt kan hierdoor zelf zijn gedrag aanpassen. De gegevens in de diabetes zorg worden nu nog in papieren statussen vastgelegd, als een zorgverlener oude gegevens van een patiënt wil inzien moet hij/zij dus door de status bladeren. Door deze gegevens digitaal vast te leggen kan de zorgverlener makkelijker oude gegevens opzoeken en een duidelijker overzicht van die data krijgen.

7 aeXist


20040705

Vertrouwelijk

3. Opdrachtomschrijving In dit hoofdstuk staat de opzet van de opdracht beschreven, onder verdeeld in aanleiding, probleemstelling, doelstelling en resultaat. Verder wordt er ook uitgelegd waarom er voor de Agile software ontwikkelmethode is gekozen. De opdrachtomschrijving is gemaakt voordat ik bij het bedrijf aan de slag ging, deze moest worden bijgesteld omdat de architectuur van de applicatie nog niet zover ontwikkeld was als van te voren werd ingeschat. De aanleiding is nog wel de juiste maar de probleemstelling en de doelstelling moesten worden bijgesteld. Deze bijgestelde onderdelen zijn in paragraaf 2.4 en 2.5 te vinden.

3.1 Aanleiding. De stichting Zorg e-Novatie is bezig met het ontwikkelen van een zelfzorgdossier voor diabetes patiënten. Door dit zelfzorgdossier wordt de afstand tussen patiënt en zorgverlener verkleind. De patiënten kunnen in het zelfzorgdossier onder andere glucose- en insulinewaardes invoeren waarna de zorgverlener deze gegevens kan beoordelen. Het is een open source project dat door de stichting Zorg e-Novatie is opgezet. Het zelfzorgdossier is een webportal waardoor de gebruikers ook via de mobiele telefoon hun gegevens kunnen bijwerken. Het project is in ontwikkeling en enkele modules zijn al gemaakt. Volgens de planning dient de applicatie in juni als bèta versie te worden opgeleverd. Hierna zal een pilot starten. Bij het ontwikkelen van de applicatie wordt met meerdere scenario’s rekening gehouden, namelijk: de applicatie als een op zichzelf staande applicatie of de applicatie als aanvulling van een software pakket in een ziekenhuis. Dit houdt in dat bij het ontwerpen van de architectuur er altijd met deze twee scenario’s rekening moet worden gehouden. Omdat de directeur van de stichting, R. Hoekstra, contacten heeft in het UMC St Radboud zal er bij het tweede scenario worden uitgegaan van de situatie zoals deze in het Radboud is.

3.2 Probleemstelling. Aan de applicatie ontbreekt nog een aantal modules, voordat deze kunnen worden gebouwd zal er nog het een en ander onderzocht en ontworpen moeten worden. Zo moet er een veilig, want het gaat om medische gegevens, e-mailsysteem komen. Voor de zorgverleners is het nog niet mogelijk om snel inzicht te krijgen in de status van hun patiënten: op basis van criteria moeten patiënten worden geselecteerd die zorg nodig hebben. Daarnaast moet er een rapportage module komen op basis waarvan externe rapportage plaatsvindt. Tot slot dient de zorgverlener met een barcodelezer snel en foutloos een patiënt te kunnen selecteren. Dit omdat het systeem in ziekenhuizen gebruikt gaat worden.

3.3 Doelstelling van de afstudeeropdracht. Het doel van de opdracht is het ontwerpen en ontwikkelen van een viertal modules met bijbehorende database: •

Een beveiligd e-mailsysteem 8

aeXist


20040705

Vertrouwelijk •

De zorgverlener cockpit

•

Rapportage module Kwaliteitsindicatoren

•

De Selectiemodule patiënten

De modules dienen te passen binnen de architectuur van Orbeon (formulieren) en eXist (XMLdatabase). De Zorgverlener Cockpit en de rapportagemodules vereisen mogelijk additionele componenten in de architectuur. Te denken valt aan een datawarehouse. De selectie en integratie van deze componenten maken onderdeel uit van de opdracht.

3.4 Bijgestelde probleemstelling. De algemene architectuur van de applicatie is nog incompleet, deze moet worden uitgewerkt tot het niveau dat er ontwikkeld kan worden. Dit houdt onder andere in dat er een ontwikkelomgeving moet worden ingericht.

3.5 Bijgestelde doelstelling van de afstudeeropdracht. Het doel van de opdracht is het ontwerpen van de algemene architectuur van de applicatie, waarbij rekening moet worden gehouden met de volgende wetten: Wet bescherming persoonsgegevens Wet geneeskundige behandel overeenkomst Hierbij kan de volgende norm worden aangehouden: NEN 7510 – norm informatiebeveiliging in de zorg Dit houdt in dat er met de volgende aspecten bij elk onderdeel van de architectuur rekening moet worden gehouden: Veiligheid Performance Betrouwbaarheid Bruikbaarheid Als de algemene architectuur rond is, kan er worden begonnen met het maken van verscheidene modules, zoals: Loginsysteem Database ontwerp Rapportage module kwaliteitsindicatoren De zorgverlener cockpit 9 aeXist


20040705

Vertrouwelijk De selectiemodule patiënten Doordat bepaalde technische kennis bij het bedrijf nog niet aanwezig was bij aanvang van mijn project, was de ontwikkeling van het project nog niet zover gevorderd als van te voren werd ingeschat. De prioriteit kwam daardoor niet bij het maken van de modules te liggen, maar bij het vormen van de algemene architectuur van de applicatie. Er is besloten om het ontwikkelen van het beveiligde e-mailsysteem met een aantal weken uit te stellen. Dit komt doordat er, zoals eerder aangegeven, bepaalde ontwikkelingen nog niet zo ver gevorderd waren. Voor het e-mailsysteem was bijvoorbeeld een rollenindeling nodig, dit moest nog gemaakt worden.

3.6 Resultaat. Het ontwerp en de code van de algemene architectuur en van de modules zoals hierboven beschreven met bijbehorende documentatie. De beschrijving hoe deze modules passen in de architectuur.

3.7 Projectbeheersing. Bij dit project wordt gebruik gemaakt van verschillende innovatieve technieken. Omdat er bij sommige van de technieken die in dit project worden gebruikt geen of weinig support wordt aangeboden, is het moeilijk om een goede gedetailleerde planning te maken. Veel keuzes bij het ontwikkelen zullen worden gemaakt op basis van wat er technisch mogelijk is, hierdoor kan het voorkomen dat eisen snel bij moeten worden gesteld. De Agile software ontwikkelmethode is een methode die goed bij deze manier van werken past, omdat er bij deze methode snel naar een werkende versie wordt gewerkt. Met de Agile software ontwikkelmethode worden risico’s verminderd doordat er steeds, in kleine stapjes, naar een werkend concept toe wordt gewerkt.

10 aeXist


20040705

Vertrouwelijk

4. Technieken. In dit hoofdstuk wil ik een aantal technieken verduidelijken zodat het verslag makkelijker te lezen wordt. Voor aanvang van dit project had ik totaal geen ervaring met XForms of met het werken in een native XML-database. Voor het inwerken had ik in de originele planning 1 week uitgetrokken, maar voor het leren werken met de technieken had ik wel wat meer tijd nodig, zoals in paragraaf 6.1 zal worden uitgelegd.

4.1 HL7v3. HL7v3, oftewel Health Level 7 versie 3, is een internationale standaard voor interoperabiliteit van medische gegevens. Om ervoor te zorgen dat medische gegevens van verschillende applicaties uitgewisseld kan worden heeft de HL7 organisatie een standaard geschreven. De standaard bepaalt de structuur van de data, waardoor deze internationaal inter-operabel wordt. De HL7 standaard beschrijft de structuur in XML-formaat waardoor de gegevens programmeertaal onafhankelijk is. De HL7-organisatie is in 1987 opgericht in de Verenigde Staten, de eerste versie van de standaard was gericht op de Amerikaanse zorg. In de jaren ’90 werd de standaard in meer dan 30 landen geïmplementeerd, elk land dat de standaard gebruikt heeft een lokale organisatie die de standaard beheert. De meeste applicaties gebruiken HL7 alleen bij het uitwisselen van data. Het patiëntendossier diabetes daarentegen gebruikt de HL7 structuur ook voor het opslaan van de data. Dit heeft als grootste voordeel dat de data voor uitwisseling niet eerst omgezet hoeft te worden. Het landelijk elektronisch patiënten dossier in Nederland gebruikt ook HL7, hierdoor sluit de applicatie goed aan op het centrale landelijke patiëntendossier.

4.2 SNOMED. SNOMED, oftewel Systematized Nomenclature of Medicine, is een verzameling van codes die representatief zijn voor verschillende medische termen. Door deze codes te gebruiken wordt de data inter-operabel en universeel uitwisselbaar. Als voorbeeld: De glucosemeting van een patiënt heeft als code: 2.16.840.1.113883.5.139 Dit in combinatie met de structuur en codes van HL7 maakt de modellen (inter)nationaal uitwisselbaar.

4.3 XForms. XForms is een XML-formaat waarmee XML-data kan worden weggeschreven. Een XForm is een webbased XML-formulier waarmee een gebruiker data naar een database kan wegschrijven. 11 aeXist


20040705

Vertrouwelijk XForms is vanaf eind 2003 een officiële W3C recommendation, wat inhoudt dat het tot een standaard webtechniek is verklaard.

4.4 XQuery. XQuery is de XML-variant van SQL, je kunt er query’s op een XML-database of XML-bestand mee uitvoeren. XQuery heeft een FLWOR-sintaxis waarbij de letters voor de volgende instructies staan: For, Let, Where, Order By en Return. De instructies zijn dus enigszins hetzelfde als bij SQL maar de structuur is daar niet mee te vergelijken.

4.5 XProc. Met XProc kun je XML-pipelines definiëren. Een XML-pipeline bestaat uit verschillende procesoren die gebruikt kunnen worden voor bijvoorbeeld het transformeren van een XML-bestand.

4.6 XPath. Met XPath kun je door XML-bestanden navigeren om elementen of attributen op te halen, het is een soort query-taal. Een XML-bestand is opgebouwd uit elementen: <element>. Een element kan tekst of andere elementen bevatten. Een element kan tevens attributen bevatten: <element attribuut=‘‘>. Om te demonstreren hoe XPath werkt staat hieronder een voorbeeld: Neem het volgende XML-bestand.

Figuur 2

Stel je wilt het voornaam element selecteren, dan is de volgende XPath expressie nodig: /root/naam/voornaam Dit komt omdat het ‘voornaam’-element in het ‘naam’-element staat, welke weer in het ‘root’element staat.

4.7 Native XML database. Een native XML database is een database die volledig gebaseerd is op XML-technieken. De data in een native XML database hoeft niet in tabellen worden opgeslagen. In het geval van de eXist database die bij dit project wordt gebruikt wordt de data in XML-formaat in de database gezet. 12 aeXist


20040705

Vertrouwelijk Bij de eXist database wordt dus geen gebruik gemaakt van tabellen, wel wordt er gebruik gemaakt van zogenaamde XML-collecties. Deze XML-collecties zijn verzamelingen van XML-bestanden, door het gebruik van de collecties kunnen de XML-bestanden makkelijker worden gevonden.

13 aeXist


20040705

Vertrouwelijk

5. Startsituatie. Om de startsituatie van mijn project te verduidelijken zal ik in dit deel uitweiden over hoe de situatie van de stichting was op het moment dat ik startte bij het bedrijf.

1. Stichting. De stichting is opgericht in november 2009 met als doel het maken van een digitaal patiëntendossier voor diabetes patiënten. In de beginfase heeft de stichting beslissingen genomen over welke technieken bij het maken van dit dossier moeten worden gebruikt. Zo is er besloten om XForms en een XML-database te gebruiken. Als platform voor de XForms is er op dat moment gekozen om het Orbeon platform te gebruiken. Omdat de eXist-database aansluit bij het Orbeon platform is er voor gekozen de eXist-database als XML-database te gebruiken. Het idee achter het gebruik van deze technieken is dat alle data in XML-formaat wordt opgeslagen zonder dat daar enige transformatie voor hoeft worden uitgevoerd. Alle data die voor de applicatie wordt opgeslagen is in HL7v3, Health Level 7 versie 3, formaat. Doordat alle medische instanties dit HL7-formaat aanhouden is het universeel uitwisselbaar. De XForms worden gebaseerd op HL7-modellen, deze modellen worden door de gebruiker, via een XForm, ingevuld en direct in de database opgeslagen. Omdat er een XML-database wordt gebruikt kunnen de ingevulde modellen direct in de database worden gezet, dit komt doordat de modellen ook in XML-formaat zijn. Bij de stichting was de kennis van de XForms zeer beperkt. Er was tot dan toe alleen nog een simpel formulier gemaakt. Dit formulier was gemaakt door de voorbeelden op de Orbeon website na te maken. De configuratie tussen Orbeon, Tomcat en eXist moest nog worden gemaakt. De kennis over deze onderdelen was bij de stichting ook zeer beperkt. De Tomcat server had op dit moment nog de standaard configuratie. Dit houdt in dat de Tomcat server alleen nog voor software ontwikkeling geschikt was.

2. Eigen kennis. Voor ik aan de afstudeeropdracht begon had ik nog nooit met XForms gewerkt. Wel was ik al redelijk bekend met de XML structuur omdat ik daar bij mijn vorige stage al kennis over had opgedaan. Met de Tomcat server had ik nog nooit gewerkt, wel heb ik bij mijn vorige stage met een Apache server gewerkt. Maar met het configureren van een server had ik nog geen ervaring. Ook met de overige technieken zoals XQuery, XProc en XPath had ik voor aanvang van dit project nog geen enkele ervaring.

14 aeXist


20040705

Vertrouwelijk

6. Werkzaamheden. In dit hoofdstuk wordt uitgelegd wat ik tijdens de afstudeerstage heb uitgevoerd en wat de belangrijkste keuzes bij de werkzaamheden zijn geweest. Per opdracht wordt hieronder de volgende indeling aangehouden: inleiding, aanpak, uitvoering, test en resultaat.

6.1 Inwerken. 1. Inleiding Op 8 februari ben ik aan het werk gegaan voor de stichting Zorg e-Novatie. Op de eerste dag ben ik begonnen met het inrichten van mijn werkplek. Hiervoor moest ik de volgende programma’s downloaden en installeren: Oxygen editor eXist database Orbeon platform Tomcat server Na de programma’s geïnstalleerd te hebben ben ik begonnen met het maken van een simpel testscherm met twee invoervelden. De ingevoerde data moest vervolgens in de database worden opgeslagen. Bij deze opdracht moest ik dus Orbeon en eXist samen laten werken.

2. Aanpak Dit was voor mij de eerste keer dat ik met XForms zou gaan werken en ik had dus totaal geen ervaring met de techniek. Het was noodzakelijk om wat voorbeelden op te zoeken. Daarom heb ik bij het maken van deze ‘opdracht’, met hulp van mijn collega’s, de beschikbare middelen geïnventariseerd. Omdat XForms geen veelgebruikte techniek is, zijn er ook niet veel platformen voor te vinden. De stichting heeft besloten om het Orbeon platform te gebruiken als platform voor de XForms. En ook al probeert Orbeon de officiële XForms standaard nauwkeurig aan te houden, moeten de XForms zo nu en dan ‘Orbeon specifiek’ worden gemaakt. Dit houdt tevens in dat er niet veel voorbeelden op het internet te vinden zijn. Op de officiële website van Orbeon staan wel voorbeelden en deze kon ik dus raadplegen. Mijn collega’s hadden op dit moment zeer geringe kennis van XForms en hadden alleen nog een simpel formuliertje gemaakt. Dit formulier kon ik wel als voorbeeld gebruiken bij het maken van deze ‘opdracht’. Verder kon ik gebruik maken van de W3schools website om een introducerende tutorial te volgen van XPath expressies en XForms. Zodat ik ook wat beter de gedachte achter de technieken kon begrijpen en de basisprincipes onder de knie kon krijgen. 15 aeXist


20040705

Vertrouwelijk Ook kon ik de XForms wikibook website raadplegen, op deze website zijn zowel simpele als ingewikkelde voorbeelden van XForms te vinden.

3. Uitvoering Ik ben begonnen met informatie op te zoeken op de Orbeon website, het viel meteen op dat deze website zeer beperkte informatie verstrekt. De website geeft namelijk korte voorbeelden over bepaalde functionaliteit, maar laat bepaalde belangrijke aspecten achterwege. Waardoor je alsnog uren bezig kunt zijn met het werkend krijgen van zo’n voorbeeld. Maar door de informatie op de Orbeon website te gebruiken kon ik wel genoeg informatie vinden om het XForm te kunnen maken.

4. Test Om te kunnen testen of de data ook daadwerkelijk werd opgeslagen moest ik in de database kunnen kijken. Ook voor de database geldt dat de documentatie matig is en het was voor mij dan ook even uitzoeken hoe ik de database kon inzien. De Oxygen editor bleek echter een databasekoppeling te hebben waarmee je via de editor in de database kunt kijken. Door de opgeslagen data, uit het gemaakte formulier, op te zoeken in de database wist ik dat het formulier naar behoren functioneerde.

5. Resultaat Een simpel XForm, waarmee je via twee invoervelden data in de database kunt opslaan. Maar daarnaast ook basiskennis over het maken van een XForm. Vooral de denkwijze, die bij het programmeren van XForms wordt gebruikt, verschild erg van de denkwijze die bij de traditionele programmeertalen wordt gebruikt. Zo is het in XForms bijvoorbeeld niet mogelijk om een eigen functie te creëren. Ook is het niet mogelijk om een if-statement in een XForm te plaatsen. De XForms structuur is voor gedefinieerd en daar kun je niet van afwijken. Dit betekent dus dat je met XForms minder vrijheid hebt in het schrijven van de code. Dit heeft zo zijn voor- en nadelen. Met XForms is ‘as-you-type’-validatie bijvoorbeeld standaard geïmplementeerd.

16 aeXist


20040705

Vertrouwelijk

6.2 Ontwikkelomgeving inrichten. 1. Inleiding De stichting is, zoals al eerder aangegeven, een startend bedrijf met voor ik er begon te werken drie medewerkers. Deze drie medewerkers werkten allen aan verschillende delen van de applicatie. Maar nadat ik bij het bedrijf was begonnen moest er toch iets aan versiemanagement worden gedaan, zodat er meerdere mensen aan dezelfde delen van de applicatie konden gaan werken. Zoals een programmeur die een XForm in elkaar zet en een designer die dit XForm vorm geeft.

2. Aanpak Om ervoor te zorgen dat er een ontwikkelomgeving kwam waarbij meerdere mensen tegelijk aan de applicatie konden werken heb ik voorgesteld om met versiebeheer aan de slag te gaan. Daarbij heb ik geadviseerd om SVN, Subversion, te gaan gebruiken omdat ik daar persoonlijk ervaring mee heb.

3. Uitvoering Een collega heeft toen besloten om inderdaad met SVN te gaan werken en heeft de complete Tomcat server in de SVN repositorie gezet. Dit gaf problemen omdat daar bestanden in stonden die niet door SVN gelezen konden worden en dus ook niet gemerged konden worden. Vandaar dat ik op dat moment heb voorgesteld niet de gehele Tomcat server in SVN te zetten, maar alleen de map met de XForms en models. Dit zijn .xml, .xhtml of .xpl bestanden die wel door SVN kunnen worden gelezen. Een ‘schone’ versie van de Tomcat server heb ik vervolgens op de algemene server gezet zodat iedereen deze kon kopiëren. Om ervoor te zorgen dat iedereen weet hoe er met SVN om moet worden gegaan heb ik een simpel protocol geschreven, zodat de SVN repositorie netjes blijft.

4. Resultaat Een ontwikkelomgeving die alle medewerkers zonder problemen op hun eigen machine kunnen zetten. En een werkend versiebeheer, met bijbehorende documentatie, zodat er bijvoorbeeld naar oudere versies kan worden terug gegaan.

17 aeXist


20040705

Vertrouwelijk

6.3 Loginsysteem. 1. Inleiding Veiligheid is een belangrijk onderdeel van de applicatie, want er worden medische gegevens opgeslagen. Het loginsysteem is een belangrijk onderdeel van de algemene architectuur. Bij het maken van het loginsysteem is het belangrijk om met de veiligheid rekening te houden. De applicatie moet, zoals in hoofdstuk drie benoemd, aan de norm informatiebeveiliging in de zorg(NEN 7510) voldoen. Het loginsysteem is een belangrijk onderdeel van de beveiliging van de applicatie, het schermt pagina’s af voor niet-geautoriseerde gebruikers. Ook moet het systeem de gebruikers na het inloggen naar de juiste URL sturen op basis van de toegewezen rol. Voor deze eerste versie van het loginsysteem vult de gebruiker een gebruikersnaam en een wachtwoord in. Later zal de gebruiker ook de mogelijkheid hebben om met DigID of een UZIkaartlezer in te loggen.

2. Aanpak Bij het maken van het loginsysteem ben ik begonnen met het maken van een functionele analyse. Bij het maken van deze analyse was het belangrijk om de eisen van het login systeem vast te leggen. Deze functionele eisen kon ik krijgen door met de heer R. Hoekstra te overleggen. De functionele eisen van het loginsysteem zijn vastgelegd in het Afst_Loginsysteem.doc bestand. Voor het maken van het loginsysteem kreeg ik in de aanpak alle vrijheid, als er uiteindelijk maar aan de eisen werd voldaan. Daarbij had ik de keuze om het loginsysteem via de Tomcat server, in Orbeon of een combinatie van deze twee, te laten verlopen. Ik ben begonnen met het werken aan het loginsysteem in week twee. Op dat moment was mijn technische kennis van XForms nog zeer beperkt. Dit had invloed op het ontwerpproces en ik moest dus uitzoeken wat er met welke techniek mogelijk was. Het lastige hierbij is dat er geen voorbeelden van een soortgelijke applicatie te vinden zijn, namelijk een applicatie die op een Tomcat server draait met een Orbeon platform en eXist als database.

3. Uitvoering Uitzoekwerk. De eerste stap bij het ontwerpen van het loginsysteem was het onderzoeken van de mogelijkheden. Zoals eerder aangegeven kon het loginsysteem via de Tomcat server, in Orbeon of via een combinatie van beide verlopen. Het voordeel van het afhandelen van het loginsysteem via de Tomcat server zou zijn dat daar standaard functies voor zijn. Mijn voorkeur ging dus uit naar het laten regelen van het loginsysteem door de Tomcat server. Als eerste heb ik daarom de Apache Tomcat website geraadpleegd om uit te vinden hoe de Tomcat server login gegevens afhandelt. De Tomcat server bleek een standaard functie te hebben voor het inloggen. Maar nadat een gebruiker zou zijn ingelogd, was het wel de bedoeling dat de gegevens van die gebruiker, in Orbeon op konden worden gehaald. Want op basis van de login gegevens wilde ik 18 aeXist


20040705

Vertrouwelijk de gebruiker aan de database koppelen. Zodat er gegevens over de ingelogde gebruiker opgehaald kunnen worden. Om uit te vinden of ik Orbeon en Tomcat kon laten samenwerken ben ik op de officiële Orbeon website gaan zoeken naar functies of voorbeelden. Op de Orbeon website kon ik geen informatie vinden en ik ben verder gaan zoeken met behulp van Google. Het lastige van een oplossing zoeken voor de XForms is dat de techniek niet veel gebruikt wordt. Maar daarnaast zijn er nog verschillende platformen die een andere implementatie van XForms hanteren. Het is dus vaak niet mogelijk om te zoeken op ‘XForms’ omdat je dan alleen voorbeelden vindt van XForms die voor een ander platform zijn gemaakt. Als je echter op ‘orbeon’ zoekt kom je alleen op de Orbeon website uit, waar weliswaar enkele voorbeelden te vinden zijn. Maar deze voorbeelden zijn vaak incompleet en onduidelijk. Omdat ik geen voorbeelden kon vinden van het laten samenwerken van Orbeon en Tomcat, was het laten verlopen van het loginsysteem via Tomcat geen optie. Daarom heb ik toen besloten om het loginsysteem volledig binnen Orbeon te regelen.

Ontwerp Nu ik besloten had om het loginsysteem in Orbeon te regelen kon ik beginnen met het maken van een ontwerp. Het ontwerp in grote lijnen hield in dat de gebruiker inlogt en dat zijn gebruikersnaam en wachtwoord in de database gecheckt werden. Als deze gegevens goed waren werd de gebruiker doorgestuurd naar een home-pagina, waarbij zijn gebruikersnaam wordt doorgegeven. Daarna kan dan op basis van zijn gebruikersnaam verschillende gegevens uit de database worden gehaald. Om dit ontwerp te laten werken moest het dus mogelijk zijn om gegevens van het ene formulier aan het andere door te kunnen geven. Op dit moment was mijn kennis van XForms zeer beperkt en ik kon alleen nog maar een formuliertje maken wat gegevens in de database opslaat. Dus om er zeker van te zijn dat het mogelijk was om gegevens tussen twee XForms door te geven, ben ik aan de slag gegaan met twee testformulieren. Wederom ging ik een oplossing zoeken op de Orbeon website. Op deze website kon ik wel een voorbeeld vinden over hoe je een ‘http post’ kon uitvoeren, maar niet hoe je deze ‘post-data’ weer kon opvangen. Ook via Google en Wikibooks kon ik niet uitvinden hoe de ‘post-data’ opgehaald kon worden. Nadat ik geprobeerd had het voorbeeld van Orbeon werkend te krijgen, heb ik besloten om hulp in te schakelen van een expert. Deze expert, Joost Horward, is een zakelijk contact van mijn baas en hij heeft een eigen Open Source Consultancy bedrijf. De expert heeft ook werkervaring met Orbeon/XForms. De expert kon mij een voorbeeld sturen, via email, van het opvangen van ‘post-data’ met XForms in Orbeon. Dit kon ik zelf namaken en met de twee testformulieren kon ik aantonen dat het mogelijk was om data vanuit het ene formulier te versturen en in het andere formulier op te vangen.

Bouwen Nadat was gebleken dat gegevens doorgegeven konden worden, ben ik begonnen aan het bouwen van het loginsysteem. 19 aeXist


20040705

Vertrouwelijk Als eerste ben ik begonnen met het maken van een XML-pipeline met behulp van XProc, een XMLpipeline taal. In een XML-pipeline kun je meer logica toevoegen dan in een XForm. Een XML-pipeline bestaat uit een serie processors die verschillende functies kunnen hebben. Zo kunnen deze XML transformeren of opslaan in de database. Ik had op dit moment nog nooit met de XProc techniek gewerkt en moest daardoor literatuur raadplegen. Een tutorial van XProc bleek echter moeilijk te vinden op het internet. Wel stonden er op de Orbeon website kleine voorbeelden van een XML-pipeline. Op basis van deze voorbeelden ben ik begonnen met het creëren van de XML-pipeline. Bij het bouwen van deze pipeline ben ik erg simpel begonnen en heb ik de pipeline steeds verder uitgebreid. De pipeline voor het loginsysteem moet als input de gebruikersnaam en wachtwoord van de gebruiker binnen krijgen en vervolgens in de database deze gegevens controleren. Deze pipeline kan op basis van de controle de gebruiker naar de home-pagina of terug naar het login-scherm sturen. Nadat ik deze pipeline had gemaakt kwam ik op een ander probleem, namelijk als het patiëntnummer om wat voor reden dan ook niet doorgegeven kan worden, de gebruiker de pagina niet zou kunnen zien. Dit geeft problemen als een gebruiker is ingelogd en bijvoorbeeld zelf de URL verandert. Het patiëntnummer kan namelijk alleen doorgegeven worden wanneer de gebruiker een submit-knop indrukt.

Nieuw ontwerp Het regelen van de volledige security in Orbeon was dus geen goede optie, maar ook het regelen van de security volledig door Tomcat was geen goede optie omdat we wel de login gegevens wilden gebruiken. Het was dus duidelijk dat er een combinatie tussen Orbeon en Tomcat moest worden gemaakt, maar daar kon ik geen informatie over te vinden op internet. Het probleem waar ik bij het gebruik van Tomcat en Orbeon tegen aan liep, was dat we de ingevoerde gebruikersnaam niet meer konden terughalen. De standaard login functie van Tomcat wordt via een html-formulier geregeld, hier kun je niets op aanpassen. Het formulier stuurt de login gegevens naar de tomcat-server, deze worden gecontroleerd door Tomcat en de gebruiker wordt vervolgens wel of niet doorgestuurd naar een beveiligde pagina. Bij dit doorsturen worden de login gegevens niet meegegeven en kun je dus niet opvangen wie er ingelogd is. Er moest dus een manier worden gevonden waardoor de ingevoerde gegevens van de gebruiker langs Tomcat gaan en vervolgens opgevangen kunnen worden. Op internet was hier geen informatie over te vinden en dus moest ik hulp inschakelen. Na contact te hebben opgenomen met Joost Horward bleek dat er toch een functie binnen Orbeon bestaat om de login gegevens op te halen. Deze functie is een XML-pipeline processor die met Tomcat communiceert en de gebruikersnaam en rol van de ingelogde gebruiker teruggeeft. Door deze pipeline in een XForm aan te roepen, kon ik dus de gebruikersnaam terug krijgen. Met deze gebruikersnaam was het vervolgens mogelijk om gegevens uit de eXist-database te halen, omdat de gebruikersnaam van Tomcat overeenkomt met de gebruikersnaam die in de eXist-database is opgeslagen.

20 aeXist


20040705

Vertrouwelijk Er moest nu alleen nog uitgezocht worden hoe de role-based-access gerealiseerd kon worden. Omdat ik geen ervaring had met het configureren van een server, ben ik voor informatie op de officiële Tomcat website gaan zoeken. In tegenstelling tot de Orbeon website staan er op de Tomcat website goede en duidelijke voorbeelden. Zo staat er ook uitgelegd hoe de Tomcat server met authenticatie omgaat. Bij de Tomcat server worden voor elke gebruiker de gebruikersnaam, wachtwoord en rol vastgelegd. Het XML-bestand waarin de gebruikers staan gedefinieerd is hieronder te zien:

Figuur 3

In dit figuur is te zien dat de gebruiker met gebruikersnaam ‘piet.jansen’ als wachtwoord ‘abc’ heeft en de rol ‘patient’ toegewezen heeft gekregen. In een configuratiebestand van Tomcat kun je vervolgens aangeven welke mappen of URL’s moeten worden afgeschermd. Hierbij is het ook mogelijk om aan te geven welke rollen recht hebben om de mappen of URL’s wel te openen. In het figuur hieronder is een deel van het configuratiebestand, voor het afschermen van mappen of URL’s, van Tomcat te zien:

21 aeXist


20040705

Vertrouwelijk

Figuur 4

In figuur 4 is te zien dat de map ‘/v0-2/’ is afgeschermd door de Tomcat server. Daarbij is aangegeven dat de rol ‘patient’ toegang tot deze map mag hebben. Bij het gebruik van deze voorbeelden figuren 3 en 4 zou de gebruiker met gebruikersnaam ‘piet.jansen’ dus toegang tot de map ‘/v0-2/’ hebben omdat er wordt gecontroleerd op rol.

4. Test Om te testen of het loginsysteem aan de, in Afst_Loginsysteem.doc in bijlage, gestelde eisen voldeed moest er getest worden. Deze test is beschreven in Afst_Loginsysteem_test.doc in bijlage. Bij het testen had ik van te voren een aantal acties opgesteld met het daarbij door mij verwachtte resultaat aan de hand van de gestelde eisen voor het loginsysteem.

5. Resultaat Een werkend loginsysteem dat aan de, in het ontwerpdocument gestelde, eisen voldoet. De Tomcat server werkt samen met Orbeon, waardoor er op basis van de login gegevens, die vanuit de Tomcat server teruggegeven worden, gebruikers aan de database kunnen worden gekoppeld. Naast het loginsysteem is er als resultaat ook sprake van opgedane kennis. Zo kon ik na deze opdracht gegevens van het ene formulier aan het andere doorgeven. Ook kennis over de Tomcat server is opgedaan.

22 aeXist


20040705

Vertrouwelijk

6.4 Database inrichten. 1. Inleiding De database inrichting is een belangrijk maar lastig punt in dit project, de applicatie wordt in eerste instantie alleen voor het Radboud ziekenhuis gemaakt. Maar uiteindelijk zal de applicatie in meerdere ziekenhuizen of op zichzelf staand moeten kunnen draaien. Als de applicatie in meerdere ziekenhuizen gaat draaien, moet het mogelijk zijn dat de database door meerdere ziekenhuizen wordt gebruikt. Waardoor de informatie centraal komt te staan. Binnen de stichting zijn bepaalde keuzes gemaakt over welke software er gebruikt gaat worden. Zo is er voor een eXist database gekozen, omdat dit een native XML-database is. Er wordt geen gebruik gemaakt van tabellen, zoals bij een relationele database, maar de data moet in XML-formaat worden opgeslagen. Op de XML-bestanden in de database kunnen query’s worden uitgevoerd, met behulp van XQuery. Toen ik begon met het werk voor de stichting was er nog geen ontwerp voor de database. De database was tot dan toe naar eigen inzicht ingericht. Maar naarmate er meer formulieren voor de applicatie werden gemaakt was het noodzakelijk om de database alvast goed in te richten. Bij het ontwerp is het belangrijk om rekening te houden met uitbreidbaarheid en performance. De uitbreidbaarheid is belangrijk omdat de database zogezegd eerst voor het Radboud wordt ontworpen maar later door meerdere ziekenhuizen moet kunnen worden gebruikt. De performance is belangrijk omdat de applicatie mede door zorgverleners, wiens tijd kostbaar is, gaat worden gebruikt. De performance kan bij een XML-database gewaarborgd worden door XML-collecties met weinig inhoud te maken. Je kunt dus beter heel veel collecties met weinig inhoud maken dan weinig collecties met veel inhoud.

2. Aanpak De eerste stap bij het inrichten van de database was het maken van de functionele analyse. Deze is terug te vinden in het Afst_database_ontwerp.doc in bijlage. Om de eisen aan de database op te stellen ben ik gaan overleggen met R. Hoekstra. Er moest vooral rekening worden gehouden met de performance en de uitbreidbaarheid. Na de functionele analyse te hebben uitgevoerd, ben ik verder gegaan met het ontwerpen van de database. In principe maakt het niet uit waar welk XML-bestand komt te staan, want je kunt query’s uitvoeren op de gehele database. Bij XQuery selecteer je met behulp van XPath eerst het juiste element of collectie waarop je een query wilt uitvoeren. De HL7-modellen zorgen voor de onderlinge relaties. Als voorbeeld kan ik een stukje HL7-code laten zien dat een glucosemeting vastlegt. Dit ziet er als volgt uit:

23 aeXist


20040705

Vertrouwelijk

Figuur 5

In figuur 5 is te zien hoe een glucosemeting in HL7-formaat wordt vastgelegd, enkele regels code zijn ingeklapt voor de leesbaarheid. In het pertinentInformation3-element in dit figuur wordt de glucosemeting opgeslagen. Het element bevindt zich in het careProvisionEvent-element waar ook het subject-element in staat. In dat subject-element staan de gegevens van de patiënt. Doordat de meting en de patiëntgegevens in hetzelfde XML-element staan opgeslagen kun je de meting op basis van bijvoorbeeld het patiëntnummer terugvinden. Een XML-database is opgebouwd uit XML-collecties waarin de verschillende XML-bestanden komen te staan. Bij het indelen van de verschillende XML-collecties is het belangrijk om te kijken naar wat voor soort data er in komt te staan en hoe groot die data in de collectie uiteindelijk kan worden. In de database worden verschillende ‘soorten’ data opgeslagen, zoals: medische gegevens, log-files en NAW-gegevens van patiënten, zorgverleners en zorginstellingen. Voordat ik het ontwerp kon maken moest ik dus uitzoeken welk soort data groot kon worden. De medische gegevens houden onder andere in: metingen verricht door de patiënt zelf of door een zorgverlener, labuitslagen of adviezen van zorgverleners. De log-files zijn bedoeld om enkele acties in de applicatie vast te leggen, hierbij gaat het bijvoorbeeld om een zorgverlener die een patiënt selecteert. Hierbij zullen dan de zorgverlener gegevens, het patiëntnummer en de datum/tijd worden vastgelegd. Deze log-files kunnen bijvoorbeeld worden gebruikt om zorgverleners te controleren. 24 aeXist


20040705

Vertrouwelijk Omdat ik niet direct inzicht had op de aantallen patiënten, zorgverleners en zorginstellingen, of het aantal metingen dat een patiënt bijvoorbeeld per jaar vastlegt, heb ik overlegd met de heer R. Hoekstra. Na wat cijfers te hebben opgezocht konden we beter inschatten welke data in welke collecties moest worden gestopt. Bij de analyse hebben we voor de volgende gevallen de aantallen opgezocht: Diabetespatiënten in Nederland Diabetespatiënten per zorginstelling Zorgverleners in Nederland Zorginstellingen in Nederland Met als aanname dat een patiënt gemiddeld één meting per dag invult. Omdat er veel patiënten zijn, met nog meer metingen, moesten we deze opsplitsen in veel collecties. Elke patiënt krijgt dus een eigen collectie waarin zijn eigen metingen komen te staan. De NAWgegevens van patiënten, zorgverleners en zorginstellingen komen in een aparte collectie te staan. En de log-files komen in een aparte collectie. Het uiteindelijke ontwerp ziet er als volgt uit:

25 aeXist


20040705

Vertrouwelijk Legenda: DB Bestand

Bevat

Radboud Collectie

Patient

Queries

Registratie

Zorgaanbiede r_registratie

1234 (Patientnummer)

Dashboard

4312 (Patientnummer)

Log

Zorgverlener_ registratie

987654 (Uzinummer)

Patient_regist ratie

Dagboek Log

Welbevinden

Log

Lichamelijk onderzoek Log

Anamnese

Behandelplan

Figuur 6

In figuur 6 is te zien dat de database zelf als een XML-collectie gezien kan worden. De collectie ‘db’ bevat dan de collecties die individueel per zorginstelling worden gecreëerd, in dit geval is dat het Radboud. Binnen de ‘radboud’-collectie is er weer een verdeling gemaakt in patient, queries, log en 26 aeXist


20040705

Vertrouwelijk registratie. Binnen deze collecties staan of nog meer collecties of er staan XML-bestanden in opgeslagen. Als er naast het ‘radboud’ nog een zorginstelling gebruik gaat maken van de applicatie krijgt deze instelling een vergelijkbare collectie als die van het radboud. Op deze manier blijven de gegevens van de twee ziekenhuizen wel gescheiden, maar is het ook mogelijk om data uit beide collecties te selecteren. De collectie patiënt is onderverdeeld in collecties die per patiënt worden aangemaakt. In de collectie van een patiënt komen dan alle medische gegevens te staan. De medische gegevens worden voor de leesbaarheid opgeslagen onder de naam van het formulier (XForm) waarin ze ingevuld zijn. Deze bestandsnamen worden nooit in een query gebruikt en kunnen dus willekeurig worden benoemd. De log-files worden in de collectie ‘log’ opgeslagen onder het zorgverlenernummer zodat de collecties in dit geval ook niet te groot gaan worden. De NAW-gegevens van de patiënten, zorgverleners en zorginstellingen komen in de collectie ‘registratie’ te staan. Ook worden er XQuery’s in de database opgeslagen deze worden in de collectie ‘queries’ gezet.

3. Uitvoering. Bij de uitvoering van het inrichten ben ik begonnen met het aanpassen van de database op mijn eigen computer. Bestaande query’s in de database hadden nog verwijzingen naar bepaalde locaties in de database. Deze verwijzingen moesten worden aangepast. Nadat ik had uitgetest dat deze aanpassingen aan de query’s in orde waren kon ik de nieuwe indeling van de database ook op de ‘live’-server toepassen.

4. Test. De database moet worden getest om te kunnen vaststellen of de gestelde eisen ook daadwerkelijk behaald zijn. De belangrijkste eis is hierbij dat de performance van de database op een goed niveau blijft. De database kan echter pas getest worden als deze veel data bevat. Hiervoor moet de database worden gevuld met test-data. Als deze data aanwezig is kan er gekeken worden of de data relatief snel uit de database te halen is, er kan dan een zogenaamde stress-test plaatsvinden. Door de tijdsdruk die bij dit project komt kijken, is er door mijn baas besloten deze test op een later moment uit te voeren.

5. Resultaat. Een database ontwerp waarbij rekening is gehouden met de performance door de collections zo klein mogelijk te houden. Om de performance in de toekomst ook te garanderen zal er gebruik moeten worden gemaakt van indexering. Zo kunnen bijvoorbeeld per bestand de patiëntnummers en meting-id’s, de SNOMED codes, worden geïndexeerd waardoor de database dit soort data sneller zou kunnen opzoeken. 27 aeXist


20040705

Vertrouwelijk

6.5 Ontwikkelen XForms. 1. Inleiding. Tijdens de afstudeerperiode heb ik naast het werk aan de algemene architectuur van de applicatie ook verschillende webformulieren gemaakt. Deze XForms zal ik niet specifiek beschrijven omdat mij dat niet interessant lijkt voor dit verslag. Wel zal ik hier de werkwijze van het maken van de XForms beschrijven. Om een duidelijk beeld te geven is het ontwikkelproces, van de XForms binnen de stichting Zorg e-Novatie, in het volgende figuur schematisch weergegeven:

28 aeXist


20040705

Vertrouwelijk

Ontwikkelproces XForms Software Engineers

Design teams

1. Maken HL7modellen

2. Maken/wijzigen wireframes

Gebruikerspanel

Wireframe afgekeurd

Evaluatie wireframe

Wireframe goedgekeurd 3. Ontwikkelen XForm (op basis van model en wireframe).

4. Testen XForm

5. Stylen XForm

Styling verbeteren

User feedback

Styling goedgekeurd 6. Live zetten XForm

Figuur 7

In figuur 7 is het ontwikkelproces van een XForm binnen de Stichting Zorg e-Novatie te zien. Mijn rol, aangegeven met het blauwe vak, bevindt zich hierin in het team van software engineers, binnen dit team is ook een onderverdeling. Zo is er één iemand met het maken van de modellen bezig en zijn de overige leden van dit team met het ontwikkelen van de XForms bezig.

29 aeXist


20040705

Vertrouwelijk

2. Aanpak. Bij het maken van de XForms kon ik dus twee documenten als uitgangspunt gebruiken, namelijk: een wireframe en het HL7-model. Het wireframe werd als ontwerpdocument aangeleverd voor de XForm. Hierbij was dan beschreven welke functionaliteiten het XForm moest bevatten. Het HL7model wordt als een soort template voor het XForm gebruikt. De invoervelden van het XForm zijn namelijk aan de XML-elementen uit het HL7-model gekoppeld. Het ontwikkelen van de HL7modellen, waar de XForms onder andere op zijn gebaseerd staat hieronder schematisch weergegeven:

Diabetes zorgstandaard

Nictiz basisdataset (HL7, SNOMED)

Extern

Intern Modellen

XForms

Database

Figuur 8

In figuur 8 is het ontwikkelproces van de modellen en XForms te zien. De XForms zijn op de modellen gebaseerd, deze zijn op hun beurt weer gebaseerd op de Nictiz documentatie, die weer op de Diabetes Zorgstandaard is gebaseerd. De Diabetes Zorgstandaard is opgesteld door de Nederlandse Diabetes Federatie, de NDF. De Zorgstandaard beschrijft de noodzakelijke onderdelen van zorg om diabetes te voorkómen, tijdig op te sporen en juist te behandelen. Nictiz is het landelijke expertisecentrum dat ontwikkeling van ICT in de zorg faciliteert. Met en voor de zorgsector voorziet Nictiz in mogelijkheden en randvoorwaarden voor elektronische informatieuitwisseling voor en rondom de patiënt. Nictiz stelt daarbij documenten samen van waaruit de modellen kunnen worden gevormd. De modellen bepalen de inhoud van de XForms, de XForms slaan de ingevulde XML-modellen op in de database. De externe input is nu gebaseerd op het diabetes ziektebeeld, maar de interne processen zijn zo ingericht dat dit ook kan veranderen naar andere ziektebeelden. Dit kan omdat de HL7 standaard en SNOMED niet specifiek voor diabetes zijn ontwikkeld, maar alle ziektebeelden omvatten.

30 aeXist


20040705

Vertrouwelijk

3. Uitvoering. Toen ik begon met het ontwikkelen van de XForms waren alleen de stappen één en twee uit figuur 7 gezet. Het proces na deze stappen moest nog gedefinieerd worden. Hierbij hebben we gekeken naar wat een efficiënte manier van ontwikkelen zou zijn. Omdat de stappen daarna nog niet ‘bewandeld’ waren moest er bij elke stap veel uitgezocht worden. Zeker bij het ontwikkelen van de XForms moesten er nog veel functies worden uitgezocht. Dit heb ik onder andere gedaan door elke functionaliteit stap voor stap te ontwikkelen en met elk XForm simpel te beginnen om dit vervolgens steeds uit te breiden.

4. Test. Bij het testen van de verschillende XForms heb ik geen testdocumenten gemaakt. Tijdens het ontwikkelen van de XForms ‘test’ je in principe elke functionaliteit die je toevoegt om te zien of het werkt.

5. Resultaat. De XForms zijn het deel van de applicatie wat de gebruiker te zien krijgt. Het is daarbij belangrijk dat het design er goed uitziet en dat de formulieren makkelijk in gebruik zijn. De eerste versies van de XForms worden momenteel gebruikt voor feedbacksessie met een aantal patiënten.

31 aeXist


20040705

Vertrouwelijk

6.6 Patiëntselectie module. 1. Inleiding. De applicatie heeft in principe twee verschillende soorten gebruikers, namelijk: de zorgverleners en de patiënten. De zorgverleners gebruiken de applicatie altijd om gegevens over patiënten op te slaan of in te zien. Daarom moet een zorgverlener na het inloggen altijd een patiënt selecteren, over wie de zorgverlener gegevens gaat invoeren of bekijken. Wettelijk gezien mag een zorgverlener alleen de gegevens bekijken van een patiënt die onder de behandeling is van de zorgverlener. Er zijn echter gevallen waarin een zorgverlener de gegevens van andere patiënten wel op mag vragen, zoals bij een spoedeisende ingreep. Dit betekent dat er geen restrictie op de patiëntselectie kan komen, maar er kan wel achteraf controle op worden uitgevoerd. Deze controle kan via log-files worden uitgevoerd. Tevens betekent dit dat de patiënten in het systeem niet aan een zorgverlener worden gekoppeld.

2. Aanpak. Bij het maken van de patiëntselectie module ben ik begonnen met het opstellen van het ontwerpdocument, zodat de eisen vastgelegd waren voordat er met het bouwen werd begonnen. Dit ontwerp staat beschreven in Afst_Patientselectie_ontwerp.doc. Het uitgangspunt van dit ontwerpdocument was het ontwerp wat door de designers was gemaakt. De eisen die in het ontwerpdocument staan beschreven kon ik krijgen door met R. Hoekstra te overleggen. Bij het maken van de selectie module wordt de meeste logica in de XQuery’s gezet. Ik had op dat moment nog geen ervaring met XQuery’s en moest dus tijd inplannen om de techniek te begrijpen. Om de techniek onder de knie te krijgen, ben ik begonnen met het volgen van een tutorial op internet. Het maken van de patiëntenselectie module ging in principe volgens de werkwijze zoals beschreven staat in hoofdstuk 6.5. Het enige verschil was dat er geen HL7 model voor was gemaakt, omdat er geen ingevoerde data hoefde te worden opgeslagen.

3. Uitvoering. Het maken van de patiëntenselectie module, was dus vooral werken met XQuery. En zoals gezegd kon ik dit met behulp van een tutorial op internet onder de knie krijgen. Het enige verschil zat hem in het ‘samen laten werken’ van XForms en XQuery. De data die vanuit de XQuery wordt terug gegeven moet in het XForm worden getoond. Het maken van de XQuery’s verliep zonder problemen, het testen van de XQuery’s kon in de browser worden uitgevoerd waardoor het XForm nog niet gemaakt hoefde te worden. Er moesten dus twee query’s worden gemaakt, om een indruk te geven van een XQuery is hier een voorbeeld van de query die patiënten op patiëntnummer selecteert.

32 aeXist


20040705

Vertrouwelijk

Figuur 9

In figuur 9 is de query te zien waarmee een patiënt op basis van een patiëntnummer wordt geselecteerd. De query begint met het definiëren van een aantal namespaces. Bij het maken van de query was het declareren van het HL7-namespace een groot struikelblok. Deze namespace is nodig om de juiste collectie in de database te kunnen selecteren. Vervolgens wordt er in de XQuery een parameter ‘opgevangen’, met de functie request:get-parameter(patientnummer). Met behulp van dit patiëntnummer wordt vervolgens in de collectie ‘gebruikers’ de juiste patiëntgegevens opgehaald. Dit ophalen wordt met behulp van een XPath expressie gedaan, die er dus als volgt uitziet: //db/v0-2/zorgdossier/patient/gebruikers/hl7:patient/hl7:id Het onderstreepte deel staat in een XQuery functie genaamd collection(), dit is het pad naar de collectie in de database. Nadat de collectie is geselecteerd hoeft er niet een specifiek bestand te worden aangewezen. De database maakt het namelijk mogelijk om data uit alle bestanden in de collectie te selecteren. ‘hl7:patiënt’ en ‘hl7:id’ verwijzen naar een element in een bestand in de collectie. Met ‘hl7:id[@extension=$patientnummer]’ wordt het attribuut ‘extension’ van het element ‘id’ vergeleken met de variabele patientnummer. In principe geef je daarmee aan dat het element ‘id’ moet worden geselecteerd waar het attribuut ‘extension’ gelijk is aan het patiëntnummer. Als er geen element ‘id’ wordt gevonden waarvan het attribuut ‘extension’ gelijk is aan het patiëntnummer wordt er niets terug gegeven. Bij het maken van deze query ben ik heel erg simpel begonnen met het laten zien van een tekst uit de database in de browser. Door steeds de query iets uit te breiden en te testen ben ik uiteindelijk op de volledige query uitgekomen.

33 aeXist


20040705

Vertrouwelijk Bij de XQuery hieronder was de moeilijkheidsgraad iets hoger. De query kan één of meerdere patiënten teruggeven op basis van een combinatie van BSN, achternaam, adres, plaats, postcode en geboortedatum.

Figuur 10

In figuur 10 is te zien dat net als in figuur 9 de parameters worden opgevangen. Vervolgens wordt met behulp van een XQuery for-loop door alle patiënten geïtereerd. Daarna wordt er binnen de iteratie gecontroleerd of de patiënt gegevens met de in het if-statement gedefinieerde criteria overeenkomen. Na de for-loop wordt de verzameling patiëntgegevens teruggegeven.

34 aeXist


20040705

Vertrouwelijk Bij het maken van deze query ben ik wederom simpel begonnen door de query alle patiënten terug te geven. Daarna ben ik de query uit gaan breiden met het if-statement, een if-statement in XQuery had ik nog nooit gemaakt. Daarom moest ik eerst uitzoeken hoe de structuur van een if-statement in elkaar zit. Op de w3schools heb ik het XQuery tutorial doorgelopen. Ook met het if-statement ben ik simpel begonnen door er één conditie in te zetten en deze vervolgens uit te breiden. Nu de XQuery’s gereed waren moest het XForm worden gemaakt, waarin de zorgverlener de patiënten kon opzoeken. Van de designers kon ik een layout-document krijgen waarin de invoervelden staan beschreven, zodat ik wist welk invoerveld waar moest komen te staan. Nu moest er nog functionaliteit aan het XForm worden gegeven. Het XForm bestaat in principe uit een aantal invoervelden en één uitvoerveld. De invoervelden bestaan uit: patiëntnummer, BSN, achternaam, adres, plaats, postcode en geboortedatum. Deze velden zijn bedoeld als invoer van de XQuery’s, de uitvoer van deze query’s kan dan in het uitvoerveld worden getoond. Het uitvoerveld in dit XForm bestaat uit een select-box waarin de resultaten van de XQuery’s dus geselecteerd kunnen worden. Als in de velden BSN, achternaam, adres, plaats, postcode en geboortedatum een waarde verandert moet een query worden uitgevoerd. In een normaal webformulier zou dit kunnen worden gedaan met behulp van Javascript, maar in XForms zijn daar standaard functies voor. Dit zou in principe het ontwikkelen makkelijker moeten maken, maar doordat de documentatie van deze functies gebrekkig bleek te zijn werd het moeilijker dan ik had gedacht. De weinige voorbeelden die er van de ‘onchange’ functies te vinden waren, lieten niet zien in welke context ze stonden. Hierdoor was ik wat tijd kwijt om de werking van deze functies te achterhalen. Uiteindelijk kon ik de functie implementeren, het was de bedoeling om de standaard functie aan het input-veld te koppelen zoals in het volgende figuur te zien is:

Figuur 11

In figuur 11 is te zien dat zodra in het input veld een waarde verandert de XQuery wordt aangeroepen met behulp van het Xforms:send element. Nu de XQuery’s op de juiste manier aangeroepen werden moest de optie voor het selecteren van de patiënten worden gemaakt. De resultaten van de query’s worden in een select-box gezet waarbij er één kan worden geselecteerd, de zorgverlener kan dan op de ‘selecteren’-knop drukken om gegevens van de patient te gaan bewerken of in te zien. Als de zorgverlener een patient selecteert 35 aeXist


20040705

Vertrouwelijk moet die worden vastgelegd in een log-file, zodat er controle kan worden uitgevoerd op de zorgverleners.

4. Test. Om het gemaakte XForm met bijbehorende XQuery’s te testen, heb ik een testplan opgesteld. Deze staat in Afst_Patientselectie_test.doc. Bij het testen heb ik een aantal acties van te voren opgesteld met het bijbehorende, door mij, verwachtte resultaat. Deze acties heb ik gedefinieerd aan de hand van de gestelde eisen. Het testen van de module is ook grotendeels tijdens het ontwikkelen gebeurd, omdat de query’s los ook al getest moesten worden. Bij het ontwikkelen van de query’s heb ik bij elke stap vooruit het resultaat getest, door de query’s in de browser aan te roepen.

5. Resultaat. Het gemaakte XForm ziet er als volgt uit:

Figuur 12

In figuur 12 is het gemaakte XForm te zien. Links bovenaan is de optie om op patiëntnummer te zoeken te zien. Zodra er op ‘zoeken’ wordt geklikt, wordt de XQuery uit figuur 9 uitgevoerd. Daaronder zijn de invoervelden voor het zoeken op een combinatie van geslachtsnaam, BSN, postcode, woonplaats, adres en geboortedatum te zien. Zodra in deze invoervelden een waarde veranderd wordt de XQuery in figuur 10 uitgevoerd. Het resultaat van de beide query’s wordt onder het kopje ‘Gevonden resultaten’ getoond. Hierin kan een patiënt worden geselecteerd. Als de knop ‘selecteer’ wordt ingedrukt wordt er een log-file gecreëerd op basis van de gekozen patiënt en de ingelogde zorgverlener.

36 aeXist


20040705

Vertrouwelijk Als resultaat zijn er niet alleen de gemaakte XForm en XQuery’s maar ook de kennis die ik tijdens deze opdracht heb opgedaan. Voor deze opdracht wist ik nog niet hoe XQuery’ werken of hoe ik deze met XForms kan laten samenwerken. Dat heb ik tijdens deze opdracht dus wel geleerd.

37 aeXist


20040705

Vertrouwelijk

7. Evaluatie. In de voorgaande hoofdstukken heb ik de werkzaamheden uit mijn afstudeerstage beschreven. In dit hoofdstuk zal ik terugblikken op deze periode. Hierbij zal ik het proces en het product evalueren.

7.1 Producten. In deze paragraaf zal ik reflecteren op de producten die ik tijdens mijn afstudeerperiode heb gemaakt. Hierbij moet ik stellen dat niet alle producten, zoals in het afstudeerplan beschreven, zijn gemaakt. Dit komt door de in hoofdstuk 3 genoemde oorzaken, de ontwikkelingen waren bij het bedrijf nog niet zo ver als van te voren ingeschat was.

1. Ontwikkelomgeving. De ontwikkelomgeving van het bedrijf was toen ik begon met het project nog niet echt ingericht. Er werd nog niets met versiebeheer gedaan en het was niet mogelijk om met meerdere mensen tegelijk aan één bestand te werken. Mijn rol in het inrichten van de ontwikkelomgeving is vooral van adviserende aard geweest. Het eindresultaat is een ontwikkelomgeving waarin, door het gebruik van SVN, wel met meerdere personen in één bestand kan worden gewerkt. Dit kan bijvoorbeeld handig zijn als het design team met een XForm bezig is waarin ook technisch nog wat aangepast moet worden.

2. Loginsysteem. Het loginsysteem levert het role-based-access waardoor het mogelijk is om gebruikers meerdere rollen toe te kennen. Op deze manier worden de twee ‘kanten’ van de applicatie, het patiëntendeel en het zorgverlener deel, op een nette manier gescheiden gehouden. Doordat de Tomcat server en het Orbeon platform ‘samenwerken’ is het mogelijk om in elk XForm de gegevens van de ingelogde gebruiker uit te lezen. Bij het testen is ook gebleken dat het loginsysteem aan de gestelde eisen voldoet.

3. Database ontwerp. Omdat het testen van het database ontwerp pas op een later tijdstip zal plaatsvinden is het lastig te beoordelen. Het ontwerp, met collecties, is zo in elkaar gezet dat het naar mijn mening goed uitbreidbaar is. Door de naamgeving zijn de database bestanden overzichtelijk te houden.

4. XForms. De XForms die ik heb gemaakt tijdens mijn stageperiode zijn, zoals al eerder vermeld, al in gebruik in de testversie van de applicatie. Deze XForms voldoen aan de in de ontwerpdocument vermelde eisen.

38 aeXist


20040705

Vertrouwelijk

5. Patiëntselectie module. De patiëntselectie module voldoet aan alle, van te voren, gestelde eisen. Dit is vastgelegd in het testdocument. Met behulp van deze module is het voor zorgverleners mogelijk gemaakt om patiënten op een slimme manier op te zoeken.

7.2 Proces. In dit hoofdstuk zal ik het werkproces uit mijn stageperiode evalueren. Bij deze evaluatie is het belangrijk om rekening te houden met het feit dat ik, voor aanvang van dit project, geen ervaring had met de gebruikte technieken. Tijdens dit project heb ik volgens het Agile-software-ontwikkelmethode gewerkt. Wat beknopt inhoudt dat de eisen snel kunnen worden gewijzigd. Er worden daarbij dus geen dikke documenten met eisen opgesteld maar er wordt snel naar een werkend product toegewerkt. Deze methode paste perfect bij dit project, omdat het project erg innovatief is. Ook zijn de gebruikte technieken redelijk onbekend waardoor het moeilijk wordt om een product van te voren volledig te ontwerpen. Veel keuzes, die zijn gemaakt, waren voor een groot deel afhankelijk van de mogelijkheden die de technieken bieden. Om deze wat chaotisch ogende methode toch te beheren was veel overleg nodig. Vaak was dit overleg in de vorm van een gesprek of een email. Om de planning te beheren was er elke maandagochtend een vergadering waarin elk groepslid zijn werk kon demonstreren en een planning voor de aankomende week kon worden besproken. Deze planning moest vaak bijgewerkt worden omdat de tijd, die voor het uitzoeken van de technieken nodig is, vaak lastig in te schatten was. Ook moest het ontwerp vaak worden bijgewerkt omdat bepaalde ontwerpkeuzes niet technisch mogelijk bleken te zijn. De globale planning binnen het bedrijf was gericht op een aantal mijlpalen. Namelijk een presentatie in Luxemburg, waarvoor een prototype van de applicatie klaar moest zijn. En een feedback sessie van ‘proefpatiënten’, voor beide versies moest het een en ander klaar zijn. Voor deze mijlpalen moesten verschillende struikelblokken worden opgelost. Zo was voor het prototype de beveiliging nog niet zo belangrijk, terwijl dat bij de latere ‘test’-versie wel belangrijk was. En moest het loginsysteem dus klaar zijn voor de ‘test’-versie.

1. Ontwikkelomgeving. Het inrichten van de ontwikkelomgeving had een grote prioriteit aan het begin van het project. Om de productiviteit van het bedrijf te kunnen verbeteren was het noodzakelijk de ontwikkelomgeving te professionaliseren. Met behulp van het versiemanagement werd het mogelijk om met meerdere mensen aan de applicatie te werken.

39 aeXist


20040705

Vertrouwelijk Mijn rol in het inrichten van de ontwikkelomgeving was vooral van adviserende aard. Daarbij heb ik SVN aangeraden om als versiemanagement tool te gebruiken.

2. Loginsysteem. Bij het maken van het loginsysteem had ik veel tijd nodig om de technische details uit te zoeken. Omdat er niet veel informatie beschikbaar was moest ik het één en ander uitproberen. Hierbij mislukte de eerste aanpak maar daarmee is de tijd niet volledig weggegooid. Bij deze mislukte aanpak heb ik namelijk het één en ander kunnen leren over de Tomcat server en Orbeon.

3. Database ontwerp. Het maken van het database ontwerp heeft tijdens mijn stageperiode flink wat tijd gekost. Ook bij dit onderdeel was er veel tijd nodig om de technieken te onderzoeken. Het werken met een Native XMLdatabase vergt een geheel andere denkwijze dan het werken met een traditionele database. Door deze andere denkwijze, omdat er niet met tabellen maar met collecties wordt gewerkt, moest ik een periode uitplannen om de techniek onder de knie te krijgen. Hierbij kon ik gelukkig wel enige informatie op het internet vinden.

4. XForms Bij het maken van de verschillende XForms was veel tijd nodig voor het uitzoeken van functies binnen XForms. Bij het maken van een planning was het daarom moeilijk om in te schatten hoeveel tijd per XForm nodig zou zijn. Het werk wat ik in het uitzoeken heb gestopt is niet verloren gegaan doordat ik de functies in de documentatie van de XForms heb vastgelegd.

5. Patiëntselectie module. Het maken van de patiëntselectie module ging een stuk sneller dan het maken van de andere onderdelen. Omdat ik al bekend was geworden met het maken van XForms. Maar omdat er wat XQuery’s moesten worden gemaakt, een techniek waar ik nog geen ervaring mee had, had ik ook voor deze opdracht wat tijd nodig om de nieuwe techniek te leren kennen. Na de XQuery’s te hebben gemaakt kwam ik bij het volgende struikelblok, namelijk het laten samenwerken van de XQuery’s en XForms. Om over dit punt heen te komen moest ik het één en ander uitproberen maar door middel van trial en error ben ik uiteindelijk verder gekomen.

40 aeXist


20040705

Vertrouwelijk

8. Conclusie. In dit hoofdstuk zal ik beschrijven welke beroepstaken ik bij dit project heb gedemonstreerd en wat mijn algemene ervaring bij dit project is geweest.

1. Beroepstaken. In het afstudeerplan wat voor de aanvang van de stage is goedgekeurd staan de beroepstaken opgesteld waaraan tijdens dit project moest worden voldoen. Deze beroepstaken zijn: Werken in (internationale) projecten (niveau 3) Resultaatgericht werken (niveau 3) Uitvoeren analyse door definitie van requirements (niveau 3) Ontwerpen, bouwen en bevragen van een database (niveau 4) Bouwen applicatie (niveau 3) Initiëren en plannen van het testproces (niveau 3) Uitvoeren van en rapporteren over het testproces (niveau 3) De nadruk bij dit project lag bij de beroepstaken: ‘ontwerpen, bouwen en bevragen van een database’ en bij ‘bouwen applicatie’. Deze beroepstaken zijn naar mijn mening tijdens dit project behaald. Het bouwen van de database was dan wel geheel anders dan ik van school uit heb geleerd. Maar dat komt omdat de technieken die bij dit project worden gebruikt niet zoals de traditionele software technieken zijn. In paragraaf 6.4 is te lezen hoe ik de database heb ontworpen. De beroepstaak ‘bouwen applicatie’ is naar mijn mening behaald omdat ik tijdens dit project een aantal belangrijke aspecten van het zelfzorgdossier heb ontwikkeld. Daarbij ben ik systematisch te werk gegaan door eerst uitzoekwerk te verrichten waarna een ontwerpdocument kon worden opgesteld.

2. Ervaring. Tijdens dit project heb ik ervaring opgedaan met het gebruiken van technieken zoals: XForms, XPath, XQuery en XProc. Daarnaast heb ik ervaring opgedaan in het professionaliseren van een werkomgeving, waarbij ik dan wel vooral een adviserende rol heb gespeeld. Omdat ik bij dit bedrijf belangrijke onderdelen van de applicatie mocht maken heb ik ook kunnen leren hoe de architectuur van de applicatie in elkaar zit. Toen ik aan dit project begon had ik geen enkele ervaring met de gebruikte technieken, ook bij het bedrijf ontbrak de ervaring met deze technieken. Dit heeft mij veel tijd gekost omdat ik alle functionaliteiten van de technieken zelf moest uitzoeken. Als ik dit uitzoekwerk niet had hoeven verrichten had ik meer modules voor de applicatie kunnen maken. 41 aeXist


20040705

Vertrouwelijk

9. Woordenlijst. HL7v3

Health Level 7 versie 3 is een internationale standaard voor elektronische uitwisseling van medische, financiële en administratieve gegevens tussen zorginformatiesystemen.

XML

Extensible Markup Language is een standaard van W3C waarmee gestructureerd data kan worden weergegeven in platte tekstformaat.

eXist

eXist is de Native XML-database waarvan bij dit project gebruik wordt gemaakt. Het is een open source project die volledig op XML- technologie is gebouwd.

Orbeon

Orbeon is het platform waarin de XForms van dit project worden ontwikkeld en geïmplementeerd.

XForms

XForms is een W3C standaard, een XForm is een webformulier waarmee een gebruiker data kan invoeren. Deze data wordt dan volgens een XML-model opgeslagen in XML-formaat

XPath

XML Path Language is een taal waarmee delen van een XML-bestand kunnen worden opgezocht. XPath heeft een geheel eigen syntaxis en kan worden gezien als een soort kleine query-taal.

XQuery

XQuery is een query-taal waarmee informatie uit een of meerdere XMLbestanden kan worden opgevraagd.

XProc

XProc is een programmeertaal voor het maken van XML-pipelines. Met een pipeline kun je verschillende acties uitvoeren op een XML-bestand.

SVN

Subversion is een versiebeheer gereedschap, waarmee je documenten per versie kunt opvragen. Je kunt hier tevens meerdere versie mee samenvoegen.

42 aeXist


20040705

Vertrouwelijk

10.

Literatuurlijst.

1. Internet bronnen.

Wikibook over XForms. http://en.wikibooks.org/wiki/XForms Wikibook over XQuery. http://en.wikibooks.org/wiki/XQuery Wikibook over XProc. http://en.wikibooks.org/wiki/XProc Orbeon website. http://www.orbeon.com W3schools tutorials. http://www.w3schools.com Tomcat website. http://tomcat.apache.org Raad voor de Volksgezondheid website. http://www.rvz.net

43 aeXist


20040705

Vertrouwelijk

11.

Overzicht bijlage.

1. Plan van aanpak.

2. Login ontwerp.

3. Login testverslag.

4. Database ontwerp.

5. Patientselectie ontwerp.

6. Patientselectie testverslag.

44 aeXist


20040705

Het ontwikkelen van een online patiëntendossier

Recommend Documents