Geavanceerde applicatie voor patiëntopvolging en trendanalyse

Transcriptie

1 Geavanceerde applicatie voor patiëntopvolging en trendanalyse Jonas Casteur en Kim Schrooten Promotoren: prof. dr. ir. Filip De Turck, prof. dr. Koenraad Smets Begeleiders: dr. ir. Marc De Leenheer, Kristof Steurbaut Masterproef ingediend tot het behalen van de academische graad van Master in de toegepaste informatica Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Vakgroep Pediatrie en genetica Voorzitter: prof. dr. Dirk Matthys Faculteit Ingenieurswetenschappen Academiejaar

2 Voorwoord Graag willen we een aantal mensen bedanken die dit eindwerk mede tot stand hebben gebracht. Vooreerst gaat onze dank naar Prof. Dr. Ir. Filip de Turck en prof. dr. Koenraad Smets, onze promotoren, voor hun positieve aanmoediging en begeleiding. Daarnaast willen we onze begeleiders dr. ir. Marc De Leenheer en Kristof Steurbaut bedanken voor hun raadgeving en betrokkenheid. Een speciaal woord van dank gaat uit naar Femke De Backere voor het bijstaan in moeilijke tijden. Ten slotte willen we ook onze familie en vrienden voor de interesse en steun. Jonas Casteur en Kim Schrooten Gent, 28 mei 2010 ii

3 Verklaring van bruikleen De auteurs geven de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef. Gent, 28 mei 2010 Jonas Casteur Kim Schrooten iii

4 Inhoudstabel Voorwoord... ii Verklaring van bruikleen... iii Lijst van figuren...vi Lijst van tabellen...viii Gebruikte afkortingen en termen...ix 1 Inleiding Probleemstelling Doelstelling Analyse van de functionele vereisten Vereisten Draaiboek op basis van documentatie UZ Gent Use case diagram Architectuur High level architectuur Theorie Toepassing Database Theorie Toepassing Databasemap Java Enterprise Edition Persistence tier Business logic tier Web tier Invoer: PDF itext OpenOffice.org Uitvoer: notificaties en rapportering Herinnerings E mail Exporteren en gegevensanalyse iv

5 4 Uitgewerkte case Opeenvolging taken Gebruikershandleiding Registreren als nieuwe gebruiker PDF formulieren downloaden en uploaden Het admin menu Conclusie en mogelijke uitbreidingen Bijlagen Bibliografie v

6 Lijst van figuren Figuur 1 Cytomegalovirus...1 Figuur 2 Usecase diagram van de functionele vereisten...8 Figuur 3 Java EE architectuur...9 Figuur 4 Gedetailleerde Java EE architectuur...10 Figuur 5 Java EE voor de CMV applicatie...11 Figuur 6 One-to-one mapping...13 Figuur 7 One-to-many, many-to-one mapping...13 Figuur 8 Many-to-many mapping...14 Figuur 9 Algemeen overzicht van de database...19 Figuur 10 Database Patient - Mother relatie...20 Figuur 11 Database Patient - Doctor relatie...20 Figuur 12 Database Diagnostic...21 Figuur 13 Database AudioFollowup...21 Figuur 14 Database AudioIntake...22 Figuur 15 Database Treatment...22 Figuur 16 Database Additional Screening...23 Figuur 17 Relatie tussen Patient en Mother...26 Figuur 18 Legende Java Server Pages...34 Figuur 19 Java Server Pages - Inlog- en registratieproces...35 Figuur 20 Java Server Pages - Menukeuze...35 Figuur 21 Java Server Pages - Administratormenu...36 Figuur 22 CSV bestand...41 vi

7 Figuur 23 legende stroomdiagram...42 Figuur 24 Stroomdiagram registratieproces...43 Figuur 25 Stroomdiagram Invullen patiëntgegevens...44 Figuur 26 Stroomdiagram gebruikersbeheer...45 Figuur 27 Startpagina website...46 Figuur 28 Registratie pagina...47 Figuur 29 Mededeling nieuwe gebruiker aan admin...47 Figuur 30 bevestiging registratie...48 Figuur 31 Welkomstpagina admin...48 Figuur 32 Admin menu...49 Figuur 33 Pagina met lijst nieuwe registraties...50 Figuur 34 bevestiging toegang...50 Figuur 35 account verwijderd...51 Figuur 36 Welkomstpagina gewone gebruiker...51 Figuur 37 Lijst patiënten van de gebruiker...52 Figuur 38 Download pagina...52 Figuur 39 PDF-formulier registratie patiënt...53 Figuur 40 PDF-Formulier Behandeling patiënt...54 Figuur 41 Upload pagina...55 Figuur 42 User management...56 Figuur 43 toekennen admin rechten...56 Figuur 44 Bestanden exporteren naar csv vii

8 Lijst van tabellen Tabel 1 Draaiboek op basis van documentatie van het UZ Gent...7 Tabel 2 Datatypes in Java...24 Tabel 3 Entiteiten in Java EE...27 Tabel 4 Facades...28 Tabel 5 Session beans...32 Tabel 6 Java Server Pages...34 Tabel 7 CSV invoer in Excel...41 viii

9 Gebruikte afkortingen en termen CMV ejb war Java EE PDF html csv UML SMTP Cytomegalovirusinfectie Enterprise JavaBeans Web Application Archive Java Enterprise Edition Portable Document Format HyperText Markup Language Comma-separated values Unified Modelling Language Simple Mail Transfer Protocol De term gebruiker staat voor een arts die van het systeem gebruik maakt. Indien deze gebruiker een administrator is, zal hij admin worden genoemd. ix

10

11 1 Inleiding 1.1 Probleemstelling Cytomegalovirus(CMV)-infectie is een veelvoorkomende perinatale besmetting. Deze besmetting wordt aangetroffen bij 0,6 tot 1% van de levendgeborenen in Vlaanderen per jaar. Dit vertaalt zich naar 400 tot 600 patiënten per jaar. Bij de patiënten worden er op lange termijn vooral neurosensoriële doofheid en psychomotorische vertraging in de ontwikkeling gevreesd als gevolg van de congentiale infectie (Goossens, Temmerman, & Vanhaesebrouck, 2003). Door het beschikbaar worden van het geneesmiddel Ganciclovir (Cymevene ), dat mogelijk een belangrijke rol kan spelen bij de preventie van ernstige gehoorstoornissen bij het opgroeiend kind, komt deze infectieziekte opnieuw in het centrum van de belangstelling. Figuur 1 Cytomegalovirus (Abbott Diagnostics, 2006) Een elektronische database is van belang voor een langdurige opvolging van alle kinderen met congenitale CMV-infectie in Vlaanderen. Op dit moment is hiervoor geen databankgedreven applicatie aanwezig op de afdeling Neonatalogie van het Universitair Ziekenhuis Gent. Hierdoor zijn de artsen genoodzaakt alle data op papieren documenten te bewaren. Indien men deze data wil analyseren of exporteren moet dit handmatig in een Excelbestand ingevoerd worden. Dit maakt opvolging, analyse en opzoekingen uiterst moeilijk en omslachtig. In nauwe samenwerking met het Universitair Ziekenhuis Gent werd 1

12 daarom besloten een databankgedreven applicatie te ontwikkelen ter ondersteuning van de dataregistratie en opvolging. 1.2 Doelstelling De doelstelling is het ontwikkelen van een systeem waarmee geregistreerd kan worden hoe de diagnostiek tot stand kwam, welke afwijkingen aanwezig waren bij de geboorte en het verloop van de verdere behandeling. Dit heeft als doel de patiënten op lange termijn (6 jaar) op te volgen op het gebied van neuromotoriek, gehoor en visus. Visus is een maat voor gezichtsscherpte als onderdeel van het gezichtsvermogen. Het systeem maakt het daarnaast mogelijk om de verzamelde gegevens te onderwerpen aan data-analyse om belangrijke tendensen weer te geven. 2

13 2 Analyse van de functionele vereisten In dit hoofdstuk wordt eerst een overzicht gegeven van de functionele eisen die aan de applicatie worden gesteld. Daarna geeft een use case diagram de mogelijkheden per gebruiker weer. 2.1 Vereisten Gebruikersregistratie: Elke arts kan zich online registreren als een potentiële gebruiker van de applicatie. Een nieuwe gebruiker moet door een administrator toegang verleend worden tot de website. Zolang een administrator een nieuwe gebruiker niet aanvaard heeft, kan de gebruiker niet inloggen. Patiëntregistratie: Elke gebruiker kan gegevens van zijn patiënten invullen. Elke gebruiker moet toegang kunnen krijgen tot de gegevens van zijn patiënten. Om de gegevens van patiënten van andere artsen te bekijken is echter eerst goedkeuring nodig door een administrator. Bij patiënten die door een andere arts behandeld worden kan men enkel het ID nummer, geslacht en geboortedatum bekijken, zodat de persoonlijke gegevens van de patiënt vertrouwelijk blijven. Formulieren: De verschillende formulieren om de patiëntinformatie in te vullen kunnen als PDF-formulier van de website gedownload worden. Dit biedt de mogelijkheid aan de artsen om de gegevens op een later tijdstip, al dan niet verbonden met het internet, in te vullen. Zodra de formulieren zijn ingevuld, kan de gebruiker de formulieren uploaden op de website, zodat ze in een centrale database bewaard worden. Follow-up: Elke 6 maanden na de geboorte van de patiënt, dient zijn behandelende arts een follow-up formulier in te vullen. Wanneer zo een deadline nadert, moet de applicatie automatisch een ter herinnering naar de arts sturen. Excel: De gebruiker heeft de mogelijkheid om de verschillende patiëntgegevens uit de database te exporteren naar Excel (bv. door middel van een csv-bestand). Hierdoor kan men verdere analyses uitvoeren op de gegevens uit de database. Administrator: Beheerders moeten in staat zijn om de lay-out van de PDFformulieren aan te passen, zoals bv. toevoegen of weglaten van items. Verder kan 3

14 een administrator een gewone gebruiker administrator rechten gegeven en gebruikers verwijderen. Rapportering: Jaarlijks moet op eenvoudige wijze een verslag gegenereerd worden, waarin belangrijke tendensen worden weergegeven op numerieke en grafische wijze. 2.2 Draaiboek op basis van documentatie UZ Gent 1 User 2 Administrator 3 Beide 4 Applicatie zelf Actie 1 Surfen naar de website Toont loginscherm: login of aanvraag login 1 Aanvraag login Aanvrager vult gegevens in in het formulier op de website: o Naam en Voornaam o adres o Telefoonnummer o Vakgebied o Eventueel soort arts o Ziekenhuis of praktijk (eventueel adres) o Eventueel commentaar waarom hij een login wilt Wanneer de aanvrager op Send drukt, worden deze gegevens doorgestuurd naar de administrator. De admin krijgt via een notificatie en hij kan deze aanvraag terugvinden op de website onder een speciale pagina Aanvragen 2 Goedkeuren aanvragen en paswoorden De administrator behandelt de aanvraag en beslist of deze aanvaard wordt. Hij kan op een venster waartoe enkel hij toegang tot heeft een lijst van aanvragen zien. Bij aanvaarding wordt er automatisch een registratie van de user in de database gemaakt en een gestuurd naar de user met daarin: 4

15 o Login-naam: (in optie) een combinatie van de eerste letter van de voornaam en de achternaam en afkorting van het vakgebied o Paswoord: (in optie) automatisch random gegenereerd door de applicatie. Mogelijkheid tot wijzigen via de website later Bij weigering wordt er een gestuurd naar de aanvrager met een adres of telefoonnummer waarmee hij de admin zal kunnen contacteren voor verdere vragen 3 Keuzemogelijkheden website Gebruikers Ingeven nieuwe patiënt Invullen/(wijzigen: in optie) gegevens Raadplegen gegevens patiënten (in optie) Userprofiel (in optie, voor aanpassen gegevens, o.a. paswoorden) Tabel met de namen van de patiënten van de arts en hun IDNummers Administrator: o Aanvragen login o Aanvragen leesrechten (in optie) o Patiënten Alle informatie over patiënt opzoeken In optie: Verschillende views (alle patiënten per arts, vakgebied, leeftijd, enz) o Formulieren (in optie: mogelijkheid tot aanpassen) 1 Ingeven nieuwe patiënt Ingeven persoonsgegevens: o Naam en voornaam o Geboortedatum o Geslacht o Geen adres o (Naam ziekenhuis/praktijk) o (Vakgebied) Wanneer de arts op ok drukt, wordt de patiënt toegevoegd aan de database met het IDNummer dat automatisch wordt aangemaakt. Voor elk vakgebied wordt er een ander 5

16 IDNummer aangemaakt per patiënt. In de database moet dan wel een koppeling komen voor de patiënt met de verschillende IDNummers. In optie: een pdf-bestand wordt aangemaakt met deze informatie + het IDNummer voor de patiënt 1 Invullen gegevens patiënt De arts kan op basis van het IDNummer waarden ingeven van een patiënt. o Ingave IDNummer van de patiënt o In optie: het tijdstip van waarneming moet telkens vermeld worden o Tekstvelden o Keuzelijsten waar slechts 1 item kan geselecteerd worden o Keuzelijsten waar meerdere items in geselecteerd worden In optie: na ingave kan de arts deze waarden exporteren naar een pdf-bestand De arts kan enkel waarden ingeven voor IDNummers waar hij toegangsrechten (leesen schrijfrechten) voor heeft Bij het bevestigen worden de gegevens in de database gekoppeld aan het IDNummer Optie: Mogelijkheid om vorige ingaven te wijzigen 3 Raadplegen gegevens patiënten Gegevens van de patiënten van de arts moeten kunnen worden weergegeven o IDNummer o Leeftijd o Geslacht o Waarden o Tijdstip (vanaf geboorte blokken van 6 maanden) Deze moeten geëxporteerd kunnen worden naar een excelbestand. Mogelijkheid gegevens andere artsen in te kijken, mits goedkeuring admin. De arts geeft aan welke gegevens hij wilt bezichtingen: o Dezelfde patiënt, ander vakgebied o Hetzelfde vakgebied, alle patiënten o Alle vakgebieden, alle patiënten 6

17 In optie: de admin ontvangt deze aanvraag en beslist of hij (lees)rechten geeft aan de arts. o Dit kan beperkt worden in de tijd o Het is nooit toegelaten om persoonlijke informatie (de naam van de patiënt) mee te geven. Er wordt altijd gewerkt op basis van IDNummers. Gegevens (of een deel daarvan) moeten kunnen geëxporteerd worden naar een excelbestand. 2 Aanpassen keuzemogelijkheden bij De admin moet de mogelijkheid hebben om invoer van waarden op vraag van de arts de keuzemogelijkheden voor invoer van de gegevens te wijzigen (extra mogelijkheden toevoegen). Hierdoor wordt er een nieuw veld aangemaakt in de database, oudere records kunnen hier best null krijgen Artsen van het vakgebied krijgen hierover een mail zodat ze op de hoogte zijn van de wijziging 4 Reminders De database houdt bij wanneer de deadlines voor ingave zijn (elke 6 maanden na geboortedatum) De applicatie kijkt elke nacht na of er een deadline nadert Bij het naderen van de deadline wordt er een reminder gestuurd naar de arts om gegevens aan te vullen. Als gegevens al ingevuld zijn, vervalt de deadline 4 Rapporteringmodule Jaarlijks aanmaak van een rapport, progressief in de tijd Eventueel samen met exportering van de gegevens in excel. Voor de analyse kan men een macro in Excel schrijven. Een vast aantal items komen jaarlijks terug in het verslag Tabel 1 Draaiboek op basis van documentatie van het UZ Gent 7

18 2.3 Use case diagram Het use case diagram geeft een schematisch overzicht welke de functies zijn waarvan de verschillende gebruikers, zijnde een gewone gebruiker en administratoren, gebruik kunnen maken. Figuur 2 Usecase diagram van de functionele vereisten 8

19 3 Architectuur 3.1 High-level architectuur Theorie Voor de ontwikkeling van deze applicatie hebben we gekozen voor de programmeeromgeving Java EE. Deze omgeving laat toe om meerdere lagen in de applicatie te programmeren. Op de Java EE server kan men meerdere lagen onderscheiden: Web tier Business logic tier Persistence tier Figuur 3 Java EE architectuur De web tier is de presentatielaag van de applicatie. Hier wordt de architectuur voor de gebruikerszijde geprogrammeerd, bijvoorbeeld een website. Deze architectuur wordt geprogrammeerd in jsp-files, Java Server Pages. Dit zijn tekstgebaseerde documenten waarin men in een combinatie van HTML code en Java code gaat programmeren die de client (gebruiker) te zien krijgt. De business logic tier maakt deel uit van de business tier op de Java EE server (zie Figuur 4). Hier wordt door middel van session beans geprogrammeerd wat de verschillende stappen zijn voor het uitvoeren van opdrachten. Session beans zijn kleine programma s die uittekenen hoe men de opdrachten van de gebruiker zal uitvoeren (bijvoorbeeld het ingeven van data in een formulier, het opvragen van een lijst van gebruikers, enz ). Daarnaast behandelt de logische laag met behulp van facades de verschillende opdrachten voor de database. Deze laag kan bijvoorbeeld een nieuwe entity Persoon aanmaken met de door de gebruiker ingevoerde gegevens, door middel van een query (zoekopdracht) de personen met achternaam Janssen opzoeken, enz... 9

20 De persistence tier maakt deel uit van de business tier op de Java EE server en is een schakel in de communicatie tussen de logische laag (meer bepaald de facades) en de database. In deze laag worden de tabellen van de database gegenereerd. Men gaat entiteiten programmeren waarin men definieert welke waarden in de tabellen komen (bijvoorbeeld een entity Persoon met daarin de variabelen Voornaam, Achternaam, Geboortedatum en Geslacht). Deze entiteiten kan men in de Java EE programmeertaal beschouwen als een op zichzelf staand object dat verbonden kan worden met andere entiteiten (bijvoorbeeld Persoon kan verbonden worden met Woonplaats). Op die manier kan de volledige wereld gemodelleerd worden. Figuur 4 Gedetailleerde Java EE architectuur (Sun, 2008) Een van de grote voordelen van een gelaagde architectuur is dat men zeer gemakkelijk een laag kan aanpassen zonder de overige lagen te moeten herprogrammeren. Dit komt de uitbreidbaarheid van de applicatie ten goede. Daarnaast zorgen de lagen voor meer plaatsen waar het systeem beveiligd kan worden. Door de gelaagdheid kan de gebruiker bijvoorbeeld nooit rechtstreeks de data in de database wijzigen omdat zijn opdrachten worden behandeld door de logische laag. De architectuur maakt het ook mogelijk dat de lagen draaien op verschillende servers, waardoor men het functioneren van de applicatie kan distribueren (Cade, Humphrey, & Sheil, 2010). Een gedistribueerde uitvoering is, mits een goede planning, efficiënter omdat de delen van de applicatie op servers kunnen draaien die het meest geschikt zijn voor de specifieke functionaliteit. Java EE is daarnaast 10

21 ook platformafhankelijk, wat betekent dat het probleemloos op elke computer kan draaien, onafhankelijk van bijvoorbeeld het besturingssysteem Toepassing De componenten van onze applicatie voor patiëntopvolging en trendanalyse hebben we op volgende wijze geprogrammeerd: Figuur 5 Java EE voor de CMV applicatie Aan de web tier kant hebben we onder meer een login pagina en een upload pagina voor de PDF-formulieren geprogrammeerd (een gedetailleerde uitwerking volgt verder in deel 0). Daarnaast hebben we een mogelijkheid voorzien om een administrator te benoemen die meer rechten heeft dan een gewone gebruiker en de verschillende registratieaanvragen behandelt. De business logic tier heeft session beans (facades) die het onder meer mogelijk maken entiteiten aan te maken (create), deze op te slaan in de database (persist) en om zoekopdrachten uit te voeren (find). De session bean logic behandelt onder meer het inlezen van de gegevens van de PDF-formulieren en de registratie van een nieuwe gebruiker (een gedetailleerde uitwerking volgt verder in deel 0). Een mailcomponent is geprogrammeerd om de verschillende bevestigingen en reminders (die bijgehouden worden door de timer) te sturen. Als laatste hebben we de mogelijkheid voorzien om de data van de database te exporteren naar een csv bestand, wat de mogelijkheid biedt deze data verder te analyseren in Excel. 11

22 De persistence tier bevat entiteiten zoals Patient, Doctor, Treatment, enzovoort. Elk PDFformulier (treatment, additional screening, ) is een entity omdat deze gegevens als een aparte tabel in de database worden opgeslagen. 12

23 3.2 Database Theorie In een database kan men 4 soorten relaties definiëren: One-to-one One-to-many Many-to-one Many-to-many One-to-one Elke entity-instantie is gerelateerd aan een enkele instantie van een andere entity. De annotatie javax.persistence.onetoone wordt geïmporteerd in de entiteiten die deel uitmaken van deze relatie. Figuur 6 One-to-one mapping One-to-many, Many-to-one Een entity-instantie kan gerelateerd zijn aan verschillende instanties van andere entiteiten. Iemand woont bijvoorbeeld in één stad, maar deze stad heeft meer dan één inwoner. De annotatie javax.persistence.onetomany wordt geïmporteerd in de entiteiten die deel uitmaken van deze relatie. Figuur 7 One-to-many, many-to-one mapping 13

24 Many-to-many De entity-instanties kunnen gerelateerd zijn aan verschillende instanties van andere entiteiten. Een student volgt bijvoorbeeld veel vakken en deze vakken hebben meerdere studenten. De annotatie javax.persistence.manytomany wordt geïmporteerd in de entiteiten die deel uitmaken van deze relatie (Sun, 2008). Figuur 8 Many-to-many mapping Toepassing In dit hoofdstuk wordt onze databasestructuur uitgelegd aan de hand van Java EE entiteiten. Voor een gedetailleerde uiteenzetting van deze entiteiten, gelieve paragraaf te raadplegen of Tabel 3. One-to-one Tussen de entiteiten Patient en Mother bestaat er een one-to-one relatie. Een moeder kan meerdere kinderen (patients) hebben maar een kind heeft maar één moeder. Deze verhouding doet een one-to-many relatie vermoeden maar dit wordt onmogelijk gemaakt doordat de gegevens van de moeder telkens vernieuwd worden bij ingave. Waarden zoals het aantal weken zwangerschap, de plaats van tewerkstelling, enz. kunnen bij elke geboorte gewijzigd zijn. Deze relatie wordt geprogrammeerd in de entity Patient op volgende private Mother patient_mother; public Mother getpatient_mother() { return patient_mother; } public void setpatient_mother(mother patient_mother) { this.patient_mother = patient_mother; } 14

25 In de entity Mother wordt deze relatie op volgende wijze = "patient_mother") private Patient patient; MappedBy geeft de owning side van de relatie aan. In een bidirectionele one-to-one relatie bevindt deze notatie zich in de entity die de foreign key bevat, in dit geval Mother. In een Patient record zal de ID van Mother in een kolom ingevuld worden. Op deze manier kan men Patient met Mother linken. One-to-many, many-to-one Patients kunnen verschillende Doctors hebben en Doctors hebben verschillende Patients. Wanneer een Patient entity wordt ingegeven in de database krijgt deze automatisch een ID. Opdat de gegevens van bijvoorbeeld behandelingen en onderzoeken gescheiden kunnen blijven voor andere gebruikers, hebben we geopteerd voor een mapping tussen Patient en Doctor, zijnde de entity Patient_Doctor. Deze mapping is een entity (in plaats van een automatisch gegenereerde mapping) omdat we dit kunnen zien als een soort patiëntdossier. De behandelende arts zal de mapping ID, niet de Patient ID, gebruiken om in te vullen in de forms. Mapping ID Patient ID Doctor ID ID1 Patient1 Doctor1 ID2 Patient1 Doctor2 ID3 Patient2 Doctor1 Voor Patient1 zal ID1 gebruikt worden door Doctor1 en ID2 door Doctor2. Deze relatie wordt geprogrammeerd in Patient op volgende = "ID_Patient") private List<Patient_Doctor> patient_doctors; In de entity Doctor wordt dit op soortgelijke wijze = "ID_Doctor") private List<Patient_Doctor> patient_doctors; Dit zijn One-to-many relaties omdat een Patient of Doctor meerdere mapping ID s kan hebben. Het omgekeerde geldt niet, een mapping ID kan niet gedeeld worden door meerdere Patients of Doctors. 15

26 In Patient en Doctor wordt er een List opgegeven van de verschillende mapping ID s die bij deze entiteiten horen. In de entity Patient_Doctor wordt deze relatie als volgt private Patient ID_Patient; public Patient_Doctor() { } public Patient getid_patient() { return ID_Patient; } public void setid_patient(patient ID_Patient) { this.id_patient = ID_Patient; private Doctor ID_Doctor; public Doctor getid_doctor() { return ID_Doctor; } public void setid_doctor(doctor ID_Doctor) { this.id_doctor = ID_Doctor; } Deze relaties zijn Many-to-one omdat verschillende mapping ID s gelinkt zijn aan één Patient en één Doctor. Voor de relatie tussen de verschillende forms en de mapping ID hebben we gekozen voor volgende relatie: In bijvoorbeeld de entity (en tevens form) private Patient_Doctor ID_Mapping; public Patient_Doctor getid_mapping() { return ID_Mapping; } 16

27 public void setid_mapping(patient_doctor ID_Mapping) { this.id_mapping = ID_Mapping; } In de mapping entity = "ID_Mapping") private List<Treatment> treatments; Dit is een Many-to-one relatie in treatment omdat de verschillende treatment-entiteiten telkens verbonden zijn aan één mapping ID. Wanneer een arts een formulier invult met de gegevens over de behandeling, zal dit altijd over één patient gaan, nooit meerdere. In Patient_Doctor is dit een One-to-many relatie omdat één mapping ID verbonden kan zijn aan verschillende Treatments, bijvoorbeeld gespreid over de tijd. Daarom wordt aan de mapping entity een lijst opgegeven van alle verbonden Treatments. Many-to-many De verschillende forms (Patient, Treatment, Additional screening, ) bevatten velden waar meerdere antwoordmogelijkheden mogelijk zijn. Voor elke checkbox-vraag hebben we een many-to-many relatie geprogrammeerd. Een voorbeeld is bijvoorbeeld Occupational_hazards en Mother. Wanneer men de entity Mother aanmaakt, moet men meegeven of deze behoort tot een aantal risicoberoepen. Het is bijvoorbeeld mogelijk dat een moeder zowel een kleuterleidster als een verpleegster is. Daarnaast is het mogelijk dat meerdere moeders tot de risicogroep kleuterleidster horen. Deze relatie is met andere woorden many-to-many. Bij many-to-many relaties wordt er, om het overzicht te behouden, automatisch een mapping-tabel gemaakt in de database. Deze tabel zal een oplijsting geven van bijvoorbeeld welke Occupational_hazards bij welke Mothers horen. Database Mother Mapping Database O_H Mother1 Mother1 OH1 OH1 Mother2 Mother1 OH3 OH2 Mother3 Mother2 OH1 OH3 In de entity Mother wordt deze relatie als volgt private Collection<Occupational_hazards> occupational_hazards; 17

28 public Collection getoccupational_hazards() { return occupational_hazards; } public void setoccupational_hazards(collection occupational_hazards) { this.occupational_hazards = occupational_hazards; } In de entity Occupational_hazards wordt de relatie als volgt = "occupational_hazards") private List<Mother> mothers; In de entity Mother zal een collectie Occupational_hazards opgegeven worden, in de entity Occupational_hazards wordt er per hazard een lijst bijgehouden welke Mothers verbonden zijn aan het risicoberoep Databasemap In de volgende figuur is de databasemap in zijn geheel afgebeeld. De rood gekleurde delen stellen de PDF-formulieren voor die de gebruiker invult. De automatische mappings voor de meerkeuzevragen worden voorgesteld als een veld met de notatie <Naam van de entity>_has_<naam van de meerkeuzevraag>. Dit geldt ook voor de automatische mapping tussen Patient en Mother. Voor een gedetailleerd overzicht van de entiteiten, gelieve Tabel 3 te raadplegen. De relaties tussen de delen worden aangeduid door middel van de UML (Unified Modelling Language) notatie. Het cijfer 1 staat voor de eerder besproken betekenis van One, de notatie 1 * staat voor Many. In de volgende figuur is het duidelijk dat de mapping ID van Patient_Doctor gebruikt wordt als patient ID tijdens het invullen van de PDF-formulieren. In de figuren die de relaties in meer detail bespreken zal deze waarde telkens terug te vinden zijn. 18

29 Figuur 9 Algemeen overzicht van de database 19

30 Figuur 10 Database Patient - Mother relatie Figuur 11 Database Patient - Doctor relatie 20

31 Figuur 12 Database Diagnostic Door het groot aantal variabelen in AudioFollowup en AudioIntake worden er in de volgende twee figuren niet alle variabelen in afgebeeld. Figuur 13 Database AudioFollowup 21

32 Figuur 14 Database AudioIntake Figuur 15 Database Treatment 22

33 Figuur 16 Database Additional Screening 23

34 3.3 Java Enterprise Edition Dit hoofdstuk geeft een gedetailleerde uiteenzetting van de architectuur weergegeven in Figuur Persistence tier Definiëren van tabelwaarden De persistence tier bestaat uit entiteiten. Persistence staat voor het permanent opslaan van gegevens, bijvoorbeeld in een database. De entiteiten staan in het ejb-gedeelte (Enterprise JavaBeans) van de Java EE applicatie. De entiteiten stellen de verschillende tabellen voor die in de database zullen komen (met uitzondering van de automatische mapping-tabellen). Voor elke entity zal een facade gemaakt worden op een hoger niveau (zie paragraaf voor een gedetailleerde uiteenzetting van facades). In de entiteiten wordt er bepaald welke waarden en datatypes in de tabel zullen komen. De datatypes zijn voorgeprogrammeerd door Java, maar het is mogelijk om nieuwe types te definiëren (bijvoorbeeld de entity Patient maakt een object Patient aan dat gebruikt kan worden in andere delen van de applicatie). Volgende tabel geeft een uiteenzetting van de meest gebruikte datatypes in de CMV applicatie: Naam Programmacode Domein Bits Integer int Gehele getallen 32 Long long Grote gehele getallen 64 Double double Reële getallen 64 String String Tekst Boolean boolean True/False 1 Tabel 2 Datatypes in Java Men bepaalt de datatypes telkens expliciet omdat het van belang is om zo efficiënt mogelijk geheugenruimte vrij te maken. Het datatype long geeft gehele getallen weer, maar heeft dubbel zoveel geheugenruimte nodig. Indien de ingevoerde waarden niet zo groot zijn, is het efficiënter om te opteren voor het datatype integer. Hetzelfde geldt voor het datatype double: als het ingevoerde getal geen cijfers achter de komma moet opslaan is het efficiënter om een integer te gebruiken. 24

35 Een voorbeeld van de waardedefinitie voor de entity = GenerationType.AUTO) private Long id_patient; protected String name; protected String firstname; protected String birthdate; protected int gestation; protected int birthweight; protected int birthlength; protected int headcircumference; protected String protected Mother mother;... De ID die de Patient automatisch toegewezen krijgt heet geeft aan dat deze variabele als ID zal dienen geeft aan dat deze automatisch wordt ingevuld. Private en Protected geven aan welke delen van de applicatie toegang hebben tot deze variabelen. Voor de toegang tot deze variabelen worden kleine methodes in de entity geschreven, namelijk getters (die de waarde van de variabele teruggeven) en setters (die een waarde aan de variabele toekennen). Daarnaast wordt er een constructor aangemaakt die een object van de entity zal aanmaken. Zoals vermeld kunnen entiteiten ook dienen als een variabele. Omdat Patient en Mother verbonden zijn door middel van een one-to-one relatie, is het object mother één van de variabelen. 25