Bilaga 2 Beskrivning av projektet och dess leveranser

Bilaga 2 Beskrivning av projektet och dess leveranser 1 (28) PVS 937-6118/12 1.0 Bilaga 2 Beskrivning av projektet och dess leveranser

Bilaga 2 Beskrivning av projektet och dess leveranser 2 (28) PVS 937-6118/12 1.0 INNEHÅLL 1 DETTA DOKUMENT... 4 1.1 Begrepp... 4 2 PROJEKT DIGITAL ARKIVTJÄNST... 5 2.1 Bakgrund... 5 2.2 Projektbeskrivning... 6 2.3 Intressenter... 8 3 PROJEKTORGANISATION... 8 3.1 Organisation... 8 3.2 Styrgrupper... 9 4 LEVERANS AV SYSTEMET... 10 5 LEVERANSETAPPER... 10 5.1 Etappernas leveranser och tidplaner... 11 5.2 Etapp 1... 11 5.3 Etapp 2... 13 5.4 Etapp 3... 16 5.5 Etapp 4... 18 6 OPTIONER... 20 6.1 Ny lagringslösning... 20 6.2 Option integrering med lagringslösning... 21 6.3 Option migrering... 23 7 ÖVRIGA ÅTAGANDEN... 25 7.1 Resurser... 25 7.2 Utförande i beställarens lokaler... 26 7.3 Kompetensöverföring... 26 7.4 Testdata... 26 7.5 Grunddata... 26 8 ÖVERLÄMNING OCH STÄNGNING AV PROJEKT... 26 8.1 Överlämning till beställaren... 26 8.2 Projektavslut... 27 9 PROJEKTDOKUMENTATION OCH RAPPORTERING... 27 9.1 Projektdokumentation... 27 9.2 Statusrapportering... 27 9.3 Finansiell rapportering... 27 10 KOMMUNIKATIONSPLAN... 27

Bilaga 2 Beskrivning av projektet och dess leveranser 3 (28) PVS 937-6118/12 1.0 shistorik Datum Ändring Handläggare 1.0 2012-10-19 Ann Rosenlind

Bilaga 2 Beskrivning av projektet och dess leveranser 4 (28) PVS 937-6118/12 1.0 1 Detta dokument Detta dokument beskriver projekt med tillhörande delprojekt i form av Leverantörens införandeprojekt. Dokumentet ger en bakgrundsbeskrivning, beskrivning av främst Införandeprojektets leveranser med ansvarsfördelning mellan Rikspolisstyrelsen (RPS) och Leverantören samt beskrivning av optioner vad gäller integrering med lagringslösning samt migrering. 1.1 Begrepp För e-arkivets centrala begrepp finns en begreppsmodell framtagen. Begreppsmodellen omfattar: - arkivredovisning, - e-arkivets funktionsområden För begrepp se bilaga 9, Begreppsmodell för e-arkivet. Inom RPS projekt används två centrala begrepp: e-arkiv samt. Med e-arkiv avses Systemet. omfattar både e-arkivet och arkiveringsprocessen, riktlinjer och handläggarstöd för att arbeta i e-arkivet. Figur 1 Förhållande e-arkiv

Bilaga 2 Beskrivning av projektet och dess leveranser 5 (28) PVS 937-6118/12 1.0 2 Projekt Syftet med avsnitt 2 är att ge allmän information om projektet Digital arkivtjänst. 2.1 Bakgrund Polisens 28 000 anställda använder sig dagligen av ett eller flera systemstöd för att utföra sina arbetsuppgifter. Totalt skapas ca 1,8 miljoner nya pappersakter per år. Trots att det mesta av verksamhetens information inkommer eller upprättas digitalt är det enbart en mindre del som hanteras digitalt under hela informationens livscykel. Arkivering sker istället nästan uteslutande på papper. Rikspolisstyrelsen (RPS) bedriver ett omfattande moderniseringsarbete och inför digitala processer inom Polisen. Förändringsarbetet innebär att ett antal äldre system behöver kunna ställa av sin information till ett e-arkiv och att system löpande behöver kunna leverera till ett e-arkiv. Även den polisdatalag som trädde i kraft 1 mars 2012 driver införandet av ett e-arkiv. Lagen reglerar hur Polisen får behandla personuppgifter i sin brottsbekämpande verksamhet. Bland annat införs regler för när uppgifter ska gallras eller överföras till ett e-arkiv. Med hänsyn taget till övergångsregler måste det blivande e-arkivet vara i full drift och ha tagit emot bevarandematerial från system som omfattas av polisdatalagen senast 31/12 2014. RPS projekt för ansvarar för att: - Implementera ett för Polisen nationellt e-arkiv - Beskriva en arkiveringsprocess - Utforma riktlinjer och verksamhetsstöd för digital arkivering - Produktionssätta tjänsten på alla myndigheter inom Polisen - Genomföra anslutning av fyra centrala system - Överlämning till drift och förvaltning Inom ramen för RPS projekt för ingår också ett delprojekt för införande. Införandeprojektet ägs och drivs av Leverantören och innefattar att leverera ett standardsystem 1 med tillhörande anpassningar för att möta överenskomna krav. Leverantörens införandeprojekt har ett antal definierade leveranser t.o.m. produktionssättning. 1 För Polisens definition av standardsystem se avsnitt Teknik och förvaltningsmål 2.2.3.

Bilaga 2 Beskrivning av projektet och dess leveranser 6 (28) PVS 937-6118/12 1.0 2.2 Projektbeskrivning Polisens vision är en nationell digital tjänst för långsiktig bevarande av information och i vilken arkivering sker på ett säkert, effektivt och juridiskt korrekt sätt över hela polisväsendet. Detta på ett sätt som stödjer kärnverksamheten. Som en följd av har Polisen upphört att arkivera på papper, cd- och dvd-skivor och filkataloger. 2.2.1 RPS projekts effektmål Nedan listas s effektmål: Säker informationshantering - Hållbart över tid: informationen ska finnas kvar och vara läsbar över tid, trots mjuk- och hårdvaruuppdateringar. - Autentiskt: informationen ska vara oförvanskad och behöriga personer ska komma åt rätt information. Effektiv informationshantering - Enkelt det ska vara enkelt att söka och hitta informationen i systemet. - Samlade ärenden lösningen ska möjliggöra att all information om ett ärende lagras och hämtas på ett ställe. - En samlad arkivredovisning lösningen ska kunna redovisa både elektronisk och analog information. - Enkelt att ansluta och leverera det får inte vara för höga hinder för att ansluta till e-arkivet samt att det ska vara beskaffat med flera anslutningssätt. Behovet från verksamheten och möjligheten att möta behovet ska styra. Juridiskt korrekt informationshantering - Logiskt avskild information - e-arkivet ska vara gemensamt för alla myndigheter inom Polisen, men respektive myndighet ska kunna ha var sitt arkiv, logiskt avskilt från de andra. - Stödja olika leveransscenarion lösningen ska kunna ta emot leveranser av information när verksamheten behöver leverera för att bland annat uppfylla polisdatalagens krav. 2.2.2 Projektmål för För att möta upp till bestämda effektmål ska RPS projekt för Digital arkivtjänst leverera både en teknisk lösning för e-arkivering samt därtill kopplade verksamhetsregler i form av en gemensam digital arkiverings-

Bilaga 2 Beskrivning av projektet och dess leveranser 7 (28) PVS 937-6118/12 1.0 process med tillhörande delprocesser och riktlinjer och rutiner för att leverera, ta emot, förvalta/framtidssäkra och tillhandahålla information samt etablera och lämna över till en förvaltning. 2.2.3 Teknik och förvaltningsmål Utifrån målsättningarna i Polisens nationella it-strategi år 2010-2015 ska e- arkivet bygga på ett standardsystem. Med standardsystem avses ett system som innehåller ett antal väldefinierade och färdigutvecklade funktioner med tillhörande gränssnitt för att kunna ta emot, lagra, vårda, söka och lämna ut handlingar. Med färdigutvecklade funktioner avses kod som tillhandahålls, supporteras, underhålls och vidareutvecklas av leverantören. Ett standardsystem kan anpassas till Polisens verksamhet utan att förstöra eller försvåra möjligheter till införande av nya releaser från leverantören. Ett standardsystem kan i sin tur, av leverantören, vara sammansatt av flera komponenter såsom olika system, plattformar, 3:e parts produkter etc. Ur RPS perspektiv är standardsystemet dock en helhet med en leverantör och där RPS inte ska behöva hantera eventuella problem mellan ingående komponenter. Utifrån förvaltningsmål ska det standardsystem som leverantören tillhandahåller i så hög grad som möjligt kunna driftas och förvaltas utan beroende av leverantören. Det kräver att leveransen innehåller tillräckligt med dokumentation och kunskapsöverföring för att Polisen själva ska kunna ta över ansvaret. Det kräver också att standardsystemet är så uppbyggt att det i hög grad kan förvaltas och driftas genom konfiguration tillgängliga via någon form av applikation. För ett högt leverantörsoberoende specifikt för ett e- arkiv menas att RPS själva ska kunna definiera och sätta upp på vilket sätt systemet ska kunna ta emot leveranser, hur informationen ska vårdas samt kunna genomföra en komplett utlämning/ flytt av information till andra plattformar eller andra arkiv. I leverantörsoberoende inbegrips även att om leverantörens verksamhet avslutas ska RPS kunna få tillgång till koden för standardsystemet.

Bilaga 2 Beskrivning av projektet och dess leveranser 8 (28) PVS 937-6118/12 1.0 2.3 Intressenter För har följande intressenter identifierats: Figur 2 Intressenter för 3 Projektorganisation 3.1 Organisation RPS projekt för drivs inom ramen för programmet Effektiv allmän ärendehantering (EIM-A). Programmet ägs av Rikspolisstyrelsens Rättsavdelning. Se nedanstående organisationsskiss:

Bilaga 2 Beskrivning av projektet och dess leveranser 9 (28) PVS 937-6118/12 1.0 Figur 3 Projektorganisation (EIM-A) 3.2 Styrgrupper Styrning sker på två nivåer, på programnivå och projektnivå med följande frekvens enligt nedan. Leverantörens representant ska delta vid dessa möten. Projektstyrgrupp Frekvens: 1 gång per månad Styrgruppsordförande: RPS affärsansvarig Föredragande: Deltar: Inriktning: Projektledaren för och projektledaren för Leverantörens införandeprojekt Representanter RPS och Leverantörens affärsansvarig Uppföljning projekt (status, planering, risk) frågeställningar och beslut inom ramen för definierade mål, tids- och kostnadsramar. Rekommendationer till strategiska frågor och förändringar av projektets ramar. Programstyrgrupp Frekvens: 1 gång per månad Styrgruppsordförande: Programägare Föredragande: Deltar: Programledare Representanter RPS och polismyndigheter

Bilaga 2 Beskrivning av projektet och dess leveranser 10 (28) PVS 937-6118/12 1.0 Inriktning: Uppföljning projekt (status, planering, risk) Beslut strategiska frågeställningar, initiering och avslut av projekt samt förändringar av ingående projektens ramar. 4 Leverans av Systemet För varje överenskommet krav ska RPS acceptanstesta och godkänna Leverantörens leveranser. För acceptanstest se vidare under bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering. 5 Leveransetapper RPS projekt för är indelat i sex leveransetapper, varav Leverantören kommer att vara delaktig i de fyra första leveransetapperna. Projektplanering sker under hösten 2012 och planerad start för införande projektet sker tidigast 7 januari 2013. I nedanstående bild beskrivs leveranserna översiktligt där RPS leveranser är markerade med grått och Leverantörens med gult. Figur 4 Leveransetapper Leverantören - RPS

Bilaga 2 Beskrivning av projektet och dess leveranser 11 (28) PVS 937-6118/12 1.0 5.1 Etappernas leveranser och tidplaner Utifrån Leverantörens införandeprojekt listas nedan, per leveransetapp; omfattning, förväntade leveranser av såväl RPS som Leverantör, avtalade tider samt godkännandepunkter. Angivna avtalade tider avser den bortre gränsen för en leverans. Acceptanstest ska dock kunna påbörjas senast åtta (8) månader 2 från införandeprojektets start. 5.2 Etapp 1 Etapp 1 startar enligt ramavtal. 5.2.1 Etappens omfattning Etapp 1 omfattar projektuppstart och projektetablering. Vidare omfattar etappen att Leverantören tillgängliggör e-arkivet med standardkonfiguration samt utbildar RPS projektmedlemmar i systemet. Baserad på denna installation acceptanstestar RPS gjord leverans. Detta ska göras i testmiljö hos RPS. 5.2.2 Leverans av standardsystem i etapp 1 Det standardsystem som Leverantören ska kunna tillhandahålla direkt vid avtalstecknande ska vara fullt körbart på en av Leverantören definierad testmiljö hos RPS. Funktionaliteten för det standardsystem som levereras ska omfatta minst 65 % av samtliga skall-krav och minst 50 % av de bör-krav som Leverantören angivit i bilaga 1 Kravspecifikation. Standardsystemet ska tillhandahållas med standardkonfiguration, standard inleveransspecifikation samt tillhandahållet testdata. 5.2.3 RPS leveranser RPS leveranser etapp 1 i relation till Leverantörens införandeprojekt: 1. uppdaterad projektplan, inklusive aktivitetsplan och riskanalys, 2. uppsatt test- och utbildningsmiljö enligt Leverantörens anvisningar, 3. medverkande vid installation av standardsystem i test- resp. utbildningsmiljö, 4. testplan och testfall, 2 En (1) månad definieras som trettio (30) kalenderdagar

Bilaga 2 Beskrivning av projektet och dess leveranser 12 (28) PVS 937-6118/12 1.0 5. acceptanstest av standardsystem, 6. testprotokoll med tillhörande testrapporter avseende acceptanstester av standardsystem. 5.2.4 Leverantörens avtalade leveranser Leverantörens avtalade leveranser för etapp 1: 1. etablerad projektorganisation, 2. projektplan, inklusive aktivitetsplan och riskanalys, 3. dokumenterad anvisning på uppsättning av en test- och en utbildningsmiljö 3, 4. stöd vid uppsättning av test- och utbildningsmiljö, 5. installation av standardsystem etapp 1 med tillhörande standardkonfiguration, testdata på uppsatt test- respektive utbildningsmiljö 4, 6. verifiering att standardsystemet är korrekt uppsatt på test- respektive utbildningsmiljö, 7. leverans av dokumentation enligt Avtal och tillhörande standardsystem, 8. utbildning av projektmedlemmar på standardsystem, max 10 personer, 9. stöd under RPS acceptanstestperiod, 10. analys och felsökning av inkomna skriftliga testrapporter, 11. felavhjälpning, 12. om identifierade fel skriftlig åtgärdsplan för identifierade fel, 13. om identifierade fel rättningsreleaser installerade på test- och utbildningsmiljö. 5.2.5 Avtalade tider Avtalade tider etapp 1: - Leverantörens installation och verifiering av standardsystem ska ske inom fjorton (14) kalenderdagar efter installerad test- och utbildningsmiljö. - Acceptanstest och leveransgodkännande av standardsystemet i etapp 1 ska vara genomförd inom en (1) månad efter installerat standardsystem. 3 Avser installation av hårdvara, operativsystem och databaser. 4 För vad som omfattas i systemleveransen se ovan avsnitt 5.2.2 Leverans av standardsystem i etapp 1.

Bilaga 2 Beskrivning av projektet och dess leveranser 13 (28) PVS 937-6118/12 1.0 5.2.6 Godkännande För godkännande av leverans standardsystem, etapp 1: - För godkännande av standardsystem får det inte finnas några fel/brister på nivå 1 Blockerande eller nivå 2 Hindrande. Om det finns fel/brister på nivå 1 eller 2 efter avtalad acceptanstestperiod varvid ett leveransgodkännande inte kan ges räknas detta som leveransförsening. Därtill ska åtgärder av fel/brister på nivå 3 Störande, max få uppgå 10 st. i en överenskommen restlista, samt ha en överenskommen åtgärdstid. - Fel/brister på nivå 4 Kosmetiska hindrar inte godkännande, men de ska vara åtgärdade till nästkommande kompletta release. För definition av fel/brister se bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering. 5.3 Etapp 2 Etapp 2 startar omedelbart efter godkänd etapp 1. 5.3.1 Etappens omfattning Etappen omfattar att färdigställa och leverera avtalat system och avtalad dokumentation. Leveransen omfattar alla anpassningar för RPS. Anpassningar kan levereras både i form av konfiguration eller utveckling. Vilka krav som kräver anpassningar och därmed behöver detaljspecificering och eventuell teknisk design framgår i definierade krav i bilaga 1, Kravspecifikation på två sätt: 1. I kolumn F, Anmärkning, har RPS angett "Innehåll detaljspecificeras" om kravet innehållsmässigt behöver RPS-anpassas genom konfigurering av en standard- eller av Leverantören utvecklad funktion. Detta kan innebära att RPS anger värden eller urval. Exempel på det som avses: kravet är en gallringsfunktion, men vilka gallringsregler som ska kunna tillämpas måste detaljspecificeras och sedan realiseras. 2. I kolumn K, Realiseras, har Leverantören angett behov av detaljspecificering genom att ange K = konfiguration (ingår i standardsystemet, men måste konfigureras för RPS räkning) eller U = utveckling (måste utvecklas för RPS räkning). Har Leverantören i angiven kolumn istället angett: S = standard (ingår i standardsystemet) så förutsätts att kravet inte behöver detaljspecificeras. Utöver att genomföra anpassningar som framgår från kravspecifikation i bilaga 1 ingår även i etappen att realisera de integrationer som definieras

Bilaga 2 Beskrivning av projektet och dess leveranser 14 (28) PVS 937-6118/12 1.0 nedan under avsnitt 5.3.3 Integrationer med omvärlden. För detta ansvarar Leverantören. Vidare omfattar etappen att Leverantören i RPS verifierar avtalad prestanda samt att RPS acceptanstestar hela leveransen hos RPS samt granskar avtalad dokumentation 5.3.2 Leverans av avtalat system och dokumentation i etapp 2 Leveransen för etapp 2 omfattar 100 % av alla skall-krav och 100 % av alla överenskomna bör-krav definierade i bilaga 1, Kravspecifikation. För framtagning av en detaljerad kravspecifikation och tillhörande teknisk designspecifikation ansvarar Leverantören och RPS deltar. Framtagna specifikationer ska godkännas av RPS. Senast på avtalad leveransdag ska avtalat System vara installerat i RPS testmiljö och all avtalad dokumentation överlämnad. Till avtalad leveransdag ska Leverantören också visa på att avtalad prestanda kan uppnås i en produktionsmiljö. Detta genom att verifiera på ett sådant sätt att testen blir så produktionslik som möjligt. Behövs speciell programvara för att påvisa prestandan ska denna tillhandahållas av Leverantören under testperioden. Denna programvara ska efter godkänd prestandatest avinstalleras från RPS miljö. RPS ansvarar för att grunddata är levererad eller registrerad enligt Leverantörens dokumenterade anvisningar. 5.3.3 Integrationer med omvärlden Leverantörens åtagande innefattar realisering av nedanstående integrationer. Kravkolumnen refererar till relaterade krav i bilaga 1 Kravspecifikation. Integration Refererade krav Kommentar Behörighetssystem IFS 228- IFS 238 Active Directory med Kerberosverifiering Polisens händelselogg IFS 205 IFS 226 E-post IFT 242 F 309 Inleveransarea F 216 Anslutning pilotsystem Exchange Server Bilaga 4, Inleveransspecifikation

Bilaga 2 Beskrivning av projektet och dess leveranser 15 (28) PVS 937-6118/12 1.0 Övervakning, fånga systemmeddelande IFT 239 IFT 241 Adobe LiveCycle ES3 F 281 F 282 5.3.4 RPS leveranser RPS leveranser etapp 2 i relation till Leverantörens införandeprojekt: 1. uppsatt produktionsmiljö enligt Leverantörens anvisningar 5, 2. deltagande i detaljering av krav och teknisk designarbete, 3. skriftligt godkänna detaljkrav- och teknisk designspecifikation, 4. tillhandahållande och registrering av grunddata enligt Leverantörens anvisningar, 5. medverka i genomförande av integrationer med omvärlden, 6. medverka vid installation av avtalat system i test-, utbildningsmiljö, 7. installation av avtalat system i produktionsmiljön, 8. testplaner och testfall, 9. testdata, 10. acceptanstest av avtalad leverans, exklusive prestandatester, 11. testprotokoll med tillhörande testrapporter avseende acceptanstest av avtalad leverans. 5.3.5 Leverantörens avtalade leveranser Leverantörens avtalade leveranser för etapp 2: 1. detaljkravspecifikation och teknisk designspecifikation utifrån avtalad leverans, 2. vara RPS behjälplig med vilken grunddata och hur denna ska läggas in. Vid större register ska Leverantören vara behjälplig att läsa in grunddata, 3. vid behov uppdateringar av anvisningar på hur test-, utbildnings- och produktionsmiljö sätts upp, 4. leverans av avtalat System inkluderande anpassningar 6, 5. leverans av integrationer med omvärlden 7, 6. installation av avtalat System i test- och utbildningsmiljö, 5 Avser installation av hårdvara, operativsystem och databaser. 6 För vad som omfattas i systemleveransen se ovan avsnitt 5.3.2 Leverans av avtalat System och avtalat dokumentation i etapp 2 7 För vad som omfattas, se ovan avsnitt 5.3.3 Integrationer med omvärlden

Bilaga 2 Beskrivning av projektet och dess leveranser 16 (28) PVS 937-6118/12 1.0 7. stöd vid installation av avtalat System i produktionsmiljö, 8. verifiering av avtalad prestanda i produktionsmiljö utifrån avtalade krav, 9. skriftlig rapport på hur verifiering av prestanda har genomförts, utfall och eventuell åtgärdsplan, 10. verifiering att avtalad leverans är korrekt uppsatt i alla tre definierade miljöer, 11. stöd under RPS acceptanstestperiod, 12. analys och felsökning av inkomna skriftliga testrapporter, 13. felavhjälpning, 14. om identifierade fel - skriftlig åtgärdsplan för identifierade fel, 15. om identifierade fel rättningsreleaser installerade på test- och utbildningsmiljö samt stödja införande av rättningsreleaser i produktionsmiljö. 5.3.6 Avtalade tider Avtalade tider för etapp 2: - Leveransdag av avtalad leverans ska ske senast åtta (8) månader efter Avtalets undertecknande. - Acceptanstest av leverans i etapp 2 ska vara genomförd inom en (1) månad efter faktiskt leveransdag. 5.3.7 Godkännande För godkännande av avtalad leverans, etapp 2: - För godkännande av avtalad leverans etapp 2 får det inte finnas några fel/brister på nivå 1 Blockerande eller nivå 2 Hindrande. Om det finns fel/brister på nivå 1 eller 2 efter avtalad acceptanstestperiod varvid ett leveransgodkännande inte kan ges räknas detta som leveransförsening. Därtill ska åtgärder av fel/brister på nivå 3 Störande, max få uppgå 10 st. i en överenskommen restlista, samt ha en överenskommen åtgärdstid. - Fel/brister på nivå 4 Kosmetika hindrar inte leveransgodkännande, men de ska vara åtgärdade till nästkommande kompletta release. För definition av fel/brister se bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering. 5.4 Etapp 3 Etapp 3 startar omedelbart efter godkänd etapp 2.

Bilaga 2 Beskrivning av projektet och dess leveranser 17 (28) PVS 937-6118/12 1.0 5.4.1 Etappens omfattning Etappen omfattar att verifiera hela processen och systemlösningen genom att från tre piloter (källsystem) leverera in skarp produktionsdata till e-arkivet. Pilotanslutningar kommer att drivas av RPS. Under etappen ska också eventuella överenskomna restpunkter från ett leveransgodkännande vara åtgärdade och verifierade av Leverantören samt acceptanstestade av Beställaren. 5.4.2 RPS leveranser RPS leveranser etapp 3 i relation till Leverantörens införandeprojekt: 1. rensning av testdata i produktionsmiljö, 2. testplaner och testfall, 3. inläsning av leveranser från tre pilotsystem, 4. acceptanstester av genomförda leveranser, 5. testprotokoll med tillhörande testrapporter avseende acceptanstester av genomförda leveranser, Om överenskommelse om restpunkter från ett leveransgodkännande etapp 2: 6. medverka vid ominstallation av avtalat system i test-, utbildningsmiljö, 7. acceptanstester verifiering av att överenskomna restpunkter är åtgärdade, 8. testprotokoll med tillhörande testrapporter avseende acceptanstester, överenskomna restpunkter är åtgärdade. 5.4.3 Leverantörens avtalade leveranser Leverantörens avtalade leveranser för etapp 3: 1. rensning av testdata i produktionsmiljö, 2. testning av skarpt testdata, 3. beredskap för ändringshantering utifrån resultat av testning på skarpt testdata, Om överenskommelse om restpunkter från ett leveransgodkännande etapp 2: 4. installation av nya releaser efter korrigerande åtgärder av avtalat system i test- och utbildningsmiljö 8, 8 Är restpunkten av prestandakaraktär ansvarar Leverantören av verifieringen på motsvarande sätt som under etapp 2.

Bilaga 2 Beskrivning av projektet och dess leveranser 18 (28) PVS 937-6118/12 1.0 5. releaseförteckning över förändrad funktionalitet, 6. verifiering att avtalat system är korrekt uppsatt i test- och utbildningsmiljö, 7. uppdatering av avtalade dokument utifrån överenskomna restpunkter, 8. stöd på plats under RPS acceptanstestperiod, 9. felavhjälpning, 10. analys och felsökning av inkomna skriftliga testrapporter, 11. om identifierade fel - skriftlig åtgärdsplan för identifierade fel. 5.4.4 Avtalad tidplan Avtalad tidplan för etapp 3: - Åtgärder på eventuella överenskomna restpunkter ska vara levererade och verifierade inom två (2) månader efter leveransgodkännande av etapp 2. - Acceptanstester av åtgärdade restpunkter ska vara genomförd inom en (1) månad efter faktisk leveransdag. - Acceptanstester av leveranser från tre pilotsystem ska vara genomförd tre (3) månader efter godkänd leverans etapp 2. 5.4.5 Godkännande För godkännande av avtalad leverans, etapp 3: - För godkännande avtalad leverans etapp 3 får det inte finnas några fel/brister på nivå 1 Blockerande, nivå 2 Hindrande eller på nivå 3 Störande. Om det finns fel/brister på nivå 1-3 efter avtalad acceptanstestperiod varvid ett leveransgodkännande inte kan ges räknas detta som leveransförsening. - Fel/brister på nivå 4 Kosmetika hindrar inte leveransgodkännande, men de ska vara åtgärdade till nästkommande kompletta release. För definition av fel/brister se bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering. 5.5 Etapp 4 Etapp 4 startar omedelbart efter godkänd etapp 3.

Bilaga 2 Beskrivning av projektet och dess leveranser 19 (28) PVS 937-6118/12 1.0 5.5.1 Etappens omfattning Etappen omfattar att produktionssätta e-arkivet och överlämna slutgiltig dokumentation från Leverantörens införandeprojekt. 5.5.2 RPS leveranser RPS leveranser etapp 4 i relation till Leverantörens införandeprojekt: 1. eventuell rensning av testdata i produktionsmiljö, 2. installera leveransgodkänd release från testmiljö till produktionsmiljö, 3. officiellt ta systemet i produktion, 4. produktionssättningsprotokoll, 5. påbörja inläsning av leveranser från de tre pilotsystemen, inledningsvis från pilotmyndigheterna, 6. överlämning av produktionssatta delar till förvaltning och drift. 5.5.3 Leverantörens avtalade leveranser Leverantörens avtalade leveranser för etapp 4: 1. eventuell rensning av testdata i produktionsmiljö, 2. uppdatering av leveransgodkänd release i produktionsmiljö, 3. medverka vid produktionssättning och under två veckor efter produktionssättning, 4. slutgiltig överlämning av avtalad dokumentation, 5. överlämning av all projektdokumentation som tas fram i projektet, 6. slutrapport för projektet, 7. avslut av Leverantörens införandeprojekt. Om fel uppkommer vid produktionssättning eller inom två veckor från produktionssättning: 8. analys och felsökning av inkomna skriftliga testrapporter, 9. felavhjälpning, 10. om identifierade fel - skriftlig åtgärdsplan för identifierade fel, 11. om identifierade fel rättningsreleaser installerade på test- och utbildningsmiljö samt stödja införande av rättningsreleaser i produktionsmiljö.

Bilaga 2 Beskrivning av projektet och dess leveranser 20 (28) PVS 937-6118/12 1.0 5.5.4 Avtalad tidplan Avtalad tidplan för etapp 4: - Produktionssättning ska ske inom en (1) månad efter godkännande av etapp 3. - Leverantörens införandeprojekt ska vara avslutat inom en (1) månad efter godkänd produktionssättning. 5.5.5 Godkännande För godkännande av hela leveransen, etapp 4: - För godkännande avtalad leverans etapp 4 får det inte finnas några fel/brister på nivå 1 Blockerande, nivå 2 Hindrande eller på nivå 3 Störande. Om det finns fel/brister på nivå 1-3 efter avtalad acceptanstestperiod varvid ett leveransgodkännande inte kan ges räknas detta som leveransförsening. - Fel/brister på nivå 4 Kosmetika hindrar inte leveransgodkännande, men de ska vara åtgärdade till nästkommande kompletta release. För definition av fel/brister se bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering. 6 Optioner Inom upphandlingens ram finns följande optioner: - Utökade Licenser, support- & underhåll - Utökad supporttjänst - Tilläggstimmar för specificerade roller - Utbildning. - Förbereda nya leveranser. - Integrering med lagringslösning och migrering. Samtliga optioner definieras i bilaga 1 Kravspecifikation fliken Prisangivelser. Nedan beskrivs optionen Integrering med lagringslösning samt migrering mer detaljerat då dessa kan ha ett beroende till projektets etapper. 6.1 Ny lagringslösning RPS arbetar med att införa en ny lagringslösning där man går från traditionell filbaserad lagring till en objektrelaterad lagringslösning. Då det är osäkert när detta skrivs om genomförande av ligger i fas med införande av en ny lagringslösning hanteras anslutning av Systemet

Bilaga 2 Beskrivning av projektet och dess leveranser 21 (28) PVS 937-6118/12 1.0 till Polisens Lagringslösning som en option. Denna anslutning omfattas i Option integrering med lagringslösning. Antingen kan Option integrering med lagringslösning avropas så att den levereras i anslutning till Leverantörens införandeprojekt, etapp 2, eller så kan optionen avropas som ett mindre fristående uppdrag vid ett senare tillfälle inom avtalsperioden. Om avrop av optionen sker efter genomförande av Leverantörens införandeprojekt och därmed efter produktionssättning måste även Option migrering avropas. Denna option handlar om att flytta redan arkiverad information in i den nya lagringslösningen. 6.2 Option integrering med lagringslösning Option integrering med lagringslösning avropas antingen så att den levereras i anslutning till Leverantörens införandeprojekt, Etapp 2 eller som en fristående leverans. Om leverans ska kunna ske i anslutning till Leverantörens införandeprojekt ska avropet ske före påbörjande av Etapp 2. 6.2.1 Optionens omfattning Optionen omfattar att ansluta e-arkivet till RPS nya objektorienterade lagringslösning. Vid avrop under projektet ingår prestandatester och produktionssättning som del i Leverantörens införandeprojekt Etapp 2 respektive Etapp 4. Vid avrop i förvaltningsläge ingår prestandatester och produktionssättning som en del av Option - migrering. 6.2.2 Leverans Leverantörens åtagande innefattar realisering av nedanstående krav anpassat till Polisens Lagringslösning. Kravkolumnen refererar till relaterade krav i bilaga 1 Kravspecifikation. Integration Refererade krav Kommentar Lagringslösning IFT 212 IFT 215 IFT 217 IFT 219 - IFT 220

Bilaga 2 Beskrivning av projektet och dess leveranser 22 (28) PVS 937-6118/12 1.0 6.2.3 RPS leveranser RPS leveranser Option integrering med lagringslösning i relation till Leverantörens leverans av optionen: 1. teknisk dokumentation kring Polisens Lagringslösning. 2. genomgång med Leverantören om Polisens Lagringslösning. 3. deltagande i detaljering av krav och teknisk designarbete, 4. skriftligt godkänna detaljkrav- och teknisk designspecifikation, 5. medverka vid installation av avtalat System innehållande funktion som stödjer optionen i test-, utbildningsmiljö, 6. testplaner och testfall, 7. testdata, 8. acceptanstest av avtalad leverans, exklusive prestandatester, 9. testprotokoll med tillhörande testrapporter avseende acceptanstest av avtalad leverans. 6.2.4 Leverantörens avtalade leveranser Leverantörens avtalade leveranser för Option integration med lagringslösning: 1. detaljkravspecifikation och teknisk designspecifikation utifrån avtalad leverans, 2. vid behov uppdateringar av anvisningar på hur sätta upp test-, utbildnings- och produktionsmiljö, 3. leverans av avtalat System innehållande funktion som stödjer optionen inkluderande anpassningar till Polisens Lagringslösning, 4. installation av avtalat System innehållande funktion som stödjer optionen i test- och utbildningsmiljö, 5. verifiering att avtalad leverans är korrekt uppsatt i alla definierade miljöer, 6. stöd under RPS acceptanstestperiod, 7. analys och felsökning av inkomna skriftliga testrapporter, 8. felavhjälpning, 9. om identifierade fel - skriftlig åtgärdsplan för identifierade fel, 10. om identifierade fel rättningsreleaser installerade på test- och utbildningsmiljö samt stödja införande av rättningsreleaser i kommande produktionsmiljö.

Bilaga 2 Beskrivning av projektet och dess leveranser 23 (28) PVS 937-6118/12 1.0 6.2.5 Avtalad tidplan Avtalad tidplan för Option integration med lagringslösning: - Om avrop sker med leverans inom Leverantörens införandeprojekt ska optionen levereras samtidigt och med samma förutsättningar som leverans inom etapp 2. - Om avrop sker med leverans efter Leverantörens införandeprojekt ska leverans ske senast fyra (4) månader efter avrop. 6.2.6 Godkännande För godkännande av hela leveransen, Option integration med lagringslösning: - För godkännande av avtalad leverans Option integration med lagringslösning får det inte finnas några fel/brister på nivå 1 Blockerande eller nivå 2 Hindrande. Därtill ska åtgärder av fel/brister på nivå 3 Störande ha en överenskommen åtgärdstid. Åtgärdstiden får inte vara längre än 1 månad. - Fel/brister på nivå 4 Kosmetika hindrar inte leveransgodkännande, men de ska vara åtgärdade till nästkommande kompletta release. För definition av fel/brister se bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering. 6.3 Option migrering Option - migrering avropas om anslutningen till Polisens Lagringslösning ska ske efter genomförande av Leverantörens införandeprojekt. 6.3.1 Optionens omfattning Optionen omfattar att leverera ett fristående projekt, genomföra prestandatester, produktionssätta samt flytta redan arkiverad information så att den lagras i Polisens nya lagringslösning. 6.3.2 Leverans Leverantörens åtagande innefattar realisering av nedanstående krav anpassat till Polisens Lagringslösning. Kravkolumnen refererar till relaterade krav i bilaga 1, Kravspecifikation. Integration Refererade krav Kommentar Lagringslösning IFT 213 IFT 214

Bilaga 2 Beskrivning av projektet och dess leveranser 24 (28) PVS 937-6118/12 1.0 6.3.3 RPS leveranser RPS leveranser Option - migrering i relation till Leverantörens leverans av optionen: 1. testplaner och testfall, 2. testdata, 3. acceptanstest av avtalad leverans; - exklusive prestandatester och testprotokoll, - samt med tillhörande testrapporter avseende acceptanstest av avtalad leverans. 4. installation av leveransgodkänd release i produktionsmiljö, 5. verkställa så att redan arkiverad information lagras in i Polisens Lagringslösning, 6. ta ny release i drift 7. produktionssättningsprotokoll, 8. överlämning av produktionssatta delar till förvaltning och drift. 6.3.4 Leverantörens avtalade leveranser för Option - migrering Förutsättningar för prestandatester avseende programvara är de samma som vid etapp 2: 1. Verifiering av avtalad prestanda utifrån avtalade krav, 2. skriftlig rapport på hur verifiering av prestanda har genomförts, utfall och eventuell åtgärdsplan, 3. verifiering att avtalad leverans är korrekt uppsatt i alla definierade miljöer, 4. stöd under RPS acceptanstestperiod, 5. analys och felsökning av inkomna skriftliga testrapporter, 6. felavhjälpning, 7. om identifierade fel - skriftlig åtgärdsplan för identifierade fel, 8. om identifierade fel rättningsreleaser installerade på test- och utbildningsmiljö. 9. stöd vid installation av leveransgodkänd release i produktionsmiljö, 10. extra beredskap vid produktionssättning och under två veckor efter produktionssättning, 11. överlämning av teknisk dokumentation, 12. slutrapport för uppdraget.

Bilaga 2 Beskrivning av projektet och dess leveranser 25 (28) PVS 937-6118/12 1.0 Om fel uppkommer vid produktionssättning eller inom två veckor från produktionssättning: 12. analys och felsökning av inkomna skriftliga testrapporter, 13. felavhjälpning, 14. om identifierade fel - skriftlig åtgärdsplan för identifierade fel, 15. om identifierade fel rättningsreleaser installerade på test- och utbildningsmiljö samt stödja införande av rättningsreleaser i kommande produktionsmiljö. 6.3.5 Avtalad tidplan Avtalad tidplan för Option - migrering: - Option integrering med lagringslösning och Option - migrering ska tillsammans levereras senast fyra månader efter avrop. 6.3.6 Godkännande För godkännande av hela leveransen, Option - migrering: - För godkännande av avtalad leverans Option - migrering får det inte finnas några fel/brister på nivå 1 Blockerande eller nivå 2 Hindrande. Därtill ska åtgärder av fel/brister på nivå 3 Störande ha en överenskommen åtgärdstid. Åtgärdstiden får inte vara längre än 1 månad. - Fel/brister på nivå 4 Kosmetika hindrar inte leveransgodkännande, men de ska vara åtgärdade till nästkommande kompletta release. För definition av fel/brister se bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering. 7 Övriga åtaganden 7.1 Resurser Leverantören har ansvar för att säkra att det finns tillräckligt med resurser med rätt kompetens som skyndsamt kan utföra åtaganden enligt avtal. Följande resurser från Leverantören har preliminärt bedömts behövs: resurser för projektledning, teknisk installation av standardsystem, konfigurering, utveckling integrationsarbete, prestandatester, detaljspecificering och design, samt stöd i testarbete.

Bilaga 2 Beskrivning av projektet och dess leveranser 26 (28) PVS 937-6118/12 1.0 RPS har ansvar för att säkra att det finns tillräckligt med resurser med rätt kompetens som skyndsamt kan utföra åtaganden enligt avtal. Följande RPS-resurser har preliminärt bedömts behövs: projektledare, verksamhetsspecialister, arkivarie, arkitekt, säkerhetsexpert, testansvarig och testare, jurist, kommunikatör, konfigurationsansvarig, blivande förvaltare, experter på miljöer som ska integreras, förvaltare och utvecklare från levererande system samt tekniker. 7.2 Utförande i beställarens lokaler Allt projektarbete som inte omfattar utveckling och underhåll av standardsystemet ska genomföras i RPS lokaler. Det betyder att Leverantören kan behöva en utvecklingsmiljö hos RPS. Detta ska påtalas för RPS vid projektstart. Leverantören är själv ansvarig för installation och underhåll av denna miljö. RPS ansvarar för att tillhandahålla miljöer, arbetsplatser och nödvändig utrustning för projektmedlemmar. Detta med undantag av programvara för prestandatester, se leveranser etapp 2. 7.3 Kompetensöverföring Leverantören har ett ansvar att löpande arbeta med kompetensöverföring till RPS. Målet är att RPS i hög grad ska klara sig själva när införandeprojektet är avslutat. Det betyder att RPS ska kunna ansluta ett nytt system eller ta fram en ny inleveransspecifikation utan stöd av Leverantören. 7.4 Testdata Under projektets etapp 1 ska Leverantören tillhandahålla testdata. Denna testdata behöver inte vara specifik för RPS. Från och med etapp 2 tillhandahåller RPS testdata för de tester som utförs inom Polisen. 7.5 Grunddata Under projektets etapp 1 ska Leverantören tillhandahålla grunddata. Denna grunddata behöver inte vara specifik för RPS. Från och med etapp 2 så tillhandahåller RPS grunddata efter anvisningar från Leverantören. 8 Överlämning och stängning av projekt 8.1 Överlämning till beställaren Varje leverans i etapp 1-4 godkänns skriftligt av programstyrgrupp.

Bilaga 2 Beskrivning av projektet och dess leveranser 27 (28) PVS 937-6118/12 1.0 8.2 Projektavslut Leverantörens införandeprojekt avslutas enligt plan efter etapp 4 efter godkännande i programstyrgruppen. Förutsättningar för avslut är att det finns skriftliga leveransgodkännanden för etapp 1-4. 9 Projektdokumentation och rapportering 9.1 Projektdokumentation - Krav och design ska finnas dokumenterade. - Beslut ska protokollföras. - Projektdokumentation ska finnas sammanförda i ett projektbibliotek hos RPS. - Dokument ska versionshanteras. 9.2 Statusrapportering Leverantören ska leverera en statusrapport till varje projektstyrgrupp. Statusrapporten ska innehålla rubrikerna: - Uppföljning utifrån planerade aktiviteter och leveranser. - Planerade aktiviteter och leveranser. - Projektet i förhållande till tidplan. - Resursläge. - Risker med förslag till åtgärd. - Framsteg och möjligheter. 9.3 Finansiell rapportering Leverantören ska leverera en finansiell rapportering till varje projektstyrgrupp. I rapporten ska framgå vad som är beställt, hur mycket som är förbrukat och hur detta står i förhållande till färdigställandegraden. 10 Kommunikationsplan En kommunikationsplan kommer att tas fram och omfatta kommunikationsinsatser för hela Polisen.

Bilaga 2 Beskrivning av projektet och dess leveranser 28 (28) PVS 937-6118/12 1.0 Nedan listas de kommunikationsinsatser som Leverantören medverkar vid inom ramen för Leverantörens införandeprojekt: - Informationstillfälle, med demonstration, för arkivarier inom Polisen. - Informationstillfälle, med demonstration, för projektets projektstyrgrupp. - Informationstillfälle, med demonstration, för projektets programstyrgrupp. - Informationstillfälle, med demonstration, för projektgruppen. - Informationstillfälle för arkitekter, drift samt säkerhetsgruppen.

Bilaga 3, Samverkan och styrning 1 (14) PVS 937-6118/12 1.0 Bilaga 3 Samverkan och styrning

Bilaga 3, Samverkan och styrning 2 (14) PVS 937-6118/12 1.0 INNEHÅLL 1 SYFTE MED DETTA DOKUMENT... 4 2 SAMVERKAN... 4 3 LEVERANTÖRSSAMVERKAN... 4 3.1 Strategisk nivå... 4 3.2 Taktisk nivå... 5 3.3 Operativ nivå... 5 3.3.1 Under införandeprojektet... 6 3.3.2 Projektmodell... 6 3.3.3 I förvaltningsläge... 6 3.4 Förvaltnings- och Supporthantering... 7 4 SERVICENIVÅER (SLA)... 7 4.1 Tillämpning... 7 4.2 Omfattning support och underhåll... 8 4.2.1 Underhållstjänst standardsystem... 8 4.2.2 Underhållstjänst avseende anpassningar till standardsystem... 8 4.2.3 Underhållstjänst avseende ingående 3:e partsprodukter... 9 4.2.4 Kundstöd... 9 4.2.5 Support...10 4.2.6 Prioriterings- och servicenivåer störningsärenden...10 4.2.7 Prioriterings- och servicenivåer övriga ärenden...13 4.2.8 Mätning, rapportering, återkoppling...13 4.3 Ansvarsfrihet... 14 4.4 Ändring av SLA-nivåer... 14

Bilaga 3, Samverkan och styrning 3 (14) PVS 937-6118/12 1.0 shistorik Datum Ändring Handläggare 1.0 2012-10-19 Ann Rosenlind

Bilaga 3, Samverkan och styrning 4 (14) PVS 937-6118/12 1.0 1 Syfte med detta dokument Syftet med detta dokument är att beskriva samarbetet mellan Leverantören och Rikspolisstyrelsen (RPS). 2 Samverkan RPS:s förutsätter en hög grad av samverkan, i projektet för Digital arkivtjänst och i förvaltningsläget, med ett gemensamt ansvar för ett lyckat resultat, men där RPS och Leverantör har sina tydliga roller och tydliga leveranser. RPS beskriver nedan övergripande hur samverkan och styrning ska genomföras. RPS ser positivt på ett arbetssätt som är ITIL-baserat. 3 Leverantörssamverkan För att uppnå god samverkan mellan RPS och Leverantören ska båda parter säkerställa att ansvariga på strategisk, taktisk och operativ nivå tillsätts. Namn och kontaktuppgifter på dessa personer hos Leverantören ska anges. 3.1 Strategisk nivå Syftet med den strategiska nivån är att diskutera strategisk framtid, verksamhetsutveckling, relationsfrågor. Den strategiska nivån är den högsta nivån på för eskalering av gemsamma frågor. På strategisk nivå ska Leverantören säkerställa att det för avtalet med RPS finns representation från Leverantörens verkställande ledning och en ansvarig Avtalsägare för att teckna avtal, samt en Huvudkontaktperson med huvudansvarig för Leverantörens samtliga leveranser till RPS. RPS ska säkerställa att det vid RPS finns en ansvarig Avtalsägare som kan teckna avtal samt en huvudansvarig Huvudkontaktperson för kontakter med Leverantören och som kan diskutera leveranser utifrån fastställda strategier. Samverkan sker när endera parten finner behov att lyfta strategiska frågor eller eskalera problem och centrala frågeställningar. Byte av Avtalsägare eller Huvudkontaktperson ska kommuniceras skriftligt till andra parten. Ingen ersättning utgår för Avtalsägares/Huvudkontaktpersons tid eller omkostnader.

Bilaga 3, Samverkan och styrning 5 (14) PVS 937-6118/12 1.0 3.2 Taktisk nivå På den taktiska nivån säkerställs avtalsfrågor, kvalitetsuppföljning, prognoser, uppföljning av eget åtagande enligt avtal samt styrning av kompetens och resurser. Den taktiska nivån är den mellersta nivån för eskalering av gemsamma frågor. På taktisk nivå ska Leverantören säkerställa att det finns en Affärsansvarig för RPS som är ansvarig för Leverantörens utförande enligt avtal, ansvarig för att hantera klagomål samt ansvarig för kommunikation. Den affärsansvariga ska inom ramen för avtalet ha mandat att företräda Leverantören kring affärsmässiga frågor i relation till RPS. RPS ska säkerställa att det från deras sida finns en Affärsansvarig med ansvar för uppföljning av att leverans sker enligt avtal, ansvarig för Leverantörsstyrning samt ansvarig för kommunikation. Den affärsansvariga ska inom ramen för avtalet ha mandat att företräda RPS kring affärsmässiga frågor i relation till Leverantören. Under införandeprojektet deltar Leverantörens affärsansvarig i projektstyrgruppen, med frekvens en (1) gång per månad och i vilken RPS:s affärsansvarig sitter som styrgruppsordförande. Vid behov sammankallas till separata möten där avtalsmässiga frågor hanteras mellan parternas affärsansvariga. I support och förvaltningsläge sker samverkansmöten mellan affärsansvariga minst två gånger per år. Vid mötena ska bland annat uppföljning göras av hur samverkan avlöper, uppföljning av SLA:er (Service Level Agreement), planer för nya releaser och behov av större ändringar hanteras. Parterna har också att informera varandra om planerade större förändringar som kan påverka samverkan eller leveransen. Byte av Affärsansvarig ska kommuniceras skriftligt till andra parten. Ingen ersättning utgår för affärsansvariges tid eller omkostnader. 3.3 Operativ nivå På den operativa nivån genomförs operativt planerade, förebyggande och uppföljande arbete, samt hantering av utredningar vid ändringar och problem. Den operativa nivån är den lägsta nivån på för eskalering av gemsamma frågor. På operativ nivå ska Leverantören säkerställa att det finns en kontaktperson. RPS ska ha motsvarande kontaktperson. Rollerna för kontaktpersonerna ser något annorlunda ut om man befinner sig i projektläge eller i förvaltningsläge, se nedan för närmare beskrivning.

Bilaga 3, Samverkan och styrning 6 (14) PVS 937-6118/12 1.0 3.3.1 Under införandeprojektet Under införandeprojektet ska Leverantören ha en utsedd Projektledare med projektansvaret för Leverantörens leveranser. Projektledaren ska också ha mandat att företräda Leverantören inom överenskomna projektramar kring operativa frågor. I arbetet innefattas att planera, leda och följa upp Leverantörens införandeprojekt och dess leveranser. Projektledaren ska ha mandat att ta beslut för att lösa problem och en definierad ram inom vilken projektledaren kan ta direkta beslut om ändringshantering. Leverantörens projektledare förväntas sitta i RPS:s lokaler under införandeprojektets genomförande. Ersättning för projektledarens tid och omkostnader ingår i ersättning för Leverantörens införandeprojekt. RPS ska ha en motsvarande Projektledare som har till ansvar att planera, leda och följa upp RPS:s projekt och dess leveranser. Projektledaren ska ha mandat att ta beslut för att lösa problem och en definierad ram inom vilken projektledaren kan ta direkta beslut om ändringshantering. Samverkan sker via löpande projektmöten mellan respektive parts projektledare. RPS:s projektledare är sammankallande. Rapportering sker via projektstyrgrupp där båda projektledarna är föredragande. 3.3.2 Projektmodell RPS tillämpar projektmodellen PROPS (XLPM). Leverantörens införandeprojekt och förvaltning ska drivas på svenska. Personal som deltar i leverantörens införandeprojekt och kommande förvaltning samt support ska därför kunna tala och skriva svenska. 3.3.3 I förvaltningsläge I förvaltningsläge ska Leverantören tillhandahålla en Samordningsansvarig som hanterar operativa frågeställningar. Samordningsansvarig har ansvaret för Leverantörens leveranser och mandat att företräda Leverantören inom överenskomna support- och förvaltningsramar kring operativa frågor. Ersättning för kontaktpersonens tid och omkostnader ingår i ersättning för support och förvaltning.

Förfrågning Ärende Lösning Ärende Uppgjord av Bilaga 3, Samverkan och styrning 7 (14) PVS 937-6118/12 1.0 Motsvarande kontaktperson hos RPS är Förvaltningsansvarig som ska säkerställa att det från RPS finns en ansvarig för uppföljning, en ansvarig för tjänster samt en ansvarig för hantering av incidenter och problem. Samverkan sker via löpande avstämningar samt minst fyra avstämningsmöten per år. Vid mötena ska bland annat volym/trendstatistik, uppföljning av inrapporterade fel och brister, uppföljning av SLA:er, planer för nya releaser och behov av ändringshantering hanteras. 3.4 Förvaltnings- och Supporthantering RPS har en supportorganisation som innebär: Användare inom RPS RPS Helpdesk (1 st line support) Support/Förvaltning (2 nd line support) - - - - Tjänstegränssnitt för SLA - - - - Leverantör (3 rd line support) Figur 1 Supportorganisation 4 Servicenivåer (SLA) Detta avsnitt beskriver de servicenivåer (SLA) som gäller för leverans av förvaltningsstödjande tjänster för Polisens e-arkiv. 4.1 Tillämpning SLA -nivåerna skall mätas och följas upp kvartalsvis, rapporteras till RPS samt utgör underlag för ständiga förbättringar av tjänster och tjänstehantering. Detta dokument beskriver en servicenivå, benämnd normal nivå.

Bilaga 3, Samverkan och styrning 8 (14) PVS 937-6118/12 1.0 Brister och fel i servicenivå kan ligga till grund för viten, specificerade i Avtalet. 4.2 Omfattning support och underhåll Detta avsnitt reglerar omfattning av underhåll och support. Ersättning sker via en underhålls- och supportavgift, se bilaga 1 Kravspecifikation. Vid varaktigt eller ofta förekommande överskridande av SLA-nivåerna ska Leverantören vidta de åtgärder som krävs för att uppnå och hålla de överenskomna nivåerna. 4.2.1 Underhållstjänst standardsystem Följande ingår: - Rätt att använda det avtalade standardsystemet inom Polisen enligt den omfattning definierad i Avtalet. - Rätt till nya uppdateringar och uppgraderingar av det avtalade standardsystemet. - Underhållstjänsten inkluderar nya eller reviderade standardunderhållsreleaser av det standardsystem som Leverantören kan komma att släppa från tid till annan. Minst med frekvens en (1) komplett release per år innehållande förbättrad funktionalitet. Underhållsreleaser omfattar versioner, releaser och servicereleaser. - Eventuella frakter och mediakostnader för nya standardunderhålls releaser ingår. - Leverantören ska hålla Polisen informerad om nya standardunderhållsreleaser av programmet samt göra dem tillgänglig för Polisen. 4.2.2 Underhållstjänst avseende anpassningar till standardsystem Anpassningar till standardsystem ägs av Polisen, men Leverantören säkerställer att de anpassningar som Leverantören har utfört upprätthålls och fungerar genom att: - Garantera att anpassningar som Leverantören utfört enligt avtalet och avrop på detta avtal fortsatt fungerar enligt överenskommen specifikation efter uppdatering av standardunderhållsreleaser. Detta gäller så länge inte Polisen själv har förändrat anpassningarna. - Säkerställa att anpassningar som Leverantören har utfört fortsatt fungerar enligt överenskommen specifikation inför varje ny leverans av en standardunderhållsrelease.

Bilaga 3, Samverkan och styrning 9 (14) PVS 937-6118/12 1.0 4.2.3 Underhållstjänst avseende ingående 3:e partsprodukter I underhållstjänsten ingår underhåll för i ingående 3:e partsprodukter enligt definition i bilaga 1 Kravspecifikation. Anpassningar av standardsystemet till versioner av ingående 3:e-partsprodukter säkerställs genom att Leverantören garanterar att standardsystemet anpassas till nya versioner av ingående 3:e-partsprodukter. Eftersläpningen av anpassningar är maximalt två (2) versioner bakåt gentemot ingående 3:e-partsprodukt. Slutar tillverkaren av en 3:e-partsprodukt att underhålla produkten ska Leverantören tillhandahåll en ersättningsprodukt med motsvarande funktionalitet till samma kostnad för RPS. Leverantören säkerställer att ingående 3:e-partsprodukter fungerar i samband med nya standardunderhållsreleaser genom att genomföra tester. Leverantören ska informera och planera för eventuella förändringar, då plattformskrav förändras som påverkar avtalat standardsystem. 4.2.4 Kundstöd Leverantören håller en uppbyggd kundstödsorganisation för avtalat standardsystem med dess kundunika anpassningar, som Polisen kan vända sig till med problem, fel, frågor, förbättringsförslag eller när det i övrigt finns behov av stöd. Kontakt med kundstöd kan ske via mail eller telefon. Förfrågningen till Leverantörens kundstöd kommer från Polisens 2 nd line support enligt Figur 1 Supportorganisation. Leverantörens åtagande för kundstöd omfattar registrering av alla inrapporterade ärenden i anvisat ärendehanteringssystem, initial analys, prioritering av anmälda ärenden, problemavhjälpning, initiering av fördjupad problemanalys där så krävs, bevakning avseende åtgärdstider, eskaleringsrutiner etc. i syfte att bibehålla avtalade servicenivåer, löpande uppdatering om ärendets status/åtgärdsplaner tillgängliggjord till anmälaren och Polisens förvaltare samt avslut och slutrapportering om orsak och åtgärd till Polisen på inrapporterade ärenden. Partnerna skall upprätta en förteckning över administratörer hos Polisen som är behöriga att begära support av Leverantören. Polisen har tillgång till personlig assistans från Leverantörens kundstöd varje helgfri vardag under kontorstid kl. 8-17.

Bilaga 3, Samverkan och styrning 10 (14) PVS 937-6118/12 1.0 Utöver ordinarie helgdagar betraktas även midsommarafton, julafton och nyårsafton som helgdagar. Polisen ska utanför kontorstid kunna skicka in anmälningar. Svarstid för Kundstöd via telefon ska i genomsnitt vara kortare än två (2) minuter. Med svarstid avses kontakt med personal som tar hand om anmälan av ärende/besvarar ställd fråga. 4.2.5 Support Leverantören håller en uppbyggd supportorganisation som hanterar teknikoch applikationsstöd för avtalat standardsystem. Vid anmälningar av störningar i form av problem eller fel ska Polisen genomföra en egen felanalys innan anmälan genomförs till Leverantören. Efter anmälan ansvarar Leverantören för felanalys och åtgärd vid konstaterat fel. Polisen ansvarar för att förse Leverantören med information och underlag för att Leverantören ska kunna genomföra en sådan analys. Leverantören ska vid behov, efter överenskommelse, ges möjlighet att på plats i Polisens lokaler genomföra en felanalys i produktionsmiljö. Leverantören ansvarar för korrigering av konstaterat programfel i avtalat standardsystem. Detta inkluderar ingående tredjepartsprodukter, anpassningar för vilket Leverantören ansvarat och i vilka RPS inte genomfört några förändringar. Rättningar ska levereras i form av rättningsfiler, eller i nästkommande huvudrelease. Support ges på de två senaste versionerna av Leverantörens standardsystem. 4.2.6 Prioriterings- och servicenivåer störningsärenden Vid registrering av ärende i Leverantörens ärendehanteringssystem ska ärendet klassificeras med avseende på hur verksamhetskritiskt en störning bedöms vara. Med störning avses här problem såväl som fel. Klassificeringen sker utifrån nedanstående fyra definierade kategorier och styr prioritering av inkommande ärenden. Målet är alltid att återupprätta normal drift, så snart som möjligt och att minimera skadlig påverkan på verksamheten. Parterna ska enas om en bedömning av prioritetskategori vid en störningsanmälan. Om parterna inte kan enas gäller den kategori som Polisen anser. Vid loggning av ärenden ska det indikeras om prioriteringskategorin har ändrats.

Bilaga 3, Samverkan och styrning 11 (14) PVS 937-6118/12 1.0 En störning kan temporärt åtgärdas med hjälp av en tillfällig lösning, en så kallad workaround. Denna workaround får endast användas under en begränsad tid innan den permanenta lösningen är tagen i bruk. Workaround får endast införas efter överenskommelse med förvaltningsansvarig och ska dokumenteras i ärendeloggen. Konsekvensen av att sätta in en workaround kan innebära att själva störningsärendet kvarstår, men sätts om till en lägre prioritetskategori än ursprungligt. Med arbetstid avses helgfria vardagar klockan 8-17. För anmälda störningar finns fyra definierade prioriteringskategorier med tillhörande påbörjad felsökning och åtgärdstider: 1 Kritisk störning Påverkan på verksamheten är total. Applikationen är otillgänglig eller funktionaliteten mycket allvarligt nedsatt. Verksamhetskritiska funktioner kan inte utföras. Påbörjan av felsökning: Störningen ges högsta prioritet och felsökning påbörjas snarast, och maximalt inom två (2) arbetstimmar. Hanteringstid: Hantering av rapporterade störningar enligt kategori 1 ska per rullande kvartal genomsnittligt understiga sex (6) arbetstimmar. Tiden räknas från att ärendet anmäldes tills att ärendet återrapporterades med RPS godkännande av åtgärd eller enligt överenskommelse prioriterades ner på grund av en införd workaround. Åtgärdsgaranti: Åtgärdsgarantitiden för rapporterade störningar enligt kategori 1 för ett enskilt ärende uppgår till sexton (16) arbetstimmar. Tiden räknat från att ärendet anmäldes. Garantin gäller för de problem som kan hänföras till fel: - I standardsystemet. - I anpassningar för vilka Leverantören ansvarar. - Orsakat av Leverantörens handgrepp på RPS installation av systemet. Åtgärd innebär att störningen är löst permanent eller genom en workaround. 2 Allvarlig störning Påverkan på verksamheten är omfattande. Delar av systemet är otillgängligt eller funktionaliteten är allvarligt nedsatt. Delar av verksamhetskritiska funktioner är inaktiva, fungerar felaktigt eller har svarstider som avviker väsentligt från normala nivåer.

Bilaga 3, Samverkan och styrning 12 (14) PVS 937-6118/12 1.0 Påbörjan av felsökning: Störningen ges hög prioritet och felsökning påbörjas inom sex (6) arbetstimmar. Hanteringstid: Hantering av rapporterade störningar enligt kategori 2 ska per rullande kvartal genomsnittligt understiga tolv (12) arbetstimmar. Tiden räknas från att ärendet anmäldes tills att ärendet återrapporterades med RPS godkännande av åtgärd eller enligt överenskommelse prioriterades ner på grund av en införd workaround. Åtgärdsgaranti: Åtgärdsgarantitiden för rapporterade störningar enligt kategori 2 för ett enskilt ärende uppgår till trettiotvå (32) arbetstimmar. Tiden räknat från att ärendet anmäldes. Garantin gäller för de problem som kan hänföras till fel: - I standardsystemet. - I anpassningar för vilka Leverantören ansvarar. - Orsakat av Leverantörens handgrepp på RPS installation av systemet. Åtgärd innebär att störningen är löst permanent eller genom en workaround. 3 Medelstor störning Användarna kan arbeta, men kan inte uppnå en normal produktivitet. Funktionell störning i systemet, om kan kringgås så att systemet trots detta kan användas. Påbörjan av felsökning: Felsökning ska påbörjas inom tjugofyra (24) arbetstimmar Hanteringstid: Hantering av rapporterade störningar enligt kategori 3 ska per rullande kvartal genomsnittligt understiga åttio (80) arbetstimmar. Tiden räknas från att ärendet anmäldes tills att ärendet återrapporterades med RPS godkännande av åtgärd eller enligt överenskommelse prioriterades ner på grund av en införd workaround. 4 Mindre allvarlig störning Påverkan på verksamheten är begränsad. Funktionalitet som inte har direkt påverkan på verksamheten fungerar inte som den ska eller behöver förändras. Hanteringstid: Hantering av rapporterade störningar enligt kategori 4 ska per rullande kvartal genomsnittligt vara åtgärdade till nästkommande ordinarie versionsuppdatering eller senast sex (6) månader efter anmälan.

Bilaga 3, Samverkan och styrning 13 (14) PVS 937-6118/12 1.0 4.2.7 Prioriterings- och servicenivåer övriga ärenden Ärenden som inte relaterar till störningar klassificeras enligt nedanstående: 5 teknik- och applikationsstöd Ärenden av typen teknik- och applikationsstöd och som inte är att hänföra till någon störning. Hanteringstid: Svarstiden på ställda teknik- och applikationsstödsfrågor enligt kategori 5 ska per rullande kvartal genomsnittligt understiga åtta (8) arbetstimmar. 6 allmän fråga Ärenden av typen frågor som inte är att hänföra till någon störning. Hanteringstid: Svarstiden på ställda frågor enligt kategori 6 ska per rullande kvartal genomsnittligt understiga åtta (8) arbetstimmar. 7 Förbättringsförslag Ärenden av typen förbättringsförslag på standardsystemet. Hanteringstid: Återkoppling på ställda förslag till förbättringar görs löpande. Förslaget behandlas även på avstämningsmöten på operativ nivå. Vid återrapporteringen presenterar Leverantören hur man ser på inkommet förslag och om Leverantören är positiv till förslaget ett förslag till genomförandeprioritering och till vilken release lösningen planeras. 4.2.8 Mätning, rapportering, återkoppling Leverantören ska kontinuerligt mäta avtalade servicenivåer. I ärendehanteringssystemet hos Leverantören sker uppföljning, rapportering och återkoppling av alla ärenden. Månadsvis avrapporteras statistik, planerade aktiviteter och eventuella öppna ärenden till RPS förvaltningsansvarig. Uppföljning av uppfyllande av servicenivåer och övriga avstämningar sker i samband med avstämningsmöten mellan RPS förvaltningsansvarig och Leverantörens samordningsansvarig. Rapportering Följande information ska finnas att rapportera: - Hanteringstid och orsak för respektive ärende kategori 1-2. - Antal ärenden per respektive kategori.

Bilaga 3, Samverkan och styrning 14 (14) PVS 937-6118/12 1.0 - Genomsnittlig Påbörjan felsökning per respektive kategori 1-4. - Genomsnittlig Hanteringstid per respektive kategori. - Antal öppna ärenden, svarstider och andel ärenden som kunnat avslutas vid första kontakt. - Genomsnittlig svarstid för kundtjänst via telefon. - Även problem och kända fel ska ingå i rapporten. Vid behov ska det bakomliggande underlaget kunna granskas. 4.3 Ansvarsfrihet SLA-nivåerna skall mätas i de gränssnitt från vilken Leverantören har leveransansvar. Faktorer som ligger utanför Leverantörens kontroll, som påverkar användarnas upplevelse av tjänsten negativt, ska inte belastas Leverantören. Sådana faktorer kan till exempel vara brister i kommunikationstjänst som utnyttjas för att nå tjänsten, men som ligger utanför Leverantörens ansvar och kontroll. 4.4 Ändring av SLA-nivåer Parterna kan överenskomma om ändring av SLA-nivåer, inom avtalets ramar. Sådan överenskommelse ska vara skriftlig och hanteras enligt processen för förändringshantering. Under speciella omständigheter, som till exempel vid större uppgraderingar, kan parterna överenskomma om minskning i servicenivå under en begränsad tidperiod. En sådan överenskommelse skall vara skriftlig.

Bilaga 4 Inleveransspecifikation 1 (25) PVS 937-6118/12 V1.0 Bilaga 4 Inleveransspecifikation För pilotsystemen K-RAR samt DurTvå

Bilaga 4 Inleveransspecifikation 2 (25) PVS 937-6118/12 V1.0 Innehållsförteckning INNEHÅLL 4 1 Dokumentets syfte 4 2 Inledning 4 2.1 Förklaring av tabeller 4 2.2 Tillvägagångssätt 5 3 Vid leverans från DurTvå & K-RAR 6 4 Objekt 7 4.1 Karta över objekten 7 5 Generellt brottsmålsschema 8 5.1 Ärende 9 5.1.1 Involverad person 9 5.1.2 Anmälan 11 5.1.3 Gods 12 5.1.4 Engagerad personal 12 6 Specifikt DurTvå 13 6.1 Ärende 14 6.1.1 Involverad person 14 6.1.2 Anmälan 17 6.1.3 Engagerad personal 18 6.1.4 Kallelse 19 6.1.5 Tvångsmedel 19 6.1.6 PM 20 6.1.7 Rapport 21 6.1.8 Protokoll 21 6.1.9 Externt dokument 21 6.1.10 Egna anteckningar 21 7 Specifikt K-RAR 22 7.1 Ärende 22 7.1.1 Involverad person 23 7.1.2 Anmälan 24

Bilaga 4 Inleveransspecifikation 3 (25) PVS 937-6118/12 V1.0 Datum Ändring Handläggare 1.0 2012-10-19 Ann Rosenlind

Bilaga 4 Inleveransspecifikation 4 (25) PVS 937-6118/12 V1.0 INNEHÅLL 1 Dokumentets syfte För att säkerställa att leverans till e-arkivet är korrekt kontrolleras SIP mot schema (xds). Syftet med detta dokument är att beskriva informationssamband och förklara informationen som upprättas i två av Polisens brottsutredande system, K-RAR och DurTvå. Båda systemen, samt Bilder Inom Polisen BIP, ingår i införandeprojektet som pilotanslutningar till e-arkivet. 2 Inledning Information som idag upprättas i en brottsutredning är spridd över flera system. Ärendeprocessen beskrivs översiktligt i bilaga 10 Övergripande verksamhetsbeskrivning. Information tillhörande DurTvå, K-RAR presenteras här och tabellerna beskriver vad som ska ingå i inleveransen. Schemat tillåts justeras utifrån Leverantörens lösning för inleveransspecifikation men får inte frångå RPS krav på hantering av informationsobjekten. 2.1 Förklaring av tabeller Objektens relationer förklaras med hjälp av en övergripande karta. Objekten förklaras i detalj i tabellform nedan för respektive system och ordningen på objekten följer den övergripande kartan. Tabeller i gul färg representerar objekt, de i blå färg är specifika för DurTvå och de gröna är specifika för K-RAR. Gemensamt objekt Objekt specifikt DurTvå Objekt specifikt K-RAR Tabellens kolumner är: Namn Namnet på elementet/attributet. Om fet stil är elementet ett eget objekt E/A E om det är ett element och A för attribut S Om potentiellt sökbart Kard Anger objektets kardinalitet, d v s antal förekomster som kan finnas T Type: S (Text), N (Siffror), D (Datum), O (Objekt), B(Boolean), St (Struktur, CDatafält), Bi (Bilaga),

Bilaga 4 Inleveransspecifikation 5 (25) PVS 937-6118/12 V1.0 Beskrivning An(Anteckning), Ad(Administrativt), Be(Berördperson), U(Uppgiftslämnare) Användning och kommentar CDatafält Element som är av typen St (Struktur) är CDatafält. CDatafält används där informationen inte behöver vara strukturerad men ändå ska vara med. Informationen sparas då som en XML-sträng men där strukturen på strängen inte kontrolleras direkt av schemat. Det går att validera strukturen i ett CDatafält också. Då behövs ett eget schema vilket kan följa med leveransen. Exempel på där CDatafält bedöms vara till hjälp är Gods. Gods finns i flera huvudkategorier där flertalet underkategorier finns i flera nivåer. Information i godsobjektet är inte relevant för att återsöka ärendet. Hur denna mängd av information kan struktureras tas därför inte hand av scheman beskrivna i detta dokument. Bilaga Bilaga kallas alla de handlingar, dokument, protokoll som ingår i ärendet. Dessa utgör egna objektstyper. Anteckning I DurTvå går det att som handläggare lägga till anteckningar till olika informationsobjekt. Detta är en egen objektstyp. Administrativt I DurTvå ligger information som kallas för Administrativt på flera informationsobjekt. Detta är en egen objektstyp. Svenska tecken Svenska tecken i elementens namn undviks. Defaultvärden och listor Ingen användning av defaultvärden, godkända format och strängar är definierade. Detta kommer att definieras tillsammans med verksamheten. 2.2 Tillvägagångssätt För systemen K-RAR och DurTvå visas i figur 2 en karta över hur informationen hänger ihop i systemen. Kartan visar hur objekten kommer att relatera till varandra när de levererats till e-arkiv. Scheman som beskrivs i detta dokument ska spegla allt det som syns systemen, även om samma information finns i bifogade handlingar. Till stor del kommer därför informationen att levereras i xmlformat men även komma med i olika sammanställningar (handlingar som rapporter och protokoll).

Bilaga 4 Inleveransspecifikation 6 (25) PVS 937-6118/12 V1.0 Informationen har samlats in via; dokumentation om systemen, tillgång till DurTvå testmiljö, databastabeller i viss mån, systemdemonstration av respektive förvaltning. Aktiviteter för att skapa scheman hitta objekt och dess relationer hitta objektens attribut och definiera typer och antal skapa schema som speglar objekten och dess relationer 3 Vid leverans från DurTvå & K-RAR När DurTvå och K-RAR ska börja leverera till e-arkivet ska detta dokument och tillhörande scheman ligga till grund för hur informationen ska packas ihop. Men det återstår arbete med kvalitetssäkring och eventuell anpassning av scheman för systemens förvaltningar i samarbete med sektionen för ärendehantering. Ytterligare en aktivitet inför leverans är att tillsammans med verksamheten gå igenom och kategorisera vilka metadata som ska vara sökbara och ingå i xml-schemat och vilka metadata som endast ska ingå i handlingarna. Figur 1 Metadata i XML-schema och handlingar

Bilaga 4 Inleveransspecifikation 7 (25) PVS 937-6118/12 V1.0 De scheman, för DurTvå och K-RAR, tillåts ändras beroende på vald Leverantörs lösning för inleveransspecifikation. 4 Objekt Här beskrivs objekten vars information hanteras i källsystemen DurTvå och K-RAR, i bilagan omnämnda som systemet/systemen. 4.1 Karta över objekten Figur 2 Karta över objekten

Bilaga 4 Inleveransspecifikation 8 (25) PVS 937-6118/12 V1.0 Flera av objekten återfinns i de olika systemen. Objekten ser lika ut vad gäller relationer men informationen i skiljer sig en del beroende på system. Detta innebär att viss information kan komma att levereras från de båda systemet. Som beskrivs nedan är information som hör ihop uttagna till egna komplexa element. Det kan vara så att de är ett av de definierade objekten, se kartan ovan, men det kan också vara för att ge schemat en bättre struktur, ett sätt att undvika upprepningar. 5 Generellt brottsmålsschema Figur 3 Generella sobjekt som innehåller potentiellt sökbara element.

Bilaga 4 Inleveransspecifikation 9 (25) PVS 937-6118/12 V1.0 5.1 Ärende Ärende är huvudobjekt i informationsstrukturen. Ärende med sitt diarenummer är det som binder ihop information levererat från olika system. Ärende har en 1 till 1 relation med anmälan vilket betyder att ett ärende endast har och kan ha en anmälan. Ärende kan ingå som underliggande ärende i ett annat ärende eller vara huvudärende och då ha ärenden som ingår i sig. Namn E/A Kard S T Beskrivning diarienr A 1 S S ingariarende E 0..1 S S Om ärendet är kopplat till ett annat ärende som är huvudärende/målnummer står dess diarienummer här. aklagarens E 0..1 S S Åklagarens diarienummer handlaggandeenhet E 1 S Handläggande enhet. Förkortning. underliggandearende E 0..* S S Flera ärenden kan höra ihop men det är alltid ett utsett till huvudärende/målnummer. Diarienummer på underliggande ärenden. atkomstskydd E 0..1 S historik E 1 St CDatafält, Ärendehistorik från DurTvå beskriver vad som hänt med ärendet under handläggning. RAR s historik är mer av en logg vad som gjorts med ärendet i systemet, exempelvis att en utskrift har gjorts beslut E 1 St CDatafält, Ärendebeslut från K-RAR och DurTvå skiljer sig åt till stor del och inget anses styra sökningen. involveradperson E 1..* O anmalan E 1 O Det finns alltid endast en anmälan kopplad till ett ärende. gods E 0..* O engageradpersonal E 1..* O Myndighetsanställd som är engagerad i ärendet. 5.1.1 Involverad person Involverad person är fysisk eller juridisk (kallad organisation i tabell nedan) med roll kopplad till ärendet. Exempelvis kan ett ärende involvera en fysisk person av rollen misstänkt, en juridisk person med rollen målsägare och en fysisk person med rollen vittne. En misstanke är alltid kopplad till ett brott. I xmlfilen kommer ärendets involverade personer tidigt och det är för att eventuella misstankar som tillhör brott och anmälan ska kunna referera till personen i fråga genom personens unika tekniska nyckel.

Bilaga 4 Inleveransspecifikation 10 (25) PVS 937-6118/12 V1.0 Namn E/A Kard S T Beskrivning id A 1 Unikt tekniskt id på personen typ E 1 S Lista: Person, Företag/organisation eller Okänd personnr E 0..1 S S organisationsnr E 0..1 S S Gäller organisation verksamhet E 0..1 S Gäller organisation namn E 0..1 S Gäller organisation kon E 0..1 S Lista, M eller K skyddadpuppgift E 0..1 B Skyddad personuppgift fornamn E 0..1 S S Tvingande om typen är person efternamn E 0..1 S S Tvingande om typen är person mellanamn E 0..1 S S tilltalsnamn E 0..1 S S kallasfor E 0..1 S S oknamn E 0..1 S S medborgarskap E 0..1 S medborgarskap kod A 0..1 S Lista på landskoder fodelseland E 0..1 S fodelseland kod A 0..1 S fodelseort E 0..1 S organisation E 0..1 O Person kan vara juridisk adress E 0..* O telefon E 0..* O ombud E 0..* O Objekt, bara en av typen försvarare men flera annars. dagsbotsuppgifter E 0..1 O arbetsgivare E 0..1 O roll E 1..* O 5.1.1.1 Adress Namn E/A Kard S T Beskrivning adress E 0..1 S Gatunamn och nummer postnr E 0..1 S ort E 0..1 S land E 0..1 S co E 0..1 S C/O 5.1.1.2 Telefon Namn E/A Kard S T Beskrivning typ E 1 S nr E 0..1 S hemligt E 1 B epost E 0..1 S Går bara att fylla i om typ är e-post. 5.1.1.3 Dagsbotsuppgifter Namn E/A Kard S T Beskrivning civilstand E 0..1 B egenarsinkomst E 0..1 N sambosarsinkomst E 0..1 N

Bilaga 4 Inleveransspecifikation 11 (25) PVS 937-6118/12 V1.0 taxeradarsinkomst E 0..1 N sambostaxarsinkomst E 0..1 N Make/maka/sambos taxerade inkomst kontrolldatumtax E 0..1 D taxeringsar E 0..1 D Bara datum, ingen tid taxkontrollavnamn E 0..1 S skulder E 0..1 N formogenhet E 0..1 N bidrag E 0..1 S barnhemmaunder18ar E 0..1 N forsorjningsplikt E 0..1 S taxeringskontrollutford E 0..1 S Eventuellt bara från K-RAR anteckningar E 0..1 S Eventuellt bara från K-RAR 5.1.1.4 Roll En involverad person kan ha flera roller i ett och samma ärende. Namn E/A Kard S T Beskrivning namn E 1 S S Lista, namn på rollen id A 1 S 5.1.2 Anmälan En anmälan ingår i ett ärende. Namn E/A Kard S T Beskrivning typ E 1 S Lista regdatum E 1 S D brottstidtill E 0..1 S D brottstidfran E 0..1 S D anmaltdatum E 1 S D Datum då anmälan gjordes. områdeskod E 1 S S brottsplatsadress E 1 S S brottsplatspostadress E 1 S S beskrivning E 1 S Fritextfält brott E 1..* O administrativt E 1 O 5.1.2.1 Brott Varje anmälan innehåller en eller flera brottsrubriceringar med tillhörande brotsskoder. Namn E/A Kard S T Beskrivning brottskod E 1 S S brottsrubricering E 1 S S misstanke E 0..* O

Bilaga 4 Inleveransspecifikation 12 (25) PVS 937-6118/12 V1.0 5.1.2.1.1 Misstanke Till varje brott kan en eller flera misstankar höra. En misstanke gäller endast en fysisk person(involveradperson), okänd eller känd. Namn E/A Kard S T Beskrivning brottsmisstankenr E 1 S misstanktperson E 1 S Ref till involverad person misstankebeslut E 1..* O 5.1.2.1.1.1 Misstankebeslut Namn E/A Kard S T Beskrivning beslutsfattare E 1 S Namn på engagerad personal beslutsfattare A 1 S Titel på beslutsfattare titel beslutsdatum E 1 D myndighetskod E 1 S Ex 0800 beskrivning E 0..1 S Motivering beslutstyp E 1 S Lista 5.1.3 Gods Föremål, huvudgrupp, undergrupp och antal är generella element för allt gods. Beroende på vilka grupper godset tillhör tillkommer fler element. Dessa element sparas ner i ett CDatafält vilket innebär att de inte definieras i detta schema. Ingen specifik information kommer från DurTvå. Namn E/A Kard S T Beskrivning id E 1 S foremal E 1 S huvudgrupp E 1 S undergrupp E 1 S antal E 1 N varde E 0..1 N Eventuellt bara från K-RAR anteckning E 0..1 S Eventuellt bara från K-RAR refgodspunkt E 0..1 S Eventuellt bara från K-RAR, Nummer på godspunkt nationelltsokbar E 1 B Eventuellt bara från K-RAR specinfo E 1 St CDatafält 5.1.4 Engagerad personal Myndighetsanställd. Namn E/A Kard S T Beskrivning id E 1 S Unik teknisk nyckel, möjliggör referenser inom leveransen. namn E 1 S S Efternamn, förnamn namn titel A 0..1 S tjanstenr E 0..1 S telefon E 0..1 S

Bilaga 4 Inleveransspecifikation 13 (25) PVS 937-6118/12 V1.0 orgenhet E 0..1 S S myndighetskod E 0..1 S 6 Specifikt DurTvå Leveranser som kommer från DurTvå behöver kontrolleras av två scheman som det är uppdelat här. Först av det gemensamma för brottsutredande system sedan av det som är specifikt DurTvå. Det som är specifikt DurTvå är bl.a. rapporter och protokoll, se de blå objekten i kapitel Karta över objekten vilket matchar de blå tabellerna nedan. Strukturen, hur alla objekt relaterar till varandra, är kvar i det specifika schemat för att objekten ska hamna i rätt kontext. Bilaga Bilaga är ett element som blir inkluderade av flera andra. Namn E/A Kard S T Beskrivning skapad E 1 D Datum rubrik E 0..1 S mediatyp E 0..1 S storlek E 1 S namn E 1 S beskrivning E 0..1 S forsattsbladmed E 0..1 B referense E 0..1 S Anteckning Anteckning är ett element som blir inkluderade av flera andra. Namn E/A Kard S T Beskrivning datum E 0..1 D Datum text E 0..1 S Fritext forfattare E 1 S Namn på författare rubrik E 0..1 S typ E 1 S Administrativt Adminstrativt är ett element som blir inkluderade av flera andra. Namn E/A Kard S T Beskrivning atnr E 0..1 S ejdurtva E 0..1 B enhet E 1 S

Bilaga 4 Inleveransspecifikation 14 (25) PVS 937-6118/12 V1.0 Berörd person Berörd person är ett element som blir inkluderade av flera andra. Namn E/A Kard S T Beskrivning namn E 1 S Datum namn typ A 1 S Uppgiftslämnare Uppgiftslämnare är ett element som blir inkluderade av flera andra. Namn E/A Kard S T Beskrivning namn E 1 S Datum namn typ A 1 S 6.1 Ärende Elementen är beskrivna i det gemensamma, här beskrivs endast objekt. Namn E/A Kard S T Beskrivning prioritet E 0..1 N Eventuellt inte intressant information när ärendet är slutredovisat. En siffra. status E 1 S Utgår eventuellt då det antagligen alltid stängt när det skickas till arkivet, automatiskt ifyllt. fuledning E 1 Förundersökningsledning, Automatiskt ifyllt. rubrik E 0..1 S Ärenderubrik bevakningsdatum E 0..1 D Ett valt datum för att hitta ärenden värda att bevaka. senastparverkat E 1 D Automatiskt ifyllt. involveradperson E 1..* O anmalan E 1 O Det finns alltid endast en anmälan kopplad till ett ärende. gods E 0..* O engageradpersonal E 1..* O Myndighetsanställd som är engagerad i ärendet. arendebeslut E 1..* O Minst ett ärendebeslut finn i ärendet. 6.1.1 Involverad person Namn E/A Kard S T Beskrivning avliden E 0..1 B 0 eller 1 efternamntidigare E 0..1 S S bytear A 0..1 S Det år efternamn byttes Foraldrar E 0..1 S utbildning E 0..1 S anstallning E 0..1 S arbetsforhet E 0..1 S kompluppgifter E 0..1 S

Bilaga 4 Inleveransspecifikation 15 (25) PVS 937-6118/12 V1.0 fotograferadar E 0..1 D Bara år daktadar E 0..1 D Bara år titel E 0..1 S svmedborgarear E 0..1 S S eller N forsakringsbolag E 0..1 S korkortsland E 0..1 S korkortsland kod A 0..1 S korkortsklass E 0..1 S civilstand E 0..1 B egenarsinkomst E 0..1 S sambosarsinkomst E 0..1 S skulder E 0..1 S formogenhet E 0..1 S bidrag E 0..1 S barnhemmaunder18ar E 0..1 N forsorjningsplikt E 0..1 S organisation E 0..1 O adress E 0..* O arbetsgivare E 0..1 O ombud E 0..* O Objekt, bara en av typen försvarare men flera annars. ersättningsansprak E 0..1 O forhor E 0..* O taxeringskontroll E 0..1 O roll E 1..* O 6.1.1.1 Organisation Involverad person kan vara av typen juridisk. Organisationsnr och verksamhet har med objektet organisation att göra men det ligger som element på det gemensamma objektet InvolveradPerson. Namn E/A Kard S T Beskrivning type E 0..1 S landbokstav E 0..1 S kontaktperson E 0..1 S 6.1.1.2 Adress Namn E/A Kard S T Beskrivning intervall E 0..1 S adresstyp E 1 S Lista aktuellfrandatum E 0..1 D Ej tid. utskriftsadress E 0..1 B beskrivning E 0..1 S 6.1.1.3 Arbetsgivare En involveradperson kan ha endast en arbetsgivare men för att underlätta strukturen är elementen sammansatta till ett eget objekt.

Bilaga 4 Inleveransspecifikation 16 (25) PVS 937-6118/12 V1.0 Namn E/A Kard S T Beskrivning namn E 0..1 S gatunamn E 0..1 S postnr E 0..1 S postort E 0..1 S tel E 0..1 S 6.1.1.4 Ombud En involveradperson kan ha flera ombud men endast en av typen försvarare. Namn E/A Kard S T Beskrivning typ E 1 S Lista firma E 0..1 S forordnaddatum E 0..1 D Förordnad från datum. namn E 1 S 6.1.1.5 Ersättningsanspråk Namn E/A Kard S T Beskrivning datum E 1 D Datum och tid. ersattningbrott E 0..1 S Beskrivning. ersattningbrott A 0..1 S kod rubrik E 0..1 S foretradare E 0..1 S talanaklagare E 0..1 B Talan önskas förd av åklagare. uppgiftslamnare E 1 S Namnet på uppgiftslämnaren. uppgiftslamnare A 1 S typ ansprak E 0..1 S preciseratansprak E 1 S Beskrivning, fri text. bilaga E 0..* Bi anteckning E 0..* An administrativt E 1 Ad 6.1.1.6 Förhör Namn E/A Kard S T Beskrivning datum E 1 D Datum och starttid. forhorsledare E 1 S Namn. sluttid E 0..1 D tolk E 0..1 S tolksprak E 0..1 S plats E 0..1 S typ E 1 S Förhörstyp, Lista. dokumentationtele E 0..1 B Kan vara tomma. dokumentationljud E 0..1 B dokumentationvideo E 0..1 B dokumentationkonc E 0..1 B utskrivetav E 0..1 S

Bilaga 4 Inleveransspecifikation 17 (25) PVS 937-6118/12 V1.0 forhorsvittne E 0..1 S Efternamn, fornamn. forhorsvittne Typ A 0..1 S Lista, personal eller annan. berattelse E 0..1 S Fritext. rubrik E 0..1 S hordperson E 1 O 6.1.1.6.1 Hörd person Namn E/A Kard S T Beskrivning idkontrollerat E 0..1 B kontrollsatt E 0..1 S rolliforhor E 1 S Lista misstanktunder18 E 1 B stallningtillpart E 0..1 S underrattadmisstanke E 0..1 B Underrättad om misstanke. delgiveninfo E 0..1 B Delgiven info om förenklad delgivning. underrattadforsvarare E 0..1 B Underrättad om rätt till försvarare. godtarforsvarare E 0..1 B Godtar försvarare rätten förordnar. anledning E 1 S Underrättad om vad misstanken avser, Fritext. anteckningforsvarare E 0..1 S Namn eller kommentar, fritext. forsvararenarvarande E 0..1 B inkomforhor E 0..1 D Datum och tid. undervardnadsh E 0..1 B undersocmisstanke E 0..1 B undersoctid E 0..1 B foraldrarunder20 E 0..1 S Föräldrar/Vårdnadshavare för person under 20 år. Fritext. 6.1.1.7 Taxeringskontroll Namn E/A Kard S T Beskrivning inkomst E 0..1 N sambosinkomst E 0..1 N Make/maka/sambos taxerade inkomst. kontrolldatum E 0..1 D ar E 0..1 D Taxeringsår, endast år. kontrollutfordav E 0..1 S 6.1.2 Anmälan En anmälan ingår i ett ärende. Namn E/A Kard S T Beskrivning franrardatum E 1 D Datum då ärendet kom från RAR rubrik E 0..1 S brott E 1..* O administrativt E 1 Ad 6.1.2.1 Brott Namn E/A Kard S T Beskrivning

Bilaga 4 Inleveransspecifikation 18 (25) PVS 937-6118/12 V1.0 benamning E 1 S? S antal E 1 N antalkvarejredovisade E 1 N prioritet E 0..1 N Flera siffror. brottsbeslut E 0..* O misstanke E 0..* O 6.1.2.1.1 Brottsbeslut Namn E/A Kard S T Beskrivning beslutsfattare E 1 S Efternamn, förnamn. beslutsfattare A 1 S titel myndighetskod E 1 S resovisaantal E 1 N antalkvar E 1 N Antal kvar ej redovisade. beslutsdatum E 1 D Datum med tid. beslutstyp E 1 S Lista nedlaggningsgrund E 0..1 S Lista beskrivning E 0..1 S Motivering 6.1.2.1.2 Misstanke Namn E/A Kard S T Beskrivning okandman E 0..1 B Okänd man. okandkvinna E 0..1 B Okänd kvinna. misstanktu15 E 0..1 B Misstänkt under 15 år. status E 1 S overtagen E 0..1 B Övertagen misstanke. idkontrollerat E 0..1 B kontrollsatt E 0..1 S tidigareantal E 1 N Tidigare antal på valt brott. antaltidigarem E 1 N Antal tidigare registrerade misstankar. misstankebeslut E 1..* O 6.1.2.1.2.1 Misstankebeslut Namn E/A Kard S T Beskrivning nedlaggningsgrund E 1 S Lista 6.1.3 Engagerad personal Namn E/A Kard S T Beskrivning status E 0..1 S Lista, anställd, inlånad eller slutad. funktion E 1 S Lista beslutsfattare E 0..1 S beslutsfattare A 0..1 S titel beslutsdatum E 0..1 D Datum och tid.

Bilaga 4 Inleveransspecifikation 19 (25) PVS 937-6118/12 V1.0 6.1.4 Kallelse Namn E/A Kard S T Beskrivning skickatillmalsman E 0..1 B Skicka kallelse till målsman. personnr E 0..1 S namn E 1 S Efter och förnamn. gatunamnplats E 0..1 S gatunr E 0..1 S postnr E 0..1 S ort E 0..1 S land E 0..1 S co E 0..1 S C/O typ E 1 S Kallelsetyp, Lista, radioknappar. handlaggare E 1 S För och efternamn. datum E 0..1 D Datum och tid. telefon E 0..1 S telefon2 E 0..1 S adress E 0..1 S anledning E 1 S Anledning till kallelse. 6.1.5 Tvångsmedel Tvångsmedel kan levereras med eget schema kopplat till ärende. Om informationen levereras tillsammans med DurTvå kan det se ut så här. Namn E/A Kard S T Beskrivning grupp E 1 S Reella eller Personella tvångsmedel. typ E 1 S Lista beslutsdatum E 0..1 S Finns bara om typen ingår i gruppen reella tvångsmedel. namn E 0..1 S Om med i gruppen personella tvångsmedel. status E 1 S Olika listor beroende på grupp. statusdatum E 0..1 D Om med i gruppen personella tvångsmedel. tvangsmedeldata E 1 St CDatafält administrativt E 1 Ad beslut E 1 O historik E 1 O 6.1.5.1 Beslut Kopplat till Tvångsmedel. Namn E/A Kard S T Beskrivning avser E 1 S Lista, typ av tvångsmedel. beslutsdatum E 1 S Datum och tid. beslutsfattare E 1 S beslutsdata E 1 St CDatafält

Bilaga 4 Inleveransspecifikation 20 (25) PVS 937-6118/12 V1.0 6.1.5.2 Historik Kopplat till Tvångsmedel. Namn E/A Kard S T Beskrivning registreratdatum E 1 D anvandare E 1 S beslutsfattare E 1 S beslutsdatum E 1 D handelse E 1 S forandring E 1 S 6.1.6 PM Namn E/A Kard S T Beskrivning datum E 1 D Datum och tid. beslagverkstallt E 0..1 B typ E 1 S Lista mtrlforanalys E 0..1 B uppgiftenavser E 0..1 S Kort beskrivning. uppgiftslamnare E 1 U Efternamn, förnamn. berordperson E 0..1 Be Efternamn, förnamn. rubrik E 0..1 S uppgift E 0..1 S anteckning E 0..* An bilaga E 0..* Bi administrativt E 1 Ad handelseuppgift E 0..1 O uppgiftenmottagen E 0..1 O 6.1.6.1 Händelseuppgift Namn E/A Kard S T Beskrivning intraffatstart E 0..1 D intraffatslut E 0..1 D gatunamn E 0..1 S gatunr E 0..1 S ort E 0..1 S platsbeskrivning E 0..1 S 6.1.6.2 UppgiftenMottagen Namn E/A Kard S T Beskrivning datum E 0..1 D Datum och tid eller tid för sig. uppgiftlamnadvia E 0..1 S Lista paplats E 0..1 S Fri text, På plats.

Bilaga 4 Inleveransspecifikation 21 (25) PVS 937-6118/12 V1.0 6.1.7 Rapport Rapporter: ärendehistorik, brottsrapport, offentliga dagboksuppgifter, involverade personer och engagerad personal. Det blir en rapport av varje per ärende (5 stycken). Namn E/A Kard S T Beskrivning typ E 1 S Vilken typ av rapport. bilaga E 1 Bi 6.1.8 Protokoll Av ärendets utredningsuppgifter kan handläggare sammanställa ett eller flera protokoll (huvudprotokoll, tilläggsprotokoll etc). De uppgifter som vid sammanställning inte ingår i protokollet samlas som uppgifter som inte ingår i protokoll. Om ingen sammanställning av protokoll görs samlas alla ärendets utredningsuppgifter i uppgifter som inte ingår i protokoll. Namn E/A Kard S T Beskrivning typ E 1 S Vilken typ av protokoll. Exempelvis Huvudprotokoll eller tilläggsprotokoll. handlaggare E 1 S Förnamn, efternamn skapad E 1 D Datum då förundersökningsprotokoll skapats. fup E 0..1 Bi Bilaga slask E 0..1 Bi Bilaga 6.1.9 Externt dokument Namn E/A Kard S T Beskrivning uppgiftslamnare E 0..1 U Efternamn, fornamn berordperson E 0..1 Be Efternamn, fornamn Beskrivning E 0..1 S inkomdatum E 0..1 D forvaringsplats E 0..1 S bilaga E 1 Bi handelseplats E 0..1 O 6.1.9.1 Händelseplats Namn E/A Kard S T Beskrivning adress E 0..1 S gatunr E 0..1 S ort E 0..1 S platsbeskrivning E 0..1 S 6.1.10 Egna anteckningar Namn E/A Kard S T Beskrivning typ E 1 S Lista datum E 1 D Redovisas ej i DurTvå.

Bilaga 4 Inleveransspecifikation 22 (25) PVS 937-6118/12 V1.0 forfattare E 1 S Efternamn, fornamn rubrik E 0..1 S anteckning E 0..1 S 7 Specifikt K-RAR K-RARs egna objekt, som bara kommer från K-RAR är färgade i grönt, liksom bilden i kapitel Karta över objekten. De som är gula är gemensamma objekt men där K-RAR har en del egen information. 7.1 Ärende Ärende är huvudobjekt i informationsstrukturen. Ärende med sitt diarenummer är det som binder ihop information levererat från olika system. Ärende har en 1 till 1 relation med anmälan vilket betyder att ett ärende endast har och kan ha en anmälan. Ärendet kan ingå i andra ärenden eller ha ärenden under sig. Till ärendet i K-RAR hör fuledare och handläggare, dessa återfinns i objektet engagerad personal. Namn E/A Kard S T Beskrivning diarienrannanm E 0..* S S Diarienummer annan polismyndighet myndighetskod E 1 S slutredovisningsdatum E 1 D balansfortur E 0..1 S balans E 0..1 S balansansvarig E 0..1 S aklforbeslutfu E 0..1 S enhet E 1 Handläggande enhet aklagaremyndighet E 0..1 S Namnet på åklagarens myndighet. aklagaremyndighet kod A 0..1 S datumlottning E 0..1 D remiss E 0..1 S fubeslut E 1 S fubeslutsdatum E 1 D Datum och tid fubeslutsfattare E 1 S Efternamn, förnamn bildibip E 1 B Ja/Nej det finns bild sparad. totaltgodsvarde E 0..1 S involveradperson E 1..* O anmalan E 1 O Det finns alltid endast en anmälan kopplad till ett ärende. arendebeslut E 1..* O Minst ett ärendebeslut finns i ärendet. engageradpersonal E 1..* O Myndighetsanställd som är engagerad i ärendet. gods E 0..* O anteckning E 0..* O Slutredovisningsanteckningen. historik E 1 O

Bilaga 4 Inleveransspecifikation 23 (25) PVS 937-6118/12 V1.0 7.1.1 Involverad person Namn E/A Kard S T Beskrivning yrke E 0..1 S S Yrke/Titel arbetsplats E 0..1 S under15 E 1 S B J eller N. idstyrkt E 1 B J eller N. styrktsatt E 0..1 S Id styrkt på vilket sätt. fodelseland E 0..1 S fodelseort E 0..1 S adress E 0..* O Objekt telefon E 0..* O Objekt dagsbotsuppgifter E O Objekt underrattelseinfo E 0..1 O Objekt roll E 1..* O Objekt anteckning E 0..1 O Objekt, Fuk 13. 7.1.1.1 Underrättelseinfo Namn E/A Kard S T Beskrivning fuk13a E 1 S broschyr E 1 S kanantasbrottsofferstod E 1 B kontaktbrottsofferstod E 1 S infomalsagarbitrade E 1 B onskasmalsagarbitrade E 1 B forordnatmalsagarbitrade E 1 S forordnatmalsagarbitradetfn E 1 S inforbesoksforbud E 1 S fuk13cgripenanhallenavviker E 1 B fuk13cannat E 1 S lamnadav E 1 S Namn lamnadav titel A 1 S lamnaddatum E 0..1 D kontaktbrottsofferstod E 1 O fuk13b E 1 O anhorigkontaktperson E 0..1 O 7.1.1.1.1 KontaktBrottsofferstöd Namn E/A Kard S T Beskrivning onskarkontakt E 1 B brottsofferstod E 1 S annatbrottsofferstod E 1 S 7.1.1.1.2 fuk13b (Förundersökningskungörelse 13b) Namn E/A Kard S T Beskrivning tillfragad E 1 B villunderrattas E 1 B fuejinleds E 1 B funedlagges E 1 B atalejvacks E 1 B tidpunkthuvudforhandling E 1 D dom E 1 S

Bilaga 4 Inleveransspecifikation 24 (25) PVS 937-6118/12 V1.0 7.1.1.1.3 AnhörigKontaktperson Namn E/A Kard S T Beskrivning efternamn E 0..1 S mellannamn E 0..1 S fornamn E 0..1 S tilltalsnamn E 0..1 S co E 0..1 S adress E 0..1 S postnr E 0..1 S ort E 0..1 S land E 0..1 S tfnbostad E 0..1 S tfnarb E 0..1 S yrke E 0..1 S anteckningar E 0..1 S 7.1.2 Anmälan En anmälan ingår i ett ärende. Vid sökning är alltid inskrivningsdatum med. Namn E/A Kard S T Beskrivning upptagandemyndighet E 1 S Upptagande p-myndighet upptagandemyndighet kod A 1 S upptagandemyndighetenhet E 1 S anmalningssatt E 1 S upptagenav E 1 S inskrivenav E 1 S inskrivendatum E 1 S D Datum och tid handlaggandemyndighet E 1 S handlaggandeenhet E 1 S bilagor E 0..1 S Text om bilagor brott E 1..* O tillaggsanmalan E 0..* O Tillägg till anmälan ajourforing E 0..* O Upprättas då ändring görs i anmälan. 7.1.2.1 Brott Namn E/A Kard S T Beskrivning hatbrott E 1 S B Om brottet är ett hatbrott misstanke E 0..* O 7.1.2.1.1.1 Misstankebeslut Namn E/A Kard S T Beskrivning pblad E 0..1 B Personblad underrmisstankt E 0..1 B Underrättelse misstänkt. underrmalsagare E 0..1 B Underrättelse målsägare. aklagarmyndihetensdnr E 0..1 S beslutsgrund E 0..1 S overlamning E 0..1 S redovisning E 1 O aterupptagning E 1 O

Bilaga 4 Inleveransspecifikation 25 (25) PVS 937-6118/12 V1.0 7.1.2.1.1.1.1 Redovisning Namn E/A Kard S T Beskrivning fuprot E 0..1 S fuant E 0..1 S rb23:22 E 0..1 S 7.1.2.1.1.1.2 Återupptagning Namn E/A Kard S T Beskrivning beslutsfattare E 0..1 S Namn beslutsfattare A 0..1 S titel datum E 0..1 D 7.1.2.2 Tilläggsanmälan Tillkommande uppgifter i en anmälan. Namn E/A Kard S T Beskrivning upptagandemyndighet E 1 S Upptagande polismyndighet upptagandemyndighet kod A 1 S upptagandemyndighetenhet E 1 S anmalningsdatum E 1 D anmalningssatt E 1 S upptagenav E 1 S inskrivenav E 1 S inskrivendatum E 1 D Datum och tid. inskrivenenhet E 1 S uppgiftlamnare E 1 S Namn, oftast målsägaren. beskrivning E 0..1 S Händelsebeskrivning i fritext. bilagor E 0..1 S 7.1.2.3 Ajourföring Ändrade uppgifter i en anmälan. Namn E/A Kard S T Beskrivning inskrivenav E 1 S inskrivendatum E 1 D Datum och tid inskrivenenhet E 1 S ajourforingtext E 0..1 S De förändrade uppgifterna.

Bilaga 5, IT-miljö inom RPS PVS 937 6118/12 1.0 Bilaga 5 IT-miljö inom RPS

Bilaga 5, IT-miljö inom RPS PVS 937 6118/12 1.0 Innehåll INNEHÅLL 2 1. SYFTE MED DETTA DOKUMENT 4 2. OPERATIVSYSTEM 4 2.1 Limbo 4 2.2 Microsoft Windows 4 3. HÅRDVARUPLATTFORMAR 4 4. INTEGRATIONSPLATTFORMAR 4 5. BACKUP 4 6. ÖVERVAKNING 5 7. VIRTUALLISERINGSPRODUKTER 5

Bilaga 5, IT-miljö inom RPS PVS 937 6118/12 1.0 Datum Ändring Handläggare 1.0 2012-10-19 Ann Rosenlind

Bilaga 5, IT-miljö inom RPS PVS 937 6118/12 1.0 1. Syfte med detta dokument Detta dokument beskriver de IT-tekniska plattformarna som används inom RPS och som e-arkivet ska ha stöd för. I bilagan specificeras vilka plattformar som används inom Polisen. Denna bilaga ska accepteras i Anbudsformuläret. 2. Operativsystem 2.1 Limbo SLES 11 (SuSE Linux Enterprise Server (inkl. OES) Apache 2.2.3 (den version som ingår i SLES 11) Jboss EAP 5 (Enterprise Application Platform) RSA Access Manager Apache Web Agent 4.8 RSA Access Manager Jboss SSO Agent 2.2 MySQL 5.5 eller Oracle 11 Java JDK/JRE 6 (64-bit) 2.2 Microsoft Windows Windows Server 2008 R2 X64 Microsoft SQLServer 2008 R2 X64 Microsoft Windows 7 3. Hårdvaruplattformar 3.1 Strategisk plattform x86 Intel/AMD x64 Intel/AMD 4. Integrationsplattformar 4.1 Strategisk plattform SHS IBM Websphere Message Broker 5. Backup 5.1 Strategisk plattform

Bilaga 5, IT-miljö inom RPS PVS 937 6118/12 1.0 Symantec Netbackup 6. Övervakning 6.1 Strategisk plattform HP Operation Manager HP Business Availability Center HP Network Node Manager (NNM/NNMi) HP Performance Manager HP System Insight Manager MS System Center Operations Manager 7. Virtualliseringsprodukter 7.1 Strategisk plattform VMware

Bilaga 6, Kvalitetsdokument 1 (11) PVS 937-6118/12 1.0 Bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering

Bilaga 6, Kvalitetsdokument 2 (11) PVS 937-6118/12 1.0 INNEHÅLL 1 SYFTE MED DETTA DOKUMENT... 4 2 KVALITETSSTYRNING... 4 2.1 Leverantörens kvalitetsstyrning... 4 2.2 Kvalitetsansvarig... 5 2.3 Kvalitetsarbete i leveranser... 5 2.4 Leverantörsinspektioner... 5 3 KVALITETSARBETE I UTVECKLING... 6 3.1 Krav och design... 6 3.2 Leverantörens tester... 6 3.3 Releasenoteringar... 6 4 KVALITETSARBETE I SUPPORT... 7 5 KVALITETARBETE KRING SÄKERHET... 7 6 KVALITETARBETE GENOM RISKHANTERING... 7 7 ACCEPTANSPROCEDUR... 8 7.1 Acceptansprocedur... 8 7.2 Klassning av fel och brister... 8 7.3 Godkännande... 9 8 ÄNDRINGSHANTERING OCH AVROP... 9 8.1 Ändringsprocedur... 9 8.2 Besluts- och ändringslogg... 10 8.3 Beslut... 11

Bilaga 6, Kvalitetsdokument 3 (11) PVS 937-6118/12 1.0 shistorik Datum Ändring Handläggare 1.0 2012-10-19 Ann Rosenlind

Bilaga 6, Kvalitetsdokument 4 (11) PVS 937-6118/12 1.0 1 Syfte med detta dokument Detta dokument beskriver hur Leverantören ska arbeta med kvalitet. Vidare definieras kvalitetsarbete genom riskhantering, acceptanstestproceduren och proceduren för ändringshantering och avrop. 2 Kvalitetsstyrning 2.1 Leverantörens kvalitetsstyrning För att säkerställa efterfrågad kvalitet i uppdraget ska Leverantören arbeta efter ett kvalitetssystem med dokumenterade rutiner för kvalitetsstyrning av sin verksamhet. Leverantörens kvalitetssystem kan antingen vara i form av en ISO-certifiering för SS EN-ISO 9001, motsvarande eller i form av ett eget dokumenterat kvalitetssystem. Kvalitetsstyrning av en verksamhet innebär att Leverantören har ett dokumenterat system som bland annat omfattar företagets organisatoriska strukturer, roller och ansvar. Vidare innefattas processer, rutiner och riktlinjer för kravarbete, utveckling, test, systemdokumentation, användardokumentation, releasearbete, helpdesk, och hur risker/fel/ brister tas om hand/åtgärdas, men också processer, rutiner och riktlinjer för områden som t.ex. rekrytering av medarbetare och underleverantörer, kompetensutveckling av medarbetare, avvikelserapportering, hantering av kundklagomål samt uppföljning av kvaliteten på avtalade leveranser. RPS ställer särskilt höga krav på att alla aspekter kring informationssäkerhet. Leverantören ska därmed särskilt kunna påvisa rutiner och styrning inom detta område, såsom att Leverantören använder SS-IEC/ISO 27001 som ledningssystem för informationssäkerhet (LIS), motsvarande eller har hanteringen inbyggt i sitt kvalitetssystem och ska då omfatta säkerhetspolicys, riktlinjer och rutiner avseende sitt informationssäkerhetsarbete.

Bilaga 6, Kvalitetsdokument 5 (11) PVS 937-6118/12 1.0 2.2 Kvalitetsansvarig Leverantören ska ha en utsedd kvalitetsansvarig. Det är kvalitetsansvarigs ansvar att löpande följa upp kvalitetsmålen och påtala behov av kvalitetsåtgärder. Det gäller såväl utveckling och underhåll av standardsystemet som Leverantörens leverans till RPS. 2.3 Kvalitetsarbete i leveranser Kvalitetsaktiviteter ska arbetas in i Leverantörens leveranser till RPS. Detta avser både i såväl projekt- som förvaltningsläge. 2.4 Leverantörsinspektioner RPS äger själv eller genom tredje man rätten att genomföra inspektion av Leverantörens verksamhet och tjänster. Inspektionsrätten omfattar även de underleverantörer som är berörda av leveransen till RPS. Sedan januari 2012 genomför RPS leverantörsinspektioner baserade på den struktur som finns i ISO 9001. Vid inspektionen granskas även Leverantörens arbete i relation till avtalade leveranser till RPS. Särskild inspektion kan även förekomma kring säkerhet. Figur 1 Inspektionsprocessen Under planeringsfasen skickar RPS en agenda för inspektionen samt uppgifter om när den kommer att genomföras. Leverantören ska inom rimlig tid efter RPS underrättelse ge RPS, eller sådan tredje man som avses ovan, tillgång till all dokumentation och/eller tillträde de lokaler som Leverantören eller dennes underleverantör använder vid utförande. Leverantören ska vidare tillhandahålla access till Leverantörens personal och Leverantörens underleverantörs personal. Resultat från inspektionen dokumenteras i ett protokoll, vilket sammanfattar vilka eventuella brister som Leverantören ska åtgärda. Leverantören ska inom rimlig tid inkomma med svar hur eventuella brister ska åtgärdas.

Bilaga 6, Kvalitetsdokument 6 (11) PVS 937-6118/12 1.0 I de fall RPS och Leverantören inte kan kommer överens om åtgärder eller tidplan för när bristen ska vara åtgärdad eskaleras frågan vidare: - I projektläge till projektets styrgrupp, - I förvaltningsläge till ett samverkansmöte. 3 Kvalitetsarbete i utveckling 3.1 Krav och design För funktionalitet som utvecklas speciellt för RPS ska krav och design dokumenteras av Leverantören och godkännas av RPS. Framtagen dokumentation ska vara författad på svenska och levereras till RPS i av RPS godkända format. 3.2 Leverantörens tester Vid varje leverans till RPS, av Systemet, ny release eller delar därav, ska Leverantören kunna visa upp en testplan med tillhörande testfall. Vidare ska Leverantören bifoga ett testprotokoll till leveransen som visar att testplanen är genomförd och resultatet därav. Testerna ska alltid omfatta ett antal huvudtester, som verifierar ett helt systemflöde. Vid leverans av nya releaser innehållande tillkommande eller förändrad funktionalitet ska särskilda tester kunna uppvisas på den tillkommande eller förändrade funktionaliteten. Innefattar den nya releasen förändringar i standardsystemet, inklusive ingående tredjepartsprodukter, ska standardfunktionalitet testas om. Vid förändringar av funktionalitet i standardsystemet ska Leverantören via tester säkerställa att specialutvecklad kod för RPS fortfarande fungerar och att systemet fungerar på den systemplattform med hårdvara, operativsystem, databas och driftsrelaterade produkter parterna är överens om utgör en grundplattform. 3.3 Releasenoteringar För varje hel eller delar av release som levereras till RPS ska dokumentation bifogas som beskrivs vad releasen omfattar och vad som är förändrat.

Bilaga 6, Kvalitetsdokument 7 (11) PVS 937-6118/12 1.0 4 Kvalitetsarbete i support Leverantören ska ha en bemannad supportfunktion som kan ta emot och systematiskt hantera anmälda fel och brister samt svara på frågeställningar om standardsystemet. Leverantören ska tillhandahålla ett supportsystem där alla anmälningar loggas, prioriteras och eskaleras, kan följas samt avrapporteras med uppgift om när/hur anmälda fel/brist är åtgärdad. I samma kanal ska även anmälningar om förbättringar i standardsystemet kunna rapporteras in och där den fortsatta hanteringen ska kunna följas. RPS ska kunna följa statusframskridandet av en anmälning. 5 Kvalitetarbete kring säkerhet Leverantören ska ha fastställda rutiner för rapportering av säkerhetsbrister för standardsystemet. Detta inkluderar även ingående tredjepartsprodukter. Leverantören ska inhämta kontinuerligt information om tekniska sårbarheter rörande standardsystemet, inklusive ingående tredjepartsprodukter och informera RPS om förslag på åtgärder. Leverantören ska kontinuerligt och utan fördröjning rapportera säkerhetsincidenter till RPS till angiven kontaktadress. 6 Kvalitetarbete genom riskhantering Parterna ska tillsammans löpande analysera och dokumentera genomförande- och systemrisker tillsammans med åtgärdsplaner. Under projektläge är en av de första aktiviteterna vid projektstart att genomföra en gemensam riskanalys. Därefter ska riskerna kontinuerligt följas upp och dokumenteras inom ramen för varje gemensamt projektmöte och operativt samordningsmöte. Risker ska löpande presenteras på projektstyrgruppsmöten respektive samverkansmöte på affärsmannanivå.

Bilaga 6, Kvalitetsdokument 8 (11) PVS 937-6118/12 1.0 7 Acceptansprocedur 7.1 Acceptansprocedur För varje systemleverans, ny release eller delar av därav som levereras ska de installeras i RPS testmiljö för genomförande av en acceptanstest. RPS är ansvariga för att genomföra acceptanstester och som utgör grunden för godkännande av leveranser. Annan överenskommelse kan finnas avseende prestandatester. Acceptanstestprotokoll ska vara skriftliga och på ett format som båda parterna är överens om. Varje identifierad fel/brist ska vara klassificerat enligt definierande nivåer nedan under avsnitt 7.2.2. Om inget annat är överenskommet ska RPS:s acceptanstest och återkoppling till Leverantören vara genomförd senast trettio (30) kalenderdagar efter mottagen leverans. Funna fel/brister rapporteras dock löpande för att maximera tiden för felrättning. Leverantören svarar för felsökning, men RPS ska underlätta arbetet genom att bland annat bereda tillgång till testfall och testdata för hur testerna är genomförda. Om inget annat är överenskommet ska Leverantören skriftligt återkoppla med åtgärdsplan senaste fjorton (14) kalenderdagar efter överlämnat acceptanstestprotokoll. 7.2 Klassning av fel och brister 7.2.1 Definition av fel och brister Med fel och brister avses avvikelse från bilaga 1 Kravspecifikation, där fel avser ett felaktigt realiserat krav medan brist avser att kravet inte har realiserats. Till fel och brister räknas oförmåga hos Leverantören att uppfylla aktuell kravspecifikation även vid felaktigheter eller brister i tredjepartsprodukter såsom operativsystem och databashanterare. Till fel och brister räknas inte tillfällig funktionsnedsättning orsakad av driftförhållande eller hårdvarufel för vilket RPS ansvarar. 7.2.2 Klassificering av fel och brister RPS kommer att klassificera fel och brister i följande nivåer:

Bilaga 6, Kvalitetsdokument 9 (11) PVS 937-6118/12 1.0 1. Blockerande stoppande fel/brister. Det går inte att färdigställa en uppgift. Vid prestanda klassas felet som blockerande om genomförda tester visar på mer än fyrdubbla tiden i angivet krav. 2. Hindrande allvarliga fel/brister, men uppgiften går att färdigställa via work around. Vid prestanda klassas felet som hindrande om genomförda tester visar på mer än dubbla tiden i angivet krav. 3. Störande fel/brist, men hindrar inte användaren/systemet att genomföra en uppgift. Vid prestanda klassas felet som störande om genomförda tester visar på upp till dubbla tiden i angivet krav. 4. Kosmetika mindre fel/brist som enbart påverkar användargränssnittet såsom ledtexter och färger. 7.3 Godkännande Formellt skriftligt leveransgodkännande för respektive avtalad leverans under projektläge görs av RPS:s programstyrgrupp. Formellt leveransgodkännande för respektive avtalad leverans under förvaltningsläge görs av RPS:s affärsansvarig. Förutsättningar för godkännande: - Fel/brist nivå 1 och 2 ska rättas innan leveransgodkännande lämnas. - Fel/brist nivå 3 innebär att en leveransgodkännande kan lämnas, men felet/bristen ska åtgärdas av Leverantören inom överenskommen åtgärdstid. - Fel/brist nivå 4 påverkar inte leveransgodkännande, men de ska vara åtgärdade till nästkommande kompletta release. 8 Ändringshantering och avrop I detta avsnitt specificeras rutiner för ändringshantering. 8.1 Ändringsprocedur Syftet med proceduren för ändringshantering är att säkerställa att ändringar och tillägg behandlas enhetligt och kontrollerat.

Bilaga 6, Kvalitetsdokument 10 (11) PVS 937-6118/12 1.0 Ändringarna och tilläggen kan omfatta såväl funktionalitet, som resursallokering, aktivitetsplaner etc., men också innefatta avrop av t.ex. en utbildning. Diskussion om inkomna förslag hanteras på projektmöten/samordningsmöten eller på särskilda möten vid större omfattning. Akuta frågor behandlas per e-post och telefon. Principbeslut och diskussioner om ambitionsnivåer ska hanteras i projektstyrgruppen under projektläge och i samverkansmöte på affärsmannanivå i förvaltningsläge. 8.2 Besluts- och ändringslogg Varje överenskommelse om förändring ska vara skriftliga och föras in i en Besluts- och ändringslogg som RPS ansvarar för. Loggen innehåller uppgifter till alla förslag till förändringar. För varje inkommet förslag tas beslut om: Utreds, Genomförs, Avslås, eller Avvaktar. Därtill anges uppgift om prioritet och komplexitet. Innan beslut tas måste ändringsförslaget vara tydligt och konsekvenserna kända. För varje inkommet förslag tas därför beslut om frågan ska/behöver utredas närmare. I detta beslut fastställs även vem som ska utreda och om ansvaret ligger på Leverantören ska det tydligt framgå om utredningen innefattas i Leverantörens åtagande eller om detta är ett tillägg. Om inget annat avtalas omfattas diskussioner och enkla verifieringar på vad ändringar får för konsekvenser i Leverantörens åtagande. Detta innefattar även att ta fram en kostnadskalkyl på vad en ändring kräver för tidsåtgång i genomförande. Större utredningar kräver överenskommelse kring omfattning av utredningsinsats och vem som står för kostnaden. 8.3 Avrop RPS kan avropa optioner vilka är specificerade i bilaga 1, Kravspecifikation. Optionerna kan avropas både under projektet och i förvaltningsläge. 8.3.1 Avropsvillkor Samtliga avrop som RPS gör ska Leverantören kunna påbörja inom trettio (30) kalenderdagar från det att avrop gjorts. För avvikande inställelsetider se avsnitt 8.3.2 Avropsvillkor i projektläge.

Bilaga 6, Kvalitetsdokument 11 (11) PVS 937-6118/12 1.0 Leverantören ska fjorton (14) kalenderdagar innan start lämna till RPS uppgifter om utpekade resurser som ska genomföra uppgiften. Avbeställning av gjorda avrop, från RPS:s sida, ska senast göras fjorton (14) kalenderdagar innan planerat genomförande. Uppsägningstiden är fjorton (14) kalenderdagar och Leverantören erhåller ersättning för beställt arbetet under uppsägningstiden. Både beställning och avbeställning av avrop ska ske skriftligt enligt avtal. 8.3.2 Avropsvillkor inom projekttiden för Avropsvillkor för optionerna Integration med lagringslösning samt Migrering specificeras i bilaga 2 Beskrivning av projektet och dess leveranser. Vid avrop av timmar, inom projekttiden, ska Leverantören ha beredskap att avsätta resurser med en inställelsetid på 2 dagar. 8.4 Beslut För att öka effektivitet tilldelas RPS:s projektledare/förvaltningsansvariga ett mandat inom vilka ramar denne direkt kan fatta beslut för. Leverantörens projektledare/samordningsansvarig ska ha motsvarande mandat. Hur mandaten ser ut ska dokumenteras vid igång av projektläge respektive förvaltningsläge. För större beslut, men inom ramen för avtalad leverans har RPS:s affärsansvarig mandat att ta beslut. Leverantörens affärsansvarig ska ha motsvarande mandat. Beslut förs in i Besluts- och ändringsloggen. För mindre enstaka beslut som omfattar mindre än åtta (8) timmar godtas ett bekräftande e-post räcka. För större omfattning krävs ett underskrivet besluts/avropsunderlag. Är parter inte överens kan ena parten eskalera frågan till högre nivå, enligt bilaga 3 Samverkan och styrning.

Rikspolisstyrelsen 1(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning PVS-937-6118/12 Bilaga 7 Arkitekturbeskrivning E-arkivet

Rikspolisstyrelsen 2(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning Innehållsförteckning PVS-937-6118/12 INLEDNING... 4 1.1 SYFTE... 4 1.2 OMFATTNING... 4 1.3 TILLÄMPNING... 4 2 ARKITEKTURENS MÅL... 4 3 LOGISK VY... 5 3.1 ÖVERSIKT... 5 3.2 LAGERINDELNING... 5 3.2.1 Klientlager... 6 3.2.2 Affärslogiklager... 6 3.2.3 Integrationslager... 6 3.2.4 Datalager... 6

Rikspolisstyrelsen 3(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning shistorik Datum Ändring Handläggare 1.0 2012-10-19 Ann Rosenlind PVS-937-6118/12

Rikspolisstyrelsen 4(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning PVS-937-6118/12 Inledning 1.1 Syfte Syftet med dokument är att beskriva RPS e-arkivs arkitektur och dess samverkan med andra befintliga verksamhetssystem. Dokumentet ska stödja kommunikation mellan beställare, arkitekter, utvecklare samt leverantör. 1.2 Omfattning Dokumentet fokuserar på att visa kritiska och signifikanta mekanismer kring arkitektur och infrastruktur. 1.3 Tillämpning En anbudsgivare ska genom detta dokument få en förtydligande bild av RPS tekniska krav på e-arkivet och hur det bäst integreras i RPS systemmiljö. Dokumentet ger med andra ord ytterligare information om vissa aspekter utöver de funktionella- och icke-funktionella krav som redan angivits i bilaga 1 Kravspecifikation. 2 Arkitekturens mål Beskrivningen av arkitekturen för e-arkivet syftar till att förtydliga e-arkivets utformning så att det passar in i RPS övergripande arkitektur och för att underlätta integration med andra verksamhetssystem och processer. E-arkivet är flexibelt avseende driftsmiljöns konfiguration och bakomliggande teknik. Viktiga mål för arkitekturen är att e-arkivet ska: Vara generellt och utbyggbart. Vara anpassningsbart till underliggande tjänsters förändringar. Tillgodose ställda krav på prestanda och samtidighet. Tillgodose ställda krav på tillförlitlighet. Tillgodose ställda krav på säkerhet och loggning. Vara lätt att underhålla. Viktiga mål för säker informationshantering: Hållbart över tid - informationen måste finnas kvar och vara läsbar över tid, trots mjuk- och hårdvaruuppdateringar. Autentiskt - informationen ska vara oförvanskad och behöriga personer ska komma åt rätt information. Viktiga mål för effektiv informationshantering: Sökning e-arkivet ska ha effektiv funktion för att kunna söka och hitta informationen. Samlade ärenden lösningen möjliggör att all information om ett ärende lagras och hämtas på ett ställe. En samlad arkivredovisning e-arkivet kan redovisa både elektronisk och analog information. Enkelt att ansluta och leverera det får inte vara för höga hinder för att ansluta till tjänsten och vara beskaffat med flera anslutningssätt. Behovet från verksamheten och möjligheten att möta behovet ska styra.

Rikspolisstyrelsen 5(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning Viktiga mål för juridiskt korrekt informationshantering: PVS-937-6118/12 Logiskt avskild information lösningen för e-arkivet ska vara gemensam för alla myndigheter inom Polisen, men respektive myndighet ska kunna ha var sitt arkiv, logiskt avskilt från de andra. Stödja olika leveransscenarion lösningen kan ta emot leveranser av information när verksamheten behöver leverera för att bland annat uppfylla polisdatalagens krav. 3 Logisk vy Den logiska vyn, i figur 1, innefattar en statisk struktur som visar hur olika fundamentala verksamhetssystem hänger ihop. 3.1 Översikt För att få e-arkivet att passa in i RPS arkitektur är det viktigt att identifiera vilka delar av e-arkivet som använder sig av generell funktionalitet, dvs. sådana funktioner som återkommer och är likartad i flera andra av RPS system. Användare gränssnitt Anslutande system som levererar / hämtar information E-Arkivet Användartjänster (AD,LDAP...) Medelandetjänster (E-post,SMS..) Logg (Central Säkerhets-Logg) Fig. 1. E-arkivet har sitt eget användargränssnitt som kan anropas från andra verksamhetssystem. Bilden visar en översikt över E-arkivets kopplingar till andra verksamhetssystem. 3.2 Lagerindelning Följande kapitel beskriver kort en tänkt uppdelning av e-arkivets inre logiska lager, och vilka arkitekturella krav RPS har inom respektive område. Varje lager är skalbart och kan skalas upp vid behov för att minimera risken till eventuella framtida prestandaproblem. Lastbalansering är att föredra mellan logiska lager.

Rikspolisstyrelsen 6(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning PVS-937-6118/12 Fig. 2. Bilden visar en översikt över e-arkivets inre logiska lager med koppling till Databaslagret, utanför e-arkivet. 3.2.1 Klientlager E-Arkivet har en tunn, webbaserad klient. All kommunikation mellan klient och server sker företrädelsevis med HTTPS och SOAP (dvs via web services med två-vägs-autentiserad SSL), för att tillåta en så enkel integration som möjligt och vara anpassningsbar i RPS gällande infrastruktur. 3.2.2 Affärslogiklager E-arkivet implementerar logiken och verksamhetsreglerna som är kravställda. Affärslagret är uppdelat i flera moduler, så som en integrationsmodul, en modul för workflow, en för mottagning Mottag, en för arkivvård/förvaltning/redovisning Administration, en för åtkomst Access, en för lagring/migrering osv. Några av dessa moduler beskrivs ytterligare nedan. 3.2.3 Integrationslager E-arkivet samlar alla sina kopplingar mot andra verksamhetssystem i en särskild logisk modul för integration. Detta för att förenkla underhåll och administration. Desto öppnare och flexiblare denna integrationsmodul är desto bättre. RPS primära protokoll mot andra system är meddelandehantering via MQ och synkron kommunikation via web services över HTTPS. E-arkivet kan tillgängliggöra sin informationsdomän tjänstebaserat, t.ex. via web services eller via en asynkron meddelandehanterare. E-arkivet ska med andra ord vara öppet för integration från andra verksamhetssystem och processer. WSDL-filer är kompatibla enligt WS-I (Web Services Interoperability). 3.2.4 Datalager Det finns en flexibilitet då det gäller val av databashanteraren så RPS kan byta databashanterare i framtiden. Inom Polisen är MySQL standard databashanterare. Det finns även installationer med Oracle samt några installationer med Microsoft SQL Server i drift. Databasen kan partioneras för att kunna hantera ett stort antal arkivobjekt och det är möjligt att bibehålla prestanda även fast volymen av arkivobjekt successivt kommer att öka.

Rikspolisstyrelsen 7(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning PVS-937-6118/12 Lagring av digitala filer Archival Storage kan ske mot olika typer av lagringsmedia för att garantera ett långsiktigt bevarande, integrationen mellan e-arkivet och datalagret är objektbaserad via REST, SOAP eller liknande gränssnitt som transparant lagrar informationen på lämpligt lagringsmedia. För information som mycket sällan efterfrågas är det möjligt att lagra på sekventiellt lagringsmedia såsom band, för information som frekvent efterfrågas är det möjligt att lagra på snabbt lagringsmedia såsom disksystem. Det är möjligt att migrera information mellan olika lagringsteknologier om åtkomstbehovet för lagrade filer förändras. Det finns en flexibilitet gällande kopplingen till lagringsskiktet så RPS har möjlighet att migrera till framtida lagringsteknologier eller tillverkare över tid. Exempel på verksamhetssystem som skulle kunna dra nytta av att dela datalager med e-arkivet är Mediatjänsten, ett tänkt system för kunna hantera lagring av stora volymer av exempelvis ljud, bild, video och speglade hårddiskar. Information som lagras i Mediatjänsten kan tillhöra pågående ärenden. Detta gör att flera och helt andra användare än e-arkivets behöver tillgång till Mediatjänsten vilket ställer högre krav på tillgänglighet och prestanda i förhållande till e-arkivet. I Mediatjänsten måste fler format än de som tillåts i e-arkivet lagras. Det är inte heller alltid möjligt att följa standardformat på filer som lagras eftersom de kan ha källor som Polisen inte råder över. Detta ställer höga krav på tillgång till och bevarande av presentationsapplikationer då de kan vara svårt att formatkonvertera. Om konvertering genomförs finns det behov att spara ursprungsexemplaret för att ha full spårbarhet och minimera risken till informationsförlust. Mediatjänsten kommer att lagrar stora filer och stora informationsmängder vilket ställer höga krav både på prestanda och på lagringsvolymer.

Bilaga 8 Användningsfall 1 (24) PVS-937-6118/12 1.0 Bilaga 8 Användningsfall

Bilaga 8 Användningsfall 2 (24) PVS-937-6118/12 1.0 Innehållsförteckning 1 ANVÄNDNINGSFALLSÖVERSIKT... 4 1.1 Begrepp... 5 1.2 Aktörer... 5 1.2.1 Arkivadministration... 5 1.2.2 Lokal arkivfunktion... 5 1.2.3 Drifts- och förvaltningsorganisation... 5 1.2.4 Konsument... 5 1.2.5 Producent... 6 1.2.6 E-arkivet... 6 1.2.7 Leveransapplikation... 6 1.3 Avgränsning... 7 1.4 Process: Leverera SIP... 7 AF01. Testa SIP... 8 1.5 Process: Ta emot SIP... 8 AF02. Administrera leverans... 9 AF03. Ta emot SIP...10 1.6 Process: Vårda och framtidssäkra... 11 AF04 Administrera valideringsregler...11 AF05 Administrera gallringsregler...12 AF06 Administrera konverteringsregler...13 AF07 Validera AIP...13 AF08 Gallra AIP...14 AF09 Konvertera AIP...15 AF10a Förändra AIP...15 AF10b Skriva notering till AIP...16 AF11 Hämta statistik och rapporter...17 1.7 Process: Förvalta och drifta... 18 AF12 Administrera behörigheter...18 1.8 Process: Redovisa arkiv... 19 AF13 Administrera noder för arkivredovisning...20 AF14a Upprätta arkivredovisning...20 AF14 b Redovisa arkivobjekt...21 1.9 Process: Söka AIP... 21 AF15 Söka AIP...22 1.10 Process: Tillhandahålla DIP... 23 AF16 Tillhandahålla DIP...23 AF 17 Tillhandahålla tillfällig behörighet...24

Bilaga 8 Användningsfall 3 (24) PVS-937-6118/12 1.0 Datum Ändring Handläggare 1.0 2012-10-19 Ann Rosenlind

Bilaga 8 Användningsfall 4 (24) PVS-937-6118/12 1.0 1 Användningsfallsöversikt Detta dokument beskriver de användningsfall som har identifierats för Polisens e-arkiv. Syftet med denna sammanställning är att ge en översiktlig bild av möjliga framtida scenarion för hur polisen jobbar i e-arkivet, komplement till kraven. Polisens miljöer dvs de plattformar och teknik som e-arkivet ska anpassas till finns beskrivna i bilaga 7 Arkitekturbeskrivning. Användningsfallen är grupperade under de processer som e-arkivet ska stödja. Som en ingång till användningsfallen beskrivs varje process kortfattat. Följande processer har definierats: - Leverera SIP - Ta emot SIP - Vårda och framtidssäkra arkivobjekt (AO) - Förvalta och drifta e-arkivet - Redovisa arkivobjekt - Söka arkivobjekt - Tillhandahålla DIP Figur 1 E-arkivet med tillhörande processer och användningsfall

Bilaga 8 Användningsfall 5 (24) PVS-937-6118/12 1.0 1.1 Begrepp I detta dokument används centrala begrepp för e-arkivet. Vissa av dessa bygger på begrepp från OAIS-modellen (ISO 14 721:2003). Begreppen finns sammanställda i en begreppsmodell, bilaga 9 Begreppsmodell. 1.2 Aktörer Följande aktörer har identifierats. - Arkivadministration - Lokal arkivfunktion - Drifts- och förvaltningsorganisation - Konsument - Producent - E-arkivet - Leveransapplikation 1.2.1 Arkivadministration Arkivadministrationen är den aktör som bl.a. administrerar och förbereder e- arkivet för nya leveranser samt sätter upp regler för arkivredovisning. Aktören administrerar nya regler för konvertering, validering samt gallring. 1.2.2 Lokal arkivfunktion Vid varje polismyndighet finns en arkivfunktion. Den lokala arkivfunktionen upprättar arkivredovisning samt söker och lämnar ut DIP från e-arkivet till allmänheten och medarbetare inom myndigheten. 1.2.3 Drifts- och förvaltningsorganisation Denna aktör sköter drift och förvaltning av e-arkivet och kommer bl.a. att hantera säkerhetskopiering, behörighetshantering och övervakning. 1.2.4 Konsument Konsumenten är den aktör som söker i e-arkivet och tar del av arkivobjekten. En konsument kan vara: - Handläggare som söker AO via Polisens intranät, Intrapolis. - Arkivarier vid de lokala arkivfunktionerna.

Bilaga 8 Användningsfall 6 (24) PVS-937-6118/12 1.0 - Arkivarier vid arkivadministrationen. - Anslutande verksamhetssystem. 1.2.5 Producent Producenten är den aktör som levererar SIP till e-arkivet. En producent kommer i de flesta fall att utgöras av ett levererande verksamhetssystem med förvaltning. 1.2.6 E-arkivet E-arkivet är den aktör som tar emot och validerar SIP vid Mottag. E-arkivet exekverar även satta regler eller utför andra aktörers kommandon. 1.2.7 Leveransapplikation Fristående applikation som kommer att validera SIP, normalisera metadata samt konvertera filer inför leverans till e-arkivet. Varje aktör kommer att interagera med e-arkivet på följande sätt. Figur 2 Sammanställning över aktörer och hur de interagerar med e -arkivet i form av användningsfall.

Bilaga 8 Användningsfall 7 (24) PVS-937-6118/12 1.0 1.3 Avgränsning Översikten utgår endast från normalflöden, även om alternativa flöden och felhantering finns har dessa inte beskrivits. 1.4 Process: Leverera SIP Processen startar med ett beslut att påbörja leverans och slutar när leveransen är godkänd och lagrad i e-arkivet. Processen utförs av producenten. Inför en leverans förhandlar producenten och arkivadministrationen fram en leveransöverenskommelse vilken reglerar: - Vad som ska levereras - Omfattning på leveransen - Hur SIP ska utformas (sökbegrepp, struktur, format m.m.) - Vilken typ av leverans som ska göras med avseende löpande eller engångsleverans Det är producenten som ansvarar för skapa SIP, vilken ska följa givna inleveransspecifikationer för att kunna tas emot av e-arkivet. För att underlätta för producenten att kontrollera SIP inför leverans tillhandahåller e-arkivet en leveransapplikation. Applikationen hjälper till att konvertera handlingar, validera SIP samt normalisera metadata. Genom att producenten kan konvertera och validera SIP i ett tidigt skede i leveransapplikationen undviks att felaktiga leveranser stoppar upp flödet till e-arkivet. Leveranser till arkivet kan ske på olika sätt, synkront eller asynkront. Synkron överföring innebär att information levereras kontinuerligt via en integration mellan leverande verksamhetssystem och e-arkivet t.ex. så snart ett ärende avslutats. En synkron överföring innebär att producenten erhåller kvitto på leveransen synkront. Asynkron leverans kan göras i form av stora batchkörningar vid bestämda tidpunkter t.ex. årliga uttag från personal- och ekonomisystem. En asynkron leverans sker till en filarea där SIP antingen hämtas med automatik eller manuellt av e-arkivet. Vid en leverans kan kvitto skickas på olika sätt via mail eller att kvitto läggs på filarean. Ansvaret att driva igenom varje leverans kommer att ligga på arkivadministrationen.

Bilaga 8 Användningsfall 8 (24) PVS-937-6118/12 1.0 AF01. Testa SIP Detta användningsfall beskriver hur en producent använder leveranspapplikationen för att validera SIP, konvertera handlingar till godkända arkivformat samt eventuellt normalisera metadata. Användningsfallet startar när producenten skapat SIP och levererat den till leveransapplikationen och valt vilken inleveransspecifikation som SIP ska valideras mot. Exempelförlopp - Aktör väljer att validera SIP. - Aktör väljer valideringsregel/-regler och startar. - SIP valideras och valideringsrapport (kvitto) med resultat presenteras. - Aktör väljer att konvertera handlingar. - Leveransapplikationen visar konverteringsalternativ. - Aktör väljer vilken konvertering som ska genomföras. - Handlingar konverteras och konverteringsrapport (kvitto) med resultat presenteras. - Aktör väljer att normalisera metadata ex. utformning av datum. - Metadata normaliseras och rapport (kvitto) med resultat presenteras. - Leveransapplikationen påför metadata om vilka valideringsregler som SIP passerat. Användningsfallet avslutas när leveransapplikationen avger kvitto på hur aktiviteterna gått. 1.5 Process: Ta emot SIP Processen startar med att producenten och arkivadministrationen påbörjar förhandlingar om leverans och slutar då leveransen är mottagen. Inför en leverans förhandlar arkivadministrationen och producenten fram villkor för leveransen, ex vilken data som ska levereras, volymer, kostnader för leveranser, tidpunkt för leverans, regler för hantering av AO, inleveransspecifikation gällande för leveransen. Förhandlingen slås fast i en leveransöverenskommelse.

Bilaga 8 Användningsfall 9 (24) PVS-937-6118/12 1.0 SIP levereras till en nod (FE) i arkivredovisningen. En FE kan innehålla andra FE eller arkivobjekt. Till en FE kan endast en typ av SIP levereras vilka valideras utifrån en inleveransspecifikation. Efter validering lagras SIP som AIP. När förhandlingar är genomförda förbereds e-arkivet för att kunna ta emot SIP. Först skapas nod (FE) till vilken SIP ska levereras. Till FE knyts vilka regler om hantering som ska gälla ex. validering, konvertering, gallring, vilka metadata som ska vara sökbara samt vilken inleveransspecifikation som ska gälla för FE. Att driva förhandlingar med producenten samt förbereda e-arkivet för leverans ansvarar arkivadministrationen för. AF02. Administrera leverans Användningsfallet beskriver hur en aktör administrerar ny leverans dvs. skapar och förbereder FE, som SIP ska levereras till, samt knyter regler för hantering till FE. Att förbereda leveranser kan göras samlat i ett gränssnitt. En förutsättning för att användningsfallet kan starta är att e-arkivet vet vilken inleveransspecifikation den ska validera emot. Användningsfallet startar när en aktör väljer att förbereda leverans dvs. skapa och sätta regler för FE. Exempelförlopp - Aktör väljer att skapa ny FE som SIP ska levereras till. - E-arkivet visar gällande inleveransspecifikationer som SIP kan valideras mot. - Aktör väljer inleveransspecifikation. - Aktör väljer valideringar som ska knytas till FE. - Aktör väljer vilken metadata, utifrån inleveransspecifikationen, som ska vara sökbar eller icke sökbar för FE. - Aktör väljer konverteringsregel och knyter till FE. - Aktör väljer gallringsregel och knyter till FE. - Aktör väljer att spara uppgifter. - E-arkivet validerar inmatade uppgifter.

Bilaga 8 Användningsfall 10 (24) PVS-937-6118/12 1.0 - E-arkivet loggar händelsen. - E-arkivet sparar uppgifterna. Användningsfallet avslutas när samtliga regler är kopplade till FE. AF03. Ta emot SIP Detta användningsfall beskriver hur e-arkivet validerar och arkivlägger SIP. I mottag skapas AIP då teknisk metadata påförs SIP. Mottag lagrar AIP under rätt FE. För att kunna hålla samman AIP:er som har relationer ex. samma diarienummer skapas i mottag AIC (relationer/referenser). En förutsättning för att användningsfallet kan starta är att leveranser har förberetts enligt AF02. Användningsfallet startar när en producent levererar SIP. Exempelförlopp - E-arkivet tar emot inkommen SIP från producenten. - E-arkivet validerar SIP mot inleveransspecifikation knuten till den FE som SIP ska levereras till. - E-arkivet validerar SIP enligt satta valideringsregler knutna till utpekad FE. - E-arkivet påför SIP teknisk metadata. - E-arkivet skapar AIP/AIP:er från SIP. - E-arkivet skapar/relaterar AIC till AIP. - E-arkivet lagrar AIP/AIP:er under utpekad FE. - E-arkivet lagrar uppgifter om hur leveransen tagits emot (ex. antal AO, leveransdatum, valideringsresultat). - E-arkivet returnerar kvitto till producenten på att SIP har godkänts och AIP lagrats i e-arkivet. - E-arkivet loggar händelsen. - Om SIP inte godkänns skickas hela leveransen tillbaka till producenten med felmeddelande. Användningsfallet avslutas när e-arkivet lagrat AIP och kvitto skickats till producenten.

Bilaga 8 Användningsfall 11 (24) PVS-937-6118/12 1.0 1.6 Process: Vårda och framtidssäkra Arkivadministrationen vårdar och framtidssäkrar de arkiverade AIP:erna. Processen är ständigt pågående och startar så snart den första leveransen genomförts till e-arkivet. Arkivadministrationen ansvarar för att: - Valideringar genomförs ex. att dataintegriteten kan garanteras genom att kontrollera checksummor. - Konvertera handlingar till nya format. - Genomföra gallring i arkivet. Det är arkivadministrationen som bevakar vilka validerings-, konverteringsoch gallringsregler som kan exekveras. Samtliga regler kan sättas som engångsinsats men också schemaläggas och genomförs med olika intervaller. Som en vårdande insats kan metadata påföras/uppdateras på AIP ex. ändrade regler vad gäller sekretess. I processen ingår också att bevaka vilka nya filformat som standardiseras till arkivformat och andra inom området relevanta nya standarder. AF04 Administrera valideringsregler Användningsfallet beskriver hur en aktör kopplar valideringsregler till FE. E-arkivet är förberett med standardvalideringar. När SIP tas emot kontrolleras vilka valideringsregler som är kopplade till mottagande FE. Valideringsreglerna kan också exekveras på redan lagrade AIP:er. Validering kan göras som en engångsinsats men också schemaläggas och genomföras med olika intervall. Samma valideringsregel kan kopplas till flera FE. Användningsfallet startar när en aktör väljer att koppla en valideringsregel till FE. Exempelförlopp - Aktör väljer FE. - Aktör väljer valideringsregel. - Aktör sätter villkor, i detta fall tidsintervall, för valideringsregeln. - Aktör knyter valideringsregeln till vald FE.

Bilaga 8 Användningsfall 12 (24) PVS-937-6118/12 1.0 - Aktör väljer om valideringsregeln ska vara en engångsinsats eller om den ska schemaläggas och med vilket intervall. - E-arkivet validerar uppgifterna. - E-arkivet loggar händelsen. - E-arkivet sparar uppgifterna. Användningsfallet avslutas då e-arkivet har uppdaterat FE med valideringsregeln. AF05 Administrera gallringsregler Till e-arkivet kommer gallringsbar information att kunna levereras. Användningsfallet beskriver hur en aktör knyter gallringsregler till FE. Regler för gallring kan också medfölja från producenten. Gallringsregler kan sättas på hela eller delar av arkivobjekten. Gallring kan genomföras som en engångsinsats, eller schemaläggas med olika intervaller. Användningsfallet startar när en aktör väljer att administrera en ny gallringsregel. Exempelförlopp - Aktör väljer FE som regeln ska knytas till. - Aktör väljer att registrera en ny gallringsregel eller att ändra befintlig gallringsregel. - Aktör definierar hur gallringsfristen ska beräknas (villkor samt tidsfrist). - Aktör väljer om gallringsregeln ska vara en engångsinsats eller om den ska schemaläggas och med vilken intervall. - E-arkivet validerar uppgifterna. - E-arkivet loggar händelsen. - E-arkivet sparar uppgifterna och knyter gallringsregeln till FE. Användningsfallet avslutas då e-arkivet har uppdaterat FE med gallringsregeln.

Bilaga 8 Användningsfall 13 (24) PVS-937-6118/12 1.0 AF06 Administrera konverteringsregler I e-arkivet kan AIP konverteras till nya format. Initialt är e-arkivet förberett med ett antal möjliga standardkonverteringar ex, word Pdf/A. Användningsfallet beskriver hur en aktör knyter en ny konverteringsregel till en FE. Regeln kan knytas till en eller flera FE. I e-arkivet kan man välja om ursprungsfilen ska bevaras eller gallras då konvertering genomförts och kontrollerats. Konverteringsregeln kan antingen exekveras som en engångsinsats, eller att den schemaläggs och är återkommande. Användningsfallet startar när en aktör väljer att koppla en konverteringsregel till en eller flera FE. Exempelförlopp - Aktör väljer till vilken/vilka FE som regeln ska knytas. - Aktör väljer vilken konvertering som ska genomföras. - Aktör väljer om ursprungsfilerna ska gallras efter konverteringen. - Aktör knyter konverteringsregeln till en eller flera FE. - Aktör väljer om konverteringen ska vara en engångsinsats eller om den ska schemaläggas och med vilket intervall. - E-arkivet validerar uppgifterna. - E-arkivet loggar händelsen. - E-arkivet sparar uppgifterna och knyter konverteringsregeln till FE. Användningsfallet avslutas då e-arkivet har uppdaterat FE med konverteringsregeln. AF07 Validera AIP Användningsfallet beskriver hur valideringsregler exekveras. Inför en validering sammanställer e-arkivet en lista. Det går att sätta upp en regel att listan ska godkännas innan validering genomförs. Användningsfallet startar då en valideringsregel exekveras, antingen manuellt eller genom ett schemalagt jobb. Exempelförlopp - E-arkivet startar valideringsfunktionen. - Valideringsfunktionen genomsöker e-arkivet.

Bilaga 8 Användningsfall 14 (24) PVS-937-6118/12 1.0 - Valideringsfunktionen sorterar ut de AIP: er som ska valideras enligt regeln och skapar en lista över aktuella AIP. - Aktör väljer att godkänna listan. - Valideringsfunktionen fortsätter att exekveras. - Resultatet dokumenteras i en valideringsrapport som bevaras i e- arkivet. - Valideringen loggas. Användningsfallet avslutas när valideringen är loggad och sammanställd i valideringsrapport. AF08 Gallra AIP Användningsfallet beskriver hur e-arkivet utför gallring av AIP. Inför en gallring sammanställer e-arkivet en lista. Det går att sätta upp villkor att listan ska godkännas innan gallring exekveras. Gallring ska kunna göras på hela eller delar av AIP. Användningsfallet startar när villkor och/eller tidsfrist infaller. Exempelförlopp - E-arkivet startar gallringsfunktionen. - Gallringsfunktionen genomsöker e-arkivet. - Gallringsfunktionen sorterar ut de AIP som ska gallras enligt gallringsreglerna och skapar lista över aktuella AIP. - Aktör godkänner listan och gallringsfunktionen fortsätter att exekvera gallring. - Resultatet dokumenteras i en gallringssrapport som bevaras i e- arkivet. - Gallringen loggas. Användningsfallet avslutas när AIP är gallrade och gallring är loggad samt sammanställd i gallringssrapport.

Bilaga 8 Användningsfall 15 (24) PVS-937-6118/12 1.0 AF09 Konvertera AIP Detta användningsfall beskriver hur e-arkivet genomför konvertering. Inför att en konvertering exekveras sammanställer e-arkivet en lista. Det går att sätta upp villkor för att listan ska godkännas innan konvertering exekveras. Användningsfallet startar då en konverteringsregel exekveras, antingen manuellt eller genom ett schemalagt jobb. Exempelförlopp - E-arkivet startar konverteringsfunktionen. - Konverteringsfunktionen genomsöker e-arkivet. - Konverteringsfunktionen sorterar ut de AIP som ska konverteras enligt regeln och skapar lista över aktuella objekt. - E-arkivet visar lista över de utsorterade AIP. - Aktör godkänner listan och konverteringsregeln fortsätter att exekvera regeln. - E-arkivet kontrollerar konverteringen. - E-arkivet gallrar ursprungsfilerna. - E-arkivet sammanställer resultatet av konverteringen i en konverteringsrapport vilken sparas i e-arkivet. - E-arkivet loggar konverteringen och gallring. I de fall ursprungsformatet ska bevaras skapar/uppdaterar e-arkivet en AIC som håller relationen mellan de båda arkivobjekten. Användningsfallet avslutas då AIP är konverterade och konverteringen är loggad. AF10a Förändra AIP Användningsfallet beskriver hur en aktör förändrar AIP. Utifrån personuppgiftslagens bestämmelser måste personuppgifter som är felaktigt registrerade kunna tas bort, även då handlingarna har levererats till e-arkivet. I e-arkivet kan förändringar av AIP utföras genom att ett metadata uppdateras eller att en handling tillförs, ex. med rättade personuppgifter. Efter uppdatering går det att välja (lösning enligt OAIS);

Bilaga 8 Användningsfall 16 (24) PVS-937-6118/12 1.0 - att endast förändringen sparas, dvs. genom en AIU, med en AIC till den ursprungliga AIP, för att undvika onödig dubbellagring eller - spara en ny version av AIP med en referens mellan de båda versionerna, dvs. genom en AIC Då AIP förändras måste orsak till förändringen kunna skrivas in samt att följande loggas: - Vad som uppdaterats alt vad som tillförts. - Tidpunkt. - Vem som gjort förändringen Användningsfallet startar när en aktör sökt fram aktuell AIP för att rätta felaktiga uppgifter i en handling. Exempelförlopp - E-arkivet hämtar AIP. - Aktör väljer vilken handling som ska uppdateras. - Aktör registrerar in ny uppdaterad handling. - Aktör väljer att endast uppdaterade handlingen sparas, inte skapa ny AIP. - E-arkivet skapar AIU av uppdateringen. - E-arkivet skapar AIC mellan AIP och AIU. - Aktör väljer att ursprunglig handling gallras. - E-arkivet gallrar ursprunglig handling. - E-arkivet loggar uppdatering och gallring. - E-arkivet sparar AIU samt AIC. Användningsfallet avslutas när e-arkivet har sparat AIU samt AIC. AF10b Skriva notering till AIP Till AIP kan det göras noteringar, dvs löpande anteckningar. Exempel på noteringar kan vara referens till annat ärende. Noteringarna har en referens

Bilaga 8 Användningsfall 17 (24) PVS-937-6118/12 1.0 till AIP så att notering och AIP kan presenteras samlat om önskemålet finns. Användningsfallet beskriver hur en aktör gör en notering om AIP. Användningsfallet startar när aktör valt aktuell AIP Exempelförlopp - E-arkivet hämtar AIP. - Aktör öppnar noteringsfilen. - Aktör skriver in notering. - Aktör sparar och stänger noteringsfältet - E-arkivet sparar noteringen - E-arkivet loggar uppdateringen Användningsfallet avslutas när e-arkivet loggat och sparat noteringen. AF11 Hämta statistik och rapporter I e-arkivet sker en omfattande loggning av händelser. Loggningen kommer att utgöra grunden till den statistik som kan tas fram. Detta användningsfall beskriver hur aktören sammanställer rapporter. Initialt är e-arkivet förberett med standardrapporter, exempel på rapporter är antal lagrade arkivobjekt för en myndighet, antal sökningar, aktuell lagringsstorlek (totalt för arkivet eller per myndighet) etc. Det går också att ta fram nya rapportmallar. Användningsfallet startar när aktören väljer att sammanställa en rapport. Exempelförlopp - Aktör väljer att ta ut rapport. - E-arkivet visar en lista över tillgängliga rapporter. - Aktör väljer rapporttyp. - E-arkivet visar eventuella inmatningsfält som begränsar urvalet. - Aktör fyller i inmatningsfälten och startar sökningen. - E-arkivet sammanställer rapporten. - E-arkivet loggar händelsen.

Bilaga 8 Användningsfall 18 (24) PVS-937-6118/12 1.0 - Sammanställd rapport sparas till fil och/eller skrivas ut. Användningsfallet avslutas när rapporten presenterats på skärmen eller har sparats till fil. 1.7 Process: Förvalta och drifta Att drifta och förvalta e-arkivet ansvarar PVIT för. Gränsdragningen mellan PVIT och Arkivadministrationen är i dagsläget inte klarlagt. Processen är inte framtagen. AF12 Administrera behörigheter Detta användningsfall beskriver hur en aktör administrerar behörigheter till e-arkivet. Behörigheterna sätts i form av roller. En roll kan ges olika begränsningar ex. tillgång att se olika delar i arkivet eller kunna genomföra aktiviteter i e-arkivet (sätta gallringsregler, upprätta kontrakt osv). E-arkivets behörighetssystem stämmer överens med Polisens AD som bl.a. administreras i systemet ITAC. Samtliga behörigheter knyts till noder i arkivredovisningen. Nya roller med tillhörande befogenheter kan läggas till. I e-arkivet går det att ge tillfälliga behörigheter till utpekade noder eller AIP. Användningsfallet startar då en aktör väljer att lägga till en ny behörighet eller uppdatera en befintlig. Exempelförlopp - Aktör väljer att administrera behörigheter. - E-arkivet visar aktuella roller. - Aktör väljer att ändra en befintlig roll eller lägga till en ny roll. - Aktör väljer att ändra eller lägga till behörighet till olika delar av arkivet till rollen. - Aktör väljer att ändra eller lägga till behörighet till olika aktiviteter till rollen. - Aktör väljer att koppla aktörer till rollen. - Aktör väljer att spara behörigheten. - E-arkivet loggar händelsen. - E-arkivet uppdaterar behörighetsregistret. Användningsfallet avslutas när e-arkivet har uppdaterat behörighetsregistret.

Bilaga 8 Användningsfall 19 (24) PVS-937-6118/12 1.0 1.8 Process: Redovisa arkiv Denna process delas mellan arkivadministrationen och de lokala arkivfunktionerna. Arkivadministrationen ansvarar för att sätta regler för arkivredovisningen och de lokala myndigheterna upprättar sina respektive arkivredovisningar. E-arkivet kan hantera hela Polisens arkivredovisning dvs. klassificeringsstruktur (KS) och arkivförteckning i enlighet med Riksarkivets föreskrifter. I e-arkivet kan digitala och analoga arkivobjekt redovisas. Processens första steg är att arkivadministrationen definierar vilka typer av strukturenheter, handlingsslag, handlingstyper samt förvaringsenheter som kan väljas. Därefter ansvarar varje lokal arkivfunktion för att sätta samman klassificeringsstruktur samt arkivförteckning. Redovisningen delas upp mellan den del som klassificerar handlingarna, klassificeringsstruktur, och den del som redovisar handlingarna, arkivförteckning. Klassificeringsstrukturen är en logisk redovisning av verksamheten och som byggs upp av strukturenheterna verksamhetsområden, processgrupper och processer. En process har en eller fler aktiviteter. Varje process avsätter handlingar vilka utgör ett handlingsslag. Ett handlingsslag kan innehålla en eller flera handlingstyper. Arkivförteckningen redovisar handlingarna. Denna redovisning består av noderna handlingsslag, handlingstyper samt förvaringsenheter i flera nivåer. Förvaringsenhet kommer att vara utgångspunkt för var AIP kommer att lagras. Redovisning av FE kan göras utan att den övriga arkivredovisningen är upprättad. Nedanstående bild förklarar förhållandet mellan arkivredovisning, klassificeringsstruktur samt arkivförteckning. Figur 4 Förenklad bild av arkivredovisningens delar

Bilaga 8 Användningsfall 20 (24) PVS-937-6118/12 1.0 AF13 Administrera noder för arkivredovisning Detta användningsfall beskriver hur en aktör skapar eller uppdaterar arkivredovisningens nodtyper, d.v.s. upprättar nodtyper och definierar metadata samt regler för nodtypen. Användningsfallet startar när en aktör väljer att upprätta en ny nodtyp. Exempelförlopp - Aktör väljer att skapa ny nodtyp. - Aktör kan antingen välja att skapa en ny nodtyp eller uppdatera en redan befintlig. - Aktör väljer att skapa en ny nodtyp. - Aktören definierar beteckning för noden, vilka regler som ska gälla och vilken metadata som ska vara obligatorisk samt valbar för noden. - E-arkivet validerar uppgifterna. - E-arkivet loggar händelsen. - E-arkivet sparar uppgifterna. Användningsfallet avslutas när e-arkivet har sparat uppgifterna och listan över valbara nodtyper är uppdaterad. AF14a Upprätta arkivredovisning Detta användningsfall beskriver hur en aktör sätter samman en klassificeringsstruktur eller arkivförteckning utifrån fördefinierade nodtyper enligt AF 13. Användningsfallet startar när en aktör väljer att upprätta en nod i arkivredovisningen. Exempelförlopp - Aktör väljer nodtyp och utifrån den skapar en nod. - Aktör registrerar obligatorisk metadata på noden, specificerad i nodtypen. - Aktör väljer att spara uppgifterna. - E-arkivet loggar händelsen.

Bilaga 8 Användningsfall 21 (24) PVS-937-6118/12 1.0 - E-arkivet validerar och sparar uppgifterna. Användningsfallet avslutas när e-arkivet har sparat uppgifterna och uppdaterat myndighetens arkivredovisning. AF14 b Redovisa arkivobjekt Detta användningsfall beskriver hur en aktör uppdaterar arkivförteckningen med analoga arkivobjekt. Användningsfallet startar när en aktör väljer att uppdatera arkivförteckningen. Exempelförlopp - E-arkivet visar myndighetens arkivförteckningar. - Aktör väljer den arkivförteckning som ska uppdateras. - Aktör väljer under vilken FE som AO ska registreras. - Aktör väljer att registrera in nya AO. - Aktör registrerar in antal AO samt hur de ska numreras. - Aktör registrerar obligatorisk metadata för AO. - Aktör väljer att spara uppgifterna. - E-arkivet loggar händelsen. - E-arkivet validerar och sparar uppgifterna. Användningsfallet avslutas när e-arkivet har sparat uppgifterna och myndighetens arkivförteckning är uppdaterad. 1.9 Process: Söka AIP Denna process utförs av konsumenten. Processen startar med att en fråga ställs till e-arkivet och slutar med att en träfflista presenteras. Sökning i arkivet kan göras via följande kanaler: - Ett verksamhetssystem Ett verksamhetssystem kan ansluta, enligt överenskommelse, till e- arkivet för sökning under utpekad FE. - Intrapolis (Polisens intranät)

Bilaga 8 Användningsfall 22 (24) PVS-937-6118/12 1.0 Öppen information kan sökas i och hämtas från e-arkivet via Intrapolis. I anslutning till sökfunktionen finns möjlighet att beställa ej öppen information ex. sekretessbelagt eller åtkomstskyddad. Rutiner för hur beställningar ska göras är i dagsläget inte fastslaget. - E -arkivets egna sökgränssnitt Via detta gränssnitt kommer arkivfunktionen att kunna söka AIP. När en sökning genomförs måste konsumenten först välja övergripande kategori av FE. Därefter kan aktören antingen välja att gå nedåt i strukturen med FE eller söka direkt på AIP ex. genom diarienummer. Figur 5 Struktur för FE AF15 Söka AIP Användningsfallet beskriver hur en aktör söker ett eller flera AIP/-er genom att först navigera till rätt FE. Förutsättning för att kunna söka under en FE styrs av behörigheter. I de fall en aktör inte har behörighet till en FE kommer inte denna FE vara valbar för aktören. Användningsfallet startar när en aktör valt vilket arkiv som AIP ska sökas från. Exempelförlopp - E-arkivet visar lista på de övergripande kategorierna av FE (t.ex. brottsutredningar, ekonomi). - Aktör navigerar i listan och väljer FE, Brottsutredningar.