Underbilag 3 skal udfyldes af tilbudsgiver som del af tilbuddet. Udfyldelse skal ske i overensstemmelse med nedenstående retningslinjer.

Transkript

1 BILAG 3: KRAVSPECIFIKATION OG LØSNINGSBESKRIVELSE, INCL. OPTIONER INSTRUKTION TIL TILBUDSGIVER: Underbilag 3 skal udfyldes af tilbudsgiver som del af tilbuddet. Udfyldelse skal ske i overensstemmelse med nedenstående retningslinjer. Bilag 3 er opdelt i fire afsnit. Det første afsnit indeholder en overordnet beskrivelse af formålet med opgaven og Kundens generelle krav. Det andet afsnit indeholder de funktionelle krav. Til dette afsnit knytter der sig en række Use-Cases. Det tredje afsnit omfatter non-funktionelle krav. Det fjerde afsnit indeholder optioner i udbuddet. Bilaget indeholder både mindstekrav og konkurrencekrav. Tilbudsgiver skal ved mindstekrav enten angive et JA, såfremt mindstekravet udfyldes, og med et NEJ såfremt kravet ikke opfyldes. Dette skal ske i kolonnen Tilbudsgivers besvarelse JA/NEJ. Det skal bemærkes at alle mindstekrav skal opfyldes og besvares med JA for at tilbuddet er konditionsmæssigt.

2 2 3. LEVERANCEBESKRIVELSE MED KRAVSPECIFIKATION OG Formål Læsevejledning Forretningsmæssige gevinster ved en fælles Regional SMSkomponent SMS-komponenten set fra borgerens side Løsningens omfang og afgrænsninger GENEREL BESKRIVELSE Aktør-kontekst diagram Aktørbeskrivelser SMS komponentens funktioner Use-Case diagram FUNKTIONELLE KRAV SPECIFIKATIONER Use Case 1: Hent oversigt og status til driftsopfølgning Use Case 2: Hent udtræk til statistik Use Case 3: Konfigurere og opdatere mapningstabel Use Case 4: Konfiguration og administration af SMS-komponent Use Case 5: Udsend SMS Use Case 6: Opret SMS-besked Use Case 7: Ændre_Opdatere SMS besked Use Case 8: Slet SMS-besked Use Case 9: Hent status på SMS i eget bookingsystem Use Case 9: Hent status på SMS FUNKTIONELLE KRAV NON FUNKTIONELLE KRAV OPTIONER... 33

3 3 3. LEVERANCEBESKRIVELSE MED KRAVSPECIFIKATION OG 3.1 Formål Denne kravspecifikation definerer kravene for leverancen af en fælles regional SMSkomponent til Region Syddanmark. 3.2 Læsevejledning Kapitel 4. giver en generel beskrivelse og oversigt over de forretningsmæssige gevinster, som en SMS-komponent vil give Region Syddanmark. Kapitel 5. beskriver leverancens indhold samt giver en systemoversigt blandt vha. Use Case-diagrammer. Kapitel 6. beskriver de specifikke krav, dvs. her er kravene til hver Use Case detaljeret beskrevet. Kapitel 7. og 8. beskriver henholdsvis de funktionelle og nonfunktionelle krav. Begrebet system i nærværende kravspecifikation svarer til leverancen af SMSkomponenten. Definitionen løsning svarer til den samlede leverance, altså SMSkomponent, infrastruktur, server, hardware, netværk etc. 3.3 Forretningsmæssige gevinster ved en fælles Regional SMS-komponent Implementeringen af en fælles regional SMS-komponent i Region Syddanmark skal medføre at det bliver muligt, at sende en SMS-besked til påmindelse af patienter om, at de har en aftale med et af Regionens sygehuse. Det vurderes, at indførelsen af en SMSkomponent i Region Syddanmark vil reducere antallet af udeblivelser, og dermed medføre en effektivisering på sygehusene i forbindelse med reducering af replanlægning i klinikkerne. Ud over de økonomiske gevinster og interne effektiviseringsforbedringer er det også hensigten, at patienten oplever og opnår serviceforbedringer i forbindelse med kontakten til sygehusene i Regionen. De forretningsmæssige fordele kan kort opsummeres i nedenstående overskrifter og punkter. De primære fordele er:

4 4 Nedbringe antallet af uvarslede udeblivelser Informere og servicere patienter omkring mødetidspunkter Region Syddanmark forventer desuden at opnå: Mere optimal ressourceallokering Bedre kapacitetsudnyttelse Løsningen giver værdi for patienterne Region Syddanmark ønsker en central regional løsning for at: Begrænse omkostningerne, så der ikke udvikles og driftes decentrale løsninger Patienterne behøver kun at vedligeholde stamdata ét sted Integration til SMS-komponenten er ensartet uanset systemtilkobling Minimere administrationen i klinikken i forbindelse med forsendelse af SMS 3.4 SMS-komponenten set fra borgerens side Region Syddanmark ønsker at støtte op om den nationale digitaliseringsstrategi og ønsker, at borgeren oplever en så stringent kommunikation med det offentlige som muligt. Borgerne vedligeholder kontakten til det offentlige via borger.dk/e-boks.dk. Det er derfor borgerne selv, der tilmelder sig løsningen. Region Syddanmark vil i forbindelse med implementeringen af SMS-komponenten gennemføre en kampagne med det formål at gøre patienterne opmærksomme på muligheden for at modtage SMS forud for en aftale på et sygehus. 3.5 Løsningens omfang og afgrænsninger Volumen af forsendelser af SMS-påmindelser er afhængig af borgernes tilslutning til løsningen. Region Syddanmark forventer, at man fra fuld implementering i alt vil sende SMS-påmindelser og med en 10 % stigning i årene fremad. Det afhænger dog helt af borgernes tilslutningsgrad til modtagelse af SMS fra regionens sygehuse, og estimatet er med en vis usikkerhed. Region Syddanmark håndterer årligt omkring 2 mio. bookinger. Region Syddanmark varetager selv driften af selve SMS-komponenten og vil på baggrund af leverandørens specifikationer selv sørge for anskaffelse af nødvendige infrastrukturkomponenter som eksempelvis server, database, licenser etc. SMS komponenten skal kunne afvikles i et datacenter. Dette betyder der ikke bliver tale om mulighede for fail-

5 5 over, eller aktiv/passiv setup imellem drift centrene. Det betyder til gengæld, at Tilbudsgiver detaljeret skal udarbejde en infrastrukturspecifikation, der indeholder alle nødvendige infrastrukturkomponenter, hvorved systemet kan ibrugtages og driftes på en hensigtsmæssigt måde. Dette udbydes også i kravspecifikationen. Leverancer vedr. implementering, dokumentation, projektledelse, integrationer, test, uddannelse fremgår enten af kravspecifikation eller udbuddets øvrige bilag. Projektet skal afsluttes indenfor en periode på omkring 6 måneder. Region Syddanmark ønsker endvidere at indgå en vedligeholdelses- og support aftale for løsningen med en varighed på 48 måneder med option på yderligere 2 gange 12 måneder. Leveringssted er Region Syddanmark, Damhaven 12, 7100 Vejle. 4. GENEREL BESKRIVELSE Region Syddanmark ønsker at anskaffe, implementere og efterfølgende vedligeholde og drifte en SMS komponent, der udsender SMS-beskeder (sms-påmindelser) til patienten til påmindelse om, at patienten har en aftale på et af regionens sygehuse. Udsendelse af SMS-påmindelser skal ske på baggrund af bookinger foretaget i et af Region Syddanmarks kliniske bookingsystemer (eks. Røntgensystemerne og de generelle bookingsystemer, ProSang, EPJ COSMIC, BookPlan, Opus, FPAS, Mammografi mv.). SMS-komponenten skal opfattes som en SMS gateway, hvis hovedformål er videredistribuering af SMS-beskeder til NemSMS. SMS-komponenten skal dog indeholde en brugergrænseflade primært for Administrative personer i forhold til konfiguration og udtræk. Det betyder, at SMS-komponentens hovedformål er udsendelse af SMS-beskeder via NemSMS på baggrund af bookinger foretaget i et af Regionens bookingsystemer. De forskellige elementer, som indgår i den samlede SMS løsning, fremgår af figur 1.

6 6 Borgeren/Patienten Tilmelding Borger.dk eboks.dk (Tilmeld-app) Modtagelse SMS besked National infrastruktur NemSMS Tilmeldings -register Distribution SMS komponent REST REST Leverandørens ansvarsområde inkl. integration til NemSMS Logning/ Admin SMS-Gateway Forsendelse og konfiguration Klargøring Udtræk SMS database Status SMS Opret,ændre og slet bookninger Regionale bookingsystemer Regionens ansvarsområde REGIS FPAS COSMIC Røntgen System X Figur 1 - Sammenhæng og overblik SMS komponent Regionens bookingsystemer skal via Regionens integrationsplatform (REGIS) sørge for, at bookingoplysninger overføres til SMS-komponenten. SMS-komponenten skal kommunikere med NemSMS, som står for selve afsendelsen af SMS-beskeder, til de patienter, der er tilmeldt. Region Syddanmark ønsker at bruge NemSMS, da borgerne selv vedligeholder kontaktoplysningerne i NemSMS. Det betyder, at det er Regionens ansvar via REGIS at levere bookingdata til SMSkomponentens udstillede services. Når de relevante bookingoplysninger succesfuldt er overført til SMS-komponenten, har SMS-komponenten ansvaret for den videre forsendelse af SMS-beskeder via NemSMS til patienten. Endvidere skal SMS-komponenten udstille en service via REGIS, hvorved det er muligt for Regionens systemer at foretage et opslag, der giver en status (eks. SMS besked afsendt) for SMS-beskeden. Samtykke om modtagelse af SMS samt oplysninger og opdatering af mobilnummer skal ske via borger.dk.

7 7 SMS-komponenten skal derudover håndtere: Logning og brugeradministration konfiguration af SMS-beskeden samt administration for forsendelse af SMSbeskeder. Klargøring af beskeder herunder mapning imellem SKS og SOR Udtræksmuligheder til ledelsesinformation samt til systemadministratorer. 4.1 Aktør-kontekst diagram Figur 2 viser SMS-komponenten og de aktører, der kommunikerer med systemet. En aktør repræsenterer en personrolle eller et andet eksternt system, der kommunikerer med SMS-komponenten. REGIS NemSMS SMS komponent Administrator Sekretær Øvrige interessenter Borger Udtræksbruger Figur 2 - Aktør-kontekst diagram

8 8 4.2 Aktørbeskrivelser Aktørnavn: Administrator Type: En personaktør, der er en primær aktør. Beskrivelse: Administrator er en personrolle, der varetager den generelle administration af SMSkomponenten, herunder konfiguration af SMS beskeder, vedligeholdelse af mapningstabeller, varetager overvågning og opfølgning i forbindelse med SMS-forsendelse, samt danner udtræk. Administrator er den person, der oftest vil bruge SMS-komponenten. Antal samtidige aktører: 0 til mange Aktørnavn: REGIS Type: REGIS er en sekundær aktør i forhold til SMS komponenten. Beskrivelse REGIS er Region Syddanmark integrationsplatform, hvor alle integrationer imellem systemer skal foregå. REGIS varetager både data- beskedoverførelse og datatransformation samt udstilling af services. Antal samtidige aktører: 1 Aktørnavn: NemSMS Type: NemSMS er en sekundær aktør i forhold til SMS komponenten. Beskrivelse NemSMS er en fællesoffentlig sms-løsning, hvor borgere kan vælge at registrere et mobilnummer, så de kan modtage sms-påmindelser fra offentlige myndigheder. Antal samtidige aktører: 1 Aktørnavn: Sekretær

9 9 Type: En personaktør, der er en primær aktør. Beskrivelse: Sekretærrollen vil skulle tilgå SMS-komponenten for at foretage udtræk i forhold til statistik. Om option (se Option ) vil sekretæren hente status på den afsendte SMS i enten et webopslag eller i eget bookingsystem. Usecase 5.9 og Antal samtidige aktører: 0 til mange

10 SMS komponentens funktioner 4.4 Use-Case diagram

11 11 Hent oversigt og status til driftsopfølgning «uses» «uses» Konfigurere og opdatere mapningstabel «uses» Administrator Konfiguration og administration af SMS komponent «uses» Opret SMS besked «uses» Ændre_opdatere SMS besked «uses» REGIS Slet SMS besked «uses» Udsend SMS NemSMS «uses» Hent udtræk til statisik «uses» Sekretær Hent status på SMS

12 12 5. FUNKTIONELLE KRAV SPECIFIKATIONER 5.1 Use Case 1: Hent oversigt og status til driftsopfølgning Navn: Hent oversigt og status til Aktør: Administrator driftsopfølgning Mål: Administrator skal hente oversigt over fejlede beskeder samt en status på, hvorfor beskederne er fejlet. Initiering: Administrator Samtidige forekomster: 10 Frekvens: 2 gange dagligt Referencer: Ingen Startbetingelser: SMS-beskeder er overført fra REGIS til SMS-komponenten og Administrator er logget ind i SMS-komponenten. Slutbetingelser: Succes: At Administrator præsenteres for en overskuelig oversigt over SMS-beskeder afsendt inden for et givet tidsrum over fejlede beskeder med tilknyttet fejlstatus. Fejl: At Administrator præsenteres for en forkert liste/oversigt Trin: Normalforløb 1. Administrator vælger funktionalitet for oversigt af fejlede SMS-beskeder. 2. Administrator afgrænser oversigten over fejl ved hjælp af eksempelvis sygehus, afdeling, startdato og slutdato. 3. SMS-komponenten præsenterer en oversigt over fejlede SMS-beskeder. Oversigten indeholder som minimum: - Sygehus - Afdeling - BookingID - Dato og tid for SMS-afsendelse - Dato og tid for afsendelse til NemSMS - CPR-nummer - Status for afsendelse af SMS besked - Meningsfuldfejltekst (eks. ikke muligt at sende til NemSMS, osv.) 4. Administrator har mulighed for at tilvælge og tilføje, hvilke dataelementer oversigten skal indeholde. 5. Administrator vurderer oplysningerne og kan herefter sortere i oplysningerne.

13 13 Navn: Hent oversigt og status til Aktør: Administrator driftsopfølgning 6. Administrator vælger at gemme udtræk i excel. 7. Administrator søger på specifikke parametre som eksempelvis cpr eller status. 8. Administrator afslutter og returnerer til desktop. Undtagelser: Ingen Kommentarer Lister/oversigt skal leveres som csv- eller xls-format til viderebearbejdning. Lister skal blandt andet kunne benyttes ifm. utilsigtede hændelser (eks. at patient ikke er indkaldt eller påmindet indenfor givne kvalitetsmål) 5.2 Use Case 2: Hent udtræk til statistik Navn: Hent udtræk til statistik Aktør: Sekretær Mål: Sekretær skal hente udtræk til statistiske formål. Initiering: Sekretær Samtidige forekomster: 10 Frekvens: 2 gange dagligt Referencer: Ingen Startbetingelser: SMS-beskeder er overført fra REGIS til SMS-komponent. Slutbetingelser: Succes: At sekretæren præsenteres for en overskuelig udtræk over SMS-beskeder afsendt inden for et givet tidsrum med tilhørende fejlede beskeder. Fejl: At sekretær præsenteres for en forkert udtræk. Trin: Normalforløb 1. Vælg funktionalitet for udtræk af statistiske data 2. Sekretær har mulighed for at tilvælge og tilføje hvilke dataelementer udtrækket skal indeholde. Oversigten skal som minimum indeholde anonymiseret data herunder: - Sygehus - Afdeling - Dato og tid for SMS-afsendelse - Dato og tid for afsendelse til NemSMS - Status for afsendelse af SMS besked

14 14 Navn: Hent udtræk til statistik Aktør: Sekretær - Meningsfuldfejltekst (eks. ikke muligt at sende til NemSMS, osv.) 3. Sekretæren gemmer udtrækskriterierne som standardudtræk til brug for fremtidige udtræk. 4. SMS-komponenten genererer et udtræk og præsenterer oplysningerne 5. Sekretær vælger at gemme udtræk i excel 6. Sekretær afslutter og returnere desktop. Undtagelser: Ingen Kommentarer Lister/oversigt skal leveres som csv- eller xls-format til viderebearbejdning. Som inspiration til udtræk kunne nedenstående være interessant: o o Antal SMS-forsendelser pr. måned pr. sygehus samt i hele Regionen. Antal SMS-forsendelser, som ikke blev videresendt pr. dag eller pr. måned, grupperet på eksempelvis årsag. Det skal være muligt at automatisere udtrækkene. 5.3 Use Case 3: Konfigurere og opdatere mapningstabel Navn: Konfigurere og opdatere Aktør: Administrator mapningstabel Mål: Administrator skal via SMS-komponenten kunne konfigurere og opdatere mapningstabellen i SMS-komponenten. Mapningstabellen skal benyttes til at oversætte SOR/SKS-koder og EAN til sygehus og afdeling/afsnit.og afsendertelefonnr og mailadresse Eksempelvis: SKS= ; SORkode= svarer til Sydveskjysk Sygehus, Gynækologisk afsnit, tlf , hans.ole.daugaard@svs.regionsyddanmark.dk

15 15 Navn: Konfigurere og opdatere mapningstabel Aktør: Administrator EAN= ; Svarer til Regionshospital Holstebro, HJERTEMEDICINSK DAGAFSNIT tlf Initiering: Administrator Samtidige forekomster: 10 Frekvens: 1 gange dagligt Referencer: Generel information vedr. SOR. Information vedr. Regionens SOR komponent kan findes på: Startbetingelser: Opdatering af ny mapning imellem ny SKS/SOR kode eller EAN nummer tilhørende sygehus og afdeling. Slutbetingelser: Succes: At Administrator opretter ny mapning og dette efterfølgende indgår i SMS besked til patient. Fejl: At Administrators konfigurerede mapning ikke indgår i SMS-besked til patient og dermed ikke afsendes. Trin: Normalforløb 1. Vælg funktionalitet for opdatering og konfiguration for mapninger. 2. Mulighed for at opdatere mapningstabel i SMS-komponenten. 3. Administrator vælger at gemme mapningstabel i excel. Undtagelser: Fortryd: Administrator skal på et vilkårligt tidspunkt kunne fortryde. Kommentarer Generelt ønsker Regionen at automatisere opgaver vedr. vedligeholdelse. Regionen har en SOR-komponent, hvor det automatisk er muligt at opdatere interne registre og mapningstabeller. Regionen vægter det positivt, såfremt dette kan automatiseres.

16 Use Case 4: Konfiguration og administration af SMS-komponent Navn: Konfiguration og administration Aktør: Administrator af SMS komponent Mål: At kunne konfigurere og ændre SMS-komponenten i forhold til eksempelvis tidspunkt samt i tekst opbygning og indhold i SMS-beskeden, der afsendes til patienten. Initiering: Administrator Samtidige forekomster: 10 Frekvens: Højst 1 gange dagligt. Referencer: Ingen Startbetingelser: Administrator er logget ind i SMS-komponenten og skal ændre SMS-tekst og antal timer før SMS beskeden skal sendes patienten. Slutbetingelser: Succes: At ændring af SMS-tekst er sendt til patienten. At patienten har modtaget SMS besked på det rette tidspunkt før mødetidspunkt på sygehuset. Fejl: At Administrator præsenteres for en fejlmeddelelse, såfremt tidspunkter ikke er korrekte eller at indholdet af SMS-besked er forkert eller indeholder for mange karakterer. Trin: Normalforløb 1. Administrator vælger funktionalitet for konfiguration af SMS-komponent. 2. Administrator konfigurerer via SMS-komponenten en ændring af udsendelsestidspunkt. 3. Administrator konfigurerer evt. ændring af tekstindholdet i SMS-besked 4. SMS.komponenten validerer ændringerne 5. SMS.komponenten sørger for, at ændringerne slår igennem, så SMS-beskederne fremadrettet benytter den nye konfiguration og ændringer. 6. Administrator afslutter og returnerer til desktop. Undtagelser: Ugyldig udsendelsestidspunkt Indtaster Administrator en ugyldigt tidspunkt for SMSudsendelse, giver SMS-komponenten en retvisende fejlmeddelelse og mulighed for at indtaste tidspunkt igen eller terminere use casen. Overskridelse af SMS tekstlængde Der kan være beskeder der overskrider max længden for

17 17 Navn: Konfiguration og administration af SMS komponent Aktør: Administrator SMS beskeden, hvilket medfører at der benyttes en såkaldt nødopskrift til SMS indhold og opbygning, hvilket skal varetages af SMS komponenten. Kommentarer Såfremt NemSMS opstiller regler for udsendelse af SMS beskeder, skal der tages højde for disse, når Administrator konfigurerer SMS-komponenten og gives en fejlmeddelelse, såfremt disse ikke overholdes. Eksemel af nødopskrift : Husk aftalen på <afdelings-/ afsnitsenhedsnavn>,<sygehusenhedsnavn> på <bookingdato> kl. <bookingtidspunkt>. 5.5 Use Case 5: Udsend SMS Navn: Udsend SMS Aktør: NemSMS Mål: At SMS-komponenten overfører SMS-besked til NemSMS. NemSMS sørger for udsendelse af SMS-besked til patienten. Initiering: SMS-komponent Samtidige forekomster: 1 Frekvens: 1000 i peak hour Referencer: NemSMS-og-Fjernprint/Teknisk-dokumentation-og- vejledninger/~/media/files/digitalpost%20mv/digital%20post- NemSMS%20Snitflader%20v61_med%20aendringsmarkeringer.ashx Her findes information om REST-kald: Startbetingelser: NemSMS-og-Fjernprint/Vejledning-og-teknisk-dokumentation/Om- REST-Kald SMS-komponenten har med succes fået overført bookingbesked.

18 18 Navn: Udsend SMS Aktør: NemSMS SMS-komponenten har klargjort SMS-besked, hvorved udsendelsestidspunktet og SMS-indhold er i overensstemmelse med Regionens konfiguration og opsætning af SMS-komponenten. Slutbetingelser: Succes: At patienten modtager SMS-besked via NemSMS. Fejl: At SMS-besked ikke udsendes til patient. Trin: Normalforløb 1. SMS-komponenten sender SMS-besked til NemSMS 2. NemSMS sørger for videredistribution af SMS-beskeden til patienten. Undtagelser: Patient ikke tilmeldt NemSMS SMS-komponenten skal registrere dette som en fejl, og dette skal indgå i fejloversigten. Kommentarer Sker der ændringer eller sletning af beskeder, skal SMSkomponenten sørge for, at dette også slår igennem i forhold til NemSMS. Det er først på forsendelsestidspunkt, at patientens tilmeldingsstatus til NemSMS skal checkes, da det ændres løbende. 5.6 Use Case 6: Opret SMS-besked Navn: Opret SMS-besked Aktør: REGIS Mål: Der overføres en bookingbesked via REGIS til SMSkomponenten, som på baggrund af denne danner en SMSbesked. Initiering: REGIS Samtidige forekomster: 1000 beskeder i peak hour Frekvens: Løbende Referencer: Ingen Startbetingelser: At patient er booket i af Regionens bookingsystemer. Slutbetingelser: Succes: At bookingbesked via REGIS er overført til SMSkomponenten, og at der oprettes og klargøres en SMSbesked til udsendelse. Fejl: At indholdet i besked fra REGIS er fejlbehæftet eller data mangler i mapningstabel.

19 19 Navn: Opret SMS-besked Aktør: REGIS Trin: Normalforløb 1. Der oprettes en booking i et af regionens bookingsystemer 2. Bookingbeskeden overføres via REGIS til SMS-komponenten 3. SMS-komponenten danner SMS-besked og gør klar til udsendelse i henhold til den konfigurerede eller modtaget udsendelsestidspunkt samt indhold af SMSbesked. Undtagelser: Manglende oplysninger Hvis tidspunktet er tomt eller 00:00, skal der ikke stå et tidspunkt i SMS-beskeden. Kommentarer Eksempel af en SMS besked (hvis SMStekst ikke en del af informationer modtaget fra REGIS): Kære <fornavn> <efternavn>, Husk din aftale på <afdelings- /afsnitsenhedsnavn>,<sygehusenhedsnavn> på <bookingdato> kl. <bookingtidspunkt>. 5.7 Use Case 7: Ændre_Opdatere SMS besked Navn: Ændre_Opdatere SMS-besked Aktør: REGIS Mål: Der sker en ændring og opdatering af den eksisterende bookingbesked i SMS-komponenten. Initiering: REGIS Samtidige forekomster: 100 beskeder i peak hour Frekvens: Løbende Referencer: Startbetingelser: At der sker en ændring af patientbookingen i et af Regionens bookingsystemer. Slutbetingelser: Succes: At den allerede overførte bookingbesked i SMSkomponenten opdateres/ændres, så den afspejler den ændrede booking. Fejl: At indholdet i besked fra REGIS er fejlbehæftet eller data mangler i mapningstabel. Trin: Normalforløb 1. Der ændres en booking i et af regionens bookingsystemer. 2. Den ændrede bookingbesked overføres via REGIS til SMS-komponenten.

20 20 Navn: Ændre_Opdatere SMS-besked Aktør: REGIS 3. SMS-komponenten ændrer den oprindelige SMS-besked og gør klar til udsendelse i henhold til den konfigurerede udsendelsestidspunkt samt indhold af SMSbesked. Undtagelser: Manglende oplysninger Hvis tidspunktet er tomt eller 00:00, skal der ikke stå et tidspunkt i SMS-beskeden. Kommentarer Såfremt der ikke findes en tidligere oprettet besked skal en ændring håndteres som en oprettelse. 5.8 Use Case 8: Slet SMS-besked Navn: Slet SMS-besked Aktør: REGIS Mål: Der overføres en slet bookingbesked via REGIS til SMSkomponenten, som på baggrund af denne sletter beskede i SMS komponenten. Initiering: REGIS Samtidige forekomster: 100 beskeder i peak hour Frekvens: Løbende Referencer: Startbetingelser: At der sker en sletning af patientbookingen i et af Regionens bookingsystemer. Slutbetingelser: Succes: At den oprindelige besked slettes i SMSkomponenten, så SMS-beskeden ikke udsendes til patienten. Fejl: At bookingbeskeden ikke kan slettes i SMS-komponent. Trin: Normalforløb 1. Der slettes en booking i et af regionens bookingsystemer 2. Den slettede bookingbesked overføres via REGIS til SMS-komponenten 3. SMS-komponenten sletter den oprindelige SMS-besked, så SMS-besked ikke kan udsendes. Undtagelser: Ingen Kommentarer

21 Use Case 9: Hent status på SMS i eget bookingsystem Navn: Hent status på SMS Aktør: Sekretær Mål: Sekretæren tjekker status på SMS Initiering: Sekretæren Samtidige forekomster: 100 beskeder i peak hour Frekvens: Løbende Referencer: Startbetingelser: Sekretæren ønsker at checke status på SMS og send-status på denne. Slutbetingelser: Succes: Sekretæren finder oplysninger vedrørende sendstatus på specifik SMS. Fejl: Sekretæren finder ikke oplysninger på send-status.. Trin: Normalforløb 1 Der oprettes en booking i et af regionens bookingsystemer 2 Den oprettede bookingbesked overføres via REGIS til SMS-komponenten 3 SMS-komponenten sender SMS til Nem-SMS 4 SMS-komponent lagrer oplysning på send-status og sender dette til REGIS 5 Bookingsystemet modtager oplysninger fra REGIS vedr. send-status. 6 Sekretæren laver opslag på status på SMS i bookingsystem. Undtagelser: Ingen Kommentarer Sendstatus skal indeholde tekst omkring SMS der kan forståes af sekretæren Use Case 10: Hent status på SMS Navn: Hent status på SMS Aktør: Sekretær Mål: Sekretæren tjekker status på SMS Initiering: Sekretæren Samtidige forekomster: 100 beskeder i peak hour Frekvens: Løbende Referencer: Startbetingelser: Sekretæren ønsker at checke status på SMS og send-status på denne.

22 22 6. FUNKTIONELLE KRAV ID TITEL Type MK, K Funktionelle krav MK Usecases Navn: Hent status på SMS Aktør: Sekretær Slutbetingelser: Succes: Sekretæren finder oplysninger vedrørende sendstatus på specifik SMS. Fejl: Sekretæren finder ikke oplysninger på send-status.. Trin: Normalforløb 1 Der oprettes en booking i et af regionens bookingsystemer 2 Den oprettede bookingbesked overføres via REGIS til SMS-komponenten 3 SMS-komponenten sender SMS til Nem-SMS 4 SMS-komponent lagrer oplysning på send-status. 5 Sekretæren laver opslag ved hjælp af bookingid. Undtagelser: Ingen Kommentarer Status til sekretær må ikke indeholde personfølsomme data, da vi ikke ønsker at sekretær skal logge ind for anvende denne funktionalitet. Tilbudsgivers besvarelse (Ja/Nej) Beskrivelse Leverandøren skal kunne understøtte de beskrevne Use-Cases svarede til use case 1 til 8. Leverandøren skal for hver Use-Case beskrive, hvorledes understøttelsen sker KK Leverandøren bedes redegøre for, hvordan Use-Cases 1-8 understøttes. Leverandøren skal for hver Use-Case beskrive, hvorledes understøttelsen sker MK Skaler- SMS komponenten skal ved produktionsstart

23 23 barhed håndtere udsendelse af antal SMSbeskeder. SMS-komponenten skal være dimensioneret til at kunne udsende antal SMS-beskeder årligt MK Skalerbarhed SMS-komponenten skal kunne håndtere, at 10 aktører er på samtidig i systemet KK Brugergrænseflade Selvom SMS-komponenten benyttes mindre antal aktører, lægges der vægt på, at brugergrænsefladen følger MS Windowsstandarden. At systemet kan benyttes uden mus og arbejdet kan udføres med få klik. Brugergrænsefladen er på dansk KK Hjælpefunktion Der bør være adgang til kontekstsensitiv hjælp, eller som minimum adgang til dokumentation direkte fra systemet KK Svartider Den tid det tager at danne en månedsrapport må maksimum være 4 minutter MK Uddannelse 2 personer fra Kunden skal uddannes af leverandøren i systemet, herunder i brugeroprettelser MK Uddannelse Uddannelse af driftspersonale 7. NON FUNKTIONELLE KRAV ID TITEL Type MK, K Tilbudsgivers besvarelse (Ja/Nej) Krav til Infrastruktur og hardware MK Lovgivning Beskrivelse Systemet skal til enhver tid overholde dansk lovgivning indenfor sundhedsområdet og omkring anvendelse af personfølsomme data og de retningslinjer, der er udarbejdet

24 24 af Datatilsynet herunder Datatilsynest Sikkerhedsbekendtgørelsen for Offentlig virksomhed, se link 0.aspx?id= MK Lovgivning SMS-komponenten skal overholde sikkerhedsinstrukser beskrevet af Digitaliseringsstyrelsen ifm. digitalpost/nemsms: infrastruktur/digital-post-nemsms-og- Fjernprint/Vejledning-og-tekniskdokumentation/Om-sikkerhed.aspx MK Sikkerhed Systemet skal overholde regionens politikker for it-sikkerhed, se bilag 2 Kundens IT miljø afsnit 2.5 samt underbilag 2G Strategi for IT Sikkerhed, 2G2 Politik for IT sikkerhed MK System Det skal være muligt at bruge systemet normalt, selvom der foretages opdateringer eller konfiguration MK Sikkerhed Systemet skal give fuld sikkerhed for integritet af data, således at data ikke mistes, forvanskes eller kommer til personer, der ikke har adgang til de pågældende data MK Sikkerhed og logning Systemet skal kunne foretage transaktionslogning på relevante hændelser, hvilket inkluderer brugerhændelser, hændelser fra andre delsystemer i henhold til gældende love og regler. Det betyder, at der skal være fuld sporbarhed på alle transaktioner og registreringer. Loggen skal som minimum have et tidsstempel (dato og klokkeslæt) samt information om den bruger eller det delsystem, som

25 25 er ansvarlig for hændelsen KK Sikkerhed og logning Leverandøren bedes beskrive systemets mulighed for logning, gerne illustreret med eksempellog eller skærmbilleder. Tilbudsgiver skal beskrive værktøjer og redskaber gerne illustreret med eksempler som systemet stiller til rådighed, samt hvilke typer og indhold af logning og analyser, der foretages eller kan foretages i systemet MK AD Der skal være AD-integration med autentificering med bruger-id og password mod Regionens AD via LDAP(S) KK Adgangsgangskontrol og rettigheder Tilbudsgiver bedes beskrive muligheder for rolle- og rettighedsstyring, herunder: Hvilke rettigheder og muligheder en systemadministrator har med hensyn til tilpasning og konfigurering af systemet. Beskrive rettighedsstrukturen i systemet og hvordan rettigheder i systemet administreres, herunder systemets muligheder for at tildele, oprette eller fjerne rettigheder KK Adgangsgangskontrol SMS komponenten skal tillade adgang til anonymiseret udtræk uden krav om username og password. SMS komponent MK Tegnsæt Det anvendte tegnsæt skal være i overensstemmelse med Unicode (UTF-8) og RFC Danske specialtegn skal (ved søgning, sortering, visning, udskrift og lignende) behandles korrekt overalt i systemet MK Krav til integra- Integrationer imellem SMS -komponenten og Regionens andre systemer skal ske via

26 26 tion regionens integrationsplatform (REGIS), se bilag 2 afsnit MK Krav til Integrationsrammeværket Baseline skal 3 integra- følges i forbindelse med integration i Region tion Syddanmark, se underbilag 2c2 til 2c7, samt Applikations Integrations Politik (AIP) beskrevet i underbilag 2b. Det gælder både i forhold til udstilling af webservices samt ifm. købaseret kommunikation via WMQ MK Krav til WebServices skal udstilles i henhold til regi- 4 integra- onens retningslinjer for webservices Ret- tion ningslinjer for WebServices se underbilag MK Krav til Det er et krav, at der laves integration til 5 integra- følgende eksterne services/systemer uden tion om regionens integrationsplatform NemSMS Ovenstående integration skal varetages af leverandøren og skal ske direkte til/fra systemet. Det betyder, at det er leverandørens opgave og ansvar at indhente nødvendige specifikationer såvel teknisk som forretningsmæssigt, der gør leverandøren i stand til at foretage integrationen egenhændigt. Regionen vil naturligvis være behjælpelig i det omfang, det er muligt, men i sidste ende ligger ansvaret hos leverandøren MK Krav til Systemet skal beskytte mod tab eller duble- 7 integra- ring af data ved overførsel mellem SMS tion komponenten og NemSMS, eksempelvis i forbindelse med, at ét eller begge systemer har været offline eller går ned. Det betyder konkret, at systemet skal være i stand til at gensende data.

27 KK Integra- Leverandøren bedes beskrive systemets 8 tion til mulighed for understøttelse og anvendelse SOR af SOR, herunder integration til Regionens SOR-komponent. Det betyder konkret anvendelse og integration til komponentens udstillede services samt abonnement på ændringer fra komponenten. Se beskrivelse af SOR-komponent på y/public/sor+service MK Krav til Tilbudsgiver har ansvaret for selve udarbej- 9 integra- delsen af integrationsspecifikation (se un- tion derbilag 2 C7, Baseline Integration Specification) for alle integrationer i leverancen. Tilbudsgiver har samtidig projektledelsen af, at integrationerne bliver beskrevet og etableret i henhold til den samlede projektplan for løsningen. Kunden deltager naturligvis i dette arbejde, men proces og udarbejdelsen af integrationsspecifikationerne varetages af Tilbudsgiver. Tilbudsgiver skal indgå i samarbejdet med de nuværende 3 parts leverandører som systemet skal integrere til, hvorved det sikres, at en fornuftig integrationsløsning kan etableres MK Krav til integration Omkostninger til eventuelle programmeringsmæssige tilpasninger af eksisterende 3 parts systemer afholdes af Kunden, og skal således ikke indgå i Leverancen. SMS komponent skal udstille nedenstående service/snitflade: Snitflade SMS komponent Baseline

28 28 SystemID Cprnr Fornavn Efternavn SKS/SOR EAN Sygehus Sygehusafdeling/afsnitenhed Mødested (eks indgang 112) Bookingdato Bookingtidspunkt Afsendertelefonnr SMStekstbesked SMSAfsendelsesdato SMSAfsendelsestidspunkt opretsmsbesked() opdatersmsbesked() sletsmsbesked() KK Krav til integration Det skal være muligt både at tilgå denne service som en webservice samt via WMQ. SMS komponenten skal udstille nedenstående service/snitflade som en webservice via REGIS. statussms - BASELINE - systemid - CPRnr - opslagstatussms() Det skal være muligt via denne service at lave et opslag via et cpr nummer for at se om SMS besked er afsendt eller ej på den pågældende patient MK ITIL Leverandøren skal forpligte sig til at overholde Kundens bestemmelser om Support & Servicedesk som beskrevet i Bilag 2, afsnit

29 Support og Servicedesk. Endvidere skal leverandøren opfylde Vedligeholdelsesaftalen og de pligter, der er beskrevet til at understøtte Kundens implementerede ITIL procedurer jf beskrivelser i: Underbilag 5 H - Change Management Underbilag 5 I1+I2 - Problem Management Underbilag 2D1+2D2- Incident Management Underbilag 2E Serviceintroduktion MK Installation Tilbudsgiver er ansvarlig for installation og konfiguration af systemet i alle miljøerne. MK Netværk Systemet skal kunne operere fuldt ud på Region Syddanmarks eksisterende WAN, som beskrevet i Bilag 2, afsnit Netværk, under hensyn til Servicemål angivet i bilag 6. MK Infrastruktur Orientering: Kunden ønsker selv at varetage drift af in- frastrukturen, hardware, operativsystemer samt applikations- og databaseservere ud fra specifikationer fra tilbudsgiveren på udstyr, som tilbudsgiveren garanterer lever op til den ønskede funktionalitet og kvalitet der efterlever de opstillede servicemål. SMS komponenten skal kun afvikles i et datacenter. Dette betyder der ikke bliver tale om mulighede for failover, eller aktiv/passiv setup imellem drift centrene. Krav:

30 30 Tilbudsgiver skal anføre de produkter, herunder software og hardware, evt. krav til software versioner, som Kunden skal investere i for at Leverandørens Løsning kan fungere og implementeres i Kundens it-miljø og samtidig leve op til servicemålene angivet i bilag 6. Specifikationen skal både omfatte antallet af aktive og passive servere og sammensætningen af servere. For hver enkelt server skal der redegøres for antal processorer, processortype, RAM osv. Såfremt Leverandørens Løsning stiller krav til Kundens it-miljø, som ikke opfyldes af det i bilag 2 beskrevne, skal sådanne krav anføres og specificeres i et underbilag til bilag 2, som Leverandøren udarbejder KK Tilbudsgiver bedes redegøre for Løsningens 6 pålidelighed og tilgængelighed, overvågning, logning, fejlhåndtering og backup. Der lægges i vurderingen af besvarelsen vægt på en robust løsning, der i tilfælde af nedbrud eller fatale fejl hurtigt kan reetableres MK Over- Systemet skal understøtte, at systemet 7 vågning overvåges. Dette betyder, at Kunden installerer agenter på systemet for at udføre overvågning. Leverandøren vil have mulighed for at sætte overvåningskriterier op, således at den samlede løsning kan overvåges. Overvågningen af systemet aftales med regionen KK Over- For at sikre en god overvågning af det sam- 8 vågning lede system, ønsker kunden at der udvikles en overvågnings service.

31 31 Overvågningsservicen skal benyttes af Kunden til at forespørge om systemet er kørende. Baggrunden er at kunden tidligere har set at det ikke nødvendigvis er nok at se om en service er kørende, men at den faktisk levere data. Servicen skal fungere således at når man kalder den, foretager den forskellige kontrolkald, der er nødvendige, for at sikre at systemet er kørende. Det kunne f.eks. være mod systemet database, mod et file share som bruges i løsningen, om der er forbindelse til REGIS, mod andre servere i løsningen Det er leverandøren skal sikre at inddrage de komponenter der er nødvendige for at sikre at servicen viser om systemet fungere. KK Skalering Leverandøren skal beskrive mulighederne for skalering i systemet og som en del heraf angive kendte øvre grænser for systemet mht. til udsendelse af SMS beskeder. MK Konsu- Kunden skal have mulighed for at tilkøbe lentbi- konsulentbistand under projektforløbet, stand såfremt der opstår behov for ændringer, eller efter overtagelsesdagen, såfremt der opstår behov for hjælp til integration, ændringer af systemet eller lignende. Konsulentbistand kan tilkøbes som tid og materialer, eller som fastpris aftale efter kundens valg MK Miljøer Der skal etableres følgende miljøer:

32 32 1 Produktionsmiljø Dette miljø anvendes af Kunden til den endelige produktion. Der gælder særlige servicemål for dette miljø. Testmiljø Anvendes til test af nye releases og funktionalitet samt til test af integrationer inden disse sættes i endelig produktion MK Doku- For specielt udviklet software og tekniske 2 mentati- grænseflader som tredjepart kan benytte, on skal der senest to måneder efter overtagelsen være dokumentation til rådighed, der er egnet til videreudvikling (eks. udstillede web-services skal dokumenteres, så en udenforstående udviklingsorganisation på baggrund af dokumentet umiddelbart kan integrere til servicen). Kunden skal have ret til at bruge dokumentationen og selve grænsefladerne MK Løs- Leverandøren leverer en samlet Løsningsbe- 3 ningsbe- skrivelse skrivelse

33 33 8. OPTIONER I alt er der tre optioner i udbuddet. Option 1: Licenser Leverandøren bedes beskrive eventuelle licenser der er forudsætningen for afvikling af SMS-komponenten. ID MK, K Type TITEL Tilbudsgivers besvarelse (Ja/Nej) Beskrivelse Optioner KK Licenser Leverandøren beskriver de licenser som er nødvendige for afvikling af SMSkomponenten. I Bilag 12 prisfastsættes Licenserne. Option 2: Send-status i bookingsystemet (Use-case 5.9) ID MK, K Type TITEL Tilbudsgivers besvarelse (Ja/Nej) Beskrivelse Optioner KK Sendstatus Leverandøren beskriver løsning til usecase 5.9. I bilag 12 beskrives priser på optionen.

34 34 Option 3: Hent send-status (Use-case 5.10) ID MK, K Type TITEL Tilbudsgivers besvarelse (Ja/Nej) Beskrivelse Optioner KK Sendstatus Leverandøren beskriver løsning til usecase 5.10, og beskrivelse til eventuel software. I bilag 12 beskrives priser på optionen.