PLO - Patientjournalsystem Projektkursus Systemudvikling juni 2011

Transkript

1 PLO - Patientjournalsystem Projektkursus Systemudvikling juni 2011

2 Indhold 1 IT-projektet Skematisk oversigt over gruppens projektforløb Tre centrale fænomener fra problemområdet Anvendelsesområdet Brug Den endelige model for IT-systemet Brugergrænseaden Programdokumentationen Interessant del af implementationsarbejdet Samarbejdet med brugerne og i projektgruppen Forholdet mellem parterne i projektet Samarbejdet internt i projektgruppen Reeksion over resultat og forløb af IT-projektet Styrker og svagheder ved tilrettelæggelsen af projektforløbet Forslag til forbedringer af processen Diskussion af [Michael Christensen m.., 1998] Artiklens tilgang til systemudviklingen Ligheder og forskelle mellem artiklen og kursuslitteraturen Litteratur 15 A Formål 16 A.1 Systemdenition A.2 Kravspecikation for IT-løsningen B Problemområdet 18 B.1 Struktur B.2 Klasser C Anvendelsesområdet 19 C.1 Brug C.2 Funktioner C.2.1 Specikation af komplekse funktioner C.3 Brugergrænseaden C.3.1 Dialogform C.3.2 Oversigt C.3.3 Eksempler C.4 Den tekniske platform

3 D Anbefalinger 26 D.1 Nytte og realiserbarhed D.2 Strategi D.3 Økonomi E Kvalitetsmål 27 F Teknisk platform 29 F.1 Udstyr F.2 Basisprogrammel F.3 Systemgrænseader F.4 Designsprog G Arkitektur 29 G.1 Komponentarkitektur G.2 Procesarkitektur H Referater 31

4 Terminologi PLO Praktiserende Lægers Organisation 1. Vores kunde i dette projekt. FNUX Fælles Nationalt Udvekslingsformat i XML 2. Ny journal-format standard. IC-10 International Classication of Diseases 3. ICD-10 er et system til klassikation af sygdomme og andre helbredsrelaterede lidelser udformet af verdenssundhedsorganisationen WHO. 1 Læs mere om PLO på: 2 Læs mere om FNUX standarten på: 3 Læs mere om IC-10 standarten på: 1

5 1 IT-projektet Nedenstående afsnit handler om projektkursets produkt, et patientjournalsystem vi har udviklet. 1.1 Skematisk oversigt over gruppens projektforløb Herunder ses en grask oversigt over projektets forløb. Da det er svært præcist at angive hvornår eksempeltvis analyse- eller designfasen indledes og endes, er skemaet nedenfor en grov repræsentation af det egentlige forløb. Dog har møder og evalueringer eksakte datomærkninger. Dato Emne Kontakt med kunde indledes Første møde med kunden Andet møde med kunden Analyse Første Første prototypeevaluering med kunden Udvidede brugergrænseade vises og gennemgås med kunden. Design prototype Anden prototype Figur 1: Oversigt over projektets forløb. Udviklingsprocessen har fulgt en rimelig sekventiel strategi; analyse, design og implementation (vist ved færdige protoyper). Analysen overlapper designfasen en smule, idét designfasen naturligt gav anledning til rettelser af analysen. Møder og evalueringer med kunden blev placeret efter behov; enten ved opklarende spørgsmål og kooperativ deltagelse i analysen, eller ved fremvisning af prototyper. 2

6 1.2 Tre centrale fænomener fra problemområdet Herunder beskrives tre centrale fænomener fra problemområdet; læge, patient og journal. Selvom disse ikke udgør det komplette problemområde, er disse de tre helt centrale. Hændelser og adfærd for disse fænomener beskrives også i dette afsnit, idét de er resultatet af analysen af problemområdet, der er foregået før analysen af anvendelsesområdet. Adfærdsmønstre er beskrevet som regulære udtryk jf. [L. Mathiassen m.., 2001] side 93. Læge En læge har et læge-id og en række patienter. Hændelser Tildelt patient Adfærd Adfærd er triviel for læge, idét objektet ikke bemærkelsesværdigt skifter tilstand i systemet. Læge kan tildeles patienter, men vi medtager ikke en læges daglige rutiner i dette system, da fokusområdet er patienters journaler. Patient En patient hører til en eller ere læger, og har en række personlige oplysninger (cprnummer, adresse mv.) og en journal. Hændelser Patient oprettet Patient identiceret Stamoplysninger opdateret Adfærd (Patient oprettet Patient identiceret) + Stamoplysninger opdateret* Journal En journal tilhører en patient, og indholder dennes medicinske historik. Hændelser Journal oprettet Tilføjet indhold Eksporteret til FNUX-format. Adfærd Journal oprettet + Tilføjet indhold* + Eksporteret til FNUX-format* 3

7 1.3 Anvendelsesområdet Systemet skal anvendes af praktiserende læger og deres sekretærer, og skal primært anvendes i den praktiserende læges klinik. I princippet kan systemet dog bruges hvor end det skulle være, så længe klienten er installeret og der er en fungerende internetforbindelse. Analysen af anvendelsesområdet er udført efter en analyse af problemområdet, for at fokusere på det, som brugerne arbejder med, og for derefter at opnå bevidsthed om systemets krav til brug gennem en analyse af anvendelsesområdet. Læger og sekretærer har samme funktionalitet til rådighed i systemet, og er derfor begge repræsenteret under aktøren læger Brug I systemet ndes to aktører; læge, som redigerer i patienters information og deres journaler, og FNUX-parser. FNUX-parseren er en del af IT-systemet, der kan importere og eksportere patientjournaler i journalformatet FNUX. Ved en udvidelse af systemets kernemål, foreslået ved gur I (bilag), udvides aktører til patienter, der kan få vist deres journal i en webbrowser. Nedenfor vises aktørernes brugsmønstre. Læge ˆ Oprette patient ˆ Finde patient ˆ Redigere patientoplysninger ˆ Tilføje indhold til journal ˆ Ændre journalprivilegier FNUX-parser ˆ Importere journall i FNUX-format. ˆ Eksportere journall i FNUX-format. Nedenfor er to brugssmønstre beskrevet ved brugsmønsterspecikation. Det beskrives hvorledes systemet håndterer en læges registreringer af diagnoser på en patients journal, og hvordan en journall i FNUX-format importeres i systemet. Tilføj indhold til journal Tilføjelse af indhold igangsættes af lægen, ved at vedkommende i systemet vælger den funktion, der passer til det indhold, der skal registreres i journal efter, at den patient, hvis journal skal have indhold registreret, er valgt. Lægen bliver af systemet anmodet om, at udfylde en række oplysninger i et skema omkring tilføjelsen, alt efter hvilken er valgt. Efter dette er gjort er journalen opdateret med det nye indhold. Det registreres også, hvilken læge der har tilføjet indhold. Objekter: Journal, Sygdom. Funktioner: Diagnose-registrering, Henvisnings-registrering, Konsultationsregistrering Figur 2: Brugsmønsterspecikation for tilføjelse af indhold til journal 4

8 Importere FNUX-format Importering af journall i FNUX-format kan entet ske ved oprettelsen af en patient, eller ved at vælge funktionen, efter at en patient er valgt. Under alle omstændigheder, er det lægen der vælger at importere en ekstern journall. FNUX-parseren parser indholdet af len, og registrerer journalen under den valgte patient, hvis importen blev udført uden fejl. Ellers giver systemet en fejlmeddelelse. Objekter: Journal, Sygdom, Patient. Funktioner: FNUX-importering Figur 3: Brugsmønsterspecikation for importering af l i FNUX-format 1.4 Den endelige model for IT-systemet Nedenfor listes og beskrives systemets klasser, samt deres forhold. Hændelser og adfærd for de mest interessante kan ndes i afsnit 1.2. Patient Patient har attributterne CPR-nr., navn, adresse og praktiserende læge. CPR-nr. bruges til at identicere patiententen. Læge En læge har et login i form af brugernavn og password, og så har en læge et antal patienter som han/hun har adgang til, og dermed deres journaler. Journal En journal indeholder alle oplysninger om en patients medicinske historik, og tilhører desuden en patient. En patient kan maksimum have én journal, og en journal kan kun tilhøre én patient. Sygdom Sygdom indeholder information omkring en sygdom. Sygdomme identiceres ved en IC- 10 kode, og har dertilhørende specikke informationer. Sygdomme tilhører journaler, og kan optræde ere gange på ere journaler. Struktur Herunder vises klassediagrammet, hvor klassernes forhold imellem ses i associeringsstruktur. Med et fast deneret klassediagram undgås ansvarsinteferens, og udviklingsarbejdet kan trygt fortsættes. Man kunne også have valgt, at lave en 'Ansat'-klasse, hvorfra læge og sekretær kunne nedarve. Da sekretærer og læger i systemet har samme funktionalitet til rådighed, har vi for at holde klassediagrammet simpelt, samlet disse i klassen Læge. 5

9 Læge 0..* 0..* Patient Journal 0..* 0..* Sygdom Figur 4: Klassediagram. En læge kan have ere patienter, og en patient kan have ere læger. En journal kan tilhøre én patient, og en patient kan have max én journal. En sygdom kan tilhøre mange journaler, og en journal kan indeholde mange sygdomme. 1.5 Brugergrænseaden Patientjournalsystemet er et system til håndtering af mange patienters data. Systemet skal ikke bruges til varierende, problemløsende opgaver - men i et større omfang velstrukturerede rutineopgaver; nedskrivning af diagnoser, henvisninger, konsultationer mv. For bedst muligt at designe en brugergrænseade, der passer til de situationer systemet skal bruges til, har vi valgt at lave det udtryk, der er mest eektivt og pålideligt. Designet er ensartet og professionelt, og det graske udtryk er minimalt. I øvrigt benytter implementationen operativsystemets gængse graske brugergrænseades udtryk. Brugergrænseaden er designet ud fra tesen 'ensartedhed fremmer klarhed og forståelighed'. Systemets funktioner forendes i kategoriserede menuer, for at give brugeren øjeblikkeligt overblik over systemets muligheder inden for et givent område. Da lægen ofte skal indtaste meget information til systemet (eksempeltvis ved en diagnose), er der for overblikkets skyld valgt skemaudfyldninger til dette, som argumenteret i [Weile and Trætteberg, 2000], side 11. Foruden vores egen analyse af brugergrænseaden, er kunden medtaget i processen for at sikre, at udseende af systemet passede ind i brugernes arbejdsgang. Generally speaking, each pattern that focuses on the user perspective is also usable for designers but not vice versa. Therefore, our patterns should benet both designers and end users 4 Som citatet fastlægger det, er et design, der er nyttigt for udvikleren, ikke nødvendigvis brugbart for brugeren. Ved at medtage brugeren i fastlæggelsen af brugergrænseaden, øger vi ikke blot brugervenligheden, men også brugbarheden. 4 [Weile and Trætteberg, 2000], side 1, linie 7-8 6

10 Skema- og menueksempler ses herunder ved hhv. startsiden (søgning og oprettelse af patient) og menuen på patientsiden (ere funktioner). Figur 5: Startsiden. På startsiden kan brugeren vælge mellem at oprette en ny patient, eller søge efter en eksisterende. Figur 6: Patientsiden. På patientsiden ndes alle funktionerne omhandlende patientens data og patientjournalen. Disse ndes i de respektive menuer. Navigeringen rundt i systemet er relativ simpel, idét den er begrænset til opdatering, redigering, eksportering eller oprettelse af patienter og patientjournaler. Menuvalg opstår ved ere resultater ved søgning, samt dialogbokse med fejl eller godkendelser. Navigeringsdiagrammet er derfor som ses på gur XI (bilag). I bilagene ndes ere skærmbilleder og hertil forklarende tekst. 7

11 Figur 7: Navigeringsdiagram. Systemet initialiseres ved loginskærmen, der viderefører brugeren til en starside. Fra denne vælges en patient, eller denne oprettes. Herfra ndes de egentlige patient- og journalfunktioner, der åbnes i til formålet byggede dialogbokse. 1.6 Programdokumentationen Her gives en oversigt over dokumentationen, som forstået ved [L. Mathiassen m.., 2001] kapitel 16. Der refereres til de relevante afsnit, vedlagt som bilag til rapporten. Dokumentation Overskrift Afsnit Side Formål A 16 Systemdenition A.1 17 Problemområdet B 18 Anvendelsesområdet C 19 Anbefalinger D 26 Kvalitetsmål E 27 Teknisk platform F 29 Arkitektur G 29 Dokumentationen skaber både overblik og specicerer detaljer i systemudviklingen. Selvom de to begreber kan lyde modstræbende, giver dokumentationen, som præsenteret ved tabellen ovenfor og detaljebeskrivelse ved dets referencer i bilagene, uddybende beskrivelser, der kan bruges til at holde overordnet styr på systemudviklingen, såvel 8

12 som sikring af udvklingen udmunder i det system, der er aftalt med kunden. Dertil kan dokumentationen bruges til at holde delresultater op i mod. 1.7 Interessant del af implementationsarbejdet Systemet bygger på Model View Control (MVC) arkitekturen. Det vil sige, at vi har et view, som er den graske brugergrænseade, en model, som indeholder alle systemets funktioner og logik, og en controller som håndterer forbindelsen mellem model og view via observers 5. I og med systemet skal hente data fra en MySQL database, har vi et yderligere komponent, som ligger et lag under vores model. Dette komponent fungerer som grænseade til databasen. Dette kan lade sig gøre i praksis, ved brug af observers som er implementeret i Java. Nedenfor vises et udsnit af Patient klassen, som eksempel på vores implementering af MVC-artitektur i Java. 1 package model. patient ; 2 3 import java. util. HashMap ; 4 import java. util. Observable ; /* * 9 * P a t i e n t c l a s s 10 * 11 <Removed> 12 * 13 1, * 15 */ 16 p u b l i c c l a s s Patient e x t e n d s Observable { p u b l i c v o i d getdatahash ( ) { HashMap<String, String> datahash = new HashMap<String, String >() ; datahash. put ( "CPR", t h i s. CPR ) ; 25 datahash. put ( " Fornavn ", t h i s. firstname ) ; 26 datahash. put ( " E f t e r n a v n ", t h i s. lastname ) ; 27 datahash. put ( " Adresse ", t h i s. address ) ; 28 datahash. put ( " Postnr. ", t h i s. zip ) ; 29 datahash. put ( "By", t h i s. city ) ; 30 datahash. put ( " T l f. ", t h i s. phone ) ; 31 datahash. put ( " ", t h i s. ) ; setchanged ( ) ; 34 notifyobservers ( new PatientEvent ( PatientEvent. EVENT_PATIENT_INFO, datahash ) ) ; } Figur 8: Udnsit af klassen Patient i Java-kode, som illustrerer MVC-arkitekturen ved brug af javas Observable-klasse. 5 Observers, eller Observer pattern, er et software design mønster hvor et objekt giver bedsked til sine observers hver gang der sker en ændring. 9

13 Patientklassen nedarver fra Java-bibliotekets klasse Oberservable. Ved at bruge oberservers til at sende informationer om objektopdateringer mellem vores model og view, opnås den føromtalte MVC-arkitektur. 2 Samarbejdet med brugerne og i projektgruppen Herunder beskrives samarbejdet med kunden og internt i projektgruppen. 2.1 Forholdet mellem parterne i projektet Vi har haft kontakt med to forskellige personer fra vores kunde PLO (begge praktiserende læger), der hver har sat deres ekspertise til rådighed, til gavn for systemudvklingen. Den ene sidder i ledelsen og er formand for PLOs IT-udvalg, den anden en mere 'almen' praktiserende læge, dog med stor indsigt i de eksisterende patientjournalssystemer. Begge kontaktpersoner udgør således brugere af systemet, og det har været igennem møder og evalueringer med disse, at vi har gennemført projektet. PLO er en relativ stor organisation. Det er derfor svært at opnå et omfattende forhold til organisationen inden for den begrænsede periode projektet har forløbet, så det har været med vores repræsentanter projektforholdet har eksisteret. Selvom vi ikke er blevet præsenteret for hele ledelsen i PLO, ej heller alle brugere, repræsenterer begge kontaktpersoner både ledelse, brugere og i sidste instans kunde. PLO har fra starten været meget imødekommende over for vores projekt. Projektet har fra starten været relativt ambitiøst - vores tid og bemanding taget i betragtning. Selvom det lå fast fra starten, at vores færdige produkt aldrig ville være en seriøs konkurrent til de systemer deres medlemmer (praktiserende læger) bruger, var de interesseret i at få udviklet en prototype på et patientsystem, der - modsat de eksisterende løsninger - kunne tilgå én central database. På den baggrund har det være utrolig let at lave aftaler, opsætte møder mv. med dem. Med stor entusiasme har vores kontaktpersoner givet os den fornødne information for at systemudviklingen kunne tage form. Vi blev inviteret til Odense, for at holde et møde med Medcom - det danske sundshedsdatanet, der udvikler standarder inden for lægeverdenen, herunder det føromtalte FNUX-format. Vi prioriterede dog, at udvikle en klient, der kunne foretage de mest basale journalhåndteringsfunktioner, førend vi brugte tid på at overholde samtlige medicinske standarder. Dette forhold bekræftede os dog i det høje engagement fra PLO, som fungerede som endnu en motivationsfaktor for at udvikle et så gennemført system som muligt. 2.2 Samarbejdet internt i projektgruppen Vi startede ud med at være tre i gruppen, men den tredje mand faldt fra. Dette vanskeliggjorde naturligvis planlægningen af projektets forløb. Mandefaldet betød imidlertid ikke, at projektet faldt fra hinanden. Med visheden om, at vi med kun to mand skulle gennemføre et relativt ambitiøst projekt, har vi været nødsaget til at holde vores arbejde struktureret, og uddelegere de resterende arbejdsopgaver i mellem os. Til trods for at arbejdsbyrden stiger med en mindre besætning, har der også været fordele ved at være to i stedet for tre. Det har været let at lave aftaler, og umuligt at smutte fra disse, da vi kun har haft hinanden til at sørge for, at det aftalte arbejde nu blev udført. 10

14 Vi har undervejs sikret fremdrift på de mest kritiske felter ved at holde projektets status op mod målene for projektet deneret i analysen, for at dernæst at uddelegere arbejdsbyrden - og ellers sørge for at vi udførte de aftalte opgaver. Dernæst har vi så vidt muligt undervejs sørget for at holde kunden opdateret, og sikret at vores arbejde har været i henhold til kundens ønske. 3 Reeksion over resultat og forløb af IT-projektet I dette afsnit reekteres over projektets proces, og losoferes over gode, såvel som mindre gode strategier for systemudvkling. Herigennem opnås et så højt abstraktionsniveau over processer i generel systemudvikling som muligt. 3.1 Styrker og svagheder ved tilrettelæggelsen af projektforløbet Der kan ikke herske nogen tvivl om, at tilrettelæggelsen af et projekts etablering er utrolig vigtigt. Projektetableringsfasen grundlægger fundamentet for det videre forløb, og kan ved en struktureret udførelse aive grundlæggende misforsåelser kunden og projektgruppen måtte have, såvel som projektgruppen internt. Allerede forud for kursets begyndelse var vores kunde i dette projekt kontaktet, og påbegyndelsen af projektfundamentet var så småt iværksat. Sideløbende med projektets udvikling, har gruppen sat sig ind i kursuslitteraturen, og har herigennem opnået større indsigt i teori og metode, hvad objektorienteret analyse og design angår. Som naturlig konsekvens af de to sideløbende aktiveter - systemudvkling og forståelse for teorien for det samme, har vi haft 'a-ha'-oplevelser, hvor vi har gennemført trin i udviklingsprocessen, førend vi var præsenteret for den teori, der dækkede det samme. Som eksempel kan nævnes afholdelsen af allerførste møde med projektets kunde, hvor vi foruden at skulle opnå indsigt i kundens problemstillinger og ønsker, måtte forholde os til interviewteknikker og referatstrategier, førend vi havde læst om dette. Man må kravle, før man kan gå - og det viste sig da også, at jo længere vi kom i forløbet, desto bedre blev vi til at opnå større udbytte af vores kundemøder, samt at bruge disse til fælles at analysere udfordringerne ved udviklingen af systemet. Det kan i nogle tilfælde være en lærerig proces, at kaste sig hovedkuls ud i aktiviteter, der fra et teoretisk synspunkt er besværlige, for så bagefter at sætte sig ind i den respektive teori, og derfra lære af sine fejl eller mangler. Sideløbende med dette udviklingsforløb har projektgruppen, som en naturlig del af at være universitetsstuderende, haft andre kurser, der også har krævet opmærksomhed. Det har ved enkelte lejligheder (primært opmod aevering af delrapporter i dette kursus) betydet, at nogle beslutninger har været truet for hurtigt og ugennemanalyseret, hvor vi senere har set os nødsaget til at revurdere disse. Kursuslitteraturen har en række af forslag til at strukturere delaktiviteter i systemudviklingen, og styrke samspillet disse i mellem, som at holde dagbog over systemudviklingen ved [L. O. Jepsen 1989], projektetableringsforslag ved [N. E. Andersen 1986] eller pap-mockups til prototypetesting med kunden ved [Ehn and Kyng, 1991]. Vi har gennem projektet udnyttet en situtationsbestemt strategi, som foreslået ved [L. Mathiassen m.., 2001] 6, hvor kravene til at formulere en strategi for projektets udvikling fastlægges igennem analysen. Grundlaget for at træe 6 [L. Mathiassen m.., 2001], side

15 beslutninger genevalueres efterhånden som projektet udvikler sig. Vi har altså undervejs i vores projekt målt vores planlægning op mod, hvad vi ønskede os at opnå. Dette har betydet sikkerhed for delaktiviteternes samspil projektet igennem. 3.2 Forslag til forbedringer af processen Det beskrives i kursuslitteraturen hvorledes man ved et gennemanalyseret forarbejde kan undgå en række faldgrupper, andre systemudviklingsprojekter har lidt under. I [N. E. Andersen 1986] stilles en række spørgsmål, der kan afklare vanskeligheder ved fastlæggelsen af projektets rammer, herunder relevante spørgsmål til foreståeligheden af opgavebeskrivelsen og ansvarsfordelingen i projektgruppen. Selvom rammerne er fastlagt, og gruppen føler, at grundlaget for projektet er velskabt, kan der opstå uforudsete hændelser, der vanskeliggør det videre forløb. I reference til vores eget forløb, afhjalp en fast deneret ansvarsbeskrivelse ikke problemerne, der opstod da vi pludselig var en mand mindre i gruppen. Et forslag til forbedring af processen kunne herunder være en slags kriseplan - der blot overordnet beskrev gruppens plan ved sådanne hændelser. Naturligvis kan det være svært at forudse krisesituationer (deraf navnet uforudsete hændelser), men en mulig gardering imod disse kunne være hensigstmæssig. Man kunne også tænke sig at kunden sprang fra, projektets grundlag ændrede sig radikalt eller lignende. Kernemålet i et systemudviklingsforløb må være, at få udviklet et nyttigt og brugbart system, der lever op til kundens ønsker. Derfor kan det virke paradoksalt, at selve processen i dette forløb har haft så høj prioritet. Processen er naturligvis hele måden hvorpå et godt produkt skabes, men i og med, at dette har været et universitetskursus, har selve systemet lidt under fokusmangel i forhold til selve udførelsen. Man kunne forestille sig procesteori, der afdækkede det uddannelsesmæssige perspektiv i systemudvikling som dette, for at skabe en mere ligeligt fordelt fokus. Kursuslitteraturen henviser mest til stor-skale projektudvikling, med mange ansatte og store kunder. Kunders virksomheder eller organisationer kan være umådeligt svære at opnå gennemgående kendskaber til inden for et relativt kort tidsforløb, så der må lyde en stor opfordring til at afholde så mange kundemøder som overhovedet muligt. Jeg synes ikke at objektorienteret teori kan stresse vigtigheden af dette nok. Igennem en stringent mødeplan med kunden, og fastlæggelse af helt præcise delmål, opnås et bedre forløb for alle parter. Det værste der kan ske er, at man ikke har noget at tale om til et møde - men det scenarie er svært at forestille sig. 4 Diskussion af [Michael Christensen m.., 1998] I artiklen beskrives udviklignen af et system til en shippingvirksomhed. Projektgruppen bestod af en række unversitetsmennesker samt folk fra virksomheden. I artiklen beskrives det eksperimentielle objektorienterede udviklingsforløb, der denerede sig selv løbende med systemudviklingen. Tilgangen til systemudvikling, samt de i artiklen fremhævede systemudviklingsteknikker, metoder og erfaringer, vises nedenfor i punktform. 4.1 Artiklens tilgang til systemudviklingen ˆ Det understreges at objektorientering ikke blot er at nde ordtyper og klasser, og passe disse ned i en model, for så at oversætte modellen til en implementation. 12

16 ˆ Brug af såkaldt etnogrask perspektiv, er en velfungerende metode til at skabe en forbindelse mellem virkeligheden og projektet, samt analysere organisatoriske dele af de berørte elementer i systemudviklingen. ˆ Udfordringerne ved kooperativ designproces i en storskala virksomhed. Gruppen udførte workshops, interviews og prototypetests med en lang række mennesker i forskellige stillinger fra forskellige lande. ˆ Projektgruppen udviklede en dynamisk modellering af systemet, således at systemmodellen hele tiden udviklede sig i takt med den igangværende analyse. ˆ I artiklen fremhæves fordelen ved at have kort tid imellem prototyper. ˆ Der nævnes en række udviklingsværktøjer brugt i udvklingen. ˆ Deres udviklingsforløb var eksperimentielt, og fulgte en ikke-sekventiel tilgang til udvikling. Således var analyse, design og implementation alle igangværende aktiviteter under hele forløbet, processeret i cyklus. ˆ Gruppen erfarer, at der ikke ndes en universel model, der passer til ethvert systemudviklingsforløb. 4.2 Ligheder og forskelle mellem artiklen og kursuslitteraturen Såvel som kursuslitteraturen beskriver [Michael Christensen m.., 1998] objektorieteret systemudvikling. At understrege, at objektorientering er mere end at formulere systemudvilkingen udfra fastforankrede modeller og følge fastdenerede opskrifter, er der ikke noget revolutionerende ved. Kursets lærebog, [L. Mathiassen m.., 2001], skriver på første linie, første side: En metode kan ikke følges slavisk som en opskrift. Den skal skræddersys til situationen. 7 Dette princip hersker også i [Michael Christensen m.., 1998]: The above lessons are of course not relevant for all kinds of projects but for a project as the one described in this paper we think they are relevant. 8. [Michael Christensen m.., 1998] understreger vigtigheden i at medtage brugere i systemudvikling - det såkaldte kooperative perspektiv. Artiklen beskriver, hvorledes en bred del af organisationen systemet skulle udvikles til blev inddraget i processen, ved worskshops, interviews, prototypetesting mv. Dette udgangspunkt er en hellig del af tilgangen til den systemudvikling kursuslitteraturen prædiker. Der er naturligvis forskellige måder at udføre kooperative brugertests på. Eksempeltvis beskrives der ikke udførlige interviewteknikker i [Michael Christensen m.., 1998], som eksempeltvis i [E. Frøkjær & K. Hornbæk, 2005] - dog er tankegangen den samme. Den dynamiske model og dennes udvikling, 'The evolution of the model', som [Michael Christensen m.., 1998] beskriver, er også et velkendt fænomen i OOAD. 7 [L. Mathiassen m.., 2001], Side 1, linie 1 8 [Michael Christensen m.., 1998], side 24, linie 34 13

17 Selvom [L. Mathiassen m.., 2001] først og fremmest stresser en sekventiel, iterativ udviklingstrategi, er der intet til hindre for, at en opfattelse af problemområdet ændres undervejs i udviklingen. I [N. E. Andersen 1986] beskrives, foruden vigtigheden ved projektetableringsfacen, forholdet mellem projektetableringens grundlag og det videre forløb. For naturligvis kan man ikke vide sig sikker på et helt systemudviklingsforløb fra etableringsfasen, så en fornyet vurdering af betingelserne opsat i etableringsfasen, er stortset uundgåelig. Desuden kan brugerens behov ændre sig undervejs i systemudviklingen, så etableringsgrundlaget må revurderes. Dog understreges det i [N. E. Andersen 1986], at jo mere gennemanalyseret projektetableringen har været, desto sikrere undgår man ovenstående. Der, hvor tilgangen til den systemudvkling [Michael Christensen m.., 1998] beskriver, afviger mest fra kursuslitteraturen, er ved dets opgør med den klassiske sekventielle processudvikling - analyse, design og implementation. I kursuslitteraturen beskrives analyse og design som iterative processer, hvor de samme forhold bliver gentaget ere gange,i nye versioner. Ved afslutningen af disse processer implementeres modellen. Som guren fra [Michael Christensen m.., 1998] viser, ses en cyklusbaseret proces, hvor analyse, design og implementation igennem hyppige prototyper igen og igen redeneres. Nok beskrives det i kursuslitteraturen, hvorledes man kan 'blive klogere' undervejs i et projekt - men ligefrem at gentage de objektorieterede processer i cyklus, er vi ikke blevet præsenteret for før. Figur 9: Ikke-sekventiel udviklingsstrategi. Kilde: [Michael Christensen m.., 1998] 14

18 Litteratur [N. E. Andersen 1986] Andersen, N. E. et al.: Professionel Systemudvikling Kapitel 4: Projektetablering - en god investering., Teknisk Forlag (1986) [Michael Christensen m.., 1998] Michael Christensen m..: The M.A.D. Experience: Multiperspective Application Development in evolutionary prototyping, In Proceedings of the 12th European Conference on Object-Oriented Programming (ECCOP '98), Eric Jul (Ed.). Springer-Verlag, London, UK, [Ehn and Kyng, 1991] Ehn, P. and Kyng, M.: Design at Work: Cooperative Design of Computer Systems: Sider : Cardboard computers: Mocking-it-up or hands-on the future., Lawrence Erlbaum Associates (1991) [E. Frøkjær & K. Hornbæk, 2005] Frøkjær, E. & Hornbæk, K.: Cooperative Usability Testing: Complementing Usability Tests with User-Supported Interpretation Sessions., CHI (2005) [L. O. Jepsen 1989] Jepsen, L. O. et al.: Behaviour and Information Technology vol 8, no. 3, : Back to thinking mode: diaries for the management of information systems development projects., (1989) [L. Mathiassen m.., 2001] Mathiassen, Lars m..: Objekt orienteret analyse & design, 3. udg., Forlaget Marko Aps (2001) [Weile and Trætteberg, 2000] Weile, M. V. and Trætteberg, H.: Interaction patterns in user interfaces. In Proc. Seventh Pattern Languages of Programs Conference: PLoP 2000, 26 pages. (2000) 15

19 A Formål Praktiserende læger i Danmark bruger i øjeblikket 12 forskellige patientjournalsystemer, hvor de este læger selv har en server stående i deres praksis, der håndterer deres patienters journaler. På nuværende tidspunkt er det op til den enkelte læge, at vælge mellem de kommercielle systemer, der tilbydes. Fælles for systemerne er det, at de ikke nødvendigvis kan kommunikere direkte med hinanden, hvilket der er brug for, hvis en patient eksempelvis vælger at skifte læge, eller bliver henvist til en speciallæge. Konsekvensen er, at der udføres en stor grad af udskrivning og postafsendelse af journaler samt manuelt indtastningsarbejde. I samarbejde med Praktiserende Lægers Organisation (PLO) vil vi lave en fælles platform for alle praktiserende læger. En platform, som fungerer på alle systemer (Java baseret), og som har en global database alle praktiserende læger kan tilgå. Det er værd at nævne, at dette projekt ses som en prototype for hvad PLO har brug for. Dermed vil produktet ikke være en reel konkurrent til de eksisterende kommercielle systemer, men et 'proof-ofconcept' for et journalsystem der tilgår patientdata i en central database. Kerneidéen med systemet, at tilgå patientdata fra en global database, kan anskueliggøres ved at se systemets relationer i et rigt billede, vist herunder. Figur I (bilag): Rigt billede. De stiplede linier repræsenterer mulige udvidelser af systemet, og indgår således ikke som kernemål i dette projekt. 16

20 A.1 Systemdenition Ved at have deneret BATOFF-kriteriet samt kravspecikationen fra start, har vi haft en fast milepæl, der har tjent som støtte til udarbejdelsen af systemet. Betingelser Systemet skal kunne håndtere patientdata fra en global database. Systemet skal bruges af praktiserende læger og deres sekretærer, altså mennesker, der forventes at være vant til daglig brug af lignende IT-systemer. Anvendelsesområde Praktiserende læger og sekretærer. På sigt kan listen udvides til eksempelvis andre speciallæger, dog ændres betingelserne ikke. Teknologi En PC hos den praktiserende læge, der tilgår patientdatabasen igennem en klient. Klienten er en Java-klient, der tilgår en fjerntliggende MySQL-database. Objekter Læge, Patient, Journal, Sygdom. Funktionalitet Håndtere praktiserende lægers patienters journaler. Filoso Værktøj til redigering af alle praktiserende lægers patientjournaler, ved at lagre patientdata globalt. A.2 Kravspecikation for IT-løsningen Kravspecikationen er deneret ved følgende 6 punkter, der fungerer som basis for systemet. 1. Systemet er en prototype, og skal derfor ikke ses som et fuldt funktionelt system på lige fod med allerede eksisterende kommercielle patientjournalsystemer. 2. Systemet skal kunne bruges af praktiserende læger og deres sekretærer i Danmark. 3. Systemet skal kunne håndtere al information omkring en læges patient. Det skal være let at redigere i informationerne og tilføje mere information. 4. Systemet skal være i stand til at håndtere journalformatet FNUX, og både indlæse og eksportere dette. 5. Systemet skal bruge sygdomsklassikationssytemet IC-10 til at skelne imellem sygdomme i journalerne. 6. Systemet skal lagre al information på en global database, og alle brugere skal kunne tilgå denne information gennem internettet. 17

21 B Problemområdet Herunder beskrives problemområdet. B.1 Struktur Her ses klassediagrammet, ved klassisk associerngsstruktur. Læge 0..* 0..* Patient Journal 0..* 0..* Sygdom Figur II (bilag): Klassediagram. En læge kan have ere patienter, og en patient kan have ere læger. En journal kan tilhøre én patient, og en patient kan have max én journal. En sygdom kan tilhøre mange journaler, og en journal kan indeholde mange sygdomme. B.2 Klasser Herunder listes systemets klasser, samt hændelser og adfær. Adfærdsmønstre er beskrevet som regulære udtryk jf. [L. Mathiassen m.., 2001] side 93. Læge En læge har et læge-id, og en række patienter. Hændelser Tildelt patient 18

22 Adfærd Adfærd er triviel for læge, idét objektet ikke bemærkelsesværdigt skifter tilstand i systemet. Læge kan tildeles patienter, men vi medtager ikke en læges daglige rutiner i dette system, da fokusområdet er patienters journaler. Patient En patient hører til en eller ere læger, og har en række personlige oplysninger (cprnummer, adresse mv.), og en journal. Hændelser Patient oprettet Patient identiceret Stamoplysninger opdateret Adfærd (Patient oprettet Patient identiceret) + Stamoplysninger opdateret* Journal En journal tilhører en patient, og indholder dennes medicinske historik. Hændelser Journal oprettet Tilføjet indhold Eksporteret til FNUX-format. Adfærd Journal oprettet + Tilføjet indhold* + Eksporteret til FNUX-format* Sygdom En sygdom kan tilhøre mange journaler. En sygdom har en ICO-10 kode. Sygdomsklassen er statisk idét databasen indeholder sygdomme registreret af WHO. Derfor bruges de enkelte sygdomsobjekter blot som referencer til patienters journaler. C Anvendelsesområdet Anvendelsesområdet for systemet er herunder beskrevet. Aktørernes brugsmønstre er udspeciceret ved brugsmønsterspecikationer. C.1 Brug I systemet ndes to aktører; læge, som redigerer i patienters information og deres journaler, og FNUX-parser. FNUX-parseren er en del af IT-systemet der kan importere og eksportere patientjournaler i journalformatet FNUX. Ved en udvidelse af systemets kernemål, foreslået ved gur I (bilag), udvides aktører til patienter, der kan få vist deres journal i en webbrowser. Nedenfor vises aktørernes brugsmønstre. 19

23 Læge ˆ Oprette patient ˆ Finde patient ˆ Redigere patientoplysninger ˆ Tilføje indhold til journal ˆ Ændre journalprivilegier FNUX-parser ˆ Importere journall i FNUX-format. ˆ Eksportere journall i FNUX-format. Herunder er brugssmønstre beskrevet ved brugsmønsterspecikation. Oprette patient Oprettelse af patient initaliseres af lægen, og foregår på systemets startside. Hvis oprettelsen blev udført, videreføres brugeren til denne patients patientside. Hvis der opstår fejl ved oprettelse giver systemet besked herom. Objekter: Patient. Funktioner: Patientoprettelse Figur III (bilag): Brugsmønsterspecikation for oprettelse af patient Finde patient En patient kan identiceres i systemt ved, at brugeren søger efter denne, eksempeltvis på cpr-nummer, navn mv. Hvis der er ere resultater efter søgning, skal brugeren vælge den rette ved menuvalg. Efter patienten er identiceret, videreføres brugeren til dennes patientside. Objekter: Patient. Funktioner: Patientsøgning Figur IV (bilag): Brugsmønsterspecikation for at nde patient Redigere patientoplysninger Brugeren identicerer patienten og vælger 'rediger stamoplysninger' fra menuen på patientsiden. Ved skemaudfyldelse opdateres patienens stamoplysninger. Objekter: Patient. Funktioner: Rediger-patientoplysninger Figur V (bilag): Brugsmønsterspecikation for redigering af patientoplysninger 20

24 Tilføj indhold til journal Tilføjelse af indhold igangsættes af lægen ved, at vedkommende i systemet vælger den funktion, der passer til det indhold der skal registreres i journal, efter at den patient hvis journal skal have indhold registreret er valgt. Lægen bliver af systemet anmodet om at udfylde en række oplysninger i et skema omkring tilføjelsen, alt efter hvilken er valgt. Efter dette er gjort, er journal opdateret med det nye indhold. Det registreres også hvilken læge, der har tilføjet indhold. Objekter: Journal, Sygdom. Funktioner: Diagnose-registrering, Henvisnings-registrering, Konsultationsregistrering Figur VI (bilag): Brugsmønsterspecikation for tilføjelse af indhold til journal Ændre journalprivilegier Hvis en patients journal skal være tilgængelig for en anden læge end patientens praktiserende læge, identicerer brugeren af systemet patienten, og vælger ændre privilegier på patientsiden. Objekter: Patient, Journal, Læge. Funktioner: Rediger-journalrettigheder Figur VII (bilag): Brugsmønsterspecikation for ændring af journalprivilegier Importere FNUX-format Importering af l i FNUX-format kan enten ske ved oprettelsen af en patient, eller ved at vælge funktionen, efter en patient er valgt. Under alle omstændigheder er det lægen, der vælger at importere en ekstern journall. FNUX-parseren parser indholdet af len, og registrerer journalen under den valgte patient, hvis importen blev udført uden fejl. Ellers giver systemet en fejlmeddelse. Objekter: Journal, Sygdom, Patient. Funktioner: FNUX-importering Figur VIII (bilag): Brugsmønsterspecikation for importering af journall i FNUX-format 21

25 Eksportere FNUX-format Efter en patient er identiceret, kan brugeren vælge 'eksportér journal' på patientsiden, såfremt patienten har en journal. Systemet spørger, hvor journallen skal gemmes, og efter det er valgt, eksporteres patientens journal i FNUX-format. Objekter: Journal. Funktioner: FNUX-eksportering Figur IX (bilag): Brugsmønsterspecikation for eksportering af journall i FNUX-format C.2 Funktioner Herunder ndes systemets funktionsliste, kategoriseret efter kompleksitet og funktionstype. Funktion Kompleksitet Funktionstype Patientvisning Simpel Aæsning Patientoprettelse Medium Opdater Patientsøgning Medium Aæsning Rediger-patientoplysninger Simpel Opdater Henvisnings-registrering Simpel Opdater Diagnose-registrering Medium Opdater Konsultations-registrering Simpel Opdater Rediger-journalrettigheder Medium Opdater Journalsøgning Medium Aæsning Journaludskrivning Simpel Signal FNUX-importering Kompleks Opdater FNUX-eksportering Kompleks Signal Figur X (bilag): Funktionsliste Ved at sammenholde funktionslisten med brugsmønstre samt modellens klasser og hændelser, ses at denne er konsistent. Modellen indeholder præcis de oplysninger, funktionslisten behøver - og alle brugsmønstre er dækket af funktionslisten. Derfra sluttes, at funktionslisten er tilstrækkelig. C.2.1 Specikation af komplekse funktioner Systemets funktioner er mestendels simple eller medium-simple, idét de este funktioner blot er opdatering eller registrering af patientdata. Herunder er de to komplekse funktioner udspeciceret. Disse er komplekse, da de omhandler parsing af l i FNUXformat - og denne XML-strukturerede l er relativ kompleks at håndtere. FNUX-importering FNUX-importering tager en l i FNUX-format og en patients cpr-nummer som argumenter, og parser indholdet af den XML-strukturerede journall, og gemmer dets oplysninger i den globale database, såfremt der ikke opstod fejl under parsing 22

26 (eksempeltvis hvis len ikke overholder FNUX-standarten). I tilfælde af fejl, informerer systemet brugeren. FNUX-eksportering FNUX-eksportering tager en patients cpr-nummer som argument, og danner en FNUXformateret journall som output, såfremt patientens journal eksisterer. Brugeren vælger et lokalt sted på vedkommendes maskine til at gemme len. C.3 Brugergrænseaden Systemets brugergrænseade præsenteres her. En oversigt i form af et navigeringsdiagram, samt eksempler på brugergrænseaden vises. C.3.1 Dialogform Menuvalg opstår ved ere resultater ved søgning, samt dialogbokse med fejl eller godkendelser. Der er valgt skemaudfyldelse til indtastning af data. C.3.2 Oversigt Navigeringsdiagrammet er, som det ses herunder. Figur XI (bilag): Navigeringsdiagram. Systemet initialiseres ved loginskærmen, der viderefører brugeren til en starside. Fra denne vælges en patient, eller denne oprettes. Herfra ndes de egentlige patient- og journalfunktioner, der åbnes i til formålet byggede dialogbokse. 23

27 C.3.3 Eksempler Nedenfor vises eksempler på brugergrænseaden, forklaret ved deres gurtekst. Figur XII (bilag): Login-in siden Figur XIII (bilag): Systemets startside. Der kan oprettes en patient, eller vælges en ved at søge. 24

28 Figur XIV (bilag): Hvis en søgning på en patient genererer ere resultater, skal den rette vælges fra denne menu. Figur XV (bilag): Patientsiden. Herfra foregår lægens arbejde med den enkelte patient, og dennes journal. 25

29 Figur XVI (bilag): Eksempel på dialogbokse, der viser godkendt eller afvist i oprettelse af patient. C.4 Den tekniske platform Systemets klient udvikles i Java, hvilket betyder, at systemet kan køre på Windows, Linux, OS X og andre systemer. Alt data bliver gemt i en MySQL database, som ligger på en central server, som alle klienterne kan tilgå. Brugergrænseaden er vinduesbaseret, og betjenes med mus og tastatur. D Anbefalinger I dette afsnit diskuteres udgangspunktet for systemets tilblivelse kort. D.1 Nytte og realiserbarhed Systemet er vigtigt for PLO fordi de har brug for et eksempel på et journalsystem, der kan fungere med en central database. PLO er bevidste om, at de praktiserende lægers nuværende IT-systemer ikke er i trit med de muligheder, der er for moderne IT-udvikling. Med eksempel menes der en prototype. Brugerne er bevidste om, at projektet ikke vil blive realiseret så det kan anvendes i en reel arbejdssituation. Dog har de en stor interesse i at se et "proof-of-concept", dels for at overbevise deres medlemmer om, at det er en god idé, og dels for at bekræfte dem selv i muligheden og fordelene ved en sådan model. Fordi det system vi arbejder på er en prototype, der ikke skal konkurrere med færdigudviklede patientssystemer, er det sandsynligt at systemet bliver realiseret. D.2 Strategi Der er enighed mellem gruppen og kunden om, at projektet skal forsøges gennemført inden for projektkursetsrammer. Det er i alles interesse, at få udviklet en så nyttig prototype som mulig. Det er planlagt at implementere systemet i Java med en MySql-database. Desuden planlægger vi at følge en situtationsbestemt strategi, som foreslået ved [L. Mathiassen m.., 2001] 9, hvor kravene til at formulere en strategi for projektets udvikling fastlægges igennem analysen. Grundlaget for at træe beslutninger genevalueres efterhånden som projektet udvikler sig. D.3 Økonomi Økonomisk set, er der ingen problemer. Brugerne har allerede PC'er som ville kunne køre systemet, og den mængde data som databasen skal håndtere i prototypen, er ikke større 9 [L. Mathiassen m.., 2001], side