Digitalt Helsekort for Gravide. Hovedprosjekt

Transkript

1 Digitalt Helsekort for Gravide Hovedprosjekt Institutt for Informasjonsteknologi Avdeling for ingeniørutdanning Høgskolen i Oslo og Akershus

2 Petter Abrahamsen og Stian Flatby: Digitalt Helsekort for Gravide, hovedoppgave bachelor, Copyright 2014 ii

3 Informasjonsteknologi Høgskolen i Oslo og Akershus Hovedprosjekt Digitalt Helsekort for Gravide POSTADRESSE: Postboks 4 St. Olavs plass, 0130 Oslo BESØKSADRESSE: Holbergs plass, Oslo PROSJEKTNUMMER: 43 TILGJENGELIGHET: Konfidensielt DELTAKERE: Stian Flatby og Petter Abrahamsen VEILEDER: Thor E. Hasle OPPDRAGSGIVER: CSAM Health AS KONTAKTPERSON: Ilan Eini Antall sider: 86 DATO: 27. Mai SAMMENDRAG: Webapplikasjon for forenkling av dagens svangerskapsprosess 3 STIKKORD: HTML, CSS, JavaScript iii

4 iv

5 FORORD Dette er sluttdokumentasjonen til gruppe 43, bestående av Stian Flatby og Petter Abrahamsen. Produktet er et resultat av oppdragsgivers krav og spesifikasjoner, som generelt sett definerer en webapplikasjon for oppretting og håndtering av et digitalt helsekort for gravide. Dette dokumentet vil ta for seg hvordan vi har jobbet, hva som har blitt laget, informasjon om testing, brukerveiledning, og kravspesifikasjonen. Dokumentet er beregnet på personer med god forståelse innen informasjonsteknologi, da deler av dokumentasjonen kan være noe teknisk. Dokumentasjonen er optimalisert for å leses som PDF ettersom det blir benyttet linker innad i dokumentet, dog det er likevel fullt mulig å lese på papir da linkene beskriver hvor i dokumentet den peker. Gruppen kom i kontakt med CSAM Health AS via Stian Flatby (gruppemedlem). Han snakket med Sverre Flatby (administrerende direktør i CSAM), som forhørte seg rundt i selskapet. Etter noen timer ble vi satt i kontakt med Ilan Eini og fikk tilbud om et oppdrag. Vi hadde et par møter med CSAM før vi bestemte oss for å ta dette oppdraget. Oppdraget var å lage en fungerende prototype av et nettsted slik at CSAM kunne demonstrere denne på presentasjoner. Nettstedet skulle kun være rettet mot brukeren, og gi muligheten til å se og endre noe informasjon rundt svangerskapet, samt snakke med leger via en meldingstjeneste. Takk til En stor takk til Thorsten Pørscke, Creative Director hos CSAM Health AS, for hans gode forslag til design og funksjonalitet. Vi vil også takke Ilan Eini for å gi oss muligheten til å jobbe med dette prosjektet og Lilly Marit Angermo for å ha hjulpet oss med og lettere forstå den kliniske delen av oppgaven. v

6 vi

7 INNHOLDSFORTEGNELSE DEL I SLUTTDOKUMENTASJON PROSESSDOKUMENTASJON PLANLEGGING OG METODE Forprosjektfasen Verktøy Kommunikasjon Risiko UTVIKLINGSPROSESSEN Brukergrensesnitt DATABASE Dynamisk innhold og utseende Testing Backend Dokumentering og kommentering Faglige utfordringer Oppbygning Viktige valg Ekstra vanskelig EXTREME PROGRAMMING KRAVSPESIFIKASJONEN OG DENS ROLLE ANSVARSFORDELING AVSLUTTENDE DEL Resultatet Prosessen Fremtidig bruk OPPDRAGSGIVER SINE MENINGER PRODUKTDOKUMENTASJON PRODUKTBESKRIVELSE SENTRALE DATASTRUKTURER INTRODUKSJON TIL RAMMEVERK AngularJS Bootstrap Entity Framework BIBLIOTEKER OG PROGRAMVAREUTVIDELSER jquery Masonry mmenu Highcharts jquery UI STRUKTUR vii

8 2.6 NAVIGASJON OG TILBAKEMELDING MODELLER AV OPPSETTET API Web-API JSON og XML Sikkerhet URL DTO PRODUKT Kjernefunksjonalitet Min Profil Mitt Svangerskap Medisinsk Info Meldinger Dagbok Ultralyd Tidligere Svangerskap Undersøkelser Veiviser Administrator ResponsibleUI Ekstra Systemkrav BRUKERVEILEDNING GENERELT Systemkrav Menyen Tilgjengelighet MIN PROFIL Oppdatere informasjon Feil informasjon MITT SVANGERSKAP Registrering av svangerskap Undermenyen Tidslinjen KURVE UNDERSØKELSER MEDISINSK INFO Oppdatering av informasjon MELDINGER Sende meldinger Meldinger på mobil Starte samtale med annen lege/jordmor MIN DAGBOK Nytt innlegg viii

9 3.8.2 Last opp bilde ULTRALYD TIDLIGERE SVANGERSKAP Endre bilde Informasjonen LOGG UT TESTDOKUMENTASJON BRUKERTEST FORMÅLET MED TESTENE AKSEPTANSETEST KONKLUSJON UTVALGTE TESTER KRAVSPESIFIKASJON VERSJON PRESENTASJON Hovedtrekk ved kravspesifikasjonen Forord KRAV Forbedringer en venter å oppnå Systemet må inneholde: Systemet bør inneholde: Systemet kan inneholde: Rammekrav i systemet Simpel datamodell Krav til systemkonstruksjon Krav til dokumentasjon DATAORDBOK DEL II APPENDIKS KRAVSPESIFIKASJON VERSJON PRESENTASJON Hovedtrekk ved kravspesifikasjonen Forord KRAV Forbedringer en venter å oppnå Systemet må inneholde: Systemet bør inneholde: Systemet kan inneholde: Rammekrav i systemet Simpel datamodell Krav til systemkonstruksjon Krav til dokumentasjon DATAORDBOK ix

10 x

11 FORKORTELSER OG FREMMEDORD Administrasjonsproduktet Nettsidene og tjenerdelen som administratorer skal bruke AJAX Asynchronous JavaScript and XML, webutviklingsteknikk for å lage interaktive nettsider AngularJS JavaScript rammeverk, åpen kildekode Bootstrap Rammeverk for å gjøre det enkelt å tilpasse nettsider for mobiler og nettbrett Cookie En liten mengde data som blir lagret på brukerens datamaskin og nettleseren sender dataene tilbake til serveren for at serveren skal være klar over brukerens tidligere aktivitet CSS Cascading Style Sheet, et språk som definerer utseende på HTML og XML filer C# - Et programmeringsspråk DOM Document Object Model Entity Framework ORM-rammeverk I.NET, hjelpemiddel for oppretting av relasjonsdatabaser Hash Endrer vilkårlig lengde data til en fast lengde HTML HyperText Markup Language, nettsider er laget med HTML http HyperText Transfer Protocol MVC Model View Controller MVVM Model View ViewModel Naegels regel Regel for beregning av fødselstermin, 282 dager i snitt fra første dag i siste menstruasjon ORM Object-Relational Mapping, en teknikk for å konvertere data mellom inkompatible typer Pasientproduktet Nettsidene og tjenerdelen som pasientene skal bruke Produktet for ansvarlig Nettsidene og tjenerdelen som leger/jordmødre (ansvarlige) skal bruke Px Forkortelse for piksler i CSS SPA Single Page Application, nettsted som laster inn partielle sider i en ramme side WCAG Web Content Accessibility Guidelines xi

12 xii

13 DEL I SLUTTDOKUMENTASJON 1

14 2

15 Prosessdokumentasjon 1 I dagens samfunn har man blitt vant til at informasjon er tilgjengelig så lenge man har tilgang til internett. Likevel er helsekortet for gravide i dag et papirark som den gravide må ta med seg til alle undersøkelser og møter med legene. Hvis dette papirarket glemmes må man fylle ut et nytt, og viktig informasjon kan gå tapt. I Appendiks ligger det bilde av et slikt helsekort, Figur - F. Dette så CSAM Health AS på som en unødvendig byrde. CSAM er et privateid ehelse-selskap og har fokus på programvareløsninger for tilbydere av helsetjenester. Det helhetlige målet med denne oppgaven var å lage et nettsted som var intuitivt, lett å bruke og gjorde informasjonen tilgjengelig fra mobiler, nettbrett og datamaskiner. Et slikt nettsted ville gjort det mye enklere for både leger og gravide, både for kommunikasjon, effektivitet og trygghetsfølelse. Det finnes flere fordeler med en digital versjon, hvor blant annet statistikk blir langt mer effektivt. Oppgaven skal ikke ta for seg sikkerheten som kreves for en slik applikasjon, og skal kun fungere som en prototype ( proof of concept ). 1.1 Planlegging og metode Forprosjektfasen Startfasen vår var veldig trøblete; vi kom sent i gang og hadde interne gruppeproblemer. Til å begynne med var det ingen som tok ordentlig initiativ, og det ble ofte kommunikasjonssvikt mellom medlemmene. Gruppen bestod opprinnelig av fire personer som ikke kjente hverandre fra før, noe som også førte til at samtlige forventet at én skulle ta ansvar. Vårt første møte var veldig sent, men til tross for dette kom vi veldig raskt i kontakt med CSAM. Etter å ha overveid det totale gruppearbeidet etter ferdigstillingen av kravspesifikasjonen ble alle medlemmene sammen enige om at de to andre gruppemedlemmene skulle hoppe av, da de verken hadde tid, lyst eller kunnskap til å gjennomføre et slikt stort prosjekt på tiden som gjenstod. Dette var selvfølgelig ikke optimalt, men vi prøvde å gjøre det beste ut av det, og valgte å ikke forandre på kravspesifikasjonen. Dette fikk ganske store konsekvenser for prosjektet og gjorde at vi måtte ta mye ansvar og samarbeide tett. Vi planla prosjektet ved å sette opp en arbeidsplan i Microsoft Project som ga oss en god oversikt over hvor lenge vi hadde igjen og hvor langt vi burde ha kommet. Arbeidsplanen ble senere jevnlig sjekket for å se at vi ikke lå etter skjema Verktøy Visual Studio Visual Studio 2013 ble brukt som utviklingsverktøy for nettstedet på bakgrunn av ønskene og kravene satt av oppdragsgiver tidlig i prosjektet, og har gitt fantastisk støtte for.net og MVC. Produktet skulle også demonstreres og kjøres på en tjener fra Microsoft Azure, så dette var det beste alternativet også for vår 3

16 del. Verktøyet ble brukt til all programmering til samtlige språk, HTML, C# og JavaScript. Innebygd støtte for Git gjorde dette valget enda lettere Git Git er et distribuert versjonskontrollsystem som gjør samhandling på samme filer langt enklere. I tillegg til å være støttet i Visual Studio 2013 kunne Git gi oss full historikk på prosjektet, noe som gir oss en stor fordel dersom et nytt problem skulle dukke opp, da vi enkelt kan gå tilbake for å gjenopprette tidligere versjoner eller feilsøke gjennom tid Dropbox Dropbox er en fildelingstjeneste som kan klone lokale mapper til en skytjeneste for å synkronisere med andre brukere som har tilgang. Dette er et verktøy som kommer godt med for prosjekter som krever deling av forskjellige typer filer, hvor det i vårt tilfelle ble brukt mye for å overføre instanser av databaser, prosjekter og design mellom maskiner. I tillegg til å være en ren fil-deler har vi også benyttet Dropbox til å fungere som en tjener for versjonskontrollsystemet Git. Dette er vanligvis frarådet da simultan synkronisering visstnok kan skape problemer for resultatet, men med tett samarbeid og god kommunikasjon har ikke dette vært et problem Nettlesere Google Chrome, Apple Safari og Mozilla Firefox har blitt brukt kontinuerlig for å verifisere funksjoner og utseende på nettstedet. Standardnettleseren gjennom hele prosessen har vært Google Chrome, i tillegg til at vi også har brukt Chrome for Android og Safari for iphone/ipad, da oppgaven hovedsakelig er en mobil web-applikasjon Skype Skype er en gratis applikasjon for IP-telefoni som forenkler kommunikasjon over internett. I tillegg til å være en telefoni-tjeneste støtter det også video og hurtigmeldinger. Vi har benyttet Skype som en av kommunikasjonsmetodene dersom vi ikke befinner oss på samme sted, noe som har gjort det enklere å holde kontakten Azure Microsoft Azure er en plattform i skyen som gir støtte for hosting av en applikasjon. Etterhvert i utviklingen av applikasjonen har vi ofte rullet ut små fungerende versjoner som ble brukt til demonstrasjoner og presentasjoner til denne tjenesten, som var ordnet av CSAM. Her ble IIS brukt til å kjøre applikasjonen, og SQL Server Management brukt til å håndtere databasen IIS IIS 8.0, Internet Information Services, er en nett-tjener fra Microsoft som støtter alle vanlige protokoller for kommunikasjon over nett. Innebygd i IIS er det også støtte for.net og andre rammeverk, noe som gjorde det veldig enkelt og effektivt for oss å gå mellom utvikling og release av applikasjonen. I tillegg har IIS støtte for å raskt kunne endre prosjektets connection-string for bruk av database, da databasemiljøet opptrer noe annerledes fra utvikling til ferdigprodukt Microsoft SQL Server Management Studio SQL Server Management Studio er et verktøy brukt til å konfigurere, håndtere og administrere komponenter i en SQL-tjener. For vår del ble dette benyttet kun til å holde på vår egen database ved utrullede ferdigversjoner på Azure-tjeneren. Ved å gå fra debug i Visual Studio til å publisere prosjektet 4

17 med IIS på Azure ble det veldig enkelt å knytte sammen databasen og IIS gjennom SQL Server Management Studio Microsoft Project Microsoft Project er et prosjektstyringsverktøy, laget av Microsoft som et ekstra program med tilknytning til Microsoft Office. Dette ble brukt til å lage arbeidsplanen og beregne hvor lang tid de forskjellige delene av prosjektet ville ta Google Docs/Drive Google Docs er en skybasert tjeneste for å lage og endre dokumenter. Google Drive er område der dokumenter fra Google Docs blir lagret. Vi brukte Google Docs for å kunne jobbe på dokumentene våre samtidig. Dette var en stor fordel under dokumenteringen Kommunikasjon Som beskrevet i punkt Forprosjektfasen hadde gruppen en vanskelig start hvor kommunikasjonen var dårlig. Dette ble helt snudd etter at forprosjektfasen var over og gruppen bare bestod av to medlemmer. Fra vi ble to personer har kommunikasjonen mellom oss vært svært viktig for oss, og høyt prioritert. Dette resulterte i at vi snakket sammen tilnærmet hver dag, med fordelen at vi under utviklingsprosessen og sluttfasen jobbet hos oppdragsgiver og satt ved siden av hverandre. Dette førte til at vi kunne snakke sammen under utviklingen av produktet, og fikk en god flyt i arbeidsprosessen. Dette har vært viktig for hvordan fordelingen av oppgaver har vært, som beskrevet i punkt 1.5 Ansvarsfordeling, og har gjort at vi klarte å få ferdig produktet til tross for forholdet mellom tid og oppgaver. En annen fordel som kom av at vi satt på CSAM s kontor under utviklingen var kommunikasjonen mellom oss og oppdragsgiver. Vi fikk jobbet veldig tett med de ansatte som var knyttet til prosjektet; designeren, prosjektdirektør, administrerende direktør og produktsjef på føde-området. Den ansatte vi jobbet nærmest med var designeren, Thorsten Pørscke. Han var ansvarlig for å gi oss det helhetlige inntrykket av hvordan nettstedet skulle bli utviklet, både på design og funksjon, gjerne i form av gode og beskrivende photoshop-bilder. Dette utviklet seg gjennom utviklingsfasen og kommunikasjonen ble bedre ettersom vi jobbet tettere og tettere sammen. 5

18 1.1.4 Risiko Risiko evaluering fra startfasen. Beskrivelse Sannsynlighet Konsekvens Tiltak (før/etter) Personer på gruppen blir syke Middels Lav God kommunikasjon og omfordele oppgaver. For stort prosjekt Middels Middels Utvikle i et høyt tempo, samarbeide godt og omprioritere krav Tidsmangel Høy Middels Gjøre om på prioriteringene Kommunikasjonssvikt Middels Middels Snakke mye sammen Gruppemedlemmer frafaller Middels Høy Evaluere kravspesifikasjonen på nytt Prosjektet frafaller Lav Lav Fortsette med produktet som planlagt (selvstendig) Ukjente rammeverk Middels Lav Sette av tid for å lære oss rammeverkene Data går tapt Lav Middels Bruke git og ha flere kopier liggende. 6

19 1.2 Utviklingsprosessen Mye av vårt arbeid er utført hos oppdragsgiver, og vi arbeidet i tråd med Extreme programming - utvikling. Ettersom vi satt ved siden av hverandre og kunne snakke og stille spørsmål, så var dette en helt naturlig utviklingsmetode å velge. Extreme programming blir videre forklart i punkt 1.3 Extreme programming. Dette var veldig viktig da det var mye usikkerhet fra oppdragsgiver under utviklingen av kravspesifikasjonen om hva som faktisk skulle være med på nettstedet. Vi utviklet i en litt annen rekkefølge enn det vi satte opp på arbeidsplanen, men vi klarte likevel å estimere hvor langt vi skulle ha kommet underveis. Innledningsvis fikk vi forespørsler om vi kunne utvikle design-spesifikke sider med statisk data som kunne bli brukt i presentasjoner, noe som stred i mot våre planer om å bli ferdig med dynamikken mellom tjener og klient først. Noe av det første vi vil nevne er at all programmeringen er gjort av oss (dette gjelder selvsagt ikke tredjeparts programvare/kode). Når vi nevner at oppdragsgiver vil ha funksjoner på nettstedet så er det ikke spesifikke kodesnutter, men en generell beskrivelse av hva de vil nettstedet skal gjøre. Vi har ikke fått eller bedt om støtte med tanke på koden, så alle problemer som er løst er det vi selv som har måttet kommet frem til. Dette har bidratt til et stort læringsutbytte for oss, da vi mener problemløsning er det man lærer mest av. Utviklingsprosessen vår består av en del underfaser; brukergrensesnitt, database, dynamisk innhold, dynamisk utseende og testing Brukergrensesnitt Som nevnt ble det tidlig bedt om en rask statisk versjon av brukergrensesnittet i produktet, noe som satte vår utviklingsprosess ut til en skjev start. Vi ønsket likevel å levere det vi ble bedt om, og sammen med Extreme Programming ble ikke dette et stort problem for videre utvikling. I denne fasen er det snakk om at vi kun programmerte i HTML, CSS og vanlig JavaScript, med innskudd av biblioteker og rammeverk som Highcharts og Masonry for det visuelle. Informasjonen som ble vist, samt knappene som var fordelt utover grafer og menyer, var alle statiske og funksjonsløse til å begynne med. I denne fasen fikk vi mange illustrasjoner og bilder fra designeren som vi kunne gå ut i fra da vi lagde nettstedet. Figur 1 viser et av flere design vi mottok og skulle ta utgangspunkt i. Designet var laget for datamaskiner, og vi modifiserte designet, i dialog med designeren, inntil det var mulig å vise på mobiler og nettbrett i tillegg. Figur 1 Mitt Svangerskap design Nettstedet ble brukt i en del presentasjoner av oppdragsgiver, hvor vi ofte senere fikk tilbakemeldinger på hvordan det hadde gått og hva de gjerne ville ha med på neste presentasjon. Dette ga oss en god mulighet 7

20 til å ha bra kommunikasjon med oppdragsgiver, og utvikle et produkt som kan brukes og videreutvikles senere. Vi fikk tilbakemeldinger både muntlig og på mail, alt ettersom hva tilbakemeldingen inneholdt og/eller om vi var på kontoret. Samtlige tilbakemeldinger har vist at presentasjonene har vært meget vellykkede, noe som igjen har gitt oss en god følelse av ordentlig prestasjon og motivasjon underveis i utviklingen. Innsatsen i denne startfasen utgjorde en utilsiktet dog viktig milepæl for produktet, samt at det er godt å vite at hovedoppgaven vår allerede har blitt benyttet flere ganger for intensjonen Database Etter de første presentasjonene av det statiske nettstedet fikk vi mulighet til å begynne på tjener-siden av nettstedet. Databasen fikk neste prioritet ettersom vi så på denne som en nødvendighet for å kunne ha dynamisk innhold på sidene. I løpet av denne fasen ble databasen strukturert i henhold til både kravspesifikasjonens utgangspunkt og tilbakemeldingene fra de ansatte. Vi videreutviklet databasen fortløpende ettersom nye nettsider og datamodeller ble lagt i ønskelisten. Databasen ble ikke ferdig før helt mot slutten av utviklingen, men starten av denne fasen var svært viktig for å få en god oversikt over hvordan oppsettet for databasen skulle se ut. Vi benyttet oss av Visual Studio s Entity Framework basert på prinsippet for Code First, altså at vi programmerte objektene i C# før de automatisk ble overført og håndtert av databasen Dynamisk innhold og utseende Det dynamiske innholdet i denne løsningen består av data som hentes fra tjeneren via en JavaScriptmetode, som videre legges inn på nettsiden. Under denne fasen gikk flere deler parallelt, med prioritet på at JavaScript hadde ordentlig kommunikasjon med tjeneren. Vi ventet med å lage dynamikk mellom tjener og database til vi hadde fått orden på kall mellom tjener og klient. Vi lagde derfor en WebAPI på tjenersiden som skulle ta for seg alle slike kall fra JavaScript og gi riktig data tilbake. Utover i prosjektet, når databasen begynte å inneholde alle nødvendige modeller, ble metodene gjort om til å hente ut reell dynamisk data. Dynamisk utseende gikk ut på å få hele nettsiden til å se bra ut uansett hvor stor nettleseren var. Det som ser bra ut på en stor pc-skjerm ser ikke bra ut på en telefon, og det var i denne fasen vi gjorde de største endringene på utseendet for å få nettstedet til å se bra ut på tvers av enheter. Under denne fasen så var testing med mobil svært viktig og at utseende ble pent i alle størrelser. Bootstrap gjorde dette litt lettere for oss Testing Underveis i utviklingen av dynamisk innhold og utseende var testing og retting av feil en viktig del. Ettersom vi brukte extreme programming -metoden ble simultan testing og utvikling nødvendig for å få fremgang. Dette er en viktig del av utviklingsprosessen og resulterte i at mange feil og mangler ble oppdaget og rettet. Man kan aldri garantere at det ikke finnes flere feil eller mangler, men grundig testing minsker sannsynligheten for at dette eksisterer. Testingen av produktet ble utført som brukertester, dette er forklart nærmere i Testdokumentasjonen. 8

21 1.2.5 Backend Parallelt med utviklingen av prosjektet ble det opprettet en backend for å kommunisere mellom databasen og klienten. Dette grensesnittet er utviklet etter og på bakgrunn av pasientenes grensesnitt, samt at det er utenfor oppgavens omfang, og kan derfor inneholde noe som kan oppfattes som dårlig programmeringsskikk. Det ble tidlig i prosessen avklart at design og funksjonalitet på klientsiden var hovedprioritet og at en backend bare var et pluss. Backend har derfor ikke noen spesifikke krav i kravspesifikasjonen, og heller ikke gjennomgått noen form for enhetstest Dokumentering og kommentering Dokumentering og kommentering er den fasen som er helt til slutt før prosjektet skal leveres. Selv om noe dokumentasjon og kommentering er blitt gjort underveis så er det vanlig at en god del av dokumentasjonen, spesielt prosessdokumentasjonen, er skrevet etter at utviklingen er ferdig. Her var det brukerveiledningen, testdokumentasjonen, prosess- og produktdokumentasjonen som stod i sentrum Faglige utfordringer Vi har støtt på mange faglige utfordringer, blant annet at vi ikke hadde noen forkunnskaper om rammeverkene vi har brukt. Den største utfordringen vi hadde var at gruppen ble redusert fra fire personer til to. Dette skjedde etter at kravspesifikasjonen ble laget, og vi som ble igjen fikk da enda større ansvar. Vi konkluderte med at prosjektet var gjennomførbart etter å ha evaluert kravspesifikasjonen på nytt. Det vi har lært tror vi at vi kommer til å få bruk for senere i livet da det virker som store deler av fremtiden baserer seg på internettapplikasjoner. Nesten hver eneste uke kan man lese om nye applikasjoner og løsninger som kommer som skytjenester eller webløsninger. Vi ser derfor på de utfordringene og læringskurven vi har hatt som et viktig steg mot fremtiden Oppbygning Vi har valgt en oppbygning av klientsiden som er kjent som SPA. Hovedtanken med en slik oppbygning er at du aldri skal forlate siden du er på, innholdet skal kun oppdateres. Dette er en viktig faktor for å redusere datatrafikken til mobiler og nettbrett som ofte benytter mobil-nett. Tjenersiden er bygget opp med en klassisk MVC-struktur, som returnerer hovedsiden og de partielle nettsidene Viktige valg Gjennom prosessen har vi måttet ta noen viktige valg ang. design og funksjonalitet, da designeren ikke alltid ga full informasjon om alle funksjonaliteter. Vi har blant annet tatt valget om animasjon og støtte for slide på mobil og nettbrett. Vi har noen funksjoner som vi gjerne skulle hatt med, som push for meldinger, kalender, administrere tilgang, og mer. Dette var dessverre ikke mulig for oss å få på plass på denne tiden. Vi har også valgt å prioritere forespørslene fra oppdragsgiver om diverse sider de gjerne ville ha klare til presentasjoner. Administrator- og Ansvarlig-delen av produktet er kun ment som et tillegg for nettstedet slik at den er lettere å utvikle. Oppdragsgiver har også spesifisert at nettsidens grafiske verdi i funksjoner og design er viktigere enn backend, da hele denne delen vil bli erstattet ved videre utvikling uavhengig av resultatet. 9

22 Ekstra vanskelig Noe av det vi syntes var ekstra vanskelig å få til var: Få nettsiden til å ligne og oppføre seg slik designeren ville. Implementere slide/swipe med animasjon for mobil og nettbrett. Forstå AngularJS og hvordan den fungerer ved MVVM -strukturen. Mye av designet var svært vanskelig å få laget om til nettsider for desktop, nettbrett og mobil. Det vanskeligste lå i det dynamiske og i forskjellige funksjoner som designeren gjerne ville ha med. Swipe med animasjon er noe av det vanskeligste vi har implementert i JavaScript. Her skal den håndtere at brukeren drar i siden, animere når det slippes, og gjøre beregninger slik at animasjonen blir riktig. Forståelsen av AngularJS var ekstra vanskelig å bygge opp ettersom det er et stort og komplekst rammeverk. Angular er ganske lett å bruke, men samhandling med å hente dynamisk data fra server og få alt til å skje i riktig rekkefølge og til rett tid var ekstra vanskelig. AngularJS bruker MVVM -struktur, noe som vi heller ikke kjente til og som gjorde det litt vanskeligere å forstå hvordan det fungerte. 1.3 Extreme programming Som systemutviklingsmetode brukte vi extreme programming, heretter kalt XP. Denne metoden er utviklet for å være så fleksibel som mulig. Dette innebærer at man er åpen for mulige forandringer og bruker liten tid på dokumentasjon før utviklingen av produktet starter. XP baserer seg på fem verdier: kommunikasjon, enkelhet, tilbakemelding, mot og respekt. En viktig del i XP er testing. Vi testet koden vår som om vi var litt slemme brukere, slik at vi forsikret oss om at brukerne alltid ville få en god opplevelse uansett hva de kom til å gjøre. Denne testemetoden var svært viktig for produktet ettersom nettstedet er den viktigste delen for pasienten, og at det er den visuelle delen som skal videreutvikles av oppdragsgiver. Fleksibiliteten til XP har vært svært viktig og gjorde det mulig for oss å utvikle utgaver som kunne bli vist frem. Det gjorde også at vi tapte svært liten tid når et par av punktene i kravspesifikasjonen ble endret/fjernet og kunne implementere nye punkter istedenfor. 1.4 Kravspesifikasjonen og dens rolle Kravspesifikasjonen har endret seg minimalt fra første versjon. Vi har tatt bort punktet om at vi skal ha med en kalender og at koden skal valideres i W3 sin WCAG Authenticator. Dette er ikke bare fordi vi ikke har implementert deler / ikke validert, men av den grunn at oppdragsgiver har gitt beskjed om at vi ikke skal implementere kalenderen og at Angular gjør at validering ikke er mulig. Grunnen til at kalenderen ble valgt bort var at oppdragsgiver så på implementeringen som vanskelig og at funksjonaliteten ikke var nødvendig for produktets formål. Kravspesifikasjonen samsvarer bra med produktet som produktdokumentasjonen omtaler. Vi har implementert alt som er listet opp under kravene som skal og bør være med. Det har også blitt lagt til en del funksjonalitet som ikke finnes på den første versjonen av kravspesifikasjonen. Alle funksjonene som finnes er ikke nødvendigvis på kravspesifikasjonen ettersom vi regner de som en del av de andre punktene, eller at de ikke er store/viktige nok til å få sitt eget punkt. Vi kan derfor konkludere med at kravspesifikasjonen ga grunnlag for oppgaven og utviklingsprosessen vår, men den definerer derimot ikke hele oppgaven, da vi ville ha fleksibilitet istedenfor å følge kravspesifikasjonen slavisk. 10

23 1.5 Ansvarsfordeling Det var under utviklingsfasen at ansvarsfordelingen tok rot. Helt i starten av utviklingsfasen så virket det som at lå vi dårlig an og var derfor helt nødt til å ta ansvar. Dette presset gjorde at vi valgte å ikke ha en leder/sjef som delte ut oppgaver, men at hver person tok ansvar for å løse en del/oppgave. Denne måten å utvikle på krever at man har god kontakt og kan stole på hverandre. Dette var også grunnen til at extreme programming ble utviklingsmetoden vi valgte. Som et resultat av at vi jobbet ved siden av hverandre så fikk vi en tidlig bekreftelse på at begge parter la like mye tid og energi i dette prosjektet. Det å få en slik bekreftelse har vært svært viktig, da det ga grunnlaget for at vi kunne arbeide videre uten en leder/sjef, men som likestilte. Utover i utviklingensfasen så fortsatte vi med denne måten å fordele oppgaver. Med en gang man var ferdig med en oppgave, så var det bare å velge noe annet. Med den gode kommunikasjonen kunne vi også raskt finne ut hvilke typer oppgaver hver av oss hadde mest erfaring med, og kunne fordele det slik. Dette var en enkel og naturlig måte for oss å fordele oppgavene og ansvaret på. Vi jobbet hovedsakelig med oppgavene som vi hadde ansvar for, men hjalp hverandre med å løse problemer på tvers av oppgavene. Det er lett at man ender opp med å jobbe adskilt med hver sin oppgave, men vi jobbet godt sammen og dro nytte av at vi satt ved siden av hverandre. Denne ansvarsfordeling var et biprodukt av at vi bare var to personer som jobbet sammen på dette prosjektet. Gjennom hele utviklingsprosessen og dokumentasjonen har vi fordelt ansvaret på denne måten. Det var en risiko knyttet til denne ansvarsfordelingen, men god jobbing har gjort at det har gitt uttelling. 11

24 1.6 Avsluttende del I denne delen av dokumentet vil vi komme med egne meninger om forskjellige deler av hovedprosjektet og vår opplevelse av prosjektet Resultatet Vi er svært fornøyd med hvordan produktet ble til slutt. Før vi startet med utviklingen av produktet (etter at vi ble to på gruppen), så virket oppgaven for stor for to personer. Dette ville vi prøve å motbevise for vår egen del, og vi mener at vi har lyktes med det. Produktet har fått den funksjonaliteten og designet som oppdragsgiveren var ute etter, og har blitt laget etter deres ønsker. Det at vi samtidig som å ha tidspress fra starten av klarte å finne tid til å lage små prototyper som oppdragsgiver kunne vise frem, var for oss veldig tilfredsstillende Prosessen Prosessen vår har vært veldig lærerik og spennende. Vi har lært utrolig mye og er rimelige sikre på at vi vil få bruk for denne kunnskapen fremover. Det å jobbe på en så effektiv og ryddig måte som vi gjorde var den eneste grunnen til at resultatet har blitt som det har blitt. Vårt inntrykk av prosessen er at den startet dårlig, og bare blitt bedre og bedre. Vi jobbet kontinuerlig med dette prosjektet utenom et lite avbrekk i påskeferien grunnet eksamen i et annet fag, som man kan se i Figur 2. Denne informasjonen er hentet fra Git og er autogenerert. Røde verdier er kodelinjer som er slettet og/eller endret, og grønne verdier er linjer som er lagt til. Figur 2 Statistikk generert fra Git Fremtidig bruk Det virker rimelig sannsynlig at vi kommer til å jobbe videre med dette produktet for oppdragsgiver. Vi har blitt tilbudt videre arbeid - for det motstående grensesnittet for leger og jordmødre, noe som virker veldig interessant for oss på bakgrunn av denne erfaringen. Oppdragsgiver kommer til å bruke denne prototypen for flere videre presentasjoner, og selv kanskje bruke den i det endelige produktet. Dersom produktet vårt blir en del CSAMs større sluttprodukt håper vi å kunne kjenner igjen noe når vi selv får barn. 12

25 1.7 Oppdragsgiver sine meninger Stian og Petter har i løpet av de siste månedene hjulpet oss i CSAM med å utvikle en prototype for det som skal bli et nasjonalt digitalt helsekort for gravide kvinner. Både Stian og Petter har vært svært delaktige gjennom hele prosjektet, og de har levert en meget funksjonell prototype basert på våre krav, design og spesifikasjoner. Begge to har vært veldig løsningsorienterte og de vist stor interesse, god teknisk forståelse og meget bred kunnskap innen webarkitektur, webutvikling og design. Løsningen Stian og Petter leverte lever opp til våre forventningene på alle måter og vi er veldig fornøyd med resultatet. Prototypen er både funksjonell på PC, nettbrett og mobil, den har en god arbeidsflyt, god responstid og den har blitt godt tatt i mot hos våre testere. Vi er veldig fornøyd med jobben Stian og Petter har gjort for oss, og vi ønsker begge to lykke til. - Thorsten Pørscke, Creative Director at CSAM Health AS 13

26 14

27 Produktdokumentasjon 2 I dag må gravide kvinner i Norge fylle ut og ta med seg et fysisk skjema, et A4-ark, til hver eneste undersøkelse de går til under svangerskapet. Dette skjemaet inneholder en mengde relevant informasjon om svangerskapet og er av stor betydning for legenes videre avgjørelser. Om skjemaet blir glemt, mistet eller ødelagt må legene utføre et fåtall undersøkelser på nytt og/eller basere videre kontrolldata ut i fra hva som er normalt for norske gravide kvinner. Det er ingen tvil om at dagens teknologiske nivå tillater, og forventer, en digitalisering av denne prosessen, og det er dette CSAM Health AS (CSAM) nå går inn for å gjøre på nasjonalt basis. Denne produktdokumentasjonen vil ta for seg produktet som er laget, hvordan den er satt opp og hvilke valg som er tatt med hensyn til design og funksjonalitet. Produktdokumentasjonen vil være noe teknisk og det anbefales at leseren kjenner til vanlige IT-begreper. For å forstå produktets virkemåte er det også viktig å kjenne til de teknologiene som er brukt. Hovedsakelig er produktet laget ved hjelp av JavaScript, C#, HTML og CSS, men vi har også brukt blant annet AngularJS og Bootstrap til å få ønsket funksjonalitet. Dokumentasjonen inneholder også en introduksjon til de viktigste rammeverkene. CSAM har tidligere benyttet egravida som kodenavn for prosjektet, noe som vil være tydelig diverse steder i kildekoden. Dette er dog ikke en identifikator på tjenesten. 2.1 Produktbeskrivelse Et av CSAM s prosjekter går ut på å digitalisere det norske helsekortet for gravide kvinner. Prosjektet er i en tidlig planleggingsfase og krever noe politisk arbeid, samt samarbeid med deler av helsevesenet i Norge, for å få prosjektet gyldig og klinisk korrekt. Som en del av CSAM s større prosjekt er det omtalte produktet en fungerende prototype av pasientenes brukergrensesnitt, som både er ment å fungere som et utgangspunkt for videre utvikling, og som en visuell prototype til demonstrasjonsbruk. Produktet har allerede vært i bruk som en prototype og blitt vist frem som en pitch flere ganger, tilsynelatende med stor suksess. Produktet er i hovedsak laget som et nettsted/webapplikasjon med hovedfokus på design og støtte for mobile enheter. I tillegg til design og funksjonalitet på klientsiden for pasienter er det også mye som skjer bak kulissene på tjeneren. Data behandles, prosesseres og lagres på en backend, i tillegg til at det er opprettet to eksterne prosjekter for administrasjon av data og legevirksomhet. Dette bidrar til at leger og gravide sparer tid og at informasjonen man trenger alltid er tilgjengelig. Hovedfokuset med dette produktet har vært å balansere ønskene fra grafisk designer og fra prosjektansvarlige, både for medisin og system. Det er viktig å skille mellom hva som er hva innenfor produktet som leveres, som i bunn og grunn inneholder tre separate produkter. 15

28 Det første produktet, som er fundamentet for prosjektet og det eneste som er innenfor oppgavens faktiske omfang, kalles Digitalt Helsekort for Gravide, forkortet DHG. Dette produktet er pasientens portal til løsningen, altså brukergrensesnittet og tjenerdelen som håndterer alt av det pasienten kan interagere med, og vil i denne dokumentasjonen omtales som Pasientproduktet. Det totale prosjektet inneholder et grensesnitt for leger, jordmødre og andre personer ansvarlige for informasjon rundt et svangerskap. Ettersom pasienten får mulighet til å se informasjon, oppdatere noe data, og sende meldinger med leger og jordmødre i sin egen løsning kreves det at disse ansvarlige menneskene også har et eget grensesnitt som kan behandle dette. Dette grensesnittet er essensielt, men utenfor kravspesifikasjonens omfang. Under utvikling av pasientens grensesnitt ble det likevel tydelig at det var nødvendig med grensesnittet for ansvarlige for å få en fungerende prototype, selv for demonstrasjoner, og dette er dermed opprettet som et sub-produkt av selve prosjektet. I dette dokumentet vil det omtales som Produktet for ansvarlige. Det tredje produktet av prosjektet håndterer overordnet data, og fungerer som en portal for systemutviklere til å observere og lettere videreutvikle/feilsøke hva som faktisk skjer bak kulissene, og hvordan data ender opp. Mye av funksjonaliteten som nå ligger i produktet for ansvarlige stammer opprinnelig fra dette produktet. Som en del av kravspesifikasjonen skal pasienter logge inn med fødselsnummer og pin-kode som en midlertidig løsning som simulerer bruken av MinID, BankID og andre offisielle muligheter. Administrasjonsgrensesnittet fungerer dermed i denne løsningen som et grensesnitt der utviklere blant annet kan opprette mennesker i et simulert folkeregister, og vil heretter omtales som Administrasjonsproduktet. 2.2 Sentrale datastrukturer Det er benyttet to forskjellige datastrukturer i sluttproduktet. Tjeneren bruker en vanlig MVC-struktur, som var oppgitt i kravspesifikasjonen. MVC er veldig vanlig å bruke i objektorienterte programmeringsspråk slik som C#, som er benyttet på tjeneren. Systemet følger MVC fullt ut på både produktet for ansvarlige og for administratorer, men kun på tjenerdelen av pasientproduktet. Pasientproduktets klientside bruker strukturen MVVM, som er en litt mindre kjent struktur. MVVMstrukturen er foretrukket ved bruk av AngularJS og minner mye om MVC. Nettstedet pasientene benytter er en Single Page Application(SPA) hvor AngularJS tar hånd om å hente og erstatte partielle sider inn i nettleserens innhold. Fordelen med MVVM ovenfor en standard MVC-oppbygning på dette grensesnittet er at det er mer rettet mot et event-drevet oppsett. Hovedsakelig snakker Model og View kun med ViewModel og kjenner ikke til hverandre. 16

29 2.3 Introduksjon til rammeverk AngularJS AngularJS 1 er et open source JavaScript-rammeverk, som blir vedlikeholdt av Google og deler av brukermassen i fellesskap. Målet med AngularJS er å endre statiske HTML-sider til å støtte dynamisk endringer. Rammeverket kjører etter at DOM er ferdig med å laste, og består av tre faser. Den første fasen lager en ny injector 2 på siden som kaller på metoder, instansierer typer, og henter moduler og objekter. Fase to er kompilering av siden, her leter den opp alle direktiver (eksterne attributter). Den siste fasen linker direktivene til scope 3, et objekt som representerer applikasjonens modell. AngularJS gjør det lett å manipulere DOM-elementet og har også en del innebygget sikkerhet. Den hjelper også til med å lage en SPA og gjør at nettsiden etterligner MVC-strukturen. Figur 3 Hvordan man spesifiserer sider og kontrollere I routeprovider AngularJS implementerer SPA på pasientproduktet. Dette gjøres via routeprovider som kommer fra modulen ngroute. Denne leser adressefeltet og har et sett med regler for hvor den skal hente de forskjellige nettsidene og hvilken kontroller som hører til. Dette gjøres bak kulissene av AngularJS og man trenger kun å lage partielle sider. routeprovider endrer på den indre delen av elementet som har attributten ng-view. Dette gjør at det for brukeren oppleves som at man aldri forlater siden; den bare endrer seg. Pasientproduktet bruker to moduler, TourApp og egravidaapp, som nettstedets applikasjon. Disse modulene ligger linket i TourIndex.cshtml og Index.cshtml, via attributten ng-app. Det brukes flere moduler enn disse to, men de blir inkludert i TourApp - og egravidaapp -modulene. Ulike moduler kan enten brukes som nettstedets app eller så kan de bli brukt i andre moduler. shared 4 er en modul som brukes av både TourApp og egravidaapp. Det Figur 4 Eksempel på ng-app Figur 5 Eksempel på en controller shared - Shared.js, linje 10 17

30 som ligger i modulen shared er da tilgjengelig for begge, dette gjelder for alle direktiver og kontrollere som ligger i shared -modulen. Når kontroller nevnes, så er det snakk om en modul sin controller. Kontrollere får hvert sitt scope /område hvor funksjonaliteten ligger. Hva som ligger i slike kontrollere kommer helt an på hva kontrolleren skal brukes til. Kontrolleren blir benyttet av en eller flere nettsider, dette kan gjøres enten via routeprovider eller som en attributt, ng-controller, på nettsiden. I pasientproduktet vil alle nettsider bli tildelt en kontroller via routeprovider. Moduler i AngularJS bruker direktiver, directive, ved at navnet til direktivet kan legges på et hvilket som helst element som en attributt ( ngswipe = ng-swipe ). Direktivet inneholder gjerne et sett med funksjoner som man vil implementere flere steder. I motsetning til en kontroller så har ikke et direktiv et eget scope /område, men tar imot scopet som er i bruk. AngularJS vil kalle på direktivet og motta funksjonen som direktivet returnerer, og kjøre denne funksjonen. Figur 4 Eksempel på et direktiv For eksempler på direktiver og kontrollere anbefales det å se litt på oppbygningen av disse i Shared.js eller controller.js. Filene er godt kommentert (på engelsk) og vil gi bedre innsikt i hvordan direktiver og kontrollere er laget og hvordan de ser ut. 18

31 2.3.2 Bootstrap Bootstrap 5 er et rammeverk for å gjøre det enkelt å tilpasse nettsider for mobiler og nettbrett. Det inneholder både JavaScript-, HTML- og CSS-funksjonalitet for å modellere et passende utseende. I tillegg til de forskjellige grafiske posisjoneringene håndterer det også blant annet modale vinduer, popover, og alerts.det tilhørende CSS-dokumentet inneholder ferdiglagde klasser, ikoner og funksjonalitet for posisjonering i forskjellige størrelser, og er det som brukes over store deler av pasientproduktet for å tilpasse vinduet til både datamaskin, nettbrett og mobil. Dette er et responsivt, mobil-først flytende rutenettsystem som fordeler bredden av skjermens innhold inn i tolv forskjellige ruter. Ved bruk av kodesnutten i Figur 7 kan det illustreres hvordan Bootstrap håndterer de ulike situasjonene i figurene 8,9 og 10. Bootstrap opererer med fire forskjellige størrelser med Figur 7 - Kodesnutt Figur 8 col-md-3 hvert sitt forkortede navn, Large - lg, Medium - md, Small - sm, og Extra Small - xs. Disse fire håndterer utseende i sine respektive bredder, der Large er alt over og inkludert 1200px, Medium er fra og med 992px til 1200px, Small er fra og med 768px til Figur 9 col-sm-6 992px, og Extra Small er alt under 768px. Dersom nettleseren har en bredde på 1100 piksler, som er innenfor spekteret til Medium, så benyttes kolonne-klassene med prefikset col-md-* til å definere posisjoner og plass. Som vist i Figur 8 er det blant annet brukt col-md-3 som klasse for alle de fire innholdene som skal vises på nettsiden. Med tanke på at det alltid er tolv plasser ved siden av hverandre i hver rad kan det dermed tenkes at det er plass til fire versjoner av elementer med Figur 10 col-xs-12 klassen col-md-3 i bredden for Medium, da tolv delt på tre er lik fire. Ved å kjøre kodesnutten i en nettleser med en bredde som faller innenfor Medium blir det vist med alle fire innhold ved siden av hverandre som vist i Figur 8. Dersom man endrer størrelsen på nettleseren til den faller innenfor Small eller Extra Small med samme kodesnutt vil de respektive klassene igjen definere plasseringene, der hvert innhold i dette eksempelet tar opp seks av tolv plasser i Small, og tolv av tolv plasser i Extra Small. Dette blir seende ut som i Figurene 9 og 10. Alle figurene er representasjoner av samme kodesnutt i forskjellige bredder

32 2.3.3 Entity Framework 6 Entity Framework er et open source ORM-rammeverk under.net som fungerer som et hjelpemiddel ved oppretting av relasjonsdatabaser på ulike måter. Til denne applikasjonen er det benyttet code first - prinsippet som tillater utvikling av objekt-klassene før databasemodellene, som da vil genereres automatisk. Ved videreutvikling av databasen og modellene er det anbefalt å fortsette med denne strukturen. 2.4 Biblioteker og programvareutvidelser jquery jquery 7 er et JavaScript-bibliotek som skal gjøre det lettere å skrive JavaScript-kode, manipulere HTML dokumentet, animere og behandle hendelser. Dette biblioteket er det mest brukte JavaScript-biblioteket Masonry Masonry 8 er et JavaScript-bibliotek for generering av posisjoneringsrutenett. Dette biblioteket plasserer elementer basert på den horisontale plassen som er tilgjengelig. Masonry inkluderer animasjon når elementene flytter på seg, slik at nettsiden får en god og fin flyt når brukeren endrer på bredden av vinduet. I denne applikasjonen er Masonry kun benyttet i Min Dagbok mmenu mmenu 9 er en programvareutvidelse til jquery for nettsider egnet for nettbrett og mobil. Denne lager en app -lignende meny og krever kun én linje med JavaScript-kode for å bli implementert. Pasientproduktets hovedmeny er et resultat av denne utvidelsen, med modifisert grafisk design Highcharts Highcharts er et JavaScript-rammeverk som lager visuelle og interaktive grafer. Dette rammeverket er gratis for ikke-kommersielle produkter, noe som krever en kjøpt lisens ved eventuell publisering av nettstedet. Highcharts ble valgt på grunnlag av dens støtten for alle nettlesere på mobiler, nettbrett og skrivebord, samt at det er meget gode hjelpemidler og kodereferanser på nettsiden 10. I pasientproduktet blir dette både benyttet for tidslinjen i Mitt Svangerskap og for Svangerskapskurve jquery UI jquery UI 11 er et JavaScript-bibliotek som gir støtte for å implementere en lang rekke med forskjellige funksjoner, blant annet interaktive knapper, dialoger, menyer og fremdriftslinjer. Fra bibliotekets nettsted er det mulig å egendefinere akkurat hvilke elementer som skal være med, og til dette prosjektet har kun DatePicker blitt brukt

33 2.5 Struktur Nettstedet, som i utgangspunktet er optimalisert for mobile enheter, er bygget opp på prinsippene til en SPA. Dette vil si at applikasjonen kun overskriver og bytter ut deler av nettsiden ved navigasjon fremfor å laste ned et nytt sett med komplette dokumenter. Ved å benytte denne teknologien vil ikke nettleseren forstå at det navigeres mellom forskjellige nettsider, da adressefeltet ikke oppdaterer seg, noe som også prinsipielt gjør det umulig å bruke frem- og tilbake-knappene i nettleseren. For å motvirke denne sideeffekten er det benyttet JavaScript til å oppdatere adressefeltet med en egendefinert tekst ( /#/ ), som nettleseren tolker som et anker; altså uten å faktisk oppdatere nettsiden. Den største fordelen med en slik implementasjon er at datamengden er sterkt redusert. For hver av nettsidene erstattes kun innholdet i én enkel div-tagg i stedet for å representere hver nettside med hver sin head- og body-tagg. Navigasjonslinjen og menyen blir altså ikke lastet inn flere ganger. En positiv effekt av at nettleseren ikke oppdaterer innholdet på hver side er eliminasjonen av blinking rett før nettleseren laster ned en ny side. Denne effekten gir en følelse av at man faktisk bruker en reell applikasjon, spesielt på mobile enheter. 2.6 Navigasjon og tilbakemelding På et nettsted er det viktig at man enkelt kan navigere mellom de forskjellige nettsidene som finnes. For større nettsteder ville det vært logisk å bruke et hierarki som hovedstruktur. På denne måten er det lett å vite hvor en befinner seg, samt at det er lettere å finne relaterte og relevante nettsider. For denne tjenesten kreves kun en overfladisk struktur, der tilnærmet samtlige individuelle nettsider er tilgjengelige fra den globale sidemenyen vist i Figur 11(meny). Til enhver tid er det mulig å nå alle andre nettsider med maksimalt tre klikk, noe som var et uskrevet mål i seg selv. Navigasjonsfeltet øverst på skjermen vil alltid vise hvilken nettside man befinner seg på, og samsvarende felt i hovedmenyen vil være markert. Først når brukeren klikker på et valg i hovedmenyen blir prinsippene for Single Page Application satt i kraft, da kun spesifikke deler av nettsidens nåværende innhold blir byttet ut med destinasjonens innhold. Menyen, så vel som navigasjonsfeltet, er en del av index og vil aldri bli lastet inn mer enn én gang. Fra menyen har man tilgang til nettsidene Min Profil, Mitt Svangerskap, Medisinsk Info, Meldinger, Min Dagbok, Ultralyd, Tidligere Svangerskap og Veiviser. Veiviseren kan åpnes ved å klikke på tannhjulet. I menyen har man også mulighet til å velge Logg ut og funksjonen for Endre profilbilde. Ved siden av menyvalget Meldinger i Figur 11 blir det også vist hvordan Figur 5 - Meny notifikasjoner viser seg for brukeren. Disse notifikasjonssymbolene viser bl.a. hvor mange uleste meldinger som ligger i meldingsboksen. Symbolet vises konsist på flere deler av applikasjonen; i menyen, på nettsiden Mitt Svangerskap (for meldinger), og på nettsiden Meldinger (på listen over de forskjellige samtalene). Dersom man har uleste meldinger fra forskjellige samtaler blir notifikasjonssymbolet i hovedmenyen og på Mitt Svangerskap addert opp til det totale antall uleste meldinger, mens hver samtale på nettsiden Meldinger vil vise riktig antall. Til fremtidig utvikling kan det også tenkes at blant annet Ultralyd vil vise notifikasjoner når ultralydbilder eller - video er tilgjengeliggjort av legen. 21

34 2.7 Modeller av oppsettet Figur 6 Sammenheng mellom produktenes nettsider 22

35 Figur 7 Modell av databasen 23

36 2.8 API API står for application programming interface (applikasjonsprogrammeringsgrensesnitt på norsk). En API spesifiserer hvordan to komponenter(programvare) interagerer med hverandre Web-API Web-API er en API som er tilgjengelig for både en nettleser og web-serveren. Produktet inneholder en Web-API-komponent, WebAPIController, i pasientproduktet. Målet til denne API-komponenten er å ha tilgang til å sende og motta data. WebAPIController tar imot forespørsler via HTTP-protokollen. Disse forespørslene kan inneholde data som WebAPIController -komponenten skal behandle, for så å gi objekter tilbake i henhold til dataene som ble mottat. Denne implementerer et lag med sikkerhet, dette er forklart nærmere i punkt Sikkerhet JSON og XML JSON står for JavaScript Object Notation og XML står for Extensible Markup Language. Dette er to vanlige måter å formatere objekter som sendes over HTTP. Hovedsakelig bruker WebAPI-komponenten, ref. punkt Web-API, XML når den sender objekter. Konverteringen fra lister av objekter eller objekter til XML eller JSON blir gjort automatisk. Grunnen til at objekter blir formatert på denne måten er at dette er lett for JavaScript å håndtere. Både XML og JSON blir til JavaScript-objekter automatisk, da disse formene stemmer overens med syntaksen som JavaScript bruker Sikkerhet Sikkerheten som blir implementert i WebAPIController -komponenten er ganske simpel. Denne sjekker hvem som har bedt om data via en cookie og sammenligner dette med hvem som eier dataene som forespørselen ber om. Dette gjør at man ikke kan hente andre brukere sin data. Det er også sjekk på hva som sendes inn, så om tjeneren forventer et tall og får tekst så vil klienten få en 404-error(ikke funnet) i retur. Man kan ikke kontakte komponenten hvis man ikke er logget inn. I nettstedets konfigurasjonsfil web.config er det definert at dersom noen kommuniserer med tjeneren uten å være autentisert vil de automatisk bli navigert til login. Dette gjelder hele pasientproduktet URL 12 For å få kontakt med WebAPIController så må adressefeltet (URL) være korrekt. Denne ligger alltid på ~/WebAPI/Funksjonsnavn[/verdi1][/verdi2] hvor ~ er basen (alt før.com,.no,.net osv). Klammer, [ og ], betyr at det i funksjonen er gitt hvor mange verdier den skal motta i adressefeltet. Funksjonsnavnet er navnet på funksjonen som aksesseres. Funksjonene har annoteringen [Route( Navn )], og kan også inneholde verdier. For eksempel vil annoteringen [Route("GetMessages/{id:int}/{amount:int}")], som vist på figur 14, vise til funksjonen GetMessages, der første variabel vil være id i form av et heltall (int), og hvor andre verdi er heltallet amount som i denne funksjonen definerer hvor mange meldinger som skal hentes. Figur 8 Funksjon fra WebAPIController 12 URL - Uniform Resource Locator 24

37 2.8.5 DTO DTO står for Data Transfer Object som betyr at objektet er laget for å sendes. Fordelen med å ha slike objekter er at serveren automatisk konverterer JSON- og XML-objekter som har riktig oppsett, til DTO - objekter. DTO-objektene blir automatisk konvertert til XML- eller JSON-format når de sendes fra server, dette trenger ikke å bli gjort eksplisitt. Kommunikasjonen mellom kontrolleren til nettsiden og serveren bruker objekter (modeller) som har navn som slutter på Dto, eller lister av disse. Ved å bruke DTOobjekter kan man også unngå å sende for mye unødvendig data. Dette kan her illustreres ved at modellobjektet som benyttes i databasen for svangerskapet (HealthCard.cs) inneholder veldig mange variabler, mange av dem totalt uinteressante for pasientens grensesnitt, samtidig som det spesifiserte DTO-objektet som sendes ned kun inneholder variabler som skal benyttes på grensesnittet. 25

38 2.9 Produkt Kjernefunksjonalitet Login All navigasjon på nettstedet krever at brukere er innlogget. Dersom brukere prøver å direkte aksessere en nettside uten å være autentisert vil de umiddelbart bli navigert til Login. Denne informasjonen blir holdt kryptert i en cookie, og blir verifisert med personens fødselsnummer som en midlertidig løsning for en fremtidig versjon med BankID/MinID. Når en pasient logger inn vil tjeneren gå gjennom tre faser for å definere hvordan brukeren skal logges inn. Både Pasient - og Ansvarlig -objektene arver fra det virtuelle objektet Person i denne tjenesten, noe som gjør dette til en enkel sjekk. Tjeneren vil ved login først sjekke om det eksisterer et Person - objekt for dette fødselsnummeret, og vil deretter sjekke om dette objektet er av type Pasient. Dersom dette eksisterer, så er det ikke første gang brukeren logger inn på tjenesten, og de vil få returnert en cookie som videre tillater aksess på nettstedet, samt omdirigert til Mitt Svangerskap. Dersom pasienten ikke har logget inn på pasientproduktet fra før vil tjeneren kontrollere om personen er registrert i den lokale databasen av andre grunner, f.eks om personen er registrert som en lege eller en jordmor(ansvarlig). I dette tilfelle vil systemet først finne et Person -objekt for fødselsnummeret, men ikke et tilknyttet Pasient -objekt. Ettersom en Person er virtuell betyr dette foreløpig at personen må være av type Ansvarlig. For Ansvarlige å logge inn på pasientenes grensesnitt er foreløpig håndtert, men ikke støttet, da dette er utenfor prosjektets omfang i denne fasen. Om en pasient logger inn på pasientproduktet og tjeneren ikke finner et Person -objekt i den lokale databasen, altså at de verken er registrert som pasient eller ansvarlig, vil tjeneren rette seg mot det nasjonale folkeregisteret for å hente ut personinformasjon. Dette vil tjenesten fremtidig ha støtte for, men er i denne omgang kun simulert. Etter det er bekreftet at personen ikke finnes i det lokale systemet, og at personen faktisk eksisterer i folkeregisteret, så vil systemet opprette et Pasient-objekt for denne personen, basert på data hentet fra registeret. Når dette er fullført vil tjeneren returnere en cookie, samt omdirigere brukeren til tjenestens Veiviser. Ettersom Pasient arver fra det virtuelle Person -objektet er det gitt at pasienten nå også eksisterer i form av et Person -objekt i databasen, som vil benyttes ved neste innlogging Index Pasientproduktets klientside bruker Index som ramme. Dette betyr at Index alltid vil vises, og at den alltid vil ligge rundt de partielle sidene. Index er et resultat av at nettstedet er en SPA, og inneholder hovedsakelig en meny, navigasjonslinje og et åpent element der alle partielle sider legges, samt å inkludere/importere samtlige nødvendige JavaScript- og CSS-filer. Index er ansvarlig for å hente inn de partielle sidene i elementet som er gitt, samt å gi riktig kontroller til nettstedet. Hvordan dette gjøres kan leses om i punkt AngularJS. SPA delen er forklart i punkt 2.5 Struktur og menyen og navigasjonslinjen er forklart i punkt 2.6 Navigasjon og tilbakemelding. Opplasting av profilbilde benytter samme oppsett som i punkt Tidligere Svangerskap - Laste opp bilde. 26

39 2.9.2 Min Profil Min Profil er nettsiden som inneholder all generell informasjon tjenesten har lagret om brukeren. Tanken bak dette er å få samlet alt på et sted slik at pasienten selv kan endre/fjerne den informasjonen de vil. Informasjonen som er oppgitt kan også leger få tilgang til. Her har pasienten full kontroll over sin egen informasjon, og det de ikke vil skal lagres kan de velge å ikke fylle ut. Figur 9 Min Profil for store skjermer Oppsett og utseende Første gang nye pasienter logger inn på nettstedet vil de bli presentert med en veiviser og et førstegangsoppsett. Oppsettet og Min Profil er samme nettside, men ved hjelp av JavaScript er det noen ekstra funksjoner under oppsettet. Etter at siden har lastet inn hentes alt av nødvendig informasjon som allerede finnes i databasen med JavaScript. Under oppsettet kan noe av informasjonen være blank eller feil, som er grunnen til at Min Profil er inkludert i oppsettet. Informasjonen som blir endret under oppsettet eller ved en senere endring på Min Profil vil kun lagres når brukeren trykker Lagre Endringer. Utseende endrer seg i forhold til hvor stor skjermen er. Denne delen er helt avhengig av Bootstrap for å fungere Informasjonsflyt Mye av informasjonsflyten behandles av JavaScript via GET - og POST - metoder. Min Profil er koblet sammen med profilecontroller 13 som tar seg av informasjonsflyten. Når nettsiden er lastet ned vil to metoder bli kalt automatisk, den ene viser neste-knappen dersom man befinner seg under oppsettet, og den andre Figur 10 Min Profil for mobil henter informasjon fra databasen. Informasjonen sendes som et ProfileInfoDto -objekt formatert som XML. Dette gjør at JavaScript-koden som mottar objektet kan gå gjennom og hente ut navn og verdi fra objektet. Verdiene blir så plassert i sine respektive felt. Samme metode som JavaScript bruker for å motta et objekt blir benyttet for å lage og sende et objekt. Verdiene blir hentet fra feltene, et objekt blir opprettet basert på informasjonen, og alt blir sendt til tjeneren. Her vil WebAPI motta objektet og automatisk konvertere det til et ProfileInfoDto - objekt. Denne flyten av informasjon tar liten plass, er rask og gjøres asynkront. 13 profilecontroller - Shared.js linje:

40 2.9.3 Mitt Svangerskap Mitt Svangerskap fungerer som forside for hele løsningen, og er på mange måter et knutepunkt for all informasjon pasienten kan se. Denne nettsiden er kun tilgjengelig dersom pasienten har et aktivt svangerskap registrert i systemet, og viser da informasjon rundt kun dette svangerskapet. Informasjonen er privat, og det er kun pasienten og legene som får tilgang. Når siden lastes inn returnerer tjeneren et digitalt helsekort fra databasen, funnet med pasientens fødselsnummer. Det digitale helsekortet som blir mottatt (DTO-versjonen) inneholder alle variabler og data som skal vises for pasienten, inkludert noen verdier som ikke er direkte knyttet til helsekortet i databasen, blant annet antall dagbok-innlegg og meldinger Tidslinje-grafen Denne interaktive grafen skal illustrere hva som har skjedd gjennom svangerskapet for en pasient. Ved senter av grafen benyttes det et sektordiagram til å illustrere hvor langt gjennom svangerskapet pasienten har kommet, basert på datoer som siste menstruasjon og antatt termin. I grafen er det tatt utgangspunkt i at et svangerskap kan vare i opp til 42 uker, da det gjennomsnittlige svangerskap varer i rundt 40. Grafen er utviklet med JavaScript i vinduets kontroller 14 med rammeverket Highcharts, basert på illustrasjoner og bilder mottatt fra designer. Den ytterste ringen av grafen viser de ni Figur 11 Tidslinje-graf månedene pasienten går gjennom under svangerskapet, der mengden til bakgrunnsbildet viser hvor langt de er på vei. Den midterste ringen kan inneholde en rekke forskjellige punkter som hver representerer en hendelse i svangerskapet. I Figur 17 er det vist med to forskjellige punkter, der blå representerer en svangerskapskontroll, og grønn representerer en ultralyd. Dersom et punkt er valgt vil hendelsen presenteres med angitt informasjon under eller ved siden av grafen, videre forklart i punkt Representasjon av hendelser. Det er uttrykt ønske om støtte for flere enn kun to typer punkter, men dette skulle ikke være prioritert før senere. Her kan det tenkes at hendelser som prøveresultater og/eller annen kommunikasjon med legen har funnet sted, og vil presenteres med egne punkter med egne fargekoder. Hver hendelse blir registrert av lege/jordmor på produktet for ansvarlige, og blir hentet og inkludert sammen med helsekortet når nettsiden lastes inn av pasienten. De forskjellige typene hendelser inneholder forskjellige felter, og krever derfor separate handlinger og visningsmetoder. I databasen inkluderer samtlige hendelser helsekortets ID, dato for registrering, og ID en til den ansvarlige som registrerte hendelsen. Disse variablene er samlet i en super-klasse kalt GraphEvent, som GraphControlEvent og GraphUltrasoundEvent arver fra. På denne måten blir også alle hendelser samlet til én List<GraphEvent> -variabel i helsekortet. 14 pregnancycontroller - controller.js linje:

41 Representasjon av hendelser Som tidligere nevnt er det forskjellige informasjonstyper i de forskjellige hendelsene. Figurene 18, 19 og 20 viser de nåværende forskjellene mellom en svangerskapskontroll og en ultralyd. På bakgrunn av designerens tidligere ønske er det inkludert mulighet for de ansvarlige å legge til et stillbilde av en ultralyd i hendelsesdataene. Man kan klikke på bildet og bli tatt videre til Ultralyd, til tross for at siden foreløpig er statisk. Alle tre figurene er skjermdumper tatt med forskjellige bredder på nettleseren, som da også viser hvordan Bootstrap er benyttet til å håndtere visning av data. Figur 18 Mitt Svangerskap, datamaskin og nettbrett i landskap Undermenyen Figur 19 Nettbrett portrett Figur 20 - Mobil Figur 12 - Undermenyen Nederst på Mitt Svangerskap får pasientene vist en undermeny som gir diverse generell informasjon om graviditeten, som vist i Figur 21. Det første feltet leder brukeren videre til kurven til magens fundushøyde. Kurven blir videre forklart i punkt Svangerskapskurve / Mage- og Fundus-mål. Øverst i midten blir man presentert med antall meldinger fra legen, hvorav antall uleste meldinger vises som et notifikasjonssymbol. Ved å klikke her blir man omdirigert til meldingsboksen, beskrevet i punkt Meldinger. Øverst til høyre ser man en nedtelling av dager som er basert på datoene registrert med svangerskapet. Til å starte med er det tatt utgangspunkt i 282 dager fra siste menstruasjon etter Naegeles Regel, en dato som kreves ved registrering av svangerskapet. Nederst til venstre blir man presentert med antall prøveresultater for gjeldende svangerskap, og man blir her omdirigert til listen over undersøkelser, forklart i punkt Undersøkelser. Nederst i midten kan man se barnets antatte vekt og størrelse, noe legene registrerer i produktet for ansvarlige. Den siste boksen viser antall innlegg pasienten selv har skrevet i den implementerte dagboken, og leder videre til denne nettsiden, forklart i Dagbok. 29

42 Alle dataverdier i denne undermenyen er mottatt fra serveren i form av klassen HealthCardDto, hvor noe av informasjonen i dette DTO-objektet er opprettet kun for dette formålet; til tross for liten relevanse med helsekortet. Det råder noe tvil hvorvidt dette feltet kan klassifiseres som en meny da ikke alle feltene er klikkbare. To av feltene viser foreløpig kun informasjon uten å lede pasienten videre, noe som ødelegger noe for konsistensen i designet. Disse to feltene skal visstnok få mulighet til å lede til hver sin nettside i en senere versjon av applikasjonen Medisinsk Info Medisinsk Info er ansvarlig for å gi brukeren en rask måte å vise/endre informasjon om deres helse. Informasjonen som finnes på Medisinsk Info er indirekte knyttet til svangerskapet og kan være kritisk for pasientens graviditet. Alle endringer blir lagt til slik at man kan se endringshistorie i databasen. Pasientens medisinske informasjon vil på denne måten aldri slettes, noe som er veldig viktig for en lege. Medisinsk Info er også en del av oppsettet for førstegangsbrukere Informasjon Den medisinske informasjonen som nettsiden viser er kun basert på hva brukeren har lagret. Brukeren får ved denne siden en mulighet til å oppgi viktig informasjon tidlig. Dette sparer legen og brukeren tid på når det er ferdig utfylt ved første legetime. Nettsiden har ingen validering av informasjonen som er oppgitt, da dette i denne omgang ikke er innenfor oppgavens omfang. Informasjonsflyten til Medisinsk Info er ganske lik Min Profil, men bruker andre objekter og kall. Fremgangsmåten kan leses om i punkt Min Profil - Informasjonsflyt. 30

43 2.9.5 Meldinger Meldinger er utarbeidet for å gi pasienten og legen en enkel måte å holde kontakt på gjennom svangerskapet. Pasienter kan sende og motta meldinger i de samtaler som er registrert for hver pasient. For å unngå at én pasient kontakter flere forskjellige leger og jordmødre på eget initiativ, f.eks som en liten panisk handling, så er det kun administrator som kan opprette samtalene. Denne funksjonen vil i fremtiden bli styrt av de ansvarlige selv. Nettsiden er fleksibel og fungerer på tvers av enheter Kontroller Meldinger bruker messagecontroller 15 som vinduets kontroller. Kontrolleren har ansvar for å håndtere alle dynamiske endringer på nettsiden, dette gjelder både utseende og innhold. Den vil ta kontakt med WebAPIController (tjeneren) for å sende og motta informasjon. Dette er derimot bare en liten del av hva kontrolleren gjør. Informasjon som sendes mellom kontrolleren og WebAPIController er blant annet meldinger, samtaler, antall meldinger og nye meldinger. Denne informasjonen får kontrolleren tak i ved å bruke GET - og POST -metoder. Kontrolleren endrer også på css-verdiene på bakgrunn av nettleserens bredde. Dette brukes for å skille mellom hvordan det vises på nettbrett og datamaskin, og hvordan det vises på mobil Funksjonalitet Meldinger vil se litt forskjellig ut på mobil enn fra andre enheter. Dette er et resultat av at meldinger har mindre bredde for å vise innhold. Denne funksjonaliteten er essensiell for at nettsiden skal være mulig å bruke på mobiler. Nettbrett og datamaskiner vil derimot vise meldinger på samme måte. Disse store enhetene har plass til å vise både meldingene og samtalelisten på samme side. Nettsiden vil dele seg opp i to ulike vinduer for mobiler; de vil først få opp samtalelisten, og deretter meldingene til valgt samtale, som vist i Figurene 22 og 23. Ved å navigere til en samtale på mobile enheter vil menyknappen erstattes med en tilbake-pil, som benyttes for å komme tilbake til samtalelisten. Brukeren kan også utføre en swipe - bevegelse mot høyre for å gå tilbake til samtalelisten fra samtalen. Meldingene har en funksjon som blar automatisk ned, så når pasienten sender en melding vil meldingsvinduet bla ned til siste melding automatisk. Alle disse funksjonene er med på å gjøre bruken av meldinger så lett som mulig. Figur 13 Samtaleliste for mobil Figur 14 Samtale for mobil 15 messagecontroller - controller.js, linje:

44 2.9.6 Dagbok Min Dagbok skal gi brukeren en nettbasert dagbok som kun de skal ha tilgang til. Alle innlegg er kun ment for brukeren og er foreløpig ikke tilgjengelig for andre. På denne nettsiden vil man kunne se alle innlegg man har lagt til, samt muligheten til å legge til nye innlegg. Dagboken viser alle månedene hvor brukeren har innlegg, i tillegg til den måneden man er i - selv om det potensielt ikke er noen innlegg i den. Ved siden av månedens navn vises det antall innlegg i måneden. Innleggene legger seg på en tidslinje, slik at man får innleggene som er nyest øverst. Helt i toppen av tidslinjen finner man et plusstegn. Dette er knappen man skal trykke på hvis man vil legge til nye innlegg. Denne er uavhengig av hvilken måned pasienten befinner seg i, den vil alltid legge til innlegg på tidspunktet man lagrer innlegget. I fremtidige versjoner av tjenesten er det spekulert i om pasientens familie og barnets far skal få egne innloggingsmuligheter, og de vil da kanskje få tilgang til dagboken, om pasienten ønsker dette Masonry Masonry er et tredjeparts JavaScript-rammeverk som Min Dagbok bruker. Dette rammeverket er ansvarlig for å holde styr på hvor innleggene ligger visuelt. Nettsiden får en fin dynamikk ved nye innlegg og en god struktur på grunn av Masonry. Rammeverket vil sette innleggene på riktige plasser i forhold til hverandre når vindusstørrelsen endrer seg. Innleggene vil også ha en animasjon når dette skjer, som gjør at innleggene flyter til sine respektive plasser Valg av måned Å velge hvilken måned man vil se innlegg for kan gjøres på noen forskjellige måter. På nettbrett og datamaskiner vises piler til hver Figur 24 Navigasjon nettbrett/pc sin side, som vist i Figur 25. Ved å trykke på en slik pil vil man enten gå frem eller bakover en måned. Disse pilene er ikke tilgjengelig for mobile enheter, se Figur 24. Uansett hvilken enhet som benyttes kan brukeren alltid trykke på en måned for å se innleggene til den måneden. Mobil og nettbrett har også swipe -funksjon tilgjengelig for å velge Figur 25 Navigasjon mobil måned, dette blir forklart litt mer om i punkt Kontroller og direktiv. Alle dagbokinnlegg blir hentet ned ved første aksess, og kontrolleren vil selv arrangere innleggene i forskjellige måneder, og hente dem ut når pasienten navigerer mellom dem Modal Dagboken har en Modal for å legge inn nye innlegg. En Modal er en boks som legger seg over siden, som man kan se på Figur 26. Fordelen med å bruke en Modal for å skrive innlegg er at man klart ser hva som er fokus, hvor man skal skrive, og hva man skal trykke på for å lagre innlegget. Dagboken endrer ikke utseende når en Modal kommer frem, den blir bare liggende i bakgrunnen (noe mørkere). Figur 15 - Modal 32

45 Modal er implementert ved Bootstrap (.css og.js) og Bootstrap er ansvarlig for funksjonaliteten for å vise den frem. Lagring og opplasting av bilde er gjort av nettsidens kontroller (punkt Kontroller og direktiv). En annen fordel ved bruken av en slik Modal er at Bootstrap støtter alle enheter uansett størrelse Kontroller og direktiv Nettsiden Min Dagbok bruker JavaScript-kontrolleren diarycontroller 16 og et direktiv ngswipe 17. Hva en kontroller og et direktiv er blir forklart under punktet AngularJS. Direktivet blir på denne nettsiden kun brukt for listen over månedene. Denne delen av nettsiden vil ha en attributt som heter ng-swipe og direktivet vil bli koblet med listen, slik at pasienter med mobil og nettbrett kan utføre en swipe -bevegelse. Direktivets oppgave er å spore hvor brukere drar fingeren og gjøre at det som blir dratt vil følge med. Dette kunne blitt utført i kontrolleren, men som et direktiv så kan dette brukes flere steder, da veiviseren også bruker dette direktivet. Direktivet samarbeider tett med kontrollerene for å kunne lagre unna hvor langt brukeren har dratt i elementet. Dagbokens kontroller, diarycontroller er en av de få eksklusive kontrollere, altså at det kun er Min Dagbok som benytter den. De andre eksklusive kontrollere er for Meldinger og Svangerskapskurve. Den første oppgaven kontrolleren får, som skjer med en gang, er å hente månedene som skal vises. Kontrolleren tar kontakt med WebAPIController og får et objekt med de respektive dataene som brukeren skal se. Dette objektet som kontrolleren mottar er et DiaryMonthDto -objekt, og inneholder alt nettsiden trenger. Månedene hentes frem, og kontrolleren beregner hvor den skal plassere siste måned for å få den senterert til midten ut i fra nettleserens bredde. Alle innleggene blir sortert i lister etter hvilken måned de er lagt inn, noe som gjør det lettere å presentere innleggene for valgt måned. Dette er hovedfunksjonen til kontrolleren, men for å gjøre dette så må den i tillegg utføre en rekke andre små oppgaver. Kontrolleren sender også nye innlegg til serveren slik at innleggene alltid blir lagret, dette sendes som et PostDto -objekt Animasjon Valg av måned i Min Dagbok bruker animasjon for å gi brukeren en visuell tilbakemelding på hvilket valg brukeren ender opp på. Animasjonen er beregninger gjort av kontrolleren, mer om kontrolleren under punkt Kontroller og direktiv. Disse beregningene er ikke optimalisert for at de skal ha utrolig god flyt, men for at mobiler skal få animasjoner som ikke hakker. Animasjonen tar utgangspunkt i et tall som kontrolleren mottar fra direktivet og begynner så snart brukeren avslutter swipe -bevegelsen. Kontrolleren beregner så hvilken måned det er kortest avstand til, og starter animasjonen som går til riktig side. Ved å trykke på en måned, eller ved å benytte pilene, så vil det være animasjon. Dette er for at nettsiden skal oppføre seg så likt som mulig uansett enhet og at det ser mye bedre ut med animasjon. 16 diarycontroller - controller.js, linje: ngswipe - Shared.js, linje:

46 Ultralyd Ultralyd har som formål å vise hvordan en mulig implementasjon av ultralyder kan bli seende ut i fremtiden. Denne nettsiden er statisk, det vil si at den ikke henter data fra databasen. Alle brukere vil se den samme nettsiden. Dette er ikke grunnet at nettsiden ikke er ferdig implementert, men et resultat av hva oppdragsgiver ønsket denne siden skulle gjøre ettersom dagens helseteknologi ikke støtter digitalisering av ultralyder. Nettsiden er ikke optimalisert og kun et raskt utkast Funksjonalitet Til tross for at Ultralyd er en statisk side, så bruker den JavaScript for å forandre på innholdet som vises på siden ved lokal navigasjon. Denne funksjonaliteten er til for å gi siden litt forandringsmulighet og er med på å gjøre Ultralyd bedre enn en nettside som er helt statisk, spesielt for demonstrasjoner. I motsetning til de andre nettsidene på pasientproduktet benytter ikke Ultralyd seg av kontrolleren sin. Bootstrap er ikke implementert fullt ut for å støtte utseende på mobiler Tidligere Svangerskap Her blir pasienten presentert med en liste over de overståtte svangerskapene pasienten tidligere har hatt og/eller hatt registrert i systemet. Ettersom det falt utenfor omfanget av oppgaven er det ikke lagt inn støtte for å automatisk konvertere et aktivt svangerskap til et tidligere svangerskap, da oppgaven kun omhandler svangerskapsprosessen uten selve fødselen. Informasjonen som ligger i et tidligere svangerskap er ment å fylles ut etter barnet er født (navn, vekt, høyde etc.), og ansvarlige kan på denne løsningen registrere dette på produktet for ansvarlige, nevnt i punkt ResponsibleUI - Tidligere svangerskap. I en fremtidig versjon vil det være ekstra informasjon på denne nettsiden, som for eksempel øyefarge, hårfarge/lengde, og videre informasjon. Dette kommer til å være tilgjengelig gjennom knappen Mer info øverst til høyre i hvert tidligere svangerskap, som for øyeblikket er uten funksjon, men har demonstrasjonmessige verdier Informasjonsflyt Denne nettsiden benytter en helt vanlig.net MVC-struktur, som henter informasjon rett fra databasen via kontrolleren på tjeneren. Når brukeren ber om dette nettstedet blir -objekt av type List<PregnancyResult> hentet fra databasen og plassert i passende felter ved hjelp av.net s HTMLhelper, med blant annet Laste opp bilde Ved å klikke på et lite kamera-ikon ved siden av det åpne feltet til venstre kan pasienten velge å laste opp et bilde av barnet sitt. Denne funksjonen er lik opplastingsfunksjonene til både pasientens profilbilde og i Min Dagbok. Ved å bruke en gjemt HTML-<input> av type file som tillater image/* med capture= camera kan mobile brukere få mulighet til å ta bilder med mobilkameraet og laste dette opp. For selve opplastingen brukes et asynkront AJAX-kall til kontrolleren på tjeneren. Kontrolleren tar i mot bildet, genererer et bildenavn basert på en hash av nåværende dato i millisekunder, lagrer bildet i passende filsystem, og returnerer den relative filbanen fra tjeneren. Når banen er returnert blir bildet umiddelbart vist der det hører hjemme. 34

47 For denne nettsiden, Tidligere Svangerskap, blir det i tillegg sendt ved det valgte svangerskapets ID slik at bildet blir lagret for riktig svangerskap i databasen. Ettersom dette kun er en prototype er det ikke lagt inn støtte for håndtering av forskjellige aspektforhold for bilder, og visningen kan bli feil dersom det ikke blir brukt riktig Svangerskapskurve / Mage- og Fundus-mål På denne nettsiden vil pasienten bli presentert med en graf som viser magens størrelse i forhold til hva som er normalt. Som et utgangspunkt viser grafen elleve linjer som definerer normalen. Grafen er laget fra bunnen av med Highcharts og på bakgrunn av tegninger og matematiske funksjoner mottatt fra helsedirektoratet uten videre forklaring. Det har i midlertidig ubekreftet blitt fastslått at prosentene på høyre side av grafen kan leses av som X% av gravide i Norge har lavere fundusmål enn dette. Punktene kan representeres fra og med uke 24 til og med uke 42. Punktene på grafen kan bli plottet inn av legen når pasienten er på svangerskapskontroll Informasjonsflyt Svangerskapskurven er et menyvalg som kun er tilgjengelig fra undermenyen på Mitt Svangerskap da det er direkte underlagt det digitale svangerskapet/helsekortet og ikke kan eksistere uten. Når pasienten befinner seg på Mitt Svangerskap blir helsekortets ID lagret som en variabel, som blir hentet ut av Svangerskapskurven ved navigasjon. Når nettsiden lastes inn blir det utført et asynkront kall til tjeneren som henter grafens data basert på helsekortets ID. Denne informasjonen blir returnert i form av en DTO som inneholder en double for centimeter, en integer for uken, samt en streng for tittel. Grafen benytter disse verdiene, samt en god del statiske/grafiske verdier i klientkontrolleren til å generere passende utseende Kontrolleren Denne nettsiden benytter pregnancygraphcontroller 18 som kontroller for å generere grafen ut i fra gitt data. Når nettsiden ber kontrolleren om å initialisere grafen blir først statisk data generert til å representere grafens utgangspunkt basert på normalen fra helsedirektoratet, for deretter å putte inn hvert punkt mottatt fra serverens asynkrone kall, om noen blir returnert. Verdiene, funksjonene og variablene som blir prosessert i løpet av livssyklusen og generering av den faktiske grafen er noe overveldende for dette dokumentet, og er forklart med nærmere beskrivelse i kommentarene til kontrolleren. 18 pregnancygraphcontroller - controller.js, linje:

48 Undersøkelser Denne nettsiden blir linket til fra undermenyen i Mitt Svangerskap beskrevet i punkt Undermenyen. Undersøkelser skal gi pasienten en oversiktlig måte å lese resultater fra legebesøkene. All informasjon som vises på denne nettsiden blir generert til tekst på tjeneren før klienten mottar noe ved hjelp av standard.net/mvc Html-helper Utseende Den dynamiske delen av utseende er det hovedsakelig Bootstrap som tar seg av. Det er også litt ekstra CSSkode for å håndtere endringen mellom landskap og portrett (horisontal og vertikal) på mobiler. Dataene for undersøkelsene kommer fra nyest til eldst, slik at det skal være lett for brukeren å alltid kunne se sin siste undersøkelse, hvor det motsatte ville gjort at mobilbrukere hadde fått lenger bla-avstand til sine siste resultater. Informasjonen er det viktigste på denne nettsiden og utseende ble derfor formet for å få mye informasjon inn på så liten plass som mulig og fortsatt se ryddig og ordentlig ut. Figur 16 Undersøkelser, viser to undersøkelser 36

49 Veiviser Denne nettsiden er laget for å gi en kort introduksjon til applikasjonen slik at brukere som ikke har benyttet denne applikasjonen raskt kan sette seg inn i bruken. Veiviseren er tilgjengelig første gang man logger inn, og fra menyen ved å klikke på tannhjulet øverst til høyre. Introduksjonen er delt opp i fire undersider: intro, startskjerm, funksjonalitet og profil. Hver av disse undersidene tar for seg en liten forklaring. Hvordan undersidene er konstruert blir forklart i punkt Kontroller og direktiv Navigasjon av siden Navigasjon mellom undersidene kan gjøres på flere forskjellige måter. Dette inkluderer: swipe -bevegelse, neste- og tilbake-linker nederst på siden, og ved å trykke på navigasjonslinjen øverst (punktet, teksten eller linjen). Swipe -bevegelse er kun tilgjengelig for mobiler og nettbrett. Dette er grunnet at en swipe -funksjon for datamaskiner ville resultert i markert tekst. Ved navigasjon vil innholdet på siden forandre seg med en animert overgang. Swipe -funksjonen er videre forklart i punkt Kontroller og direktiv, og animasjonen er forklart i punkt Animasjon. Figur 17 Veiviser navigasjon for nettbrett/pc Figur 18 Navigasjon for mobil og tilbake/neste linker Kontroller og direktiv Nettsiden Veiviser bruker JavaScript-kontrolleren guidecontroller 19 og et direktiv ngswipe 20. Hva en kontroller og et direktiv er blir forklart under punktet AngularJS. Direktivet som brukes er det samme som for Dagbok, og blir forklart i punkt Kontroller og direktiv. Når en underside blir byttet må kontrolleren også endre på hvilket punkt på navigasjonslinjen som skal bli lyst opp. Alle dynamiske og visuelle endringer når nettleseren endrer størrelser gjøres i kontrolleren. Disse endringene gjør at man forandrer hva som vises på navigasjonslinjen og at undersidene skalerer seg riktig og ikke forskyves ut av fokus. For å få bedre innsikt kan kommenteringen til guidecontroller leses, der er alle funksjonene forklart på engelsk. 19 guidecontroller - Shared.js, linje: ngswipe - Shared.js, linje:

50 Animasjon Veiviser bruker animasjon som er implementert via kontrolleren. Animasjonen vises når brukeren skal gå fra en underside til en annen, eller når brukeren benytter swipe -funksjonen. Kontrolleren utfører animasjonen basert på hvilken underside som det vises mest av (nærmest midten) når brukeren utfører en swipe -bevegelse. Ved trykk på navigasjonslinjen, tilbake - eller neste -knappene vil animasjonen starte på nåværende underside og dra siden bort til valgt underside. Animasjonen er optimalisert for at den skal vises med minst mulig hakking på mobile enheter. For datamaskiner kunne animasjonen brukt flere utregninger per sekund og fått en litt bedre flyt. Dette ville blitt for tungt for mobiler og har blitt testet ut for å finne en optimal middelvei Administrator Administratorproduktet har, som nevnt innledningsvis i dette dokumentet, vært et viktig verktøy i utviklingsfasen av dette prosjektet, og fortsetter å være essensielt som en del av prototypen. Her opprettes profiler for test-menneskene som brukes i prototypen, samt opprettelse av samtaler mellom pasient og lege. En pasient må først være registrert i folkeregisteret før det er mulig å opprette et pasient-objekt for dem. Når objektet er opprettet i registeret, så vil register-objektet konverteres og overføres til et personog pasient-objekt i databasen straks pasienten logger inn for første gang, der Pasient arver fra Person (dog ikke direkte fra registeret). Før første login finnes ikke pasienten i person-registeret til systemet med mindre de allerede er registrert som en ansvarlig person (lege, jordmor) Folkeregister I folkeregisteret lagres det fiktive personer som skal representere pasienter. I dette produktet lagres personer med navn, adresse, telefon etc., og med en pin-kode som kan brukes til login. Dette er for å simulere det reelle folkeregister med bruk av MinID eller lignende. På en fullstendig versjon av applikasjonen ville selvsagt ikke folkeregisteret vært en del av den lokale databasen, og ingen administrator ville opprettet personer på denne måten Ansvarlige Slik systemet er utviklet nå er det foreløpig ikke nødvendig at ansvarlige er registrert i folkeregisteret. Administratorer kan opprette leger og jordmødre rett inn i det lokale person-registeret, uten at de skal behøve å knyttes til et fiktivt menneske i folkeregisteret. Det ble hovedsakelig utviklet slik på grunn av at det var langt utenfor oppgavens omfang, men også fordi det ikke ga noe mening å implementere en simulering av MinID for leger og jordmødre Samtaler For å opprette en samtale mellom en pasient og en ansvarlig må det på denne versjonen opprettes et samtale-objekt i databasen først. Dette gjøres via administrasjonsgrensesnittet, der man velger én pasient, og én ansvarlig. Etter dette objektet er opprettet, og lagt inn som et felt i databasen, så vil den ansvarlige dukke opp i samtalelisten for pasienten, og vice versa. Dette ble utviklet på denne måten for å unngå at gravide kvinner har mulighet til å legge til alle leger og jordmødre de kan navnet på, f.eks i tilfelle de er i en litt hysterisk periode av graviditeten. I en fremtidig versjon er det ment at leger og jordmødre selv gir pasienten tilgang til å bli med i en samtale med dem. Ettersom produktet for ansvarlige er utenfor oppgavens omfang har denne funksjonen blitt liggende i administrasjonsproduktet slik at det er lettere å kontrollere opprettelsen, såvel som notifikasjoner om uleste meldinger mellom dem. 38

51 ResponsibleUI På samme måte som administratorproduktet så er produktet for ansvarlige i denne løsningen kun implementert av årsaker basert på funksjon, og har ingen designmessig bakgrunn. Ettersom kravspesifikasjonen og oppgaven generelt kun spesifiserer et grafisk brukergrensesnitt for pasienter ble grafikken og grafikkfunksjonen i dette produktet kraftig nedprioritert, og kun automatisk generert fra Visual Studio s standard MVC-forslag. Dette egne nettstedet er beregnet kun for leger og jordmødre, der de kan logge inn og registrere/endre verdier for pasientenes data. De ansvarlige som kan logge inn på dette nettstedet må først være registrert som en ansvarlig fra administratorproduktet, men trenger ikke et felt i folkeregisteret. Dette grensesnittet er utviklet etter og på bakgrunn av nødvendigheter fra pasientenes grensesnitt, samt at det er utenfor oppgavens omfang, og kan derfor inneholde noe som kan oppfattes som dårlig programmeringsskikk. I samtlige av produktets svangerskapsrelaterte kontrollere (listet nedenfor) vil de ansvarlige få en rullgardin der pasientenes registrerte svangerskap (helsekort) skal velges Meldinger De ansvarliges meldingsfunksjon er kopiert over fra pasientproduktet, men ikke fullstendig implementert. Denne funksjonen er kun implementert på bakgrunn av at det var langt vanskeligere og tungvint å legge inn samtaler og meldinger rett inn i databasen. Meldingsfunksjonen fungerer da i stor grad på samme måte som pasientenes meldinger, som forklares i punkt Meldinger Svangerskapskontroller Svangerskapskontroller er et av to hendelser som dukker opp i pasientens grafiske tidslinje på forsiden ( Mitt Svangerskap ). Dette inneholder foreløpig informasjon om hvilken uke i svangerskapet pasienten er i, hvilken tilstand pasienten er i, navn på legen som utfører kontrollen, en oppsummering og en dato. For leger og jordmødre er det mer informasjon som kunne blitt vist her, men som ikke er relevant for pasienten(for eksempel kommentarer) og er derfor utelukket fra prosjektet, som kun omhandler pasientens grensesnitt. Feltet for uke vil definere hvor på pasientens tidslinje kontrollen vil dukke opp. Hovedsakelig skal svangerskapskontroller registreres den dagen de blir utført, men dette gir altså mulighet for å registrere hendelser bakover i tid, dersom noe blir oversett Ultralyd Her kan leger registrere pasientenes ultralyder, som kun vil vises i pasientens tidslinje. Pasientproduktet inneholder også en ufullstendig nettside for visning av ultralyder som skal basere seg på de samme dataene som registreres her, men dette ble senere flyttet utenfor omfanget for denne versjonen av produktene på bakgrunn av at dagens teknologi ikke tillater at tjeneren får tilgang til bilder og/eller video fra en ultralyd. Ettersom prosjektet kun er for utvikling av en visuell prototype ble det likevel bedt om en representasjon av ultralyd i pasientens tidslinje, og leger kan dermed nå registrere en URL for et ultralydbilde. I en fremtidig versjon av dette produktet vil ultralyd-objektet inneholde langt mer informasjon, som statisk illustrert på pasientens nettside for ultralyd. 39

52 Helsekort Pasientene kan selv registrere digitale svangerskap fra sitt eget grensesnitt, men de skal ikke være nødt til dette. For denne grunnen er det også mulig for leger og jordmødre å opprette disse verdiene, som i tillegg vil få langt flere felter å redigere. Dersom en pasient registrerer svangerskapet selv vil det likevel dukke opp for leger og jordmødre i dette grensesnittet, og de kan også her endre alle verdier. Det er dette objektet som i størst grad representerer svangerskapet, med blant annet termin, siste menstruasjon, vekt og høyde. Foreløpig inneholder objektet også noen verdier som ikke er i bruk, men som kun har blitt lagt til på bakgrunn av dagens fysiske versjon av helsekortet, på etterspørsel fra oppdragsgiver. Pasientproduktets tjener-kontroller håndterer dataene fra et slikt helsekort-objekt og oversetter dette til et DTO-objekt som kun inneholder dataene som faktisk skal vises for pasient, noe som minsker nettverksbelastningen. Som i resten av løsningen er det minimalt med validering av felter, og bruk av grensesnittet krever dermed kunnskap om hva som vil være passende dataverdier i denne versjonen Fundusmål I pasientproduktet blir høyde- og fundusmål presentert i form av en graf med centimeter og uker som grafens akser. Grafen blir nærmere forklart i punkt Svangerskapskurve / Mage- og Fundus-mål. Registrering av slike punkter kan kun skje fra produktet for ansvarlige, og innebærer at legen velger hvem/hvilket svangerskap, hvilken uke, magens høyde, og skriver en tittel for registreringen Tidligere svangerskap I en overgangsfase fra dagens fysiske helsekort til en digital løsning vil det være uunngåelig at tidligere svangerskap må registreres uten at svangerskapene faktisk har vært registrert digitalt i denne løsningen fra før. Spørsmålet om hvordan systemet skal takle overgangen fra et svangerskap til et tidligere svangerskap har dermed aldri blitt besvart av oppdragsgiver, da dette uansett ville bli satt i en unntakstilstand de første årene. For denne løsningen er det likevel slik at de ansvarlige må registrere et eget digitalt svangerskap for det tidligere svangerskapet, og deretter velge det i nedtrekkslisten ved opprettelse av et tidligere svangerskap. All informasjon i et tidligere svangerskap skal beskrive det som skjer etter fødselen er ferdig, noe som også vil legge seg utenfor omfanget av oppgaven Undersøkelser Dersom det blir utført en undersøkelse ved en svangerskapskontroll skal dette registreres her. Her lagres informasjon om pasientens og barnets tilstand, og blir vist i en egen nettside for pasienten. Mer om dette kan leses i punkt Undersøkelser. 40

53 Ekstra Dette punktet inneholder informasjon om funksjonalitet og tjenester som ikke hører til noen av de andre punktene. De ekstra funksjonalitetene og tjenestene er laget kun for å gjøre produktet helhetlig bedre og er på ingen måte kritiske for infrastrukturen. Som oftest er funksjonaliteten/tjenesten der for å hindre at brukeren ser partielle nettsider, error sider eller lignende Error page Som en ekstra funksjonalitet har vi laget en error-side dersom tjeneren ikke kan finne siden som blir bedt om (Error 404). Dette vil i utgangspunktet ikke skje av seg selv, og er kun for å erstatte de forskjellige standardene som følger med forskjellige nettlesere. Denne siden kommer man kun til ved at man prøver å aksessere sider som ikke er tilgjengelig på nettstedet. Dette er oftest et resultat av at brukeren skriver noe direkte inn i adressefeltet uten å vite nøyaktig hva som skal stå der. Error-siden er kun tilgjengelig på klientsiden (pasientproduktet) når man er logget inn Omdirigering på sidene Det at pasientproduktet er en SPA gjør at alle undersider som hentes inn er partielle nettsider. Disse partielle nettsidene er det mulig å nå via adressefeltet. Dette er et problem ettersom partielle sider ikke vises riktig uten at enten Index - eller TourIndex -nettsiden holder på innholdet, blant annet fordi de partielle sidene ikke inkluderer noen form for stilark. For å unngå at man skal kunne bruke disse partielle sidene alene inkluderer alle sidene en funksjon helt i toppen som sjekker hva som står i adressefeltet. Funksjonen bruker denne informasjonen til å avgjøre om brukeren befinner seg under Index eller TourIndex. Dersom brukeren ikke befinner seg under noen av disse vil den partielle siden automatisk sende deg videre til Index. Denne funksjonen kjører med en gang nettleseren mottar nettsiden TourIndex Dette er en side som er nesten identisk til Index i virkemåte og utseende. Denne har i motsetning til Index ikke en meny. Formålet med å ha TourIndex er å håndtere de sidene som skal ligge i Veiviseren som vises ved førstegangs-innlogging. De partielle nettsidene som kan hentes inn i TourIndex gjennom veiviseren er Veiviser, Min Profil og Medisinsk info Systemkrav Dette produktet er laget i Visual Studio 2013 og krever da at utviklere må bruke Windows som operativsystem. Produktet kjøres normalt på Microsofts IIS, og vil også trenge et databasehåndteringssystem for SQL. Lokal kjøring av prosjektet krever at databasen ligger spesifisert i prosjektenes connectionstrings med navn DatabaseContext, dette finnes i Web.config -filen for hvert av de respektive prosjektene. For brukere vil ikke dette ha noen effekt. Nettstedet skal støtte mobiler og nettbrett som faller under dagens standard for smarttelefoner, og datamaskiner i alle vanlige operativsystemer. Det vil likevel finnes nettlesere som ikke er støttet. Anbefalte nettlesere er: Chrome/Safari/Firefox for datamaskiner, standardnettleser for iphone/ipad og Chrome for Android. 41

54 42

55 Brukerveiledning 3 Denne applikasjonen er en prototype og ikke rullet ut for faktisk bruk. Dette dokumentet er en brukerveiledning for Digitalt Helsekort for Gravide og skal dekke bruken av prototypen som om den var i bruk og implementert. Denne brukerveiledningen er beregnet på alle brukere av nettsiden og krever minimalt med forkunnskaper for å forstå og leses. Denne brukerveiledningen er for brukere av prototypen som kjenner til fødselsnummere og pin koder som er tilgjengelig i databasen. Digitalt Helsekort for Gravide, forkortet DHG, er et nettsted som er laget for å brukes på alle enheter. Dette nettstedet skal fjerne nødvendigheten av å ta med seg et skjema, A4 ark, hver gang man skal til legen. DHG vil gi informasjon så raskt som mulig og være tilgjengelig så lenge man har en internetttilkobling. I dagens samfunn gjør dette at du som bruker kan ta med deg smarttelefonen eller nettbrettet og ha tilgang til informasjonen som en ny lege trenger. Dette vil spare tid og miljø, da man ikke fyller ut et papirskjema. Noe informasjon kan bli fylt ut før man har sitt første legebesøk og dermed spare tid for både legen og deg som bruker. DHG fungerer som et helt vanlig nettsted. På mobil og nettbrett så kan du også swipe (dra) elementer. Dette gjelder kun noen nettsider og dette kommer frem i instruksjonen under. Som nettsted så er det optimalt at man kan klare seg uten en brukerveiledning og nettsiden vil derfor gi deg tilbakemeldinger fortløpende. Det står mer grundig om de forskjellige nettsidene og hvordan man bruker disse i punktene under. Første gang man logger inn blir man ledet gjennom en veiviser. Denne vil gi en rask innføring om nettstedet og viktig informasjon for nye brukere. Denne brukerveiledningen går mer i dybden av alle nettsidene og forklarer hvordan funksjoner kan bli brukt. 43

56 3.1 Generelt Digitalt Helsekort for Gravide er en web-applikasjon som skal gi gravide kvinner rask og enkel tilgang til informasjon uansett hvor de er. Nettstedet skal være lesbar i alle formater, så du kan dra til legen med kun en mobil og fortsatt hente ut den informasjonen du/de trenger. Denne applikasjonen skal være et alternativ til å gå rundt med et papirark med informasjonen som de gravide og legen har skrevet informasjon på. Nettstedet fungerer som et vanlig nettsted, trykk på det som ser ut som kan trykkes på, så vil siden forandre seg. Applikasjonen er laget slik at feilmeldinger skal komme automatisk dersom noe går galt Systemkrav Denne applikasjonen/nettstedet stiller ingen systemkrav til deg som bruker. Vi vil likevel anbefale at du bruker Chrome/Safari/Opera/Firefox på en datamaskin, standardnettleser på iphone/ipad og Chrome på Android-enheter. Grunnen til at vi anbefaler disse er at vi ikke kan si med sikkerhet at alt vil fungere hvis du bruker andre nettlesere Menyen Menyen er tilgjengelig fra hele applikasjonen etter du er logget inn, og vil være måten du navigerer deg rundt på siden. Menyen er delt opp i tre hoveddeler, Personlig, Graviditet, og Annet. Notifikasjonssymbolet vil vise seg ved siden av menyvalget for Meldinger dersom du har uleste meldinger. Menyen vil ikke være tilgjengelig fra meldingsvinduet dersom du er på en mobil enhet, da den vil være erstattet av en tilbakepil som vil ta deg tilbake til samtalelisten. Første gang du logger inn og blir presentert med veiviser og oppsett vil du heller ikke se en menyknapp, dette er gjort slik at du ikke faller ut av denne viktige fasen. Til vanlig vil menyknappen være tilgjengelig øverst til venstre på skjermen. Figur 19 - Meny Tilgjengelighet Nettstedet er tilgjengelig for hvem som helst, og nettadressen ligger i README -filen på CD-en som er gitt sammen med denne dokumentasjonen. Hvilke brukernavn og pin-koder som kan brukes vil oppgis i et samme dokument. Dessverre så har prototypen, som dette dokumentet dreier seg om, ikke tilgang til folkeregisteret og det gjør at vi kun har fiktive personer liggende i databasen. 44

57 3.2 Min profil Min profil er nettsiden som oppgir generell informasjon om deg som vi har liggende i databasen. Her vil telefonnummer, adresse, yrke og andre relevante opplysninger ligge. Du vil ha tilgang til å endre på all informasjon utenom adressen din, da vi henter adressen fra folkeregisteret. Det er ikke mulig å endre på informasjonen i feltene inntil man trykker på knappen Endre, som man kan se i Figur 31. Figur 20 Min Profil uten endringsmulighet Oppdatere informasjon Ved å trykke på Endre -knappen vil de tillatte feltene bli trykkbare og du kan endre informasjonen. Etter informasjonen er endret må du trykke på knappen med teksten Lagre endringer, som befinner seg nederst på siden, som vist på Figur 32. Hvis lagringen lyktes så vil det komme grønn skrift over knappen med teksten Vellykket lagring. Dersom noe gikk galt vil rød tekst komme over med et forslag til hva som kan ha gått galt. Figur 21 Min Profil m/endringsmulighet, vellykket lagring Feil informasjon Dersom det er feil informasjon i Min Profil så må dette endres snarest. Denne informasjonen kan være kritisk for leger og vi anbefaler på det sterkeste at du er ærlig og fyller ut det du kan. Hvis adressen din er feil, så er ikke dette mulig å endre i Min Profil. Dette er grunnet at vi henter adresser fra folkeregisteret, og du må derfor endre adressen din der. Dersom adressen i Min Profil ikke stemmer overens med adressen i folkeregisteret, vennligst forklar dette til legen din slik at det blir fikset. 45

58 3.3 Mitt Svangerskap Denne nettsiden fungerer som applikasjonens forside, og her vil du finne all essensiell informasjon om ditt aktive svangerskap. Dersom du ikke har et aktivt svangerskap registrert vil denne siden være erstattet av et valg som leder deg direkte videre til opprettelse av et. Dersom du heller ønsker å se et tidligere svangerskap kan dette velges i hovedmenyen på venstre side. Ved et aktivt svangerskap registrert vil Mitt Svangerskap i hovedsak bestå av tre hoveddeler; generell informasjon om svangerskapet i form av en undermeny nederst på skjermen, en Figur 22 Mitt Svangerskap tidslinje-graf som viser hvor langt underveis i svangerskapet du er samt en rekke hendelser i form av punkter, og et informasjonsfelt som viser utdypende informasjon om det valgte punktet fra tidslinjen. Utseende på denne nettsiden er responsivt, og vil tilpasse seg størrelsen på enheten du bruker, enten det er en mobil, et nettbrett eller en datamaskin Registrering av svangerskap Figur 23 Hyperkobling til Registrer svangerskap Figur 24 Date termin baseres på Dersom du ikke har noe registrert aktivt svangerskap vil du bli presentert med en hyperkobling: Opprett svangerskap. Ved å klikke på denne blir du ført videre til oppsettet, som fra din side ikke krever mer enn at du fyller inn dato for når du tror du hadde siste mens før svangerskapet startet Dato for siste mens Ved registreringen av et svangerskap blir du bedt om å fylle inn dato for første dag ved siste menstruasjon. Ved å bruke denne datoen kan systemet benytte seg av fødejournalenes statistikker og regler, kalt Naegeles Regel 21, til å beregne hvor lenge det er til antatt termin. Figur 25 - Datepicker

59 3.3.2 Undermenyen Figur 26 Undermeny Dersom et aktivt svangerskap er registrert så blir du blant annet presentert med en undermeny som både viser informasjon om svangerskapet, og leder deg til andre informasjonssider Kurve Denne menyknappen fører deg videre til svangerskapskurven som viser deg mage- og fundusmål. Denne nettsiden er videre forklart i punkt 3.4 Kurve Meldinger Denne menyknappen tar deg videre til meldinger, som kan leses mer om i punkt 3.7 Meldinger. Menyknappen viser deg en notifikasjon (rød firkant med et tall inni) dersom du har uleste meldinger. Tallet i notifikasjonen representerer det totale antallet uleste meldinger på tvers av alle dine samtaler. Hvor mange som er uleste i hver samtale finnes i Meldinger når du trykker her eller i menyen. Tallet til høyre i menyknappen representerer det totale antallet meldinger du har mottatt fra leger og jordmødre, enten de er ulest eller ikke. For Figur 37 betyr det altså at pasienten har mottatt til sammen to meldinger fra en eller flere ansvarlig, der én av meldingen ikke har blitt lest X Dager til termin Denne boksen viser deg hvor mange dager det er til antatt termin basert på informasjonen som er registrert ved svangerskapet. Dersom du selv har registrert svangerskapet vil dette tallet være basert på datoen du registrerte for siste menstruasjon og regnet med Naegeles Regel som tilsier 282 dager. Etter hvert i svangerskapet vil legen din oppdatere informasjonen dersom de ser det passende, og dette tallet vil da bli mindre usikkert. Ved å klikke på denne boksen blir du foreløpig ikke navigert videre til en annen nettside, men dette er planlagt til å oppdateres i en senere versjon Undersøkelser Dette menyvalget tar deg videre til nettsiden over undersøkelser som er utført med deg gjennom svangerskapet, som kan leses mer om i punkt 3.5 Undersøkelser. Tallet til høyre for ikonet viser antallet undersøkelser som er registrert. 47

60 Baby-informasjon Informasjonen i denne boksen viser deg antatte verdier basert på forskjellige kontroller av deg og din mage underveis i svangerskapet. Denne informasjonen kan aldri være 100 % korrekt, men er ment som en pekepinn. Dersom du besøker flere forskjellige leger vil ikke alle legene behøve å utføre de samme undersøkelsene på nytt. På lik linje som Dager til termin er det foreløpig ingen interaksjonsmuligheter på dette valget Dagbok Dette valget tar deg videre til Min Dagbok, som beskrives i punkt 3.8 Min Dagbok. Tallet inne i ikonet viser hvor mange innlegg du har skrevet Tidslinjen Figuren viser deg hvor langt du har kommet i svangerskapet basert på data samlet inn fra legen og deg selv. Bildet i midten av figuren vil vokse underveis i svangerskapet, og tallet nærmest enden av bildet viser deg hvilken måned du er i. Innenfor tallene ligger det en ring som vil fylles med punkter for forskjellige hendelser som har skjedd underveis i svangerskapet. Ved å klikke på disse punktene blir du presentert med noe informasjon om hendelsen ved siden av eller over figuren. Når et punkt er valgt vil det være hvitt med en rød ring rundt Kontroll Figur 27 Tidslinje-graf Figur 28 Eksempel på kontroll Et blått punkt på figuren er en vanlig kontroll/undersøkelse. Her vises informasjon som oppsummering, status, dato for kontrollen, og navnet på legen Ultralyd Figur 29 Eksempel på ultralyd Et grønt punkt på grafen representerer eventuelle ultralyder som er registrert i systemet for ditt svangerskap. Når et ultralyd-punkt er valgt blir bildet, sammen med diverse informasjon, vist i et panel ved siden av grafen. Etter en ultralyd er det vanligvis enklere for leger å beregne en ny og sikrere termin. 48

61 3.4 Kurve Denne kurven viser deg dine mage- og fundusmål etter hvert som de blir registrert. De elleve blå linjene som alltid vises representerer hva som er normalt i Norge, der den midterste linjen er det absolutte gjennomsnittet. Etter hvert som du passerer uke 24 vil legen jevnlig måle størrelsen og høyden på magen, og plotte inn data i denne grafen. Dine punkter vises som røde diamanter, og ved å trykke eller bevege musepekeren over et punkt kan du se hvilken uke og hvilken verdi som er registrert. Prosentverdiene på høyre side kan for eksempel leses av som X% har lavere mageog fundusmål enn meg. 3.5 Undersøkelser Figur 30 - Svangerskapskurve Figur 31 Undersøkelser Her finner du de lagrede resultatene fra dine undersøkelser. Har du hatt undersøkelser som ikke vises på denne siden må du kontakte din lege og få han/henne til å legge inn resultatene. Informasjon som du finner på denne siden er standard for alle undersøkelser og den vil ikke vise noe ekstra selv om legen legger det inn. Ved endringer i praksisen for undersøkelser så vil informasjonen kunne endre seg. 49

62 3.6 Medisinsk Info Medisinsk informasjon finner du under meny valget Medisinsk Info. Her vil du som bruker få muligheten til å endre og legge inn en del informasjon som legene kan ha nytte av. Vi anbefaler at denne informasjonen fylles ut så tidlig som mulig etter at du tar i bruk denne applikasjonen. Du har mulighet til å endre informasjonen og vi anbefaler at du her er helt ærlig, da det kan ha konsekvenser for ditt svangerskap. Figur 32 Medisinsk Info Oppdatering av informasjon Det ligger tre knapper på siden med teksten Endre ved siden av hver sin overskrift for informasjonen. Når du trykker på en av disse knappene så vil feltene under, som hører til overskriften som knappen ligger ved sidene, bli mulige å endre. Ved endringer så er det viktig at man trykker på knappen som finnes nederst Figur 33 Medisinsk Info med vellykket lagring på siden med teksten Lagre endringer. Hvis denne knappen ikke trykkes på vil ikke informasjonen lagres. Det vil komme grønn tekst over Lagre endringer knappen med teksten Vellykket lagring hvis informasjonen ble lagret. Kommer det rød skrift eller ingenting så har det skjedd noe uforutsett og vi beklager det. 50

63 3.7 Meldinger På denne siden vil du finne alle samtalene du er med i og meldingene som finnes i hver samtale. Her vil du kunne lese og sende meldinger til legen eller jordmoren du er i samtale med. Meldingstjenesten er foreløpig ikke en fullverdig chat, og vil ikke oppdatere seg av seg selv. Hver gang hovedmenyen åpnes vil den søke etter meldinger, og du vil få en notifikasjon der dersom Figur 34 Meldinger for nettbrett/pc en ny melding kommer inn. Du kan også trykke på samtalen igjen for å oppdatere den. For å se tid og dato for meldinger på datamaskiner kan man bevege musepekeren over en melding Sende meldinger Denne tekstboksen fungerer slik man er vant til. Her er det bare å skrive i vei og så trykke Enter, så blir meldingen sendt. For å få en ny linje kan du trykke Shift + Enter. Enter vil sende teksten på mobile enheter uansett om shift er aktivert eller ikke. Grunnen til dette er at Shift på mobile enheter ikke kan leses av nettleser Meldinger på mobil Meldinger har et litt annet utseende på en mobil enn på nettbrett og datamaskiner. Dette er grunnet plassmangel på mobiler. Vi har valgt en løsning som mange vil kjenne igjen og har brukt før. Som du kan se i figurene til høyre så kommer man først til en samtaleliste hvor alle man snakker med vil dukke opp. Her velger man hvilken samtale man vil åpne, og så vil samtalelisten forsvinne og meldingene dukke opp. Knappen til hovedmenyen vil her erstattes med en tilbakeknapp. Figur 46 - Samtaleliste Figur 35 - Samtale 51

64 3.7.3 Starte samtale med annen lege/jordmor Om du ikke har noen samtaler, eller ønsker å starte en samtale med en lege som du ikke har i din samtaleliste, må du kontakte legen/jordmoren og be han/henne om å opprette en samtale. Det er dessverre ikke mulig for brukere å sette opp en samtale med en lege/jordmor. Dette er av sikkerhetsgrunner og for at leger/jordmødre ikke skal få mange samtaler de ikke ønsker. 3.8 Min Dagbok Min Dagbok er laget kun for deg og det er kun du som kan se det du skriver her. Her kan du skrive notater til deg selv, bruke den som en dagbok eller til å minne deg selv på forskjellige ting. Akkurat hva den brukes til er opp til deg. Figur 36 Min Dagbok Nytt innlegg Dagboken har et pluss-tegn øverst på siden. Denne åpner muligheten for å skrive inn i tittel, innlegg og et bilde, se Figur 49. Trykk OK når du har fått med alt du vil ha med for å laste opp innlegget. Alle innlegg vil legge seg i den siste måneden. Du kan lese innlegg fra tidligere måneder ved å trykke på måneden, bruke pilene til å navigere, eller utføre en swipe -bevegelse på mobiler og nettbrett. Dersom du klikker utenfor vinduet eller på knappen Lukk etter å ha fylt inn informasjon, så vil informasjonen fortsatt ligge der dersom du igjen klikker på pluss -ikonet. Denne informasjonen vil kun forsvinne dersom du oppdaterer nettsiden eller fjerner den selv. Dette er lagt inn for at du ikke skal miste informasjonen ved et feilklikk. OBS! Det er foreløpig ikke mulig å endre eller slette innlegg. Figur 37 - Modal Last opp bilde Trykk på Velg bilde for å velge et bilde. Du kan kun laste opp maksimalt ett bilde per innlegg. Når et bilde er lagt til kan du klikke på ikonet x øverst i høyre hjørne av bildet for å fjerne det. 3.9 Ultralyd Ultralyd er foreløpig en statisk nettside (den forandrer seg ikke fra bruker til bruker). Denne ser lik ut uansett hvem du er og har ingen nyttig informasjon. Den er kun tilstede som en visuell side for å vise hvordan nettsiden kan bli i fremtiden. Grunnen til at denne er statisk og ikke henter dataene fra din ultralyd er at det ikke finnes mulighet for dette i dagens system. Dette vil bli forbedret og implementert i fremtiden. 52

65 3.10 Tidligere svangerskap Figur 38 Tidligere svangerskap, informasjon Dersom du har hatt et registrert svangerskap her før, eller om legen din har lagt inn et tidligere svangerskap eksternt fra dette systemet, så vil disse vises med noe relatert informasjon her som vist i figuren. I nåværende versjon av systemet vil ikke knappen Mer info ha noen funksjon, men dette vil bli implementert senere. Overgangen fra et aktivt svangerskap til et tidligere svangerskap skjer når barnet blir født, og må registreres av legen Endre bilde Ved å klikke på kamera-ikonet kan du velge et bilde fra din datamaskin, nettbrett eller telefon. På mobile enheter vil du i tillegg få mulighet til å umiddelbart ta et nytt bilde. Du kan oppdatere bildet så ofte du vil Informasjonen Navn Født Kjønn Tid Vekt Varighet Lengde Barnets fulle navn Barnets fødselsdag Barnets kjønn Tidspunkt på dagen for fødselen Barnets vekt ved fødsel Svangerskapets varighet i antall dager Barnets lengde ved fødsel. Figur 39 Velg bilde på mobil 3.11 Logg ut Du blir logget ut når du trykker på denne knappen. Du må da logge inn igjen for å bruke nettstedet. Alle endringer som ikke er lagret før du logger ut vil bli borte. Ved å lukke nettstedet vil du normalt bli logget ut automatisk, men enkelte nettlesere kan holde deg innlogget selv etter en omstart uten at du vet det. Dersom du føler at noe av informasjonen på nettstedet er personlig er det derfor viktig at du logger ut manuelt for å være sikker. 53

66 54

67 Testdokumentasjon Brukertest Det ble utført flere brukertester daglig, både under og etter utvikling. Disse testene avdekker feil eller mangler i både utseende og oppførsel. Slike tester gir deg ofte en pekepinn på hva som kan være feil, men det hender også at man oppdager feil som det ikke er like lett å finne årsaken til. Slike feil kan skyldes at kommunikasjonen med server, som skjer asynkront, skjer samtidig som annen kode kjører. Brukertestene har vært et godt verktøy for å finne feil på nettstedet og i JavaScript-koden som kjøres. Nettstedet består i store deler av JavaScript, hvor det ikke finnes syntakssjekk, så det er få enkle feil man finner ved tester. Feil i grafiske brukergrensesnitt kan kun oppdages ved brukertester, da dette går på utseende og ikke faktiske verdier. Tester er en stor del av extreme programming, metoden vi har benyttet, og ved å bruke en slik metode så er man forberedt på å teste mye. Det at prosjektet i stor grad baserer seg på hvordan produktet ser ut gjør det naturlig å brukerteste programmet. Disse testene vil også kunne gi informasjon om at det er feil i koden på tjenersiden. 4.2 Formålet med testene Testene har hatt som formål å avdekke feil og mangler ved nettstedet for brukere. Det har vært lite testing spesifikt egnet for tjenerdelen av produktet. Dette er grunnet at det fra begynnelsen av prosjektet har vært fastslått at hele tjenerdelen skal byttes ut uavhengig av resultat, hvor det i dette prosjektet kun skal være en kommunikasjonsportal mellom brukere, administratorer, ansvarlige og databasen. Det er minimalt med kode som ligger på server og det har derfor krevd veldig få tester for å få ønsket resultat. 4.3 Akseptansetest Før produktet leveres er det vanlig med en akseptansetest, slik at oppdragsgiver kan forsikre seg om at produktet inneholder den funksjonaliteten som er avtalt. Dette er ikke en test for å finne feil ved produktet, men for å se at punktene på kravspesifikasjonen er oppfylt og at det ikke er noen mangler ved produktet. Produktet har blitt presentert gjentatte ganger og alle kravene under Systemet bør og Systemet kan i kravspesifikasjonen 22 er implementert. 4.4 Konklusjon Testing av produktet er en viktig og tidkrevende prosess. Andre typer testing som integrasjonstester, enhetstester og modultester hadde nok vært gode tester å bruke for andre prosjekter. For dette produktet var brukertest den letteste og sikreste måten å teste produktet på. Produktet har gjennomgått hundrevis av 22 Kravspesifikasjon versjon 2, side 60 55

68 tester og dette sier ingenting om hvor mange feil man finner. Det at man kan utføre testene raskt og effektivt, for så å avklare om det finnes feil ved koden eller ikke, er utrolig viktig. Akkurat hvordan testene er utført eller hvilken testmetode som er brukt er mindre viktig og kan variere. For vår del har testingen vært en naturlig del av utviklingen, da det bare er én måte å finne ut hvordan et nettsted faktisk oppfører seg, det er å bruke den selv. 4.5 Utvalgte tester Under så kan man se noen av de få utvalgte brukertestene som har blitt utført. Testene er gjort litt simplere, for at de skal være lettere å forstå. Hver test er egentlig flere iterasjoner av tester med små forandringer i koden til ønsket resultat er oppnådd. Tittel Hva testes? Ønsket resultat Faktisk resultat Hva ble endret Resultat/konklusjon Tverrprosjektlig tilgang til database Kjøre både Pasientproduktet og Administrasjonsproduktet samtidig, begge med kobling til samme database. Begge produkter får lese- og skrive-rettigheter på databasen samtidig. Databasen ligger opprinnelig lokalt i administrasjonsproduktet, uten at pasientproduktet får tilgang. Ingen connection string kunne peke til en database innenfor et annet prosjekt, verken på lokal eller ekstern kjøring av prosjektene. Databasen ble flyttet ut av administrasjonsproduktet, og inn til en absolutt bane som blir benyttet i connection string for hver av de ulike produktene. Både Pasientproduktet, Administrasjonsproduktet og produktet for Ansvarlige får tilgang til databasen samtidig. For lokal debugging er dette noe uvanlig, men det måtte uansett skje for publiseringen av produktene på Microsoft Azure (SQL Server Management Studio). 56

69 Tittel Hva testes? Ønsket resultat Faktisk resultat Hva ble endret Resultat/konklusjon Ugyldig navigering Navigasjon til spesifikke partielle nettsider (f.eks ~/Home/Messages), som brukere kun skal kunne se som en del av index Brukeren blir omdirigert slik at ønsket nettside blir presentert korrekt. Brukeren fikk en HTML-side uten stilark, og kunne se rå informasjon Det ble lagt til en JavaScript-funksjon i starten av den partielle siden som skal omdirigere brukeren dersom adressefeltet tilsier at den partielle siden ikke blir vist under Index. Ved manuell navigasjon til den partielle nettsiden via adressefeltet blir brukeren omdirigert til Index, som videre benytter adressefeltet til å finne ut hvilken partielle side som skal hentes. Tittel Hva testes? Ønsket resultat Faktisk resultat Hva ble endret Resultat/konklusjon Motta en melding når man sender Vise rekkefølgen mellom meldinger som hentes og sendes. Når en melding blir sendt skal nye meldinger(sendt fra den ansvarlige) bli plassert over meldingen som blir sendt. Meldingen som den ansvarlige sendte ble vist etter meldingen som brukeren sendte. Kallet på funksjonen som sender en melding blir gjort etter at funksjonen som henter ned nye meldinger har fått respons fra tjeneren. Ved å sende en melding blir nye meldinger i samtalen lastet ned og vist før meldingen som blir sendt. 57

70 Tittel Endring av vindusstørrelse i nettleser Hva testes? Endring av nettleserens bredde på Mitt Svangerskap, ned til minimum 340 piksler i bredden (vanlig størrelse for visning av CSS på mobile skjermer). Ønsket resultat Faktisk resultat Hva ble endret Resultat/konklusjon Elementene som befinner seg på Mitt Svangerskap tilpasser seg bredden ved å forflytte seg under hverandre, og gjør at nettleseren aldri krever at brukeren må bla til høyre for å se alt innhold. Alle elementer plasserte seg riktig i forhold til hverandre, men tidslinjegrafen viste seg å være bredere enn 340 piksler, altså bredere enn en mobilskjerm. Tidslinjen, laget med Highcharts, støtter ikke resize ettersom sektordiagrammet inneholder et bakgrunnsbilde. Ved å aktivere resize ble bildet deformert. Bildet er essensielt for funksjonen, og dette måtte løses ved at hele tidslinjen ble reinstansiert med en annen størrelse. Kontrolleren lytter på størrelsesendringer, og utfører passende handling ut i fra størrelsen på over og under 500 piksler. Når nettsiden lastes inn blir nettleserens bredde brukt til å definere hvilken størrelse tidslinjen skal være. Et uheldig biprodukt av endringen er at tidslinjens siste punkt alltid vil bli markert ved instansiering. Dersom noe annet enn det siste punktet er markert ved resize forbi 500 piksler vil det siste punktet markeres. Dette kan likevel kun skje på datamaskiner, da mobiler alltid har liten versjon, og nettbrett alltid har stor. Nå ser Mitt Svangerskap ut akkurat som ønsket. 58

71 59

72 Kravspesifikasjon versjon 2 5 Hovedprosjekt 2014 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Tittel: Oppgave: Gruppemedlemmer: Prosjektgruppe: Gruppe nr. 43 Veileder: Oppdragsgiver: Om oppdragsgiver: Kontaktperson hos oppdragsgiver: Digitalt Helsekort for Gravide Utvikle en prototype for en digital versjon av helsekort for gravide. Petter Abrahamsen (s169962@stud.hioa.no), Stian Flatby (s171182@stud.hioa.no) Thor E Hasle (thor.hasle@hioa.no) CSAM Health AS Programvareleverandør av ehelse-løsninger for helsevesenet Ilan Eini (Ilan.Eini@csamhealth.com) Hovedtrekk ved kravspesifikasjonen HTML5/CSS/JavaScript-løsning for mobiler, nettbrett og desktop som kommuniserer med server som har en database. Nettsiden skal oppføre seg som en applikasjon på mobile plattformer og som en nettside for desktop. Forord Vi skal lage en mobilvennlig nettside som skal kunne håndtere og simplifisere dagens registrering av informasjon for gravide kvinner i Norge. Denne nettsiden skal først og fremst støttes av iphone, med Android som en sekundær prioritet. Nettsiden/appen skal være mulig å bruke for så mange som mulig, uten tidligere kunnskap om systemet. Hovedprosjektet vårt består av å lage en prototype for CSAM, som senere skal kunne bruke denne som en demonstrasjon i fremvisninger. 60

73 Hensikten med kravspesifikasjonen Hensikten med denne kravspesifikasjonen er å få tydelig avklart hva som er prioritert i løpet av hovedprosjektet, hvilke dokumenter som må være med, hvordan det som blir laget skal fungere, og hvilke funksjoner som er absolutt essensielt å få på plass. Kravspesifikasjonen vil gi oss en bedre oversikt over hva som skal gjøres før vi går ordentlig i gang med å lage noe, samt at den skal hjelpe oss med å sette prioriteringer. For CSAM (oppdragsgiver) vil kravspesifikasjonen gjenspeile på en best mulig måte hva de har størst behov for at blir produsert av oss. For de som leser kravspesifikasjonen som en del av dokumentasjonen så vil kravspesifikasjonen gi en pekepinn på hva som kan forventes at er med i produktet og hva som vil være med videre i dokumentasjonen. Krav Forbedringer en venter å oppnå Sluttproduktet, som en webapplikasjon for ios (og mulig Android/Windows phone), vil fjerne behovet for å gå rundt med et fysisk helsekort for den gravide. Digitalisering av denne informasjonen vil øke effektiviteten til et slikt nivå som i teknologiens verden i dag er forventet. Vi skal produsere en prototype i form av en nettside (HTML5/CSS/JavaScript) for dette formål. Denne nettsiden skal være "proof of consept" og trenger ikke å bli gjort om til en ordentlig app, men skal kjøres på mobilens nettleser. Systemet må inneholde: Se egen profil, og endre diverse informasjon (telefonnummer, e-post etc). Se nåværende svangerskap (vise informasjon). Se egen medisinsk info. Se ultralyd (dummy bilder/statisk side) Graf for å se utviklingen i svangerskapet. Kunne se data fra undersøkelser (legebesøk) Dagbok, hvor den gravide kan skrive om sine opplevelser gjennom svangerskapet. Meldinger mellom lege og pasient (skrive/sende og lese). Mulighet til å se tidligere svangerskap. Logge inn med brukernavn og passord. Systemet bør inneholde: En guidet tour første gang man logger inn. Opprette nytt svangerskap under egen profil. Mulighet for å legge inn og endre profil bildet. Oppdatere noe medisinsk informasjon. Støtte for android nettlesere. 61

74 Systemet kan inneholde: Andre former for innlogging. Omgjort til app for iphone og Android. Rammekrav i systemet For prototypen vil innlogging med brukernavn og passord bli brukt som en substitutt for bankid/minid, som forventes å bli brukt i fullversjonen. Prototypen vil ikke ha sensitiv informasjon, den vil kun bruke "dummy data". Endringer og mistet data vil dermed ikke være et stort problem. Prototypen skal kunne kjøres uten problemer på ios-enheter (helst også Android). Ved brukerens første innlogging i systemet vil det bli presentert en mulighet for å få en guidet tour gjennom systemets funksjoner. Simpel datamodell Figur 40 Simpel datamodell 62

75 Krav til systemkonstruksjon Vi skal ta utgangspunkt i å lage nettsiden/appen med en MVC tilnærming, hvorav en database har modellene, C# (mest sannsynlig) er kontrolleren og HTML/CSS står for view (vindu) delen. Dette vil gjøre at vi kan ha en administrasjonsside som gjør det lettere å teste ut forskjellige deler av nettsiden etter hvert som informasjon blir lagt inn. Krav til dokumentasjon Vi vil følge HiOAs retningslinjer for dokumentasjonen for hovedprosjektet. All denne dokumentasjonen vil foregå på norsk. Det vil i tillegg være noe ekstra dokumentasjon for CSAM som vil følge deres retningslinjer, men ettersom dette prosjektet er helt i startfasen er det noe usikkert akkurat hva som skal lages. Vi er likevel forberedt på at kode skal kommenteres, dokumenter om hvordan oppgaven kan utvikles videre, brukerveiledninger o.l vil med stor sannsynlighet bli et krav. Dataordbok App - Applikasjon (et lite program) til smart telefoner som bruker ios, Android eller Windows phone/mobile. C# - Uttales C sharp. Et programmeringsspråk som ble utviklet av Microsoft for å brukes i deres.net rammeverk. Dummy data - Statisk data som er funnet opp. MVC - Model, view, controller. Er en måte å dele opp applikasjonen på slik at den skal være oversiktlig og at ikke deler av programmet har mer kontroll enn det skal ha. HTML - HyperText Markup Language, språket som man bruker for å lage nettsider. CSS - Cascading Style Sheets, det man bruker for å endre utseendet på nettsider. JavaScript - Et dynamisk programmeringsspråk som brukes for å tilføre dynamiske elementer til nettsider. WCAG - Web Content Accessibility Guidelines. 63

76 64

77 DEL II APPENDIKS 65

78 66

79 Figure A Design Meny Figure B Design Mitt Svangerskap Figure C Design Min Dagbok Figure D Design Undersøkelser 67