Kontraktbilag - Region Midtjylland€¦ · Web viewDet skal være muligt at foretage et print af en plan i word-, pdf- og rtf-formater. (KP) Det skal være muligt at læse og skrive

KONTRAKTBILAGtil

KONTRAKT OM LEVERING AF SOCIALFAGLIGT IT-SYSTEM SOM SOFTWARE-AS-A-SERVICE

Region Midtjylland – Kontraktbilag Side 1 af 78

INDHOLDSFORTEGNELSE

BILAG 1. INDLEDNING OG TIDSPLAN........................................................................51.1 DEN OVERORDNEDE TIDSPLAN...........................................................................................51.2 DEN DETALJEREDE TIDSPLAN..............................................................................................6

1.2.1 Den detaljerede tidsplan skal endvidere være ledsaget af: 71.2.2 Elementer i tidsplan......................................................................................8

BILAG 2. OM SYSTEMET OG KUNDEN.......................................................................92.1 KUNDENS OVERORDNEDE MÅL...........................................................................................92.2 ORGANISATIONSDIAGRAM.................................................................................................102.3 STRATEGI FOR SOCIALOMRÅDET......................................................................................12

BILAG 3. SYSTEMADMINISTRATION OG SIKKERHED.....................................153.1 SYSTEMADMINISTRATION..................................................................................................153.2 SIKKERHEDSFUNKTIONER..................................................................................................15

3.2.1 Logning................................................................................................................163.2.2 Leverandørens adgang til Systemet.................................................173.2.3 Lokal konfiguration......................................................................................173.2.4 Roller, profiler og brugere.......................................................................183.2.5 Generering af statistik og dataoverblik..........................................183.2.6 Samspil med Kundens brugerstyringssystem.............................193.2.7 Tilpasning af brugerflade.........................................................................21

BILAG 4. FUNKTIONELLE KRAV..................................................................................224.1 REGISTRERING AF INFORMATIONER.................................................................................22

4.1.1 Når en borger kræver anonymitet eller cpr-nummer er uk-endt 224.1.2 Organisering i grupper..............................................................................23

4.2 DOKUMENTATION..............................................................................................................244.2.1 Den individuelle plan..................................................................................254.2.2 Dokumentation af indsatser...................................................................264.2.3 Brug af resultatdokumentation............................................................28

4.3 RISIKOVURDERINGER.........................................................................................................294.4 OPGAVEFORDELING OG PLANLÆGNING...........................................................................304.5 INDBERETNINGER VEDR. BORGERE..................................................................................314.6 INDBERETNING AF MAGTANVENDELSER...........................................................................324.7 DATA OG STATISTIK IFM. INDBERETNINGER....................................................................344.8 INTERN KOMMUNIKATION..................................................................................................344.9 KALENDERFUNKTION.........................................................................................................35

4.9.1 Integration med Exchange......................................................................364.10 MEDICINHÅNDTERING........................................................................................................36

4.10.1 Udlevering og dokumentation af udleveret medicin...............384.10.2 Statistik over medicin og medicinbeholdning.............................39

4.11 BEBOERØKONOMI..............................................................................................................394.12 ADGANG FOR EKSTERNE PARTER.....................................................................................40

4.12.1 Adgangsdifferentiering ved ekstern adgang...............................414.12.2 Nyhedsfunktion..............................................................................................41

4.13 SAGSBEHANDLING.............................................................................................................424.14 DOKUMENTHÅNDTERING...................................................................................................424.15 STATISTIKGENERERING OG DATABEHANDLING................................................................43

4.15.1 Rapportgenerator.........................................................................................444.16 GENERELT VEDR. SYSTEMET............................................................................................44

Region Midtjyllands – Kontraktbilag Side 2 af 78

4.17 SYSTEMET PÅ MOBILE ENHEDER.......................................................................................45

BILAG 5. KUNDENS IT-MILJØ........................................................................................475.1 SNITFLADER.......................................................................................................................47

5.1.1 Snitflader – ajourføring..............................................................................505.1.2 Udbredt klientteknologi............................................................................505.1.3 Mobile enheder...............................................................................................50

5.2 NUVÆRENDE LØSNINGER, MÆNGDER OG DIMENSIONERING..........................................51

BILAG 6. VEDERLAG OG BETALINGSPLAN...........................................................526.1 GENERELT..........................................................................................................................526.2 KONTRAKTVEDERLAG........................................................................................................536.3 BRUGSVEDERLAG OG BRUGERLICENSER..........................................................................546.4 VEDERLAG FOR UDTRÆDELSE OG EXITFEE.....................................................................546.5 TIMEPRISER........................................................................................................................546.6 BETALINGSPLAN OG BETALINGSFORHOLD.......................................................................56

BILAG 7. BESKRIVELSE AF DRIFTSMILJØ OG SYSTEMET.............................577.1 BESKRIVELSE AF DRIFTSMILJØ OG SYSTEMET.................................................................577.2 LEVERANDØRENS BESKRIVELSE AF SYSTEMET................................................................57

BILAG 8. BESKRIVELSER AF TILKNYTTEDE YDELSER....................................588.1 TILKNYTTEDE YDELSER......................................................................................................58

BILAG 9. KUNDENS DELTAGELSE..............................................................................609.1 GENERELT OM KUNDENS DELTAGELSE............................................................................609.2 KUNDENS PROJEKTLEDER OG ANDRE CENTRALE PERSONER..........................................609.3 OVERSIGT OVER RESSOURCEKRÆVENDE AKTIVITETER...................................................61

BILAG 10. SPECIFIKATION AF DRIFTS-, SUPPORT-, VEDLIGEHOLDELSES- OG VIDEREUDVIKLINGSYDELSER......................................62

10.1 DRIFTSMILJØ OG -YDELSER...............................................................................................6210.2 VEDLIGEHOLDELSE, SUPPORT, VIDEREUDVIKLING..........................................................6210.3 BESKRIVELSE AF VEDLIGEHOLDELSE................................................................................6410.4 VIDEREUDVIKLING.............................................................................................................65

BILAG 11. PRØVER................................................................................................................6611.1 OM AFPRØVNING...............................................................................................................67

BILAG 12. LICENSBETINGELSER...................................................................................6812.1 LEVERANDØREN ANFØRER EVENTUELLE RELEVANTE LICENSBETINGELSER...................68

BILAG 13. SERVICEMÅL.....................................................................................................6913.1 FEJL OG FEJLTID.................................................................................................................6913.2 SVARTIDER.........................................................................................................................7013.3 REAKTIONSTID...................................................................................................................7113.4 DRIFTSEFFEKTIVITET, GARANTI OG DRIFTSBOD...............................................................72

BILAG 14. SAMARBEJDSORGANISATION..................................................................7314.1 GRUPPE- OG MØDEFORA..................................................................................................7314.2 LEVERANDØRENS PERSONALE..........................................................................................74

BILAG 15. ÆNDRINGSHÅNDTERING...........................................................................75BILAG 16. OPTIONER...........................................................................................................78

16.1 INTEGRATION MED KUNDENS MAILSYSTEM.....................................................................78


16.2 ELEKTRONISK MEDICINBESTILLING...................................................................................7816.3 LOG-IN VED BRUG AF DIGITAL MEDARBEJDER SIGNATUR...............................................7816.4 LOG-IN VED BRUG AF NEMID..........................................................................................7816.5 INTEGRATION MED FAGSYSTEMER....................................................................................7816.6 Brugeruddannelse – enhedspriser og prisindikation.....................................78

UNDERBILAGA. KravlisteB. Region Midtjyllands informationssikkerhedspolitik C. BeboerbetalingD. Snitflade til ØSE. Snitflade ang. Unge sikredeF. Snitflade ang. SIPG. Use-case 1 – Specialområdet SVOH. Use-case 2 – Specialområdet DOKI. Generel beskrivelse af Region Midtjyllands IT-miljø.J. Præsentation af Region Midtjyllands Identity og Access

management løsning BSK.K. Beskrivelse af BSK screeningsprocessen.L. Retningslinje for systemadministrator passwords.M. Retningslinje for Passwords i Region Midtjylland/ Sammensætning

af adgangskode


BILAG 1 – INDLEDNING OG TIDSPLAN

Bilag 1. Indledning og tidsplan

Vejledning til tilbudsgiver: Besvarelse af krav foretages i Underbilag A, med mindre andet er anført, i overensstemmelse med de deri anførte instruktioner herom.

Leverandøren skal udfærdige en tidsplan for projekts forløb. Tidsplanen skal indeholde: Kundens krav til den overordnede tidsplan på baggrund af hvilke

Leverandøren udarbejder en overordnet tidsplan. Kundens krav til detaljeret tidsplan på baggrund af hvilke

Leverandøren skal udarbejde detaljeret tidsplan. Detaljeret tidsplan skal forelægges for Kunden til godkendelse som led i afklaringsfasen og i øvrigt løbende i projektperioden i overensstemmelse med de tidsfrister, der er fastsat i den overordnede tidsplan.

1.1 Den overordnede tidsplanKrav 1 Der skal udfærdiges en overordnet tidsplan. Den overordnede tidsplan

skal: (MK)

a) Omfatte hele projektforløbet til og med den endelige driftsprøve og skal afspejle væsentlige aktiviteter i de forskellige faser, som løbende udfyldes med mere detaljerede tidsplaner.

b) Tydeligt angive de anvendte faseopdelinger af leverancen, aktiviteterne indeholdt i faserne, afhængigheden mellem faserne.

c) Tydeligt angive de løbende prøver i relation til delleverancerne.d) Angive, hvornår testplanerne fremsendes til Kunden, hvornår de

skal være kommenteret af Kunden, og hvornår de skal være godkendt af Kunden.

e) For hver afprøvning angive perioden fra fremsendelse af den tilhørende dokumentation og frem til det tidspunkt, hvor dokumentationen skal være godkendt af Kunden.

f) Angivelse af perioder for de detaljerede tidsplaner samt hvornår de fremsendes til Kunden. Den første detaljerede tidsplan skal foreligge i afklaringsfasen.

g) Indeholde en angivelse af ansvarsforhold, herunder ifm. projektarbejde, konvertering, afprøvning, dokumentation og kvalitetssikring i forbindelse med ibrugtagning af systemet.

h) Beskrive, hvorledes anførte metoder for projektstyring og kvalitetssikring indgår i projektforløbet.



i) Angive, hvorledes Leverandøren forud for prøverne har draget omsorg for, at såvel overtagelsesprøven som driftsprøven med størst mulig sandsynlighed kan afvikles uden væsentlige problemer.

j) Markere, hvilke aktiviteter Leverandøren anser som kritiske for projektets forløb.

k) Den endelige driftsprøve skal kunne gennemføres, således at endelig godkendelse kan foreligge senest et år efter kontraktindgåelse.

l) Markere de bodslagte milepæle. Disse er:

Beståelse af den samlede overtagelsesprøve,

Beståelse af driftsprøven og

Deadline for evt. senere leveret funktionalitet (svarende til besvarelse med kode 3). Dette skal være markeret i tidsplanen.

Krav 2 Synliggøre de af Leverandøren tilbudte optioner, jf. kontraktbilag 16. (MK)

1.2 Den detaljerede tidsplan Krav 3 Leverandør skal udfærdige en detaljeret tidsplan, som forelægges for

Kunden til godkendelse som led i afklaringsfasen og i øvrigt løbende i projektperioden i overensstemmelse med de tidsfrister og krav, der er fastsat i den overordnede tidsplan. (MK)

Krav 4 Såfremt ændringer skal foretages i planen, forelægges revideret tidsplan til Kundens godkendelse. (MK)

Krav 5 Udarbejdelse af detaljeret tidsplan for projektet skal ske i overensstemmelse med følgende krav: (MK)

a) Den detaljerede tidsplan skal som minimum omfatte perioden frem til næste detaljerede tidsplan (faseafslutning), jf. den overordnede tidsplan. Der skal angives sporbarhed mellem den overordnede tidsplan og den detaljerede tidsplan.

b) Detaljeret tidsplan for projektet sendes til Kunden i overensstemmelse med fristerne i den overordnede tidsplan.

c) Den detaljerede tidsplan vedlægges som appendix til bilagsmaterialet, når den er godkendt af Kunden.

d) Den detaljerede tidsplan skal vise afhængighederne mellem aktiviteterne.



e) Der skal være overensstemmelse mellem afhængighederne i den overordnede tidsplan og afhængighederne i den detaljerede tidsplan.

f) Den detaljerede tidsplan skal omfatte samtlige aktiviteter, som bidrager til projektets realisering, herunder også aktiviteter hos evt. underleverandører.

g) Den detaljerede tidsplan skal som minimum efterleve de krav, som er stillet i den overordnede tidsplan.

For hver aktivitet i den detaljerede tidsplan er det gældende at:

h) Aktiviteten er målbar og inkludere en test og dokumentation for om aktiviteten er opfyldt.

i) Hvilke forhold, der skal være opfyldt for at aktiviteten er afsluttet – hermed indforstået, at det skal være målbart, om aktiviteten er afsluttet.

Tidsplanen skal som minimum indeholde de nedenstående implementeringsydelser:

a) Introduktion til det kommende system – demonstration på områdeledermøde

b) Deltagelse i diverse projektgrupper mv.c) Projektledelse d) Konvertering af datae) Migration af dataf) Integration til andre systemerg) Uddannelseh) Opfølgning – ibrugtagning af systemerne

1.2.1 Den detaljerede tidsplan skal endvidere være ledsaget af:

Krav 6 Beskrivelse af Kundens medarbejderinddragelse i planlægningen og implementeringen af leverancen, herunder angivelse af ressourceindsatsen for Kundens medarbejdere Se nærmere Bilag 9. (MK)



1.2.2 Elementer i tidsplan

Krav 7 Tidsplanen skal mindst indeholde følgende elementer med angivelse af start og sluttidspunkt: (MK)

a) Kontraktunderskrift

b) Demonstration for områdeledere

c) Implementeringsfase, herunder:

- Integrationer og snitflader

- Konvertering af data

- Opsætning og konfiguration

- Uddannelse af superbrugere og administratorer

- Overtagelsesprøve

d) Overtagelsesdag/driftsstart

e) Driftsprøve

Krav 8 Den samlede løsning skal være fuldt ud implementeret til overtagelse/driftsstart og med fuld adgang for alle de omfattede socialfaglige tilbud i henhold til Kontrakten senest den 31. dec. 2015. (MK)


BILAG 2 – OM SYSTEMET OG KUNDEN

Bilag 2. Om Systemet og Kunden

Kunden har i kontraktbilaget anvendt følgende terminologi om centrale enheder og aktører:

Centraladministration: Fællesadministrationen for Psykiatri og Socialområderne.

Specialområdernes administration: Eet specialområde dækker over flere tilbud, og disse tilbud har en administration til fælles.

Administrator: En medarbejder, som er ansvarlig for administrationen af it-systemet på det enkelte tilbud. Administrator vil typisk have 2 adgange til systemet, en adgang som administrator og en adgang som Superbruger eller Bruger.

Superbruger: Medarbejder med uddannelse og erfaring i brug af dele af systemet.

Bruger: Medarbejderen på det respektive tilbud, som i sin arbejdsfunktion er bruger af it-systemet.

Medarbejder: En medarbejder på det respektive tilbud. Borger: Person som bor på eller deltager på et dag- eller

døgntilbud.

2.1 Kundens overordnede mål Socialområdet i Region Midtjylland har formuleret en række (uprioriterede) overordnede mål med anskaffelsen af systemet:

At anskaffe et brugervenligt system, der er målrettet brugerne og hermed sikrer og højner kvaliteten af arbejdet omkring borgeren.

At etablere hurtig og let adgang til overskuelig og opdateret information

At samle dokumentation af indsats og information om borgeren på ét sted

At lette videndeling og gennemsigtighed omkring borgerrettede indsatser og effekter

At tilgodese lovkrav og krav om journalisering og digitalisering At udveksle data med andre interessenter (eksempelvis

pårørende, læger, kommuner, regioner eller statslige organer). At skabe større mobilitet i brugen af Systemet.

2.2 Organisationsdiagram Organisationsdiagram for Region Midtjylland – ledelse, administration og socialområdet:



Figur: Organisationsdiagram for Socialområdet

Region Midtjylland er i dag en af de største enkeltstående leverandører på det specialiserede socialområde i Danmark. Socialområdet består af 31 sociale tilbud, der er samlet i ni specialområder. Otte specialområder benytter Systemet fordelt på 30 sociale tilbud. Nedenfor ses specialområdeinddelingen, de sociale tilbud og deres volumen fordelt på dag- og døgnpladser.


DirektionPsykiatri- og socialledelsen (PSL)

Specialområde

SOH

Specialområde

SUA

Specialområde

SAU

Specialområde

SVO

Specialområde

DOK

Specialområde

SBU

Specialområde

UFH

Tilbud

Boligerne Svalevej

Tilbud

Høskoven

Tilbud

Tagdækkervej

Specialområde

Holmstrupgaard

Tilbud

Bygmarken

Tilbud

Granbakken

Afdeling

Afdeling

Afdeling

Afdeling

Afdeling

PS-administrationen

Ledelsessekretariatet HR

Økonomiafdeling Kommunikation og formidling

Kvalitetsafdelingen Psykiatriplanlægning

Socialplanlægning


Specialområde Tilbud

Pladser

Netto-budget 2014

i

dag Døgn i altAnsatte

Pr. 15.09.14

1.000 kr.

Udviklingshæmning og ADHDwww.sua.rm.dk

BygmarkenElbæk HøjskoleGranbakkenMosetoftNørholm KollegietSaustrupStormly, selvejende

122 174 296 520 147.387

Autismewww.sau.rm.dk

BækketoftenGudenåkollegietHinnerup Kollegiet

150 168 318 475 118.292

Hjerneskadewww.soh.rm.dk

Boligerne Svalevej HøskovenTagdækkervej

160 118 278 591 113.265

Socialpsykiatri Voksnewww.svo.rm.dk

BlåkærgårdGårdhavenPilebakkenSct. MikkelSønderparkenTangkær

5 168 173 414 115.658

Kriminalitetstruede og Dømte Børn og Ungewww.dok.rm.dk

Den sikrede døgninstitution GrenenDen sikrede døgninstitution KoglenMultifunC Midtjylland

41 62 103 287 113.409

Holmstrupgårdwww.holmstrupgaard.rm.dk

Den selvejende institution Holmstrupgård

63 60 123 196 67.308


http://www.holmstrupgaard.rm.dk/

http://www.holmstrupgaard.rm.dk/

http://www.dok.rm.dk/

http://www.svo.rm.dk/

http://www.soh.rm.dk/

http://www.sau.rm.dk/

http://www.sua.rm.dk/


Specialområde Tilbud

Pladser

Netto-budget 2014

i

dag Døgn i altAnsatte

Pr. 15.09.14

1.000 kr.

Socialpsykiatri Børn og Ungewww.sbu.rm.dk

Behandlingsinstitutionen Hald EgeHimmelbjerggårdenOustruplund

95 75 170 195 71.555

Udviklingsforstyrrelser og fysiske handicapwww.ufh.rm.dk

Børn- og unge Centret EngvejenFenrishusMøllebækkenUlriksdal

27 112 139 464 126.757

I ALT 663 937 1.600 3142 873.631

Det kommende socialfaglige IT-system skal kunne understøtte en hverdag og praksis, der muliggør arbejdet på otte specialområder med meget forskellige målgrupper. For at give et indblik i områdernes arbejdshverdag er vedlagt to use-cases – to eksempler på medarbejderes hverdag og nuværende brug af socialfagligt IT-system. Se Underbilag G og H.

2.3 Strategi for socialområdetSom leverandør af højt specialiserede tilbud på det sociale område stræber Region Midtjylland efter at være garant for, at der er fagligt kvalificerede tilbud til borgere med komplekse handicaps og særlige behov. Borgeren er som den direkte bruger af tilbuddene i fokus, og det er kommunen som myndighedshaver og betaler også. Det kræver et tæt samarbejde med kommunen og borgeren. Et samarbejde som former regionens leverandøropgave. Regionen skal kunne løse nogle af de sværeste opgaver for kommunerne, og skal dermed kunne løse de særligt komplekse og sjældne opgaver.


http://www.ufh.rm.dk/

http://www.sbu.rm.dk/


Socialområdet har udarbejdet en ”Social Strategi” (november 2013). Det er en strategisk plan, der udstikker de overordnede mål for de kommende års udvikling, og som realiseres over de kommende år.Med ”Social Strategi” sættes der fokus på initiativer, som kan sikre fortsat høj kvalitet.

Regionens specialisering skal udvikles med udgangspunkt i at identificere begrænsninger og udviklingspotentiale - med fokus på og i samarbejde med den enkelte borger. På den ene side arbejdes med rehabilitering. Det vil sige målrettet opbygning af praktiske eller sociale kompetencer og samarbejde med borgeren om at udvikle evnen til at tage ansvar og til aktivt medborgerskab.

På den anden side arbejdes med indsatser, der har en mere omsorgspræget karakter, hvor det drejer sig om at kunne vedligeholde funktioner og skabe rammer for et godt liv. I langt de fleste tilfælde kan der arbejdes med begge spor samtidig.

Et mål med ”Social Strategi” er at sikre, at arbejdet med at opnå produktivitet og effektivitet for de samme ressourcer målrettes. Det er vigtigt, at flest mulige borgere modtager den bedst mulige indsats for de samme midler. Derfor skal regionen levere effektive tilbud og samtidig dokumentere indsats og resultater med henblik på at producere viden, der kan optimere den fremtidige indsats.

Endelig skal ”Social Strategi” bidrage til at skabe, udvikle og drage nytte af samarbejdsrelationer på tværs. Både internt i det regionale sociale område, men også eksternt. Det kan være samarbejde med kommuner i og udenfor regionen, Socialstyrelsen, bruger- og pårørendeforeninger, uddannelsesinstitutioner, forskningsinstitutioner og sundhedsområdet.

Social Strategi tager afsæt i hovedvisionen:

Nødvendig viden – målrettet indsats – bedre liv – til flere

Hovedvisionen er opdelt i 4 individuelle og forbundne temaer, som skal udstikke retningen for de kommende års videreudvikling af området.

Nødvendig viden handler om målrettet anvendelse af kompetencer og at sikre rammerne for at skabe, samle og dele den viden, det regionale socialområde har behov for med henblik på fortsat udvikling og specialisering.



Målrettet indsats handler om at arbejde systematisk og videnbaseret for at fokusere de faglige ressourcer til den enkeltes behov og opnå det ønskede resultat.Bedre liv handler om fokus på livskvalitet, sundhed og sociale netværk. Det regionale socialområde skal forbedre liv gennem fokus på individuelle mål og indsatser samt arbejde på, at borgeren er aktør i eget liv.Til flere handler om, at der skal arbejdes fagligt effektivt med henblik på at opnå mest muligt med de ressourcer, der er til rådighed.”Social Strategi” findes på www.socialstrategi.rm.dk


http://www.socialstrategi.rm.dk/

BILAG 3 – SYSTEMADMINISTRATION OG SIKKERHED

Bilag 3. Systemadministration og sikkerhed


3.1 Systemadministration

INFO:

Leverandør skal levere eet System, som kan anvendes på socialområdet i Region Midtjylland, som består af 3 organisatoriske niveauer:

PS-administrationen

Specialområder

Tilbud

Krav 9 Leverandøren skal angive hvorledes en implementering af Systemet skal ske således for at sikre Kundens overordnede mål for Systemet indfries og i henhold til Kundes angivne mindstekrav. (KP)

Krav 10 Det skal være muligt at lave konfigurationer på hhv. specialområdeniveau og tilbudsniveau. (MK)

Krav 11 Data skal kunne aggregeres opad i organisationen uafhængigt af tilpassede konfigurationer på hhv. specialområdeniveau og tilbudsniveau. (MK)

3.2 Sikkerhedsfunktioner

Vejledning til Tilbudsgiver: Tilbudsgiver skal i forhold til Region Midtjyllands informationssikkerhedspolitik kommentere nedenstående forhold. Region Midtjyllands informationssikkerhedspolitik er vedlagt som Underbilag B.

Krav 12 Leverandøren skal forholde sig til sin evne til at overholde Region Midtjyllands informationssikkerhedspolitik. (MK)



Krav 13 Mailkorrespondance der udgår fra Systemet skal ske via Kundens mailsystem som sikker mail. Der må ikke forekomme korrespondance mellem systemerne i ukrypteret eller usigneret form. (MK)

3.2.1 Logning

Krav 14 Det skal være muligt at søge i loggen på bestemte brugere, der har fremsøgt personoplysninger, foretaget ændringer i, oprettet eller slettet poster. (MK)

Krav 15 Det skal være muligt at foretage en udskrivning eller kopiering af loggens oplysninger til ledelsen, revisionen eller interne sikkerhedsmedarbejdere afgrænset på detaljerede udvalgskriterier. (MK)

Krav 16 Systemet skal kunne sende logdata til et eksternt logsystem i standard syslog format (RFC 5424) eller tilsvarende, for at sikre logdatas arkivering og tilgængelighed i den krævede logperiode. (KP)

Krav 17 Det skal være muligt at angive et tydeligt revisions- og transaktionsspor. (MK)

Krav 18 Det skal være muligt at kunne foretage logning af alle afviste adgangsforsøg. Hvis der inden for en fastsat periode er registreret et nærmere fastsat antal på hinanden følgende afviste adgangsforsøg fra samme arbejdsstation eller med samme brugeridentifikation, skal der ske en automatisk blokering af yderligere forsøg. Der henvises til Sikkerhedsbekendtgørelsens § 18 (bkg. nr. 528 af 15/6 2000 om sikkerhedsforanstaltninger til beskyttelse af personoplysninger, som behandles for den offentlige forvaltning, som ændret ved bkg. nr. 201 af 22/3 2001). (MK)

Krav 19 Logning af brugertransaktioner skal kunne gemmes elektronisk i minimum 5 år. (MK)



Krav 20 Såfremt systemet ikke har været i brug i en af Kunden pre-defineret periode, skal der kunne foretages en låsning af adgang til systemet, men ikke logge brugeren af. Ny adgang til systemet skal kræve fornyet logon af brugeren. (MK)

Krav 21 Administrator skal kunne ændre/opsætte og konfigurer en periode for inaktivitet før låsning af systemet, inden for en overordnet fastsat tidsramme. (MK)

Krav 22 Det skal være muligt at gemme indtastninger, selvom der ikke er foretaget en færdig indtastning/indberetning, således at der ikke vil være datatab i forbindelse med nedbrud mv. (KP)

3.2.2 Leverandørens adgang til Systemet

Krav 23 Leverandøren skal gøre det klart under hvilke forhold, at Leverandørens medarbejdere skal tilegnes adgang til Region Midtjyllands data, herunder hvilke logdata som kan udleveres på forlangende til Leverandøren medarbejdere, under hvilke forhold og til hvilket formål. (KP)

Krav 24 Leverandøren skal sikre at sikkerhedskrav til Systemet overholdes (MK)

3.2.3 Lokal konfiguration

INFO:Det er et gennemgående træk, at det enkelte specialområde og socialfaglige tilbud, administrativt og kontekstuelt, har en autonomi, som Systemet differentierende skal kunne understøtte.

Krav 25 Leverandør skal i en beskrivelse af, hvorledes Systemet kan konfigureres individuelt til det lokale tilbud, forholde sig til: (KP)

1) Gruppering af medarbejdere og borgere efter en lokal organisation.

2) Styring af information ift. den lokale organisation.3) Ingen ekstern adgang til lokale data, med mindre daglig leder, IT

ansvarlig, eller andre ansvarlige for tilbuddet selv giver adgang hertil.

4) Begrænsning af brugers adgang til data, således at de svarer til brugernes organisatoriske placering.



Krav 26 Administrator skal selvstændigt og uafhængigt af systemets leverandør kunne konfigurere systemet. (KP)

Krav 27 Det enkelte socialfaglige tilbud skal kunne anvende egen lokal terminologi i Systemets dokumenter ifm. at: (KP)

at oprette, vælge og redigere felter, således at terminologi tilpasses det enkelte socialfaglige tilbud.

at formulere og placere lokale instrukser alt efter medarbejdernes opgaveløsning.

Krav 28 Kunden skal kunne varetage alle aspekter ved brugeradministration uden involvering af leverandøren, herunder oprettelser, ændringer og sletninger af brugerkonti og organisationsenheder. Brugeradministration skal kunne foretages lokalt af en administrator. (KP)

Krav 29 Administrator skal have mulighed for at begrænse adgangen til systemet. (KP)

3.2.4 Roller, profiler og brugere

Krav 30 Det skal være muligt for en administrator at kunne konfigurere systemet til grupper af medarbejdere inden for de respektive socialfaglige tilbud. (KP)

Krav 31 Systemet skal følgende kunne konfigureres til at muliggøre en personalisering af brugergrænsefladen, således indhold og funktionsmuligheder præsenteret for den enkelte bruger, kan tilpasses i forhold til brugerens arbejdsfunktion og rettigheder. (KP)

3.2.5 Generering af statistik og dataoverblik

Krav 32 Det skal være muligt for en administrator at kunne hente statistik over brugerdata: Seneste logon, Seneste kodeskift, Oprettelsesdato, Seneste ændring, Antal aktive brugere. (KP)

Krav 33 Statistik som nævnt i krav 39 skal kunne gemmes i alment accepteret format, Excel eller CSV. (KP)



3.2.6 Samspil med Kundens brugerstyringssystem

INFO:

Region Midtjylland anvender Bruger Stamdata Katalog (BSK), som er et eget udviklet brugerstyringssystem.

Se nærmere herom i Underbilag I og J.

Krav 34 Systemet skal kunne integreres med BSK, således at der ved brugeroprettelse kan importeres oplysninger og rettigheder fra BSK, hvis brugeren i forvejen er defineret heri. (MK)

Krav 35 Løsningen skal sikre identifikation af brugere ud fra deres brugerID i ordregivers Identity Management løsning (BSK).

Krav 36 Løsningen skal ved integration med BSK understøtte autentificering af brugerne ved en af følgende modeller: (KP)1. Bruger-ID/password (Secure LDAP)2. Føderation med understøttelse bland andet: SAML, OIOSAML og WS-Trust 3. Windows sign-on (kerberos/Trust)

I alle tilfælde skal autentificeres op imod BSK, og altid under overholdelse af Kundens krav til passwords kompleksitet (se Underbilag L og M), udskiftningsfrekvens, spærring ved mislykkede forsøg på adgang, logning af adgange/forsøg etc.Hvis windows sign-on (kerberos/Trust) tilbydes, skal tilbudsgiver være opmærksom på at ordregiver har flere Active Directories og at de ikke nødvendigvis er forbundet med AD trusts Løsningen skal desuden understøtte 2-faktor identifikation ved RSA.

Krav 37 Løsningen skal indeholde bruger- og rettighedsstyring, der gør det muligt for Kunden med et minimum af ressourceindsats at granulere og styre brugernes adgange til at benytte funktioner og tilgå data, og således at alene autoriserede brugere kan tilgå data, og med fuld sporbarhed af hvem der har tilgået - eller forsøgt at tilgå - funktioner og data, hvornår og hvorfra, og hvem der har godkendt og tildelt disse adgange. (MK)

Krav 38 Privilegier/rettigheder skal knyttes til brugere gennem et rollebegreb, således at brugere kan tildeles og fratages rettigheder gennem tildeling/fratagelse af roller. Rollebegrebet skal være baseret på veldefinerede RBAC principper (Role Based Access Controls). (MK)



Krav 39 Dokumentationen for Løsningen skal indeholde et overblik over den tilbudte bruger- og rettighedsmodel, og en beskrivelse af hver af de roller, sikkerhedsparametre mv. som indgår. Beskrivelsen skal give et billede af standardroller og rettighedstyper, hvilke typer af brugere, der er tiltænkt hvilke roller, og hvilke roller/funktioner/dataadgange der er indbyrdes uforenelige, ud fra almindelige principper for SOD / funktionsadskillelse. (MK)

Krav 40 Kunden skal selv kunne oprette og tilpasse roller og rettighedsprofiler, og selv kunne tildele disse til specifikke brugere. (MK)

Krav 41 Det skal være muligt at vise sporbarheden, når der foretages ændringer i tildelte rettigheder og roller. (MK)

Krav 42 Systemet skal understøtte, at en bruger kan have flere roller tilknyttet. Dog skal det generelt søges at definere rollerne så bredt som muligt, således at behovet for at være tilknyttet flere roller, minimeres. (KP)

Krav 43 Det skal være muligt at foretage sikkerhedsmæssige ændringer (rettelse af fejl eller tilpasninger ved ændrede, sikkerhedsmæssige krav), som er nødvendige af hensyn til ordregivers lovgivningsmæssige forpligtelser. (MK)

Krav 44 Løsning skal understøtte og stille veldefinerede snitflader til rådighed for en provisionering af brugere og adgangsrettigheder i Løsningen - gennem hele deres livscyklus - kan ske vha. udbredte værktøjer til automatiseret administration af brugere og adgangsrettigheder (såkaldt Identity & Access Management værktøjer). (KP)

Krav 45 Leverandør skal redegøre for, hvorledes understøttelsen er etableret, herunder hvilke snitflader og evt. IAM-værktøjer, som understøttes. (KP). ”Præsentation af BSK – Region Midtjyllands Identity and Access management platform” kan rekvireres efter aftale med Kunden.

Krav 46 Det skal være tydelige for medarbejdere med flere logins, eks. administrator, at se hvilken rolle det er logget ind med. (MK)



3.2.7 Tilpasning af brugerflade

Krav 47 En bruger skal kunne tilpasse brugerfladen til sit daglige brug inden for rammerne af den overordnede opsætning af arbejdsgrupper (KP)

Krav 48 Systemet skal kunne konfigureres til at tilpasse brugerfladen, således at indhold og funktionsmuligheder, der præsenteres for den enkelte bruger, er tilpasset i forhold til brugerens arbejdsfunktion og rettigheder. (MK)

Krav 49 Den enkelte bruger skal kunne tilpasse viste kolonner og sortere i lister og derved få præsenteret den, for brugeren, relevante information (KP)


BILAG 4 - FUNKTIONELLE KRAV

Bilag 4. Funktionelle krav


4.1 Registrering af informationer Krav 50 Brugeren skal kunne registrere borgers navn, cpr-nummer , e-mail,

Indskrivningsdato, Udskrivningsdato, Indskrivningsårsag, Udskrivningsårsag. (MK)

Krav 51 Det skal være muligt for brugere at oprette kontaktpersoner med angivelse af navn, adresse, telefonnummer, personlige oplysninger, tilhørsforhold til borger. (MK)

4.1.1 Når en borger kræver anonymitet eller cpr-nummer er ukendt

INFO:

I visse tilfælde har socialområdet brug for at udvise særlige hensyn i forbindelse med registrering og adgang af data på borgere indskrevet på et socialfagligt tilbud. En borger kan have ønske om - eller have et lovmæssigt krav på at blive behandlet anonymt.

Krav 52 Det skal være muligt at oprette borgere med erstatnings cpr-nummer (MK)

Krav 53 Det skal være tydeligt for brugeren, hvorvidt en borger er registreret med et erstatnings cpr-nummer. (KP)

Krav 54 Systemet skal kunne understøtte, at alle lovpligtige indberetninger til styrelser kan gennemføres i anonymiseret form for borgere, hvor dette er relevant. (KP)

Krav 55 Hvis en borger går fra anonym registrering til registreret ved eget cpr-nummer, skal systemet kunne understøtte en ændring af alle registreringer på borgeren, dvs. med korrekt cpr-nr. uden at der skal foretages nye indberetninger, således at de eksisterende oplysninger bevares på korrekte cpr-numre. (KP)



4.1.2 Organisering i grupper

INFO:

Socialområdet består af en organisatorisk hierarkisk opbygning suppleret med tværgående samarbejder og grupperinger.

Niveauerne i organisationen på Socialområdet er:

Psykiatri- og socialledelsen/ PS administrationen

Specialområde

Tilbud

Afdeling

Team

Krav 56 En administrator og/eller superbruger skal kunne oprette teams, som er en gruppe af medarbejdere. (KP)

Krav 57 En medarbejder skal kunne være med i flere teams. (KP)

Krav 58 Et team skal kunne bestå af medarbejdere på tværs af deres organisatoriske placering. (KP)

Krav 59 Brugeren skal kunne anvende teams på lige fod med en enkelt medarbejder. Dvs. et team skal kunne oprettes som ansvarlig for en given borger. (KP)

Krav 60 En superbruger skal kunne organisere borgere i grupperinger på en afdeling. (KP)

Krav 61 En superbruger skal kunne organisere borgere i andre grupperinger end i forhold til deres placering på en afdeling. (KP)

Krav 62 Brugeren skal kunne få en oversigt over forskellige grupper: Medarbejdere, Pårørende, Samarbejdspartnere og Borgere. (KP)



4.2 DokumentationKrav 63 Det skal være muligt for brugere at foretage en daglig dokumentation.

(MK)

INFO:

Socialområdet består af flere forskellige specialområder, som henvender sig til hver sig gruppe af borgere.

I varetagelsen af den daglige funktion foretager hvert specialområde daglige dokumentationer. Indholdet i denne dokumentation kan variere alt efter hvilket gruppe af borgere som dokumentationen omhandler.

For Kunden indgår der i en daglig dokumentation som minimum følgende aktiviteter:

- Skriv i handlingsplaner

- Medicinregistreringer

- Registrering af borgers aktiviteter

- Indberetninger



Krav 64 Det skal være muligt at foretage søgning og læsning af daglige dokumentationer. (MK)

Krav 65 Brugeren skal kunne knytte daglig dokumentation til borgerens individuelle plan eller definerede mål/indsatsområder. (KP)

Krav 66 Brugeren skal kunne vedhæfte dokumenter til sin daglige dokumentation. (KP)

Krav 67 Flere brugere skal kunne skrive daglig dokumentation på samme borger på én gang. (KP)

Krav 68 Det skal være muligt, at linke en hændelse/et arrangement til flere borgere, som har været involveret. (KP)

Krav 69 Det skal være muligt at skrive daglig dokumentation ved hjælp af få klik. (KP)

Krav 70 Daglig dokumentation skal kunne vises kronologisk med tidsstempel. (KP)

Krav 71 Superbruger skal kunne definere egne kategorier/emner og oprette en niveaudeling indenfor daglig dokumentation, således at det er muligt at arbejde med egen defineret kategorisering af dokumentationen. (KP)

Krav 72 Det skal være muligt, at søge, læse og skrive daglig dokumentation på mobile enheder (Se krav vedr. mobile enheder i afsnit 4.17) (KP)

Krav 73 Brugeren skal kunne dokumentere faglige observationer, som ikke er borgerspecifikke, men som er relevante for tilbuddets medarbejdere. (KP)

4.2.1 Den individuelle plan

INFO:

Den individuelle plan er overskriften for de mange typer af planer, som Socialområdets tilbud udarbejder sammen med borgerne, vedrørende borgernes ophold og aktiviteter samt mål for udvikling.

Planer kan strække sig over få uger til op til flerårige tidsrum. Planer kan indeholde billede- og videodokumentation, som understøtter fx måden, de beskrevne mål skal udføres på.



Krav 74 Systemet skal understøtte en arbejdsplanlægning hvor den individuelle plan er grundlaget for indsatserne. (Planer er beskrevet i en info-box) (MK)

Krav 75 Superbrugeren skal kunne oprette tilbudsspecifikke skabeloner til de forskellige planer enkelt og intuitivt og uden nødvendigvis at kende hele systemets opbygning. (KP)

Krav 76 Brugeren skal kunne oprette det antal planer på hver borger, som de respektive tilbud ønsker. (KP)

Krav 77 Brugeren skal kunne skrive og efterfølgende redigere i de enkelte planer. (KP)

Krav 78 Brugeren skal kunne overføre data fra en plan til en anden med enkelte klik/ drop down menu. (Genbrug af data) (KP)

Krav 79 Det skal være muligt at printe en plan, dels som den foreligger, dels med udvalgte afsnit og/ eller punkter efter brugerens valg. (KP)

Krav 80 Det skal være muligt at foretage et print af en plan i word-, pdf- og rtf-formater. (KP)

Krav 81 Det skal være muligt at læse og skrive i planer på mobile enheder. (Se krav vedr. mobile enheder i afsnit 4.17) (KP)

4.2.2 Dokumentation af indsatser

INFO:

Socialområdets tilbud arbejder med forskellige metoder til måling af resultater af sociale indsatser for hver enkelt borger eller resultatdokumentation.



Krav 82 Systemet skal understøtte dokumentationen af indsatser overfor borgerne. (MK)

Krav 83 Brugeren skal kunne foretage en opfølgende dokumentation på en plan (eventuelt via den daglige dokumentation). (KP)

Krav 84 Brugeren skal kunne oprette mål og delmål, og knytte dem til en plan. (KP)

Krav 85 Brugeren skal kunne dokumentere indsats i forhold til delmål med direkte kobling til målbeskrivelsen i den enkelte plan. (KP)

Krav 86 Brugeren skal kunne overføre/tilknytte mål og delmål fra en plan til en anden plan. Også mellem planer på forskellige borgere. (KP)

Krav 87 Det skal være muligt at oprette standardmål med tilknyttede delmål, som kan tilknyttes planer. (KP)

Krav 88 Det skal være muligt at overføre felter fra en plan til brevskabeloner. (KP)

Krav 89 Det skal være muligt at dokumentere indsats på mobile enheder (Se krav vedr. mobile enheder i afsnit 4.17) (KP)

INFO:

I en understøttelse af arbejdet på socialområdet er brug af data indhentet ved spørgeskemaer vist sig at være en nyttig kilde for informationer. Spørgeskemaer udgør et essentielt værktøj i indsamling af informationer, som ikke på forhånd er at finde i Systemet.



Krav 90 Det skal være muligt at oprette spørgeskemaer. (KP)

Krav 91 Spørgeskemaer skal kunne knyttes til en Borger. (KP)

Krav 92 Spørgeskemaer skal kunne knyttes til en Medarbejder og en Afdeling. (KP)

Krav 93 Data fra Systemet skal kunne indarbejdes i spørgeskemaer. F.eks. Borgernavn, Borgerafdeling osv. (KP)

Krav 94 Spørgeskemaer skal kunne printes. (KP)

Krav 95 Besvarelser skal kunne eksporteres til behandling i Microsoft Office og LibreOffice. (KP)

Krav 96 Svar i spørgeskemaer skal kunne overføres til andre områder i Systemet uden manuel behandling. (KP)

Krav 97 Det skal være muligt at udfylde spørgeskemaer på mobile enheder (Se krav vedr. mobile enheder i afsnit 4.17) (KP)

4.2.3 Brug af resultatdokumentation

Krav 98 Systemet skal understøtte måling af indsatser overfor borgerne. (MK)

Krav 99 Det skal være muligt at foretage resultatdokumentation baseret på data hentet ved såvel kvantitative som kvalitative undersøgelser. (KP)

Krav 100 Det skal være muligt at opsætte målinger på en borger. (KP)

Krav 101 Det skal være muligt at opsætte målinger på en afdeling. (KP)

Krav 102 Det skal være muligt at opsætte målinger på en medarbejder. (KP)

Krav 103 Resultatmålingerne skal kunne aggregeres på borger-, afdelings- og områdeniveau ved at samle facts, aggregere og generere dokumentation og resultater på baggrund af registrerede data. (KP)

Krav 104 Det skal være muligt at anvende afkrydsningsskalaer ved målinger. (KP)

Krav 105 Det skal være muligt at tilføje kommentarer til målinger. (KP)

Krav 106 Det skal være muligt at journalisere og udskrive resultatet af resultatmålinger via enkle grafiske redskaber, således progression, stagnation eller tilbagefald kan dokumenteres. (KP)



Krav 107 Der skal være mulighed for at genanvende data fra resultatmålinger, dvs. indsætte eet sæt af registreringer til brug i andre skemaer (eks. ICF eller tilsvarende). (KP)

4.3 Risikovurderinger

INFO:

Kunden anvender primært Bröset Violence Checklist som værktøj til risikovurderinger, men der anvendes også andre lignende værktøjer.

En risikovurdering af en borger foretages efter en fastlagt plan og/eller efter behov. Når der risikovurderes tager medarbejderne udgangspunkt i borgerens habituelle tilstand.

En risikovurdering består af en eller flere vurderinger af en borger. Vurderinger og samlet resultat af en risikovurdering er kvantitativ.

Det samlede resultat og hver enkelt vurdering, kan medføre en række handlingsanvisninger til medarbejderne. F.eks. ”Medarbejdere må ikke være alene med borgeren”.

Handlingsanvisninger er midlertidige og ophører efter fastlagt tidsforløb og/eller efter resultater af efterfølgende risikovurderinger. F.eks. ”Mindst 24 timer og seneste to risikovurderinger svarende til habituel tilstand”.

Handlingsanvisninger vil typisk være standardanvisninger i forhold til den enkelte borger.

Krav 108 Systemet skal kunne modtage data fra 3. partssystemer. (MK)

Krav 109 Det skal være muligt at registrere risikovurderinger på borgere. (KP)

Krav 110 Resultaterne af en borgers risikovurderinger skal være let tilgængelige for alle medarbejdere med primært fokus på seneste risikovurdering. (KP)

Krav 111 Det skal være muligt, at en medarbejder hurtigt kan få et overblik over alle aktuelle risikovurderinger på et til bud og en afdeling. (KP)

Krav 112 Det skal være muligt at gøre medarbejdere opmærksom på ændringer i borgeres risikovurdering. (KP)



Krav 113 Det skal være tydeligt for medarbejdere, hvis der er handleanvisninger på en borger. (KP)

Krav 114 Det skal være muligt at dokumentere indsats og resultater på handleanvisninger. (KP)

Krav 115 Det skal fremgå hvilke medarbejdere, der har foretaget en risikovurdering. (KP)

Krav 116 Resultater og handleanvisninger fra risikovurdering skal kunne udveksles med tredjeparts programmel. (Status vedr. risikovurderinger vises på infoskærme). (KP)

Krav 117 Det skal være muligt at foretage risikovurderinger fra mobile enheder (Se krav vedr. mobile enheder i afsnit 4.17) (KP)

Krav 118 Det skal være muligt at se aktuelle risikovurderinger og handleanvisninger på mobile enheder (Se krav vedr. mobile enheder i afsnit 4.17) (KP)

Krav 119 Det skal være muligt at lave statistiske udtræk af risikovurderinger. (KP)

4.4 Opgavefordeling og planlægningKrav 120 Det skal være muligt at planlægge opgaver for medarbejdere. (MK)

Krav 121 Brugere skal kunne oprette opgaver til andre brugere. (KP)

Krav 122 Brugere skal kunne oprette opgaver til alle brugere på en afdeling. (KP)

Krav 123 Opgaver skal kunne knyttes til en borger, afdeling, team eller til alle. (KP)

Krav 124 Brugere skal kunne kvittere for udførsel af opgave. (KP)

Krav 125 Brugere skal let kunne se de opgaver, han/hun skal løse. (KP)

Krav 126 Brugere skal let kunne se status for opgaver. (KP)

Krav 127 Opgaver skal kunne planlægges med dato og klokkeslæt for igangsætning. (KP)

Krav 128 Opgaver skal kunne have udløbsdato og udløbstidspunkt. (KP)

Krav 129 Opgaver skal kunne gentages med fast interval. (KP)



Krav 130 Det skal være muligt at anvende opgave-funktionerne på mobile enheder (Se krav vedr. mobile enheder i afsnit 4.17) (KP)

4.5 Indberetninger vedr. borgere

INFO:

Socialområdets tilbud benytter forskellige indberetningsskemaer. Nogle er baseret i en lov, andre er oprettet centralt eller decentralt med henblik på at skabe et overblik (afkrydsningsskemaer) eller overvåge tendenser (indberetninger fra medarbejdere).

Krav 131 Brugeren skal kunne oprette egne skabeloner til registrering i Systemet. (MK)

Krav 132 Brugeren skal kunne benytte Word og Excel-skabeloner til registrering. (KP)

Krav 133 Systemet skal kunne understøtte Microsoft Office og LibreOffice som kontorpakke. (KP)

Krav 134 Brugeren skal kunne vælge at få eksisterende stamdata automatisk indsat i skabelon. (KP)

Krav 135 Data skal kunne genanvendes i andre dele af planarbejdet/dokumentationsarbejdet. (KP)



4.6 Indberetning af magtanvendelser

INFO:

Udfyldelse af et indberetningsskemaer vedr. magtanvendelse (herefter skema) kræver involvering af flere medarbejdere, som på skift skal bidrage til færdiggørelsen af skemaerne.

Medarbejdere i Region Midtjyllands centrale administration bidrager også til færdiggørelsen af skemaerne og disse medarbejdere arbejder med skemaer fra alle de sociale tilbud.

Skemaer sendes bl.a. til kommuner og tilsyn. Desuden er skemaerne grundlag for statistisk behandling af magtanvendelser på både tilbud og i Region Midtjyllands centrale administration.

Systemet skal understøtte denne arbejdsgang med fokus på følgende nedenstående krav.

Krav 136 Det skal være muligt at udfylde magtindberetninger efter Servicelovens kapitel 24 med tilknyttede bekendtgørelser i Systemet. (MK)

Krav 137 De autoritative tre gældende magtindberetningsskemaer (ifølge Serviceloven) skal altid være til rådighed i Systemet. (MK)

Krav 138 Det skal være muligt, at oprette Kundens egne skabeloner til magtindberetningsskemaer, hvori der kan hentes indhold fra allerede udfyldte felter i Systemet. (KP)

Krav 139 Det skal være muligt at behandle et skema i et flow, dvs. hvor flere medarbejdere på skift har mulighed for at udfylde og føje tekst til et skema. (KP)

Krav 140 Det skal være muligt for hvert skrift i et flow at angive, hvilke brugere som har rettighed til at redigere i det pågældende skema. (KP)

Krav 141 Det skal være muligt at sende et skema frem og tilbage i et flow uden begrænsninger i antal gange. (KP)

Krav 142 Det skal være muligt at variere et flow alt efter hvilket skema som er taget i brug. (KP)

Krav 143 Det skal være muligt at variere et flow alt efter tilbud. (KP)



Krav 144 Administrator skal kunne konfigurere flow. (KP)

Krav 145 Når et skema sendes frem eller tilbage i flow, skal modtagere adviseres. Medarbejdere skal selv kunne vælge hvorledes denne advisering skal foregå, hvis der findes flere muligheder. (KP)

Krav 146 Når et skema sendes frem eller tilbage i flow, skal der gemmes en version af skemaet, som nemt kan søges/læses og printes, men ikke redigeres. (KP)

Krav 147 Når et skema sendes frem eller tilbage i flow, skal det være muligt for afsender at medsende en information til modtager(e). (KP)

Krav 148 Det skal være muligt at få oprettet et dagsbogsnotat i borgerens dagbog på udvalgte steder i et flow. (KP)

Krav 149 Sidste rolle i ethvert flow skal have mulighed for at godkende eller afvise skemaet. (KP)

Krav 150 Når et skema godkendes eller afvises, skal det samtidigt journaliseres. (KP)

Krav 151 Det skal være tydeligt i Systemet, hvor et skema er i sit flow. (KP)

Krav 152 Det skal være let for alle medarbejdere at se, hvem der har sendt et skema frem og tilbage i flow. (KP)

Krav 153 Medarbejdere skal kunne tildeles roller, som betyder, at de kan redigere skemaer når de er bestemte steder i et flow. (KP)

Krav 154 Det skal være muligt, at flere medarbejdere har samme rolle. (KP)

Krav 155 Det skal være muligt, at en medarbejder kan have flere roller. (KP)

Krav 156 Logning og historik skal understøttes på samme vis, som beskrevet i Krav 19 om Logning af brugertransaktioner. (KP)

Krav 157 Et skema og alle versioner af det skal kunne printes. (KP)

Krav 158 Det skal være muligt at printe en anonymiseret version af et skema. (Fravalg af specifikke felter). (KP)

Krav 159 Det skal være muligt at oprette og printe kontekst-specifikke udskrifter. (KP)



4.7 Data og statistik ifm. indberetningerKrav 160 Systemet skal understøtte statistisk behandling af indberetninger. (MK)

Krav 161 Det skal være muligt at eksportere skemaernes indhold i et eller flere af følgende formater – csv, xls og xml. (KP)

Krav 162 Det skal være muligt at eksportere metadata sammen med skemaernes indhold, f.eks. skemaidentifikation, oprettelsesdato, status, log-informationer. (KP)

Krav 163 Dataeksport skal være tilgængeligt for medarbejdere på tilbud og i Region Midtjyllands central administration. (KP)

Krav 164 Det skal være muligt at lave statistik for medarbejdere på tilbud og i Region Midtjyllands centraladministration. (KP)

4.8 Intern kommunikationKrav 165 Systemet skal tilbyde en kommunikation internt i systemet, som ikke

kræver brug af kundens mailsystem. (MK)

Krav 166 Det skal være muligt for brugeren at kommunikere til specifik kollega/flere kolleger vha. intern kommunikation i Systemet. (KP)

Krav 167 Det skal være muligt for brugeren at lave tidsbegrænsning på en besked, således at den slettes efter et defineret tidsrum eller på et bestemt tidspunkt. (KP)

Krav 168 Det skal være muligt for brugeren at respondere til alle ifm. en advisering, som er sendt til flere. (KP)

Krav 169 Det skal være muligt at vælge, at adviseringen popper op (og dermed forventes lettere at se af modtagere). (KP)

Krav 170 Det skal være muligt på brugerniveau at fravælge ’pop up’ funktionen. Se krav ovenfor. (KP)

Krav 171 Det skal være muligt at knytte en automatisk advisering til en given modtager ved givne handlinger. (KP)

Krav 172 Det skal kunne være muligt for brugeren at vedhæfte filer til adviseringen. (KP)

Krav 173 Det skal være muligt, at læse og skrive intern kommunikation på mobile enheder (Se krav vedr. mobile enheder i afsnit 4.17) (KP)



Krav 174 Det skal være muligt at sende beskeder med fra adviseringsfunktionen som en mail. (KP)

Krav 175 Systemet skal indeholde en SMS-tjeneste, så det er muligt at foretage flere typer af adviseringer. (KP)

Krav 176 Det skal være muligt, at beskeder fra adviseringsfunktionen ligeledes sendes som en SMS. (KP)

Krav 177 Det skal være muligt for brugeren at kunne kommunikere med sine kolleger i et brugerforum. (KP)

Krav 178 Det skal være muligt at føje kommunikation fra et forum, til en borgers sag. (KP)

Krav 179 Det skal være muligt at definere, hvem der har adgang til det enkelte forum. (KP)

Krav 180 Det skal være muligt at definere levetiden på det enkelte forum. (KP)

Krav 181 Det skal være muligt at anvende fora-funktionerne på mobile enheder. (Se krav vedr. mobile enheder i afsnit 4.17) (KP)

4.9 KalenderfunktionKrav 182 Systemet skal indeholde kalender til hver Borger, Medarbejder og

Afdeling. (MK)

Krav 183 Det skal være muligt at bruge kalender til planlægning af opgaver, møder og daglige rutiner (herefter ”aftaler”). (KP)

Krav 184 Det skal være muligt at vise aftaler som visuel guidning. (KP)

Krav 185 Det skal være muligt at tildele Brugere læse- og skriverettigheder til borger- og afdelingskalendere og evt. til tilbudskalender. (KP)

Krav 186 Det skal være muligt at give forskellige aftaler en kode (farve eller ikon), således at de er let genkendelige i oversigter. (KP)

Krav 187 Det skal være muligt at lave planlægning af aftaler for flere kalendere på én gang. (KP)

Krav 188 Kalender skal kunne påminde om aftalestart. (KP)



Krav 189 Det skal være muligt at oprette påmindelser til både egen kalender og til andre kalendere og at kunne angive, hvornår påmindelsen skal være synlig. (KP)

Krav 190 Det skal være muligt at anvende kalendere på mobile enheder (Se krav vedr. mobile enheder i afsnit 4.17) (KP)

4.9.1 Integration med Exchange

Krav 191 Systemets kalendersystem skal synkroniseres med Region Midtjyllands kalendersystem, således at aftaler booket i enten Systemets kalender eller i Region Midtjyllands kalendersystem er synlige begge steder. Dette krav omfatter udelukkende kalendere for medarbejdere. Synkronisering skal til enhver tid ske i overensstemmelse med persondataloven. (option)

4.10 Medicinhåndtering

INFO:”Medicin.dk” i dette afsnit dækker over:

Dansk Lægemiddel Information A/S medicin database med tilhørende snitflader eller anden af Socialstyrelsen godkendt database.

Krav 192 Det skal være muligt for Superbruger, at foretage en oprettelse af et medicinpræparat. (MK)

Krav 193 Systemet skal indeholde en liste af præparater, som består af præparater fra Medicin.dk og præparater oprettet af Superbruger. (MK)

Krav 194 Det skal være muligt ved oprettelse af et præparat at angive præparatets Navn, Styrke, Substans, Dispenseringsformer og Aktive stoffer. (MK)


http://pro.medicin.dk/Generelt/Show/AboutDLI




Krav 195 Det skal være muligt at oprette ordinationer for borgere. En ordination skal som minimum indeholde: (MK) Præparat, Styrke Ordinationsdato Ordineret af (Typisk læge navn) Døgndosis Start dato (for udlevering) Seponeringsdato Dosisdispensering Om præparat udleveres til selvadministration Om præparat udleveres til selvindtag Om præparat er PN-medicin (pro necessare) Navn på medarbejder, som har oprettet ordination i systemet Navn på medarbejder som har godkendt oprettelsen. Mulighed for at skrive en bemærkning.

Krav 196 Det skal være muligt at en ordination først kan udleveres når en anden medarbejder, der opretter ordinationer, har godkendt oprettelsen. (MK)

Krav 197 Det skal være muligt at lave en medicinliste for fremtidige ordinationer og seponeringer for en borger. (MK)

Krav 198 Det skal være muligt at oprette en udleveringsplan for hver ordination. (MK)

Krav 199 En udleveringsplan skal angive tidspunkter (tt:mm) for udlevering pr. dag præparatet udleveres. (MK)

Krav 200 Det skal være muligt at planlægge udleveringer med mere end en dags interval. Beskriv mulighederne. (MK)

Krav 201 Udleveringsplaner skal kunne vises som en samlet plan for en afdeling. (MK)

Krav 202 Udleveringsplaner skal kunne vises som en samlet plan for et tilbud. (KP)

Krav 203 Det skal være muligt at se udleveringsplaner på mobile enheder (Se krav vedr. mobile enheder i afsnit 4.17) (KP)



4.10.1 Udlevering og dokumentation af udleveret medicin

Krav 204 Det skal være muligt for Brugeren at dokumentere udlevering af medicin i forhold til hvem, der har udleveret, hvad der er udleveret, hvornår det er udleveret samt mulighed for at tilføje egen kommentar vedr. daglig medicin. (MK)

Krav 205 Det skal være muligt for Brugere, at registrere om man har observeret at medicin blev indtaget. (KP)

Krav 206 Det skal være muligt for en bruger, at kunne gennemføre lovpligtig dokumentation af effekt ved udlevering af PN-medicin. (MK)

Krav 207 Det skal være muligt at foretage en angivelse af max dosis PN og herefter advarsel hvis max udlevering er nået. (KP)

Krav 208 Ifm. udlevering af medicin til borger, skal det være muligt at registrere udlevering af medicin pr. gang, for en dag eller for en længere tidshorisont. (KP)

Krav 209 Det skal være muligt at dokumentere udlevering af medicin fra mobile enheder (Se krav vedr. mobile enheder i afsnit 4.17) (KP)

INFO:

Medicinlisten er den samlede oversigt over ordinationer og udleveringsplaner for en borger.

Krav 210 Det skal være muligt at angive Cave og medicinopbevaring på medicinlisten. (MK)

Krav 211 Det aktive stof i præparater skal være på medicinlisten. (MK)

Krav 212 Det skal være muligt, at læse medicinlister på mobile enheder (Se krav vedr. mobile enheder i afsnit 4.17) (KP)

Krav 213 Det skal være muligt at sende en påmindelse om medicinering til brugere, hvis ikke medicinen er udleveret til rette tid. Dette gælder både daglig medicin og depotmedicin. (KP)

Krav 214 Det skal være muligt for brugeren at få adgang til relevante medicininstrukser i forbindelse med håndtering af medicin. (KP)

Krav 215 Det skal være muligt i Systemet at angive om en instruks er blevet læst af en bruger. (MK)



Krav 216 Det skal være muligt at tilgå instrukser fra mobile enheder (Se krav vedr. mobile enheder i afsnit 4.17) (KP)

Krav 217 Det skal være muligt for brugeren at tilknytte et skema til registrering af medicinrelaterede prøver til borgerens medicinliste. (eks. ang. blodtryk, vægt, blodsukker, temperatur og lignende). (KP)

Krav 218 Det skal være muligt at printe medicinlister inkl. evt. depotplaner – også for udleveringer frem i tiden. (MK)

Krav 219 Det skal være muligt for brugeren at kunne vælge at printe medicinkort ud i formater, som passer til medicinæsker. (KP)

Krav 220 Det skal være muligt at lave elektronisk medicinbestilling. (option)

4.10.2 Statistik over medicin og medicinbeholdning

Krav 221 Det skal være muligt at kunne danne statistiske udtræk af udleveret medicin. (KP)

Krav 222 Det skal være muligt at kunne danne statistiske udtræk over manglende udleveringer af medicin. (KP)

Krav 223 Det skal være muligt at foretage lagerstyring af medicinbeholdninger. (KP)

4.11 Beboerøkonomi

INFO:

Personalet på et tilbud hjælper med til at styre borgernes økonomi. Personalet registrerer økonomiske transaktioner (udgifter/ indtægter) på flere konti for at styre eksempelvist lommepenge.

Beboere på Voksentilbud betaler bl.a. husleje, el. og varme mens de bor på tilbuddet. Derudover betaler de nogle gange også for andre udgifter, f.eks. kost, vask osv.

Desuden håndteres betalinger fra borgerens bankkonti og disse betalinger skal dokumenteres.



Krav 224 Det skal være muligt for brugerne at kunne oprette samt føre regnskab med flere konti for en borger. (KP)

Krav 225 Transaktioner skal kunne godkendes af anden medarbejder (gælder for alle konti). (KP)

Krav 226 Det skal være muligt, at borgeren kan godkende transaktioner på udvalgte konti. (KP)

Krav 227 Det skal være muligt at kunne dokumentere formål med hver enkel transaktion. (KP)

Krav 228 Det skal være muligt at registrere transaktionsdato. Transaktionsdato er ikke nødvendigvist samme dato som registreringsdato. (KP)

Krav 229 Det skal være muligt at planlægge faste transaktioner. (KP)

Krav 230 Det skal være muligt at beregne husleje, el og varme for hver beboer. (Vejledning til beregning findes i underbilag C. (KP)

Krav 231 Det skal være muligt at lave en faktura til borgere. En faktura skal indeholde faste betalinger og brugeroprettede betalinger. (KP)

Krav 232 Det skal være muligt at overføre filer med beboerfaktura til kunden på fastlagte datoer, som udmeldes en gang om året. (KP)

Krav 233 Det skal være muligt at foretage en indberetning til SKAT om udbetalt løn til borgeren. (KP)

4.12 Adgang for eksterne parter

INFO:

Flere typer af personer kan have behov for adgang til informationerne i systemet. Heriblandt også personer, som ikke er ansat i den organisation, som systemet dækker. F.eks. pårørende, sagsbehandlere, psykologer og borgeren.

Krav 234 Systemet skal understøtte, at person, som ikke er ansat hos Kunden, kan få adgang til informationer i systemet. (MK)

Krav 235 Adgang til eksterne parter skal kunne oprettes af Administrator. (KP)



Krav 236 En adgang må kun gælde for informationer vedr. én borger. Har f.eks. pårørende to borgere på samme tilbud, skal de have to eksterne adgange. (KP)

Krav 237 En adgang skal kunne oprettes med en gyldighedsperiode. (KP)

Krav 238 Eksterne parters adgang skal logges på samme vis som Brugere. (KP)

Krav 239 Brugere skal kunne logge ind med Digital medarbejder signatur. (option)

Krav 240 Bruger med ekstern adgang skal kunne logge ind med NemID. (option)

4.12.1 Adgangsdifferentiering ved ekstern adgang

Krav 241 Der skal kunne adgangsdifferentieres for alle dokumentationstyper, hvorvidt de skal være tilgængelige for ekstern adgang. (MK)

Krav 242 Det skal være muligt at give adgang til at skrive i udvalgte områder af Systemet. (MK)

Krav 243 Det skal være muligt at give adgang til at foretage registreringer i udvalgte funktioner i Systemet. (MK)

Krav 244 Superbruger skal i Systemet kunne fremkalde et overblik over, hvilke borgere, pårørende og eksterne der har adgang til Systemet og hvilke borgere og tilbud disse har adgang til. (MK)

Krav 245 Superbruger skal i Systemet kunne fremkalde et overblik over hvilke rettigheder, der er knyttet til en ekstern adgang. (MK)

Krav 246 En ekstern adgang skal deaktiveres automatisk i forbindelse med at borgeren udskrives fra tilbuddet eller når gyldighedsperiode ikke længere er gældende. (MK)

4.12.2 Nyhedsfunktion

Krav 247 Systemet skal indeholde en nyhedsfunktion for eksterne, hvor borgere, pårørende mv. kan abonnere på udvalgte nyheder, efter tilbuddets valg og med muligheder for adgangsdifferentiering. (KP)



4.13 SagsbehandlingKrav 248 Systemet skal kunne understøtte udveksling af sagsdokumenter til

eksterne ESDH-systemer. (KP)

Krav 249 Dokumenter skal kunne journaliseres. (KP)

Krav 250 Journaliserede dokumenter må ikke kunne redigeres eller slettes. (KP)

Krav 251 Ved journalisering skal materialet låses for videre redigering. (KP)

Krav 252 Det skal være muligt at flytte en sag mellem de forskellige organisatoriske niveauer og enheder inden for Systemet. Dvs. både mellem afdelingerne i et Specialområde og mellem Specialområder, såfremt en borger flytter. (KP)

Krav 253 Det skal være muligt at kopiere sagsmaterialet fra specialområdet til kommunen ved udskrivning, når borgeren overgår til et kommunalt tilbud. (KP)

Krav 254 Det skal være muligt at kopiere sagsmateriale fra kommune til specialområde i forbindelse med visitation og evt. senere indskrivning. (KP)

Krav 255 Ved eksport af data skal det være muligt at udvælge det sagsmateriale, der skal eksporteres. (KP)

Krav 256 Systemet skal indeholde en funktion til journalisering af e-mails fra Outlook med det formål at dokumentere kommunikation. (KP)

Krav 257 Administrator skal kunne vælge hvilke brugere, der kan journalisere e-mails fra Outlook. (KP)

4.14 Dokumenthåndtering Krav 258 Systemet skal kunne håndtere fil- og mappestruktur for borgere,

medarbejdere og afdelinger. (KP)

Krav 259 Der skal kunne tildeles rettigheder (læse- og skriverettigheder) på mappeniveau. (KP)

Krav 260 Der skal kunne tildeles brugerrettigheder (læse- og skriverettigheder) på filniveau. (KP)



Krav 261 Brugeren skal kunne advisere sine kolleger, via systemets adviseringsfunktion eller ved hjælp af mail notifikation om relevant materiale med direkte henvisning/link til materialet. (KP)

Krav 262 Systemet skal kunne åbne, importere og eksportere alle filformater, der bruges i standard kontorpakker, samt pdf, grafikformater, videoformater og lydformater. Kundens skal selv sørge for at software til at åbne filformaterne er til stede. (KP)

Krav 263 Bruger skal kunne redigere Microsoft Office dokumenter og LibreOffice dokumenter direkte i systemet. (KP)

Krav 264 Det skal være muligt at håndtere filer via standardbrowsere eller plugin med funktioner, som forventes af et nutidigt filhåndteringssystem. (f.eks. flytning af filer, valg af flere filer, gendanne filer m.v.) (KP)

Krav 265 Kunden skal kunne oprette Microsoft Office og LibreOffice dokumenter ud fra egne skabeloner. (KP)

Krav 266 Informationer fra systemet skal kunne indarbejdes i dokumenter, som er oprettes fra Systemet. (KP)

4.15 Statistikgenerering og databehandlingKrav 267 Det skal være muligt for at generere statistik på baggrund af

oplysningerne i Systemet. (MK)

Krav 268 Statistikker skal kunne gemmes så de kan afvikles af alle brugere med adgang til statistik. (KP)

Krav 269 Brugere skal kunne lave og afvikle statistik på data fra områder, de har rettighed/adgang til i systemet. (KP)

Krav 270 Det skal være muligt, at lave krydstabuleringer. (KP)

Krav 271 Det skal være muligt at trække statistik på tværs af den organisatoriske opbygning. (KP)

Krav 272 Det skal være muligt at trække statistik på besvarelser af (ens) skemaer, så det derved er muligt at vise progression. (KP)

Krav 273 Statistikresultater skal kunne eksporteres til videre behandling i Microsoft Office og LibreOffice. (KP)

Krav 274 Felter skal kunne eksporteres i samme format som i Systemet, dvs. tal eksporteres som talformat, datoer som datoformat osv. (KP)



4.15.1 Rapportgenerator

Krav 275 Det skal være muligt at lave rapporter, som kan vise data i Systemet. (KP)

Krav 276 Ved opbygning af rapporter skal det være muligt at vælge fra alle data i systemet. (KP)

Krav 277 Rapport skal kunne gemmes så de kan afvikles af alle Brugere med adgang til rapporter. (KP)

Krav 278 Opbygning af rapporter skal være brugervenligt og enkelt. (KP)

Krav 279 Det skal være muligt at lave en kort beskrivelse af en rapport, som vises når Brugere skal vælge rapporter. (KP)

Krav 280 Rapporter skal kunne eksporteres til videre behandling i Microsoft Office og LibreOffice. (KP)

4.16 Generelt vedr. SystemetKrav 281 Der skal være stavekontrol, der følger de standardiserede

retningslinjer for den danske grammatik. (KP)

Krav 282 Ved indtastning og redigering i tekstfelter skal det være muligt at benytte tekstbehandlingsfunktioner, som ændring af skrifttype, størrelse og farve, punktopstilling, indrykning mv. (KP)

Krav 283 Det skal være muligt at tilbyde autoudfyldelse af alle felter, hvor der er mulighed for det ved opslag i Systemet eller gennem snitflader til andre Systemer. (KP)

Krav 284 Data skal kunne indtastes én gang i systemet og derefter kunne genbruges i alle områder af systemets. (KP)

Krav 285 Brugeren skal kunne søge i data (felter) og i fri tekst, indtastet i Systemet. (KP)

Krav 286 Det skal være muligt at søge på tværs af den organisatoriske opbygning. (KP)



Krav 287 Det er et krav, at Systemet tilstræber at tilbyde brugeren oprettelse af egne definerede genvejstaster, eller som minimum brug af standardgenvejstaster, således det er muligt at komme direkte til målet for navigationen, ved hjælp af genvejstaster. (KP)

Krav 288 Det er et krav, at der i navigationen i Systemet findes alternativer, til brug af mus. (KP)

Krav 289 Systemet skal indeholde en kontekstafhængig hjælpefunktion. (KP)

Krav 290 Det er et krav, at Systemet kan guide brugeren ved brug af forklarende tekst enten i form af: (KP)

konkrete og letforståelige fejlmeddelelser, hjælpetekster (der forståeligt og handlingsanvisende påpeger,

hvad brugeren bør gøre/indtaste) eller ved brug af ”mouse-over-tekst”.

Krav 291 Bruger skal kunne printe alle oprettede rapporter og skabeloner og skemaer. (KP)

Krav 292 Printfunktionen skal indeholde en print preview funktion. (KP)

Krav 293 Print skal kunne foretages til PDF-filer.(KP)

Krav 294 Det skal være muligt at arkivere oplysninger, som ikke længere skal anvendes i arbejdet med borgeren, i Systemet.

Krav 295 Arkiverede oplysninger skal kunne findes af Brugere, men skal ikke være en del af det generelle informationsbillede til Brugeren. (KP)

4.17 Systemet på mobile enheder

INFO:

Det vil blive vurderet positivt, hvis Systemet helt eller delvist kan afvikles på mobile enheder. Mobile enheder er i denne sammenhæng Tablets og smartphones.

Det er angivet i de enkelte afsnit hvilke dele af systemet, som Kunden betragter som specielt vigtige at kunne afvikle på mobile enheder.



Krav 296 Apps skal som minimum findes til Android og IOS – gerne andre i tillæg. (KP)

Krav 297 Apps skal opleves som native på den platform de afvikles på (std. GUI og arbejdsgange). (KP)

Krav 298 Der må ikke forbruges urimelige ressourcer som fx batteri og RAM på mobile enheder. (KP)

Krav 299 Der skal være sikring af data både under transport og lagring med effektiv kryptering. (KP)

Krav 300 Der skal være brugerstyring mod central brugerbase, jf. kontraktbilag 3.2.6 (KP)

Krav 301 Der skal være logning på både læsning og skrivning af data jf. persondataloven. (KP)

Krav 302 Afvikling på mobile enheder skal kunne fungere fejlfrit ved manglende eller svingende dataforbindelse, så fx registrering af data kan foregå og bliver synkroniseret transparent ved forbindelse uden deltagelse af bruger. (KP)


BILAG 5 – KUNDENS IT-MILJØ

Bilag 5. Kundens IT-miljø


INFO:Netværksforbindelser til de sociale tilbudI Region MIDT er standard net-forbindelsen til institutioner:En fiber-kablet 100/100Mbit Ethernet tilslutning til RM's lukkede MPLS-net (to enheder har dog kun en 10/10Mbit forbindelse).Der er dog nogle adresser, som ikke har RM-netværk - men "kun" har en 10/1 Mbit ADSL Intenet forbindelse og/eller er afhængig af en Mobil-løsning via 3G-mobilnet.

Krav 303 Systemet skal kunne anvendes inden for rammerne af Kundens IT-miljø (se nærmere Underbilag I). (MK)

5.1 Snitflader

Vejledning til Tilbudsgiver: Priser anføres i Kontraktbilag 6.

Krav 304 Leverandøren skal angive vilkår og priser for implementering af snitflade til Unge Sikrede (se nærmere Underbilag E) (MK)

Unge Sikrede (kun på sikrede institutioner)

Ind- og udskrivningsdata leveres til CGI. CGI leverer data videre til CFK ved FTP.Data til valgmuligheder i Bosted hentes fra CGI.Format: Webservice (Bilag)Dataretning: Tovejs.Data skal anvendes til statistik vedr. sikrede institutioner.



Krav 305 Leverandøren skal tilbyde at implementere snitflader med henblik på at etablere eksport af data fra Systemet til de anførte systemer. (KP) Snitfladerne er:

BI Overførsel af data til RM BI enhed.Social Indikator projekt (SIP)Se nærmere Underbilag F

Data leveres til CGI. CGI leverere data videre til CFK ved FTP.Rapporter udarbejdes af CFK og placeres i Bosted.Format: Ukendt. (Er i gang med at finde mere info.)Dataretning: Tovejs.

ØS-indsigt/ beboerfakturaSe nærmere Underbilag C og D.

Beboerfaktura leveres til RM/PS Administrationen.Format: Tekstfiler. Format EGDEB01 (Bilag)Dataretning: Envejs.Faktura indlæses af økonomiarbejder i ØS Indsigt.

Promedicin.dk Oplysninger om medicinpræperater overføres til Bosted.Format: UkendtDataretning: Envejs.

Medcom Mulighed for at kommunikere vha. Medcom standarder.

CPR-registret Mulighed for at trække oplysninger om borgeren fra CPR-register til Systemet.

Statens Arkiver Overførsel af data til Statens arkiver.Fælles Medicinkort (FMK)

Integration til FMK ønskes i fremtiden.I modsætning til EPJ, så skal der IKKE kunne ændres i FMK fra det socialfaglige system. Der skal udelukkende overføres data fra FMK.

Klinisk logistik Integration til Klinisk Logistik ønskes i fremtiden.



Figur over snitflader til Systemet:



5.1.1 Snitflader – ajourføring

Krav 306 Leverandøren skal i en beskrivelse af sin generelle politik mht. redegøre for, hvorledes Kundens sikres adgang til data, herunder på hvilke betingelser adgangen kan sikres, hvordan der gives adgang, og hvilke standarder der benyttes til dataudvekslingen. Leverandøren skal endvidere redegøre for status på udviklingen af OIOXML-baserede snitflader. (MK)

Krav 307 Vedr. web-services bedes Leverandøren fremkomme med konkrete eksempler eller planer for indførelse af web-services til erstatning af nuværende snitflader eller manuelle arbejdsgange ved anvendelse af Systemet. (KP)

5.1.2 Udbredt klientteknologi

Krav 308 Systemet skal kunne afvikles inden for rammerne af Kundens IT-miljø og må ikke forudsætte brugen af en specifik hardwareleverandørs produkter”. (MK)

5.1.3 Mobile enheder

Krav 309 Systemet skal være tilgængeligt fra gængse operativsystemer, som minimum Microsoft Windows XP og 7. (MK)

Krav 310 For et system der udelukkende er WEB-baseret, skal dette være tilgængeligt fra – og kompatibelt med, Internet Explorer, Google Chrome og Mozilla Firefox. Systemet skal fleksibelt og progressivt tilpasse sig udviklingen af browsere, med hensyn til tidligere browserversioner. Ibrugtagede funktioner i Systemet bør således også kunne tilgås i en tidligere version af browserne i 2 år. (MK)

Krav 311 For WEB-baserede systemer, der benytter sig af 3. parts software/programmer, som eksemplvis Java, skal kompatibiliteten sikres gennem aftale med RM IT afdelingen, således der er en funktionel sammenhæng mellem systemet og kundens IT miljø. (MK)



5.2 Nuværende løsninger, mængder og dimensionering

INFO:

Kunden anvender pt.:

Bosted-systemet fra Team Online på 28 tilbud – ca. 3000 brugere. Systemets data udgør ca. 49 Gb og kan stilles til rådighed i XML-format og/ eller MySQL. Hertil kommer de enkelte tilbuds egne tilknyttede dokumenter, som udgør ca. 106 GB.


BILAG 6 – VEDERLAG OG BETALINGSPLAN

Bilag 6. Vederlag og betalingsplan

6.1 GenereltVederlag opgøres som anført neden for under punkt 6.2 – 6.5. Samtlige Kontraktens vederlag skal således angives neden for. Dog angives vederlag for optioner i Kontraktbilag 16.

Såfremt en ydelse tilbydes omkostningsfrit eller inkluderet i en anden ydelse, anføres dette med tallet nul (0). Manglende angivelse af en pris anses som værende et forbehold for et grundlæggende element, og tilbuddet betragtes således som ukonditionsmæssigt.

For de overordnede bestemmelser om behandling af Kontraktens vederlag henvises til Kontraktens punkt 12 (priser) og 13 (betalingsbetingelser).



6.2 Kontraktvederlag

Ydelser Pris Forudsætninger/forbehold

Vederlag for gennemførelse af afklaringsfasenVederlag for gennemførelse af etableringsfasenIntroduktion til det kommende system – demonstration på områdeledermødeDeltagelse i diverse projektgrupperProjektledelseKonvertering af dataMigration af dataIntegration til andre systemerUddannelse - SuperbrugereOpfølgning - ibrugtagning af SystemetAssistance ved konfiguration og opsætningProjektstyring og kvalitetssikringØvrige ydelserI alt



6.3 Brugsvederlag og brugerlicenser

Ydelser PrisÅrligt brugsvederlagBrugsvederlaget dækker alle faste driftsydelser, der nødvendige for at stille ydelsen løbende til rådighed – uanset antallet af brugere.

Ydelser PrisÅrligt vederlag for brugerlicenser pr. intern brugerÅrligt vederlag for brugerlicenser pr. ekstern brugerVederlaget for brugerlicenser dækker alle omkostninger, der er variable i forhold til brugerantallet.

6.4 Optioner

Ydelser PrisIntegration til Kundens mailsystemElektronisk medicinbestillingLog-in ved brug af digital medarbejder signaturLog-in ved brug af NemIdIntegration med fagsystemer:

- BI- Social Indicator Projekt (SIP)- ØS-indsigt/beboerfaktura- Promedicin.dk- Medcom- CPR-registret- Statens Arkiver- Fælles Medicinkort (FMK)- Klinisk Logistik

I alt

Angiv pris pr. system:

Brugeruddannelse



6.5 Vederlag for udtrædelse og exitfee

Ydelser PrisVederlag for udtrædelse, jf. Kontraktens pkt. 8.4Exitfee ved udtræden inden for de første 24 måneder, jf. Kontraktens pkt. 23.2I alt

6.6 Timepriser

Medarbejderkategori TimeprisKonsulentProjektlederProduktspecialist



6.7 Betalingsplan og betalingsforholdKontraktvederlaget, jf. punkt 6.2, betales i henhold til betalingsplanen:

Milepæl Betaling (%)

Afsluttet afklaringsfase 5 %Afsluttet etableringsfase 20 %Godkendt overtagelsesprøve 40 %Godkendt driftsprøve 35 %

Leverandøren kan i sit tilbud foretage ændringer i ovenstående betalingsplan, men det er et krav, at betalingen for henholdsvis godkendt driftsprøve og godkendt overtagelsesprøve udgør mindst 25 % hver for sig.

Fakturering af det årlige brugsvederlag, jf. punkt 6.3, kan først finde sted fra overtagelsesdagen. Endvidere er Leverandøren maksimalt berettiget til at fakturere det årlige brugsvederlag 12 måneder forud.

Interne og eksterne brugerlicenser betales månedligt fra overtagelsesdagen på baggrund af Leverandørens opgørelse over antallet af interne og eksterne brugere. Opgørelsen sendes ved fakturering til Kunden.


BILAG 7 - BESKRIVELSE AF DRIFTSMILJØ OG SYSTEMET

Bilag 7. Beskrivelse af Driftsmiljø og Systemet

7.1 Beskrivelse af Driftsmiljø og Systemet

SystemdokumentationLeverandøren skal levere og løbende opdatere en:

Komplet drifts- og systemdokumentation, som beskriver alle driftsmæssige foranstaltninger som Kunden skal iagttage.

Endvidere skal foreligge vejledning, som beskriver forskellige fejlsituationer samt, hvordan disse identificeres og afhjælpes.

Og dokumentationen for systemets grænseflader til Kundens relevante enheder, så som net, PC’er, printere, scannere.

Vederlag for denne dokumentation er omfattet af det årlige brugsvederlag anført i Kontraktbilag 6.

7.2 Leverandørens beskrivelse af SystemetLeverandøren indsætter sin beskrivelse af Systemet.Krav til Kundens it-miljø skal tillige angives i dette bilag. Endvidere skal Leverandøren beskrive dokumentation (dansk brugervejledning, system- og driftsdokumentation) til løsningen, herunder dokumentation rettet mod

Systemadministratorer Superbrugere Brugere

Undervisning/dem systema) Kunden skal have adgang til eget undervisningssystem.b) Undervisningssystem skal holdes opdateret, så det altid svarer

til driftssystem.


BILAG 8 - BESKRIVELSE AF TILKNYTTEDE YDELSER

Bilag 8. Beskrivelser af tilknyttede ydelser


8.1 Tilknyttede ydelser Bilaget skal indeholde en specifikation af tilknyttede ydelser i form af implementerings-, konverterings-, undervisnings- og øvrige konsulentydelser i inden idriftsættelse, omfattet af kontrakten. Det forudsættes – med mindre andet er angivet – at de i dette bilag angivne ydelser er omfattet af de i Kontraktbilag 6 specificerede faste vederlag forbundet med afklarings- og etableringsfasen samt den efterfølgende drift af systemet.

Krav 312 Krav til implementeringsydelser i etableringsfasen (KP)Systemet skal kunne ibrugtages i henhold til Kontraktbilag 1, Tidsplan.Tidsplanen skal som minimum indeholde de nedenstående implementeringsydelser:

a) Introduktion til det kommende system – demonstration på områdeledermøde

b) Deltagelse i diverse projektgrupper mv.c) Projektledelse d) Konvertering af datae) Migration af dataf) Integration til andre systemerg) Opfølgning – ibrugtagning af systemerne

Det forudsættes, at priserne for disse ydelser er omfattet af pris for etableringsfasen i Kontraktbilag 6.

Krav 313 Assistance ved konfiguration og opsætning (KP)Leverandøren skal stille nødvendig ekspertise til rådighed i forbindelse med en praksisnær konfiguration og opsætning af Systemet i forhold til de enkelte socialfaglige tilbud. Der skal afsættes én dag pr. socialfagligt tilbud til afklaring og rådgivning i forbindelse hermed.Det forudsættes, at priserne for disse ydelser er omfattet af pris for etableringsfasen i Kontraktbilag 6.


BILAG 8 - BESKRIVELSE AF TILKNYTTEDE YDELSER

Krav 314 Uddannelse – superbrugere (KP)a) Kunden ønsker tilbud på en superbrugeruddannelse gennemført

i Kundens lokaler. Kunden vil som udgangspunkt selv stå for uddannelse af slutbrugerne. Her tages udgangspunkt i 100 superbrugere.

b) Undervisningen skal foregå i testmiljøet på egne data, dvs. efter foretaget konvertering

c) Kundens efterfølgende anvendelse af Leverandørens uddannelsesmateriale skal være inkluderet i prisen herfor.

d) Såfremt den ovennævnte opsætning af Systemet i forhold til de enkelte socialfaglige tilbud integreres i uddannelsesforløbet for superbrugere, skal dette beskrives.

Det forudsættes, at priserne for disse ydelser er omfattet af pris for etableringsfasen i Kontraktbilag 6.

Krav 315 Projektstyring og kvalitetsikring (KP)Leverandøren skal beskrive metoder for projektstyring og kvalitetssikring og disses anvendelse i projektforløbet skal tillige beskrives.Det forudsættes, at priserne for disse ydelser er omfattet af pris for etableringsfasen i Kontraktbilag 6.

Krav 316 Øvrige ydelser (KP)Såfremt Leverandøren tilbyder øvrige ydelser, bedes disse beskrevet og prissat. Ydelser, der ikke er efterspurgt under nærværende udbud, kan alene indkøbes af Ordregiver i henhold til den til enhver tid gældende udbudslovgivning.


BILAG 9 – KUNDENS DELTAGELSE

Bilag 9. Kundens deltagelse

9.1 Generelt om kundens deltagelseUanset Leverandøren er ansvarlig for gennemførelsen af en aktivitet, er det en forudsætning for gennemførelsen, at Kunden medvirker aktivt dertil. Kunden skal i den forbindelse sørge for, at de nødvendige ressourcer med den aftalte kompetence samt de fysiske forhold beskrevet nedenfor vil være til rådighed og opfyldt i forbindelse med kontraktens gennemførelse.Kunden deltager i styregruppens møder og dertil knyttede aktiviteter, jf. Kontraktbilag 14.

9.2 Kundens projektleder og andre centrale personerLeverandøren skal udfylde skemaet med sine forudsætninger omkring Kundens projektleders deltagelse i henholdsvis implementerings- og driftsfase. Ligeledes anfører Leverandøren sine forudsætninger om eventuelt øvrige medarbejderes deltagelse i implementerings og driftsfasen. Personprofil/ kompetence

Estimeret antal personer

Periode Deltagelse i % af normal arbejdstid

Kundens projektleder

1 Implementeringsfase

1 Driftsfase[…øvrige, udfyldes…]

[…] Implementeringsfase

[…]

[…øvrige, udfyldes…]

[…] Driftsfase […]


BILAG 9 – KUNDENS DELTAGELSE

9.3 Oversigt over ressourcekrævende aktiviteterLeverandøren anfører tillige om sine forudsætninger om eventuel deltagelse af øvrigt personale i implementering og drift:

Aktivitet Personprofil/antal

Estimeret ressourceforbrug i dage pr. person

Tidsangivelse

Bemærkning

AfklaringsfaseParameteropsætningMedvirken ved udvikling af tilretninger, specialudviklinger og lignendeUddannelseKonvertering af dataAfprøvning i testmiljøLevering af data til overtagelsesprøveOvertagelsesprøveDriftsprøve


BILAG 10 - SPECIFIKATION AF DRIFTS-, SUPPORT-, VEDLIGEHOLDELSES- OG VIDEREUDVIKLINGSYDELSER

Bilag 10. Specifikation af drifts-, support-, vedligeholdelses- og videreudviklingsydelser


10.1 Driftsmiljø og -ydelser

Sikkerhedskopiering Samtlige data skal sikkerhedskopieres af Leverandøren en gang i døgnet, og opbevares i 30 dage inden overskrivning.

Krav 317 Leverandøren skal i en beskrivelse opstille bud på løsninger til at minimere datatab ved evt. nedbrud. (KP)

Krav 318 Leverandøren skal i en beskrivelse redegøre for Systemets muligheder for offline drift hos Kunden ved system eller kommunikationsnedbrud.Det vægtes positivt, hvis leverandøren beskriver en løsning herpå. (KP)

Beredskab og katastrofehåndtering

Krav 319 Leverandøren skal i en beskrivelse redegøre for etablering af faciliteter og beredskab i sit Driftsmiljø med henblik på at imødegå og minimere effekter ved force majeure (KP).

10.2 Vedligeholdelse, support, videreudvikling

Løbende ajourføring og vedligeholdelse Systemet skal løbende ajourføres og vedligeholdes af Leverandøren, så det kan driftsafvikles i overensstemmelse med Kontraktens bestemmelser i hele kontraktperioden, inkl. eventuel forlængelse.

Fremtidssikring, sikkerhedsforholdSåfremt der i dansk lovgivning, nationale fælles systemer eller arkitekturer fastsættes nye normer eller standarder for informationssikkerhed, herunder adgangskontrol, logning og dataopbevaring, skal implementering heraf i systemet ske med et skriftligt varsel på minimum 3 måneder og uden yderligere udgift for Kunden end det årlige brugsvederlag.



FejlafhjælpningLeverandøren skal udføre fejlafhjælpning på baggrund af fejlmeldinger modtaget via Service Desk eller meldinger fra overvågningssystemer – reaktionstid skal være i overensstemmelse med de aftalte servicemål. Fejlrettelser skal lægges løbende ind i overensstemmelse med aftalte servicemål.

Nye versioner og releasesNye versioner og nye releases af Systemet eller komponenter heri inkl. udgifter til installation skal være inkluderet i det faste årlige brugsvederlag i Kontraktbilag 6.Opgradering til nye udgaver af systemet må ikke fjerne/forstyrre udførte tilpasningers funktionalitet eller på anden måde forringe funktionaliteten.Superbrugere skal informeres om indholdet af nye releases, som indeholder nye og ændrede funktionaliteter, mindst 10 Arbejdsdage dage før release. Undtaget herfra er releases, som udelukkende gennemføres for at rette fejl i systemet.

Service Desk – kontaktpunkt til Kundens superbrugereLeverandøren skal stille en Service Desk-funktion til rådighed for Kundens superbrugere. Denne skal være brugernes centrale kontaktpunkt (Single Point of Contact) i forbindelse med spørgsmål om fejl, utilgængelighed og brugsmæssige problemer. Service Desk skal varetage følgende funktioner:

Registrering af alle henvendelser fra superbrugere. Førstehånds support til superbrugerne, besvarelse af korte

præcise spørgsmål (telefonisk eller via e-mail) vedrørende anvendelse af Systemet.

Problemdiagnosticering med henblik på at afgøre om et konstateret forhold beror på fejl og mangler i Systemet eller Driftsmiljøet.

Opfølgning og eskalering af ikke løste hændelser videre hos Leverandøren.

Information til superbrugere om status, problemløsning og løsningstidspunkt samt ændringer heri.

Opfølgning på problemløsning og sikring af superbrugerens accept af at afsluttede sager er løst til superbrugerens tilfredshed.

Service Åbningstid og tilgængelighedLeverandøren skal som minimum bemande Service Desk indenfor Kundens almindelige åbningstid, fra 8.00 – 16.00, mandag-fredag. Service Desk skal være tilgængelig via telefon og mail i ubegrænset omfang for Kunden.



Uden for dette tidsrum skal Service Desk kunne modtage henvendelser via mail. For henvendelser om forhold, der har betydning for servicemål, skal reaktion foretages i overensstemmelse hermed. Øvrige henvendelser besvares ved næstkommende Arbejdsdags start.

Kategorisering ved henvendelser om fejlHenvendelser om fejl kategoriseres af parterne i fællesskab i henhold til kontraktbilag 13.Hvis brugeren melder et forhold som værende en fejl eller mangel, og viser det sig efterfølgende, at meldingen er fejlagtig – at den beror på manglende uddannelse, forkert brug eller lignende, som ikke kan tilregnes Leverandørens forhold, er Leverandøren berettiget til kræve supportvederlag for behandling af Kundens henvendelse i overensstemmelse med det i Kontraktbilag 6 anførte om timebetaling. Retten til vederlag indtræder dog først fra det tidspunkt, hvor Leverandøren gør Kunden opmærksom på, at forholdet ikke er omfattet af Leverandørens vedligeholdelsesforpligtelser, og da under forudsætning af, at Kunden accepterer at Leverandøren fortsætter arbejdet.Såfremt der er uenighed om kategoriseringen, kan hver af parterne henvise kategoriseringen til Kundens og Leverandørens projektleder, der da sammen afgør dette spørgsmål. Kan der ikke opnås enighed mellem parternes projektledere, skal tvisten håndteres i henhold til Kontraktens bestemmelser herom.Indtil afgørelse foreligger skal Leverandøren afhjælpe problemet i forhold til Kundens kategorisering. Viser det sig efterfølgende gennem fælles erkendelse eller den sagkyndiges afgørelse, at manglen burde have været kategoriseret som anført af Leverandøren, kan Leverandøren kræve dokumenterede meromkostninger som følge af Kundens fejlagtige kategorisering, dækket af Kunden.

Alle udgifter til Leverandørens varetagelse af vedligeholdelse i overensstemmelse med de ovenstående krav skal være inkluderet i det faste årlige brugsvederlag i Kontraktbilag 6.

10.3 Beskrivelse af vedligeholdelse

Krav 320 Leverandøren skal beskrive Systemets vedligeholdelse i forhold til de ovenstående krav i afsnit 10.2 og sin besvarelse af disse i Underbilag A – Kravliste. (KP)

Krav 321 Leverandøren skal endvidere beskrive sin supportorganisation, procedure for fejlhåndtering, eskalation mv. (KP)



10.4 Videreudvikling

Krav 322 Leverandøren skal vedlægge roadmap for videreudvikling af Systemet (MK).

Krav 323 Ved vurderingen af Leverandørens roadmap (Krav 322), vægtes det positivt: (KP) At videreudviklingen af Systemet er klart og tydeligt beskrevet At videreudviklingen af Systemet er planlagt for en længere

periode (mere end 6 måneder) At videreudviklingen af Systemet tager højde for den øgede brug af

mobile enheder (tablets og smartphones) som arbejdsredskab

Krav 324 Leverandøren skal sikre Kundens muligheder for at påvirke videreudviklingen af Systemet. I en redegørelse af samme skal Leverandør således beskrive både hvilke muligheder Kunden har for at påvirke videreudviklingen af Systemet samt hvorledes muligheder for at udvikle og videreudvikle på kundespecifikke funktionaliteter (det vil sige funktionaliteter, der kun er anvendelige for Kunden) kan understøttes. Ved vurderingen lægges der vægt på hhv. graden af indflydelse for Kunden til at påvirke videreudviklingen samt omfanget heraf. Endvidere vægtes det positivt, såfremt Leverandøren giver mulighed for kundespecifik udvikling. (KP)


BILAG 11 - PRØVER

Bilag 11. Prøver


OvertagelsesprøveOvertagelsesprøve for en levering gennemføres af Kunde og Leverandør i samarbejde. Overtagelsesprøven gennemføres på Leverandørens maskinel til driftsafvikling og i øvrigt efter nærmere aftale. Kunden leverer en overordnet teststrategi, mens Leverandører leverer testplaner inkluderende test-cases til overtagelsesprøven. Leverandøren udarbejder en procedure, der sikrer at overtagelsesprøven omfatter en enkeltvis og integreret kontrol af kontraktens systemleverancer. Således skal proceduren sikre, at kravene, der kan stilles i henhold til kontrakten og dens bilag, er opfyldt. Overtagelsesprøven skal indeholde en afprøvning af svartidskrav.Overtagelsesprøverne er godkendt, når der er konstateret overensstemmelse mellem det i kontrakten specificerede og det leverede. Heri indgår også kontrol og accept af specificerede ændringer og tilretninger.Såfremt Kunden godkender overtagelsesprøven med konstaterede mangler, skal disse anføres i en mangelliste, der godkendes af Kunden. Overtagelsesprøven kan i sådanne tilfælde først betragtes som accepteret, når mangellisten er godkendt. Kunden er først forpligtet til at godkende driftsprøven, når de anførte mangler i det væsentligste er afhjulpet, og Kunden er givet rimelig tid til at konstatere, at manglerne er afhjulpet.

DriftsprøveAfholdelse af driftsprøve skal sikre, at løsningen opfylder de i Kontraktbilag 13 anførte servicemål, for så vidt angår svartidskrav og driftseffektivitet. Godkendt driftsprøve forudsætter, at de anførte servicemål er opfyldt i en periode på 30 sammenhængende kalenderdage.Leverandøren skal foreslå procedurer for afholdelse af driftsprøver, herunder etablering af et dimensioneringsgrundlag, der kan danne en realistisk ramme omkring både svartids- og oppetidsmålinger.


BILAG 11 - PRØVER

Løbende afprøvning af servicemåls overholdelse i Kontraktens varighed

Servicemåls overholdelse måles løbende i Kontraktens varighed, jf. Kontraktbilag 13 om Servicemål.

11.1 Om afprøvning

Krav 325 Leverandøren skal beskrive sine metoder og procedurer for overtagelsesprøven, driftsprøven og løbende afprøvning af servicemåls overholdelse. Beskrivelserne skal fungere som uddybning af dette Kontraktbilag 11.Ved overtagelsesprøven skal Leverandør forholde sig til de to use-cases – hhv. Underbilag G og Underbilag H. (KP)


BILAG 12 - LICENSBETINGELSER

Bilag 12. Licensbetingelser

Tilbudsgiver skal ved udfyldelse af dette bilag være særlig opmærksom på kontraktens bestemmelser om licens og brugsrettigheder – særligt Kontraktens punkt 21 – Rettigheder til programmel og dokumentation.

12.1 Leverandøren anfører eventuelle relevante licensbetingelser


BILAG 13 - SERVICEMÅL

Bilag 13. Servicemål


13.1 Fejl og fejltid

Aftalt driftstidDen aftalte driftstid for Systemet er defineret til at være 24 timer, alle kalenderdage i året.

Definition af fejl og fejltid Ved fejl forstås en hændelse, hvor en komponent eller data i Systemet ikke er tilgængelig for brugere med de egenskaber, som med rette kan forventes af Systemet.Ovenstående gælder også hændelser forårsaget af Leverandørens overvågningssystemer.For så vidt angår hændelser, der fører til utilgængelighed, indgår Prioritet 1 og 2-fejl, jf. afsnit 13.3.

FejltidAlle tidsforløb med fejl måles i timer og minutter. Fejltid fastsættes ud fra Leverandørens registrering foretaget ved hjælp af overvågningsrutiner, eller via logfiler eller brugerhenvendelser. Reetablering af data/system regnes som fejltid.

Udefra kommende faktorerUtilgængelighed, der skyldes faktorer som hærværk og brand hos Leverandøren, strømsvigt og fejl hos Leverandørens ISP indgår som fejltid.En tidsperiode med udfald i elforsyning, offentlige datanet, Kundens interne netværk og internetopkobling mv. indgår ikke som fejltid.

ServicevindueForebyggende vedligeholdelse og planlagt service (servicevindue), der medfører utilgængelighed, indgår ikke som fejltid – på betingelse af at servicevinduet

Både er varslet med 3 arbejdsdage og at det ikke overstiger 8 timer om måneden og at det ikke placeres inden for ma-sø 8-17



13.2 Svartider

Definition og målemetodeVed svartid forstås den tid, der forløber fra brugerens aktivering af en funktion i systemet, til systemet er klar til næste brugeraktivering af en ny funktion eller indtastning.

Målemetode og omfangMålingen foretages manuelt med stopure, suppleret med maskinelle måleværktøjer, som Leverandøren kan stille til rådighed. Det er et krav, at der skal indgå svartidsmålinger foretaget hos brugeren, altså på brugerens arbejdsstation. Hvis en måling ikke ligger inden for de anførte svartidskrav, gentages målingen og først, hvis begge målinger ligger udenfor kravene, registreres målingen som fejl. Der tages mindst 20 målinger pr. målepunkt.

Generel svartidsgarantiLeverandøren garanterer, at for nedenstående målepunkter vil 99 % af de i henhold til ovenstående afsnit foretagne målinger være mindre eller lig med de nedenfor anførte svartider.

< 1,5 sekunders svartid ved almindelige transaktioner, disse kan være

o Søgning af sag og stamdata vedr. borger via CPR-nummer eller navn

o Søgning af emnesag via sagsnummer eller titelo Fremkaldelse af dokument under sago Fremkaldelse af programmodul (dagbog, plan mv.)o Opdatering af indtastede data i systemskabelono Åbning af system efter indtastet login

< 3 sekunders svartid på komplekse transaktioner, fxo Søgning af sag og dokument i fri tekst eller via emneordo Opdatering af kalendero Åbning af indskannet dokumento Indhentning af præparatdata fra medicin.dko Beregning af udgift på borger ved månedsafslutning

Opdatering af skærmbilleder må ikke på noget tidspunkt have en svartid > 7 sekunder

Generelt skal svartidsgarantien i kontraktperioden gælde uanset antal brugere og datamængder. Det er Leverandørens ansvar at sikre at den



nødvendige kapacitet er til stede.

Ved driftsprøven gælder nedenstående krav:

Forudsætninger ved svartidsmålingerVed svartidsmåling ved driftsprøve skal:

Data skal være konverteret Halvdelen af brugerne være logget på

Overskredne svartider indgår som fejltidOverskredne svartider, målt efter ovenstående principper, anses som fejltid og indgår således i beregningen af driftseffektiviteten.

13.3 Reaktionstid

Klassifikation af hændelser og reaktionstidKundens oplæg til reaktionstider er anført nedenfor – nærmere detaljer om klassifikation af hændelser og deres tilhørende reaktionstid fastsættes i samarbejde mellem Leverandøren og Kunden inden for rammerne af det nedenstående oplæg.



Prioritet Beskrivelse Frist1 Kritisk

Fejl, der forhindrer størsteparten af brugerne i at arbejde. Fejl i funktioner, der ajourfører data på tværs af systemer, eller som opdaterer data til mange brugere.Fejl, der rammer væsentlige funktioner i forhold til overholdelse af lovgivning, rapportering, herunder lovpligtige indberetninger mv.

Løsning påbegyndes inden for en halv time.

2 HøjFejl, der forhindrer én eller flere brugere i at arbejde.

Løsning påbegyndes inden for 2 timer

3 NormalDriftsforstyrrelse, hvor alle væsentlige funktioner er velfungerende, men som hindrer en eller flere brugere i at anvende programmet optimalt

Løsning påbegyndes inden for 8 timer.

Overskredne reaktionstider indgår som fejltid.Det tidsrum, som en given reaktionstid overskrides, tæller som fejltid og indgår således i beregningen af driftseffektivitet.

13.4 Driftseffektivitet, garanti og driftsbod

Indeks for driftseffektivitetDen samlede driftseffektivitet beregnes månedligt i form af et indeks som 100 * (1 – (fejltid/aftalt driftstid)) for hele Systemet.

Garanteret driftseffektivitetLeverandøren garanterer driftseffektivitet på 99,5 opgjort efter de ovenstående regler for produktionsmiljøet.

DriftsbodHvis beregning af driftseffektivitet for en måned ikke opfylder det garanterede resultat, skal Leverandøren for hvert påbegyndt procentpoint, som den beregnede driftseffektivitet ligger under den garanterede driftseffektivitet, betale en bod på 10 % af det samlede nettoprisindekserede drifts og vedligeholdelsesvederlag for det pågældende netsted for den pågældende måned.


BILAG 14 - SAMARBEJDSORGANISATION

Bilag 14. Samarbejdsorganisation

14.1 Gruppe- og mødeforaSamarbejdsorganisationen består i princippet af 4 niveauer:

Styregruppe Driftsgruppe Projektgruppe(r) Hertil kommer den daglige interaktion i regi af Leverandørens

Service Desk, aktiviteter i drift og projekter.

Personkreds og ændringer heriGruppernes sammensætning og ændringer heri dokumenteres i form af mødreferater.

Styregruppen Der udpeges og nedsættes en styregruppe for indholdet af Kontrakten. Her fastlægges de overordnede principper for samarbejdet samt fremtidige strategiske tiltag. Styregruppemøderne afholdes én gang pr. kvartal eller efter behov. I styregruppen udpeger hver af parterne mindst én ledelsesrepræsentant. Herudover deltager Leverandørens og Kundens driftsansvarlige og projektledere fra aktive projektgrupper. Begge parter kan udvide deltagerkredsen efter behov, herunder med eksterne rådgivere.Faste punkter på styregruppemøder:

Gennemgang af kvartalsrapport, herunder opfyldelse af servicemål

Status på drift og projekter Kontraktlige og økonomiske forhold, samarbejdets overordnede

styring og forløb Strategiske forhold og tiltag, planlægning af fremtidige

aktiviteterKunden er ansvarlig for møderne (dvs. indkalder til møderne og udarbejder referat). Kompetencekravet til mødedeltagerne er, at de kan træffe beslutninger om såvel økonomiske som ressourcemæssige forhold.


BILAG 14 - SAMARBEJDSORGANISATION

ProjektgrupperProjektsamarbejde omkring Kontrakten skal organiseres i form af en projektgruppe. Dette gælder også eventuelt efterfølgende leveringer, med mindre Kunden afstår herfra.Gruppedeltagere og mødefrekvens afhænger af kompleksiteten i leveringen – men som minimum er udpeget en projektleder fra Kunden og fra Leverandøren. Projektgruppemødernes minimumsindhold er:

Status, opfølgning på igangværende aktiviteter i henhold til Kontrakten tidsplan

Aktivitets- og tidsplanlægning, herunder identifikation af risikofaktorer og tiltag til minimering af disse

Udarbejdelse og vedligeholdelse af aktivitetslog, der skal udtrykke de to foregående punkter – med aktivitetsID, -beskrivelse, ansvarlig, tidsfrist, status

Leverandøren er ansvarlig for at opdatere aktivitetslog og at udarbejde referat af projektgruppemøderne. Referatet fremsendes minimum 2 arbejdsdage forud for næste projektgruppemøde.Parterne kan endvidere aftale at nedsætte en særlig projektgruppe, der varetager forhold vedrørende driften.

Generel initiativpligtArbejdsdeling omkring indkaldelse til møder og udarbejdelse af mødereferater ændrer ikke på Leverandørens generelle initiativpligt.

14.2 Leverandørens personale

Krav 326 Leverandøren skal beskrive det involverede personale, dets kvalifikationer (på personniveau) og dets roller i samarbejdsorganisationen.Kunden lægger i beskrivelsen vægt på, at Leverandøren i de ansvarshavende funktioner stiller med personer som har flerårig projektledererfaring (certifikat på uddannelse samt dokumentation for erfaring).Såfremt Leverandør udpeger en gruppe til varetagelse af en opgave, så skal den ansvarlige på opgaven være seniorkonsulent. (KP)


BILAG 15 - ÆNDRINGSHÅNDTERING

Bilag 15. Ændringshåndtering

Vejledning til Tilbudsgiver: Kravene i besvares i Underbilag A - Kravliste.

Leverandøren skal håndtere ændringsstyring på struktureret vis, således at servicemål ikke brydes på grund af ændringsønsker.

Ændring af kontraktenÆndring af kontrakten sker efter anmodning fra Kunden eller Leverandøren i overensstemmelse med kontrakten og nærværende bilag

ÆndringsanmodningKundens ændringsanmodning skal som minimum indeholde følgende oplysninger:

beskrivelse af den ønskede ændring, Kundens forslag til prioritering af ændringen, og dato for fremsættelse af ændringsanmodningen.

Ændringsanmodningen skal være tilstrækkelig detaljeret til, at Leverandøren i overensstemmelse med kontrakten kan udarbejde et estimat over det vederlag, som vil være forbundet med udarbejdelse af et løsningsforslag. Leverandøren er ikke berettiget til særskilt vederlag for udarbejdelse af sådanne estimater.

Leverandørens ændringsanmodningLeverandørens ændringsanmodninger skal have samme indhold som indholdet af et løsningsforslag til Kunden.Leverandøren har ikke krav på vederlag for udarbejdelse af løsningsforslag, der er en del af en ændringsanmodning fra Leverandøren.

Mindsteindhold for et løsningsforslagEt løsningsforslag skal mindst indeholde og behandle følgende:

Referat af ændringsanmodningen Beskrivelse af de påkrævede ændringer til opfyldelse af

ændringsanmodningen, Pris for gennemførelse af løsningsforslaget og eventuelle

konsekvenser for aftalt betalingsplan Eventuelle konsekvenser

o for tidsplan



o for Leverandørens øvrige ydelser og aftalte projekter i medfør af kontrakten,

o for eventuelle andre leverandørers leverancer,o for dokumentationo Kundens deltagelseo servicemål o garantiero uddannelseo tidspunkter for afprøvninger o vedligeholdelseo eventuelle andre relevante forhold.

Med mindre andet er aftalt udarbejder Leverandøren de nødvendige korrektioner til bilag, der berøres af ændringen og løsningsforslaget vedlægges disse.

Vurdering af løsningsforslag Kunden kan vælge at afvise et løsningsforslag, at anmode om ændring af løsningsforslaget eller at acceptere løsningsforslaget. Hvis Kunden anmoder om ændring af løsningsforslaget, udarbejder Leverandøren straks estimat over det vederlag, der påregnes at være forbundet med udarbejdelse af et revideret løsningsforslag. Godkendes estimatet, udarbejder Leverandøren uden ugrundet ophold og senest 5 arbejdsdage herefter et revideret løsningsforslag til Kunden. Accepteres det reviderede løsningsforslag, bortfalder Leverandørens vederlag for udarbejdelse af både det oprindelige og det reviderede forslag. Anmodning om væsentlige ændringer af et løsningsforslag anses som en afvisning af det foreliggende løsningsforslag samt fremsættelse af en ny ændringsanmodning, der så skal behandles særskilt i overensstemmelse med kontrakten og nærværende bilag. Hvis løsningsforslaget eller Leverandørens ændringsanmodning accepteres af Kunden, skal denne skriftligt have godkendt forslaget eller anmodningen forinden arbejdets iværksættelse.

ÆndringslogLeverandøren skal føre en ændringslog. Heri skal indføres:

daterede ændringsanmodninger, daterede estimater for vederlag for udarbejdelse af

løsningsforslag, daterede løsningsforslag, godkendte løsningsforslag,



opdaterede tidsplaner, opdaterede betalingsplaner, og øvrige relevante dokumenter.

Hver ændringsanmodning skal tildeles et særligt identifikationsnummer, således at ændringsanmodningen og de hertil knyttede dokumenter kan følges i ændringslog'en.


BILAG 16 - OPTIONER

Bilag 16. Optioner

Vejledning til tilbudsgiver: Besvarelse af krav foretages i Underbilag A, med mindre andet er anført, i overensstemmelse med de deri anførte instruktioner herom. Priser angives i Kontraktbilag 6.

16.1 Integration med Kundens mailsystemLeverandøren anfører pris og vilkår for integration af Systemet med Kundens mailsystem Exchange med henblik på at mails kan overføres til og journaliseres direkte systemet, jf. Krav 191.Leverandøren anfører pris og vilkår for integration af Systemet med Kundens kalendersystem med henblik på, at medarbejderes kalendere synkroniseres således, at aftaler oprettet i Systemets medarbejderkalender overføres til medarbejderens kalender i kundens kalendersystem og omvendt.

16.2 Elektronisk medicinbestillingLeverandøren anfører pris og vilkår, jf. Krav 220.

16.3 Log-in ved brug af digital medarbejder signaturLeverandøren anfører pris og vilkår, jf. Krav 239.

16.4 Log-in ved brug af NemIDLeverandøren anfører pris og vilkår, jf. Krav 240.

16.5 Integration med fagsystemerLeverandøren anfører pris og vilkår for integration med de i Krav 305 anførte systemer.

16.6 Brugeruddannelse – enhedspriser og prisindikationLeverandøren skal pr. systemområde i Løsningen anføre, under forudsætning af at uddannelsen foregår i Kundens lokaler:

a) Enhedspriser for brugeruddannelse (X personer i Y dage)

Det kan umiddelbart lægges til grund, at ca. 3200 bruger skal uddannes.


Documents

Kontraktbilag - Region Midtjylland€¦ · Web viewDet skal være muligt at foretage et print af en plan i word-, pdf- og rtf-formater. (KP) Det skal være muligt at læse og skrive