Review af kravspecifikation for Støttesystemer

Transkript

1 MNI Klik her for at angive tekst. Review af kravspecifikation for Støttesystemer Kommuner April 2013 KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 1/49

2 Indhold 1. Forord Succeskriterier Sikkerhed Organisation Beskedfordeler Ydelsesindeks Sag- og Dokumentindeks Advisservice Feedback fra kommuner Sikkerhed Organisation Klassifikation Beskedfordeler Klienter Ydelsesindeks Sags- og Dokumentindeks Kontaktdata Advisservice Drift og test Evaluering af workshoppen Bemærkninger: KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 2/49

3 1. Forord Tak til de kommuner, som havde tid og lyst til at tilbringe to dage med at gennemgå 800 siders kravspecifikationer for støttesystemerne i Den Fælles Kommunale Rammearkitektur. Det var bestemt ikke en triviel opgave at gennemføre 8 workshops i træk, så det var en positiv oplevelse, at kommunerne fik påpeget så mange relevante problemstillinger undervejs og at der var mulighed for at drøfte problematikkerne på tværs af kommunerne. I har mulighed for at se de gule lapper, som blev nedfældet undervejs i de forskellige workshops - og så er de blevet suppleret med det et svar, som blev fortalt på workshoppen. Så sagt med andre ord så kan I betragte dokumenterne som værende referaterne fra de 8 workshops. KOMBIT arbejder i sagens natur videre med at færdiggøre kravspecifikationerne og hvis alt går efter planen, så vil de være klar i opdateret version ultimo juni. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 3/49

4 2. Succeskriterier I forbindelse med workshoppen blev de kommunale repræsentanter bedt om at opstille succeskriterier for de enkelte støttesystemer. Nedenfor følger denne liste: 2.1 Sikkerhed Høj oppetid. Uafhængighed af platforme. Det skal være let forståeligt at trække data fra loggen. Sikkerhed skal kunne understøtte SSO og SSout. Ekstern adgang til borger og virksomheder. Positiv udvikling efter idriftsættelse (red. af svartider). Max 1,5 sekunder ekstra til login. Lave svartider. Systemerne skal kunne skaleres efter behov. tider skal kunne måles/logges i sikkerhedskomponenterne. Det gælder ligeledes for end-to-end svartiden for hele sessionen. Der skal kunne laves fejlhåndtering og diagnostisering på sikkerhedskomponenterne. Oppetid >99%. Skal kunne understøtte mobile platforme. Smidig overgang. 2.2 Organisation Implementering og vedligehold af organisation skal være let. Kommunerne skal have vejledning i, hvordan organisationer opbygges. Kommunerne skal have vejledning i, hvordan man mest hensigtsmæssigt opmærker med KLE og FORM. Organisationens vision bør fremgå tydeligt på kort og på langt sigt. Kommunerne skal have hjælp og vejledning i udfasning af de eksisterende systemer. 2.3 Beskedfordeler Det skal være nemt at administrere. Administrationsforbruget må ikke øges. Beskederne skal leveres hurtigt KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 4/49

5 Der skal ikke være begrænsninger på antal af beskeder Det skal være enkelt og billigt at tilslutte afsender- og modtagersystemer Teknisk understøttelse af flere måder at kommunikere med klienten på Programmatisk API til håndtering af abonnementer. 2.4 Ydelsesindeks Alle typer ydelser skal med i Ydelsesindeks. Adgang til egen sag på f.eks. borger.dk > mine ydelser. Klarhed om, hvorvidt der kommer adgang via SAPA eller om der skal etableres en særskilt løsning. 2.5 Sag- og Dokumentindeks Kritisk masse for antal leverandører (Afsendersystemer) o F.eks. minimum svarende til systemer fra monopolbruddet. Datakvalitet. Mulighed for at holde indeks synkront (med Afsendersystemer). Simpel og stabil integration skal tilbydes Anvendersystemer. Bedre mulighed for udfasning af KMD Sag. 2.6 Advisservice Der skal være sikkerhed om Advisservices levetid. Der leveres en generisk kravspecifikation, der kan bruges i andre udbud. Den skal leveres som komponent, der kan indlejres i fremtidige systemer (komponent skal defineres). Der skal være et centralt støttesystem med mulighed for lokale tilpasninger. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 5/49

6 3. Feedback fra kommuner Som sidste skridt i forberedelsen til udbuddet af støttesystemerne er der behov for, at kommunerne kommenterer materialet mhp. følgende: Afspejler kravspecifikationerne de behov, som der er for at skabe sammenhæng på tværs mellem kommunale it-systemer? Er indholdet af systemernes 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 kravspecifikationernes 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? Ud fra ovenstående modtog KOMBIT en lang række kommentarer, der er stillet op i Q&A tabeller nedenfor. Det er muligt, at se den fælles præsentation fra workshoppen her. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 6/49

7 3.1 Sikkerhed Sikkerhed omhandler to centrale komponenter i rammearkitekturen, der håndterer adgangen til brugervendte og ikke-brugervendte systemer. Komponenterne indgår som centrale elementer i en moderne, fødereret sikkerhedsmodel, hvor adgang er baseret på udstedelse og præsentation af billetter (security tokens). De to hovedkomponenter i denne er: En SAML Identity Provider (Context Handler) som håndterer personbrugere med en browser, der ønskes at tilgå et brugervendt system. De brugervendte systemer vil typisk være fagsystemer eller administrationsmoduler i støttesystemerne. En Security Token Service (STS) som håndterer systembrugere (Anvendersystemer), der skal foretage et web service kald til et støttesystem. Plancherne for Adgangsstyring kan ses her. Plancherne for Administrationsmodul kan ses her. /FAQ Sikkerhed 1. 1Hvilke muligheder er der for at udtrække rapporter? Ja der vil være muligheder for at udtrække rapporter via administrations modulet. 2. Er visionen om borgerens adgang tænkt grundigt nok ind i det tekniske/performance setup? 3. Understøtter sikkerhed organisationsændringer? I og med at borgerne kan fødereres ind via NemLog-in, er der taget højde for det. Hvis en organisationsændring automatisk skal slå igennem på tildeling af jobfunktionsroller, skal kommunerne selv realisere denne automatik via en lokal IdM oven på deres brugerkatalog. 4. Roller kontra dataudsnit? KOMBIT er i gang med at undersøge i hvilket omfang, dataudsnit kan understøttes. 5. Kan de samme roller både defineres på højt og på lavt niveau, alt efter kommunale behov? Ja. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 7/49

8 /FAQ Sikkerhed 6. Hvordan hænger administrationsmodulet sammen med måden at tildele roller på i dag i kommunen? 7. Hvordan håndteres forskelle i granularitet på tværs af de enkelte kommuners AD er? 8. Kan real-time og dynamiske rettighedsændringer håndteres? 9. Jobfunktions vs. systemroller og samspillet med fagsystemer? 10. Infrastruktur Hvad kræver det af kommunerne? 11. Brugerfladen til administrationsmodulet skal være nem at bruge. 12. SAML 2 ikke udbredt endnu. Hvordan håndteres dette? Tildeling af roller forbliver kommunespecifikt, således, at det stadig sker i kommunens eget brugerrettighedssystem og ikke i administrationsmodulet. Datamodellen giver mulighed for at understøtte forskellig granularitet, men kommunerne definerer selv jobfunktionsroller og har dermed kontrollen. Ja, det vil være et krav, men ændringer i jobfunktionsroller slår ikke igennem, før brugeren logger på igen og etablerer en ny session. Der er dog mulighed for at gennemtvinge en tvungen logout. Jobfunktionsroller defineres af kommunen og systemroller defineres af det enkelte fagsystem. Mapping mellem jobfunktionsroller og systemroller sker i den enkelte kommune. Vil blive besvaret i forbindelse med anvenderkravene, som kommer senere på året. Kommunerne vil blive inddraget i forbindelse med formuleringen af kravene til brugerfladen på administrationsmodulet. SAML2 er ikke en teknologisk barriere og er desuden særdeles udbredt i det offentlige. Eksempelvis bruger samtlige 150+ selvbetjeningsløsninger på NemLog-in og borger.dk SAML2. Alle Virk-dk s løsninger bruger det, WAYF føderationen bruger det, og Miljøportalen bruger det. Med andre ord bør det være uproblematisk at anvende SAML2 13. Hvordan håndteres mobile platforme? Sikring af kommunikation direkte mellem mobileenheder og fagsystemerne er ikke en del af dette udbud. Men sikkerhedsmodellen KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 8/49

9 /FAQ Sikkerhed understøtter særligt mobilvenlige IdP'er til autentifikation af brugere på mobile enheder. KOMBIT arbejder på at fastlægge kravene til sikring af kommunikation ifm. rammearkitekturen. Sikring af kommunikation til mobileenheder vil blive behandlet herunder. Endvidere kan SAML2 sagtens køre på en browser i en mobil enhed, da den kun bruger standard HTTP operationer, så det er ikke adgangsstyring, som sætter begrænsningen. 14. Styring af brugeradgang til S&D? Se svar på spørgsmål Hvem vil administrere ansøgning og fordeling af certifikater? 16. Hvordan vil sameksistens med andre brugere/ administration/sikkerhed/systemer foregå? (Undgå administrations KAOS.) 17. Bliver løsningen ressourcetung at administrere. 18. Sikkerhedsintegrationen vil være den indledende integration, og det vil belaste de første sagssystemer? 19. Hvordan med sikkerhed ift. Sag- og Dokument metadata, som ikke følger standarderne. (F.eks. sagstyper fremfor KLE-nr. og sikkerhedsbetegnelser, som er Afklares ifm. drift- og governancekrav. Kommunernes IDM/IAM systemer kan integrere med administrationsmodulet, således, at de ikke skal administreres flere steder. Den daglige administration foregår i kommunens eget brugerkatalog, hvor de frit kan vælge værktøjer og processer. Så det bør ikke blive mere besværligt at administrere fremover. Ja. KOMBIT er i gang med at undersøge denne problemstilling nærmere. forskellige.) 20. Kan det performe? Ja det kan det. AD FS kan erfaringsmæssigt skalere næsten lineært. 21. Bekymring: Performance? Se ovenstående svar. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 9/49

10 /FAQ Sikkerhed 22. Bliver det hurtigere eller langsommere? Et relativt spørgsmål der nok skal uddybes yderligere. Der er formuleret et krav om en maksimal login-tid på 1.5 sek. 23. Variable timeout tider? KOMBIT ser på muligheden for variable timeout tider. 24. Kan der segmenteres på data? Kommunerne definerer selv rollerne. Eksempelvis fagsystem? 25. Hvordan håndteres hop i forbindelse med sikkerhed? Der skal forespørges via kommunens IdM/IAM som nyt SSO login til det system, der hoppes til. Dvs. det er usynligt for brugeren. 26. Det skal være muligt at fejlfinde. Der vil blive formuleret specifikke krav vedrørende fejlfinding 27. Rapporter? Se svar på spørgsmål Bruges der SSO? Ja. 29. Tag ved lære af sundhedssektorens erfaringer, som har kæmpet med disse problemer (SSO). KOMBIT er i dialog med forskellige sektorer for at lære af deres erfaringer med SSO. Eksempelvis ved KOMBIT, at sundhedssektoren har anvendt proprietære standarder, og dette har voldt dem store udfordringer. Overgangen vil fremgå af den planlagte drejebog for kommuner. Vil blive besvaret i forbindelse med anvenderkravene, som kommer senere på året. 30. Hvordan vil overgangen til de nye løsninger foregå? 31. Hvad kræves af kommunerne (f.eks. ADFS, IDP) og hvordan med betaling? 32. 5Hvad er planen for de gamle KOMBIT er i gang med at undersøge systemer? nærmere. 33. Kan NemID anvendes? Der vil blive integreret til NemID via NemLog-in. 34. Standarder vs. egen udvikling? KOMBIT vil tilstræbe at anvende OIO,SAML og OIO WS-Trust, som er fællesoffentlige standarder, og som har været anvendt siden Relation til logning? Se krav til logning. 36. Konsolidering af logs? Tanken er, at alle logs for rammearkitekturen vil blive konsolideret et sted. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 10/49

11 /FAQ Sikkerhed 37. Hvordan håndteres DDOS angreb? Bliver håndteres via et driftskrav, hvor der stilles krav til internetudbyderen om at tilvejebringe DDOS services. 38. Flere kommuner på samme platform? Arkitekturen for adgangsstyring skal mere ses som en føderation af distribuerede, løst-koblede elementer. Hvilket betyder, at der sagtens kan være flere kommuner på samme platform 39. Hvad forsvinder? KSP-CICS? KOMBIT er i gang med at undersøge dette nærmere. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 11/49

12 3.2 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). Plancherne for Organisation kan ses her. 1. 1Fælles kommunale stamdata/født med stamdata /Organisation 2. Userinterface: Det skal være enkelt at tilføje en ændring Det vurderes om der skal stilles krav til, at Organisation skal indeholde et fælles sæt af stamdata som alle kommuner anvender. Disse stamdata vedligeholdes af KOMBIT og leveres sammen med løsningen. Eksempel er oversigt over leverandører og løsninger. KOMBIT overvejer hvorledes det kan blive indarbejdet som et krav i kravspecifikationen Der stilles en række krav til brugervenlighed. 3. Import! Der stilles en række krav til at det skal være muligt at importere organisationer fra eksisterende systemer. 4. Userinterface skal udvikles i tæt samarbejde med kommunerne 5. Er der flere brugertyper (bestiller, udfører, godkender)? 6. Grafisk eksport af hierarki til brug på bl.a. hjemmesider? Brugergrænseflader til administration af organisationer skal designes i tæt samarbejde med kommunerne. Der stilles en række krav til at der skal være roller i Organisation, således at rollen som bestiller, redaktør og godkender af organisationer kan adskilles. Der stilles en række krav til løsningen skal indeholde mulighed for at KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 12/49

13 /Organisation eksportere organisationer på et grafisk format. Dette kan anvendes i rapporter, på websider m.m. 7. Organisation skal tilbyde onlineopdatering således, at ændringer i Afsendersystemer afspejles tidstro (i Organisation). Der stilles en række krav til at det skal sikres, at opdateringer i Afsendersystemer kan importeres real-time i Organisation således, at ændringer øjeblikkeligt er synlige for Modtagersystemer. 8. AD vs. import/oio? Der stilles en række krav til at det skal være muligt at importere fra AD og transformere til OIO. 9. Tidsangivelser? Det er usikkert hvad spørgsmålet dækker over, men data i Organisation har bitemporale egenskaber. 10. To-vejs? Der stilles en række krav til at det er muligt både at importere og eksportere fra Organisation. 11. Slå op direkte vs. klienten (tilgang)? Opslag skal ske gennem klienten. 12. Brugen af beskedfordeler? Organisation skal understøtte såvel modtagelse som afsendelse af beskeder. 13. Er lokale behov tidskritiske? Afsendersystemer der er autoritative har ansvaret for, at Organisation er opdateret. 14. Selvbetjeningsløsning? Det skal være muligt at anvende data fra Organisation i kommunernes selvbetjeningsløsninger. 15. Initiel load? Man kan importere sin Organisation første gang. Se spørgsmål Fejl! Henvisningskilde ikke fundet Forretningsregler - Der skal f.eks. være KLE-nr. på Organisationsenheder Organisation skal indeholde forretningsregler, der validerer en organisation for korrekthed. Således kan en redaktør gennem brugergrænsefladen få vist, hvad der eksempelvis mangler for, at en KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 13/49

14 17. Hvordan kobles kommunernes Organisationssystemer på?? /Organisation organisation er komplet og korrekt. Krav til at Organisation skal tilbyde integrationspunkter til kommunernes eksisterende systemer til administration af organisationer. 18. En funktion som kan beskrive/udskrive en given Organisation? Der vil blive stillet krav til at der skal være muligt at udskrive en Organisation. 19. Import? (CSV format.) Der vil blive stillet krav til at Organisation som minimum skal tilbyde import fra CSV filer. 20. Hvem skal være hotline? KOMBIT er i gang med at fastlægge den fremadrettede governance og ønsket vil blive overleveret til dette projekt KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 14/49

15 3.3 Klassifikation Støttesystemet Klassifikation gør det muligt at udstille og vedligeholde en række klassifikationssystemer, så disse kan bruges af fælleskommunale itsystemer til opmærkning af information. Klassifikationssystemer er et centralt bindeled i rammearkitekturen fx skal stort set alt hvad it-systemer lægger i eller læser fra de øvrige støttesystemer opmærkes med klassifikationer. Plancherne for Klassifikation kan ses her. /Klassifikation Hvordan sikres versionsstyring? Der er lavet en lokal udvidelse til OIO standarden, se Kravspecifikationen side 15. Side 43 står der: Til at håndtere versionering udnyttes de bitemporale egenskaber ved alle objekter, hvor import af et klassifikationssystem, som konsekvens af registrering jf. [OIO_GEN_SAGDOK] side 21, skaber nye instanser af de klassifikationssystems objekter der er ændret. Redaktøren kan tilføje en logisk label til versionen og dermed lave sammenhæng med en gruppe af objekter med en bestemt virkning og et eksternt kendt versionsnummer. Er der taget stilling til et centralt system versus 98 lokale? De 10 første klassifikationer, hvad skal det være? Støttesystemet har af natur en eller få kilder til hvert klassifikationssystem, mens der er mange modtagere, hvilket logisk ligger op til et centralt system, men det afgøres endeligt i udbudet om man fysik vælger et distribueret løsning. Det er planen at KLE, IM kontoplan og FORM er en del af udbuddet. Efter udbuddet kan ligges klassifikationssystemer ind efter behov. Klassifikationssystemer som er blevet nævnt er: hændelsestyper, ydelsestyper, kommunale kontoplaner KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 15/49

16 /Klassifikation Mapning mht. KLE og andre klassifikationssystemer f.eks. sagstyper, sker den i sagsindeks eller i klassifikation? UUID hvordan bliver det genereret? Mapning fra et klassifikationssystem til et andet noteres i klassifikationssystemet selv, se attribut mapninger under KlasseRelationsListe i informationsmodellen for Klasse i kravspecifikationen side 31. UUID er en unik nøgle der generes lokalt hvor der er brug for den, se UUID er er en del af de generelle egenskaber i Generelle egenskaber for serviceinterfaces på sags- og dokumentområdet, se side 9, 19. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 16/49

17 3.4 Beskedfordeler 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. Plancherne for Beskedfordeler kan ses her. /FAQ Beskedfordeler Push vs pull af beskeder 1. Det vil være hensigtsmæssigt at både push og pull understøttes. KOMBIT kigger på kompleksiteten ved at understøtte begge metoder. Det overvejes at kravsætte en option om, at Beskedfordelerklienten skal kunne pushe til et modtagersystem, såfremt dette implementerer en push snitflade. Denne snitflade kan være inspireret af WS-Notification eller tilsvarende. 2. Kan ting pushes ud? Se ovenfor. Abonnementer 3. Hvordan forestiller vi os administration af abonnementer? 4. Automatisk og manuel opsætning af abonnementer? I kravspecifikationen er det beskrevet, at dette vil være en manuel opgave for et givet anvendersystems administrator. Adgang til administration af abonnement m.m. sker via en fælles adgangsportal. KOMBIT forstår godt ønsket om automatisk opsætning af abonnementer, og vi kigger på det. Vi skal sikre, at man kun kan oprette de abonnementer og abonnementsudtryk, man har ret til, når man anvender den automatiske KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 17/49

18 Beskedstørrelse /FAQ Beskedfordeler 5. BF-tænkning understøtter behovet for en file-container/database til opbevaring af filer. 6. Hvad med filer/vedhæftning (F.eks. i kommunikation med sygehuse omkring indlæggelser og udskrivning af rapporter/behandlingsplaner)? 7. Besked payload (ubegrænset) kan være et krav. 8. Prioriterede beskeder evt. med kvittering? måde (API) til opsætning af abonnementer mv. Det skal desuden afklares, hvordan det adgangsstyres, at et system kan modificere et abonnement. Vil ikke blive medtaget i første version af Beskedfordeleren. Kan på længere sigt blive medtaget som et ændringsønske. Der er pt ikke specificeret et støttesystem, der kan indeholde filer. Dokumentindeks og evt. beskeder vil/kan indeholde referencer til filer, hvorfra de kan hentes. Dette er ikke en del af Beskedfordeleren. Vi mener ikke, at beskeder er den rette måde at udveksle filer på. Beskeder kan indeholde en reference til en fil, og filen kan så hentes herfra. Vi stiller krav til maksimal beskedstørrelse i forbindelse med opstilling af servicemål Vi forventer, at det bliver nødvendigt at sætte en grænse for beskedstørrelser, hvis servicemålene skal kunne opfyldes. I forbindelse med opstilling af servicemål vil vi medtage ønsket om, at beskeder leveres hurtigt. Det forventes ikke, at dette vil blive nødvendigt. Kvitteringer, der skal sendes til et specifikt system og har en adressat, harmonerer ikke helt med intentionen om, at beskedfordeleren understøtter det asynkrone publish/subscribe mønster. 9. Stop så med at diskutere svartider tider vil bl.a. afhænge af mængder af beskeder og deres størrelse Det er rigtigt, at mange små beskeder KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 18/49

19 /FAQ Beskedfordeler Central/lokal beskedfordeler bør/vil sikre at beskeder leveres hurtigt. 10. Mulighed for replikering af andre beskedfordelere? 11. Mulighed for anvendelse til lokale formål eller tværgående f.eks. mellem kommune og UDK? 12. Hvordan er sammenhængen mellem den gule og den røde beskedfordeler (fra oversigtstegningen)? Kuvert og protokoller mv. Der er intet til hinder for, at den fælleskommunale beskedfordeler kan modtage beskeder fra afsendersystemerne via en evt. lokal beskedfordeler. Dette kræver bare, at de nødvendige aftaler er på plads, og at det stadig tydeligt fremgår, hvor beskeder kommer fra. Beskedkuverten giver mulighed for at registrere beskedens rute. Føderering med andre vil blive kravsat. Se ovenfor. Den beskedfordeler, vi kravspecificerer, er den fælleskommunale beskedfordeler. Se i øvrigt svar ovenfor. 13. Har man overvejet AMQP protokollen i stedet for at udvikle sin egen? Kravspecifikationen skal understøtte, at leverandørerne kan vælge frit mellem de forskellige protokoller. Vi stiller ikke krav til en specifik protokol men beskriver de krav vi har til den. Herefter vil det være op til leverandøren at komme med forslag. Leverandøren kan f.eks. vælge at anvende AMQP. 14. Hvad stiller vi af krav til protokoller? Vi opdaterer kravspecifikationen, med et krav til dette. 15. Hvilke standarder forventer man at benytte sig af? I forhold til kuverten se nedenfor. I forhold til indhold (payload) undersøges det i øjeblikket, hvad der er mest relevant (dette foregår i regi af Forretningskravprojektet). KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 19/49

20 /FAQ Beskedfordeler 16. Overholdelse af standarder? Beskedkuverten er defineret med udgangspunkt i flere kendte standarder herunder WS-notification og Anbefalingen til generel hændelsesbesked. Det er kravsat at integrationen mellem anvendersystem og beskedfordelerklienten skal understøtte kuverten. Beskeder 17. Skal beskedtyper registres i Klassifikation? 18. Hvad med et beskedkatalog, så man kan optimere sine processer? 19. Global definition af hændelsestyper, så forståelsen er den samme? 20. Hvor længe skal beskeder gemmes (udløbsdato)? 21. Gem/log af beskeder - er vi sikre på at de når frem? Sammenhæng til andre Det forventer vi ikke. Vi har beskrevet et beskedkatalog i kravspecifikationen vi forventer det er her overblik over beskeder vil findes. Dette er beskrevet i kravspecifikationen vi ser på om det skal gøres tydeligere. Dette arbejdes der på i øjeblikket i regi af Forretningskravprojektet. Der er mulighed for at påføre beskeder en udløbsdato, og når den nås, vil beskederne automatisk blive slettet fra dueslaget. Hvis en besked ikke har en udløbsdato, vil den blive liggende (og afleveret) indtil anvendersystemer har initieret, at den slettes. Dead-letter-queue funktionaltet skal sikre at fejl i opsætningen af abonnementer ikke medfører uigenkaldeligt tab af beskeder. 22. Samspillet med Advis er? Advis er er ikke relevante for beskedfordeler idet en simpel definition på forskellen mellem Advis er og beskeder er, at adviser er til mennesker, og beskeder er udveksling af information mellem systemer. Advis er kan eksempelvis dannes på KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 20/49

21 /FAQ Beskedfordeler 23. Hvorfor er Sags- og Dokumentindeks og andre ikke bare abonnenter på Beskedfordeler? 24. Samspillet med STS i forhold til klienterne? Hvorfor og hvordan? 25. Beskedfordelers funktion forekommer begrænset i forhold til nødvendigheden af en egentlig transaktionsarkitektur baggrund af en modtaget besked men også på anden baggrund. Her henvises til beskrivelse af Advis. Det er i første omgang besluttet, at alle støttesystemer integrerer med deres anvendersystemer via klienter. Men der er intet teknisk til hindrer for, at indekserne kan abonnere på beskeder i fremtiden Det vil/kan dog være uheldigt, hvis en besked om en opdatering overhaler den faktisk foretagne opdatering. Altså hvis en besked om et nyt dokument til en sag når frem til et givet fagsystem, før Dokumentindeks er opdateret. Klienten er støttesystemets ansigt udadtil det vil sige, at det er her man afleverer og afhenter beskeder. Herefter sørger klient og støttesystem i samspil for, at beskeder distribueres, leveres og slettes. Klienterne skal gøre det simpelt at anvende støttesystemerne således er der ingen teknisk hindring for at anvende dem, og ligeledes skal det heller ikke være omkostningstungt for det enkelte anvendersystem at tilslutte sig. KOMBIT har stillet krav om at beskeder lagres i Beskedfordeleren indtil et modtagersystem eksplicit indikerer, at de kan slettes. Det er eksplicit fravalgt, at en beskedfordelerklient kan indgå som en ressource i en distribueret transaktion. I stedet er det valgt, at klienten beholder beskeden, indtil modtagersystemet er færdig med at behandle. Modtagersystemet skal selv sikre sig imod modtagelse af samme besked KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 21/49

22 /FAQ Beskedfordeler 26. Berigelse af beskeder (abonnement på CPR oplysninger) flere gange. Detektion af dette understøttes via et unikt sporings-id per besked. Den generelle beskedagent er tænkt som en funktion, der kan tilføre objektive informationer til beskedkuverten - eksempelvis kommunenummer på CPR beskeder. Dermed bliver der mulighed for at abonnere på relevante CPR-beskeder for en given kommune. 27. Annullering af beskeder Beskedfordeleren forholder sig alene til de informationer, der angives i beskedkuverten og vil derfor ikke opdage, hvis to forskellige beskeder (ID) indeholder samme oplysninger. Beskedklienten kan dog indenfor et kort tidsrum opdage, at der afleveres to beskeder med samme beskedid og dermed sørge for at kun den ene sendes. Hvor langt dette tidsrum bliver, er under afklaring. Det vil blive medtaget som en præcisering i kravspecifikationen. Øvrige 28. Fejlhåndtering driftovervågning. Dette vil blive kravsat. 29. Hvem formulerer krav til og prioriterer videreudvikling? Dette handler om governance - og vi vil indgå i en generel strategi for dette. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 22/49

23 3.5 Klienter I første version af støttesystemerne vil integrationen til fælleskommunale itsystemer mv. ske via klienter. Klienterne skal driftafvikles sammen med de itsystemer, der skal anvende støttesystemerne og vil typisk rumme en cache mv. af oplysninger fra støttesystemerne, og deres operationer. It-systemerne 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. Plancherne for klienter kan ses her. Der foreligger ingen spørgsmål til emnet. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 23/49

24 3.6 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. Plancherne for Ydelsesindeks kan ses her. /FAQ Ydelsesindeks 1. Er der adgang til den Lovmæssig baggrund bagved Ydelsesindeksets overblik? Er det nødvendigt? Eller kan det løses ved at "hoppe" til det konkrete fagsystem? 2. Ydelsesindeks skal være i stand til at integrere til flere forskellige udbetalingssystemer 3. Sikkerhed er vigtigt - også i forbindelse med "hop" til konkret fagsystem. 4. Ydelseskatalog er ikke en del af Ydelsesindeks. Den bagved liggende lov, som ligger til grund for beregningen af ydelsen, vil ikke blive medtaget i ydelsesindeks. Man vil være nødt til at gå til det fagsystem, der har foretaget beregningen for at få dokumenteret dette. Ja, Ydelsesindeks vil kunne integrere til de afsendersystemer som er relevante. Ja, det er vigtigt, at den konkrete bruger kun ser relevante informationer; også i forbindelse med hop til fagsystem. Sikkerhedsmodellen i forhold til hop er pt. under afklaring. Ydelseskatalog kan f.eks. implementeres i Klassifikation 5. Sikkerhed. Hvem forvalter data og adgang til data? Myndigheden og anvendersystemet skal være godkendt og tilsluttet til Støttesystemet for kunne benytte Ydelsesindeksservices. Mht. autorisation er det sikkerheden i Afsendersystem, der skal håndhæves i modtagersystemet. Ydelsesindeks vil indeholde den nødvendige information til at dette kan lade sig gøre. Den endelige model er under afklaring. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 24/49

25 /FAQ Ydelsesindeks 6. UDK må kun vise ydelser 3 måneder tilbage i tid? 7. Det skal være muligt både at kunne hoppe til det system, der har beregnet ydelsen (fagsystemet) og til udbetalingssystemet. 8. Hvorfor er Ydelsesindeks ikke konsolideret ind i Sags- og Dokumentindeks? 9. Bliver indholdet i Ydelsesindeks eventuelt ophøjet til OIO standard? 10. Alle typer ydelser er nødvendige for at give f.eks. SAPA værdi. 11. Kan Ydelsesindeks tænkes som master for ydelser for fagsystemer? Fagsystemet kunne så udelukkende indeholde regler/forretningslogik omkring beregning af ydelsen. Fagsystemet kunne så aflevere de beregnede ydelser til Ydelsesindeks Der henvises til [OIODMFUN] og [OIOSGFUN] uden disse fremgår af afsnittet Referencer Der henvises til [GRUNDDATA] uden dette fremgår af afsnittet Referencer 14. s. 29 For Forretningsobjekt Bevilget Ydelse: hvordan definerer de aktiv, in aktiv og passiv. 15. s. 76, s. 81 Er klient servicen en webservice? Use case diagram og beskrivelser indeholder ikke de samme use cases. F.eks. Mangler Y120 Slet Bevilget Ydelse på diagrammet. Det indgår som en del af kravene til sikkerhedsmodellen Det medtages som input. Ydelsesindeks er et særskilt støttesystem, idet der er et ønske om at være i stand til at konkurrencesætte det selvstændigt. Det er der ikke taget stilling til på nuværende tidspunkt. Fysiske ydelser og ressourceydelser forventes inkluderet i udbuddet. Ydelsesindeks er udelukkende tænkt som et passivt indeks, der kun indeholder data til at skabe overblik, så det er pt ikke i scope. Det forventes fortsat, at de enkelte fagsystemer indeholder ydelsesmetadata. Korrekt. Det vil blive opdateret. Korrekt. Det vil blive opdateret. Skal angive hvorledes status på ydelsen er. Klienten vil skulle installeres sammen med fagsystemet. Klienten udstiller sine services via facader, som kunne være web services. Det vil blive uddybet. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 25/49

26 /FAQ Ydelsesindeks Økonomisk Effektuering: Er det tanken at tilbagesøgninger af for meget udbetalt ydelse også skal lægges i ydelsesindekset, eller skal ydelsen i sådanne tilfælde korrigeres i indekset, eller hvad er politikken? Use cases til hent af data skal virke, selvom anvender ikke har lov til at se data for alle begrebstyper. I.fbm. overblik på tværs af myndighedere (UDK/kommuner) er det kun Effektueringer, som må deles og ikke de øvrige oplysninger Ved søgning/hent af data kan der være behov for at kunne angive, om man ønsker data kun for kommune/udk eller for begge (relevant ifbm. overblik på tværs af UDK/kommuner). 20. Klienter - Hvilke Services udstilles på klienten? 21. Klienter - Hvem har ansvaret for at indekset opdateres efter at Fagsystemet har kaldt Klienten? 22. Sikkerhed - Hvorledes sikres det at kommuner kun kan se ydelser for egne borgere? 23. Sikkerhed - Hvorledes sikres det at Udbetaling Danmark kan se ydelser for alle borgere i Danmark? 24. Sikkerhed - Hvordan sikres det, at kommunerne kun kan se ydelser 3 måneder bagud? Det vil blive afklaret, men som udgangspunkt vil effektueringen skulle opdateres i Indekset på baggrund af opdateringen i Fagsystemet. Den endelige version af sikkerhedsmodellen er under udarbejdelse, afgrænsning vedrørende hvilke myndigheder og systemer som kan benytte ydelsesindeks, vil blive understøttet i den generelle kommunale rammearkitektur, Ydelsesindeks vil understøtte afgrænsninger på myndighedsniveau, mens konkrete autorisationer vil blive håndhævet af modtagersystemet. Her vil Ydelsesindekset give modtagersystemet den nødvendige information. Se ovenstående Klienten er en proxy for støttesystemet og udstiller samme services. Støttesystemet har ansvaret for at indekset opdateres når det er modtaget af klienten Sikkerhed er pt. under udarbejdelse, men hver sag og dokument har en myndighedskode (kommunekode), hver forespørgsel vil blive filtreret efter myndighedskode inden afsendelse. Såfremt tilslutningen af Modtagersystemet indeholder de rette tilladelser, så vil det være muligt at søge på ydelser for alle sager i indekset. Sikkerhed er pt. under udarbejdelse. Det er en god pointe som medtages KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 26/49

27 /FAQ Ydelsesindeks 25. Generelt - Hvorledes håndteres det hvis man tilslutter andre end kommuner f.eks. SU-styrelsen, som ikke må have adgang til ydelser fra UDK? og forventes understøttet Sikkerhed er pt. under udarbejdelse, tilslutning af afsendersystem og myndighed styres i rammearkitekturen. Ydelsesindeks vil indeholde data om autorisation af de enkelte forretningsobjekter, som skal håndhæves af modtagersystemet. 26. Generelt - Når man har samlet Sags- og Dokumentindeks, hvorfor er Ydelsesindeks ikke medtaget? 27. Generelt - Hvis ikke det garanteres via klienten at der etableres mulighed for lokal replika, bør der i stedet kravstilles mulighed for lokal replika udenfor klienten via services. Der skal etableres mekanismer til at garantere et opdateret lokalt replika af indekses. 28. Generelt - Hvorledes er det sikret, at Ydelsesindekset kan understøtte "Model for dataudvekslingsaftaler mellem myndigheder, UDK og Kommunerne"? 29. Hvem har ansvaret for at foretage oprydning i indekset? (håndtering af retention periode) Skal det eventuelt være muligt at sætte en levetid på oplysningerne, hvorefter de automatisk slettes? Der bør være en driftsproces omkring dette. Enten i støttesystemet eller i arbejdsgangene. 30. Hvorledes sikre integritet mellem indekset og de forskellige fagsystemer? Ydelsesindeks er pt. ikke medtaget, således at det er muligt specifikt på ydelse at konkurrenceudsætte, afgrænse tilsluttede systemer og måle servicemål Lokalt repository forventes at være en mulighed i klienten Modellen indgår som en del af analysegrundlaget for Ydelsesindeks Data i indekset er Afsendersystemets ansvar, og afsendersystemet skal således slette data, når data bliver slettet i Afsendersystemet. Data fra det Afsendersystemet vil være afsendersystemets ansvar. Integriteten af data fra støttesystemets opkoblingspunkt vil være leverandøren af støttesystemets ansvar. Ud over dette, så vil indekset indeholde en administrativ KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 27/49

28 /FAQ Ydelsesindeks grænseflade som kan bruges administrative brugere til afklaring i fejlsituationer 31. Hvorledes kan man genopbygge indekset? Afsendersystemet kan genopbygge indekset via de udstillede services, det vil ikke være muligt for indekset at genopbygge et afsendersystems data for et bestemt tidspunkt. 32. Hvorledes bliver indekset bygget initialt? Indekset vil blive opbygget som en del af udviklingskontrakten, hvor de første systemer og kommuner kobles på. 33. Er det muligt at angive hvornår en registrering indekset skal slettes? 34. Ved søgning/hent af data kan der være behov for at kunne angive, om man ønsker data kun for kommune/udk eller for begge (relevant ifbm. overblik på tværs af UDK/kommuner). 35. Hvordan kan fejl i indekset rettes op, hvis der opstår fejl af den ene eller anden grund? Skal der evt. være en metode til masseopdateringer? Nej, det vil skulle håndteres af fagsystemet. Understøttes for Sag og Dokument gennem søgning på OrganisationsID fra objekttypen Organisationsrelationer. Understøttes pt. ikke for Journalnotat eller Journalpost, men kan indføjes i krav 20 og krav 31 som søgekriterier. Fejl i indekset kan kun rettes op, såfremt afsendersystemet sender en opdatering. Det overvejes om der skal være en metode til masseimport. 36. Logning - Hvordan sikres transaktionsspor på tværs af anvendersystemer, klienter og indeks? Ansvaret for transaktionssporet end to end ligger ikke i støttesystemet, men det vil overvejes at medtage et transaktionsid i operationer 37. Hvorledes håndteres masseopdateringer til indekset, som følge af masserettelser i Masserettelser i Indekset styres ved at afsendersystemet kalder Indekset KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 28/49

29 /FAQ Ydelsesindeks afsendesystemet? via de udstillede services 38. Hvem har ansvaret for, at indekset opdateres efter, at Fagsystemet har kaldt Klienten? Når klienten har modtaget et kald med succes, så er det støttesystemets ansvar at indekset opdateres. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 29/49

30 3.7 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. Plancherne for Sags- og Dokumentindeks kan ses her. /FAQ Sags- og Dokumentindeks 1. Performance? Støttesystemets performance vil blive kravsat. Krav til afsendere af data om rettidig levering vil være en del af krav til anvendersystemer 2. Overvej ordet liste i forhold til en effektiv datastruktur til udveksling af data måske er en stor liste ikke effektiv. Leverandøren af Støttesystemet vil blive målt på svartider alt efter kompleksiteten i forespørgslen, en stort svarresultat vil forøge kompleksiteten. Snitfladen til støttesystemet forventes at gøre både simple og store lister mulige. 3. Hvad med arkivering af SAPA-sager? Støttesystemet understøtter ikke arkivering af sager, dvs. det er ikke et forvaltningsarkiv. Arkivering af SAPA sager ligger i regi af SAPA projektet. 4. Overvej at konsolidere Ydelsesindeks ind i Sags- og Dokumentindeks. 5. Mangler der eventuelt metadata (f.eks. fagspecifikke metadata) Ydelsesindeks er pt. ikke medtaget, således at det er muligt specifikt på ydelse at konkurrenceudsætte, afgrænse tilsluttede systemer og måle servicemål Støttesystemet vil, til at starte med, indeholde felter fra standarden, samt de felter, som er essentielle for transition og forretningen. Domæne eller fagspecifikke felter for sag er pt. Ikke med ud over bevilling, men forventes at kunne udvides i en senere fase. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 30/49

31 /FAQ Sags- og Dokumentindeks 6. I forbindelse med opret sag. Hvor lang tid går der før indekser er opdateret med nye data? 7. Sammenhæng til sundhedsområdet, kobling til NSI m.v. også i forhold til governance og arkitektur. Støttesystemets performance vil blive kravsat. Krav til afsendere af data om rettidig levering vil være en del af krav til anvendersystemer God pointe, der vil blive koordineret i et vist omfang. 8. Kommunikerer fag-/esdh systemer udelukkende med indekser vha klienter og ikke Beskedfordeler? 9. Behov for at få defineret mere tydeligt, hvad der skal opdateres i indekset ved f.eks. ændringer i Afsendersystemer. 10. Hvad gør man med sags-/dokument metadata, der ikke er indeholdt i standarden? 11. Idé: returner information om hvornår forekomster er opdateret. Støttesystemets snitflade er altid via Støttesystemets klienter. Det vil være muligt at integrere Støttesystemet til modtagelse af beskeder. Såfremt fagsystemets data har ændret sig vil indekset skulle opdateres, de præcise regler vil være afhængigt per fagområde. Krav forventes yderligere uddybet i krav til anvendersystemer. Disse kan medtages i støttesystemet som følge af en ændringsanmodning af kunden i en senere version. Felterne skal dog overvejes nøje, være generelt anvendelige og væsentlige for et overblik. Væsentlige fagspecifikke felter kan udtrykkes i modellen og generelt anvendelige bør først opløftes til standard. God ide som vil blive inddraget i det videre arbejde. 12. Hvad med anvendelse i regioner og staten? Der er endnu ikke truffet nogen bindende aftale med henholdsvis regioner eller staten om anvendelse af Sags- og Dokumentindeks. Det er bestemt en mulighed. 13. Søgning i indhold i dokumenter? Det er ikke muligt at søge i dokumentindhold. 14. ATP har brug for at se på tværs af Behovet medtages i analysen med kommuner, mens kommuner kun skal sikkerhed. have mulighed for at se egne data det skal løses af sikkerhed. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 31/49

32 /FAQ Sags- og Dokumentindeks 15. Tidlig beskrivelse og tilgængelighed i forhold til testmiljøer og dokumentation af disse (WSDL, schema m.v.) Input medtages til krav i Kontrakten. 16. Hvordan sikrer KOMBIT, at Afsendersystmer kan/vil levere data? 17. Hvem har ansvaret for data i Sags- og Dokumentindeks? 18. Hvor ligger dokumentet? Hvis dokumentet ligger i fag-/esdh systemet hvordan sikres performance så? 19. Hvordan håndteres dubletter? Samme sag kan eksistere i flere fag-/esdh systemer. Det bør sikres at incitamentsstrukturen for at anvende støttesystemerne er så favorabel som mulig. Derudover skal det rent teknisk være så nemt som muligt, under skyldig hensyntagen til den overordnede arkitektur. Derudover vil vi så vidt muligt anvende allerede eksisterende snitflader udviklet i klippekortsregi. Der pågår i øjeblikket arbejde for at afklare hvordan det kan gøres nemmest muligt. Myndigheden er dataejer, afsendersystemet er ansvarlig for opdateringen, Leverandøren af Støttesystemet er ansvarlig for driften. Dokumentindholdet befinder sig i Fag/ ESDH systemet. Performance fx ved åbning via klienthop vil ikke være en del Støttesystemet. Hvert forretningsobjekt har et UUID, der kan kun være et afsendersystem som ejer sags eller dokument instansen, men der kan i princippet godt være flere afsendersystemer som opdaterer om end synkronisering så må håndteres af afsendersystemerne. 20. Governance. En klar governancestrategi for støttesystemerne inklusive klienter forventes at være en del af Kontrakten. 21. Bekymring: Standarder kan måske være et problem i forhold til nogle fagområder i forhold til samlet overblik. Det er korrekt, at antallet af felter som medtages skal afvejes nøje. Succeskriteriet om, at der skal kunne gives et relevant sagsoverblik, kræver KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 32/49

33 /FAQ Sags- og Dokumentindeks at de væsentlige felter er medtaget, men som udgangspunkt findes specifikke felter for fagområder kun i fagsystemet som afsender data. 22. OIO standard? OIO standardens nuværende model bygger på en proces, hvori der er opbygget erfaringer fra leverandører og kunder og der er truffet en del designvalg. Støttesystemet bygger på OIO standarden og vil som hovedregel ikke ændre på standarden. 23. Sagsstatus? Overholder den standarden i indekserne? Vi vil kontrollere at attributter er korrekte ifølge standarden 24. Det er vigtigt, at der er flere typer af snitflader (REST, SOAP, SAML ) Støttesystemerne vil eksisterende i kontekst af rammearkitekturen og de protokoller (fx SAML). Hvis forretningsbehovet for flere protokoller og facader til samme snitflade er til stede, så vil det blive medtaget som nonfunktionelt krav. 25. Regler for statusskift? Støttesystemet sætter ikke forretningsregler for hvordan eller hvornår afsendersystemet opdaterer metadata i Støttesystemet, men Krav til Anvendersystemer vil blive beskrevet. 26. Oppetid for Sags- og Dokumentindeks (er det f.eks. 24/7)? Støttesystemet vil have relativt høje SLA krav omkring oppetid. 27. Opdateringsfrekvens? Hvordan sikres, at data er i realtid i forhold til Afsendersystemer? Og er det nødvendigt? Kontrakten vil sætte krav til Leverandøren af Støttesystemet i forhold til opdateringshastighed efter modtagelse af data. Afsendersystemets krav vil skulle aftales jf. Krav til Anvendersystemer. 28. Statens arkiver? Sags- og Dokumentindeks skal ikke aflevere data til Statens arkiver. 29. Synliggør hvilke leverandører og Det er et godt forslag, som kunne systemer, der er koblet på Sags- og medtages i projektet efter tildeling. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 33/49

34 /FAQ Sags- og Dokumentindeks Dokument indeks i hver enkelt kommune. Det sikrer gennemsigtighed. 30. Anvendelse af Beskedfordeler? Anvendelse af Beskedfordeler som afsendersystem til Sag og Dokumentindeks er ikke med, primært ønskes der ikke afhængigheder mellem Støttesystemerne i udviklingsfasen. 31. Leverandøropbakning? KOMBIT lægger stor vægt på dialog med Leverandører. 32. Hvem har ansvaret for at bygge klienter til Sags- og Dokumentindeks? Udvikling af Klienter til Sags- og Dokumentindeks er en del af støttesystemet. Drift af klienten i kommunerne er ikke direkte en del af udbuddet. 33. Hvem må se hvilke data? Sikkerhed er pt. under afklaring behov for dataafgrænsning fx tidsmæssig afgrænsning, afgrænsning efter organisatorisk indplacering er en del af afklaringen. 34. Kunne der være erfaringer at hente fra sundhedssektoren? NSI? Erfaringer fra NSI vil forsøges inddraget. 35. Hvordan styrer man udvidelse af Sags- og Dokumentindeks? Både i forhold til indhold og funktionalitet. 36. Synliggøre hop henvisning til notat om emnet. 37. SOA versus Event (brugen af Beskedfordeler). Udviklingen af Sags- og Dokumentindeks vil styres via den samarbejdsorganisation som er specificeret i Kontrakten. Forslag til udvidelser vil så vidt muligt inddrage leverandører og myndigheder Det vil blive uddybet. Der er truffet nogle designvalg som kombinerer SOA og EDA i den nuværende arkitektur. Dette er sket på baggrund af en række overvejelser. Disse overvejelser er beskrevet i en række dokumenter, som KOMBIT ved nærmere kontakt gerne henviser til. KOMBIT A/S Halfdansgade København S Tlf kombit@kombit.dk CVR Side 34/49