Web service raamwerk voor medische advisering

Transcriptie

1 Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE Web service raamwerk voor medische advisering door Koen De Proft en Kristof Taveirne Promotoren: Prof. Dr. Ir. F. DE TURCK, Prof. Dr. J. DECRUYENAERE (UZ Gent) Scriptiebegeleider: Ir. S. VAN HOECKE Scriptie ingediend tot het behalen van de academische graad van Licentiaat in de Informatica Academiejaar

2 Voorwoord De menselijke factor van de medische informatica was voor ons de doorslaggevende factor om een thesisonderwerp in deze richting te kiezen. Het helpen van mensen is op vele vlakken een uitstekende drijfveer. Na een rondleiding op de Intensieve Zorgen van het Universitair Ziekenhuis wisten we het zeker. De motivatie was groot en de ideeën talrijk. Vooral het idee om een arts te helpen bij het maken van bepaalde beslissingen sprak ons erg aan. In deze scriptie zullen we het concept en de concretisering hiervan uit de doeken doen. We wensen in dit voorwoord Ir. Sofie Van Hoecke en Prof. Dr. Ir. Filip De Turck uitdrukkelijk te bedanken voor hun uitstekende begeleiding en advies doorheen elk stadium van dit werk. Dankwoord Kristof: Graag had ik mijn ouders bedankt voor alle steun die ze mij hebben gegeven doorheen mijn volledige opleiding. Ook mijn vriendin Jothi kan ik niet genoeg bedanken voor haar eindeloze geduld en onvoorwaardelijke steun. Verder wens ik nog mijn zus en haar zoontje Nitai te bedanken voor alle steun en leuke momentjes. Ook aan al mijn vrienden een woordje van dank voor al hun geduld en steun. En natuurlijk ook een dikke bedankt aan Koen voor de aangename en soms hilarische samenwerking. Bedankt! Dankwoord Koen: Veel dank aan mijn ouders voor de onvoorwaardelijke steun. Ook aan mijn volledige vriendenkring, in het bijzonder Laure, Ruud en Kristof. Koen De Proft en Kristof Taveirne, mei 2005

3 Toelating tot bruikleen De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie 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 scriptie. Koen De Proft en Kristof Taveirne, mei 2005

4 Web service raamwerk voor medische advisering door Koen De Proft en Kristof Taveirne Scriptie ingediend tot het behalen van de academische graad van Licentiaat in de informatica Academiejaar Promotoren: Prof. Dr. Ir. F. DE TURCK, Prof. Dr. J. DECRUYENAERE (UZ Gent) Scriptiebegeleider: Ir. S. VAN HOECKE Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE Samenvatting Binnen Intensieve Zorgen worden een aantal bedden gemonitord. Alle gegevens die hierdoor worden verzameld worden gestockeerd in een centrale databank. Deze gegevens kunnen door stukjes software worden geanalyseerd met behulp van verschillende medische algoritmes teneinde de artsen nuttige informatie te verschaffen. Deze thesis behandelt een mogelijkheid om in de communicatie te voorzien tussen de verschillende bronnen van medische informatie, de software die de algoritmes implementeren en de eindgebruikers. Trefwoorden Medische informatica, Web service, XML, Intelligent Agent

5 INHOUDSOPGAVE i Inhoudsopgave 1 Inleiding Motivatie Oplossing Het voorstel Situatieschets Indeling Technologie Inleiding Betrouwbaarheid Schaalbaarheid Service Oriented Architecture XML SOAP WSDL UDDI XML Schema Integratie J2EE Algemeen BEA WebLogic Specificatie Use cases Overzicht

6 INHOUDSOPGAVE ii Arts Labo Systeembeheerder Intelligent Agent Architectuur Inleiding XML Schema s genericmsgschema triggerschema configschema commandsschema Overzicht Communication Component Inleiding Ontwerp Interface voor clientapplicatie Interface voor systeembeheerder Interface voor Event Handler Subscription Component Ontwerp Interface voor Communication Component Interface voor systeembeheerder Interface voor Trigger Forwarder Trigger Forwarder Ontwerp Interface voor labo s Interface voor systeembeheerder Database Manager Ontwerp Interface voor systeembeheerder Interface voor Event Handler Event Handler

7 INHOUDSOPGAVE iii Interface voor agents Interface voor Trigger Forwarder Interface voor Communication Component Interface voor Subscription Component Agent Subsystem Ontwerp Interface voor Event Handler Werking van het raamwerk Inleiding Inloggen Werking Web service technisch Inschrijven Werking Web service technisch Agent aansturen Werking Web service technisch Agent stuurt bericht Werking Web service technisch Labo stuurt trigger Werking Web service technisch Agents vragen gegevens uit databank Werking Web service technisch De Clientapplicatie Inleiding Gebruiksvriendelijkheid Technologie

8 INHOUDSOPGAVE iv 6.4 De use cases De structuur van de client MVC Klassendiagram GUI Datamodel DataModelListener WebServiceControl en WebServiceCaller SecurityInformation SubscriptionConfig CommandsConfig Inloggen en Uitloggen Functionaliteit Werking Belangrijke code Beheer van berichten Functionaliteit Werking Belangrijke code Inschrijvingen Functionaliteit Werking Belangrijke code Commando s Functionaliteit Werking Belangrijke code Prestatietesten Inleiding Testopstelling Polling Reistijd

9 INHOUDSOPGAVE v 7.5 Clientapplicatie Uitbreidingen en besluit Uitbreidingen Betrouwbaarheid Beveiliging Conceptuele uitbreidingen Besluit A Installatiegids 77 A.1 Server A.1.1 Configuratie databronnen voor Entity Beans A.1.2 Configuratie voor link met IZIS A.1.3 Installatie van de componenten A.2 Client B Gebruikershandleiding 81 B.1 Client B.1.1 Berichten B.1.2 Inschrijvingen B.1.3 Commando s B.1.4 Overzicht B.2 Systeembeheer C Lijst van afkortingen 89

10 INLEIDING 1 Hoofdstuk 1 Inleiding 1.1 Motivatie Het gezondheidslandschap zal de komende decennia een sterke evolutie ondergaan. Geboortecijfers zakken en de gemiddelde levensverwachting neemt toe. Samen met de babyboom generatie zijn dit de oorzaken van een vergrijzing van de bevolking. Dit laatste wordt regelmatig naar voren geschoven als een van de belangrijkste oorzaken van de steeds toenemende medische uitgaven. Dit is echter niet altijd waar. Het grootste deel van de medische kost wordt besteed in de laatste zes maanden van een persoon zijn leven, onafhankelijk van de leeftijd waarop hij/zij sterft. Een hogere levensverwachting hangt niet altijd samen met meer ziektes. De medische vooruitgang is de hoofdoorzaak van de toenemende vraag naar kwalitatieve gezondheidszorg. Er zijn meer mogelijkheden tot het voorkomen van bepaalde ziektes, de drempel om een ziekenhuis te bezoeken is verlaagd door bv. de korte herstelperiode bij kijkoperaties. Door de technologische vooruitgang is ook de kost van allerlei ingrepen en behandelingen sterk gedaald, en wordt de drempel verlaagd om zich te laten behandelen. Kortom, er is een duidelijk verband tussen het toenemend aantal patiënten en de vooruitgang in de gezondheidszorg. ehealth is een term die gebruikt wordt om de brug aan te duiden tussen de medische en de ICT-wereld. Medische apparatuur wordt steeds gesofistikeerder door de digitale vooruitgang en steeds meer computertoepassingen worden gebruikt. Vooral op administratief vlak is de informatica goed ingeburgerd. Maar de informatisering van het ziekenhuiswezen biedt nog veel meer mogelijkheden. Medische gegevens van patiënten kunnen worden bijgehouden en artsen kunnen beroep doen op de medische gegevens om hun medische beslissing te baseren. A.H. Morris berichtte in [12] dat er in een medisch ICU-dossier meer dan 236 verschillende

11 1.2 Oplossing 2 variabele categorieën zijn. In [9] beweert A. Miller echter dat de mens slechts met een gemiddelde van 7 parameters tegelijk rekening kan houden om een beslissing te nemen. Hierdoor kunnen fouten optreden die hadden kunnen vermeden worden indien men meerdere parameters in rekening had gebracht. Gecomputeriseerde algoritmes die alle parameters in rekening brengen, en die herinneringen, alarmen of andere boodschappen zouden kunnen genereren, kunnen de artsen helpen een preciezere diagnose te stellen[10]. De geautomatiseerde medische algoritmes worden vanaf nu in deze scriptie Intelligent Agents, of kortweg agents genoemd. 1.2 Oplossing Het voorstel In deze scriptie wordt een raamwerk voorgesteld dat een dergelijk systeem van decision support aanbiedt. De voornaamste plaats waar menselijke fouten ernstige medische gevolgen kunnen hebben, is de afdeling Intensieve Zorgen van een ziekenhuis. Het raamwerk biedt de mogelijkheid geautomatiseerde decision support algoritmes te koppelen aan de medische data over de patiënten in Intensieve Zorgen. Het resultaat van de berekeningen kan dan in de vorm van een bericht naar een arts of naar een monitor naast het bed worden verstuurd. De inzetbaarheid van dit raamwerk gaat verder dan Intensieve Zorgen. Het kan eenvoudig ingezet worden op grotere schaal dankzij zijn generiek, dynamisch en schaalbaar ontwerp. De implementatie van de agents is geen onderdeel van deze scriptie. Het raamwerk is enkel bedoeld als generiek communicatiesysteem waarop agents kunnen worden ingeschakeld. Het raamwerk legt een specificatie op waaraan de agents moeten voldoen. De functionaliteit van de agents is echter volledig vrij en kan dus de meest uiteenlopende toepassingen aanbieden Situatieschets Als vertrekpunt beschouwen we de huidige informaticainfrastructuur van de Intensieve Zorgen van het Universitair Ziekenhuis te Gent. Wat belangrijk is voor het raamwerk zijn om te beginnen de verschillende informatiebronnen. Ten eerste is er de IZIS-databank. IZIS staat voor Intensieve Zorgen Informatie Systeem. Hierin worden alle gegevens van elke patiënt binnen Intensieve zorgen in opgeslagen. Zowel niet-medische gegevens zoals de naam, leeftijd, geslacht en adres van de patiënt, als de eigenlijke medische gegevens. In figuur 1.1 is IZIS afgebeeld links bovenaan. De Intelligent Agents, rechts

12 1.2 Oplossing 3 op de figuur, kunnen uit deze databank gegevens opvragen om hun algoritme uit te voeren. Niet alle gegevens komen echter onmiddellijk in deze databank terecht. Meer bepaald de informatie die de verschillende labo s genereren, arriveert met een zekere vertraging in IZIS. Maar binnen de Intensieve Zorgen is het van cruciaal belang dat nieuwe informatie zo snel mogelijk kan behandeld worden. Daarom dient er een manier te zijn om rechtstreeks data te leveren aan de agents. Zo kunnen de laboratoria rechtstreeks gegevens aan het raamwerk leveren. Dit wordt afgebeeld links op figuur 1.1. Figuur 1.1: Schets van een geïntegreerd raamwerk voor medische advisering Het resultaat van de algoritmen van de agents wordt aan de artsen medegedeeld in de vorm van een bericht. Dit bericht bestaat in verschillende types, bv. een advies in de vorm van een zuiver informatief bericht, een waarschuwing in de vorm van een alarm. Artsen ontvangen enkel de berichten waarin ze geïnteresseerd zijn, maar alle berichten over een bepaalde patiënt worden wel naar de betreffende bedmonitor gestuurd. Gelijktijdig met dit werk zijn door Diederick Hallynck en Joris Van der Mijnsbrugge twee agents ontwikkeld voor het raamwerk. Diederick heeft een RIFLE-agent ontwikkeld, die de

13 1.3 Indeling 4 nierfunctionaliteit onderzoekt. Joris heeft een Glycemieagent ontwikkeld die gebruik maakt van Grid services. Deze geeft aan de hand van de glycemiewaarde in het bloed een suggestie voor de insulinepomp van de patiënt. 1.3 Indeling Hoofdstuk 1: Inleiding Een korte uiteenzetting rond de motivatie van dit werk, en een ruwe schets van een mogelijk ontwerp. Hoofdstuk 2: Technologie In dit hoofdstuk wordt een korte introductie gegeven over de verschillende gebruikte technologieën. Hoofdstuk 3: Specificatie De vereisten van het systeem worden hier gedetailleerd besproken. Hoofdstuk 4: Architectuur In dit hoofdstuk wordt een overzicht gegeven van de verschillende componenten en de taken die zij vervullen. Ook het ontwerp van de componenten wordt hier behandeld. De XMLSchema s die de componenten gebruiken worden hier ook besproken. Hoofdstuk 5: Werking van het raamwerk Na een overzicht van alle componenten en de gebruikte schema s wordt in dit hoofdstuk uitgelegd hoe de verschillende componenten samengesteld worden om in de eigenlijke functionaliteit te voorzien. Hoofdstuk 6: De clientapplicatie Hier wordt een overzicht van de client applicatie gegeven, samen met wat uitleg over zijn interne werking en functionaliteiten. Hoofdstuk 7: Prestatietesten Resultaten omtrent de snelheid en belasting van de componenten wordt hier weergegeven. Hoofdstuk 8: Besluit en uitbreidingen Het boek wordt afgesloten met een besluitvorming en reeks ideeën voor eventuele uitbreiding en aanpassingen van het raamwerk die zouden kunnen doorgevoerd worden.

14 1.3 Indeling 5 Appendix A: Installatiegids Hoe je het raamwerk kunt installeren en operationeel krijgen kunt U hier lezen. Bibliografie

15 TECHNOLOGIE 6 Hoofdstuk 2 Technologie 2.1 Inleiding Om een bruikbaar raamwerk voor medische advisering te construeren, moeten een aantal belangrijke aspecten in rekening worden gebracht. Zo is het uitermate belangrijk dat het systeem betrouwbaar en schaalbaar is Betrouwbaarheid Met betrouwbaarheid wordt bedoeld dat het systeem op elk moment correct dient te werken en in het bijzonder dat er geen berichten verloren mogen gaan. Het is onaanvaardbaar dat een arts een alarmerend bericht niet aankrijgt, omdat het systeem faalt. Een single point of failure moet absoluut vermeden worden om een betrouwbaar systeem te bekomen. Het systeem dient dus opgesplitst te worden in verschillende functionele componenten. Om de betrouwbaarheid te optimaliseren kunnen deze componenten dynamisch aan elkaar worden gekoppeld. Op deze manier is het eenvoudig om de ene component te vervangen door een andere implementatie of door een tweede installatie van diezelfde component. In het geval van een defect bij de ene component kan een andere instantie ervan dynamisch en eenvoudig de functionaliteit overnemen Schaalbaarheid Naast betrouwbaarheid is ook schaalbaarheid een belangrijk aspect. De omgeving waarin een raamwerk voor medische advisering kan draaien verschilt van ziekenhuis tot ziekenhuis. Het systeem wordt ontwikkeld voor de afdeling Intensieve Zorgen maar het kan zijn dat men het

16 2.2 Service Oriented Architecture 7 later wil gaan toepassen in het volledige ziekenhuis. Het aantal eindgebruikers kan in grote mate veranderen op lange termijn indien de omgeving van het raamwerk verandert. Maar ook op korte termijn is een drastische verandering in het aantal gebruikers mogelijk, bij een ramp bijvoorbeeld. Het systeem moet dan op een eenvoudige en flexibele manier kunnen uitgebreid worden zodat het de extra werklast snel kan opvangen. Al deze eigenschappen en meer worden ondersteund door een service georiënteerde architectuur. 2.2 Service Oriented Architecture Figuur 2.1: Het SOA model In een service georiënteerde architectuur zijn alle componenten geïmplementeerd als services. Elk van deze services zijn onafhankelijke bouwstenen die samen de volledige applicatie vormen. Elke service werkt volledig autonoom en onafhankelijk van andere services en is daardoor slechts verantwoordelijk voor zijn eigen functionaliteit. De verschillende services zijn losjes aan elkaar gekoppeld via een afgesproken interface. Ze communiceren met elkaar via een internet protocol, meestal HTTP en ze sturen berichten naar elkaar in de vorm van XML-documenten. Het SOA model wordt weergegeven in figuur 2.1. Indien twee componenten met elkaar wensen te communiceren wordt de ene de service requester genoemd, en de andere de service provider. De laatste biedt een dienst aan die de andere wenst te gebruiken. Een service provider publiceert zijn dienst eerst aan een zogenaamde service broker. De service requester kan dan

17 2.2 Service Oriented Architecture 8 van deze broker gebruik maken om de service provider te lokaliseren. Als Web services worden gebruikt om deze manier van communiceren te ondersteunen, dan spreken we van een Webgebaseerde implementatie van een SOA. Voor het transporteren van de XML-documenten wordt in dit geval gebruik gemaakt van SOAP over HTTP. Een service beschrijving wordt gegeven door middel van een WSDL-document. Dit WSDL-document is wat gelokaliseerd wordt door de service broker met behulp van UDDI XML XML is een standaard voor de representatie van gestructureerde gegevens in de vorm van platte tekst. Deze representatie is leesbaar voor machine en mens, en leent zich uitstekend om gegevens op eenduidige manier uit te wisselen tussen verschillende platformen, zoals bijvoorbeeld J2EE en.net SOAP SOAP staat voor Simple Object Access Protocol. SOAP is het protocol bij uitstek om een XML-document te transporteren van de service requester naar de Web service in kwestie. De aanvragen en antwoorden worden verstuurd als SOAP-berichten over het HTTP-protocol om volledige interoperabiliteit te garanderen. Zo zijn de locatie en het onderliggend platform van de services niet meer van belang WSDL WSDL staat voor Web Services Description Language. Web services kunnen met behulp van WSDL worden beschreven. Deze beschrijving kan gebruikt worden door de requester van de service om zogenaamde proxies te genereren. Dit zijn stukjes code die instaan voor de communicatie tussen de aanvrager en de aanbieder. Ze abstraheren de complexiteit van de communicatie en zorgen voor handige datatypes die kunnen gebruikt worden door de aanvrager UDDI UDDI betekent Universal Description Discovery and Integration. UDDI is een mechanisme om Web service beschrijvingen te lokaliseren. Er wordt gebruik gemaakt van een centrale directory waar de beschrijvingen aan de hand van WSDL-documenten worden verzameld. In het raamwerk

18 2.3 J2EE 9 zouden Intelligent Agents van een UDDI-register bijvoorbeeld kunnen gebruik maken om mee te delen waar ze zich bevinden XML Schema In een XML Schema wordt de structuur van een XML-document vastgelegd. Zo kunnen we de uitwisseling van XML-documenten binnen het raamwerk en tussen het raamwerk en de verschillende eindgebruikers eenduidig vastleggen Integratie Bij het installeren van een service georiënteerde architectuur in een bestaande informaticaomgeving kunnen problemen optreden. De omgeving in Intensieve Zorgen is niet Web servicegebaseerd. Er moeten dus enkele aanpassingen worden gemaakt aan de rand van het raamwerk. Een eerste probleem is het aanleveren van data aan het raamwerk. Omdat dit een testproject is, kan aan de infrastructuur van de omgeving niets veranderd worden. Een oplossing hiervoor wordt besproken in Een tweede integratieprobleem ligt bij het gebruik van reeds bestaande implementaties van bepaalde algoritmes. Deze stukken software moeten worden omgebouwd tot een Intelligent Agent, die kan ingezet worden in het systeem. Dit kan eenvoudig door een Web service laag rond de bestaande code te bouwen die aan een bepaalde interface voldoet (zie 4.9 en [4]). 2.3 J2EE Algemeen J2EE staat voor Java 2 Platform, Enterprise Edition. Het J2EE platform biedt een meerlagig gedistribueerd applicatiemodel aan (zie figuur 2.2). Naast de goede integratie en ondersteuning van Web services kan men de businesslogica implementeren met behulp van Enterprise Java Beans (EJB). De twee soorten EJB s die wij in ons raamwerk gebruiken zijn de volgende Session Beans: Deze EJB s kunnen een taak uitvoeren voor een client. Ze kunnen de implementatie ondersteunen van Web services. Entity Beans: Deze EJB s kunnen gebruikt worden om data persistent te maken. Een Entity Bean wordt gelinkt aan een tabel van een onderliggende databank met behulp van

19 2.3 J2EE 10 Container-Managed Persistence (CMP). CMP is een manier om de ontwikkelde Entity Beans onafhankelijk te maken van de onderliggende databank. De integriteit van de onderliggende data van het raamwerk is van kritisch belang voor een correcte werking. De gegevens moeten accuraat en betrouwbaar zijn op elk moment. J2EE gaat transactioneel met data om. Het regelt de gelijktijdige toegang van verschillende componenten tot data en zorgt ervoor dat in het geval van een exception de data hersteld wordt in een consistente toestand.[14] Figuur 2.2: De verschillende lagen van een J2EE applicatie BEA WebLogic WebLogic van BEA is het J2EE platform dat gebruikt werd voor de ontwikkeling van het raamwerk. De WebLogic Workshop is een geïntegreerde ontwikkelingsomgeving met een intuïtief programmeermodel dat de ontwikkelaar toelaat zich te concentreren op de logica in plaats van op de complexe onderliggende implementatiedetails. Het platform ondersteunt alle aspecten die nodig zijn voor het raamwerk en dit zonder volledig afgeschermd te worden van de onderliggende technologie. De Workshop maakt gebruik van zogenaamde Java Controls om de gebruiker van de business logica af te schermen van de implementatiedetails via een bepaalde interface. Het gebruik en de mogelijkheden van BEA WebLogic wordt later verder toegelicht.

20 SPECIFICATIE 11 Hoofdstuk 3 Specificatie Aan de hand van use cases en sequentiediagrammen worden in dit hoofdstuk de vereisten van het systeem beschreven. Dit gebeurt vanuit het perspectief van de eindgebruikers, zijnde de artsen en de systeembeheerder, de labo s en de Intelligent Agents. 3.1 Use cases Overzicht In dit overzicht staan de meest algemene use cases voorgesteld. Een arts beheert de diensten voor zijn patiënten, een labo levert nieuwe gegevens aan het raamwerk, de systeembeheerder beheert het raamwerk, en een Intelligent Agent stuurt een bericht Arts Algemeen Om het systeem te kunnen gebruiken, moet een arts zich eerst aanmelden. Hierbij hoort ook het corresponderende afmelden op het einde van een gebruikerssessie. Het eigenlijke gebruiken van het systeem komt neer op drie use cases: beheer inschrijvingen, agent aansturen, en ontvangen berichten bekijken. Een arts kan zich inschrijven op een patiënt voor een Intelligent Agent, zodat de berichten voor die patiënt hem/haar zullen meegedeeld worden. Het is mogelijk dat een arts een Intelligent Agent aanstuurt, en als laatste en belangrijkste use case is er het bekijken van de ontvangen berichten.

21 3.1 Use cases 12 Figuur 3.1: Overzicht use cases Beheer inschrijvingen De arts beheert via de clientapplicatie zijn inschrijvingen. Dit behelst taken zoals een nieuwe inschrijving voor een patiënt en agent aanmaken en een bestaande inschrijving verwijderen. Precondities: de gebruiker heeft zich succesvol aangemeld op het systeem Postcondities: de gebruiker ontvangt de berichten geassocieerd met zijn/haar inschrijvingen Agent aansturen Met commando s kan een arts via de clientapplicatie een agent aansturen. Zo kan een arts zelf gegevens leveren aan een agent, de status van een dienst voor een bepaalde patiënt opvragen, of andere mogelijke commando s op de agent uitvoeren. Deze functies worden door de agent zelf aangeboden. Precondities: de gebruiker heeft zich succesvol aangemeld op het systeem

22 3.1 Use cases 13 Figuur 3.2: Dienstbeheer use case diagram Ontvangen berichten bekijken Het behandelen van de ontvangen berichten gebeurt ook via de clientapplicatie. Dit is simpelweg het notie nemen van het bericht, en eventueel de gepaste medische acties ondernemen Labo Een labo is elke instantie die nieuwe medische gegevens over een patiënt aan het raamwerk kan leveren. De gegevens dat een labo stuurt zijn bestemd voor één of meerdere agents. Deze data wordt verstuurd onder de vorm van triggers. Een labo heeft maar één use case: nieuwe gegevens leveren Systeembeheerder De systeembeheerder beheert het raamwerk met behulp van een administratiewebsite. Configuratie IA s De configuratie van de Intelligent Agents is een belangrijke taak van de systeembeheerder. Het raamwerk gebruikt een externe databank die moet ingeplugd worden op het systeem. Als een

23 3.1 Use cases 14 Figuur 3.3: Labo use case Figuur 3.4: Systeembeheer use case diagram agent bepaalde gegevens nodig heeft uit de databank, moeten er query s gedefinieerd worden om die data op te kunnen vragen. Configuratie labo s De informatie die van het labo komt moet compatibel zijn met het gewenste formaat. Voor elk type labo zal een adapter geschreven moeten worden, om de gegevens te transformeren naar een intern generiek formaat Intelligent Agent Om het algoritme uit te voeren, heeft een Intelligent Agent medische gegevens nodig. Een agent kan dankzij het PUSH/PULL-model die gegevens op twee manieren verkrijgen. Dit paradigma veronderstelt dat het mogelijk is gegevens aan een instantie te leveren (PUSH), alsook dat deze instantie de data zelf kan opvragen (PULL). De triggers die vanuit de labo s aankomen, stellen de PUSH-methode voor, en het opvragen van medische gegevens uit de databank is het PULLsysteem. Wanneer het algoritme voltooid is, wordt eventueel een bericht gestuurd.

24 3.1 Use cases 15 Figuur 3.5: Intelligent Agent use case diagram

25 ARCHITECTUUR 16 Hoofdstuk 4 Architectuur 4.1 Inleiding Bij het opstellen van de architectuur zijn een aantal objectieven vooropgesteld. De schaalbaarheid, uitbreidbaarheid en betrouwbaarheid van het systeem moest gemaximaliseerd worden. Daarom is er gekozen voor een componentgebaseerde aanpak. Het raamwerk is samengesteld uit een reeks van componenten, die een Web service op zichzelf zijn. Elke component is verantwoordelijk voor een elementair en essentieel onderdeel van de werking van het systeem. Omwille van het Web service karakter is de platformkeuze voor de componenten tussen Java Enterprise en Microsoft.NET arbitrair. Reeds bij het begin van het ontwerp van de architectuur werden de XML Schema s vastgelegd. Deze bepalen eenduidig de vorm waarin de XML-berichten door het raamwerk reizen. Na de bespreking van deze Schema s volgt de componentgebaseerde architectuur. 4.2 XML Schema s Hier worden de XML Schema s besproken die voor het raamwerk ontworpen zijn. De belangrijkste hieronder zijn het Schema voor de berichten, en dat voor de triggers. Daarnaast is er nog een voor de configuratie van de inschrijvingen, en voor de commando s genericmsgschema Het generieke berichtformaat wordt vastgelegd door dit Schema. Het formaat is opgedeeld in drie delen. Een identificatiestuk met tekstuele uitleg, om de patiënt en agent te specifiëren, en

26 4.2 XML Schema s 17 een beschrijving van het bericht te geven. Die beschrijving kan een tekstueel advies bevatten. Het tweede deel maakt het mogelijk om een grafiek mee te sturen. Alleen een lijngrafiek is momenteel mogelijk, maar dit is simpel uit te breiden naar andere soorten grafieken. Om de lijngrafiek te specifiëren, moet men een een lijst van coördinaten ingeven. Hier volgt een listing van het volledige Schema: <?xml version="1.0"?> <xs:schema xmlns:xs=" xmlns:tns=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="genericmsg"> <xs:complextype> <xs:sequence> <xs:element name="message" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="patientid" type="xs:string"/> <xs:element name="agenttype" type="xs:string"/> <xs:element name="message" type="xs:string"/> <xs:element name="description" type="xs:string"/> <xs:element name="linegraph" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="title" type="xs:string"/> <xs:element name="color"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:pattern value="#[a-fa-f0-9]{6}"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="scale"> <xs:complextype> <xs:attribute name="xmin" type="xs:string"/> <xs:attribute name="xmax" type="xs:string"/> <xs:attribute name="ymin" type="xs:string"/> <xs:attribute name="ymax" type="xs:string"/> </xs:complextype> </xs:element> <xs:element name="axisnames"> <xs:complextype> <xs:attribute name="x" type="xs:string"/> <xs:attribute name="y" type="xs:string"/>

27 4.2 XML Schema s 18 </xs:complextype> </xs:element> <xs:element name="pointlist"> <xs:complextype> <xs:sequence> <xs:element name="point" maxoccurs="unbounded"> <xs:complextype> <xs:attribute name="x" type="xs:decimal"/> <xs:attribute name="y" type="xs:decimal"/> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <!-- END LINEGRAPH --> <xs:element name="table" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="title" type="xs:string"/> <xs:element name="columnnames"> <xs:complextype> <xs:sequence> <xs:element name="column" maxoccurs="unbounded"> <xs:complextype> <xs:attribute name="name" type="xs:string"/> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="row" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="item" maxoccurs="unbounded"> <xs:complextype> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="columnname" type="xs:string"/> </xs:extension> </xs:simplecontent> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="rownumber" type="xs:integer"/>

28 4.2 XML Schema s 19 </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <!-- END TABLE--> </xs:sequence> <xs:attribute name="messagetype" use="required"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="info"/> <xs:enumeration value="alarm"/> </xs:restriction> </xs:simpletype> </xs:attribute> <xs:attribute name="datetime" type="xs:datetime" use="required"/> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> triggerschema In het triggerformaat bestaan er drie luiken. Het eerste bevat informatie over de geassocieerde arts, het tweede bevat de patiëntinformatie, en het derde de informatie over het monster. Hier volgt een listing van het volledige Schema: <?xml version="1.0"?> <xs:schema xmlns:xs=" xmlns:tns=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="triggers"> <xs:complextype> <xs:sequence> <xs:element name="trigger" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="ordernr" type="xs:string"/> <xs:element name="arts"> <xs:complextype> <xs:sequence>

29 4.2 XML Schema s 20 <xs:element name="rizivnr" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="patient"> <xs:complextype> <xs:sequence> <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> <xs:element name="patientid" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="monster"> <xs:complextype> <xs:sequence> <xs:element name="afkorting" type="xs:string"/> <xs:element name="referentiewaarden" type="xs:string"/> <xs:element name="eenheid" type="xs:string"/> <xs:element name="waarde" type="xs:string"/> <xs:element name="afnametijd" type="xs:date"/> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> configschema Het Schema voor de configuratie van de inschrijvingen bestaat ook uit drie delen. Een lijst van alle patiënten, een lijst van alle agents, en een lijst van de huidige patiënten van de arts met hun geactiveerde agents. De eerste twee zijn er om te weten welke patiënten en welke agents er aanwezig zijn. De derde lijst is de eigenlijke lijst van inschrijvingen. Hier volgt een listing van het volledige Schema: <?xml version="1.0"?> <xs:schema xmlns:xs=" xmlns:tns=" targetnamespace="

30 4.2 XML Schema s 21 elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="config"> <xs:complextype> <xs:sequence> <xs:element name="patientlist"> <xs:complextype> <xs:sequence> <xs:element name="patient" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:element name="patientid" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="agentlist"> <xs:complextype> <xs:sequence> <xs:element name="agenttype" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="agent" type="xs:string"/> </xs:sequence> <xs:attribute name="default" type="xs:boolean"/> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="mypatients"> <xs:complextype> <xs:sequence> <xs:element name="patient" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:element name="patientid" type="xs:string"/> <xs:element name="agents"> <xs:complextype> <xs:sequence> <xs:element name="agent" type="xs:string" maxoccurs="unbounded"/>

31 4.2 XML Schema s 22 </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> commandsschema Dit Schema beschrijft de vorm van het XML-formaat waarmee de agent zijn commando s kenbaar maakt. Hier volgt een listing van het volledige Schema: <?xml version="1.0"?> <xs:schema xmlns:xs=" xmlns:tns=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="commanddescriptions"> <xs:complextype> <xs:sequence> <xs:element name="command" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:element name="parameter" type="xs:string" maxoccurs="unbounded"/> <xs:element name="description" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="agent" type="xs:string"/> </xs:complextype> </xs:element> </xs:schema>

32 4.3 Overzicht Overzicht Hier volgt een overzicht van de componenten met een eerste woordje uitleg (zie 4.1). Communication Component (CC) De Communication Component verzorgt de communicatie tussen de verschillende PDA s, bedden en het raamwerk. De artsen kunnen via een applicatie op hun PDA de inschrijvingen beheren. Er wordt een databank bijgehouden die alle berichten opslaat. Subscription Component (SC) De Subscription Component ontvangt van de Communication Component de aanvragen voor nieuwe inschrijvingen en beheert deze met behulp van een databank. Trigger Forwarder (TF) Ontvangt de triggers van de labo s en zet ze om naar een intern generiek triggerformaat via adapters, die de systeembeheerder configureert. Dan stuurt hij ze door naar de Agents via de Event Handler. Database Manager (DBM) De Database Manager is de component die in contact staat met de externe databank, die de gegevens over de patiënten bevat. De DBM biedt één enkele interface aan voor de agents naar de databank toe. De DBM is verantwoordelijk voor het uitvoeren van de verschillende query s die de agents hun gewenste data leveren. Event Handler (EH) De Event Handler staat in voor de communicatie tussen de agents en de rest van het framework. Enerzijds biedt deze de agents één interface aan om te communiceren met het raamwerk en anderzijds worden de agents geabstraheerd tot één interface, wat de complexiteit voor de andere componenten verbergt. Agent Subsystem Hiermee wordt de Agent Manager Coördinator en de bijbehorende Agent Managers bedoeld. Dit onderdeel vormt een platform waarop de agents kunnen ingeplugd worden. Het zorgt voor

33 4.3 Overzicht 24 Figuur 4.1: Overzicht architectuur

34 4.4 Communication Component 25 de localisatie van de agents op de verschillende machines. Dit deel is geïmplementeerd in.net door Diederick Hallynck. 4.4 Communication Component Inleiding De Communication Component moet in eerste instantie de logingegevens beheren. Als hoofdtaak heeft deze component het bezorgen van de berichten aan de bedden van de patiënten en aan de artsen. Dit gebeurt door ze op te slaan, en de client applicaties op regelmatige tijdsstippen om hun berichten te laten vragen (polling). De Communication Component delegeert ook alle andere taken van de artsen zoals het beheer van de inschrijvingen en het uitvoeren van commando s Ontwerp Aangezien Web services op zich geen toestand bijhouden, wordt de logininformatie van een arts opgeslagen in een Entity Bean. Conversational Web services kunnen wel een toestand bijhouden en zouden dit probleem eleganter kunnen oplossen, maar dit heeft callbacks naar de PDA nodig, en dit is bij deze PDA-implementatie niet mogelijk. De clientapplicatie van een arts vraagt periodiek - typisch om de 30 seconden - om de berichten die voor de arts bestemd zijn. Alle berichten worden in Entity Beans opgeslagen, samen met de datum waarop ze in de CC aangekomen zijn. Zo kan de CC gemakkelijk de berichten opvragen die sinds de laatste poll aangekomen zijn. Een bericht kan meerdere bestemmingen hebben, dus om redundantie te vermijden, worden de berichten met een Entity Bean gemodelleerd, en de bestemmingen met een andere. Deze twee zijn aan elkaar gekoppeld via primaire en vreemde sleutels. Dit wordt afgehandeld door een Java Control, die een interface aanbiedt met methodes om berichten toe te voegen en op te vragen. Het geheel dat de opslag van de berichten omvat, heet de Message Store. De interface van de Communication Component wordt geïmplementeerd door een Java Control. Hierop is een Web service laag gebouwd, die de foutafhandeling voor zich neemt Interface voor clientapplicatie Voor de clientapplicatie zijn de volgende functies beschikbaar:

35 4.4 Communication Component 26 Figuur 4.2: Communication Component login De aanmeldingsprocedure, waar een arts een gebruikersnaam en paswoord meegeeft. logout De afmeldingsprocedure, ook met gebruikersnaam en paswoord. newsubscription Deze methode schrijft de arts voor de gegeven patiënt en gegeven agent in. Na deze actie ontvangt de arts alle berichten van de agent bestemd voor de patiënt. Als deze agent nog niet actief is voor deze patiënt, wordt deze opgestart (zie 4.5). deletesubscription Met deze functie kan de arts zich uitschrijven voor een agent die voor een patiënt loopt. stopagent Hiermee stopt de arts de opgegeven agent voor de opgegeven patiënt. Dit betekent dat naast zijn/haar eigen inschrijving, ook alle inschrijvingen van andere artsen verdwijnen. Deze functie is er voor de volledigheid, want ze zal zelden gebruikt worden, omdat de meeste agents waarschijnlijk zullen lopen tot de betrokken patiënt uit Intensieve Zorgen ontslagen wordt. Als dit gebeurt, worden de agents automatisch gestopt.

36 4.4 Communication Component 27 getconfig De arts kan met deze functie zijn/haar huidige configuratie van inschrijvingen opvragen. Hier worden ook lijsten van alle patiënten en agents ingesloten. getpatientconfig Deze methode is er om een arts de agents die voor een gegeven patiënt lopen, op te laten vragen. getcommands Als een arts wil weten welke commando s er mogelijk zijn op een bepaalde agent, roept zijn clientapplicatie deze functie aan met de agent in kwestie als argument. Een lijst van de functies met de argumenten wordt teruggeven. executecommand Deze functie stuurt het opgegeven commando naar de opgegeven agent. resultaat terug in de vorm van een bericht. De agent geeft het poll Dit is de functie die de clientapplicatie op periodieke tijdstippen aanroept. In het antwoord zitten alle berichten die sinds de vorige keer dat de clientapplicatie erom vroeg, aangekomen zijn Interface voor systeembeheerder newuser Deze methode dient om een nieuwe gebruiker (arts) aan te maken. Gebruikersnaam en paswoord worden meegegeven. deleteuser De corresponderende oproep om een gebruiker te verwijderen.

37 4.5 Subscription Component 28 getallusers Deze functie geeft een lijst van al de artsen terug. Dit wordt gebruikt door de administratiesite om een overzicht van de gebruikers te geven voor de beheerder Interface voor Event Handler sendmessage De Event Handler stuurt de berichten komende van de agents door naar de Communication Component via deze methode, waarna ze worden opgeslagen. 4.5 Subscription Component Ontwerp Om de informatie over de inschrijvingen bij te houden, worden Entity Beans gebruikt. Om te beginnen één voor de patiëntinformatie en één voor de agentinformatie. De patiëntinformatie bestaat uit het ID uit IZIS, een naam en het bed waarin hij/zij zich bevindt. De agentinformatie is gewoon een naam en een veld dat bepaalt of de agent standaard is of niet. Een standaardagent is een agent die standaard voor elke patiënt moet lopen. Er bestaan twee soorten inschrijvingen, die elk door een Entity Bean zijn voorgesteld. De ene is een combinatie tussen patiënten en agents, de andere een combinatie tussen patiënten, agents en artsen. De patiënt-agent Bean houdt voor een patiënt de geactiveerde agents bij. De patiënt-agent-arts Bean stelt de inschrijvingen van een arts voor een patiënt-agent combinatie voor. Deze Entity Beans worden consistent gehouden door een gemeenschappelijke interface via een Java Control. Zoals bij de Communication Component is hierop een Web service laag met foutafhandeling gebouwd. De SC heeft ook nog als taak initialisatiesignalen te versturen. Dit gebeurt wanneer een agent voor een patiënt geactiveerd wordt door een arts en wanneer de standaard agents opgestart moeten worden voor een nieuwe patiënt Interface voor Communication Component newsubscription Eerst wordt gecontroleerd of de patiënt-agent Bean voor de gegeven patiënt en agent al bestaat. Als dat niet zo is, wordt deze eerst aangemaakt en wordt er een initialisatiesignaal gestuurd naar

38 4.5 Subscription Component 29 de agent via de Event Handler. Daarna wordt een nieuwe patiënt-agent-arts Bean aangemaakt. deletesubscription Met de gegeven patiënt, agent en arts, wordt de patiënt-agent-arts Bean opgezocht en verwijderd. stopagent De patiënt-agent Bean wordt opgezocht en verwijderd, alsook alle patiënt-agent-arts Beans die bestaan voor deze patiënt en agent. Daarna wordt via de Event Handler een stopsignaal gestuurd naar de agent. getconfig Aan de hand van een XML Schema wordt het configuratiedocument opgesteld. De lijsten met alle patiënten en agents en de lijst van inschrijvingen worden opgezocht in de corresponderende Beans. getpatientconfig Met hetzelfde XML Schema wordt alleen de lijst van inschrijvingen ingevuld met de agents die actief zijn voor de betrokken patiënt. getdestinations De Communication Component roept deze functie op om te weten te komen welke de bestemmingen zijn voor een bericht. De argumenten zijn patiënt en agent Interface voor systeembeheerder createagent Een simpele functie om een agent te registreren in het raamwerk. Er moet worden opgegeven of de agent standaard is of niet. removeagent Corresponderende functie om een agent uit het raamwerk te halen.

39 4.6 Trigger Forwarder 30 createbed Registreert een bed in het raamwerk. deletebed Verwijdert een bed. newpatient Hiermee registreert men een nieuwe patient met ID, naam en bed. Deze functie is ook beschikbaar voor IZIS. Er is een databanktrigger gedefinieerd op IZIS die deze functie aanroept wanneer er een nieuwe patiënt in de databank verschijnt. removepatient Haalt een patiënt uit het systeem. Ook IZIS gebruikt deze nadat een patiënt uit de databank verdween Interface voor Trigger Forwarder getagenttypes De Trigger Forwarder kan hiermee voor een gegeven patiënt de agents ophalen die hiervoor lopen. De TF heeft dit nodig om te bepalen naar welke agents hij de triggers moet doorsturen (zie 4.6). 4.6 Trigger Forwarder Ontwerp De triggers die de Trigger Forwarder aankrijgt van de labo s zijn gewone tekstbestanden. Idealiter zouden deze triggers al in een XML-formaat bestaan, bijvoorbeeld Kmehr-Bis (Kind Messages for Electronic Healthcare Records - Belgian Implementation Standard [8]). Wanneer de triggers binnenkomen, zal er dus eerst een transformatie moeten gebeuren naar het interne XML-formaat. Dit is het werk van de adapters. Voor een labo met een specifiek type triggerformaat kan een adapter worden geconfigureerd. Deze zijn geïmplementeerd als een simpele Web service. In de Trigger-Agent Mapping Entity Bean is geregistreerd in welk type trigger de

40 4.6 Trigger Forwarder 31 Figuur 4.3: Subscription Component agents geïnteresseerd zijn. Als de RIFLE-agents de triggers over het creatininegehalte in het bloed willen aankrijgen, is er een mapping RIFLE/creatinine aanwezig. Aan de hand van het ID van de patiënt, vraagt de Trigger Forwarder aan de Subscription Component welke agents er lopen voor die patiënt. Tot slot stuurt de TF de trigger samen met deze informatie door naar de Event Handler. De Trigger-Agent mapping wordt aangevuld door de systeembeheerder bij het inschakelen van een nieuw soort agent. Figuur 4.4: Trigger Forwarder

41 4.7 Database Manager Interface voor labo s trigger De labo s worden deze functie aangeboden om hun triggers te versturen. Als argument wordt een XML-document meegegeven dat voldoet aan het XML Schema dat de vorm van de triggers bepaalt. labotrigger Als de labo s een tekstformaat gebruiken voor hun triggers, moeten ze deze functie gebruiken. Deze zal de juiste adapter Web service aanroepen om de het tekstformaat te transformeren naar het intern XML-formaat Interface voor systeembeheerder addtriggeragentmapping Dit is de functie waarmee de systeembeheerder de Trigger-Agent Mapping aanvult met de informatie van het nieuwe agenttype. gettriggerconfig De administratiesite gebruikt deze functie om een lijst op te vragen van de Trigger-Agent Mapping, zodat de systeembeheerder een overzicht heeft en wijzigingen kan aanbrengen. 4.7 Database Manager Ontwerp De externe databank die de gegevens van de patiënten bevat, is in Intensieve Zorgen van UZGent de IZIS-databank (Intensieve Zorgen Informatie Systeem). Om de agent gegevens te laten opvragen, worden er specifieke query s gedefinieerd. Dit is een taak van de systeembeheerder. Hij/zij zal een query vastleggen met een aantal parameters, in te vullen door de aanroepende agent. De systeembeheerder stelt de query op aan de hand van een beschrijving van de gewenste data. Zo dient de agentontwikkelaar niet op de hoogte te zijn van de structuur van de databank. Deze query kan dan uitgevoerd worden door de functie requestvalue met de key van de query en de nodige parameters aan te roepen. Deze key wordt gemapt op de query, en de parameters

42 4.7 Database Manager 33 worden ingevuld. Dit systeem laat toe dat de agents op een gecontroleerde manier gegevens opvragen. De link naar IZIS wordt onderhouden door het onderliggende J2EE-platform. De Database Manager maakt enkel gebruik van een DataSource die door de J2EE Application Server wordt gemapt op een Connection Pool. Het is deze laatste die de fysische link met de IZIS-databank onderhoudt. Door enkel de instellingen op de Connection Pool te wijzigen en de DataSource onveranderd te laten wordt de flexibiliteit met betrekking tot het gebruik van de databank bevorderd. Er kan gemakkelijk overgeschakeld worden op een andere databank zonder dat hier ook maar iets voor moet aangepast worden in het raamwerk. Enkel wat configuratie van de Application Server is vereist. Op IZIS zijn een aantal databanktriggers gedefinieerd, die het raamwerk op de hoogte houden van de gegevens van de patiënten. Als er een nieuwe patiënt in IZIS wordt ingevoerd, wordt dit samen met zijn naam en het bed waarin hij/zij ligt, gemeld aan de Subscription Component. Initialisatiesignalen voor de standaard agents worden verstuurd. Er is ook een trigger gedefinieerd voor een patiënt die uit IZIS verdwijnt, met de corresponderende gevolgen. Als het nodig is, kunnen er op latere datum nog triggers gedefinieerd worden. Figuur 4.5: Database Manager

43 4.8 Event Handler Interface voor systeembeheerder newmapping De systeembeheerder geeft een aantal argumenten mee, om de query te specifiëren. Ten eerste een key, om de query te kunnen identificeren. De string die na SELECT komt, is het tweede argument. Dan komen nog FROM, WHERE, en een beschrijving Interface voor Event Handler requestvalue Met de key van de query en een rij van parameters als argumenten, kan de agent de query uit laten voeren. De resultaatset wordt als een HashMap teruggegeven. 4.8 Event Handler De Event Handler handelt de communicatie tussen het raamwerk en de agents af. Er wordt één interface aangeboden aan zowel het raamwerk als de agents. Dit betekent dat de agents voor aanvragen voor gegevens uit IZIS en voor het versturen van berichten bij deze component moeten aankloppen. Zo verlopen ook de triggers en andere aanroepen voor de agents langs deze weg. Een simpele communicatiecomponent als de Event Handler heeft geen toestand, en dus geen EJB-laag Interface voor agents sendmessage De berichten worden doorgegeven aan de Communication Component. requestvalue De aanvragen voor gegevens uit de databank worden doorgesluisd naar de Database Manager Interface voor Trigger Forwarder trigger Samen met agenttype en patiënt-id kan de Trigger Forwarder zijn triggers via deze functie doorsturen naar de agents.

44 4.9 Agent Subsystem Interface voor Communication Component getcommands De aanvragen voor de mogelijke commando s op een agent worden doorgegeven aan de agent in kwestie. executecommand De commando s worden doorgestuurd naar het Agent Subsystem Interface voor Subscription Component initagent De initialisatiesignalen voor een agent worden doorgestuurd naar het Agent Subsystem. stopagent De stopsignalen voor een agent worden doorgestuurd naar het Agent Subsystem. 4.9 Agent Subsystem Ontwerp Het Agent Subsystem bestaat uit de Agent Manager Coordinator (AMC) en een aantal Agent Managers, één per machine. Er kan een willekeurig aantal machines in gebruik genomen worden, afhankelijk van de noden van de agents. De keuze voor de spreiding van de agents over de machines is volledig arbitrair en zal geregistreerd worden in de AMC. Er kunnen bijvoorbeeld vijf glycemie-agents en één RIFLE-agent op machine 1 draaien, en drie RIFLE-agents op machine 2. De Agent Manager Coordinator is verantwoordelijk voor de spreiding van de werklast voor de machines. In deze implementatie gebruikt de AMC hiervoor het load balancing algoritme Round Robin. De Agent Manager stuurt het verkeer door naar de juiste agent op zijn machine Interface voor Event Handler init De Agent Manager Coordinator kiest aan de hand van zijn load balancing algoritme een machine. De Agent Manager van die machine zorgt dat een agent wordt geïnitialiseerd.

45 4.9 Agent Subsystem 36 trigger De Agent Manager Coordinator weet na de initialisatie op welke machine deze agent voor deze patiënt draait, en routeert de triggers naar de juiste machine. executecommand De Agent Manager Coordinator routeert het commando naar de juiste Agent Manager, die de juiste agent contacteert. getcommands De Agent Manager Coordinator stuurt deze vraag aan de hand van zijn load balancing algoritme door naar een agent van het gegeven type.

46 WERKING VAN HET RAAMWERK 37 Hoofdstuk 5 Werking van het raamwerk 5.1 Inleiding Nadat in het vorig hoofdstuk alle componenten één voor één werden besproken, is het tijd om het raamwerk in zijn geheel te bekijken vanuit volgende perspectieven: Hoe werken de componenten samen zodat zij de gewenste functionaliteit vervullen? Welke afspraken zijn er om onderling gegevens uit te wisselen? Dit hoofdstuk loopt de belangrijkste use cases af: Inloggen, Inschrijven, Agent aansturen, Agent stuurt bericht, Labo stuurt trigger en Agents vragen gegevens uit databank. Aan de hand van sequentiediagrammen wordt de uitleg ook schematisch verduidelijkt. 5.2 Inloggen Werking Dit is een eenvoudig use case waarbij de gebruiker de actie onderneemt. Het doel is het raamwerk te melden dat een arts in staat is berichten te ontvangen. De communicatie geschiedt volledig tussen de clientapplicatie en de Communication Component. Zie figuur 5.2. Uitloggen verloopt volkomen analoog Web service technisch De typedefinitie voor de loginprocedure staat in de WSDL van de Communication Component als volgt omschreven:

47 5.3 Inschrijven 38 Figuur 5.1: Inloggen op het raamwerk <s:element name="login"> <s:complextype> <s:sequence> <s:element name="login" type="s:string" minoccurs="0"/> </s:sequence> </s:complextype> </s:element> Dit betekent dat de gebruikersnaam dient te worden meegegeven als argument aan de functie login. Een voorbeeld SOAP-body kan er dan als volgt uitzien: <login xmlns=" <login>dr_taveirne</login> </login> 5.3 Inschrijven Werking Een nieuwe inschrijving aanmaken wordt ook aangevat in de clientapplicatie. Zoals altijd legt de client eerst en vooral een verbinding met de Communication Component. Vervolgens voert de CC met dezelfde gegevens een newsubscription-aanroep uit op de Subscription Component. Indien het hier gaat om een nieuwe instantie van de agent, dan wordt met de methode init op de Event Handler uitgevoerd om deze informatie door te sturen naar het Agent Subsystem Web service technisch De typedefinitie van de newsubscription-methode staat in de WSDL van de Communication Component als volgt omschreven:

48 5.4 Agent aansturen 39 Figuur 5.2: Een nieuwe Inschrijving <s:element name="newsubscription"> <s:complextype> <s:sequence> <s:element name="login" type="s:string" minoccurs="0"/> <s:element name="patientid" type="s:string" minoccurs="0"/> <s:element name="agent" type="s:string" minoccurs="0"/> </s:sequence> </s:complextype> </s:element> Een voorbeeld van een SOAP-body die hieraan voldoet is: <newsubscription xmlns=" <login>dr_taveirne</login> <patientid>1906</patientid> <agent>rifle</agent> </newsubscription> 5.4 Agent aansturen Werking Een agent heeft specifieke commando s die hij kan uitvoeren. Omdat die van agent tot agent kunnen verschillen, moet eerst een configuratie van de ondersteunde commando s opgevraagd worden. (zie 4.2.4) Dit laat een grote dynamiek toe in de functionaliteit die agents kunnen vervullen, omdat hierdoor de kans ontstaat om extra functies aan te bieden die los staan van de triggers en de opgelegde interface van de agents. Deze functies kunnen ook gebruik maken van de Database Manager om extra informatie op te vragen als dat nodig is.

49 5.4 Agent aansturen 40 Figuur 5.3: Aansturen van agents Web service technisch Het XML Schema dat gebruikt wordt voor de commandoconfiguratie werd besproken in Een voorbeeld ziet er als volgt uit: <commanddescriptions agent="rifle" xmlns=" xmlns:xsd=" xmlns:xsi=" <command> <name>get_current_status</name> <parameter></parameter> <description> Geef huidige creatinine- en urinestatus van patient </description> </command> <command> <name>get_evolution</name> <parameter></parameter> <description> Geef verloop creatinine- en urinestatus van patient

50 5.5 Agent stuurt bericht 41 </description> </command> </commanddescriptions> In dit voorbeeld vragen de functies geen argumenten. Als dit wel nodig is, worden er een aantal parametertags gespecifieerd. De SOAP-body van een executecommand-methode kan er bijvoorbeeld zo uitzien: <executecommand xmlns=" <patientid>1906</patientid> <agenttype>rifle</agenttype> <command>get_evolution</command> <params></params> </executecommand> 5.5 Agent stuurt bericht Werking Een agent stuurt een bericht in XML-vorm naar de Event Handler met de methode sendmessage. De Event Handler stuurt vervolgens het bericht door naar de Communication Component. Daar worden het bericht in de Message Store opgeslagen. Uit het bericht worden de patiëntidentificatie en het agenttype gehaald. Met deze informatie kan de Communication Component aan de Subscription Component vragen wat de bestemmelingen zijn die geïnteresseerd zijn in dit bericht. Het bericht wordt samen met zijn bestemmingen bijgehouden in de Message Store en wacht daar tot de clients erom pollen Web service technisch De methode sendmessage heeft een genericmsgdocument als argument. Het XML Schema van dit document werd uitgelegd in Een SOAP-body ziet er bijvoorbeeld als volgt uit: <genericmsg xmlns=" <!--1 or more repetitions:--> <message messagetype="alarm" datetime=" t08:36:28"> <patientid>1906</patientid> <agenttype>rifle</agenttype> <message>dit is een voorbeeld van een genericmsgdocument</message> <description>string</description>

51 5.5 Agent stuurt bericht 42 Figuur 5.4: Versturen van een bericht <!--Zero or more repetitions:--> <linegraph> <title>een titel</title> <color>#ffffff</color> <scale xmin="0" xmax="10" ymin="0" ymax="10"/> <axisnames x="x-as" y="y-as"/> <pointlist> <!--1 or more repetitions:--> <point x="0" y="0"/> <point x="1" y="2"/> <point x="2" y="4"/> <point x="4" y="7.3"/> </pointlist> </linegraph> <!--Optional:--> <table> <title>data</title> <columnnames> <!--1 or more repetitions:--> <column name="status"/> </columnnames> <!--1 or more repetitions:--> <row rownumber="100"> <!--1 or more repetitions:--> <item columnname="status">normaal</item> </row>

52 5.6 Labo stuurt trigger 43 </table> </message> </genericmsg> 5.6 Labo stuurt trigger Werking Het laboratorium van de Intensieve Zorgen van het UZGent gebruikt een eigen formaat om labogegevens in op te slaan. Dit formaat is niet handelbaar door het raamwerk en moet dus omgezet worden naar een handiger XML-formaat. Dit gebeurt door de adapters die aan de Trigger Forwarder zijn gekoppeld. Het toevoegen van nieuwe adapters verzorgt dus de compatibiliteit met diverse laboratoria. Het bestand kan niet rechtstreeks naar een Web service worden gestuurd als klare tekst omdat het niet XML-compatibel is. Er komen namelijk soms tags in voor die niet worden afgesloten, bijv: <CR>. Hierdoor wordt een foutmelding gegenereerd door de parser van de Web server. Het labo kan zijn tekstbestand bijvoorbeeld wel uploaden naar een directory via FTP. Een klein programma houdt deze directory in de gaten voor nieuwe bestanden. Dit programma heet de LaboMonitor. Een eerste belangrijke taak van dit programma is het XML-compatibel maken van het tekstbestand. Ongeldige tags worden gefilterd door < te vervangen door < en > te vervangen door >. Het resulterende bestand wordt vervolgens doorgestuurd naar de Trigger Forwarder. De LaboMonitor verplaatst vervolgens de behandelde triggerdocumenten naar een andere directory en er wordt aan de bestandsnaam een unieke prefix toegevoegd. De Trigger Forwarder krijgt de trigger binnen in de vorm van een string. De TF vraagt aan de bijhorende adapter om de string te transformeren naar XML aan de hand van het XML Schema triggerschema (zie 4.2.2). Het is mogelijk dat meerdere triggers opgenomen zijn het XML-document. Uit elke trigger wordt het patiënt-id gehaald om hiermee aan de Subscription Component te vragen welke agents er lopen voor deze patiënt. De Trigger Forwarder houdt zelf ook een mapping bij tussen enerzijds de verschillende soorten triggers, en anderzijds de agenttypes die in deze trigger geïnteresseerd zijn. De doorsnede van de verzamelingen draaiende en geïnteresseerde agents vormt de verzameling van geïnteresseerde agents die draaien voor de patiënt in kwestie. Per agent en patiënt wordt nu de Event Handler opgeroepen. Deze stuurt de trigger op zijn beurt door naar het Agent Subsystem. Binnen het Agent Subsystem wordt

53 5.6 Labo stuurt trigger 44 door de Agent Manager Coordinator een machine gekozen waarop de instantie van de agent geïnstalleerd staat. Figuur 5.5: Versturen van een trigger Web service technisch Een geldige SOAP-body voor de Trigger Forwarder is als volgt: <labotrigger xmlns=" <t> 00000\ \A1\\17/12/2004\06:38\17/12/2004\06:37\C\Ward\ \05/12/2004\03:10\\49\OPN\INZ01\ \ \\ 00001\ \S1\ CAEP02\1906\ A14\xxxxx\Fons\06/05/1979\M\straat 1\9690\B\KLUISBERGEN 00003\ \R1\ \17/12/2004\06:38\ 17/12/2004\06:39\S\\\KREAT\Creatinine Nieuw\ \mg/dL\\1.01\Opgelet: Enkel creatinine nieuw gebruiken voor berekening Cockroft\Val\N\ \\LABINW\D\Y\\\17/12/2004\07:58 </t> <id>id</id> </labotrigger> Het resultaat van de transformatie ziet er zoals volgt uit: <ns:trigger xmlns:ns="

54 5.7 Agents vragen gegevens uit databank 45 <ns:patientid>1906</ns:patientid> <ns:agenttype>rifle</ns:agenttype> <trig:triggers xmlns:trig=" <trig:trigger> <trig:ordernr> </trig:ordernr> <trig:arts> <trig:rizivnr> </trig:rizivnr> </trig:arts> <trig:patient> <trig:firstname>fons</trig:firstname> <trig:lastname>xxxxx</trig:lastname> <trig:patientid>1906</trig:patientid> </trig:patient> <trig:monster> <trig:afkorting>kreat</trig:afkorting> <trig:referentiewaarden> </trig:referentiewaarden> <trig:eenheid>mg/dl</trig:eenheid> <trig:waarde>1.01</trig:waarde> </trig:monster> </trig:trigger> </trig:triggers> </ns:trigger> 5.7 Agents vragen gegevens uit databank Werking Zoals in het vorig hoofdstuk al werd uitgelegd, wordt voor een bepaald agenttype een query gedefinieerd in de Database Manager. De query zelf wordt voor de agent verborgen gehouden en is enkel uit te voeren via de requestvalue-methode van de Database Manager met behulp van een sleutel en reeks parameters. De agent roept de (requestvalue) methode aan bij Event Handler met de sleutel van de query en de lijst van parameters als argument. Dit wordt doorgestuurd naar de Database Manager. Daar wordt de sleutel gebruikt om de letterlijke query op te halen. Hierin worden dan de parameters ingevuld en wordt de query uitgevoerd op de databank. Een array van HashMaps wordt teruggegeven Web service technisch In het WSDL-document staat de requestvalue-methode beschreven als volgt:

55 5.7 Agents vragen gegevens uit databank 46 Figuur 5.6: Bevragen van de IZIS databank <s:element name="requestvalue"> <s:complextype> <s:sequence> <s:element name="key" type="s:string" minoccurs="0"/> <s:element name="parameters" type="ope:arrayofstring" minoccurs="0"/> </s:sequence> </s:complextype> </s:element> Een geldige SOAP-body ziet er als volgt uit: <requestvalue xmlns=" <key>uo</key> <parameters> <String>1906</String> <String> </String> </parameters> </requestvalue> Een mogelijk resultaat als gevolg van de uitvoering van deze query: <ns:hashmap> <ns:item> <ns:key xsi:type="xsd:string">value</ns:key> <ns:value xsi:type="xsd:double">26.0</ns:value>

56 5.7 Agents vragen gegevens uit databank 47 </ns:item> <ns:item> <ns:key xsi:type="xsd:string">datetime</ns:key> <ns:value xsi:type="xsd:datetime"> T22:00:00+02:00 </ns:value> </ns:item> </ns:hashmap> <ns:hashmap> <ns:item> <ns:key xsi:type="xsd:string">value</ns:key> <ns:value xsi:type="xsd:double">10.0</ns:value> </ns:item> <ns:item> <ns:key xsi:type="xsd:string">datetime</ns:key> <ns:value xsi:type="xsd:datetime"> T23:00:00+02:00 </ns:value> </ns:item> </ns:hashmap> Dit is een representatie in de vorm van een tabel. Elke HashMap vormt een rij en elk item stelt een cel voor. De naam van de bijhorende kolom wordt opgenomen als sleutel in het item. De eigenlijke waarde zit in het value-luik van een item.

57 DE CLIENTAPPLICATIE 48 Hoofdstuk 6 De Clientapplicatie 6.1 Inleiding Artsen willen tijdens hun job de tijd optimaal indelen. Ze lopen door het ziekenhuis van patiënt tot patiënt met elk hun individuele uitdagingen en problemen. Een arts wenst niet te veel tijd te verspillen met het aanklikken van knopjes of het doorzoeken van een menu op zijn PDA. Het ontwerp van de grafische gebruikersinterface is dus uitermate belangrijk voor de bruikbaarheid van het volledige raamwerk. Het moet voor de arts een winst opleveren in zowel efficiëntie als tijd. Het gebruikersprogramma moet zeer nauw aansluiten bij de noden van de artsen en het verplegend personeel. Dit maakt dat de structuur van het programma intern goed moet opgebouwd zijn zodat het programma gemakkelijk kan aangepast worden aan de noden van de gebruiker. Na een proefperiode kan het gebeuren dat bepaalde zaken moeten aangepast worden en dit mag dan ook niet betekenen dat het programma vanaf nul dient te worden herschreven. In die zin is het ontwikkelde programma slechts een vertrekpunt van wat het uiteindelijk zou kunnen worden. Eventuele uitbreidingen worden besproken als laatste paragraaf van dit hoofdstuk. Het programma dient in de eerste plaats om de werking van het raamwerk te demonstreren. Dit omdat deze client de enige plaats is waar de berichten effectief worden getoond en voor menselijke interpretatie beschikbaar zijn. 6.2 Gebruiksvriendelijkheid Er kunnen in principe twee soorten gebruikersprogramma s worden geschreven. Ten eerste kan de arts het programma overal met zich meedragen op een PDA. De grafische

58 6.3 Technologie 49 gebruikersinterface dient hiervoor speciaal te zijn ontworpen want een PDA legt bepaalde beperkingen op zoals afmetingen in pixels, rekenkracht en geheugen. Hierdoor is het een uitdaging een programma te ontwikkelen waarbij alle informatie duidelijk op het scherm verschijnt. Een andere beperking ligt hem in rekenkracht en geheugen. De applicatie dient zelf niet veel rekenwerk uit te voeren, maar als het aankomt op het draaien van een grafische gebruikersinterface kunnen sommige bibliotheken die hiervoor voorzien zijn toch te zwaar uitvallen. Een tweede soort applicatie is een applicatie die op een machine naast het bed van de patiënt loopt. Hierop komen alle berichten met betrekking tot deze patiënt terecht, onafhankelijk van de arts die de patiënt voor een bepaalde agent heeft ingeschreven. 6.3 Technologie De client zoals die hier beschreven wordt, is ontwikkeld met in het achterhoofd het doel op een PDA geïnstalleerd te worden. Het is ook zo dat het ontwerp van de client zo is opgebouwd dat het relatief eenvoudig is om dit te wijzigen naar een applicatie die op een normaal computer scherm kan worden getoond. De ontwikkelde applicatie kan ook op een normale computer naast het bed van de patiënt worden geïnstalleerd, maar ze maakt niet optimaal gebruik van het grotere scherm om de informatie te tonen. De code van de grafische gebruikersinterface werd strikt gescheiden gehouden van de rest van de code om uitbreiding naar een ander type terminal mogelijk te maken. Om te kunnen draaien op een PDA moesten enkele keuzes worden gemaakt in verband met de implementatie. Zo is bijvoorbeeld de Java Swing-bibliotheek voor het ontwikkelen van grafische gebruikersinterfaces niet bruikbaar voor programma s op PDA indien J9 van IBM op de PDA wordt geïnstalleerd als Java virtuële machine(jvm ). Deze JVM is gebaseerd op de JDK 1.3 specificatie maar heeft geen volledige ondersteuning voor de Swing-bibliotheek. Swing is ook behoorlijk zwaar voor een PDA waardoor de vereiste rekenkracht de levensduur van de batterij zou verminderen. SWT echter is een bibliotheek die veel lichter is en waarbij gebruik gemaakt wordt van het onderliggende besturingssyteem om zijn componenten te tekenen. Hierdoor is SWT behoorlijk wat sneller dan Swing. Er zijn slechts minieme aanpassingen nodig om het programma te porteren naar andere virtuële machines. Er treedt echter nog een probleem op bij het gebruik van J9 als JVM. De proxies die gegenereerd worden door BEA WebLogic gebruiken namelijk sommige klassen die niet goed beschikbaar zijn vanaf JDK 1.4. De virtuele machine CrEme [3] zou hiervoor een betere oplossing aanbieden.

59 6.4 De use cases 50 CrEme biedt echter wel ondersteuning voor Swing aan, maar de snelheidswinst door het gebruik van SWT blijft aanzienlijk. 6.4 De use cases Om de netwerktraffiek zoveel mogelijk te beperken houdt het programma zelf ook de berichten bij die hem werden toegestuurd. De gebruiker wenst op een vlotte en intuïtieve manier deze berichten te beheren. Niet alleen de berichten maar ook de patiënten moeten op de applicatie kunnen beheerd worden. Kortom, de use cases voor de clientapplicatie verschillen lichtjes ten opzichte van die van het gehele raamwerk. Figuur 6.1: Use cases van de clientapplicatie 6.5 De structuur van de client MVC MVC staat voor Model-View-Controller, ook wel Observer pattern genoemd. Het is een software architectuur die ervoor zorgt dat de data en de gebruikersinterface mooi van elkaar worden

60 6.5 De structuur van de client 51 Figuur 6.2: MVC architectuur gescheiden. De architectuur bestaat uit drie componenten die met elkaar communiceren zodat veranderingen in de data onmiddellijk zichtbaar worden in de interface en zodat de data reageert op acties ondernomen door de gebruiker. Model Dit is het deel dat instaat voor de representatie van de data waarop de applicatie opereert. View Deze module zorgt ervoor dat de onderliggende data wordt getoond aan de gebruiker. Er kunnen verschillende views bestaan. Welke data hier getoond wordt en op welke manier kan verschillen van view tot view, maar allen zijn ze gebaseerd op hetzelfde datamodel. Controller Deze module vormt de verbinding tussen de model en de view. Het is de controller die reageert op gebeurtenissen of acties en die de correcte functies in de model of in de view aanroept Klassendiagram In figuur 6.3 ziet u een overzicht van de opbouw van de clientapplicatie. In volgende paragrafen worden de verschillende klassen één voor één uitgelegd, waarna de samenwerking tussen de componenten wordt geïllustreerd aan de hand van sequentiediagrammen.

61 6.5 De structuur van de client 52 Figuur 6.3: Client Application UML GUI Dit is de hoofdklasse van de clientapplicatie. De volledige grafische gebruikersinterface wordt hier opgebouwd in een methode createcontents(). Alle componenten van de interface worden hier geïnitialiseerd en de implementaties voor de verschillende knoppen worden voorzien. Na de initialisatie van alle componenten wordt een dialoogvenstertje getoond om in te loggen. De arts kan hier zijn gebruikersnaam en paswoord ingeven. De aanmeldingsprocedure (zie 6.6.2) controleert of de opgegeven gegevens correct zijn. Indien niet wordt het dialoogvenstertje opnieuw getoond. GUI heeft ook een interne klasse die de interface DataModelListener (zie 6.5.5) implementeert. Hierin staan de methodes die reageren op nieuwe gebeurtenissen. Deze methodes zorgen ervoor dat de grafische gebruikersinterface altijd synchroon blijft met de data die zich bevindt

62 6.5 De structuur van de client 53 in het DataModel (zie 6.5.4) Datamodel Het DataModel is de Model-klasse uit het MVC-applicatiemodel. Het is de datarepresentatie van alle gegevens die in de client aanwezig zijn. Dit gaat van een gelinkte lijst van alle berichten tot een index in deze lijst die wijst naar het huidige bericht dat getoond wordt. Het DataModel implementeert ook de acties die moeten worden uitgevoerd nadat een gebruiker de knop heeft ingedrukt om de berichten te laden. Een andere belangrijke functie is addmessage(message m). Deze functie voegt een nieuw bericht toe aan het datamodel. Al deze functies kunnen veranderingen teweeg brengen in de toestand van de applicatie en het is dan ook noodzakelijk dat de grafische gebruikersinterface hierop reageert. Zo is wat men ziet, consequent met de interne data. Met de functie notifymodellisteners() worden alle DataModelListeners (zie 6.5.5) op de hoogte gebracht van deze veranderingen. Er zijn vier types van gebeurtenissen waarop de grafische gebruikersinterface kan reageren. UPDATE MESSAGE VIEW Dit type wordt gebruikt als er een navigatiemethode werd gebruikt om een ander bericht te laden in de applicatie. Bij dit type wordt de functie updatemessageview()uit de DataModelListener-interface (6.5.5) gebruikt. UPDATE CONTROL INFORMATION Als een nieuw bericht wordt toegevoegd, moet het overzicht van alle berichten worden aangepast. Dit type komt overeen met de newmessagereceived()-functie uit de DataModelListenerinterface (6.5.5). UPDATE SUBSCRIPTION INFORMATION Bij nieuwe inschrijvingen moet ook dit deel van de applicatie opnieuw geladen worden. De nieuw toegevoegde patiënten en de nieuwe configuratie van de inschrijvingen worden getoond. Hier wordt de GUI verwittigd via de functie updatesubscriptionview() uit de DataModelListener. UPDATE COMMAND INFORMATION Om te weten te komen welke commando s de verschillende agents ondersteunen wordt

63 6.5 De structuur van de client 54 een configuratie document opgevraagd. Bij het ontvangen van deze informatie wordt een gebeurtenis van dit type gegenereerd DataModelListener Dit is een interface die bepaalt welke functies de klassen moeten implementeren als zij wensen op de hoogte gebracht te worden van verandering in de data van de applicatie. Deze functies werden reeds in de vorige paragraaf opgesomd. De methode newmessagerecieved() wordt opgeroepen als er een nieuwe boodschap opgenomen werd in de lijst van berichten na het uitvoeren van een poll op de Communication Component. De methoden updatemessageview(), updatesubscriptionview() en updatecommandview() zorgen ervoor dat de respectievelijke panelen worden hertekend aan de hand van de data bestemd voor het paneel in kwestie. public interface DataModelListener { void newmessagerecieved(); void updatemessageview(); void updatesubscriptionview(); void updatecommandview(); } WebServiceControl en WebServiceCaller De twee klassen zorgen voor de eigenlijke communicatie met het raamwerk. De WebServiceControl klasse stuurt de WebServiceCaller aan. Ze heeft een interne timer die de snelheid van het pollen regelt. De WebServiceCaller maakt gebruik van proxy s die gegenereerd worden door BEA WebLogic. Het gebruik van deze proxy s wordt later uit de doeken gedaan. Het is de klasse WebServiceCaller die in de communicatie voorziet tussen de clientapplicatie en de Communication Component van het raamwerk. Een lijst van functies die hierin geïmplementeerd zijn, staan hieronder weergegeven. De werking ervan wordt uitgelegd wanneer de werking van de verschillende use cases wordt uitgelegd (6.8.3 en 6.9.3). public class WebServiceCaller { void login(){...} void logout(){...} void pollfornewmessage(){...} void getconfig(){...} void unsubscribe(string patient, String agent){...} void newsubscription(string patient, String agent){...}

64 6.6 Inloggen en Uitloggen 55 } void getcommands(){...} void executecommands(){...} SecurityInformation Dit is de klasse die de authenticatiegegevens bijhoudt. Zaken zoals gebruikersnaam en paswoord worden hier bewaard en gebruikt indien nodig SubscriptionConfig Deze klasse houdt alle informatie bij die de inschrijvingen aangaat. Informatie zoals een lijst van patiënten en een lijst van Intelligent Agents die beschikbaar zijn. De inschrijvingen worden bijgehouden in een java.util.hashmap met de patiëntnaam als sleutel. De waarde behorend bij deze patiënt in de HashMap is een java.util.arraylist van Intelligent Agents CommandsConfig Hier wordt de informatie bijgehouden in verband met commando s die kunnen uitgevoerd worden op agents. Deze configuratie bestaat uit de namen van de verschillende commando s gelinkt aan de agents waarop ze kunnen worden uitgevoerd, samen met de parameters die kunnen worden meegegeven. Het maakt gebruik van een interne klasse Command die de eigenlijke datastructuur van een commando beschrijft. 6.6 Inloggen en Uitloggen Functionaliteit Het in- en uitloggen zoals het ondersteund wordt door het raamwerk is van zeer eenvoudige aard. Het dient enkel en alleen om het raamwerk op de hoogte te brengen van het feit dat een arts actief is en dus in staat is berichten te ontvangen. Het is wel zo dat om te kunnen inloggen een gebruikersnaam en paswoord vereist is. Deze gegevens worden naar het raamwerk gestuurd met behulp van WS-Security. Enkel het authenticatieluik werd uitgewerkt om als voorbeeld te dienen van hoe beveiliging kan worden geïmplementeerd tussen de clientapplicatie en het raamwerk.

65 6.6 Inloggen en Uitloggen 56 Figuur 6.4: Login dialoogvenster Werking De werking is eenvoudig. Bij het opstarten van de applicatie wordt aan de gebruiker een gebruikersnaam en een paswoord gevraagd via een dialoogvenster. In figuur 6.5 is te zien hoe de loginprocedure wordt afgehandeld. De WebServiceCaller gebruikt de login-methode van de Communication Component Web service van het raamwerk. Als de aanmeldingsprocedure echter faalt, wordt een SOAPFault met de details van de fout teruggestuurd. Als dat gebeurt, zorgt de GUI ervoor dat het dialoogvenster opnieuw wordt getoond om een eventueel foute invoer te corrigeren Belangrijke code Om de gebruikersgegevens door te sturen naar het raamwerk wordt gebruik gemaakt van WS- Security. Het komt er hier op neer een UsernameToken aan de SOAPHeader toe te voegen met daarin de gebruikersnaam en het paswoord. Dit gebeurt als volgt: WebServiceContext context = proxy.context(); WebServiceSession session = context.getsession(); HandlerRegistry registry = proxy.gethandlerregistry(); List list = new ArrayList(); list.add(new HandlerInfo(WSSEClientHandler.class,null,null)); registry.sethandlerchain(new QName("CCSoap"),list); UserInfo ui = new UserInfo(username, password); session.setattribute(wsseclienthandler.request_userinfo,ui);

66 6.6 Inloggen en Uitloggen 57 Figuur 6.5: Sequentie diagram inloggen SecurityElementFactory factory = SecurityElementFactory.getDefaultFactory(); Security security = factory.createsecurity(null); security.addtoken(ui); session.setattribute(wsseclienthandler.request_security,security); De header van het resulterende SOAP bericht ziet er als volgt uit. Dr Taveirne en Mijn- Paswoord zijn respectievelijk de ingegeven gebruikersnaam en paswoord. Deze gegevens dienen overeen te komen met de gebruikersconfiguratie van de WebLogic Applicatie Server. <env:header> <wsse:security env:mustunderstand="1" xmlns:wsse=" <wsse:usernametoken wsu:id="id-dpschdeowxz7qohcf6ircmqn" xmlns:wsu=" <wsse:username>dr_taveirne</wsse:username> <wsse:password Type=" MijnPaswoord </wsse:password> </wsse:usernametoken> </wsse:security> </env:header>

67 6.7 Beheer van berichten Beheer van berichten Berichten worden na het pollen lokaal bijgehouden in het geheugen van de PDA. Na een tijdje kan dit aantal berichten aanzienlijk oplopen en is dus een goed beheer noodzakelijk. In figuur 6.6 is een momentopname van de applicatie met een demonstratiebericht geladen afgebeeld. Figuur 6.6: Berichten venster

68 6.7 Beheer van berichten Functionaliteit Een eerste belangrijk aspect is het inladen van berichten zodat ze worden getoond zoals te zien is in figuur 6.6. Daarvoor zijn er een aantal mogelijkheden. Eerst en vooral kan men bovenaan de applicatie in het berichtenvenster een patiënt selecteren. Dan kan men met de knoppen Vorige en Volgende de onbehandelde berichten overlopen. De knoppen onderaan de applicatie kunnen worden gebruikt om rechtstreeks te springen naar de dringende berichten, en dit over alle patiënten heen. De patiëntselectie bovenaan de applicatie heeft hier dus geen invloed. Eens een bericht werd behandeld, kan dit worden aangegeven met de knop Bericht behandeld onderaan het berichten venster. Vanaf dat ogenblik is het bericht niet meer bereikbaar via de navigatieknoppen, maar enkel via het overzichtvenster. Een tweede aspect is het overzicht. De arts wenst op een eenvoudige manier een overzicht te hebben van alle berichten die voor een bepaalde patiënt werden ontvangen. Het overzichtvenster is te zien in figuur 6.9. Elk bericht wordt hier samengevat op één enkele lijn. Als men dubbelklikt op een lijn dan wordt het bericht geladen in het berichtenvenster, onafhankelijk of die al dan niet reeds werd behandeld. In dit overzicht venster is het ook mogelijk bericht definitief uit het geheugen van de PDA te verwijderen door op het delete-veld te klikken Werking De navigatieknoppen worden geïmplementeerd door de volgende functies shownextmessage() Deze functie springt vooruit in de lijst van boodschappen naar het volgende bericht dat bij de huidig geselecteerde patiënt behoort. showpreviousmessage() Deze functie springt achteruit in de lijst van boodschappen naar het vorige bericht dat bij de huidig geselecteerde patiënt behoort. shownextalarm() Deze functie springt naar het volgende alarm over alle patiënten heen. showpreviousalarm() Deze functie springt naar het vorige alarm over alle patiënten heen.

69 6.7 Beheer van berichten 60 Figuur 6.7: Overzicht venster Belangrijke code Deze vier functies worden allemaal op een analoge wijze geïmplementeerd. Als een voorbeeld volgt de code van de methode shownextmessage(). public void shownextmessage() { try { int i = currentmessageindex; do {

70 6.8 Inschrijvingen 61 } ++i; }while(i < messages.size() && ((Message)messages.get(i)).getStatus()==Message.STATUS_HANDLED &&!((Message)messages.get(i)).getPatientID().equals(currentPatientID)); if(i < messages.size() && ((Message)messages.get(i)).getStatus()==Message.STATUS_UNHANDLED) { // only update when current message index has changed currentmessageindex = i; notifymodellisteners(update_message_view); } }catch (NoSuchElementException nsee){ System.err.println("showNextMessage(): No Such Element"); }catch (IndexOutOfBoundsException ioobe){ System.err.println("showNextMessage(): Index out of bounds"); } 6.8 Inschrijvingen Functionaliteit Een inschrijving is een combinatie van een arts, een patiënt en een agent. De clientapplicatie heeft een venster waarin de arts in staat is zijn/haar inschrijvingen te beheren. De procedure is eenvoudig, men selecteert een patiënt uit een keuzemenu en één van de beschikbare agents uit een ander keuzemenu. De knop Schrijf in zorgt ervoor dat de nieuwe inschrijving wordt doorgestuurd naar het raamwerk. Van zodra de inschrijving is geregistreerd, ontvangt de client een nieuw configuratiedocument om het datamodel in de clientapplicatie consistent te maken met de configuratie in het raamwerk. Naast een nieuwe inschrijving is het ook mogelijk zichzelf uit te schrijven voor de berichten van de betrokken agent voor een patiënt. In de grafische gebruikersinterface dient men hiervoor enkel de gewenste inschrijvingen uit te vinken en vervolgens de nieuwe configuratie naar het raamwerk door te sturen Werking Nadat de gebruiker op de knop gedrukt heeft om de nieuwe inschrijving door te voeren wordt de methode newsubscription(patientid,agent) opgeroepen op de WebServiceControl klasse. Deze stuurt de oproep op zijn beurt door naar de WebServiceCaller. Deze voert een asynchrone Web service call uit naar de Communication Component van het raamwerk. In paragraaf 6.8.3

71 6.8 Inschrijvingen 62 Figuur 6.8: Inschrijvingen venster

72 6.8 Inschrijvingen 63 staat beschreven hoe dit gebeurt. Nadat de Web service oproep werd afgehandeld, vraagt de client opnieuw op een analoge asynchrone manier de configuratie van de huidige inschrijvingen van het raamwerk op. Met deze gegevens wordt een nieuw SubscriptionConfig-object aangemaakt en geregistreerd in het datamodel. Als reactie hierop dient de grafische gebruikersinterface worden aangepast. Dit gebeurt met behulp van de methode updatesubscriptionview() uit Het uitschrijvingen van een patiënt gebeurt volledig analoog Figuur 6.9: Sequentie diagram inschrijven Belangrijke code Een nieuwe inschrijving wordt op een asynchrone manier gestuurd naar het raamwerk. Dit betekent dat de clientapplicatie niet moet wachten tot de Web service aanroep is afgehandeld. Er wordt een luisteraar geregistreerd die wacht tot de oproep is afgehandeld. public void newsubscription(string patient, String agent) { AsyncInfo asyncinfo = new AsyncInfo(); asyncinfo.setresultlistener(new ResultListener(){ public void oncompletion(invokecompletedevent event) { CCSoap_Stub source = (CCSoap_Stub)event.getSource(); try { source.endnewsubscription(event.getfutureresult()); getconfig(); } catch (RemoteException e) { e.printstacktrace();

73 6.9 Commando s 64 } } } }); try { soapproxy.startnewsubscription(secinfo.getusername(), patient, agent, asyncinfo); } catch (RemoteException e) { e.printstacktrace(); } 6.9 Commando s Functionaliteit Een agent kan allerlei mogelijke commando s definiëren. Een voorbeeld: als een arts een patiënt bezoekt en informatie wenst van een agent over de betrokken patiënt, dan zou het kunnen dat die arts een agent een bepaald commando wenst uit te voeren om meer recenter informatie te ontvangen. Het is volledig aan de agent om te bepalen wat een commando doet en hoe het kan opgeroepen worden Werking Het ophalen van de commandoconfiguratie gebeurt typisch bij het opstarten van de clientapplicatie en bij het herladen van de configuratie van de inschrijvingen indien er een nieuwe agent opduikt. Na het ophalen van de configuratie van de inschrijvingen zal voor elk agenttype daarin gevonden de Communication Component worden aangesproken om de getcommands(agenttype) methode te kunnen uitvoeren. Hoe het raamwerk deze oproep verwerkt is te lezen in Belangrijke code Hier wordt opnieuw getoond dat de Web service asynchroon wordt aangesproken zodat de client niet onbeschikbaar is tot alle aanvragen zijn afgehandeld. Dit is ook een eenvoudig voorbeeld van hoe gemakkelijk men kan gebruik maken van de datastructuren geleverd door de proxygeneratie van de J2EE applicatie server. public void getcommands() { final CommandsConfig cconfig = new CommandsConfig(); AsyncInfo asyncinfo = new AsyncInfo();

74 6.9 Commando s 65 Figuur 6.10: Commando venster

75 6.9 Commando s 66 Figuur 6.11: Sequentie diagram commando s asyncinfo.setresultlistener(new ResultListener(){ public void oncompletion(invokecompletedevent event) { CCSoap_Stub source = (CCSoap_Stub)event.getSource(); try { CommandDescriptions cds = source.endgetcommands(event.getfutureresult()); CommandAnonType [] cs = cds.getcommand(); ArrayList commands = new ArrayList(); for (int i = 0; i < cs.length; i++) { CommandsConfig.Command c = new CommandsConfig.Command( cs[i].getdescription(), cs[i].getname(), cs[i].getparameter()); commands.add(c); } cconfig.setcommands(cds.getagent(),commands); model.setcommandsconfig(cconfig); } catch (RemoteException e) { e.printstacktrace(); } } }); ArrayList agents = model.getsubscriptionconfig().getagents(); for (final Iterator iter = agents.iterator(); iter.hasnext();) { String agenttype = (String) iter.next(); try { GetCommands gc = new GetCommands();

76 6.9 Commando s 67 } } gc.setlogin(secinfo.getusername()); gc.setagenttype(agenttype); soapproxy.startgetcommands(gc,asyncinfo);//for all types } catch (RemoteException e) { e.printstacktrace(); }

77 PRESTATIETESTEN 68 Hoofdstuk 7 Prestatietesten 7.1 Inleiding Door de artsen te laten pollen om hun berichten, kan de Communication Component gevoelig zijn aan overbelasting. Dit werd uitvoerig onderzocht in 7.3. De Subscription Component heeft geen functies die zeer veel aangeroepen worden. Laboresultaten worden niet aan de lopende band gegenereerd, dus de belasting van de Trigger Forwarder is ook laag. De Event Handler is een component die geen toestand heeft, en dus zeer snel zijn taken kan uitvoeren. De huidige agents - RIFLE en Glycemie - vragen slechts sporadisch gegevens op uit IZIS. De Database Manager wordt hierdoor slechts af en toe zwaar belast. Door het lage voorkomen heeft dit geen negatieve invloed op de rest van het raamwerk. De clientapplicatie moet op PDA kunnen draaien, en dit brengt een aantal beperkingen met zich mee. De applicatie mag daarom in rekenkracht en geheugen niet te veeleisend zijn. Dit is getest in Testopstelling Het Agent Subsystem werd geïnstalleerd op een Intel Pentium GHz machine met 512 MiB geheugen en Windows XP Professional Build en draaide op het.net framework Build Service Pack 1. De rest van het raamwerk werd geïnstalleerd op een AMD Athlon XP machine met 1 GiB geheugen. Het besturingssysteem was Microsoft Windows 2000 Server Service Pack 2. De application server was BEA WebLogic Version Build

78 7.3 Polling 69 De Agent Subsystem machine werd via een VPN-connectie in hetzelfde netwerk gebracht als de andere machine. Dit is het Atlantis-netwerk van INTEC (UGent). 7.3 Polling Een testprogramma berekent voor een stijgend aantal clients de antwoordtijd van de pollaanroepen (7.1). De aanroepen worden random gestart in het interval van 30 seconden. Het programma simuleert dit door de aanroepen van alle clients random te starten in het interval van 30 seconden. Dit resulteert in een quasi uniforme verdeling. Er zijn ongeveer 50 bedden aanwezig in Intensieve Zorgen. Stel dat ook 10 artsen aanwezig zijn. Dan zijn er op elk moment 60 clients actief aan het pollen. Figuur 7.1 maakt duidelijk dat dit geen probleem vormt. De antwoordtijden blijven comfortabel onder 100 ms. Figuur 7.1: Grafiek polling Indien we het aantal clients doen stijgen krijgen we een situatie zoals in figuur 7.2. Hier is te zien dat vanaf een 175-tal clients de duur om een request af te handelen ongeveer gelijk is aan het interval waarmee de aanvragen binnenkomen. Indien het aantal clients verder blijft stijgen is de verwerkingstijd langer dan het interval tussen de aanvragen en ontstaat er dus een ophoping van aanvragen waardoor trashing kan ontstaan zoals te zien in deze figuur. Bij een groot aantal clients moet dus zeker gezocht worden naar een andere oplossing dan polling. Zie hiervoor de Uitbreidingen in Hoofdstuk 8.

79 7.4 Reistijd 70 Figuur 7.2: Grafiek polling stijgend aantal clients 7.4 Reistijd De gemiddelde reistijd doorheen het raamwerk geeft niet echt een goede representatie van de ware reistijd van een bericht omdat in onze testomgeving alle componenten op één machine draaien en er dus geen netwerkverkeer is. Wat het wel toont is een idee van welke component het meest tijd vergt om zijn werk te doen. Figuur 7.3: Gemiddelde reistijd

80 7.5 Clientapplicatie 71 Zoals te zien in figuur 7.3 is de Communication Component de zwaarste component op dit pad. Dit komt voornamelijk door de databank toegangen die nodig zijn voor het opslaan van het te versturen bericht. Verrassend is ook het relatief grote aandeel van de Event Handler in de reistijd van een bericht. Aangezien de Event Handler een doorsluiscomponent is, is het relatief eenvoudig om meerdere Event Handlers in het systeem op te nemen en volgens de verschillende uitvoeringspaden te scheiden. Bijvoorbeeld door het inzetten van een afzonderlijke Event Handler die enkel instaat voor het het overbrengen van de labotriggers naar de agents. 7.5 Clientapplicatie De testen die we hebben uitgevoerd op de clientapplicatie dienen om te kijken of het programma geschikt is om op PDA te draaien. Ten eerste blijft het uitvoerbare jar-bestand onder de 5 MiB, inclusief alle bibliotheken die nodig zijn zoals de Web service ondersteunende archieven van WebLogic, en de bibliotheken voor de ondersteuning van SWT. Figuur 7.4: Staafdiagram voor geheugengebruik Het geheugengebruik wordt in figuur 7.4 getoond. De hoeveelheid gebruikt geheugen hangt sterk af van het aantal berichten die werden ontvangen en het soort bericht. Een statusrapport is meestal zeer klein en vormt geen enkel probleem voor het geheugen. Berichten die de evolutie van bepaalde medische eigenschappen willen weergeven kunnen zeer groot zijn en de prestaties op een PDA in grotere mate beïnvloeden. Het type PDA speelt hier natuurlijk ook een grote rol. Men zou ervoor kunnen opteren het aantal berichten dat in het geheugen gehouden wordt, te beperken, maar het blijft de arts die beslist welke berichten hij wil bijhouden en welke niet.

81 UITBREIDINGEN EN BESLUIT 72 Hoofdstuk 8 Uitbreidingen en besluit 8.1 Uitbreidingen Het verhaal van het raamwerk is na dit werk nog niet ten einde. Op het vlak van betrouwbaarheid en beveiliging is er nog verbetering mogelijk. Maar ook conceptueel is er nog een wereld van mogelijkheden Betrouwbaarheid Betrouwbaarheid is een zeer belangrijk concept in de medische wereld. Allerhande apparatuur moet aan de strengste eisen voldoen om te kunnen worden ingezet. Dit is niet anders bij softwaresystemen. De architectuur en de implementatie die wij in deze scriptie hebben voorgesteld, werkt, maar raakt slechts het oppervlak van wat mogelijk is met de gekozen technologieën. J2EE biedt een zeer betrouwbaar en stabiel platform aan om om te gaan met belangrijke gegevens door zijn goed uitgewerkt transactioneel model voor datauitwisseling. Ook de Web service georiënteerde aanpak biedt nog tal van mogelijkheden. UDDI bijvoorbeeld kan ervoor zorgen dat componenten dynamisch aan elkaar worden gekoppeld in plaats van statisch. Dit kan door telkens een UDDI-register te raadplegen om de componenten te localiseren. Zo kunnen alle componenten meermaals in het systeem aanwezig zijn, wat men kan gebruiken voor load balancing of backup doeleinden. Zuiver dynamische selectie van de componenten zou een behoorlijke overhead leveren en de totale uitvoeringstijd drastisch naar beneden halen. Daarom kan er geopteerd worden voor een hybride vorm tussen de statische en de dynamische aanpak. Hierbij worden de proxy s bijgehouden in de clientcomponent en het UDDI-register wordt slechts geraadpleegd indien een timeout optreedt. Op deze manier verkleint de kans dat een component

82 8.1 Uitbreidingen 73 overladen wordt en de aanvragen niet meer kan afhandelen waardoor de betrouwbaarheid van het raamwerk stijgt Beveiliging Op het vlak van beveiliging biedt de Web service technologie nog tal van mogelijkheden. WS- Security kan verder in de beveiliging voorzien van de componenten onderling en tussen het raamwerk en de client. Naast identificatie kan ook authenticatie, authorisatie, integriteit en betrouwbaarheid met behulp van WS-ReliableMessaging en single sign on worden toegevoegd. Dit onderwerp is echter zo omvangrijk dat dit een scriptie op zich zou kunnen vormen Conceptuele uitbreidingen Vermijden van polling De overhead die geleverd wordt door het pollen van de clients is aanzienlijk, zowel in de Communication Component als op het netwerk. De oorzaak is dat vele poll-aanvragen negatief beantwoord zullen worden, omdat er niet elke 30 seconden een bericht zal zijn. Wij hebben gekozen voor de polling methode om ons niet te veel af te leiden van het werk in het raamwerk. Toch hebben we een aantal alternatieven geprobeerd. Om pollen te vermijden wensen we eigenlijk vanuit de CC een Web service op te roepen op de clientapplicatie. Daarvoor dient op de PDA een mini-webcontainer worden geïnstalleerd waarop Web services kunnen draaien. Een voorbeeld van een lichtgewicht Web container is Jetty. Het probleem dat hierbij optrad was het probleem om de gegevens vanuit de web container op PDA naar de grafische gebruikersinterface te transfereren. Het systeem van listeners tussen de webcontainer en de clientcode werkte in de door ons geteste versie nog niet optimaal. Maar een mogelijke oplossing bestond erin vanuit clientcode te pollen naar de lokale webcontainer om te zien of er iets is toegekomen. Dan pollt de client nog altijd, wat betekent dat aan de clientapplicatie bijna niets moet veranderd worden, en is toch het netwerk ontlast van polltrafiek door het inbouwen van een extra Web service component op de PDA. Jetty is hiervoor uitstekend omdat dit in feite een mini J2EE server is, wat betekent dat we zonder probleem de berichten kunnen persistent maken op de PDA. Omdat op deze manier niet meer gepolld wordt, en dus niet meer weten waar naartoe de CC het bericht moet doorsturen, moet gebruik gemaakt worden van UDDI om de PDA s van de artsen te lokaliseren. Dit ging ons echter te ver leiden van het eigenlijk werk aan het raamwerk, maar is zeker de moeite waard om nog verder

83 8.1 Uitbreidingen 74 te worden uitgespit. Een ander mogelijk systeem is OSGi. OSGi is een perfect raamwerk om gegevens op een asynchrone manier naartoe te sturen. Het zag er hier echter naar uit dat we niet langer zouden kunnen gebruik maken van de WebLogic proxy s die we gebruikten voor de implementatie van de client. Het zou echter interessant zijn deze twee mogelijkheden eens tegen elkaar te plaatsen en te testen op samenwerking met BEA WebLogic als Application Server. Profielen in de Communication Component Het is belangrijk dat de informatie die op de clientapplicatie verschijnt, overzichtelijk is. De agents zijn echter niet op de hoogte van de mogelijkheden van de applicatie waar de informatie op tevoorschijn komt. Het is eerder de taak van de Communication Component om ervoor te zorgen dat de geleverde data wordt aangepast aan de terminal waarop de informatie wordt getoond. Met een XQuery-expressie kan het bericht afkomstig van de agent getransformeerd worden naar een formaat aangepast aan de clientapplicatie. Een oplossing zou zijn om op de clients waar het minst kan weergegeven worden enkel de belangrijkste informatie te tonen, bijvoorbeeld bij een curve vooral de pieken indien de rest van de curve min of meer constant is. De Communication Component is echter niet in staat de betekenis van de gegevens in het bericht te ontleden en te beslissen wat al dan niet belangrijk is. Een oplossing is de agents bij elke tag in het genericmsgdocument een attribuut te laten zetten, waarin de agent definieert wat de graad van belangrijkheid is. De Communication Componenten kan dan deze informatie gebruiken om een graad van belangrijkheid te koppelen aan een type clientapplicatie. Deze informatie kan geconfigureerd worden in zogenaamde profielen. Deze oplossing verzwaart lichtjes de werking van de Communication Component maar vermindert de hoeveelheid gegevens die over het netwerk tussen client en CC moeten getransfereerd worden. Artificiële Intelligentie in de Agents De agents hebben een grote vrijheid omtrent het medisch algoritme dat ze wensen te implementeren. Dit kan gaan van eendvoudige if-then-else-code tot complexe algoritmes die gebruik maken van artificiële intelligentie en neurale netwerken. Bij deze laatste kan het noodzakelijk zijn dat voor het leerproces van de neurale netwerken feedback wordt gegeven door de arts op het

84 8.1 Uitbreidingen 75 resultaat van de agent. Deze feedback is in de huidige implementatie nog niet mogelijk en zou een interessante uitbreiding zijn indien er meer complexere agents zouden ontwikkeld worden. Thuisverpleging Het raamwerk werd ontwikkeld met de toepassing in de Intensieve Zorgen in het achterhoofd. De inzetbaarheid van het raamwerk is echter niet beperkt tot deze omgeving. De clientapplicaties kunnen geïnstalleerd worden bij bijvoorbeeld huisartsen of mensen die instaan voor thuisverpleging. De mogelijkheden hiervan zijn eindeloos maar er is nog een belangrijk probleem dat moet overbrugd worden. Het raamwerk maakt gebruik van een centrale databank waarin patiëntgegevens kunnen worden opgevraagd. In de huidige situatie in België is het zo dat er geen gecentraliseerd medisch dossier bestaat. Het is de taak van de huisarts om alle patiëntinformatie bij te houden. Het komt er dus op neer dat een agentinstantie voor een bepaalde patiënt zijn patiëntspecifieke gegevens moet gaan zoeken in de databank van de huisarts. Het grote nadeel hiervan is natuurlijk dat de huisartsen zekere investeringen zouden moeten doen willen ze op dit systeem aangesloten worden. Het aspect van patiëntspecifieke gegevens voor elke agent-instantie wordt aangehaald in [5]. Dan blijft nog het probleem over dat de patiënt in zijn huiselijke omgeving ten eerste gegevens moeten kunnen versturen naar de agent. Ook moet de patiënt de resultaten die hij/zij mag inzien, kunnen raadplegen. Om data te versturen kan de Trigger Forwarder worden gebruikt. De Trigger Forwarder biedt immers ook een interface aan waarbij geen transformatie nodig is. Om data te leveren aan het raamwerk kan voor de patiënt thuis ook een applicatie worden ontwikkeld waarmee ze dus zowel informatie kan bekijken als versturen. Dit kan eventueel zelfs via GSM/UMTS of digitale televisie gebeuren. Nog geavanceerder zou zijn om via lichaamssensoren automatisch bepaalde lichaamsfunctionaliteit te monitoren en die door te sturen. Dit zou handig zijn bij minder motorische patiënten. IMEC werkt aan een project genaamd Human++, waar van lichaamssensoren en draadloze technologie (BAN) gebruik wordt gemaakt om medische gegevens te verzamelen. Het resultaat van deze metingen kan via een USB-ontvanger in een PDA verwerkt worden en van daaruit doorgestuurd worden naar het raamwerk via het triggersysteem. De inzetbaarheid van het raamwerk op het gebied van thuisverpleging is zeker de moeite waard om verder onderzocht te worden.

85 8.2 Besluit Besluit Het raamwerk voor medische advisering is een veelbelovend idee met tal van mogelijkheden om efficiënt artsen te helpen bij het nemen van goed onderbouwde beslissingen. Hoe verder we vorderden in dit werk, hoe meer mogelijkheden boven water kwamen door de generieke architectuur die we hadden ontworpen tijdens de eerste maanden. Genericiteit heeft later zijn vruchten afgeworpen toen we ontdekten dat voor de meeste uitbreiding en aanpassingen zelden of nooit drastische veranderingen in het raamwerk moesten doorvoeren. De service georiënteerde architectuur in combinatie met J2EE heeft in grote mate bijgedragen aan het feit dat we niet aan genericiteit hebben moeten inboeten. Het bleek een systeem te zijn dat perfect voor onze doeleinden kon worden ingezet zonder te verdrinken in de complexiteit van het geheel. We konden mooi elke componenten afzonderlijk implementeren zonder elkaar in de weg te lopen eenmaal de interface was afgesproken. De grote voordelen van het componentgebaseerd ontwerp en het Web service karakter zat hem voornamelijk in de dynamiek en uitbreidbaarheid van het raamwerk. Ook de interoperabiliteit met.net is niet onbelangrijk aangezien.net de werkvloer binnen de ICT van het Universitair Ziekenhuis overheerst. We hebben in dit werk aangetoond dat ook dit geen probleem is. Door de keuze van de architectuur en technologie is het relatief eenvoudig bestaande applicaties om te bouwen naar een agent door er een Web service-laag op te bouwen. Dit kan de drempel tot het inschakelen van dergelijk systeem mee verlagen. Een ander voorbeeld is dat wanneer een ander ziekenhuis een bepaalde expertise heeft, er beslist kan worden deze dienst aan te bieden als een agent en dus naadloos kan laten samenwerken met dit raamwerk. Dit kan de kost mee drukken omdat men dan zelf niet meer moet instaan voor de ontwikkeling van dergelijke agents. Al deze eigenschappen klinken veelbelovend mede omdat er nergens wordt gesproken over drastische veranderingen in de bestaande structuur en herorganisatie van de Intensieve Zorgen. Voor ons betekende deze thesis vooral een leerrijke ervaring. Op het gebied van architectuur, ontwerp en technologie. Maar ook op het gebied van de gezondheidszorg en het menselijk aspect van het geheel. Technologie wordt zeer interessant als ze kan ingezet worden om rechtstreeks mensen te helpen. Het ehealth project in het algemeen is een project dat ons zal blijven boeien en waarvan we hopen dat we de kans zullen krijgen er nog een grote bijdrage aan te geven in de toekomst.

86 INSTALLATIEGIDS 77 Bijlage A Installatiegids A.1 Server Het servergedeelte van het raamwerk voor medische advisering moet op een zodanige manier worden geïnstalleerd zodat schaalbaarheid en betrouwbaarheid worden gemaximaliseerd. Voor de zwaardere componenten zoals de Communication Component en de Database Manager wordt aangeraden ze op afzonderlijke machines te installeren. De Event Handler vereist niet veel rekenkracht maar krijgt veel trafiek te verwerken. Hier is het dus aan te raden een hoge bandbreedte te voorzien omdat vanuit veel verschillende hoeken aanvragen zullen binnenkomen die moeten doorgestuurd worden naar een andere component. Het is aan te raden om een privaat LAN te gebruiken als netwerk tussen de verschillende componenten zodat extern netwerkverkeer geen invloed kan hebben op de werking van het raamwerk. A.1.1 Configuratie databronnen voor Entity Beans Voor de ontwikkeling van het raamwerk werd zoals reeds verteld de WebLogic Application Server van BEA gebruikt. Een nagenoeg standaard configuratie van de server volstaat voor het draaien van het raamwerk. Er dienen enkel een paar extra maatregelen worden genomen voor de configuratie van de databronnen. Alle componenten, op de Event Handler na, gebruiken informatie die via Entity Beans wordt opgeslagen in een databank. Dit kan een gedistribueerde databank zijn, of voor elke componenten een afzonderlijke databank. In [2] wordt uitgelegd hoe men een DataSource kan koppelen aan een Entity Bean.

87 A.2 Client 78 In de WebLogic Server Console kan onder Services/JDBC/DataSources een JDBC Connection Pool gekoppeld worden aan de betrokken datasource zodat deze pool een verbinding met de databank aan de componenten kan leveren indien die erom vraagt. Voor de eigenlijke Connection Pool is de keuze van de te gebruiken databank volledig vrij. Door een URL te definiëren kan eender welke databank worden gebruikt. De databankspecifieke details worden immers afgeschermd door het gebruik van JDBC. A.1.2 Configuratie voor link met IZIS Voor de link met IZIS werd op analoge wijze als voor de Entity Beans een Connection Pool aangemaakt met daarop een DataSource. De gebruikte JDBC-driver voor de Database Manager is weblogic.jdbc.sybase.sybasedriver. A.1.3 Installatie van de componenten De meest eenvoudige manier om de componenten te installeren op de server is om elke component te laden in WebLogic Workshop, daar de server te kiezen waarop men wenst te installeren en vervolgens een build uit te voeren. Men kan ook gewoon de ear-files uploaden naar de server via de console. UDDI wordt in deze feasibility demonstrator nog niet gebruikt. De componenten zijn nu statisch aan elkaar gelinkt waardoor zeker aan betrouwbaarheid, flexibiliteit en schaalbaarheid wordt ingeleverd. Zoals reeds vermeld in is de invoering van UDDI en load balancing de belangrijkste uitbreiding die moet ingebracht worden om een echt inzetbaar raamwerk te krijgen. Als gevolg hiervan zal men het raamwerk zoals het nu bestaat na deployment van de verschillende componenten de onderlinge verbindingen manueel moeten herverbinden in WebLogic workshop. Naast de componenten is er dan nog het LaboMonitor programma dat moet opgestart worden om triggers afkomstig van het labo naar het raamwerk te kunnen sturen. Als argument aan het programma moet men directory opgeven waar de triggerbestanden door een FTP-server zullen worden gedumpt. Alle behandelde triggers worden vervolgens in een subdirectory van de opgegeven directory bewaard voor eventuele latere referentie. A.2 Client De clientapplicatie is ontworpen met als doel het te kunnen installeren op een PDA. Recente PDA s hebben een scherm van 480 x 640 pixels. De grafische gebruikersinterface is daar op

88 A.2 Client 79 Figuur A.1: De console - JDBC Connection Pools afgesteld. Indien de client op een oudere generatie PDA s dient te worden geïnstalleerd zullen er kleine wijzigingen moet doorgevoerd worden aan de GUI klasse (zie 6.5.3) van de applicatie. De client kan op zowel de standaard JRE, CrEme als J9 van IBM gedraaid worden, beiden hebben hun voor- en nadelen. CrEme scoort bijvoorbeeld beter op het gebied van bandbreedte dan J9. J9 scoort beter op het verbruik van de batterij, maar de bandbreedte is significant lager dan bij CrEme. Op het gebied van processorgebruik is de gewone JRE de zwaarste JVM, J9 de lichtste en CrEme gebruikt al snel 80 procent van de processor (gemeten op PocketPC [11]). Naast het jar-bestand van de clientapplicatie moeten nog een aantal bijkomende bestanden in dezelfde directory komen te staan voor de ondersteuning van SWT. SWT maakt namelijk gebruik van een native library die gebruik maakt van het onderliggende besturingssysteem

89 A.2 Client 80 om zijn grafische componenten te tekenen. Het betreft de bestanden: javaw.exe.manifest, swt-awt-win dll, swt-win dll.

90 GEBRUIKERSHANDLEIDING 81 Bijlage B Gebruikershandleiding B.1 Client In wat volgt wordt een beknopte uitleg gegeven over de werking van de clientapplicatie voor het raamwerk. B.1.1 Berichten Het berichten venster toont de inhoud van een GenericMsgDocument. Zie figuur B.1 1. Bevat bericht type (ALARM of INFO) en het tijdstip waarop het bericht in gegenereerd. 2. Een lijst waarin een patiënt kan geselecteerd worden. Bij selectie van de patiënt wordt het eerste bericht geladen in het venster. 3. Deze knop laadt het bericht in dat het huidige bericht voorafgaat voor dezelfde patiënt. 4. Deze knop laadt het bericht in dat volgt op het huidig getoonde bericht van de geselecteerde patiënt. 5. Toont alle curves uit het ontvangen bericht samen met een kleurenlegende. 6. Bij selectie van een punt op de curve worden hier de coördinaten getoond. 7. Hier wordt de tekstboodschap getoond uit het ontvangen bericht. 8. Dit is een tabel van gegevens die opgenomen werden in het bericht. 9. Indien het bericht behandeld werd kan hierop worden geklikt zodat het niet langer in de lijst van berichten opgenomen wordt. Het is wel nog te bereiken via Overzicht.

91 B.1 Client 82 Figuur B.1: Het berichtenvenster 10. Deze knop springt naar een dringend bericht dat aan het huidig bericht vooraf gaat. Dit niet gebonden aan de huidige geselecteerde patiënt. 11. Deze knop springt naar een dringend bericht dat volgt op het huidig geselecteerd bericht. Niet gebonden aan de huidig geselecteerde patiënt. B.1.2 Inschrijvingen Het Inschrijvingvenster geeft een overzicht van nieuwe inschrijvingen en laat toe nieuwe inschrijvingen door te voeren. Zie figuur B.2

92 B.1 Client 83 Figuur B.2: Het Inschrijvingenvenster 1. Selecteer een patiënt uit de lijst. 2. Selecteer een agent uit de lijst. 3. De knop om de nieuwe inschrijving door te voeren. 4. Een overzicht van de volledige patiëntconfiguratie van de ingelogde arts. 5. Na het deselecteren van bepaalde rijen in het overzicht kan met deze knop de nieuwe configuratie worden doorgestuurd waardoor de gedeselecteerde inschrijvingen worden verwijderd.

93 B.1 Client Herladen van de configuratie zodat nieuwe patiënten en nieuwe agents in de selectielijsten worden toegevoegd. B.1.3 Commando s Het commandovenster geeft de configuratie weer van alle mogelijke commando s behorende bij alle agents en het laat toe commando s uit te voeren. Figuur B.3: Het Commandovenster 1. Selecteer een agent. 2. Selecteer één van de commando s behorende bij deze agent.

94 B.2 Systeembeheer Selecteer een patiënt waarop het commando moet worden uitgevoerd. 4. Toont een overzicht van de mogelijke parameter die met het commando kunnen worden meegegeven. In de Waarde-kolom kunnen de waarden waarden ingevoerd. 5. Toont een beschrijving van het geselecteerde commando. 6. De knop om het commando uit te voeren. B.1.4 Overzicht Het overzichtvenster geeft een overzicht van alle berichten, al dan niet behandeld, die werden ontvangen. Zie figuur B Selecteer een patiënt. 2. Dubbelklik op een rij om een bericht te laden in het Berichtenvenster. 3. Dubbelklik op de deleteknop om het bericht definitief te verwijderen uit de applicatie. B.2 Systeembeheer Voor deze thesis werd een demonstratieve website maakt dat kan dienen voor een systeembeheer portaal site. Zo bestaat er een centrale plaats voor het beheer van patiënten, artsen, inschrijvingen en dergelijke meer. Deze site kan gebruikt worden om de arts van bepaalde taken te verlossen zoals het beheer van inschrijvingen indien het over een groot aantal patiënten gaat. Deze site kan nog in grote mate uitgebreid worden afhankelijk van de noden van de artsen en de systeembeheerder. Een voorbeeld webpagine is te zien in figuur B.5. Deze website biedt eigenlijk enkel een interface aan naar de Web services aangeboden door de verschillende componenten. Men kan natuurlijk ook rechtstreeks de interfaces van de componenten gebruiken. Hieronder de links naar de verschillende consolesites, veronderstellend dat het volledige raamwerk werd geïnstalleerd op erato3. Communication Component: Subscription Component: Trigger Forwarder:

95 B.2 Systeembeheer 86 Figuur B.4: Het Overzichtvenster