LEVERANSE 2 <PROJECT HOSPITAL 2005>

Transkript

1 LEVERANSE 2 <PROJECT HOSPITAL 2005> VERSJON: LEVERANSE 2. Gruppe 46 - Team Innovation Leveranse 2 2. versjon Gruppemedlemmer: Nam Duc Pham... namdp@ifi.uio.no Tofik Sahraoui...tofiksa@ifi.uio.no Cuong van Truong...cuongvt@ifi.uio.no Tor Øyvind Fluør... torof@ifi.uio.no Dagfinn Forsaa Andersen... dagfina@ifi.uio.no Dato for ferdigstillelse: 6/0 2005

2 Innhold: Revisjonsoversikt... 3 Oppdragsgivers krav og tekniske konsekvenser... 4 Use case diagram... 5 Beskrivelse av aktører... 6 Beskrivelse av use case... 7 Domenemodell... 0 Beskrivelse av ikke-funksjonelle krav... Klassediagram... 3 Arkitekturdesign... 4

3 Revisjonsoversikt Versjon Ansvarlige Forklaring av versjon Dato Avsluttet Utkast 2.0 Alle utkast for gruppens inspeksjon Leveranse 2.0 Tor Øyvind Versjon godkjent for levering Utkast 2. Alle utkast for gruppens inspeksjon Leveranse 2. Tor Øyvind Oppdatert usecasebeskrivelsene Oppdatert domenemodell Oppdatert beskrivelse ikke funksjonelle krav Oppdatert umldiagram Oppdatert arkitekturdesign

4 Oppdragsgivers krav og tekniske konsekvenser Spesifikasjonen er svært mangelfull for hvordan det nye Project Hospital 2005 skal forholde seg til eksisterende systemer og rutiner. Her noen av områdene som kunne vært dekket: Allokering av personell, rom og tid En sentral del av Project Hospital 2005 er å allokere personell og deres tidsbruk. Systemet vi skal designe dekker bare allokering av personell til operasjoner. Det nye systemet må derfor forholde seg til eksisterende systemer og rutiner. Vi antar at det allerede finnes system(er) som har oversikt over turnusplaner, vaktlister, ferier, møter osv. Ved registrering og endring av operasjoner må vi ha tilgang til oppdatert informasjon om en persons tilgjengelighet for en gitt periode. Project Hospital 2005 må også kunne oppdatere eller melde til andre systemer når personell allokeres og de-allokeres for operasjoner. Eventuelle endringer fra eksterne systemer må også meldes til det nye systemet. Det samme kan være tilfelle med allokering av rom hvis det finnes et system som holder orden om de enkelte rom. Det vil si åpningstider, når rom er stengt på grunn av rengjøring vedlikehold med mer. Sikkerhet Det er krav om Password security system for employees. Vi har antydet en svært enkel løsning som en del av Project Hospital Det bør undersøkes om eksisterende brukerdatabaser kan benyttes og integreres. Dette vil oss en enklere løsning, gi Health Care mindre ajourhold og enklere rutiner for brukeradministrasjon. Pasientjournal og kostnadsavregning Project Hospital 2005 generer pasienthistorikk for operasjonene. Disse dataene bør leveres videre til et pasientdokumentasjonsystem. Det beregnes også kostnader for oppholdet. Hva som skal skje videre med dette beløpet sier spesifikasjonen ingen ting om, men også her er sannsynlig at dataene bør videre til andre systemer, e.g. fakturasystem, trygdesystem.

5 USE CASE DIAGRAM Check in Patient include Put Patient on Waiting List extend Register Patient Receptionist extend View Patient info Modify a Patient Check Out Patient Doctor Operation Cancellation Admin View Operation list Nurses extend Schedule operation Modify Scheduled Operation include include Check Doctor Availability extend include Notify Doctors and Nurses Check Nurses Availability Check Room Availability Diagram: /corporate/inf320p46/usecases:/systemdesign/klassediagram/usercaseleggpasient.ucd: Status: working Changed: Fri Oct 4 3:24:53 W. Europe Daylight Time 2005 Page: of

6 Beskrivelse av aktører Aktør Beskrivelse Eksempler Aktør Beskrivelse Eksempler Aktør Beskrivelse Eksempler Aktør Beskrivelse Eksempler Resepsjonist. To person fra de fem administrative personene. Ansatt som resepsjonist fra rekrutterte selskaper. Ta imot bestilling, registrere ankomst og kanselleringer. Sykepleie En person som er ansatt i sykehuset. Det er i alt 30 sykepleier ved sykehuset. Hente pasient til operasjonsrom, assistere legen og pleier pasienten. Har tilgang til pasientens informasjoner og rapporter. Lege En person som er ansatt i sykehuset. Legen er spesialisert i et område og har ansvar for medisiner til pasienter. Opererer. Har tilgang til å se pasientens informasjoner og rapporter. Administrasjonen. Administrative personer som er ansatt i sykehuset. Der av 2 av dem er ansatt som resepsjonist av rekrutterte selskaper. Sette sammen en gruppe til operasjon. Har tilgang til det meste i systemet.

7 Use case View patient info. Aktør Receptionist, Nurse, Doctor, Admin. Trigger Aktøren ønsker å se pasient informasjon. Pre-betingelser Pasienten må være registrert. Post-betingelser Aktøren få se pasient informasjon. Normal hendelsesflyt. Systemet ber om pasient id eller navn. 2. Aktøren oppgir nødvendige informasjoner. 3. Systemet validerer input data. 4. Aktøren få se all informasjon til pasient. Variasjoner.0 Pasienten ikke eksisterer i databasen.. Ber Aktøren om å oppgi ny input data. 2.0 Feil input data 2. Ber Aktøren om å oppgi ny input data. Relatert informasjon Use case Put patient on waiting list Aktør Receptionist Trigger Aktøren har fått beskjed om å legge inn pasienter i venteliste Pre-betingelser Pasient må være registrert, venteliste må eksistere. Post-betingelser Pasient blir lagt inn på venteliste, venteliste blir oppdatert. Normal hendelsesflyt. System ber om pasient id, varighet, behandling, prioritets kø. 2. Aktør oppgi nødvendige data. 3. Systemet validerer innkomne data. 4. Systemet ber aktør om godkjenning av data. 5. Pasient blir lagt i venteliste, venteliste oppdateres. Variasjoner.0 Feil input data. Oppgi nødvendige data på nytt. 2.0 Aktør kansellerer ved godkjenning av data. 2. Oppgi nødvendige data på nytt. Relatert informasjon

8 Use case Check Doctor Availability. Aktør Receptionist, Admin. Trigger Aktøren vil se status til legen. Pre-betingelser Legen må eksistere på ansatt listen. Post-betingelser Aktøren får ser statusen til legen. Normal hendelsesflyt. System ber om lege id og dato. 2. Aktør oppgi nødvendige data. 3. Systemet validerer innkomne data. 4. Systemet viser status til legen. Variasjoner.0 Feil input data. Oppgi nødvendige data på nytt. Relatert informasjon Use case Schedule operation. Aktør Admin. Trigger Aktøren ønsker å sette sammen en operasjon. Pre-betingelser Leger, sykepleier og rommene ved den avdelingen må være ledig den datoen. Pasienten er registrert. Post-betingelser Leger og sykepleier timelistene blir oppdatert. Status operasjonsrom og hvile rom blir endret ved den datoen. Pasient info blir oppdatert. Operasjonen blir lagt i lista. Normal hendelsesflyt. Aktøren oppgir tidspunkt og typebehandling til operasjon skal foregå. 2.0 Systemet: lister opp tilgjengelig sykepleier ved den avdelingen. 2. Include usercase Check Doctor Availability ved den avdelingen. 2.2 Lister opp ledig operasjonsrom ved den avdelingen. 2.3 Lister opp ledig hvile rom ved den avdelingen. 2.4 Henter ut første prioritert pasient i pasient venteliste. 3. Aktøren velger nødvendige personal og resurser til operasjonen. 4. Systemet ber aktøren om godkjenning av data. 5. Operasjonen blir opprettet og lagret. Variasjoner.0 Feil input data.. Aktør må legge ny input data. 2.0 Aktør kansellerer ved godkjenning av data. 2. Aktør må legge ny input data. 3.0 Ingen tilgjengelig personal/resurser i den oppgitt tidspunktet. 3. Aktør må oppgi ny tidspunkt. Relatert informasjon

9 Use case Operation Cancellation. Aktør Receptionist, Admin. Trigger Aktøren ønsker å kansellere en operasjon. Pre-betingelser Operasjonen må eksistere i operasjonslisten. Post-betingelser Timerlister til sykepleier og leger blir oppdatert. Status på operasjonsrom og hvile rom blir endret. Pasient ventelister blir oppdatert. Operasjonen blir slettet fra operasjonslisten. Operasjonslisten blir oppdatert. Normal hendelsesflyt. Systemet ber om meeting number. 2. Aktøren må oppgi et meeting number. 3. Systemet validere data. 4. System ber om godkjenning. 5. Operasjon blir kansellert. Variasjoner.0 Feil input data.. Oppgi meeting number på nytt. 2.0 Aktøren kansellerer ved godkjenning av data. 2. Oppgi meeting number på nytt. Relatert informasjon

10 Room roomnumber maxbed Bed bednumber 0.. Hospital name costprday Waitingroom RecoveryRoom BedCalendar StaffCalender Ward OperatingRoom name wardnr roomnumber Staff staffid name adress phonenumber pagernumber Operation meetingnumber startdatetime Nurse Doctor TreatmentType WaitingList specialization name description operationduration numberofdoctors numberofnurses recoveryduration priority indate queuenumber PatientJournal fromdate todate cost Patient patientid name address phonenumber 0.. Diagram: /corporate/inf320p46/usecases:/analysis/domenemodell/domenemodell.cad: Status: working Changed: Sun Oct 6 2:5:5 W. Europe Daylight Time 2005 Page: of

11 Beskrivelse av ikke-funksjonelle krav Systemet som helhet Det første og kanskje viktigste kravet for systemet skal være pålitelighet. Systemet skal gi pålitelig skedulering av operasjoner og det skal gi brukerne en trygghet om at de dataene som er lagret i systemet er riktige. Det er viktig at man gjør overgangen fra tidligere systemer så enkel som mulig. Dette kan gjøres ved at systemet er logisk byget opp og at kommandoene som brukes er enkle å forstå. Systemet skal være så bra at det gir brukerne økt selvtillit i arbeidet de utfører og det skal skape en trygghet på arbeidsplassen. Generelt skal det gjøre hverdagen på sykehuset enklere og mer strukturert. Brukergrensesnittet Brukergrensesnittet skal være enkelt men samtidig raskt å bruke. Det er viktig at brukerne blir raskt fortrolig med systemet. Dette kan gjøres ved å gjøre utseende og følelsen av systemet likt andre systemer de ansatte er vant med. Brukergrensesnittet skal være klart og konsist slik at brukeren aldri er i tvil om hva en funksjonalitet gjør. Det er også viktig at systemet legger til rette for avanserte brukere slik at disse kan arbeide effektivt. Sikkerhet Sikkerhet er en et viktig krav når man skal lage et system som inneholde sensitive opplysninger. Det er viktig at slike opplysninger ikke kan leses av uautorisert personell. Løsninger i forbindelse med de ikke-funksjonelle kravene Pålitelighet Pålitelighet kan ses på som to ting. Det første er at systemet er stabilt og oppfører seg som forventet. Det andre er at man kan stole på den informasjonen man finner i systemet. For å sikre stabilitet vil vi sørge for at systemet er tilstrekkelig testet. Det gjelder brukertesting, men også ved automastiske tester av funksjonalitet. Systemet må også kjøre på en plattform (både maskinvare og programvare) som er stabil. For å sikre tillit til data vil vi legge inn en rekke syntaktisk sjekker som kontrollerer den informasjonen brukerne legger inn i systemet. Det trengs også en løsning for å sikre at to personer ikke oppdaterer samme dokument samtidig. Vi vil lage systemet slik at når et dokument blir oppdater så låses det slik at ingen andre enn en bruker av gangen kan oppdatere et dokument. Brukergrensesnitt Det vil være viktig at både nybegynnere og avanserte brukere kan bruke systemet effektivt. For at nybegynnere skal komme raskt i gang vil vi forsøke å lage en så logisk oppbygning på systemet som mulig. Hjelpetekster vil være tilgjengelig på hvert steg og brukerdokumentasjonen skal være bygget opp slik at den leder brukeren steg for steg igjennom forskjellige oppgaver i systemet. For avanserte brukere vil i tilby snarveier og hurtigtaster som gjøre systemet raskt å bruke.

12 Sikkerhet Sikkerhet er viktig. Hver bruker vil derfor få et eget brukernavn og passord til systemet. Systemet vil føre log over alle aktivitetene de forskjellige brukerne foretar seg. I viktige dokumenter som journaler og lignende vil ingen av de daglige brukerne ha mulighet til å slette informasjon. I dokumenter som er mindre kritiske vil brukere har rettigheter til å slette, men systemet vil huske de slettede dataene og de vil kunne bli hentet frem av en systemadministrator. Det er også viktig at uvedkommende ikke kan logge seg inn i systemet. Vi foreslår derfor at systemet blir kjørende på et nett som er fysisk avskilt fra andre systemer og nett, spesielt internett.

13 Authenticator -userid : String -password : Password -role : String -lastlogin : DateTime +adduser() +deluser() +changeuser() +changepassword() authenticates users in Hospital +name : String +costprday : Unsigned int contains Waitingroom Room +roomnumber : Unsigned int #maxbed : Unsigned int +addbed() +removebed() +avaliablebeds() RecoveryRoom contains Bed +bednumber : Unsigned int +ChangeInfo() +DisplayInfo() Has 0.. contains has UserInterface +scheduleoperation() +check-inpatient() +check-outpatient() ReportGenerator +operationroom() +employees() +dailypatients() +patient() +bedavailability() +roomavailability() +staffdailyschedule() +staffweeklyschedule() +staffmonthlyschedule() +stafflist() +staffon-calllist() +patientlist() StaffCalender +checkifavalable() +createbooking() +removebooking() has Nurse contain Ward OperatingRoom contains +name : String +roomnumber : Unsigned int +wardnumber : Unsigned int +addstaff() +removestaff() +addroom() +removeroom() Staff #staffid : Unsigned int #name : String #adress : String #phonenumber : Unsigned int #pagernumber : Unsigned int +changeinfo() +displayinfo() Doctor +specialization : String PatientJournal +fromdate : Date +todate : Date +cost : Unsigned int Performes Assists in works in has is performed in Operation +meetingnumber : Unsigned int +startdatetime : DateTime +adddoctor() +removedoctor() +addnurse() +removenurse() has Patient lays in 0.. -patientid : Unsigned int -name : String -address : String +displayinfo() +changeinfo() BedCalendar +checkifavalable() +createbooking() +removebooking() is of type is listed in TreatmentType +name : String +description : String +operationduration : Time +numberofdoctors : Unsigned int +numberofnurses : Unsigned int +recoveryduration : Time is of type WaitingList -priority : Int -indate : Date -queuenumber : Unsigned int -phonenumber : Unsigned int +addpatient() +removepatient() +poppatient() +displaylist() Diagram: /corporate/inf320p46/usecases:/systemdesign/klassediagram/umlklassediagram.cad: Status: working Changed: Sun Oct 6 2:50:08 W. Europe Daylight Time 2005 Page: of

14