|
1 | 181 | Federation | Federeringen, när det gäller SAML2, bör ansluta mot den federerande partnerns metadata och läsas av samt uppdateras med automatik vid förändringar. Redovisa hur detta går till. | Ja | Ja | Ja | Nej |
2 | 180 | Digital post | Säljarens verksamhetssystem bör tillhanda funktioner för att via DIGG:s infrastruktur för digital post, Mina meddelanden, förmedla avsändarens (kommunens) meddelanden/brev till rätt brevlåda. Säljaren och deras verksamhetssystem tillhandahåller nödvändig funktionalitet för att leverera digital post via Mina meddelanden till rätt brevlåda. | Ja | Ja | Ja | Nej |
3 | 179 | Digital post | Säljarens verksamhetssystem bör tillhanda funktioner för att via DIGG:s infrastruktur för digital post, Mina meddelanden, förmedla avsändarens (kommunens) meddelanden/brev till rätt brevlåda. Verksamhetssystemet bör kunna leverera en utskriftsfil med erforderliga uppgifter för mottagaren och det egentliga brevet enligt av köparens angivet format, se bilaga x. | Ja | Ja | Ja | Nej |
4 | 178 | Integrationer | Umeå kommun har för avsikt att bygga egna e-tjänster enligt vår e-servicestrategi. På förfrågan från köparen ska leverantören, där det finns tillgängliga API:er, från identifierade delområden/processer, ge tillgång till API:er för att möjliggöra köparen att bygga egna e-tjänster. | Ja | Ja | Nej | Ja |
5 | 177 | Automation | Umeå kommun har som ambition att under avtalstiden, så långt det är möjligt automatisera manuella ärendeflöden i systemet. I vissa fall är vår enda möjlighet att använda RPA automation. På förfrågan från köparen ska leverantören, vara behjälplig i köparens arbete med RPA automation. | Ja | Ja | Nej | Ja |
6 | 176 | Dokumentation | Det bör finnas en teknisk beskrivning av systemets integrationsmöjligheter som helst bör vara i en öppen form, exempelvis en Swagger enligt standarden OpenAPI.
Bifoga den tekniska beskrivningen. | Ja | Ja | Ja | Nej |
7 | 175 | Backup | Backup ska ske minst en gång per dygn. Backup ska normalt ske nattetid. | Nej | Ja | Nej | Ja |
8 | 174 | Mobil användbarhet | Köparen har som ambition att under avtalstiden, så långt det är möjligt erbjuda våra kunder (leverantörer/föräldrar/brukare/patient och/patientföreträdare/mm) att arbeta mobilt på andra sätt än via användarvänliga appar (ex. via responsiv webbsida designad för handhållna enheter).
Det bör vara möjligt att skapa, läsa, uppdatera, radera information i systemets användardialoger (ärendeflöden formulär mm) där kunden kan tillåtas behörigheter. Vi vill alltså att relevanta delar av verksamhetsprocessen som utförs via användargränssnitt på stationär dator med tangentbord, ska gå att genomföra på handhållen enhet med pekskärm (mobile first). Vi vill också att kunden (brukaren mm) själv är huvudaktör i alla processer som inte kräver engagemang (beslut behörighet) av köparens tjänstepersoner, i syfte att minska vår egen administrativa börda. Beskriv hur börkravet uppfylls för de delar av systemet som är riktade mot kommunens kunder. | Ja | Ja | Ja | Nej |
9 | 173 | Mobil användbarhet | Köparen har som ambition att under avtalstiden, så långt det är möjligt erbjuda våra egna användare att arbeta mobilt på andra sätt än via användarvänliga appar (ex. via responsiv webbsida designad för handhållna enheter).
Det bör vara möjligt att skapa, läsa, uppdatera, radera information i systemets användardialoger (ärendeflöden formulär mm). Vi vill alltså att relevanta delar av verksamhetsprocessen som utförs via användargränssnitt på stationär dator med tangentbord, ska gå att genomföra på handhållen enhet med pekskärm (mobile first). Beskriv hur börkravet uppfylls för de delar av systemet som är riktade mot köparens tjänstepersoner. | Ja | Ja | Ja | Nej |
10 | 172 | Integrationer | Säljaren ska bistå köparen vid implementation av aktuella och framtida RPA robotar inklusive acceptanstest om köparen så begär. Redogör för hur er samverkansprocess ser ut i samband med etablering av befintliga och framtida RPA robotar samt ekonomisk modell för denna samverkan. | Ja | Ja | Nej | Ja |
11 | 171 | Integrationer | Säljaren ska bistå köparen vid implementation av aktuella och framtida integrationer inklusive acceptanstest om köparen så begär. Redogör för hur er samverkansprocess ser ut i samband med etablering av befintliga och framtida integrationer. | Ja | Ja | Nej | Ja |
12 | 166 | 3D | Köparen ska ha nyttjande- och äganderätt till det 3D-data som skapats i säljarens lösning för användande i sin övriga verksamhet. | Ja | Ja | Nej | Ja |
13 | 165 | 3D | Säljarens lösning ska klara av att exportera de 3D-modeller som framställts i formatet Collada (.dae ) | Ja | Ja | Nej | Ja |
14 | 164 | Ruttoptimering | Säljarens lösning bör möjliggöra för utföraren, när denne är i fält, baserat på omedelbara uppkomna händelser (ex punktering, egensjukdom, trafiksituation, hittar ej parkering, avbokning av stoppet med kort varsel), att kunna justera sin individuella planering och därmed initiera en ny ruttoptimering som gäller för den aktuella utföraren (och som visas på den aktuella utförarens enhet). Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
15 | 163 | Ruttoptimering | Säljarens lösning bör vid en justering av den övergripande planeringen enligt ovan, klara av att räkna om rutten enbart baserat på den gjorda justeringen i syfte att minska beräkningstiden för ny rutt. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
16 | 162 | Ruttoptimering | Den övergripande strategiska planeringen, gällande tidsfönster för utförarens raster (lunch, kaffe, vilotider, dygnsvila, veckovila mm), i säljarens lösning bör gå att justera och räknas om med kort varsel ex. i början av ett arbetspass och för en avgränsad period (ex. idag på förmiddagen) utan att behöva göra om den övergripande strategiska planeringen i sin helhet. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
17 | 161 | Ruttoptimering | Säljarens lösning bör inkludera strategisk planering där tidsfönster för utförarens raster (lunch, kaffe, vilotider, dygnsvila, veckovila mm) markeras på ett övergripande sätt för valfri kalenderperiod. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
18 | 160 | Ruttoptimering | Säljarens lösning bör klara av att ta hänsyn till servicetid (hanteringstid, tid på plats, osv), exempelvis att stoppet följs direkt av en tid som utföraren behöver befinna sig på den platsen innan rutten kan fortsätta. Redovisa hur börkravet uppfylls | Ja | Ja | Ja | Nej |
19 | 159 | Ruttoptimering | Säljarens lösning bör klara av att ta hänsyn till en eller flera tidsfönster i rutten, exempelvis att stoppet/avlämningspunkten (kunden, brukaren, porten) endast är på plats/öppen vissa specifika tider. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
20 | 158 | Ruttoptimering | Säljarens lösning bör i samband med ruttoptimering klara av att inkludera/ variera fordonstyper i den planerade rutten, så kallad "Park and loop" (ex. först bil sedan cykel se. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
21 | 157 | Kartdata och bakgrundskartor | I händelse av att säljarens lösning av någon anledning inte kan koppla upp sig mot ”Umeå kommuns karttjänster” ska säljaren redovisa aktuell källa för kartdata på begäran av köparen. | Ja | Ja | Nej | Ja |
22 | 156 | Kartdata och bakgrundskartor | Säljarens lösning bör använda sig av Umeå kommuns karttjänster för att nyttja t ex populärnamn och annan geografisk data som köparen tillhandahåller och som endast finns tillgängligt hos köparen | Ja | Ja | Ja | Nej |
23 | 155 | Kartdata och bakgrundskartor | Säljarens lösning ska följa svensk standard för hur adress beskrivs.
Belägenhetsadress: SS 637003:2015 Postaladress: ISO 19160-4:2017 | Ja | Ja | Nej | Ja |
24 | 154 | Kartdata och bakgrundskartor | Säljarens lösning bör använda svenska nationella geostandarder för hur data/information lagras, sorteras och beskrivs. Redovisa hur börkravet uppfylls | Ja | Ja | Ja | Nej |
25 | 153 | Kartdata och bakgrundskartor | Om säljarens lösning inte hanterar Sweref 99 20 15 eller Sweref 99 TM bör säljarens lösning hantera WGS84. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
26 | 152 | Kartdata och bakgrundskartor | Om säljarens lösning inte hanterar Sweref 99 20 15 bör säljarens lösning hantera Sweref 99 TM. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
27 | 151 | Kartdata och bakgrundskartor | Köparen använder koordinatsystemet Sweref 99 20 15 i den kartdata som produceras och lagras hos köparen. Säljarens lösning bör hantera Sweref 99 20 15 . Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
28 | 150 | Kartdata och bakgrundskartor | Säljarens lösning bör använda API eller WFS enligt senaste versionen av OGC-standard för att kunna tillhandahålla kartdata till köparens karttjänster eller andra system. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
29 | 149 | Kartdata och bakgrundskartor | Säljarens lösning bör använda WMTS eller WFS enligt senaste versionen av OGC-standard för att kunna visa och nyttja kartdata. Redovisa hur börkravet uppfylls. | Ja | Ja | Ja | Nej |
30 | 148 | Överläsning till e-arkiv | Handlingar/dokumentation och kontexten ska fortlöpande (och vid valfri tidpunkt) kunna exporteras (till e-arkiv/mellanarkiv) ur det IT-system som säljaren levererar enligt befintlig teknisk kravspecifikation från köparen. | Ja | Ja | Nej | Ja |
31 | 147 | Överläsning till e-arkiv | Säljaren ska läsa in handlingar och dokumentation från köparens e-arkiv eller mellanarkiv enligt befintlig teknisk kravspecifikation i samband med att det gamla systemet (som ersätts av det nya från säljaren) avvecklas. | Ja | Ja | Nej | Ja |
32 | 146 | Utskrifter | Utskrifter bör fungera med köparens ordinarie skrivardrivrutiner, som använder PCL. Beskriv hur detta görs. | Ja | Ja | Ja | Nej |
33 | 145 | Drift och testmiljö | Säljarens lösning ska använda Windows standard för utskrifter kopplad till inloggad användare. | Ja | Ja | Nej | Ja |
34 | 144 | Drift och testmiljö | Information (data) som säljarens lösning lagrar i SQL-databaser ska använda (fungera med) Microsoft SQL Server 2017 eller senare som databasmotor | Ja | Nej | Nej | Ja |
35 | 143 | Drift och testmiljö | Redovisa för vilken plattform som ingående delar i säljarens lösning är kompilerade. | Ja | Nej | Nej | Ja |
36 | 142 | Drift och testmiljö | Serverdelen av säljarens lösning ska vara kompilerat och körbart för / på x64 plattformar | Ja | Nej | Nej | Ja |
37 | 141 | Drift och testmiljö | Redovisa vilka prestandakrav som säljarens lösning ställer på köparens datacenter. | Ja | Nej | Nej | Ja |
38 | 140 | Drift och testmiljö | Säljarens lösning ska klara av att exekvera i en virtualiseringsmotor (hypervisor VMware vSphere 6.5) | Ja | Nej | Nej | Ja |
39 | 139 | Klientplattform | Säljarens lösning ska fungera med köparens nuvarande antivirusmiljö, f n Windows Defender och Cylance Protect. | Ja | Ja | Nej | Ja |
40 | 138 | Klientplattform | De delar av säljarens lösning som utnyttjar Microsoft Office ska fungera med senaste versionen av Microsoft Office 365 | Ja | Ja | Nej | Ja |