2013-04-22T22:00:00+00:00MEK Klik her for at angive tekst. Review af kravspecifikation for Støttesystemer Leverandører April 2013 KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/57
Indhold 1. Forord... 3 2. Feedback fra leverandører... 4 2.1 Sikkerhed... 5 2.2 Organisation... 10 2.3 Klassifikation... 13 2.4 Beskedfordeler... 15 2.5 Klienter... 20 2.6 Ydelsesindeks... 25 2.7 Sags- og Dokumentindeks... 28 2.8 Kontaktdata... 40 2.9 Advisservice... 43 2.10 Forretningskrav... 46 2.11 Drift og test... 47 3. Anbefalinger og bekymringer... 52 3.1 Anbefalinger... 52 3.2 Bekymringer... 53 4. Evaluering af workshoppen... 55 4.1 Bemærkninger... 57 KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 2/57
1. Forord Tak til de leverandører, 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. I alt deltog 19 leverandører med 34 deltagere i 8 workshops med fokus på review af kravspecifikationerne til støttesystemerne samt test, drift og forretningskrav. Det er muligt, at se de faldne bemærkninger samt svar som dialogen gav fra de respektive workshops nedenfor. På reviewmøderne var der bl.a. stor interesse for brugen af klienter ifm. støttesystemerne. Det blev derfor aftalt, at afholde endnu en workshop denne gang udelukkende med fokus på en Klienterne. Afholdt d. 7. maj 2013 i KL bygningen. Dette var en mulighed for, at leverandørerne sammen med KL og KOMBIT kunne vende eventuelle udfordringer i forbindelse med støttesystemsklienterne, og leverandørerne havde samtidig mulighed for at bidrage med anbefalinger til det videre arbejde med kravspecifikationerne. 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 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 3/57
2. Feedback fra leverandører Som sidste skridt i forberedelsen til udbuddet af støttesystemerne er der behov for, at leverandørerne 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 kravspecfikationernes informationsmodeller mv. de fælles offentlige sagog 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 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 4/57
2.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 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 UUID skal være unik og stå tydeligt i kravspecifikationen KOMBIT er i gang med at belyse nærmere hvordan et unikt bruger-id kan opnås. Det generelle UUID kan komme via staten. Der afventes yderligere afklaring. Alternativt kan man baseres sig på bruger-id er fra kommunens eget brugeradministrationssystem, der fødereres ind i den fælles løsning. 2 Behov for generelt UUID Se svar til spørgsmål 1. 3 UUID må ikke blive lige så vanskeligt Spørgsmålet bedes uddybet. at benytte som CPR 4 Brugere skal identificeres via samme Se svar til spørgsmål 1. UUID for hele Danmark 5 Hvordan håndteres dataafgrænsning? KOMBIT er i gang med at afklare dette område og vil være klar til næste version af kravspecifikationen. 6 Dataafgrænsning skal beskrives tydeligere Se svar nr. 5 KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 5/57
/FAQ Sikkerhed 7 Håndtering af AUTH til dataudsnit Eks: [Skolelederrolle; Skole] [Sundhedspleje; Børn tilknyttet] [Sagsbehandler_Læs; TeamA, TeamB] [Sagsbehandler_Skriv; TeamA] 8 Hvordan administreres stedfortrædere? 9 Sikre at kommunen kan vedligeholde eksterne brugere der skal have adgang til fagsystemer, men som ikke er brugere i kommunens egen infrastruktur. Kunne eventuelt være på kontrakt med at en leverandør holder nogle brugere for en kommune. F.eks. Jobcentrets andre aktører 10 Persistering/genbrug af fortolkning af roller ift. organisation og accessmanagement. Det kan være forskelligt, men nogle er ens. Kan dette gøres og hvordan? Se svar nr. 5 Dette håndteres via roller der tildeles til stedfortræderne i kommunens IdM/IAM system. Hvordan dette præcis gøres er kommuneindividuelt. Kommunen vil altid være ansvarlig for brugere der skal have adgang til kommunens systemer og data. Hvis der er et behov kan kommunen godt lade en leverandør håndtere dette for dem, så længe de kontraktuelle forhold er i orden mellem leverandør og kommunen og leverandører overholder de samme sikkerhedskrav som der stilles til kommunen. Spørgsmålet bedes uddybet KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 6/57
/FAQ Sikkerhed 11 Hvordan håndteres organisationsændringer? Kommunen varetager selv tildeling af roller til brugere via deres eget brugerog rettighedsadministrations system. Således vil håndtering af organisationsændringer være individuelt pr. kommune og primært være en opgave for kommunens egen brugeradministration. 12 Alle sager skal have en ejer i organisation 13 Jeg har rettigheder til en del af en organisation og ikke til egne data. 14 Hvordan håndteres sikkerhed ned på sags niveau? 15 Hvordan håndteres autorisation af flere kommuner der arbejder sammen? Og UDK? Rammearkitekturen understøtter rolle/rettighedsopsætning i forbindelse gennem kommunespecifikke opsætninger af roller i administrationsmodulet. Under afklaring Dette falder ind under dataafgrænsning se svar nr. 5 Dette falder ind under dataafgrænsning se svar nr. 5 Det er myndighedernes eget ansvar at godkende adgang til kommunens egne data. Modellen giver mulighed for at delegere rettigheder til andre myndigheder. 16 Hvordan håndteres tværfaglige roller? En bruger tildeles jobfunktionsroller, der er en samling af systemroller. En jobfunktionsrolle kan være tværfaglig idet den kan samle forskellige systemroller herunder systemroller fra forskellige systemer. 17 Hvilke roller skal ligge i administrationsmodulet? Jobfunktionsroller og systemroller samt en afbildning mellem disse ligger i administrationsmodulet. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 7/57
/FAQ Sikkerhed 18 Roller? APOS/ORG til IdM. Uden behov for flere moving parts. Hvad med at bruge eksisterende løsninger? 19 Lokalt vs. centralt. Hvordan sikre vi os at dette er konsistent ift. jobfunktionsroller? 20 Flere steder nævnes integration mellem lokal IdP og lokal IdM. Der tales om provisionering Snitfladen for integration fra lokal IdP til Administrationsmodulets indstillede services er dog ikke beskrevet. 21 Vil KOMBIT bruge serviceplatformen til at udstille sikkerhedsservices? 22 Erfaring fra LOS. Ikke ønske om gentagelse 23 Bekymring: At skulle samarbejde med IDM-leverandører 24 Vil der være et centralt master repositorie for ansatte Modellen er, at kommunen anvender deres egen (eksisterende) bruger- og rettighedsadministrationssystem til at administrerer deres brugeres rettigheder i rammearkitekturen. Der er således lagt op til genbrug af brugeradministrationsløsninger hos kommunerne. Tildeling af roller forbliver kommunespecifikt, således at det stadig sker i kommunens eget brugerrettighedssystem og ikke i administrationsmodulet. Det er ikke meningen at man skal provisionere brugere og rettigheder i traditionel forstand. KOMBIT er opmærksom på at sprogbrugen skal tilrettes. Under afklaring Noteret Modellen er at kommunen anvender deres egen (eksisterende) bruger- og rettighedsadministrationssystem til at administrerer deres brugeres rettigheder i rammearkitekturen. Der er altså ikke tale om at rammearkitekturen tilbyder en fælles IDM-løsning for kommunerne. Nej 25 NemID for ansatte skal uddybes Bliver uddybet til næste version af kravspecifikationen KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 8/57
/FAQ Sikkerhed 26 Er det realistisk at små kommuner selv kan administrere sikkerhed? 27 Lever sikkerhedsmodellen op til datatilsynets krav til niveau for bruger ved adgang til personfølsomme oplysninger over internettet? Uddybning af afsnittet assurance level. Da data er kommunernes eget ansvar, er det således også kommunernes eget ansvar at administrere sikkerheden. Hvis de ikke kan klare det, må man outsource opgaven. Ja. Sikkerhedsmodellen lever op til datatilsynets krav og den skal selvfølgelig endeligt godkendes inden udbud. Autentifikationen vil typisk ske på helt samme måde, som kommunerne gør i dag via AD på det interne domæne, og derfor er der meget lille forskel. Assurance level vil blive uddybet 28 Sammenspil med regioner, stat og SAML2 standarten er valgt netop fordi andre myndigheder den er udbredt i det offentlige. Eksempelvis er samtlige 150+ selvbetjeningsløsninger på NemLog-in og borger.dk bruger det, alle Virk-dk s løsninger bruger det, WAYF føderationen bruger det, og Miljøportalen bruger det. 29 Der mangler en drejebog for Overvejelser omkring drejebog er i implementering gang. 30 Krav til migrering, SLA svartider mv. er Disse vil blive tilgået via meget utydelige driftskontrakten. 31 Kommuner bør overveje prisstruktur Vil blive behandlet af udbudsteamet i på udbuddet. KOMBIT 32 Lige i øjet. Tak KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 9/57
2.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. /Organisation 1. Vi må ikke sende beskeder ud hvis en organisation er importeret => den er ikke autoritativ 2. Det må ikke være et minimumskrav at man kan have et redaktørmiljø. Det kan håndteres af de bitemporale data 3. Bliver det gradvis implementering? Hvordan er det tænkt? Beskeder kan ikke afsendes hvis en organisation er importeret da det antyder, at organisationen ikke kan betragtes som autoritativ, men vedligeholdes i en anden kilde. Denne kilde burde i stedet udsende beskeder Et redaktørmiljø er på nuværende tidspunkt ikke et minimumskrav. Den funktionalitet der tilbydes i et redaktør miljø kan håndteres anderledes ved brug af de bitemporale egenskaber. Nogle leverandører har andre bud på hvordan dette kan løses. Ja, der bliver en gradvis implementering. KOMBIT burde bidrage til udarbejdelsen af en udrulningsstrategi for Organisation i kommunerne. Hvordan skal de definere organisationer, hvad er minimum man kan starte med at registrere? Hvilke organisationer vil det give værdi at starte med for at få succes? Dette er under planlægning i KOMBIT. 4. Migrering og omkostninger: Lidt af gangen vs. big bang Tages til efterretning. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 10/57
/Organisation 5. Drift/SLA? Essentielt. Drift og SLA krav vil blive udarbejdet som del af udbudsmaterialet. 6. Import altid, export hvorfor? Der bør altid være mulighed for åbne snitflader. 7. Det er uklart hvilken grænseflade klienten tilbyder. KOMBIT arrangerer en workshop for leverandører om klienten. SOAP som grænseflade til klienten? Det ville være dejligt med valgmuligheder Skal klienten bruges? 8. Passiver/aktiver: Hvis man kan passivere, så giver det ikke mening at kunne aktivere 9. Governance omkring ændringer, hvordan skal det håndteres så fagsystemer kan nå at tilpasse sig? Hvordan understøttes at forskellige fagsystemer vil implementere en organisationsændring i forskellig takt? Tages til efterretning. Der er en opgave i, at få defineret en governance-struktur omkring ændringer til organisationer registreret i Organisation, således at leverandør systemer der anvender data fra Organisation får tid til at tilpasse sig ændringen. 10. Kan det passe at organisationssystemet ikke skal være synkront med hvad fagsystemet agerer på? 11. Bitemporale data på lav granularitet kan påvirke performance i negativ Denne beslutning er op til det enkelte fagsystem at beslutte. Organisation tilbyder tidstro opdatering. Ved at have bitemporale data på lavt niveau (altså på enkelte attributter) KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 11/57
/Organisation retning 12. Håndtering af relationer UD af organisationskomponenten, dvs. non UUID relationer kan f.eks. gå til legacy systemer Hvordan håndteres relationer uden UUID ved eksport til legacy systemer? Hvordan genkendes data, og ændringer på data af legacy systemet? 13. Organisationskomponent MDM med governancemodel med Decentral adm. + Enterprise Data kvalitet EDQ) 14. OIO specifikke services til at holde god performance ved hyppig brug 15. I informationsmodellen er der UUID på alle røde kasser, men hvad med de blå kasser? Ved ændringer i Organisation sendes der en besked via beskedfordeleren. Organisation giver samtidig mulighed for opdatering via operationer i støttesystemklienten. Der vil blive stillet SLA krav til alle snitflader i Organisation. KOMBIT få tydeliggjort dette i kravspec. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 12/57
2.3 Klassifikation Støttesystemet Klassifikation gør det 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 it-systemer lægger i eller læser fra de øvrige støttesystemer opmærkes med klassifikationer. Plancherne for Klassifikation kan ses her. /FAQ Klassifikation Hvad er et Klassifikationssystem i modsætning til klassifikation? Der er 3 begreber der i daglig tale omtales som klassifikation: Klassifikationssystem: F.eks. KLE, FORM, IM Kontoplan, Støttesystemet Klassifikation: Et støttesystem under kommunernes rammearkitektur som indeholder Klassifikationssystemer. Klassifikation: Klassifikationssystemer er opbygget af objekttyperne Klassifikation, Facet og Klasse. Hvor klassifikation altså er det objekt som samler de overordnet informationer for klassifikationssystemet. Se i øvrigt kravspecifikationens begrebsliste hvor alle 3 begreber er defineret. Hvorfor ligge STS roller ikke som et klassifikationssystem i støttesystemet Klassifikation? Hvad er sammenhæng til sikkerhedsmodellen? RA Sikkerhed bruger orgfunktion og systemrolle som er løst i støttesystemet Administrationsmodul for adgangsstyring. Dette set-up skal også virker i det nuværende kommunale systemlandskab, derfor er der valgt ikke at lave et klassifikationssystem for roller i støttesystemet Klassifikation. Støttesystemet Klassifikation bruger den kommunale rammearkitekturs Administrationsmodul for adgangsstyring fuldt ud, dvs. inklusiv brug af systemroller og afregning. Se KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 13/57
/FAQ Klassifikation --i øvrigt I kravspecifikations afsnit 6.8.1 Autorisation side 70 hvor dette er beskrevet og også har en forklarende figur. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 14/57
2.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 1Beskedkatalog mm. 1. 1Bør der være et beskedarkiv sammen med den centrale beskedfordeler? 2. 2Hvorfor laver i ikke en abonnementsservice og et arkiv for beskeder? 3. 3Info omkring hvad der kan abonneres på 4. 4Savner berigelser af abonnementstyper Savner governance af indhold i beskeder Kan støttesystem optræde som afsendersystem? Vi har planlagt at der skal være et katalog over mulige beskedtyper, man kan abonnere på. Det er ikke intentionen at der skal være et arkiv over gamle beskeder beskeder og relevant information om dem logges. Hvis man vil have adgang til sine gamle beskeder må man persistere dem selv, evt. ved at stille cachedatabase til rådighed for beskedfordelerklienten. Vi kigger på at kravsætte et abonnements API, således dele af et abonnementsudtryk kan opdateres ad denne vej. Ang. arkiv se ovenfor Se ovenfor Vi ser nærmere på dette og ser gerne skriftlige reviewkommentarer om samme. Indholdet i beskeder (som i payload) forholder Beskedfordeler sig ikke til. Men der er igangsat et standardiseringsarbejde i forhold til hvordan det skal/bør de ud. Dette KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 15/57
/FAQ Beskedfordeler foregår i regi af Forretningskravprojektet. Ja, støttesystemer kan også være både afsender og modtagere af beskeder 5. 5Kan støttesystemer ikke afsende Se ovenfor beskeder? - begrebsmodel 6. 6Sagsbehandlerens abonnement på Ja Advis er er for mennesker, enkelthændelser skal behandles som beskeder er for systemer advis 7. 7Slette/fortryd-protokol? En afsendt besked kan ikke slettes eller fortrydes men der kan sendes en efterfølgende rette-besked. 8. 8Mulighed for at trække beskeder Se ovenfor tilbage? Beskeder og kuvert 9. Payload og ansvar? Det er afsenders ansvar at payload er det rette det kan beskedfordeler ikke validere, da det vil være forretningsviden, der ligger til grund for dette.. Formen/strukturen for en besked arbejdes der på i regi af Forretningskravprojektet 10. 2Ingen data i beskeden Se ovenfor 11. Bitemporalitet kan være problematisk Det er ikke helt klart hvad der menes hvis beskeden indeholder data bedes uddybet 12. Koordinering i forhold til DIGST Der samarbejdes med DIGST i relation til udformningen af beskeder i regi af Forretningskravprojektet 13. Sætter lovgivningen ikke de ønskede Det er ikke helt klart hvad der menes krav til harmonisering over tid? bedes uddybet 14. Vi skal forholde os til beskedtypen Ja - se ovenfor 15. Burde der ikke være mulighed for andet end xml-beskeder? Det er ikke helt klart hvad der menes bedes uddybet Vi har ikke lagt os fast på et format beskedkuverten er illustreret i xml men det skal ikke ses som udtryk for KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 16/57
/FAQ Beskedfordeler 16. Beskedkuvertens indhold -> hændelsesbesked bør uddybes 17. Ruter på baggrund af UUID frem for kuverten? 18. Har datatilsynet været inde over? (en besked (kuvert) der indeholder CPR, emne (fx sygedagpenge m.m.) som gør den personfølsom) 19. Webservices vs. Synkron/asynkron Hvad har de synkrone kald gjort side de ikke er beskrevet? 20. Servicebaseret og ikke nødvendigvis kø-baseret 21. Beskedfordeleren spiller sammen med NSI, regioner etc. hvor er MOX? 22. Hvilke standard -databaser understøttes? krav Som beskrevet tidligere der arbejdes på payload ets form og struktur i regi af Forretningskravprojektet. Det er ikke den valgte granularitet beskedkuverten indeholder de informationer, der kan og skal rutes på. Tak for input vi undersøger om det er relevant Rent faktisk er der pt. alene beskrevet synkron integration mellem beskedfordelerklient og anvendersystem. Vi overvejer dog om også asynkrone kald mellem klient og anvendersystem skal understøttes Vi stiller alene servicemålkrav til integrationen mellem beskedfordeler og beskedfordelerklient, og vil dermed lade det være op til leverandøren at foreslå integrationsform- og teknik. MOX-projektets primære opgave er at afprøve en metode til integration mellem eksisterende systemer i kommunerne. Beskedfordeler er det fælleskommunale støttesystem, der skal kunne formidle beskeder mellem alle kommunernes systemer samt fra/til andre fællesoffentlige systemer. Som beskedkuverten er defineret pt. kan der sendes MOX-beskeder til beskedfordeleren, så længe kuverten populeres med de krævede data. Der vil blive stillet krav om at understøttelse skal ramme så bredt som muligt der vil ikke blive peget på specifikke produkter. Det må man ikke i offentlige udbud. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 17/57
/FAQ Beskedfordeler 23. Hvem er ansvarlig for fejl? Ændres praksis? 24. Hvordan er relationerne til den enkelte kommune og deres valg af andre beskedfordelere? Anvendelse Generelt vil det være sådan at funktionelle fejl i beskedfordeler og beskedfordeler klient er leverandøren ansvarlig for det drifts relaterede ansvar beskrives nærmere 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 beskederne kommer fra Beskedkuverten giver mulighed for at registrere beskedens rute. 25. Der skal kunne stilles krav om at nødvendige beskeder sendes 26. Specifik krav om anvendelse af beskedfordeler 27. Anvenderkrav til kommunernes udbud Der er det kommunernes ansvar for godkendelse 28. Husk at tage fat i de ledende konsulentfirmaer på udbudsområdet: A2, KL Devoteam, Rambøll m.fl. De små kommuners fagforvaltninger og udbudskonsulenter kan ikke overskue beskedfordeler i skal have nogle ambassadører blandt udbudskonsulentfirmaerne 29. Entydighed eller vejledning om serviceplatform vs. Beskedfordeler, når det handler om at lytte på CPRændringer Enig. Man skal som afsendersystem indgå aftale om hvilke beskeder man sender ud. Disse beskeder skal sendes ud. Se ovenfor Ja vi leverer et sæt af krav som kommunerne kan indarbejde i deres kravspecifikationer. Tilslutning af et system til beskedfordeler, kræver kommunens godkendelse Tak for input Det er taget til efterretning. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 18/57
/FAQ Beskedfordeler Kravspecifikationen 30. Hvorfor er der en specifik sikkerhedsmodel for beskedfordeler? Burde det ikke være dækket af Administrationsmodulet for Adgangsstyring? 31. cache benyttes lidt lemfældigt i beskrivelserne Brug anden beskrivelse 32. Ryd op i begrebsanvendelsen - Hændelser sker - Beskeder sendes Jo administrationsmodulet overtager registreringen af aftaler mv. Beskedfordeler skal så sørge for at enforce dem i relation til det enkelte anvendersystem, inklusiv ved oprettelse af abonnementer, og ved modtagelse af beskeder fra et afsendersystem. Det er taget til efterretning. Vi gennemgår kravspecifikationen med henblik på at ensrette begreberne. Der er nogle fine definitioner i advis scopedokumentet brug dem konsekvent! 33. Minimumskrav vs. Krav Ja dette arbejdes der videre på. 34. Kravene kan udelukke standardprodukter Kan aflives hvis 4-5 forhold fjernes 35. Erstatter i ikke 1 monopol med et andet? Vi vil meget gerne vide hvilke af vores krav, der vil udelukke standardprodukter. Send det venligst til os. Nej, ikke i den form det har haft hidtil men det er rigtigt at der vil være én leverandør af den fælleskommunale beskedfordeler (ad gangen). KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 19/57
2.5 Klienter I første version af støttesystemerne vil integrationen til fælleskommunale it-systemer mv. 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. 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. 1. 1Klienter er en god idé, men governance er vigtigt 2. 2Hvis I vil noget med standarder Hvor er governance? /FAQ Klienter Ja, vi er opmærksomme på at der skal en fornuftigt governancestrategi til. Ang. governance, se ovenfor 3. 3Den logiske tegning. Hvordan skal det vedligeholdes? 4. 4Hvorfor er det lettere at kalde en klient frem for at kalde det centrale støttesystem? Støttesystemleverandøren vedligeholder klienten hvordan dette opdateringer distribueres mv. forventes den kommende governancestrategi at adressere. Som vi har skrevet i dokumentet 1b Støttesystem klient v1.0 er der en række fordele ved klienten. Herunder understøttelse af høj grad af robusthed og høj grad af sikkerhed for at det et anvendersystem leverer til et støttesystem kommer sikkert frem. Dette har været væsentlige bekymringspunkter i tidligere dialoger med både kommuner og leverandører om støttesystemerne 5. 6Hvor mange klienter/teknologier Vi forventer at understøtte de forventer man at udvikle? vigtigste, udbredte teknologier. 6. 7KMD mener, at én samlet klient er en Dette kan også blive en mulighed på KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 20/57
fordel /FAQ Klienter 7. 8Klienter strider med en trend, der foreskriver online/realtids opslag. Kan der åbnes for direkte tilgang til det centrale støttesystem? 8. 9Klassifikation autoritativt system. Er der ikke for mange led, når nu de alligevel er embedded i de enkelte anvendersystemer? 9. 1 0 Ansvarsfordeling Den samme person på flere klienter. Hvor skal hvad caches? 10. 1Hvordan er ansvarsfordelingen i 1mellem legacysystemer og klienten længere sigt. Det har dog nogle ulemper som skitseret i dokumentet 1b Støttesystem klient v1.0 - primært her er at det komplicerer klienten betydeligt, samt at det forventes at antallet at støttesystemer kan ændre sig. Dernæst er der spørgsmål om hvem der i givet fald ville have ansvaret for en sådan fælles klient. Dette kan også blive en mulighed på længere sigt. Dette er skitseret i dokumentet 1b Støttesystem klient v1.0 og der kan være forskel på behovet for de forskellige støttesystemer Hvis man embedder sine klassifikationer i anvendersystemet, kan klienten anvendes som integration til støttesystemet alene. Som det er beskrevet i dokumentet 1b Støttesystem klient v1.0 er der krav om at alle klienter skal tilbyde den beskreven funktionalitet, der er ikke krav om at anvendersystemerne skal bruge det hele. Policy er tiltænkt relateret til kontekst. Støttesystemerne tilgås altid via et fagsystem (anvendersystem) der er dermed ikke brugere direkte på støttesystemklienterne. Så cachen vil være anvendersystemets ikke personers/brugeres hermed vil det være anvendersystemets opgave at sørge for at de rigtige informationer o.lign. præsentes for en given bruger af det givne system. Som beskrevet i dokumentet 1b Støttesystem klient v1.0 er ansvarsfordelingen den at Klienten leveres og vedligeholdes af leverandøren af støttesystemet. Klienten driftes nær KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 21/57
/FAQ Klienter anvendersystemet og af dettes leverandør af drift. 11. 1Hvorfor beriger man ikke fagsystemet 2med klient-funktionalitet, og derved undgå SLA problematik? Dette forventes at være scenariet for alle typer af anvendersystemer men vi vil gerne høre om der er systemer med specielle problemer i denne sammenhæng. Det kan være en mulighed på længere sigt. Men der er rigtig mange forskellige systemer i kommunerne og det er essentielt at så mange systemer som muligt hurtigt kan levere data til støttesystemerne. Dette vil klienterne hjælpe med at gøre på en enkel og billig måde for det enkelte kommunale system. Spørgsmål og kommentarer opsamlet på workshop d. 7. maj 2013 i KL Bygningen. /FAQ Klientworkshop 1 Det er et stort spring at gå fra ingenting i dag til decentrale klienter på alle kommunernes systemer. Det anbefales at starte med centrale klienter og herefter forsøge sig frem og stille og roligt udvide med decentrale klienter. Tages til efterretning. Hermed er målarkitekturen stadig den skitserede. 2 Hvor har i fået ideen fra? Klienter er bl.a. indført pga. sikkerhed, SLA og robusthed. De primære årsager til indførelse af KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 22/57
/FAQ Klientworkshop klienterne i arkitekturen er: Det ændrede systemlandskab fra det centraliserede mainframe baserede til det decentraliserede giver erfaringsmæssigt udfordringer i relation til at sikre robust, sikker og effektiv integration til støttesystemerne. Det har også være et udtalt krav fra kommunerne at integrationerne og data-forsyningssikkerheden sikres bedst muligt data, beskeder mv. må ikke gå tabt. Dernæst er det vigtig for understøttelsen af de berørte fagsystemers (inkl. SAPA) behov, at ikke alle alene de centrale fælleskommunale fagsystemer, men at også de kommunale fag og ESDH-systemer hurtigt kan komme til at benytte og levere data til støttesystemerne derfor skal det være nemt og billigt for alle typer af systemer at tilkoble sig støttesystemerne. Klienterne er derfor defineret til at indkapsle en del af den funktionalitet som er med til at sikre ovenstående ønsker og behov. 3 De leverandører, der er interesserede kunne modtage og benytte de decentrale klienter. Andre kunne benytte den direkte kontakt til det centrale støttesystem Det er et muligt set-up. Altså med de decentrale klienter som optioner i kontrakten. 4 Hvordan vil I drifte klienten? Den ligger i samme driftdomæne som anvendersystemet. Det er altså mere eller mindre op til leverandøren. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 23/57
/FAQ Klientworkshop 5 Hvor mange klienter forventer KOMBIT? Skal DUBU eksempelvis have 98 eller 1 klient? 6 Der er ingen fordel for at benytte cache på systemer hvor der skrives meget. DUBU vil få en klient pr. støttesystem, da der er tale om en instans. Ved eksempelvis økonomisystemer vil det se anderledes ud - 98 selvstændige klienter. Der er ikke noget krav til anvendersystemer om at benytte cache. Der er udelukkende et krav om, at det skal udvikles og klienten skal indeholde det som en grundfunktionalitet. 7 Der skal være en organisation, der kan planlægge og stå for test. 8 Fejlsøgninger er problematiske i forhold til det distribuerede ansvar for drift. Tages til efterretning. Taget til efterretning. Samarbejde er "enklere", hvis der er en sponsor. 9 Start med Klassifikation og Organisation i forhold til klienter. De kan så danne skole for brugen af klienter for de resterende støttesystemer. Tages til efterretning. 10 Klienterne stiller store krav til governance. Det anbefales derfor at benytte eksempelvis ITIL til styring af processer. 11 Decentrale databaser giver udfordringer - er ikke statiske - mange fejlkilder. Taget til efterretning. Taget til efterretning. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 24/57
2.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. 1 Motor der håndterer ydelser, dokumenter og sager findes som standardsoftware. F.eks. IBM 2. 2Ydelsesindeks som databærende? Nej fra leverandører. Fagsystemer håndterer selv ydelser. Indeks udelukkende passivt. 3. Fagsystem er ansvarlig for ydelser og beregning af disse. 4. Beregninger af ydelser kan centraliseres, men ansvar og dokumentation ligger fortsat i fagsystemet. 5. Ydelsesindeks kan med fordel eksponeres til borgere. Projektet stiller ikke krav om specifikke implementeringer, men det vil af tildelingskriterier fremgå, hvilken målarkitektur som ønskes Ydelsesindeks er udelukkende tænkt som et passivt indeks, der ikke holder master-data. Enig. Enig. Men det er ikke en del af scope for Ydelsesindeks. Det er ikke en del af Ydelsesindeks projektet at eksponere bevilgede ydelser til borgere. Men projektet stiller ingen hindringer for denne funktionalitet kan skabes i modtagersystemer. 6. Er UDK med i overvejelserne? Ja. UDK er medtaget og det tilstræbes at Støttesystemet understøtter den begrebsafklaring som sker mellem KOMBIT og ATP 7. Tilbudsportalen. Findes det i ydelsesindeks? Er der et ydelseskatalog i ydelsesindeks? De bevilgede ydelser fra afsendersystemer findes i ydelsesindeks, men pt. er kun ATP og fagsystemer i kommunerne i scope som afsendersystemer. Ydelsesindeks indeholder ikke et katalog KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 25/57
/FAQ Ydelsesindeks 8. Effektueringer og effektueringsplaner. Hvorfor er det med? 9. Ydelsesindeks har kun værdi, hvis alle ydelser og ydelsestyper er indeholdt. 10. Er der relationer til forskellige kataloger? I DUBU vælges ydelser fra et katalog. 11. Ydelsesindeks bør slås sammen med Sags- og Dokumentindeks. Det giver store fordele og en lavere pris. Ydelsesindeks skal skabe en oversigt over bl.a. en borgers ydelser på tværs af systemer. Her er visning af de fremtidige bevilgede ydelser (effektueringsplanen) og de udbetalte bevilgede ydelser(effektuering) et væsentligt forretningskrav. Ydelsesindeks projektet arbejder på at få beskrevet fysiske og ressourceydelser, så det ikke kun indeholder økonomiske ydelser. Ydelsesindekset har ikke relationer til bestemte klassifikationer af ydelser, men en bevilget ydelse kan have en nøgle til klassifikation og ydelsesart. 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. 12. Mange-til-mange relationer? Der er udtrykt et behov for at understøtte systemer som har mange sager per bevilling og vice versa. Det vil medtages i modellen. 13. Status på ydelser bør standardiseres. Ydelsesindeks projektet arbejder ikke på standardisering. Det bliver adresseret i anden sammenhæng i samarbejde med KL. 14. Bevilget versus afgørelse? Pt. er afgørelse ikke et selvstændigt forretningsobjekt i OIO sag og dokument standard Relationen mellem bevillingen og afgørelsen afhænger derfor af hvordan sagsbegrebet benyttes i afsendersystemet. I Ydelsesindeks er en relation til Sag fra Bevilling. 15. Brutto/netto. Skal håndteres. Enig. Pt. er det håndteret, men det overvejes om yderligere information er væsentlig og skal medtages. 16. Ydelsesindeks bør indeholde bitemporalitet. Ydelsesindeks projektet har som udgangspunkt fravalgt dette, eftersom KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 26/57
/FAQ Ydelsesindeks 17. Generelle egenskaber fra standarden bør implementeres i Ydelsesindeks. 18. Status på ændringer bør være med. F.eks. reduktion i kontanthjælp. man mener, at indekset kun holder den gældende forekomst. Se svar ovenfor vedr. bitemporalitet. En god pointe, informationsmodellen udvides med ændringsdato, begrundelsen vil skulle fremgå i fagsystemet. Enig. 19. Byg indekset på baggrund af eksisterende erfaringer. 20. Søg inspiration i f.eks. DHUV. Godt input. Det vil blive inddraget så vidt muligt. 21. Hvad har borgeren behov for at Se svar på spørgsmål 2. se/vide? 22. Governance af data i ydelsesindeks. Enig. Det er vigtigt. Data skal være korrekte. Især hvis man benytter indekset til sagsbehandlingsstøtte. 23. Ydelser bør standardiseres. Se svar på spørgsmål 2.. 24. Ydelsesindeks 3.2.1.1 Begreb Sagsrelation, godt princip med at Sagsrelation kan oprettes uden at sagen findes. 25. 3.3 AfsenderSystemNavn bør registreres i Organisation på ITSystem entitieten go afsendersystem id bør være relation til IT System registreret i ORganisation støttesystemet. 26. Krav #78 Hvad er en dobbeltoverførsel? Det er primært i forhold til transition og i forhold til at systemunderstøttelsen af Sagen og bevillingen ikke nødvendigvis foregår i samme afsendersystem Det er en god pointe, der vil overvejes en relation til Organisation, men der skal også tages højde for at dette måske ikke er tilfældet i en transitionsperiode. Det uddybes i materialet. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 27/57
2.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. 1Datamængder: Hvor mange transaktioner kommer der på Sagsog Dokumentindeks? Hvilke datastørrelser forventes på opdateringer? 2. 2Datamodeller: Er de egnede/optimale til de søgninger og rapporteringer, som Sags- og Dokumentindeks skal understøtte? 3. Periodeskift: Hvornår opdateres sager/dokumenter ved systemskift og periodeskift? Forudsætninger for datamængder er under udredning og forventes at være en del af beskrivelsen af Kundens miljø i Kontrakten Der opereres med informationsmodeller og der er kun få nonfunktionelle krav som vedrører datamodeller. Informationsmodellen bygger på OIO modellen og dialog med forretning om hvad som er væsentligt. Det forventes derfor at søgninger er understøttet. Visse rapporteringer er understøttet, men det er ikke hensigten at det skal bruges som LIS, her vil historik og styringsdata mangle, da det ikke er en del af modellen. Det er afsendersystemet som har ansvaret for data, der har ansvaret for at opdatere indekset. Ved periodeskift kan det medføre en større mængde sager og dokumenter som opdateres. Ved systemskift vil det nye afsendersystem skulle opdatere indekset såfremt det er nødvendigt. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 28/57
/FAQ Sags- og Dokumentindeks 4. Man skal være påpasselig med at kræve constraints og cardinaliteter 100 % i forhold til OIO standarden i forhold til Afsendersystemer. 5. Se på NSI erfaringer Enig. Godt input. 6. Afsender og Modtagersystemer skal tolke data på samme måde. 7. Er der transformation i det der vises i indekset? Der bør være så få som det kan forsvares. 8. Hvordan med den digitale kommunikation? 9. Funktionel løsning er MDM - administration af master og metadata. Hvilke ændringer systemskift og periodeskift må medføre for metadata og dermed opdateringer af indekset bestemmes af forretningsreglerne i Afsendersystemet Enig. Vi har i begrebsmodellen forsøgt at bløde op for dette krav. Modellen kan være fleksibel i forhold til nøgler til eksterne forretningsobjekter, men søgninger og håndhævelse af rettigheder skal være konsistent for at kunne benyttes af modtagersystemer, derfor vil modellen ikke være ret fleksibel i relationerne mellem forretningsobjekter indeholdt i sag og dokument standarder. Her vil det tilstræbes at understøtte standarden. Enig. Begrebsmodellen for indekset vil være den styrende definition. Sags- og Dokumentindeks vil forsøge at holde transformationer ude af projektet. Den opgave bør ligge hos Anvendersystemer. Det vægtes tungere at data mellem afsendersystem og indeks er så ens som muligt. Sags- og Dokumentindeks har ingen brugergrænseflade til slutbrugere. Det er derfor op til projekter, der skaber modtagersystemer at håndtere dette. Enig. Man kan søge inspiration i MDM. 10. OIO "arkiv" Afsendersystem? Umiddelbart er det væsentligt at det kan fremgå hvilket arkiv som sagen eller dokumentet hører til. Arkivstruktur standarden angiver KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 29/57
/FAQ Sags- og Dokumentindeks fremdrift, relationer og egenskaber, men det er kun UUID og titel som kan være relevant. 11. Bitemporalitet bør understøttes af Sags- og Dokumentindeks. F.eks.: Hvad så sagsbehandleren i indekset på en given dato. Det er nødvendigt, hvis indeksdata skal benyttes som beslutningsgrundlag i sagsbehandlingen. 12. Objekt UUID. Findes de i WSDL? F.eks. JournalpostUUID? 13. Livscyklus er ikke status. Passiv: Venter på input. Hvis den sættes på livscyklus ødelægges sagen. 14. Hvad med den tværgående forretningslogik? Sags- og Dokumentindeks har som udgangspunkt fravalgt håndtering af bitemporalitet, eftersom man mener, at indekset kun holder den gældende forekomst. Forretningsobjektet UUID findes med udgangspunkt i Generelle egenskaber for services på sags- og dokumentområdet - OIO-Godkendt [vs. 1.1] Her vil objekter (fx sag) have UUID som ObjektID og relationer (fx Journalpost) have referenceid som UUID Det forventes ikke at snitfladerne i Sags og dokumentindeks er 100 % i overensstemmelse med de WSDL filer som OIO har oprettet. Sags- og Dokumentindeks understøtter ikke bitemporære egenskaber, men medtager både sagsstatus og sagstilstand til at beskrive sagen. Det vil blive uddybet yderligere i teksten, så det fremgår mere klart og ensartet med standarden Sags- og Dokumentindeks er udelukkende et passivt indeks, der indeholder metadata om Sager og Dokumenter. Indekset vil ikke holde forretningslogik. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 30/57
/FAQ Sags- og Dokumentindeks 15. Journalpost til dokument bør være én til mange, og ikke én til én 16. Uddyb usecases/brugerscenarier for at give leverandørerne mulighed for at foreslå optimale løsninger. 17. Krav til fysisk realisering. Er de væsentlige for pris? (f.eks. brug af standardkomponenter). 18. Hvem bestiller og betaler for tilslutning til indeks (Afsendersystem)? 19. Tidligere end 2007. Gamle kommunenumre med tilhørende sagsbehandler. 20. Hvorfor skal vi tilbage til silosystemer? Burde sager og dokumenter ikke ligge i én central service? 21. Hvad er incitamentet for at koble et fagsystem på indekset? Det står ikke tydeligt i standarden, da der er en fejl i en af tabellerne, men der er kun 1 journalpost til 1 dokument. Indekset vil følge standarden på dette punkt Det er godt input som vil blive medtaget i udarbejdelsen af den endelige version. Der er ikke krav til en bestemt implementering. Men det vil fremgå af tildelingskriterier, hvad der foretrækkes som f.eks. anvendelse af standardkomponenter endvidere skal der gives en etableringspris. Den enkelte kommune skal på nuværende tidspunkt etablere tilslutning til indekset selve udarbejdelsen af snitfladen vil være en del af Kontrakten Godt input. Det skal analyseres nærmere. Sikkerhedsmodellen skal kunne håndtere data som stammer fra andre myndigheder i forbindelse med ressortomlægninger. Sags- og Dokumentindeks er ikke tænkt som et silosystem, men udelukkende som et passivt indeks med metadata om Sager og Dokumenter. Indekset er ikke en central master. Selve sagerne og dokumenterne ligger fortsat i fagsystemerne. Det er ikke i scope af Støttesystemerne at etablere en central service. Det vil være nødvendigt at tilslutte Afsendersystemer på tværs af det kommunale systemlandskab for at KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 31/57
/FAQ Sags- og Dokumentindeks give f.eks. SAPA projektet det nødvendige grundlag for at skabe overblik, men god pointe i at afsendersystemet skal have et incitament. 22. Samtykke. Hvordan håndteres det? I forhold til visning for sagsbehandler. 23. Compliance test? Hvis det ikke gennemføres kan systemer forurene data i indekser. 24. Hvad er forskellen på Sag og Sagsindeks? (i forhold til, at alle objekterne er importeret). 25. Med forskellige sagsbehandlere og sagstraditioner mellem systemer/forvaltninger kommer der også sikkerheds problematik. Hvem må vide hvad? Se hvad? Og med hvilke roller? 26. Sagsbegrebet ejes af fagsystemerne. Det betyder mange forskellige logikker skal håndteres i indeks. Det er en god pointe, Brugerens autentikation og medlemskab af grupper og roller afgøres af sikkerhedskomponenten i rammearkitekturen Enig. Kvaliteten af data i indekset er central komponent, men det kan nok forventes at indekset i transitionsperioden vil have data med forskellig datakvalitet. Sags- og Dokumentindeks er udelukkende et passivt indeks, der indeholder udvalgte metadata om sager og dokumenter. Indekset er ikke tænkt som master. Ved import tænkes ikke at sagen overdrages, men at indekset blot spejler fagsystemets data. Enig. Forklaring til sikkerhedsmodellen er under udarbejdelse på nuværende tidspunkt og en væsentlig del af leverancen. Sags- og Dokumentindeks afspejler de data, der ligger i de enkelte fagsystemer. Der implementeres ikke særskilt logik til at håndtere specielle situationer. Sags og dokumentindeks vil synliggøre forskelle og danne et udmærket grundlag for videre arbejde KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 32/57
/FAQ Sags- og Dokumentindeks med informations arkitektur for systemer, standarder og myndigheder, men det er ikke i scope af støttesystemet. 27. Definér en sags definitions standard Sags- og Dokumentindeks arbejder ikke på standardisering. Det bliver adresseret i anden sammenhæng i samarbejde med KL. 28. Migreringsstrategi. Vigtigt med et fælles sagsbegreb. 29. Hvad definerer om der er tale om en sag? 30. Formål: Skabe overblik over metadata i fagsystemer. Hvad er metadata? 31. Hvordan er det anderledes end KMD Sag? 32. Journalpost defineres som en beskrivelse af en handling på sagen. Bliver det rigtigt? 33. Hvordan håndteres sletning efter persondatalovgivningen? Der er måske mere tale om eksport end migrering siden ejerskabet af sagen og dokumenter holdes af afsendersystemet. Sags og dokumentindeks kræver ikke en ensretning af sagsbegreber for at kunne fungere. Indekset vil som udgangspunkt afspejle de data som forefindes i fagsystemet. Se svar på spørgsmål 1. Fagsystemet har dette ansvar. Metadata er defineret i Sags- og Dokument begrebsmodel. Sags- og dokumentindeks afspejler kun sager og dokumenter der findes i andre systemer. Derudover vil indekset i højere grad end KMD sag afspejle data der findes i ikke-kmd systemer. Sagsindeks har i modsætning til KMD sag ikke sin egen brugergrænseflade, men kan udstille data i andre modtagersystemer, herunder SAPA. Definitionen præciseres. Det er afsendersystemets ansvar at slette data korrekt i indekset. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 33/57
/FAQ Sags- og Dokumentindeks 34. Specialisér genstand. Umiddelbart er det tænkt således at specialiseringer vil være optioner som kan indløses 35. Historik fra før 2007 (kommunalreformen). Enig. Umiddelbart skal det analyseres i forhold til kommunekoder og rettigheder. Derudover burde historisk data kunne importeres til indekset i en transitionsperiode i den datakvalitet som findes i afsendersystemets arkiv. Se svar på spørgsmål 2. 36. Migrering af historik? Indekset lagrer ikke historik på fx enkelte sager, men historiske sager kunne være relevant Se svar på spørgsmål 2. 37. Der kommer domæne specifikke versioner af sag og dokument. Som f.eks. KY. Sag og dokumentindeks indeholder generisk data til overblik over sager, men som udgangspunkt ikke domænespecifik data. Der kan dog være nødvendigt at udvide med enkel væsentlig information fx bevilling, men det tænkes indeholdt i specialiseringer af sagsgenstand. 38. Genstand: mangler definition og proces. Umiddelbart ser definitionen ud til at være der, men sagsgenstand er en del af sag. Det vil blive uddybet. 39. Sagstandard kan kobles med lovgivning/klassifikation? 40. Fagsystem skal IKKE selv bestemme indhold i metadata. 41. Hvis der ikke findes et samlet fælles overblik over hvilke metadata, der implementeres, vil det blive svært at udnytte indekset i praksis. OIO Ja, det vil være muligt at angive en relation til klassifikation og organisation. Umiddelbart vil der ikke være tvungne krav til udfaldsrum i de fleste attributter. Sagsoverblik vil indeholde metadata fra forskellige systemer med divergerende datakvalitet og definitioner i en transitionsfase. Det vil KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 34/57