Dialyse administration. Designdokument v Projekt-opgave i forbindelse med SKOS F2007

Transkript

1 Dialyse administration Designdokument v. 2.2 Projekt-opgave i forbindelse med SKOS F2007 Af: Birgitte Seierøe Pedersen, Claus Balslev og Christian Koerner Fag: SKOS F2007 Vejleder: Jakob E. Bardram 23. maj

2 INDHOLDSFORTEGNELSE Figurfortegnelse Opgaven Formål Rettelser til analysen Kvalitetsmål Teknisk platform Udstyr Basisprogramel Systemgrænseflade Arkitektur Komponentarkitektur Komponenter Struktur Klasser Person Article Ordination og OrdinationArticle Shift Seat Drawer OO til RDMS mapning ER-diagram Anbefalinger Systemets nytte Litteraturliste FIGURFORTEGNELSE Figur 1 Komponentarkitektur med angivelse af teknologier... 6 Figur 2 Klassediagram med attributter og operationer... 7 Figur 3 ER-diagram

3 1 OPGAVEN Denne opgave er udarbejdet som en del af kurset Systemer og Koncepter i foråret 2007 på Masterstudiet i SundhedsIT på IT Universitetet. Der anvendte metode er fra bogen Objekt Orienteret Analyse & Design 1. Denne rapport dækker design-fasen, og bygger på kapitel 16 i OOAD. 1.1 FORMÅL Denne opgave omhandler udvikling af et system til administration og planlægning af dialysebehandlinger og dialyseartikler på Hæmodialysecenteret på Sygehus Syd Nykøbing Falster - i daglig tale kaldt Dialysen. En større beskrivelse af baggrunden kan findes i den tilhørende analyserapport. 1.2 RETTELSER TIL ANALYSEN Der er fjernet en række klasser i forhold til analyse-delen. Baggrunden herfor beskrives i afsnit 4 under komponentarkitekturen. Derudover er der foretaget en simplificering af metoderne, idet vi har valgt at afgrænse os fra sikkerhedsfunktionerne og lognings-funktionerne som systemet ellers ville være underlagt, og som er beskrevet i Bekendtgørelse 528 fra Datatilsynet. Der er inkluderet en snitflade til et system med persondata, som anvendes i systemet til at berige databasen med stamdata. Det har været nødvendigt at gentænke relationerne mellem en ordination og den tilhørende skuffe og dens artikler. Dette er afspejlet i klassediagrammet i afsnit 4.1. Den oprindelige struktur kunne ikke sikre repræsentation af de korrekte data for artikler i skuffen for den enkelte patient. 1.3 KVALITETSMÅL Systemet er blevet vurderet efter nedenstående kriterier. Disse skal sikre, at designet tager hensyn til de rigtige kvalitetsmål. Brugbart Sikkert Effektivt Korrekt Pålideligt Vedligeholdbart Testbart Fleksibelt Forståeligt Genbrugbart Flytbart Integrerbart Meget vigtigt Vigtigt Mindre vigtigt Irrelevant Trivielt opfyldt 1 Mathiassen et al: Objekt Orienteret Analyse & Design (OOAD), 2001, Forlaget Marko 3

4 Det er essentielt at systemet er brugbart, korrekt og sikkert som værktøj. Systemet bruges som administrativt system til at tilrettelægge arbejdet. Derfor prioriteres brugbarheden. Da det også bruges til at styre, hvilke medicinske artikler, der anvendes til den enkelte patient, er det essentielt, at denne proces er sikker og korrekt. Som et system, der bruges af alle i en afdeling, er det vigtigt, at systemet er effektivt, pålideligt og forståeligt. Værdien af systemet vil blive målt i henhold til en mere sikker og effektiv behandling i forhold til den tidligere papir baserede form. Som mindre vigtigt, men ikke irrelevante, vurderes kriterierne testbart, fleksibelt, genbrugbart og integrerbart. Systemet er ikke særlig avanceret, og derfor er det ikke nødvendigt for store testmuligheder, men selvfølgelig skal pålidelighed, sikkerhed og korrekthed ikke lide under evt. manglende test. Men det vurderes ikke nødvendigt at have indbyggede tests i koden. Da systemet bruges i én bestemt proces er det ikke nødvendigt, at det er meget fleksibelt eller genbrugbart, da det vurderes som bedre at foretage en ny implementering, såfremt hele processen omkring dialysen ændres. Da integrationen er begrænset til én systemsnitflade til persondata er det ikke et af de væsentligste kvalitetsmål, men løsningen skal selvfølgelig stadigvæk kunne tilpasses en ny kontekst. 4

5 2 TEKNISK PLATFORM 2.1 UDSTYR Systemet fungerer i en klient-server opsætning. Klienter kan være stationære PC er, bærbare eller PDA, så længe disse kan anvende en webbrowser til at tilgå en webserver sikkert over et netværk. Trafik og load vurderes at være trivielt, da det er en webbaseret løsning med et stærkt begrænset antal brugere. Webserveren kan være en virtuel server, ligesom databasen kan sameksistere med andre databaser på en MySQL installation. 2.2 BASISPROGRAMEL Der forventes anvendt følgende programmer: Klient: Internet Explorer 6.0 eller nyere, Firefox 2.0 eller nyere Webserver: Apache server eller nyere Applikationsplatform: PHP eller nyere Databaseserver: MySQL eller nyere 2.3 SYSTEMGRÆNSEFLADE Der er etableret en systemgrænseflade til et patientsystem. Dette system kan nås over en HTTP-forpørgsel på URL en Denne PHP-side kan modtage en række URLparametre, herunder group, som i dette tilfælde er 4 og f.eks. cpr som f.eks En forespørgsel til vil således returnere følgende ML: <?xml version="1.0" encoding="iso "?> <patients> <patient id="38"> <cpr> </cpr> <firstname>ole</firstname> <lastname>olsen</lastname> <address> <street1>olegade 2</street1> <street2 /> <zip>2222</zip> <city>oleby</city> </address> <AuthNo /> </patient> </patients> I ovenstående er den basale model udvidet med AuthNo, som er autorisationsnummer for læger og sygeplejersker. 5

6 3 ARKITEKTUR Systemet anvender en standard tre-lags model med en grænseflade, et funktionslag og et modellag KOMPONENTARKITEKTUR Klient (Webbrowser) Brugergrænseflade (HTML) Server (Dialyse System) Persondata System Brugergrænseflade (PHP) Systemgrænseflade (ML) Systemgrænseflade (ML) Funktion (PHP) Funktion Model (SQL) Model Figur 1 Komponentarkitektur med angivelse af teknologier Grænsefladen er det, som i Dialyse-systemet flyttes til klienten, webrowseren. Brugergrænsefladen er implementeret i HTML og ved hjælp af skabeloner (PEAR Extended Integrated Templates 3 ). Der er ikke HTML andre steder end i skabelonerne, og man kan derfor videregive udarbejdelse af skabeloner til en grafisk designer, der ikke nødvendigvis kender PHP-teknologien. Funktionslaget indeholder funktionaliteten til at tilgå objekterne i modellaget og funktionaliteten for systemgrænsefladen. Funktionslaget indeholder også en række mere tekniske hjælpefunktioner til genereringen af brugergrænseflade. Funktionslaget er delt mellem de enkelte PHP-sider og et funktions-bibliotek, som indeholder de generelle funktioner, der ikke behøver at blive omskrevet i forhold til hver enkelt webside. I systemet betragtes modellaget som bestående af objekterne og databaselaget. Al databaseadgang sker fra objekterne. Funktionslaget kender ikke til databasen. Derved er al data indkapslet af objekterne. Model-laget kender intet til bruger- eller systemgrænsefladen, det gør alene funktionslaget. Kasserne i ovenstående kan betragtes som delkomponenter, men det bør bemærkes at Klient egentlig ikke udgør et delsystem, men er tegnet for at illustrere, at der findes et separat lag, som bedre kan udnyttes i fremtiden med yderligere funktionalitet, som f.eks. DHTML/AJA. 2 OOAD, afsnit 10.2 og Williams & Lane: Web Database Applications with PHP and MySQL (W&L). 2. udg., 2004, Forlaget O'Reilly, s

7 I forhold til arkitektur-mønstre anvendes en striks tredeling imellem grænseflade, funktion og model/data. I forhold til arkitektur-mønstre kan man ikke tale om en rigtig klient-server arkitektur, idet klient-laget ikke indeholder nogen funktionalitet. Der tilstræbes en lukket-streng arkitektur i implementeringen, hvor hvert lagt kun taler med det tilstødende lag, men man kan diskutere om tilgangen til Persondata Systemet er igennem et egentligt grænseflade lag og derved en lukket-løs arkitektur. 4 KOMPONENTER 4.1 STRUKTUR Person DBConnection Shift -shifttime : integer +setshifttime() +getshifttime() +getid() +getallshifts() Person::Patient +cpr : string -id +name : string -active : boolean +getname() +setname() +getactive() +setactive() +getcpr() +getallactive() Person::Doctor +authnum : string +getauthno() +setauthno() 1 Person::ServiceAssistant -db_uri : string -db_username : string -db_password : string -db_name : string -instances : integer -connection +getrow() +getrows() +getid() +setrow() +getinsertid() +close() 1 18 Seat -room : string -seattype : string -shiftid : integer +getid() +setroom() +getroom() +setseattype() +getseattype() +setshiftid() +getshiftid() +getseatsonshift() 1 1 Drawer -seatid : integer -drawerstatus : boolean -position : integer -wagon : integer -patientcpr : string +setdrawerstatus() +getdrawerstatus() +setposition() +getposition() +setwagon() +getwagon() +setpatientcpr() +getpatientcpr() +setseatid() +getseatid() +getalldrawers() 1 Person::Nurse 1 * 1 * Ordination -patientcpr : string -doctorcpr : string +setpatientcpr() +setdoctorcpr() +getpatientcpr() +getdoctorcpr() +getallordinations() +removebypatientcpr() OrdinationArticle -articleid : integer -ordinationid : integer +removearticle() +setarticleid() +getarticleid() +setordinationid() +getordinationid() +getarticlesbypatientcpr() +removeallbypatientcpr() * 2 Article -description : string -articletype : string +getid() +getdescription() +setdescription() +getarticletype() +setarticletype() +getarticlesbytype() Figur 2 Klassediagram med attributter og operationer Udover de klasser, som direkte kan henføres til anvendelsesområdet, så er der én ekstra teknisk klasse, DBConnection, som er implementeret som en singleton-klasse 4, dvs. at den altid begrænses til én instans i den enkelte proces. I forhold til analyserapporten er der udeladt tre klasser, Vogn, Dialysefilter og Dialysekoncentrat. Vogn er udeladt, idet den kunne indarbejdes i Drawer/Skuffe, og de to sidste kunne inkluderes i moder-klassen Article/Dialyseartikel. En række operationer er implementeret som statiske, dvs. de kan bruges uden at have en instans af objektet, og generelt er de anvendt til at returnere flere objekter af en given klasse, for eksempel Seat::getSeatsOnShift(). I ovenstående figur er de markeret med en understregning. 4 Lavin: Object-oriented PHP: concepts, techniques, and code. 2006, Forlaget No Starch Press, s. 96 7

8 4.2 KLASSER Den oprindelige kortlægning af klasserne i analysefasen havde en række oprettelser og sletninger eller aktiv/inaktiv attributter og operationer. I den konkrete implementering, som er gennemført i denne fase, arbejdes der generelt kun med aktive objekter, dvs. at alle oprettede objekter er aktive, og data slettes når de ikke er i anvendelse mere. Eneste undtagelse herfra er for Person-klasserne. En videre udbygning af systemet ville i højere grad implementere denne mulighed for at have objekter i aktive og inaktive stadier. Det ville også være mere korrekt i forhold til normal praksis i sundheds-systemer, der arbejder med patientdata og som skal kunne kvalitetsmåles PERSON Alle Person klasser har moderens metoder og attributter. Konstruktionen af et objekt gøres med attributten CPR som parameter, og såfremt denne ikke findes i systemet i forvejen, fremtvinges et kald til det eksterne system med persondata. Doctor og Nurse adskiller sig ved at inkludere et autorisationsnummer. Der er generelt Set og Get metoder, dog ikke for ID og Set for CPR, idet det kommer fra instanceringen af klassen til et objekt ARTICLE Article indeholder de forskellige artikler, som anvendes. Der er Set og Get operationer for alle attributter. Derudover er der operationen getarticlesbytype(), som tager parameteren articletype som string, og returnerer et array med alle objekter af den angivne artikeltype ORDINATION OG ORDINATIONARTICLE Ordination er knyttet til Article over OrdinationArticle hjælpe-klassen, som dog har nogle selvstændige metoder. Ordination indeholder attributten doctorcpr der lænker til den læge, som har ordineret, og patientcpr, som lænker til den modtagende patient. Hjælpeklassen OrdinationArticle beskriver, hvilke artikler, der indgår i ordinationen. Når man opdaterer en ordination sletter man først de tildelte artikler med operationen removeallbypatientcpr(). Derudover er der en metode til at finde alle artikler for en given patient: getarticlesbypatientcpr(), og til sidst forefindes de sædvanlige Set og Get for de resterende attributter SHIFT En patient kan være på et eller flere af de fire hold/shift, der kører ugentligt på Dialysen SEAT Hvert hold/shift har 18 pladser/seats. Der er et objekt for hver plads på hvert hold, dvs. i alt 4 gange 18 pladser, og derved 72 objekter af klassen seat. 8

9 4.2.6 DRAWER Drawer relaterer sig én til én med Seat. Man kunne godt slå denne klasse sammen med seat, men for logikkens skyld er de adskilt. Drawer har en lænke til ordinationen med patientens CPR, og indeholder ID for pladsen. Drawer er i forbindelse med visning af fremstillingslisten omdrejningspunkt. Når en ordination skal knyttes til en plads på et hold, så gøres det over skuffen. 4.3 OO TIL RDMS MAPNING Der er foretaget en direkte mapning af klasserne til en SQL database. Mapningen er generelt således, at en klasse ejer en tabel af samme navn, og alle attributter, inklusiv ID, er felter i denne tabel. Hvert objekt bliver til en række i tabellen med objektets data. Person-klassen er markeret, men ikke som tabel, da den er abstrakt, dvs. kan ikke have sine egne objekter. Kun de nedarvende klasser (Patient, Doctor, Nurse og ServiceAssistent) er gemt som data i tabeller ER-DIAGRAM Data skal tilgås igennem objekterne, men for at kunne forstå mapningen til RDMS fra klasserne er der udarbejdet et ER-diagram. Figur 3 ER-diagram Tabellen ordinationarticle er en relations-tabel der lænker ordination og article. Sidstnævnte indeholder ud over de lænkende klassers nøgler (Foreign Keys) også sit eget ID-nummer for bedre at kunne understøtte operationerne på enkelt række-niveau, dvs. objekt-niveau. Igen her ses, at man kunne have lagt seat / drawer og patient / ordination sammen i hhv. hver deres tabel, da de to par er relateret 1:1. Men for at følge objekt-strukturen og for overblikkets skyld er tabellerne adskilt. Derved holdes forbindelsen til anvendelsesområdet. En udbygning af systemet vil derudover kunne medføre, at relationen mellem patient og ordination ændrer sig til en 1:n relation, hvor en patient kan have en aktiv og flere inaktive ordinationer. På samme måde kan relationen mellem drawer og seat muligvis ændre sig i fremtiden. 9

10 5 ANBEFALINGER 5.1 SYSTEMETS NYTTE Systemet hjælper med at sikre, at behandlingen foregår korrekt og effektivt, samt understøttende i forhold til det tidligere LEAN-projekt på afdelingen. Det gør det ved at give en mindre besparelse i arbejdstid i forbindelse med de administrative processer for Dialysen, dvs. produktion af fremstillingslister, kontrol af skuffer og tildeling af pladser på et hold. Systemet kvalitetssikrer også arbejdsgangene, og giver en sikring af, at den rette patient får den rette ordination. Risikoen for transskriptionsfejl ved overføring af data på papir bliver mindre, og muligheden for at ordinationen ikke følger patienten ved flytning af patienter fra en plads til en anden er minimeret, da systemet forholder sig til at ordinationen følger patienten. Systemet skulle derved øge kvaliteten for patientbehandlingen i Dialysen på Sygehus Syd i Region Sjælland. 6 LITTERATURLISTE Lavin, P. 2006: Object-oriented PHP: concepts, techniques, and code, No Starch Press Mathiassen, L. et al 2001: Objektorienteret analyse & design, Forlaget Marko, 3. udgave Williams, H.E. & Lane, D. 2004: Web Database Applications with PHP and MySQL, O'Reilly Media, 2. udgave 10