Rapport: Dokumentation og opsamling af kommunehøring for SAPA kravspecifikation. 20. juni 2013

Transkript

1 Rapport: Dokumentation og opsamling af kommunehøring for SAPA kravspecifikation 20. juni 2013

2 Introduktion En kravspecifikation beskriver indholdet af en it-løsning og indgår i et udbudsmateriale. SAPA-projektet har udarbejdet en kravspecifikation på en ny løsning, som et alternativ til KMD-sag. Kommunerne har haft kravspecifikationen i høring i foråret Denne rapport beskriver forløbet og involveringen af kommunerne i forbindelse med høring af SAPA kravspecifikation og indeholder også en opsamling af kommunernes høringssvar til SAPA kravspecifikationen. Indledningsvis findes et executive summary af den fulde rapport, som følger umiddelbart efter. 2

3 SAPA kravspecifikation Kommunehøring 2013 Executive Summary - Hovedpointer - Væsentligste udeståender - Om processen

4 Hovedpointer (1/2) Hovedpointer fra høring af kravspecifikation: Stort engagement fra 1/3 af landets kommuner. Høj tilfredshed med høringsprocessen. Behov for ekstra kommunikation, der sætter kravspecifikationen i kontekst. Kravspec'ens struktur og metode fungerer tilfredsstillende Hovedfunktionalitet er dækkende specificeret. It-principper, målarkitektur og sikkerhedsmodel er dækkende specificeret. Behov for større opstramninger på disse områder: Rød tråd på tværs af kapitler Begrebs- og informationsmodel Journalmodul SAPA App Shop Behov for beslutninger på disse områder: ESDH-light: In-/out-of-scope? ('Workflow'-moduler) Kontaktdata som støttesystem? Eller data i SAPA? Advis-modul. Generisk komponent eller indlejret i SAPA? 4

5 Hovedpointer (2/2) De fleste kommentarer fra kommunerne faldt i nedenstående emner. De blev dermed temaerne, som blev behandlet dybdegående i grupper på feedbackseminarerne. En gennemgang af de væsentligste pointer findes i den fulde rapport, der følger efter dette summary. Kontekst og aktører Advis Begrebs- og informationsmodel Partskontakt Journal Sag og dokument Sagsarbejde Extra (UC 910 og 911)/ Aarhus løsning Arkitektur Rettigheder/sikkerhed SAPA App Shop 5

6 Vigtigste kendte udeståender (1/3) A) Der mangler en funktionalitetsoversigt: As-is i KMD Sag To-be i SAPA B) Der mangler snitfladeskemaer: Informationerne X, Y og Z Fra it-løsningerne A, B og C Via snitflader til støttesystemerne O, P og Q C) Der mangler en beskrivelse af samspillet med ESDH-løsninger (og fagløsninger) Opret-handlinger fra SAPAs brugergrænseflade Data ned i maven på sagsbærende it-løsninger

7 Vigtigste kendte udeståender (2/3) D) Der mangler en beskrivelse af udviklingsperspektiverne (Roadmap for PLUS) Flere indgange for andre brugere Adgang på tværs af kommuner Adgang via mobile enheder Mere funktionalitet via mini-moduler (SAPA Shop) E) Der mangler en beskrivelse af standardisering contra Virkeligheden Teoretisk: Ingen begrænsninger pga. S&D-standarder Reelt: Hvilke systemer kan levere (hvilke) metadata? F) Der mangler en beskrivelse af samspillet med ATP/UDK Se ydelser Tværgående manuel advisering

8 Vigtigste kendte udeståender (3/3) G) Historik Flyttehistorik Ydelseshistorik H) Overgangsløsning Journalmodul stilles til rådighed i en overgangsperiode I) Støttesystemet Kontaktdata Svært at identificere behov uden for SAPA

9 Overblik over processen for høringen (1/4) SAPA-projektet frigiver kravspecifikation til høring i kommunerne den 22. marts Høringsprocessen kickstartes med tre identiske møder for kommunerne i slutningen af marts Kommunerne har mulighed for at ringe med spørgsmål til SAPA-projektet under hele høringsprocessen. Høringen varer i fire uger fra den 2. april 2013 til den 30. april Høringen afslutter med tre identiske feedbackseminarer i midten af maj SAPA projektet indarbejder relevante høringskommentarer i SAPA kravspecifikation. Alle kommunerne får en separat tilbagemelding på deres høringsvar. Revideret SAPA kravspecifikation kommer ud på KOMBIT s hjemmeside. 9

10 Overblik over processen for høringen (2/4) Kommunal deltagelse: Hvor mange kommuner har været involveret i høringen? På introduktionsmøderne deltog 113 personer fordelt på 66 kommuner. På feedbackseminarerne deltog 55 personer fordelt på 34 kommuner. 39 kommuner, har givet høringssvar på SAPA kravspecifikation. Kommunerne har været meget tilfredse med høringsprocessen (se næste slide) 10

11 Overblik over processen for høringen (3/4) 11

12 Overblik over processen for høringen (4/4) 12

13 Høring af SAPA kravspecifikation Samlet Rapport

14 Høring af SAPA kravspecifikation del I Overblik over forløbet og processen.

15 Overblik over forløbet af høringen SAPA-projektet frigiver kravspecifikation til høring i kommunerne den 22. marts Høringsprocessen kickstartes med tre identiske møder for kommunerne i slutningen af marts Kommunerne har mulighed for at ringe med spørgsmål til SAPA-projektet under hele høringsprocessen. Høringen varer i fire uger fra den 2. april 2013 til den 30. april Høringen afslutter med tre identiske feedbackseminarer i midten af maj SAPA projektet indarbejder relevante høringskommentarer i SAPA kravspecifikation. Alle kommunerne får en separat tilbagemelding på deres høringssvar. Der udarbejdes en høringsrapport, der dokumenterer processen og konklusionerne Revideret SAPA kravspecifikation kommer ud på KOMBIT s hjemmeside. 15

16 Hvordan har SAPA-projektet grebet høringsprocessen an? Projektet har lagt vægt på en åben, gennemsigtig proces og en tæt involvering af kommunerne. Dette for at sikre, at kvaliteten af den endelige SAPA-løsning lever op til kommunernes behov. Som kickstart på høringsprocessen holdt SAPA-projektet tre identiske møder for kommunerne i slutningen af marts På møderne blev kommunerne klædt på til at gennemfører den lokale høring af SAPA s kravspecifikation. For at støtte kommunerne og klæde dem ordentligt på til opgaven med at gennemføre en lokal høring af SAPA kravspecifikation havde projektet til lejligheden udarbejdet : Drejebog for SAPA-høringsproces i kommunerne En video; SAPA overblik på et øjeblik Tre bud på forskellige grafiske brugergrænseflader Tre brugerrejser for anvendelsen af SAPA-løsningen En visionstegning af SAPA-løsningen 16

17 Hvordan har SAPA-projektet grebet høringsprocessen an? Høringen blev afsluttet med tre identiske feedbackseminarer i midten af maj 2013, hvor kommunerne får en tilbagemelding på den samlede høring og en mundtlig dialog om kommunernes høringssvar. Dagen var tilrettelagt med mulighed for dykke ned i de væsentligste områder, som kommunerne havde givet tilbagemeldinger på. Formålet var at komme tættere på en konkretisering af forskellige udeståender gennem afklaring og dialog med kommunerne. SAPA-projektet stillede op med eksperter på flere områder fx inden for sikkerhed, arkitektur, advis, sager & dokumenter, begrebsmodellering mv. På baggrund af de tre feedbackseminarer er der udarbejdet en opsamling af pointer og handlingspunkter. 17

18 Deltagelse: Hvor mange kommuner har været involveret i høringen? På introduktionsmøderne deltog 113 personer fordelt på 66 kommuner. På feedbackseminarerne deltog 55 personer fordelt på 34 kommuner. Der er 39 kommuner, der har givet høringssvar på SAPA kravspecifikation. Kommunerne har været tilfredse med den indsats SAPA-projektet har gjort for at støtte kommunerne i høringsprocessen. 18

19 Kommuner der har afgivet høringssvar 19

20 Hovedstadsregionen 20

21 Feedback fra kommunerne 21

22 Feedback fra kommunerne 22

23 Feedback fra kommunerne 23

24 Høring af SAPA kravspecifikation del II Konklusioner fra høringen

25 Kommunernes tilbagemelding til SAPAprojektet Kommunerne har tilsammen givet mere en 600 kommentarer til SAPA s kravspecifikation. Det er værdifulde og meningsgivende kommentarer. Høringssvarene går ofte på : 1. Uklar kommunikation om scope. 2. Kapitler, afsnit el. emner er beskrevet uskarpt i kravspecifikationen. 3. Uenige i det, der står. Scope er for smalt, for bredt eller forkert. Nummer 1 og 2 bliver der rettet op på i næste version af SAPA kravspecifikation. 25

26 Gruppering af kommunernes høringssvar SAPA-projektet har læst alle høringssvarene igennem og tilbagemeldingerne falder typisk inden for følgende tre grupperinger: 1. Kendte udeståender 2. Fleste kommentarer falder i disse temaer 3. Få kommentarer vedr. disse emner 26

27 Vigtigste kendte udeståender (1/3) A) Der mangler en funktionalitetsoversigt: As-is i KMD Sag To-be i SAPA B) Der mangler snitfladeskemaer: Informationerne X, Y og Z Fra it-løsningerne A, B og C Via snitflader til støttesystemerne O, P og Q C) Der mangler en beskrivelse af samspillet med ESDH-løsninger (og fagløsninger) Opret-handlinger fra SAPAs brugergrænseflade Data ned i maven på sagsbærende it-løsninger

28 Vigtigste kendte udeståender (2/3) D) Der mangler en beskrivelse af udviklingsperspektiverne (Roadmap for PLUS) Flere indgange for andre brugere Adgang på tværs af kommuner Adgang via mobile enheder Mere funktionalitet via mini-moduler (SAPA Shop) E) Der mangler en beskrivelse af standardisering contra Virkeligheden Teoretisk: Ingen begrænsninger pga. S&D-standarder Reelt: Hvilke systemer kan levere (hvilke) metadata? F) Der mangler en beskrivelse af samspillet med ATP/UDK Se ydelser Tværgående manuel advisering

29 Vigtigste kendte udeståender (3/3) G) Historik Flyttehistorik Ydelseshistorik Andre. H) Overgangsløsning Journalmodul stilles til rådighed i en overgangsperiode I) Støttesystemet Kontaktdata Svært at identificere behov uden for SAPA

30 Gruppering af kommunernes høringssvar 1. Kendte udeståender 2. Fleste kommentarer falder i disse temaer 3. Få kommentarer vedr. disse emner 30

31 De fleste svar falder i disse temaer Kontekst og aktører Advis Begrebs- og informationsmodel Partskontakt Journal Sag og dokument Sagsarbejde Extra (UC 910 og 911) Arkitektur Rettigheder/sikkerhed SAPA App Shop Alle temaerne blev behandlet i grupper på feedbackseminarerne og de næste slides opsummerer konklusioner og handlingspunkter for temaerne. 31

32 Kontekst og aktører Pointer fra feedbackseminar Pointe 1: Der mangler prædefinerede kommunale roller. Handling: Ingen. SAPA ønsker ikke at definere for mange faste roller på forhånd. Kommunerne kan selv opsætte roller efter behov. Pointe 2: Der mangler mulighed for flere rolleopsætninger Handling: Ingen. Man kan godt oprette roller i flere niveauer med forskellige roller. Pointe 3: Der mangler mulighed for decentral organisering af aktører. Handling: Ingen. SAPA understøtter en differentiering af aktører. Sikkerheden varetages overordnet set af sikkerhedskomponenten. Pointe 4: Administrator får for frie hænder i decentralt set-up. Handling: Ingen. Det håndteres via rammearkitekturens sikkerheds set-up. Pointe 5: Er der kun én model for opsætning af roller? Handling: Det skal præciseres i SAPA kravspecifikation, at der differentieres fra kommune til kommune. KOMBIT sørger for en mere klar beskrivelse af, at byggeklodserne fleksibelt kan sættes sammen i kommunen. F.eks. med en overadministrator i toppen med én eller flere administratorer nedenunder. Desuden skal der henvises til sikkerhedsdelen i rammearkitekturen, som styrer de mere overordnede elementer. Brugerrettighederne i denne kravspecifikation gælder kun for SAPA; det skal præciseres. 32

33 Advis Pointer fra feedbackseminar I Pointe 1: Slettes advis er med status ubehandlet? Handling: Ingen. Ubehandlede adviser bliver ikke slettet. Pointe 2: Advisering af fiktive brugere (mhp parkering af adviser). Handling: KOMBIT afklarer om det kan lade sige gøre. Det har ikke været med i arbejdet indtil nu, men principielt burde det kunne lade sig gøre. Problem omkring sikkerhed og certifikater skal vurderes. Pointe 3: Mulighed for generel fordeling af advis er og påmindelser via forskellige kanaler (feed, mail mv.). Handling: KOMBIT undersøger muligheden og hvad det vil betyde for sikkerhed og ekstra arbejde vedr. opsætning. Pointe 4: Mulighed for at udstille advis er i andre (fag) systemer Handling: Ingen. Det vil ske efterhånden som disse systemer åbner for muligheden. Pointe 5: Hvad med hændelsestyper? Handling: KOMBIT beskriver hændelsestyper. 33

34 Advis Pointer fra feedbackseminar II Pointe 6: Fordeling af adviser til modtagere Handling 1: Advisservicen kan sættes op til at fordele adviser til såvel enkeltbrugere som fagområder/hele afdelinger/grupper af adviser, så en afdeling/gruppe af medarbejdere kan modtage adviser på udvalgte KLE numre. KOMBIT beskriver hvordan det kan håndteres sikkerhedsmæssigt. Det er en lokal opsætning hvor balancen skal vurderes. Pointe 7: Mulighed for advis er på sager Handling: Ingen. Det er i første omgang kun præsentation der er i fokus i SAPA. Pointe 8: Mulighed for at se/udveksle adviser fra UDK Handling: KOMBIT afventer UDK beslutning om valg af system. Bemærkning: Beskedfordeleren åbner op for muligheder for at kombinere to fordelere. Pointe 9: Mulighed for adresseadvis Handling: KOMBIT afklarer behovet for muligheden. 34

35 Advis Pointer fra feedbackseminar III Pointe 10: Et advis kan godt gå til flere modtagere. Handling: Ingen, jvf Pointe 6. Pointe 11: Det er ikke muligt at lave sammensatte adviser til komplekse mønstre, f.eks. til kontrolgruppen Handling: Ingen. Bemærkning: Bagvedliggende hændelser gemmes ikke. Pointe 12: Kommunerne udarbejder selv politiker for reaktioner på advistyper Handling: KOMBIT kommunikerer, at det er en kommuneopgave og ikke en fælleskommunal SAPA opgave (f.eks. via drejebog for monopolbrud). Pointe 13: Sikkerhedsmodel skal sikre, at man kun får adviser man har ret til at se. Handling: Ingen, det understøtter sikkerhedsmodellen allerede Pointe 14: Bedre formulering (evt. visualisering) af hændelser versus adviser. Handling: KOMBIT indarbejder en bedre beskrivelse og formulering i SAPA kravspecifikation af hændelser versus adviser. 35

36 Begrebs- og informationsmodel Pointer fra feedbackseminar Pointe 1: Begreber og ord skal ensrettes i kravspecifikationen. Handling: KOMBIT beslutter hvilke ord og begreber der skal anvendes, hvor der er tvivl. Der udarbejdes skema over disse ord, og hvad de endeligt skal hedde. Derefter søg og erstat. Pointe 2: Der skal være en ordforklaring. Handling: KOMBIT tager stilling til hvad centrale ord, og ord der ikke giver sig selv betyder. Der bygges videre på eksisterende ordliste. Pointe 3: Abstract over den samlede begrebs- og informationsmodel. Handling: KOMBIT udarbejder et abstract over den samlede begrebs- og informationsmodel. Pointe 4: Begrebsmodellen: der er tæt koordinering med begrebsmodellerne der er relateret til SAPA i den udstrækning det er nødvendigt. Handling: Ingen. 36

37 Partskontakt Pointer fra feedbackseminar I Pointe 1: Partskontaktbegrebet skal udover CPR muligvis rumme CVR og BBR. Begrebsmodellen for partskontakt udvides i så fald også med CVR og BBR. Handling: Ingen. Man kan lave opslag på CVR og BBR. Pointe 2: Kontaktdata indeholder kun oplysninger om hvordan man tager kontakt til borgeren (og muligvis virksomheden og ejendommen/lejemålet). Kontaktdata kan enten fås via CPR-registret (CVR og BBR) eller på anden vis (fx mobilnummer og adresse). Handling: KOMBIT afklarer og bliver helt skarp på hvilke kontaktdata, der ikke kan fås via cpr (CVR, BBR), og om der er behov for andre tværgående kontaktdata. Det skal også afklares hvad vi kan få fra borger.dk og fra virk.dk. Spørgsmål: For eksempel kan kontaktoplysningen værge trækkes fra CPR ligesom muligheden for at registrere en anden kontaktadresse end folkeregisteradresse. Men hvad med plejeældre adresse hvor kommer de fra? Pointe 3: I SAPA kravspecifikation er kontaktdata blandet sammen med særlige oplysninger om borgeren (fx at borgeren er voldelig). De to behov for oplysninger skal være separate. Handling: KOMBIT får skilt partskontaktbegrebet til at være eet om kontaktdata og et om særlige oplysninger om borgeren. Bemærkning: I dag skriver sagsbehandleren særlige oplysninger i et bemærkningsfelt. 37

38 Partskontakt Pointer fra feedbackseminar II Pointe 4: Kontaktdata der kun vedrører en specifik sag, skal registreres i det tilhørende fagsystem. Handling: KOMBIT afklarer om der skal et krav i transitionsarkitekturen vedr. registrering af sagsspecifikke kontaktdata. Pointe 5: Man kan i SAPA se mindst de samme kontaktdata som i dag. Handling: KOMBIT dobbelttjekker, at der er stillet de rigtige krav til dette. Pointe 6: Man får i SAPA muligheden for at registrere særlige oplysninger om borgeren på lige vis som i dag. Handling: KOMBIT dobbelttjekker, at der er stillet de rigtige krav til dette. Bemærkning: Det er op til kommunerne selv at administrere særlige oplysninger om borgeren ifht. Persondataloven. Fritekst feltet skal både kunne være helt frit og med drop-down, så kan kommunen vælge den variant de ønsker. Pointe 7: Der er behov for at KOMBIT udarbejder en masterdatamanagementstrategi, der beskriver hvilke datakilder der er de autoritative mht. hver enkelt datatype og hvordan data flyder mellem systemer. Handling: KOMBIT igangsætter dette. Spørgsmål: Kan de autoritative kilder være forskellige afhængigt af hvilken medarbejderrolle, man er logget ind med? 38

39 Partskontakt Pointer fra feedbackseminar III Pointe 8: Der er kommet ønsker om datofelter, logning, gyldighedsfelter og pop-op advarsler. Der er ikke taget stilling til, om der skal stilles krav til dette. Handling: Afklares Bemærkning: Der skal være et dato og sagsbehandler stempel på bemærkningsfeltet. Logning på feltet vil øge troværdigheden af oplysninger. Det skal fungere som pop-up, så man kan se, at en person f.eks. kan være voldelig. Voldlige o.lign. skal muligvis ikke være i fritekst felt, da det kan drukne i tekst. Opdatering/ændring i de særlige oplysninger om borgerne kan ske via påmindelse/advis til sagsbehandler, der har oprettet bemærkningen. KOMBIT tager stilling til om det skal med under advis. Pointe 9: Der er kommet ønsker om konfigurérbarhed af det felt der viser hvilken borger man har fat i (pendant til KMD-sag bjælken ), samt hvilke kontaktdata man ser på forsiden af SAPA. Der er ikke taget stilling til, om der skal stilles krav til dette. Handling: Afklares. Bemærkning: Feedback fra seminarerne er, at der generelt er tilfredshed med de kontaktdata man kan se i dag. 39

40 Partskontakt Pointer fra feedbackseminar Pointe 10: Det er under afklaring hvor kontaktdata IV (der ikke er cpr/cvr/bbr) samt særlig information gemmes. Handling: KOMBIT er i færd med at udarbejde business case for et støttesystem Kontaktdata, der evt. kan opbevare disse data. Bemærkning: Siden de afholdte feedbackseminarer er det besluttet at der ikke bliver udarbejdet et særligt SAPA støttesystem til kontaktdata. Der er bred opbakning til at anvende de anerkendte offentlige registre, og det er også i tråd med digitaliseringsstrategier, der bliver udarbejdet i mange kommuner Pointe 11: Vi har diskuteret historik, der er en problematik der ikke er beskrevet i SAPA kravspecifikation. Der kommer historik på adresse i SAPA. Handling: Afklares Pointe 12: Oplysningen om at en person er indlagt, kommer som et advis sagsbehandleren abonnerer på. Handling: Ingen. Det er i scope og under afklaring med Regionerne/MedCom. Pointe 13: Situationsbestemte kontaktdata Handling: KOMBIT afklarer hvordan situationsbestemte kontaktdata skal håndteres (og om det kan håndteres i medarbejderrolle). Pointe 14: Kontaktdata er med fra første version af SAPA. Handling: Ingen 40

41 Journalen Pointer fra feedbackseminar I Pointe 1: I en overgangsperiode vil der være mulighed for at gemme journalnotater i en interimskomponent, men på længere sigt skal kommunerne sikre sig, at den pågældende journalfunktionalitet findes i ESDH eller fagsystem. Handling 1: KOMBIT udarbejder notat til kommunerne som beskriver hvorledes journalnotater kan håndteres i en interimsperiode. Handling 2: KOMBIT udarbejder notat for indfasning af SAPA til kommuner/områder som i dag ikke har (adgang) til et journalmodul. Pointe 2: Udveksling af journalnotater mellem fagsystemer og indeks Bemærkning: Det blev fremhævet, at der i SAPA-regi er blevet udarbejdet en begrebsmodel for journalnotat, som kommunerne kan skele til, når de skal kravsætte deres fagløsninger. På længere sigt arbejdes der på at få ophøjet begrebsmodellen til offentlig standard. Pointe 3: Udveksling af journalnotater mellem fagsystemer og indeks: Så længe leverandøren kan levere og modtage data fra indekset, som overholder begebsmodellen, så kan det i brugergrænsefladen udstilles på præcis den måde som fagsystemet ønsker. Handling 1: KOMBIT skriver indstilling til KL og Digitaliseringsstyrelsen om ophøjelse af begrebsmodel til OIO-standard. Handling 2: KOMBIT publicerer snitfladebeskrivelser til støttesystemerne. 41

42 Journalen Pointer fra feedbackseminar II Pointe 4: Journalen i SAPA er ikke tænkt på samme måde som KMD-sag journalen fungerer på, men selvfølgelig vil der være en journal. SAPA journalen er tænkt bredere og kan dække flere systemer end journalen i KMD Sag. Den sammensættes altid ad hoc, hvilket betyder at visningen af journalen i SAPA er betinget af den konkrete udsøgning som foretages. Handling: KOMBIT udarbejder notat som præciserer begrebet Journalen 42

43 Dokument Pointer fra feedbackseminar I Pointe 1: SAPA holder ikke tilknyttede dokumenter. I dokumentindekset ligger der kun metadata om dokumenter. Det betyder, at hvis en kommune eller et område ikke allerede har en dokumentløsning (ESDH, fagsystem, dokumentsilo el.lign), så skal de anskaffe en sådan. Handling: KOMBIT udarbejder business case for et udbud på en fælleskommunal dokumentsilo-løsning. Pointe 2: Redegørelse for styring af licenser til kildesystemerne ift. hop til dokument. Handling: KOMBIT udarbejder notat, som redegør for hvorledes problematikken angående licensstyring i forbindelse ved hop til ESDH- eller fagsystem kan håndteres. Bemærkning 1: Hvis en bruger ikke har licens til det bagvedliggende system, kan det ikke lade sig gøre at foretage hoppet. Der skal muligvis skal foretages hop til flere forskellige systemer, hvis man ikke er helt sikker på hvilket dokument man leder efter. Bemærkning 2: At man ikke kan se selve indholdet af et dokument er fremhævet som en svaghed ved SAPA, hvorfor det også blev foreslået, at der er mulighed for at tilknytte en central (på kommuneniveau) dokumentsilo til løsningen. 43

44 Dokument Pointer fra feedbackseminar II Pointe 3: SAPA løsningen overholder gældende lovgivning vedr. visning af sager og dokumenter. Handling: KOMBIT udarbejder et notat som redegør for lovligheden af aggregering af sagsdata på tværs af datakilder. Bemærkning: KOMBIT har været i dialog med Datatilsynet, og der er udarbejdet modeller for hvorledes datavisninger håndteres via tildeling af roller og rettigheder mm. 44

45 Sagsarbejde extra Pointer fra feedbackseminar II Pointe 1: Use cases uc 910 og 911 generel enighed om at denne funktionalitet i stedet kunne ligge i et dertilhørende ESDH- eller fagsystem. Handling: KOMBIT afklarer hvorvidt de to usecases skal medtages i SAPA kravspecifikationen. Bemærkning: En sådan funktionalitet vil også ville kunne implementeres via SAPA app shop og dermed knyttes til SAPA-løsningen på længere sigt. Pointe 2: Kravoverblik i SAPA. Samlet overblik over økonomiske udeståender som en borger eller virksomhed måtte have med en kommune. Handling 1: KOMBIT afklarer hvorvidt kravoverblik skal medtages i SAPA kravspecifikationen. Handling 2: Handling: KOMBIT afklarer hvor vidt kravsoverblik skal skrives ind i kravspecifikationen som option. 45

46 Arkitektur Pointer fra feedbackseminar I Pointe 1: Rammearkitektur er en forudsætning for SAPA og SAPA realiserer to elementer af rammearkitekturen; partsoverblik og sagsoverblik Handling: Kombit forbedrer beskrivelsen af sammenhængen mellem SAPA og rammearkitekturen og hvordan SAPA indgår i en kontekst med andet end støttesystemer og fælleskommunale systemer. Pointe 2: SAPA læser kun data fra Støttesystemer, så data der ligger udenfor Støttesystemer skal konverteres/migreres hvis de skal være tilgængelige i SAPA efter go-live. Handling: KOMBIT udarbejder udrulningsstrategi, der tager højde for konvertering/migrering. Pointe 3: Rammearkitekturen og dermed SAPA læner sig op ad fælles standarder, eks. OIO. Der hersker meget berettiget usikkerhed om fremtiden for vedligehold af OIO, hvilket KOMBIT og KL er opmærksomme på. Handling: Det skal afklares hvem der løfter drift og vedligehold af OIO standarder. Det anbefales at KL løfter den opgave, og kommunerne bør opfordre KL til at gøre det. Bemærkning: KL arbejder på at få ansvaret for OIO eller få det forankret andetsteds. Det kommunale arkitekturråd er også opmærksom på problemstillingen og at OIO standarderne er guld værd for kommunerne, så vi tror på en løsning. 46

47 Arkitektur Pointer fra feedbackseminar II Pointe 4: Vigtigheden af Open Source: Porterbarheden og TCO må være det vigtigste. Om det er open eller closed source er sekundært. Handling: Ingen Bemærkning: KOMBIT har fået Accenture til at lave en teknologianalyse over de teknologier der kunne tænkes anvendt i tilbud, og ud af de 14 undersøgte var blot 4 open source. Ved at stresse krav om open source for meget, formindsker vi det potentielle antal bydere, og det vurderes som uhensigtsmæssigt. KOMBIT vil dog gerne skrue opfordringen til open source lidt op. Accenture vurderingen gik på teknologimodenhed og fremtid, TCO ud fra forskellige anvendermodeller og antal potentielle leverandører ved genudbud. Rapporten vil blive brugt i vurdering af tilbud. 47

48 Sikkerhed Pointer fra feedbackseminar I Pointe 1: Udarbejdelse af specifik standardvejledning/anbefalinger til kommunerne om design af roller. Handling: KOMBIT kommer med et bud på en vejledning. Det vurderes, at vejledningen bør være ret generisk, da der er forskellige behov og måder at gribe det an på i de forskellige kommuner. Pointe 2: Der er behov for en model, hvor kommuner selv kan vedligeholde deres medarbejdere samt de roller, som brugeren eller grupper af brugere besidder i SAPA. Handling: Ingen. Det er understøttet i KOMBIT s kommende sikkerhedsmodel. Pointe 3: Lovgivning vs. sikkerhed og mulighed for at se sager på tværs af kommuner. Handling: Ingen. Alt hvad der ligger i de fælleskommunale systemer er i princippet tilgængeligt for SAPA. Det er sikkerhed og lovgivning, der styrer hvad hver især må se. Kommunerne kan derfor sagtens se sager på tværs, hvis lovgivningen sikrer det. Pointe 4: API-understøttet adgang til administrative snitflader. Handling: Ingen. Der er to måder at tilgå sikkerhedsmodellen i rammearkitekturen. Enten via et modul udviklet af KOMBIT eller via services/api udstillet af sikkerhedsløsningen i KOMBIT. 48

49 Sikkerhed Pointer fra feedbackseminar II Pointe 5: Løsningen skal spørge på medarbejdersignaturer, om de er udløbet eller revokeret. Handling: Ingen. Sikkerhedsløsningen spørger ved login om signatur er udløbet eller revokeret, men hvis personen er logget på, kan det i nogle tilfælde først ske ved udløb af session eller ved relogin. Pointe 6: AD integration via ADFS. Handling: Ingen. Der er ikke ændret noget i forhold til den normale single sign-on til de kommunale systemer. Pointe 7: Sker sletning af log systemautomatisk eller manuelt? Handling: Ingen. Der sker en maskinel sletning baseret på regler for hvor længe de skal bevares. Pointe 8: Logning skal ske på såvel bruger- som sags-niveau således at der kan udsøges log på hvor den enkelte bruger har været inde, men også hvilke brugere, der har været inde på en specifik sag. Handling: Ingen. Løsningen sikrer, at der er fuldt transitionsspor i logningen. 49

50 SAPA App Shop Pointer fra feedbackseminar Pointe 1: Der mangler klarhed over hvad SAPA App shop er. Handling: KOMBIT udarbejder et notat som redegør for dette. Pointe 2: Der mangler klarhed over forretningsmodellen og governance Handling: KOMBIT udarbejder et notat som redegør for dette. Pointe 3: Man kan overveje hvorvidt App Shop skal udsondres fra resten af SAPA-løsningen, og være sin helt egen Handling: Ingen. App Shop funktionalitet er standardfunktionalitet i de relevante løsningsteknologier. 50

51 Gruppering af kommunernes høringssvar 1. Kendte udeståender 2. Fleste kommentarer falder i disse temaer 3. Få kommentarer vedr. disse emner 51

52 Få kommentarer til flg. emner SAPA Version 1.0 vs. SAPA PLUS Hvilke informationer? Og hvordan? Hvilke funktioner? Og hvor længe? Ingen data i SAPA? Synkronisering / Parallel drift Drift Ledelsesinformation Borger.dk / Virk.dk

53 Hovedpointer fra høring af kravspecifikation: Stort engagement fra 1/3 af landets kommuner. Høj tilfredshed med høringsprocessen. Behov for ekstra kommunikation, der sætter kravspecifikationen i kontekst. Kravspec'ens struktur og metode fungerer tilfredsstillende Hovedfunktionalitet er dækkende specificeret. It-principper, målarkitektur og sikkerhedsmodel er dækkende specificeret. Behov for større opstramninger på disse områder: Rød tråd på tværs af kapitler Begrebs- og informationsmodel Journalmodul SAPA App Shop Behov for beslutninger på disse områder: ESDH-light: In-/out-of-scope? ('Workflow'-moduler) Kontaktdata som støttesystem? Eller data i SAPA? Advis-modul. Generisk komponent eller indlejret i SAPA? 53

54 Næste skridt: Tilbagemelding og revidering af SAPA kravspecificering SAPA-projektet indarbejder relevante høringskommentarer i SAPA kravspecifikationen. Alle kommuner, der har afgivet høringssvar får en tilbagemelding på mail. Udestående emner, som er særligt udfordrende, er vendt med SAPA s kommuneprojektgruppe. En revideret version af SAPA kravspecifikation kommer ud på KOMBIT s hjemmeside. 54