Læsevejledning til review af støttesystemer, marts 2013

Transkript

1 Læsevejledning til review af støttesystemer, marts 2013 Kommunerne ønsker en fælleskommunal rammearkitektur, der kan understøtte digitaliseringen og åbne for konkurrence på det kommunale it-marked. Rammearkitekturen omfatter dels en fælles forretningsarkitektur med de forretningskrav, der stilles til it-systemer på det kommunale it-marked. Dels omfatter den en række infrastrukturer, der skal lette integrationen mellem it-systemer hos forskellige leverandører på markedet. KL og KOMBIT er nu klar med kravspecifikationer for støttesystemerne i den fælleskommunale rammearkitektur. Støttesystemerne vil blive indkøbt via udbud for hhv. Støttesystemer og SAPA. Som sidste skridt i forberedelsen af udbuddet er der nu behov for, at kommuner og itleverandører kommenterer materialet mhp følgende: Opfylder kravspecifikationerne enkelt og effektivt behovene for at skabe sammenhæng på tværs mellem kommunale it-systemer? Er indholdet af informationer det rette? Vil de eksisterende og fremtidige fagsystemer på det kommunale it-marked kunne levere de informationer ind til støttesystemerne, der foreslås i kravspecifikationerne? Bruger kravspecfikationernes informationsmodeller mv. de fælles offentlige sag- og dokumentstandarder på en hensigtsmæssig måde med henblik på ovenstående? Er kravspecifikationerne i deres form brugbare i en udbudsproces, hvor der skal skabes konkurrence, eller er der ting, der bør forbedres inden et udbud? Deltagerne bedes indskrive kommentarer/rettelser i kravspecifikationerne og afgive skriftlige kommentarer til øvrige dokumenter. Disse sendes til rasts@kombit.dk For støttesystemer, der forventes indkøbt via SAPA, fremlægges foreløbigt scopedokumenter. Kravspecifikationer udarbejdes til et kravspec-review senere på foråret. For alle kravspecifikationer gælder, at der ikke er taget stilling til fordelingen af henholdsvis krav og minimumskrav. Alle krav er derfor angivet som krav, selvom nogle af dem forventes at blive ændret til minimumskrav i det endelige udbudsmateriale. For at fastholde reviewets fokus på de funktionelle krav til støttesystemerne, er en række tværgående non-funktionelle krav, fx om brugervenlighed, ikke skrevet ind i kravspecifikationerne. Succeskriterier for systemerne er heller ikke udfyldt, idet disse skal afklares nærmere i dialog med kommunerne, og gerne gøres målbare ift leverandøren. Dette dokument skal give deltagere i reviewet et overblik over Støttesystemerne. Indholdet af hvert støttesystem beskrives kortfattet og eventuelle strategiske valg fremhæves. 1

2 Generelt om støttesystemerne Dette afsnit giver et overblik over de enkelte støttesystemer der indgår i Rammearkitekturen. For yderligere information henvises til de udarbejdede kravspecifikationer. Støttesystemerne er en del af systemlandskabet i den kommunale rammearkitektur vist nedenfor. Systemerne er vist i figuren nedenfor under Fælleskommunale støttesystemer. Støttesystemerne skal støtte op om fagsystemer idet de opsamler og udstiller information af fælles interesse. Støttesystemerne indeholder således ikke forretningsfunktionalitet men distribuerer data af fælles interesse. For en introduktion til rammearkitekturen generelt henvises til dokumentet Fælleskommunal ramearkitektur, som var det centrale dokument i review september 2012: 2

3 Udrulning af støttesystemerne Rammearkitekturen, og dermed Støttesystemene er jf. økonomiaftalen grundlaget for det aktuelle monopolbrud, og for fælleskommunale systemer generelt. Støttesystemerne forventes udrullet i det kommunale it-landskab i tre etaper, som ikke pt fremgår af det udsendte kravmateriale: 1. Indenfor udviklingskontrakten skal støttesystemerne implementeres i forhold til et eksisterende fælleskommunalt system. Dette er vigtigt for, at støttesystemerne fungerer driftsikkert, når de skal anvendes af nye fælleskommunale systemer, fx Kommunernes Ydelsessystem. Bl.a. overvejes at lade Digital Flytning være dette første system, der integreres som led i udviklingsfasen. I givet fald vil støttesystemerne skulle integrere til Digital flytning, beskedfordeleren skal kunne håndtere beskeder om flytningerne fra CPR, og der skal integreres til de enkeltkommunale systemer, typisk ESDH, der håndterer en eventuel lokal sagsbehandling vedrørende flytninger. Endelig skal Organisation integrere til de enkeltkommunale organisationssystemer, der hvor de findes. 2. I driftfasen vil støttesystemerne blive anvendt af de fælleskommunale systemer, der indgår i et monopolbrud, og af de enkeltkommunale systemer, som disse skal integrere til. Dette omfatter integration til SAPA, TIL Kommunernes Ydelsessystem, til Sygedagpenge, til Ejendomsskat og ejendomsbidrag, m.fl. Derudover vil der skulle integreres til de enkeltkommunale systemer, som skal være synlige for de fælleskommunale eller som gerne vil kunne se, hvad de foretager sig. Dette omfatter ikke blot ESDH-systemer, men også fx jobcentersystemer, omsorgssystemer mv. 3. I driftfasen, når monopolbruddet er kommet godt på vej, vil der blive åbnet for, at de fælleskommunale støttesystemer kan anvendes til lokale behov af de kommuner, som måtte ønske det. Økonomiaftalen forudsætter alene, at rammearkitekturen anvendes til fælleskommunale behov, men Arkitekturrådet har bedt om, at der ligeledes blev åbnet for lokale anvendelser af støttesystemerne. KOMBIT har lagt vægt på, at støttesystemerne driftmæssigt først var bragt til at fungere i forhold til de fælleskommunale behov, før der blev åbnet for de enkeltkommunale. 3

4 Beskrivelse af hvert Støttesystem Organisation Støttesystemet Organisation skal sikre, at fælleskommunale it-systemer fra ét samlet støttesystem kan få fat på hver enkelt kommunes organisation med hensyn til fagsystemets virkefelt. Sammen med Klassifikation skal oplysningerne i Organisation danne udgangspunkt for den sagsfordeling, der foregår i fagsystemerne. I praksis ved i Organisation at tilknytte gyldige værdier fra Klassifikation (hvem er vi og hvad må vi). Organisation skal altså modtage organisatoriske oplysninger fra kommunerne på de områder, hvor der findes fælleskommunale it-systemer, og gøre dem tilgængelige for relevante fagsystemer, så de kan sagsfordele mv. Kommunerne skal kunne aflevere oplysningerne enten via manuel indtastning eller via automatisk synkronisering system-til-system, fx fra kommunens lokale Organisationssystemer. Udgangspunktet for indholdet af Organisation er specifikationerne i OIO standarden, udvidet med de behov og begrænsninger, som er udtrykt fra fagsystemerne. Klassifikation Støttesystemet Klassifikation gør det derfor muligt at udstille og vedligeholde en række klassifikationssystemer, så disse kan bruges af fælleskommunale it-systemer til opmærkning af information. Klassifikationssystemer er et centralt bindeled i rammearkitekturen fx skal stort set alt hvad itsystemer lægger i eller læser fra de øvrige støttesystemer opmærkes med klassifikationer. Bl.a. skal fagsystemer, der har en sag, også fortælle Sags- og Dokumentindeks, hvilken type af sag, der er tale om. Det er derfor en forudsætning for, at it-systemer kan bruge støttesystemerne, at de anvender de fælles klassifikationer. Ved idriftsættelsen er planen, at Klassifikation som minimum skal udstille den fælles kommunale opgaveklassifikation KLE [KLE], den fællesoffentlige FORM [FORM], samt Økonomi og Indenrigsministeriets kontoplan. KLE er afgørende for, at it-løsninger kan identificere opgavetyper og dermed udveksle information om opgaver tværs af kommuner og systemer, bl.a. via støttesystemer. Kommunerne skal kunne lægge deres egne klassifikationssystemer ind i støttesystemet Klassifikation - fx egne kontoplaner, hvor kommunerne skal kunne vedligeholde mapninger til Økonomi- og Indenrigsministeriets kontoplan. Udgangspunktet for indholdet af Klassifikation er specifikationerne i OIO standarden [OIOKLFUN], med nogle få specificerede udvidelser. 4

5 Sags- og Dokumentindeks Sags- og Dokumentindeks skal gøre det muligt for it-systemer at se oplysninger om sager eller dokumenter i andre it-systemer uden at skulle kalde disse andre it-systemer direkte. Systemet skal kunne modtage oplysninger (metadata) om sager og dokumenter fra fagsystemerne, og fagsystemerne skal desuden kunne hente oplysninger (metadata) i systemet om, hvilke sager og dokumenter andre fagsystemer har. Sags- og Dokumentindeks bidrager til, at fagsystemerne herunder ESDH - kan få overblik over borgere og virksomheders forhold, når fx en henvendelse til kommunen måske skal indplaceres på en eksisterende sag, eller når eksistensen af en sag har betydning for behandlingen af andre sager. Systemet er helt afgørende for, at det fælleskommunale SAPA-system kan etableres, idet SAPA skal give overblik over borgerens sager helt på tværs af systemer. Udgangspunktet for indholdet af Sags- og Dokumentindeks er specifikationerne i OIO standarden [OIOKLFUN], med nogle få specificerede udvidelser. Ydelsesindeks Ydelsesindeks skal gøre det muligt for it-systemer at se oplysninger om ydelser i form af bevilinger og bevilgede ydelser i andre it-systemer uden at skulle kalde disse andre it-systemer direkte. Systemet skal kunne modtage oplysninger (metadata) om ydelser fra ydelsessystemerne, og andre it-systemer skal desuden kunne hente oplysninger (metadata) i systemet om, hvilke ydelser disse ydelsessystemer har. Ydelsesindeks bidrager til, at fagsystemerne herunder ESDH - kan få overblik over borgeres og virksomheders ydelser, når fx kommunen får en henvendelse om en eksisterende ydelse, eller når eksistensen af en ydelse har betydning for behandlingen af andre ydelser. Systemet er vigtig for, at det fælleskommunale SAPA-system kan etableres, idet SAPA skal give overblik over borgerens ydelser på tværs af systemer. Udgangspunktet for indholdet af Ydelsesindeks er de behov og begrænsninger, som er udtrykt fra de fælleskommunale fagsystemer, herunder SAPA. 5

6 Beskedfordeler For Beskedfordeler lægges to dokumenter i review dels en kravspecifikation for Beskedfordeler, dels en specifikation af Beskedkuvert. Beskedfordeler modtager oplysninger (beskeder) om hændelser fra fagsystemerne om ændringer i eksempelvis sager eller på personer, og fagsystemerne kan herefter hente oplysninger (beskeder) i systemet om, og derefter opdatere egne sager, hvis det er relevant. Beskedfordeleren vil dermed gøre det muligt for it-systemer at reagere på ændringer i oplysninger i andre it-systemer uden at skulle kalde disse andre it-systemer direkte for at se om der er ændringer. Beskedfordeleren bidrager således til, at fagsystemerne herunder ESDH kan opdatere de oplysninger, som danner grundlag for deres sager, med det samme, når oplysningerne ændrer sig. Systemet er centralt for, at ydelsessystemer kan reagere hurtigt, når grundlaget for at en borger modtager en ydelse, ændrer sig fx ændret indkomst, samlivsforhold, eller rådighed på arbejdsmarkedet. It-systemer, hvori der er sket ændringer (hændelser), vil aflevere beskeder om disse ændringer ind til beskedfordeleren. Beskedfordeleren vil så fordele beskederne til indbakker på beskedfordeleren for den kreds af abonnenter, der abonnerer netop på beskeder om netop denne type af hændelse. De abonnerende systemer får fat i beskederne ved selv at tømme deres indbakke på beskedfordeleren. Beskedfordeleren påtager sig i første omgang ikke funktioner som at push e beskeder ud til modtagerne, eller at håndtere sammenhængende kæder af beskeder. Adgangsstyring For Adgangsstyring lægges to kravspecifikationer i review dels for støttesystemet Adgangsstyring, dels for Administrationsmodul for Adgangsstyring. Desuden udsendes notatet Løsningsmodel for token-baseret adgangskontrol, som beskriver den fødererede sikkerhedsmodel. Støttesystemet Adgangsstyring skal styre adgangen for personbrugere og systembrugere til alle fælleskommunale it-systemer. Adgangsstyringen skal ske via en fødereret sikkerhedsmodel, hvor det fortsat er hver enkelt kommune, der tildeler rettigheder. Adgang i driftsituationen baseres på udstedelse, veksling og præsentation af billetter (security tokens). Det betyder, at brugere af de fælleskommunale it-systemer vil opleve single-signon. For at undgå dobbeltarbejde for kommunen og for at ændringer i kommunen kan slå igennem med det samme, skal brugeradministrationen med oprettelse og nedlæggelse af brugere samt tildeling af jobfunktionsroller ske lokalt i kommunens egen Identity Management løsning - f.eks. i 6

7 Active Directory. Adgangsstyring komponenten Context Handler integrerer til kommunens egen brugeradministrationsløsning, og kan dermed håndhæve adgang for den enkelte bruger. Kommunen skal frit kunne vælge de værktøjer, som kommunen ønsker at administrere brugerne med. Nogle kommuner lader fx deres IDM system mv. føde via et lokalt Organisationssystem, således at organisationsændringer slår igennem i rettighedsstrukturen med det samme. Hver kommune kan i Administrationsmodulet eller deres lokale IdM el. definere de lokale jobfunktionsroller, der understøtter den lokale organisering af arbejdet. Kommunens definerede Jobfunktionsroller kan via Contekst handleren mappes til en eller flere Systemroller, som er defineret fælleskommunalt. Systemrollerne henviser til en række specifikke afgrænsede funktioner i de implementerede it-systemer. Dette muliggør, at leverandørerne kan byde med standardsystemer, hvor interne systemrettigheder grupperes til på forhånd fastlagte Systemroller. Desuden skal Administrationsmodulet administrerede den formelle tilslutning af it-systemer til alle de fælleskommunale infrastrukturer støttesystemer, serviceplatform mv. I driftsituationen skal Adgangsstyring varetage to funktioner. Dels være SAML Identity Provider (Context Handler), som ud fra kommunens oplysninger autentificerer og autoriserer personbrugere der ønsker at tilgå et brugervendt system og således opnå single-signon. Dels agere Security Token Service, som autentificerer og autoriserer systembrugere (Anvendersystemer), der skal foretage et kald til et støttesystem. Kommunen kan også vælge at få brugere på systemerne med Nem-Id da Adgangsstyringen også integrerer til denne. Adgangsstyring giver person- eller systembrugeren en SAML billet (token) med til det fælleskommunale it-system. SAML billetten indeholder kalderens identitet og de systemroller, som kalderen har fået tildelt. For slutbrugere sker dette via kalderens jobfunktionsrolle i kommunen, og for systemer via aftaler indgået i Administrationsmodulet. Det system, der kaldes, behøver altså ikke at vedligeholde kalderens rettigheder, men alene definere de Systemroller der kan tildeles. Sikkerhedsmodellen er baseret på erfaringer fra den fællesoffentlige brugerstyring og fra en række kommuner, der har gennemført fødererede sikkerhedsmodeller. 7

8 Systemer der kravspecificeres via SAPA projektet Partskontakt For understøttelse af processerne Partskontakt lægges et scopedokument i review. Dokumentet uploades til nettet efter påske. Processerne omkring Partskontakt forventes understøttet af en række fysiske systemer, såvel fælleskommunalt som enkeltkommunalt. Med henblik på partskontakt forventes at blive behov for et yderligere støttesystem med arbejdstitlen Kontaktdata, som skal holde oplysninger om kontaktinformationer på parten, med hensyn til forskellige specifikke sagstyper. Andre processer, der indgår i kontakten med en part, understøttes af fagsystemer (herunder ESDH), af SAPA, samt af de øvrige støttesystemer. Kravspecifikation for Kontaktdata udarbejdes på baggrund af reviewet. Indkøb forventes som led i SAPA projektet, og vil ikke indgå i udbuddet af de øvrige støttesystemer. Overgangssystemer med henblik på udfasning af KMD Sag I reviewet indgår udover støttesystemerne også to Overgangssystemer, som kun er nødvendige med henblik på at muliggøre en udfasning af monopolsystemer, herunder navnlig KMD Sag, men som ikke forventes at spille en permanent rolle som støttesystemer. Der forelægges scopedokumenter for overgangssystemerne, og de uploades til nettet efter påske. Advis KMD sag tilbyder i dag en række muligheder for, at sagsbehandlere kan opsætte advisregler, så de får påmindelser om, hvornår de aktivt skal foretage manuelle sagsskridt. Sådanne funktioner forventes i fremtiden at blive håndteret af de relevante fagsystemer, herunder ESDH. Advis-funktionalitet skal derfor ikke etableres som et nyt fælleskommunalt støttesystem, men som et overgangssystem, der muliggør udfasning af KMD Sag. Sagsfordeling KMD Sag kan i dag udføre simpel sagsfordeling for de eksisterende monopolsystemer hos KMD. Sagsfordeling forventes i fremtiden at blive håndteret af de relevante fagsystemer, herunder ESDH. Sagsfordeling-funktionalitet skal derfor ikke etableres som et nyt fælleskommunalt støttesystem, men som et overgangssystem, der muliggør udfasning af KMD Sag. 8

9 Tværgående dokumenter om støttesystemerne Støttesystemer i sagsprocessen Papiret beskriver, hvordan fælleskommunale it-systemer med sager dvs. alle fagsystemer funktionelt skal anvende støttesystemerne. Det er tanken, at papiret skal bearbejdes videre, så det beskriver de egentlige krav til fagsystemer om at bruge støttesystemerne. Dette illustreres med udgangspunkt i den generiske sagsproces, der angiver de aktiviteter, som jævnfør lovgivningen nødvendigvis må forekomme i en proces, der omfatter myndighedsopgaver. Papiret beskriver, hvordan fagsystemer skal holde deres klassifikationssystemer opdateret ved at trække på det fælleskommunale Klassifikation-system; skal holde deres oplysninger om kommunernes organisering opdateret ved at trække på det fælles Organisation-system; skal holde andre systemer orienteret om deres sager og dokumenter samt ydelser ved at lægge metadata i Sags- og Dokumenindeks samt Ydelsesindeks og selv få oplysninger om andre systemers sager og dokumenter samt ydelser derfra. Støttesystem klient Papiret beskriver kravene til, hvordan fælleskommunale it-systemer mv. skal integrere til støttesystemerne. Dette skal i første version af støttesystemerne ske via klienter. Klienterne skal driftafvikles sammen med de it-systemer, der skal anvende støttesystemerne og vil typisk rumme en cache mv. af oplysninger fra støttesystemerne, og deres operationer. Itsystemerne vil dermed opleve det som om støttesystemerne findes i it-systemets eget driftmiljø. Dette fremmer driftsikkerheden i it-systemernes brug af de fælleskommunale støttesystemer. Selvom leverandører mv. har peget på, at flere integrationsformer ideelt set kunne være ønskelige fx servicesnitflader direkte på støttesystemet, eller beskedudveksling skal der i første version af støttesystemerne alene integreres til støttesystemerne via klienter. Flere integrationsformer, fx de nævnte, må forventes at blive tilbudt på sigt, som led i videreudviklingen af støttesystemerne. 9

10 Tværgående dokumenter med krav i rammearkitekturen Fælleskommunale rammearkitektur For en introduktion til rammearkitekturen generelt, herunder støttesystemerne, henvises til Fælleskommunal rammearkitektur, som var det centrale dokument i review september 2012: Integrationsmønstre Papiret beskriver en række fælleskommunale krav til integrationsmønstre, som vil indgå i kravspecifikationer for fælleskommunale it-systemer, og som eventuelt kan anvendes i enkeltkommunale udbud. Integrationsmønstrene skal anvendes ved specifikation af krav til integrationer i forbindelse med udbud af nye it-systemer og ved aftaler om snitflader til de omgivende, eksisterende systemer. For hver integration i en kravspecifikation eller i en aftale om en snitflade skal være specificeret de(t) relevante integrationsmønster/re. Logning Papiret beskriver en række fælleskommunale krav til logning, som vil indgå i kravspecifikationer for fælleskommunale it-systemer, og som eventuelt kan anvendes i enkeltkommunale udbud. Forretningskrav Papiret introducerer KL og KOMBITs arbejde med at vedligeholde de fælleskommunale forretningskrav, som udgør den forretningsmæssige del af rammearkitekturen. Via en fælles kravredaktion og repræsentation af kommunerne skal kommunerne kunne opsamle alle krav til processer, informationsmodeller, use cases og regler i et fælleskommunalt repository. Derved sikres, at kommunerne i fælleskab holder den relevante forretningsviden ifm it-systemers udvikling og videreudvikling, fx ifm lovændringer. Drift De to papirer uddyber den driftstrategi, som er besluttet for de fælleskommunale it-systemer, bl.a. efter behandling i Arkitekturrådet. It-systemer vil blive udbudt med udvikling og drift hos den samme leverandør, men driften skal efter en årrække kunne flyttes til en fælles driftleverandør, hvis dette er hensigtsmæssigt for systemet. Man skal kunne flytte enten hele driften incl support, eller kun infrastrukturdriften. Test Papiret beskriver teststrategien for de fælleskommunale it-systemer både test af it-systemer generelt, og test i forbindelse med it-systemers brug af støttesystemerne. 10

11 Øvrige tværgående arkitektur-emner, som ikke indgår i dette review Jævnfør det forrige fælleskommunale review i 2012, arbejdes med en række yderligere tværgående emner i rammearkitekturen, som ikke bringes i review denne gang. Til information gives her en kort status for arbejdet med disse emner: Udbetaling, opkrævning og modregning Som led i bestræbelserne på et monopolbrud omkring udbetaling, opkrævning og modregning samarbejder KOMBIT med ATP om mulighederne for udbud, der konkurrenceudsætter området. Det fællesoffentlige projekt En Konto ser umiddelbart ikke ud til at føre til et fælles initiativ. Økonomi KOMBIT har iværksat et projekt om Økonomi i rammearkitekturen, der i samarbejde med kommunerne beskriver de vigtigste processer, informationer og snitflader omkring de kommunale økonomisystemer. På kort sigt skal projektet understøtte, at der etableres de relevante åbne snitflader mellem på den ene side de nye Kommunernes Ydelsessystem og Sygedagpengesystemet, og på den anden side kommunernes respektive økonomisystemer. Dette skal ligeledes bidrage til, at kommunerne får mere standardiserede snitflader omkring deres økonomisystemer, og at fagsystemer på enkel vis kan integrere til alle økonomisystemer, eventuelt via snitflader på den fælleskommunale Serviceplatform. På længere sigt vil projektet bidrage til at understøtte ovennævnte monopolbrud på udbetalings-, opkrævnings- og modregningsområdet. BI/LIS KOMBIT har arbejdet på at afklare arkitekturen for distribution af LIS-relevante data fra de fælleskommunale fagsystemer til kommunernes lokale LIS-systemer, samt til FLIS. Afklaringen forventes at føre til, at Serviceplatformen anvendes som distributionsled, ligesom for andre typer af data af fælleskommunal interesse. Dette vil betyde, at ad hoc distribution fra FLIS til kommunerne omlægges, så den går via Serviceplatformen. Hop Jævnfør tidligere review i september arbejdes på en arkitektur for hop fra skærmbilleder i et itsystem til skærmbilleder fra et andet it-system. 11