Kravspecifikation tværga ende sundhedsplatform

Kravspecifikation tværga ende sundhedsplatform Kravliste. Høringsversion. Opdateret 21-10-2014 Indhold Indhold... 1 Typer af krav... 4 1. Sprog... 5 Krav [1.1]: Sprog... 5 Krav [1.2]: Sprog - Menusprog... 5 Krav [1.3]: Sprog - Alternative sprog... 5 2. Understøttede platforme... 5 Krav [2.1]: Understøttede platforme Microsoft... 5 Krav [2.2]: Understøttede platforme Apple... 6 Krav [2.3]: Understøttede platforme - Android... 6 Krav [2.4]: Understøttede platforme Andre typer... 6 3. Licens... 6 Krav [3.1]: Antal brugere af løsningen Licens.... 6 4. Adgangskontrol og visning af data... 7 Krav [4.1]: Brugeradgang... 7 Krav [4.2]: Brugeradgang NemId... 7 Krav [4.3]: Brugeradministration borgere og pårørende. Cpr opslag.... 7 Krav [4.4]: Brugeradministration borgere og pårørende. Integration til Avaleo... 7 Krav [4.5]: Brugeradministration Medarbejdere. Automatisk import... 8 Krav [4.6]: Brugeradministration Medarbejdere. Import fra Avaleo.... 8 Krav [4.7]: Brugeradministration Vedligehold og sletning af medarbejdere... 8 Krav [4.8]: Brugeradministration Autorisationsstyring... 8 Krav [4.9]: Brugeradministration Autorisationsstyring. Vedligehold.... 9 5. Placering af sundhedsdata... 9 Krav [5.1]: Placering af sundhedsdata Måledata... 9 Krav [5.2]: Placering af sundhedsdata Kontekstdata og Avaleo... 9 Side 1

Krav [5.3]: Placering af sundhedsdata Kontekstdata og Avaleo. Medcom besked.... 9 Krav [5.4]: Placering af sundhedsdata Kontekstdata og XDS... 10 Krav [5.5]: Placering af sundhedsdata Video/billeder... 10 Krav [5.6]: Placering af sundhedsdata FMK... 10 Krav [5.7]: Placering af sundhedsdata Medicinoplysninger... 10 Krav [5.8]: Placering af sundhedsdata Avaleo... 11 6. Ejerskab af data... 11 Krav [6.1]: Ejerskab af data... 11 Krav [6.2]: Ejerskab af data Anvendelse af data... 11 Krav [6.3]: Ejerskab af data Borgerdata. Samtykke... 11 Krav [6.4]: Ejerskab af data Digital værge... 11 Krav [6.5]: Ejerskab af data Differentieret samtykke... 12 7. Modulær opbygning... 12 Krav [7.1]: Modulær opbygning... 12 Krav [7.2]: Modulær opbygning tilbudte moduler... 12 Krav [7.3]: Modulær opbygning åben platform... 12 8. Overblik og beslutningsstøtte... 13 Krav [8.1]: Beslutningsstøtte - Triagering... 13 Krav [8.2]: Beslutningsstøtte Alarmer... 13 Krav [8.3]: Beslutningsstøtte Sortering... 13 9. Brugergrænseflade... 13 Krav [9.1]: Brugergrænseflade Platform... 13 Krav [9.2]: Brugergrænseflade Grafisk udtryk... 14 Krav [9.3]: Brugergrænseflade Tilpasning borger (og pårørende)... 14 Krav [9.4]: Brugergrænseflade Tilpasning medarbejdere... 14 Krav [9.5]: Brugergrænseflade Overbliksvisning... 14 Krav [9.6]: Brugergrænseflade Søgning... 15 Krav [9.7]: Brugergrænseflade Multilogin... 15 10. Kommunikationsmuligheder... 15 Krav [10.1]: Kommunikation - Videosamtale... 15 Krav [10.2]: Kommunikation Audiosamtale... 15 Krav [10.3]: Kommunikation Tekst beskeder... 15 11. Kalenderfunktionalitet... 16 Side 2

Krav [11.1]: Kalender... 16 Krav [11.2]: Kalender Manuelt input... 16 Krav [11.3]: Kalender Import fra Avaleo... 16 12. Statistik og logning... 16 Krav [12.1]: Statistik... 16 Krav [12.2]: Logning... 16 13. Åben platform... 17 Krav [13.1]: Open Source... 17 Krav [13.2]: Open Source udvikling af ny funktionalitet... 17 Krav [13.3]: Open Source - betingelser... 17 Krav [13.4]: Open Source - Økonomi... 17 14. Performance... 17 Krav [14.1]: Performance... 17 15. Arkitektur og standarder... 18 Krav [15.1]: Fælleskommunal rammearkitektur... 18 Krav [15.2]: Anbefalinger fra NSI... 18 Krav [15.3]: HL7 & IHE... 18 Krav [15.4]: PHMR... 18 Side 3

Typer af krav Krav kategori Minimumskrav (MK) Krav (K) Option (O) Beskrivelse Minimumskrav er et Krav (se nedenfor), der uforbeholdent skal opfyldes af Tilbudsgiveren. Opfyldes et Minimumskrav ikke, vil tilbuddet blive anset som ikke konditionelt, og tilbuddet vil ikke blive taget i betragtning. Minimumskrav er forbeholdt de egenskaber i Løsningen, som er fundamentalt afgørende for, om Løsningen kan anvendes. Kategorien Krav er Ordregivers krav til Løsningen, som Tilbudsgiveren kan, men ikke skal opfylde. Kravspecifikationen indeholder en række Optioner. Alle Optioner er angivet som et Krav i Kravspecifikationen. Alle Optionerne er Minimumsoptioner. Det betyder, at Tilbudsgivers tilbud ikke vil være konditionsmæssigt, hvis ikke alle Optioner tilbydes. Ordregiver kan vælge at indfri Optionerne, men er ikke forpligtiget heri. Side 4

Krav til den tilbudte løsning 1. Sprog Krav [1.1]: Sprog Den tilbudte løsning skal være på dansk. Krav [1.2]: Sprog - Menusprog Menusproget skal være dansk og alle brugervendte navigationsmenuer i den tilbudte løsning skal være på dansk. Krav [1.3]: Sprog - Alternative sprog Det er et krav at der kan vælges et eller flere alternative sprog i den tilbudte løsning. Som minimum skal der kunne vælges engelsk. Tilbudsgiver skal redegøre for hvilke alternative sprog den tilbudte løsning understøtter. 2. Understøttede platforme Krav [2.1]: Understøttede platforme Microsoft Kategori: K Type: Ikke funktionelt krav Det er et krav af den tilbudte løsning kan anvendes på Microsoft Windows baserede platforme, som Microsoft Windows til PC og Microsoft Windows til tablet og Microsoft Windows mobile til smartphone. Tilbudsgiver skal redegøre for hvilke Microsoft Windows baserede platforme den tilbudte løsning understøtter. Side 5

Krav [2.2]: Understøttede platforme Apple Kategori: K Type: Ikke funktionelt krav Det er et krav af den tilbudte løsning kan anvendes på Apple baserede platforme, som IOS til PC, tablet og smartphone. Tilbudsgiver skal redegøre for hvilke Apple baserede platforme den tilbudte løsning understøtter. Krav [2.3]: Understøttede platforme - Android Kategori: K Type: Ikke funktionelt krav Det er et krav af den tilbudte løsning kan anvendes på Android baserede platforme til tablet og smartphone. Tilbudsgiver skal redegøre for hvilke android baserede platforme den tilbudte løsning understøtter. Krav [2.4]: Understøttede platforme Andre typer Kategori: O Type: Ikke funktionelt krav Tilbudsgiver skal redegøre for hvilke andre platforme den tilbudte løsning understøtter. Det kunne f.eks. være Linux eller Google Chromebook. 3. Licens Krav [3.1]: Antal brugere af løsningen Licens. Kategori: MK Type: Ikke funktionelt krav Den tilbudte løsning skal kunne anvendes af alle borgere som er i kontakt med Syddjurs Kommune og deres pårørende. Den tilbudte løsning kan potentielt komme til at blive anvendt af over 1000 medarbejdere. Tilbudsgiver skal tilbyde ordregiver en kommunelicens som giver ordregiver ret til, uden merbetaling, at anvende løsningen til alle ovenstående potentielle brugere. Side 6

4. Adgangskontrol og visning af data Krav [4.1]: Brugeradgang Alle brugere af løsningen både medarbejdere, borgere og pårørende skal logge på den tilbudte løsning med brugernavn og login. Krav [4.2]: Brugeradgang NemId Borgere og pårørende skal kunne logge på den tilbudte løsning med brug af NemId. Krav [4.3]: Brugeradministration borgere og pårørende. Cpr opslag. Oprettelse og vedligehold af stamdata på borgere og pårørende i løsningen skal ske med mulighed for cpr opslag. Ordregiver stiller CPR funktionalitet til rådighed som skal anvendes. Ordregivers CPR komponent betegnes CPR broker. Tilbudsgiver skal redegøre for hvorvidt brug af CPR Broker til cpr opslag er mulig i den tilbudte løsning. Krav [4.4]: Brugeradministration borgere og pårørende. Integration til Avaleo. Det skal være muligt at importere borger-stamdata fra Syddjurs Kommunes omsorgsjournal Avaleo. Side 7

Krav [4.5]: Brugeradministration Medarbejdere. Automatisk import Oprettelse af medarbejdere skal ske via import fra enten ordregivers MDM (SOFD) eller ordregivers Microsoft Active Directory (AD). Hvis tilbudsgiver ikke har en eksisterende integration til ordregivers MDM (SOFD) eller ordregivers Microsoft Active Directory (AD), skal tilbudsgiver oplyse hvor meget det vil koste at udvikle det. Krav [4.6]: Brugeradministration Medarbejdere. Import fra Avaleo. Det skal være muligt at importere medarbejdere fra Syddjurs Kommunes omsorgsjournal (Avaleo). Krav [4.7]: Brugeradministration Vedligehold og sletning af medarbejdere Vedligehold af medarbejder-stamdata og lukning af medarbejderadgang, skal ske via integration til ordregivers MDM (SOFD) eller Microsoft Active Directory. Hvis tilbudsgiver ikke har en eksisterende integration til ordregivers MDM (SOFD) eller ordregivers Microsoft Active Directory (AD), skal tilbudsgiver oplyse hvor meget det vil koste at udvikle det. Krav [4.8]: Brugeradministration Autorisationsstyring Det skal være muligt at tildele forskellige rettigheder til medarbejdere baseret på medarbejderens organisatoriske tilhørsforhold. Side 8

Krav [4.9]: Brugeradministration Autorisationsstyring. Vedligehold. Vedligehold af medarbejderes autorisation skal ske via integration til ordregivers MDM (SOFD), Microsoft Active Directory eller tilbudsgivers Omsorgssystem Avaleo. Hvis tilbudsgiver ikke har en eksisterende integration til ordregivers MDM (SOFD) eller ordregivers Microsoft Active Directory (AD), skal tilbudsgiver oplyse hvor meget det vil koste at udvikle det. 5. Placering af sundhedsdata Krav [5.1]: Placering af sundhedsdata Måledata Den tilbudte løsning skal være forberedt til at kunne lagre og hente måledata - både manuelt indtastede og maskinelt dannede i ordregivers XDS (XDS Syddjurs). Måledata skal lagres i PHMR format. Eksempler på måledata er pulsmålinger og vægt. Krav [5.2]: Placering af sundhedsdata Kontekstdata og Avaleo Kontekstdata i form af f.eks. journalnotater og handleplaner skal kunne hentes fraog lagres i ordregivers EOJ system Avaleo via en snitflade. Krav [5.3]: Placering af sundhedsdata Kontekstdata og Avaleo. Medcom besked. Kontekstdata i form af f.eks. journalnotater og handleplaner skal kunne sendes til ordregivers EOJ system Avaleo som medcom beskeder. Side 9

Krav [5.4]: Placering af sundhedsdata Kontekstdata og XDS Den tilbudte løsning skal være forberedt til at kunne lagre og hente kontekstdata i form af f.eks. journalnotater både manuelt indtastede og maskinelt dannede XDS Syddjurs. Tilbudsgiver skal redegøre for hvornår det vil være muligt i den tilbudte løsning. Tilbudsgiver skal oplyse om det er forbundet med ekstra omkostninger for ordregiver at anvende funktionaliteten når den er udviklet. Krav [5.5]: Placering af sundhedsdata Video/billeder Den tilbudte løsning skal kunne vise videoer og billeder fra webbaserede kilder. F.eks. Youtube.com og video.syddjurs.dk. Krav [5.6]: Placering af sundhedsdata FMK Den tilbudte løsning skal være forberedt til at kunne hente og vise medicinoplysninger om den enkelte borger fra FMK. Krav [5.7]: Placering af sundhedsdata Medicinoplysninger Den tilbudte skal kunne hente og vise medicinoplysninger om den enkelte borger fra ordregivers omsorgsjournal Avaleo. Side 10

Krav [5.8]: Placering af sundhedsdata Avaleo Det skal være muligt for medarbejdere at logge på ordregivers omsorgsjournal Avaleo fra den tilbudte løsning. Både fra en tablet computer og fra en PC. 6. Ejerskab af data Krav [6.1]: Ejerskab af data Kategori: MK Type: Ikke funktionelt krav Ordregiver ejer data som skabes og/eller opbevares i den tilbudte løsning. Også i det tilfælde hvor data ikke kan gemmes i XDS Syddjurs eller øvrige fagsystemer. Krav [6.2]: Ejerskab af data Anvendelse af data Kategori: MK Type: Ikke funktionelt krav Ordregiver skal uden merbetaling kunne anvende data skabt i den tilbudte løsning, til ethvert formål, ordregiver måtte have. Krav [6.3]: Ejerskab af data Borgerdata. Samtykke Det skal være muligt for en borger at give medarbejdere og pårørende samtykke til at se borgerens egne data i den tilbudte løsning. Krav [6.4]: Ejerskab af data Digital værge Det skal være muligt for en borger at udpege pårørende som digital værge. Side 11

Krav [6.5]: Ejerskab af data Differentieret samtykke Det skal være muligt for en borger at differentiere mellem hvilke parter der har adgang til hvilke data, når der gives samtykke. 7. Modulær opbygning Krav [7.1]: Modulær opbygning Den tilbudte løsning skal være modulært opbygget. De enkelte moduler skal kunne aktiveres/deaktiveres i forhold til den enkelte bruger. Eksempler på moduler: Videosamtale (anvendt videoteknologi) Madbestilling (understøttet system) Tilkobling af pulsmåler (type) Udfylde et spørgeskema (skematype) Osv. Krav [7.2]: Modulær opbygning tilbudte moduler Tilbudsgiver skal redegøre for hvilke moduler der tilbydes i den tilbudte løsning. Det skal præsenteres i form at en liste. Krav [7.3]: Modulær opbygning åben platform Ordregiver skal selv kunne udvikle eller få 3. part til at udvikle moduler til den tilbudte løsning, hvis der opstår behov for udvikling af funktionalitet som ikke tilbydes på den tilbudte løsning. Side 12

8. Overblik og beslutningsstøtte Krav [8.1]: Beslutningsstøtte - Triagering Den tilbudte løsning skal kunne håndtere triagering af måledata for borgere. Krav [8.2]: Beslutningsstøtte Alarmer Den tilbudte løsning skal give medarbejderne beslutningsstøtte til mulige handlinger der kan foretages ved borgere, med udgangspunkt i triagering. Krav [8.3]: Beslutningsstøtte Sortering Det skal være muligt for en medarbejder at sortere i hvilke borgere der skal vises for medarbejderen. Sorteringen kan for eksempel være efter triagering, geografi eller diagnose. 9. Brugergrænseflade Krav [9.1]: Brugergrænseflade Platform Det skal være muligt at anvende og navigere rundt i den tilbudte løsning på en PC med brug af mus og tastatur og på en touchskærm med brug af fingrene. Side 13

Krav [9.2]: Brugergrænseflade Grafisk udtryk Brugergrænseflade og navigation skal baseres på ikoner og/eller knapper understøttet af farvekodning af grafiske elementer. Tilbudsgiver skal redegøre for hvorvidt det er opfyldt i den tilbudte løsning. Krav [9.3]: Brugergrænseflade Tilpasning borger (og pårørende) Brugergrænsefladen skal automatisk tilpasse sig den enkelte borger, således at borgeren kun bliver præsenteret for den funktionalitet (de moduler) som borgeren skal anvende. Tilbudsgiver skal redegøre for hvorvidt det er opfyldt i den tilbudte løsning. Krav [9.4]: Brugergrænseflade Tilpasning medarbejdere Brugergrænsefladen skal automatisk tilpasse sig den enkelte medarbejder. Medarbejderen skal kun præsenteres for information som medarbejderen er autoriseret til at se. Hvad medarbejderen må se afhænger af medarbejderens organisatoriske tilknytning og/eller jobfunktion (se Krav [4.8]: Brugeradministration Autorisationsstyring). Tilbudsgiver skal redegøre for hvorvidt det er opfyldt i den tilbudte løsning. Krav [9.5]: Brugergrænseflade Overbliksvisning Det skal være muligt for medarbejdere at vælge en overbliksvisning over udvalgte grupper af borgere eller borgere som f.eks. afviger fra en fastsat normaltilstand (habitualtilstand). Side 14

Krav [9.6]: Brugergrænseflade Søgning Det skal være muligt for medarbejdere at søge borgere frem med en søgefunktion. Krav [9.7]: Brugergrænseflade Multilogin Det skal være muligt for medarbejdere og borgere at logge ind på den tilbudte løsning fra den samme fysiske enhed. 10. Kommunikationsmuligheder Krav [10.1]: Kommunikation - Videosamtale Den tilbudte løsning skal have et videosamtalemodul til kommunikation mellem borgere og medarbejdere og mellem pårørende og medarbejdere. Videosamtale modulet skal være godkendt til brug i Danmark i henhold til lov om datasikkerhed. Krav [10.2]: Kommunikation Audiosamtale Den tilbudte løsning skal have et audiosamtalemodul til kommunikation mellem borgere og medarbejdere og mellem pårørende og medarbejdere. Krav [10.3]: Kommunikation Tekst beskeder Den tilbudte løsning skal have et tekstbeskedmodul til kommunikation mellem borgere og medarbejdere og mellem pårørende og medarbejdere. Side 15

11. Kalenderfunktionalitet Krav [11.1]: Kalender Den tilbudte løsning skal indeholde et kalendermodul, hvor kommunale medarbejderes aftaler med borgeren vises i. Krav [11.2]: Kalender Manuelt input Borgere og medarbejdere skal kunne oprette aftaler i borgerens kalender manuelt. Krav [11.3]: Kalender Import fra Avaleo Borgerrelaterede aktiviteter der er oprettet i ordregivers omsorgsjournal Avaleo, som for eksempel døgnrytmeplaner og/eller visiterede ydelser, skal kunne importeres til kalenderen. 12. Statistik og logning Krav [12.1]: Statistik Til tilbudte løsning skal give mulighed for at generere en brugsstatistik på både enkeltbrugerniveau og på gruppeniveau i forhold til antallet af logins. Krav [12.2]: Logning Til tilbudte løsning skal give mulighed for at borgere kan se logningen af aktivitet der har relation til borgernes egne data. Medarbejdere skal ligeledes have denne mulighed på borgernes egne data. Side 16

13. Åben platform Krav [13.1]: Open Source Kategori: K Type: Ikke funktionelt krav Tilbudsgiver skal redegøre for hvorvidt den tilbudte platform er Open Source og eventuelt hvilken licens den tilbudte platform er frigivet under. Krav [13.2]: Open Source udvikling af ny funktionalitet Kategori: MK Type: Ikke funktionelt krav Det er et krav at ordregiver kan udvikle moduler til den tilbudte løsning som Open Source. De udviklede moduler skal også kunne udvikles af 3. part på bestilling af ordregiver. 3. part kan også være tilbudsgiver. De udviklede moduler vil bl.a. blive gjort tilgængelige under en MPL 2.0 licens via det offentlige digitaliseringsfællesskab OS2. Krav [13.3]: Open Source - betingelser Kategori: MK Type: Ikke funktionelt krav Tilbudsgiver skal redegøre for hvilke modkrav tilbudsgiver eventuelt har for opfyldelsen af Krav [13.2]: Open Source udvikling af ny funktionalitet. Krav [13.4]: Open Source - Økonomi Kategori: MK Type: Ikke funktionelt krav Tilbudsgiver skal redegøre for hvilke omkostninger der er forbundet med opfyldelsen af Krav [13.2]: Open Source udvikling af ny funktionalitet for ordregiver. 14. Performance Krav [14.1]: Performance Kategori: MK Type: Ikke funktionelt krav Den tilbudte løsning og den funktionalitet der er tilgængelig via den, skal være fuldt funktionel på minimum en 3G forbindelse. Side 17

15. Arkitektur og standarder Krav [15.1]: Fælleskommunal rammearkitektur Kategori: K Type: Ikke funktionelt krav Tilbudsgiver skal redegøre for i hvor høj grad den tilbudte anvender komponenter fra den fælleskommunale rammearkitektur. (http://www.kl.dk/imagevault/images/id_55740/scope_0/imagevaulthandler.aspx) Krav [15.2]: Anbefalinger fra NSI Kategori: K Type: Ikke funktionelt krav Tilbudsgiver skal redegøre for hvilke af NSi s anbefalinger til standardisering og referencearkitektur den tilbudte løsning følger. (http://www.ssi.dk/sundhedsdataogit/national%20sundhedsit/standardisering.aspx) Krav [15.3]: HL7 & IHE Kategori: K Type: Ikke funktionelt krav Tilbudsgiver skal redegøre for i hvor høj grad den tilbudte løsning oveholder HL7 CDA R2 Level 3. Krav [15.4]: PHMR Kategori: K Type: Ikke funktionelt krav Tilbudsgiver skal redegøre for i hvor høj grad den tilbudte løsning oveholder PHMR dokumentstandarden og kan gemme og læse dokumenter som overholder denne standard. Side 18