BILAG 3.1 KRAVSPECIFIKATION

Transkript

1 B i l a g 3. 1 K r a v s p e c i f i k a t i o n BILAG 3.1 KRAVSPECIFIKATION 6. d e c e m b e r

2 Indholdsfortegnelse 1. Baggrund for DUBU-projektet Vision og målsætning for Systemet Kommunale fordele ved Systemet Læsevejledning Vejledning til læsning af Kravspecifikationen Vejledning til opsplitning i Faser Vejledning med hensyn til besvarelse af Krav Vejledning til kravskemaer Vejledning til Løsningsbeskrivelsen Leverandørens besvarelse af Kravspecifikationen Tidsplan og færdiggørelse af Projektets Faser Overblik over Systemet DUBU aktører DUBU begreber DUBU-blanketter DUBU-blanketter for delprocesser DUBU-blanketter - øvrige DUBU-outputblanketter KL-blanketter DUBU Processer/delprocesser Delproces vedrørende underretning eller henvendelse Delproces vedrørende 50-undersøgelse Delproces vedrørende visitation Delproces vedrørende indsats og opfølgning Supplerende delprocesser DUBU Use Cases DUBU Services Det komponentopdelte System Sagsstyringskomponenten Prioritering og håndtering af flere sager Administration af Sagsstyringskomponenten Workflow understøttelse Procesmodulet Frister og adviser Spørgsmålsadministration Familieadministrationskomponent Persontyper Genogram Integration til en CPR-datakilde F o r t r o l i g t S i d e 2 / d e c e m b e r

3 5.3. ICS-komponenten ICS-systematikken Processtøtte ICS-komponenten Håndtering af sager og dokumenter Det Interne Arkiv Sags- og dokumentarkiv Sags- og dokumentarkivets snitflader stilles til rådighed Journalarkskomponenten Journalarksnotetyper Økonomikomponenten Økonomiske fremskrivninger Det faktiske forbrug Betalinger og opkrævninger Integration til kommunale økonomisystemer Integration til et fjerde økonomisystem Økonomi-integrationens snitflader stilles til rådighed Blanketsystem Eksternt blanketsystem Tilbudssystemet Tilbudsportalen Organisationskomponent Dokumentboks Rapportering Ledelsesinformation Ledelsesinformation filudtræk Ledelsesinformationsrapporter Udtræk til Danmarks Statistik Udtræk til Ankestyrelsen Udtræk til Statens Arkiver Brugergrænseflader og kontorapplikationer Søgning Lokalt Office miljø Sikkerhed og brugerstyring Administration og styring af brugere Administration af brugerroller og funktioner Autorisation af brugeren Sikring af data Brugerstyringsløsning Reference arkitektur IT- og Telestyrelsens anbefalinger Fællesoffentlig digitaliseringsstrategi Referencearkitektur for Systemet Principper for DUBU services Tekniske krav F o r t r o l i g t S i d e 3 / d e c e m b e r

4 Workflow og serviceintegrationslag Servicelag Datalag Drift, infrastruktur, lovvedligehold og overdragelse Infrastruktur Platforme Kommunikationsinfrastruktur Skalerbarhed og performance Miljøer Mulig besparelse på drift af Systemet Sikring af lovvedligehold Overdragelse til anden leverandør Implementering Lovmæssige og politiske krav B 103 Åbne standarder for software i det offentlige DS ISO Serviceloven Forvaltningsloven Retssikkerhedsloven Persondataloven Arkivloven Regnskabsbekendtgørelsen F o r t r o l i g t S i d e 4 / d e c e m b e r

5 1. Baggrund for DUBU-projektet Systemet Digitalisering udsatte børn og unge (DUBU) er tænkt som et fælleskommunalt værktøj (et fagsystem) til at sikre kvalitet og sammenhæng i arbejdet med udsatte børn og unge. Socialministeriet, KL og de seks kommuner: Frederiksberg, Holbæk, Middelfart, Næstved, Roskilde og Silkeborg, gik i 2005 sammen om at udarbejde en kravspecifikation og procesdiagrammer på området Udsatte børn og unge. Efterfølgende har en række yderligere kommuner vist interesse for projektet. I kommunernes økonomiaftale for 2010 fremgår det, at Som led i udviklingen af redskaber, der kan understøtte kommunernes indsats, kvalitetssikring og prioritering af det specialiserede socialområde, er regeringen og KL enige om behovet for en styrket it-understøttelse. Regeringen - og derunder Socialministeriet - og KL er enige om, at prioritere en realisering af Systemet ( Digitalisering - udsatte børn og unge ) højt. Hermed skabes et godt fundament for opgaveløsningen på området for udsatte børn og unge, der kan medvirke til at styrke kvaliteten i opgaveløsningen samt lette det administrative arbejde forbundet med procesregler i lovgivningen. På denne baggrund er KL og Socialministeriet enige om, at der i regi af KOMBIT A/S ( KOMBIT ) iværksættes og afvikles et udbud af et DUBU-fagsystem (herefter Systemet). I december 2009 indgik Socialministeriet, KL og KOMBIT en samarbejdsaftale, hvori det blev aftalt, at KOMBIT skal gennemføre et EU-udbud samt være kontraktholder i forhold til den kommende leverandør og de kommuner, der tilmeldte sig Systemet. I den forbindelse fik KOMBIT endvidere ansvar for, at opdatere Kravspecifikationen i henhold til de ændringer, som var sket i de 1½ år, den har ligget stille. Det blev desuden besluttet at Faseopdele Kravspecifikationen for at undgå de faldgruber, som kan være en risiko ved Big Bang løsninger. Indførelsen af Systemet skal indgå i sammenhæng med arbejdet med udviklingen af nye arbejdsprocesser og løsninger. Som fælles referenceramme og socialfaglig metode for Systemet, er valgt Integrated Children's System (ICS) til understøttelse og dokumentation af sagsbehandlingen på børne- og ungeområdet. Efter et forløb med kompetenceudvikling har et antal kommuner taget ICS i brug pr. januar Ved udgangen af 2009 var der 13 kommuner, der anvendte ICS i en papirbaseret version. I sammenhæng med DUBU-projektet er der gennemført et OIO standardiseringsprojekt. OIO standardiseringsprojektet har to formål. Det ene er, at skabe fællesoffentlige standarder på udsatte børn- og ungeområdet, og det andet er, at varetage DUBU-projektets behov for standarder. Standarderne kan bruges uafhængigt af Systemet. F o r t r o l i g t S i d e 5 / d e c e m b e r

6 Baggrunden for standardiseringen er følgende: Den information, der oftest går igen i sagsbehandlingen og itunderstøttelsen af den, er de indsatser, som de udsatte børn og unge modtager. Det er også den oplysning, der går igen i flest systemer herunder fagsystemer, økonomisystemer, Ledelsesinformationssystemer, centrale indberetninger, tilbudsportal etc. Det har været et selvstændigt formål at lette udvekslingen af denne type informationer vedr. barnets indsats. Derudover skulle den nye begrebsmodel gerne give en mere nuanceret og præcis registrering af, hvilke indsatser der gøres på området, så man kan danne sig et bedre billede af sagerne på tværs, og være mere præcis i sin visitation i den enkelte sag. Den væsentligste strukturelle forskel fra lovgivningens kategorier er, at begrebsmodellen følger Tilbudsportalens opdeling i "ydelser" og "tilbud" (=leverandør). Begge dele indgår i "indsatsen". Et tilsvarende og parallelt arbejde gennemføres på andre sociale områder, konkret området handicap og udsatte voksne området. Indsatser med underliggende begreber og attributter er godkendt på NDR niveau. Herudover er der også - med baggrund i Systemet - specificeret begreber vedrørende sagsprocessen. Disse begreber forventes ophøjet til OIO- NDR standard. Det fremgår af afsnit 4.2, Krav 6, hvorledes begreberne skal indarbejdes i Systemet, og af underbilag 3.1B, hvilke begreber der er tale om Vision og målsætning for Systemet Det overordnede mål med Systemet er, at skabe bedre styring og sagsbehandling på området Udsatte børn og unge. Systemet skal både understøtte den enkelte sagsbehandlers arbejdsproces og tilvejebringelsen af Ledelsesinformation i form af overblik og statistik på tværs af de enkelte sager. De overordnede mål for Systemet er præciseret i følgende seks målsætninger: En mere systematisk sagsbehandling der kan sikre, at borgere oplever færre fejl i forbindelse med sagsbehandlingen. Der etableres med systemet et redskab til kommunerne der sikrer, at forvaltningsloven, serviceloven og andre love overholdes. ICS er den socialfaglige metode der er valgt til at understøtte større systematik og ensartethed i sagsbehandlingen. Muligheden for at inddrage økonomiske og socialfaglige overvejelser på et sagligt grundlag ved at sikre et øget overblik over de relevante muligheder for indsats, der findes for barnet eller den unge i en given situation. Dette skal kunne ses i sammenhæng med de økonomiske konsekvenser af de valg, der er træffes. F o r t r o l i g t S i d e 6 / d e c e m b e r

7 En god afdækning af barnets eller den unges behov, så det bliver nemmere at finde frem til de tilbud, der bedst imødekomme et givent behov. Resultatet af dette skal konkret være færre revisiteringer end i dag, hvor tilbuddet ikke i første omgang har matchet barnets behov. En afledt effekt af bedre matchning af tilbud op imod behov skal være at sikre en registrering og dokumentation af tilfredshed og målopnåelse knyttet til den konkrete nødvendige indsats overfor barnet eller den unge. Lettelse af den administrative byrde for sagsbehandlerne ved at reducere den tid, sagsbehandlerne i dag bruger på rene administrative funktioner. Det giver mere tid til de dele af sagsbehandlingen, som ikke kan overlades til maskiner f.eks. undersøgelser, handleplaner, dialog og opfølgning. Et nemmere tværgående samarbejde mellem offentlige myndigheder ved at højne kvaliteten og lette informationsudvekslingen mellem de offentlige myndigheder, fx overdragelse af sagsinformation fra kommune til kommune. Tilvejebringelsen af en højere kvalitet i de informationer, der danner basis for ledelsesbeslutninger, og dermed sikre et bedre grundlag for prioriteringer, kvalitetsudvikling og tilrettelæggelse af indsatsen. Lederne får bedre redskaber til at sparre med sagsbehandlerne på et sagligt grundlag, og modvirker dermed budgetoverskridelser Kommunale fordele ved Systemet Med udgangspunkt i målsætningerne, beskrevet i afsnit 1.1, er der formidlet en række fordele til kommunerne ved brug af Systemet. Kvalitet i indhold og proces Systemet vil understøtte en høj kvalitet i sagsbehandlingen. Anbringelsesreformens fokusområder (udvikling og adfærd, familieforhold, skoleforhold, sundhedsforhold, fritidsforhold og venskaber samt andre relevante forhold) vil være indarbejdet i Systemet således, at barnets behov bliver et naturligt omdrejningspunkt for indsatsen. Undersøgelser, handleplaner og opfølgning er baseret på den internationalt anerkendte sagsbehandlingsmetode Integrated Children s System (ICS), der også anvendes i England, Canada, Australien og Sverige. I Sverige har knapt 200 kommuner påbegyndt en implementering af metoden. Den danske model er naturligvis tilpasset vores hjemlige forhold i samarbejde med de deltagende kommuner. I Danmark har 13 kommuner ved udgangen af 2009 indgået licensaftale med Socialministeriet om anvendelsen af ICS og implementeret ICS i sagsbehandlingen. Den enkelte sagsbehandler vil i Systemet blive guidet gennem et forløb, der understøtter, at formelle krav til sagsbehandlingen overholdes, og at sagsbehandleren mindes om frister og opgaver. Dette vil reducere risikoen for fejl og kommunens sagsbehandlingsstandarder sikres. F o r t r o l i g t S i d e 7 / d e c e m b e r

8 I modsætning til i dag, hvor der er risiko for, at relevante fakta kun findes i hovedet på sagsbehandleren, så vil alle oplysninger kunne findes på skrift i sagen ved brug af Systemet. Dermed bliver sagerne bedre belyst til gavn for både barnet, forældrene og sagsbehandleren. Dette er også en fordel ved ankesager, i dialogen med familien, hvis der skiftes sagsbehandler eller hvis familien flytter til en anden kommune. Mere tid til det vigtige for medarbejderne Systemet vil skulle arbejde sammen med andre it-systemer, fx økonomi, CPR, ESDH og Tilbudsportalen. Medarbejderne vil derfor ikke skulle indtaste de samme sagsinformationer flere gange eller skifte rundt mellem forskellige it-systemer. Når sagerne er bedre belyst og figurerer i sammenhæng med oversigter over relevante tilbud med priser og erfaringer, så bliver det både hurtigere og nemmere at finde frem til det tilbud, der er relevant for barnets behov. Samtidig bliver det nemmere at følge op på den enkelte sag. Når forudsætningerne for at iværksætte en indsats er klart beskrevet, og der formuleres mål og eventuelle delmål for indsatsen, giver det et bedre grundlag for at vurdere, om indsatsen fortsat er relevant. Det gælder også i forhold til, om indsatsen skal tilpasses eller helt ophøre, fordi målet er nået. Systemet vil også sikre, at data kan sendes til Ankestyrelsen og Danmarks Statistik samt kan udtrækkes til Statens Arkiver. Derved bliver kommunernes indberetningspligter lettere at håndtere. Den fælles sagsbehandlingsmetode letter også overdragelsen af sager mellem de kommuner der benytter Systemet. Det sparer tid og giver en mere sikker håndtering af opgaverne. Bedre ledelsesinformation Med Systemet vil der være direkte adgang til Ledelsesinformation som betyder, at den interne dialog i kommunen om indsatser og prioriteringer kommer til at hvile på mere solid dokumentation. I dag er det ofte vanskeligt for den enkelte kommune at skabe sig et samlet overblik, uden at skulle gennemgå alle sagerne manuelt. Det besværliggør både dialogen mellem ledelse og medarbejdere og mellem politikere og administration. Systemet vil kunne understøtte kommunens sammenhængende børnepolitik og sagsbehandlingsstandarder ved at give kommunen mulighed for at anvende lokale opsætninger i forhold til kommunale standarder i sagsbehandlingen. Systemet vil også give ledelsen mulighed for at følge op på, om disse standarder overholdes. Når kommunens egen situation skal sættes i perspektiv, er det ofte en fordel at kunne sammenligne sig med andre. Systemets ledelsesrapporter vil omfatte data, der giver mulighed for at sammenligne nøgletal på tværs af de kommuner, der benytter Systemet. F o r t r o l i g t S i d e 8 / d e c e m b e r

9 Bedre overblik og økonomisk styring Systemet vil give kommunernes ledelse et bedre overblik over udviklingen i forhold til økonomi, indsatser og resultater. Det bliver fx lettere at se, hvor der er behov for en særlig indsats eller hvordan, nye afgørelser har påvirket kommunens budget. Samtidig vil Systemet give bedre mulighed for at følge op på, om økonomien holder i forhold til det enkelte barn samt på tværs af sagerne i forhold til det aftalte/visiterede. Det vil give færre overraskelser og dermed bedre mulighed for at planlægge og sikre kontinuitet i indsatsen. Systemet vil også sikre, at den kommunale sagsbehandler og ledelse får overblik over, om de ønskede mål for barnet eller den unge, som er opstillet i en konkret handleplan (Servicelovens 140) nås, så der ikke anvendes ressourcer, der ikke har en gavnlig effekt for barnet eller den unge. Styrkelsen af den økonomiske styring vil imidlertid ikke kun ske gennem øget overblik. I forbindelse med visitationen vil Systemet give sagsbehandleren mulighed for at vurdere de økonomiske konsekvenser af alternative beslutninger, forudsat valget står mellem alternative forebyggende indsatser, som på forskellig vis vurderes, at kunne imødekomme barnets behov lige godt. På den måde bliver det nemmere at foretage en løbende prioritering af kommunens ressourcer ud fra et sagligt grundlag. Endelig vil Systemets fokus på et grundigt beslutningsgrundlag gøre det lettere at træffe den rigtige afgørelse første gang. I dag bliver der brugt ca. 14 mia. kroner på indsatser 1. Hvis kommunerne forbedrer de valg de træffer, med 1% i forhold til børnene og de unges behov, svarer det til 140 mio. kroner om året. 1 I 2008 var de samlede offentlige udgifter til udsatte børn og unge 14,4 mia. kr. F o r t r o l i g t S i d e 9 / d e c e m b e r

10 2. Læsevejledning Dette afsnit indeholder en detaljeret beskrivelse af, hvordan Kravspecifikationen skal læses i forhold til struktur og Faseopdeling samt hvordan de identificerede Krav til Systemet skal forstås og besvares. I hele dette bilag anvendes betegnelsen Leverandøren i stedet for Tilbudsgiver, uanset om der er tale om oplysninger eller krav, der skal opfyldes ved afgivelsen af tilbuddet og således af alle Tilbudsgivere Vejledning til læsning af Kravspecifikationen Dette afsnit er en vejledning til, hvordan Kravspecifikationen er struktureret, og hvordan den nemmest læses af Leverandøren. Kravspecifikationen centrerer sig omkring en komponentbaseret opbygning af Systemet, som illustreret i følgende diagram: Figur 1: DUBU komponentbaseret opbygning Alle Krav til komponenterne er samlet i samme underafsnit til afsnit 5, for dermed at give en samlet forståelse for den pågældende komponent. Det giver Leverandøren den fordel, at Kravspecifikationen kan opsplittes og fordeles på flere inputgivere ved udfærdigelse af tilbuddet. En enkelt af komponenterne påvirker dog alle de øvrige komponenter, jf. afsnit 5.13 (Sikkerhed og brugerstyring). Ud over komponenterne indeholder Kravspecifikationen afsnit vedr. Referencearkitektur jf. afsnit 6, som supplerer de øvrige Krav til Systemets arkitektur. F o r t r o l i g t S i d e 10/ d e c e m b e r

11 Kravspecifikationen indeholder følgende afsnit: Afsnit Titel Beskrivelse 3 Tidsplan og færdiggørelse af Gennemgang af krav til tidsplaner. Projektets Faser 4 Overblik over Systemet Giver via overordnede begreber, aktører, blanketter, Use Cases, processer og services et overordnet overblik over Systemet. 5 Det komponentopdelte System 5.1 Sagsstyringskomponenten Gennemgang af krav til Sagsstyringskomponenten inkl. administration af denne, workflowunderstøttelse og konfiguration, håndtering af hændelser, frister og adviser samt spørgsmålsadministration. 5.2 Familieadministrationskomponenten Gennemgang af krav til Familieadministrationskomponenten herunder persontyper, relationstyper, genogram samt hent af CPR-data fra en CPR-datakilde. 5.3 ICS komponenten Gennemgang af krav til ICS komponenten, herunder systematikken bag ICS og procesunderstøttelsen af denne. 5.4 Håndtering af sager og dokumenter Gennemgang af krav til håndtering af sager og dokumenter med baggrund i et Internt Arkiv og integration til kommunale ESDH-systemer (Sags- og dokumentarkivet). 5.5 Journalarkkomponent Gennemgang af krav til Journalarkskomponenten inklusive dannelsen - og overførslen af journalark til Sags- og dokumentarkivet. 5.6 Økonomikomponenten Gennemgang af krav til håndtering af økonomi omhandlende økonomiske fremskrivninger samt afholdte udgifter og opkrævninger der involverer integration til de kommunale økonomisystemer (Økonomiintegrationen). 5.7 Blanketsystem Gennemgang af krav til et eksternt blanketsystem. 5.8 Tilbudssystemet Gennemgang af krav til et tilbudssystem omhandlende håndtering at lokale tilbud og integration til Tilbudsportalen. 5.9 Organisationskomponent Gennemgang af krav til Organisationskomponenten Dokumentboks Gennemgang af krav til Dokumentboks og NemSMS Rapportering Gennemgang af krav til håndtering F o r t r o l i g t S i d e 11/ d e c e m b e r

12 5.12 Brugergrænseflade og kontorapplikationer af rapportering omfattende: Indberetning til Danmarks Statistik. Udtræk af Ledelsesinformationer. Generering af Ledelsesinformations-rapporter. Afsendelse til Ankestyrelsen. Udtræk til Statens Arkiver. Gennemgang af krav til brugergrænseflader inklusiv krav til søgning, integration til kontorapplikationer og integration Sikkerhed og brugerstyring Gennemgang af krav til sikkerhed og brugerstyring samt integration til en ekstern sikkerhedsløsning. Afsnittet indeholder tværgående krav til de andre komponentbaserede afsnit. 6 Reference arkitektur Gennemgang af krav til referencearkitektur og tekniske krav. Afsnittet indeholder tværgående krav til de andre komponentbaserede afsnit. 7 Drift, infrastruktur, lovvedligehold og overdragelse 7.1 Infrastruktur Gennemgang af krav til infrastruktur som platforme, kommunikationsinfrastruktur, skalerbarhed og performance samt miljøer. 7.2 Sikring af lovvedligehold Gennemgang af krav til, hvordan Systemet skal sikres, for til enhver tid at leve op til lovgivningen. 7.3 Overdragelse til anden Leverandør Gennemgang af krav til sikring af, at drifts- og vedligeholdelsesmiljøet kan overdrages til en anden Leverandør samt alternative servicemål. 8 Implementering Gennemgang af krav til implementering. 9 Lovmæssige og politiske krav Gennemgang af lovmæssige og politiske krav. Underbilag Underbilag 3.1A Kravskemaer Underbilag 3.1B Begrebsliste Underbilag 3.1C Procesdiagrammer Underbilag 3.1D DUBU-outputblanketter Underbilag 3.1E DUBU-blanketter Underbilag 3.1F Use Cases Underbilag 3.1G Oversigt over serviceoperationer Underbilag 3.1H Økonomisystem snitfladebeskrivelser Underbilag 3.1I Ledelsesinformation Underbilag 3.1J Økonomistyrelsens designparadigme for rapporter Underbilag 3.1K Danmarks Statistik og Ankestyrelsen Underbilag 3.1L Transaktionsmængder Underbilag 3.1M Kilder Underbilag 3.1N Definitioner F o r t r o l i g t S i d e 12/ d e c e m b e r

13 Underbilag 3.1O Skabelon til Løsningsbeskrivelse Der gøres opmærksom på, at der i Kravspecifikationen er indlejret et antal skærmbilleder for at illustrere dele af Systemet. Disse skærmbilleder er kun vedlagt til orientering, og er således ikke krav til, hvorledes skærmbillederne i den endelige System skal fremstå Vejledning til opsplitning i Faser Systemet er opbygget af 4 Faser; første Fase med grundfunktionalitet og 3 efterfølgende Faser, der udvider grundfunktionaliteten, primært med integrationer. Faseopdelingen fremgår af følgende oversigt: Figur 2: Projektets Faseopdeling Som det fremgår af ovenstående figur, vil grundfunktionaliteten (Fase 1) være sammensat af næsten alle kernekomponenter: Den styrende og procesafviklende Sagsstyringskomponent (se afsnit 5.1) og de understøttende komponenter Familieadministrationskomponenten (se afsnit 5.2), ICS komponenten (se afsnit 5.3), F o r t r o l i g t S i d e 13/ d e c e m b e r

14 Journalarkskomponenten (se afsnit 5.5), Organisationskomponenten (se afsnit 5.9), Interne Arkiv (se afsnit 5.4.1), herudover Blanketsystemet for hent af OIOXML opmærkede blanketter (se afsnit 5.7) og den del af Økonomikomponenten, der er fokuseret på de økonomiske fremskrivninger (se afsnit 5.6.1). Derudover vil der være integration til hent af CPR data (se afsnit 5.2.3) og brug af frister og adviser (se afsnit 5.1.5)) samt brugergrænseflader inklusive brugergrænseflader til administration af Systemet (se afsnit 5.12) og udtræk af data til Ledelsesinformation (se afsnit ) og til indberetning til Danmarks Statistik (se afsnit ) og Ankestyrelsen (se afsnit ). De efterfølgende Faser vil indeholde udvidelser til grundfunktionaliteten således at: Fase 2 vil udvide mulighederne for håndtering af sager og dokumenter til også at omfatte integration til kommunernes ESDH-systemer 2 (se afsnit 5.4.2) samt præudfyldelse af blanketter i Blanketsystemet (se afsnit 5.7 Krav 203) og overførsel af breve til Dokumentboks (se afsnit 5.10),. Fase 3 vil udvide funktionaliteten med udtræk af Ledelsesinformation til også at omfatte faste rapporter (se afsnit ) og udvidet funktionalitet vedrørende økonomi integration omfattende overførsel af afholdte udgifter fra kommunens økonomisystem 3 til sammenligning med fremskrivningerne. Derudover vil der være en option på udvidelse af funktionaliteten vedrørende økonomi med styring af fakturaer og betalinger fra Systemet (se afsnit 5.6). Fase 4 vil udvide funktionaliteten yderligere ved, at der bliver udviklet en tættere integration med kommunernes kontorapplikationer (se afsnit ) samt muligheden for at anvende lokale tilbud i forbindelse med visitation og afgørelse (se afsnit 5.8), herunder integration til Tilbudsportalen (se afsnit 5.8.1) samt udtræk af data til Statens Arkiver (se afsnit ). For at tilgodese eksistende standardsystemer indenfor området udsatte børn og unge og dermed allerede eksisterende funktionalitet, er der indbygget den fleksibilitet i Faseopdelingen, at enkelte af aktiviteterne i Fase 2, Fase 3 og Fase 4 kan flyttes til tidligere Faser. Det drejer sig om aktiviteterne Blanketsystem Præudfyldelse (se afsnit 5.7 Krav 203), Dokumentboks (se afsnit 5.10), Ledelsesinformationer rapporter (se afsnit ), Lokalt Office miljø (se afsnit ), Tilbudssystem (se afsnit 5.8), Tilbudsportalen (se afsnit 5.8.1). Kravspecifikationens opdeling i de 4 Faser ønskes så vidt muligt fastholdt, og ændringer heraf vil således blive betragtet som et forbehold, jf. Kontraktens punkt 3.3. Det vil dog ikke blive betragtet som et forbehold, såfremt Leverandøren ønsker at fremrykke leveringen af en eller flere af de komponenter, som er markeret med lysegråt i Figur 2 ovenfor, til en tidligere Fase. En sådan fremrykning vil hverken blive tillagt positiv eller negativ vægt i forbindelse med tilbudsevalueringen og vil 2 Hvilke kommunale ESDH systemer, der er tale om er nærmere beskrevet i afsnit Hvilke kommunale økonomisystemer, der er tale om, er nærmere beskrevet i afsnit 5.6. F o r t r o l i g t S i d e 14/ d e c e m b e r

15 således ikke indgå som et element i tilbudsevalueringen i henhold til Udbudsbetingelsernes punkt 4.2. Såfremt Leverandøren anser denne faseopdeling for åbenbart uhensigtsmæssig, opfordres Leverandøren til at udnytte sin adgang til at stille spørgsmål til udbudsmaterialet. Kunden vil i givet fald inden for udbudsreglernes rammer vurdere, om sådanne spørgsmål giver anledning til at justere faseopdelingen Der vil i øvrigt, efter Kontraktens indgåelse, kunne ske mindre justeringer i fordelingen af komponenter mellem de 4 Faser som led i afklaringsfasen, jf. Kontraktens bestemmelser herom. Alle Krav i Kravspecifikationen vil være angivet med den Fase, hvori kravet skal opfyldes (se flere informationer om besvarelse af Krav i afsnit 2.3). I Use Cases vil opsplitningen i Faser have den konsekvens, at ikke alle trin kan udvikles i Fase 1. Når denne udfordring er identificeret, er der blevet lagt et midlertidigt trin ind som forklarer, hvordan Use Casen midlertidigt håndterer denne udfordring i Kravspecifikationens underbilag 3.1F. Trin i en Use Case, som er af midlertidig karakter, er markeret med det Fasenummer, hvor trinnet hører til eksempelvis Fase 1 for et trin, der skal afvikles i Fase Vejledning med hensyn til besvarelse af Krav Systemets Krav er klassificeret i følgende 5 kategorier: Krav kategori Minimumskrav (MK) Beskrivelse Minimumskrav er forbeholdt de elementer i Systemet, som er fundamentalt afgørende for, om Systemet kan anvendes af Ordregiver. Behov, formuleret som minimumskrav (MK), skal opfyldes af Tilbudsgiver og skal indgå i tilbuddet. Opfyldes et minimumskrav ikke, vil tilbuddet blive anset som ukonditionsmæssigt og tilbuddet vil ikke blive taget i betragtning. Krav (K) Minimumskrav opfyldes ved at udfylde kravskema 2 i Kravspecifikationens underbilag 3.1A med Opfyldes 100 %. Krav er Ordregivers krav til Systemet. Alle krav skal ikke nødvendigvis opfyldes, for at Ordregiver kan tage Tilbudsgivers tilbud i betragtning. F o r t r o l i g t S i d e 15/ d e c e m b e r

16 Opfyldes et krav ikke, vil tilbuddet score lavere på de relevante underkriterier i tildelingskriteriet det økonomisk mest fordelagtige tilbud. Krav opfyldes ved udfyldelse af kravskema 2 i Kravspecifikationens underbilag 3.1A. Info (I) Endvidere kan en beskrivelse af opfyldelsen af kravet indgå i afsnit 3 i Leverandørens Løsningsbeskrivelse, jf. underbilag 3.1O. Krav, anført som info, skal opfyldes af Leverandøren i Løsningsbeskrivelsen. Besvarelsen af info vil fremstå som en konkurrenceparameter ved tilbudsvurderingen og således indgå i bedømmelsen af tilbuddet i tilknytning til det relevante underkriterium. Option (O) Info opfyldes ved udfyldelse af tabellerne i Løsningsbeskrivelsens afsnit 4, jf. underbilag 3.1O. Optioner definerer tillægsfunktionalitet og/eller øvrige tilkøbsmuligheder, som Ordregiver kan vælge at tilkøbe ved kontraktindgåelsen eller senere. Såfremt Tilbudsgiver er af den opfattelse, at behov defineret som optioner (O), har betydning for opfyldelsen af minimumskrav (MK) eller krav (K), skal dette fremgå eksplicit af besvarelsen. Alle optioner skal ikke nødvendigvis tilbydes, for at Ordregiver kan og vil tage tilbuddet i betragtning. For optioner gælder, at Tilbudsgiver særskilt skal prisfastsætte hver enkel option, der afgives tilbud på, klart og entydigt, medmindre andet udtrykkeligt er angivet. Prisen skal omfatte omkostninger til alle elementer, der er nødvendige for pågældende options anvendelighed for Ordregiver. Merkantil Negativ Option (MNO) Optioner opfyldes ved: Angivelse af opfyldelsesgrad i Kravspecifikationens underbilag 3.1A, kravskema 3. Detaljeret beskrivelse af, hvordan optionen opfyldes i Løsningsbeskrivelsens afsnit 5, jf. underbilag 3.1O. Særskilt prisfastsættelse af hver option i Kontraktens bilag 12. Ordregiver benytter merkantile negative optioner (MNO'er), hvor Ordregiver er usikker på, om et krav i tilbuddet har en uforholdsmæssig fordyrende effekt på de F o r t r o l i g t S i d e 16/ d e c e m b e r

17 tilbudte priser. Kontraktsummen under Kontrakten henholdsvis den månedlige drifts- og vedligeholdelsesafgift under Driftskontraktens vil i forbindelse med kontraktunderskrift blive nedjusteret, såfremt Ordregiver eksekverer en eller flere MNO er i overensstemmelse med Tilbudsgivers angivelse af besparelsen i tilbuddet. For merkantile negative optioner gælder, at Tilbudsgiver særskilt skal prisfastsætte hver enkelt merkantil negativ option klart og tydeligt. Merkantile negative optioner opfyldes ved: Angivelse af opfyldelsesgrad i Kravspecifikationens underbilag 3.1A. kravskema 4. Detaljeret beskrivelse af, hvordan MNO'en opfyldes i Løsningsbeskrivelsens afsnit 6, jf. underbilag 3.1O. Særskilt prisfastsættelse af hver MNO i Kontraktens bilag 12. Alle krav er i Kravspecifikationen angivet ved et unikt fortløbende nummer, og vil være angivet i tabeller som den følgende: Krav [Navn] Kategori: Beskrivelse: Type: Kravtabellen er opbygget som følger: I øverste række er angivet et fortløbende unikt nummer samt et navn for kravet. Kategori er en angivelse af, om kravet er (jf. ovenstående tabel): Minimumskrav. Krav. Info. Option. Merkantil Negativ Option. Type er en inddeling af Kravet i følgende områder: Funktionelt krav (forretningskrav). Ikke funktionelle krav (løsningsorienterede krav). Implementering (krav til implementering). Lov og politik (lovmæssige og politiske krav til Systemet). Drift (krav til drift, dimensionering, vedligehold). Projektafvikling (krav til afviklingen af projektet). F o r t r o l i g t S i d e 17/ d e c e m b e r

18 Fase er en angivelse af, i hvilken Fase Kunden kravet skal opfyldes (se mere om Faser i afsnit 2.2). De Krav, som kan opfyldes i tidligere Faser er angivet i Kravet, som fx Fase 2 eller tidligere. Nederste række indeholder en tekstuel beskrivelse af Kravet. Faseangivelsen angives kun for minimumskrav og krav, herunder funktionelle og ikke funktionelle krav, samt for optioner. Info indeholder ikke angivelse af Fase og type. De skal opfyldes i forbindelse med tilbudsafgivelsen. Optioner og MNO'er indeholder ikke angivelse af type Vejledning til kravskemaer Leverandøren skal, som en del af tilbuddet, udfylde de i underbilag 3.1A vedlagte kravskemaer med angivelse af, hvordan Krav vil kunne opfyldes samt eventuelle præciseringer. Første liste i underbilag 3.1A består af en samlet oversigt over minimumskrav. Denne liste er udelukkende vedlagt til Leverandørens orientering og skal ikke udfyldes. Derefter vil være følgende kravskemaer som Leverandøren skal udfylde: Kravskema 2 med minimumskrav (MK) og krav (K). Kravskema 3 med optioner (O). Kravskema 4 med merkantile negative optioner (MNO). Et kravskema har følgende struktur: Kolonnerne i kravskemaet har følgende betydning: Krav nr., der er forudfyldt, og refererer til det unikke nummer, hvert Krav har i Kravspecifikationen, jf. afsnit 2.3. Titel, der er forudfyldt og angiver navnet på Kravet, som angivet i Kravspecifikationen, jf afsnit 2.3. Kategori, der er forudfyldt, og angiver prioriteten af Kravet som angivet i Kravspecifikationen, jf. afsnit 2.3. Type, der er forudfyldt, og angiver kategoriseringen af Kravet, som angivet i Kravspecifikationen, jf. afsnit 2.3. F o r t r o l i g t S i d e 18/ d e c e m b e r

19 Fase som angivet, der er forudfyldt og angiver, hvilken Fase kravet er gældende fra, jf. afsnit 2.3. Fase som tilbudt, der kan markeres med ét tal (1-4) af Leverandøren til angivelse af, hvilken Fase Leverandøren alternativt vælger at opfylde kravet i. Leverandøren skal her være opmærksom på de begrænsninger, der er i at vælge alternative Faser til aktiviteterne (se afsnit 2.2). De steder, hvor der ikke må vælges en alternativ Fase, er feltet markeret sort. Opfyldes 100 %, skal markeres med et X af Leverandøren, såfremt Kravet opfyldes 100 %. Delvis opfyldelse, skal markeres med en procentsats % af Leverandøren, såfremt Kravet kun delvist er opfyldt. Procentsatsen skal angive, hvor stor en del af kravet der opfyldes. Den del af kravet der er opfyldt, skal nærmere præciseres i kolonnen Leverandørens præcisering. De steder, hvor Kravet skal være opfyldt 100%, vil feltet være markeret sort. Opfyldes ikke, skal markeres med et X af Leverandøren, såfremt Kravet ikke opfyldes. De steder, hvor Kravet skal være opfyldt 100 %, vil feltet være markeret sort. Kundespecifikt Programmel skal markeres med en procentangivelse af, hvor stor en andel af kravet, der opfyldes med Kundespecifikt Programmel. Leverandørens præcisering er en angivelse af præciseringer af Leverandørens forståelse af Kravet, som skal bestå af referencer til specifikke afsnit i Løsningsbeskrivelsen. Der skal afkrydses i én og kun én, af kolonnerne Opfyldes 100 %, Delvis opfyldelse eller Opfyldes ikke. Såfremt Leverandøren intet anfører i én af kolonnerne Opfyldes 100 %, Delvis opfyldelse eller Opfyldes ikke, vil Kravet blive betragtet som 100 % opfyldt, dvs. som indeholdt i tilbuddet. Det understreges, at minimumskrav altid skal opfyldes 100 % og uden forbehold Vejledning til Løsningsbeskrivelsen Leverandøren skal, som del af sit tilbud, udarbejde en Løsningsbeskrivelse, som vedlægges som bilag 3.2 til Kontrakten. Løsningsbeskrivelsen er Leverandørens beskrivelse af det tilbudte System. Løsningsbeskrivelsen skal udarbejdes med udgangspunkt i den skabelon der fremgår af underbilag 3.1O. Såfremt Leverandøren ønsker at beskrive opfyldelsen af minimumskrav og krav, skal dette ske i Løsningsbeskrivelsen, der efterfølgende refereres til fra kravskemaerne. F o r t r o l i g t S i d e 19/ d e c e m b e r

20 Endelig er Løsningsbeskrivelsen også der, hvor Leverandøren skal besvare de krav, der er markeret med kategorien info (I), option (O) og merkantil negativ option (MNO). Ønsker Leverandøren at vedlægge underdokumenter til Løsningsbeskrivelsen bør disse nummereres med romertal og vedlægges som underbilag til Løsningsbeskrivelsen ( Underbilag I, Underbilag II, Underbilag III og så fremdeles) Leverandørens besvarelse af Kravspecifikationen Leverandørens besvarelse af Kravspecifikationen skal ske henholdsvis gennem udfyldelsen af kravskemaer i Kravspecifikationens underbilag 3.1A og Løsningsbeskrivelse med udgangspunkt i underbilag 3.1O samt ved udfyldelse af Kontraktens øvrige bilag. Dokumenterne skal udfyldes i den udleverede elektroniske skabelon. F o r t r o l i g t S i d e 20/ d e c e m b e r

21 3. Tidsplan og færdiggørelse af Projektets Faser Som gennemgået i afsnit 2.2, er udviklingen af Systemet opsplittet i 4 Faser og dermed i 4 Delleverancer, jf. Kontraktens punkt 4. Krav 1. Levering af Fase 1 (Delleverance 1) Kategori: Krav Type: Projektafvikling Beskrivelse: Leverancen af grundfunktionaliteten (Delleverance 1) skal være i drift senest 12 måneder efter underskrift af Kontrakten, jf. bilag 1. Krav 2. Færdiggørelse af det samlede Projekt Kategori: Krav Type: Projektafvikling Beskrivelse: Leverandøren skal sikre, at Projektets 4 Delleverancer er i drift senest 3 år efter underskrift af Kontrakten, jf. Kontraktens bilag 1. Leverandøren skal endvidere udfylde tidsplanen i Kontraktens bilag 1. Indholdet af de enkelte Faser fremgår af angivelserne i de enkelte Krav. Visse Krav kan opfyldes i en tidligere Fase end angivet, fx Fase 2 eller tidligere. Dette fremgår af faseangivelsen i Kravet og af kravskemaerne i underbilag 3.1A. F o r t r o l i g t S i d e 21/ d e c e m b e r

22 4. Overblik over Systemet Systemet skal understøtte den kommunale sagsbehandling i arbejdet med udsatte børn og unge. Der er tale om den proces- og analysestøtte som sagsbehandlerne behøver, for at gennemføre rådgivnings-, udrednings- og opfølgningssager i overensstemmelse med lovgivning på området og efter de retningslinjer, der følger af den socialfaglige metode ICS, som er den socialfaglige referenceramme i Systemet. Systemets sagsbehandling er bygget op omkring de vigtigste processer, der knytter sig til udsatte børn og unge, som har behov for en indsats efter Servicelovens 52. Iværksættelsen af disse indsatser følger en hovedproces bestående af fire delprocesser: Delproces vedrørende henvendelse og underretning. Delproces vedrørende 50-undersøgelse. Delproces vedrørende visitation. Delproces vedrørende indsats og opfølgning. En hovedproces betegner processen fra det øjeblik, kommunen modtager en henvendelse eller underretning, indtil de valgte foranstaltninger for et barn/en ung ophører. En hovedproces kan bestå af en række delprocesser, hvoraf de fire ovennævnte delprocesser er de mest centrale. Dertil kommer en række supplerende delprocesser. Hver delproces er en enkeltsag, og hver delproces kan gentage sig flere gange, og er hver gang en ny enkeltsag. De fire delprocesser og de supplerende delprocesser bliver beskrevet uddybende i afsnit 4.4. Følgende tegning illustrerer, hvorledes de nævnte processer/delprocesser vil blive understøttet af Systemet: F o r t r o l i g t S i d e 22/ d e c e m b e r

23 Figur 3 Referencearkitektur for Systemet Ovenstående tegning illustrerer den overordnede struktur af Systemet via en referencearkitektur (se mere information om referencearkitekturen i afsnit 6). Referencearkitekturen er resultatet af det analysearbejde, der har været foretaget, med henblik på afklaring af krav for det faglige område omkring udsatte børn og unge. Der har været gennemført en arbejdsproces, hvor der er taget udgangspunkt i de krav, som det faglige område har. Disse krav er blevet nedbrudt til en teknologisk løsning, der kan understøtte de identificerede krav (Systemet). Referencearkitekturen (jf. figur 3) viser de vigtigste elementer, som vil understøtte det faglige arbejde med udsatte børn og unge. Det helt centrale punkt i Systemet er evnen til at gennemføre sagsbehandling i forhold til udsatte børn og unge (via Sagsstyringskomponenten). Evnen til, på en fleksibel måde, at opsætte og afvikle de processer og delprocesser, som understøtter aktørens daglige arbejde med udsatte børn og unge er centralt for aktørens opfattelse af et velfungerende system og helt grundlæggende for Systemets fremtidige succes. I forbindelsen med sagsbehandlingen involveres de underliggende elementer. Sagsbehandleren kan registrere grundinformationer og familierelationer omkring barnet/den unge (via Familieadministrationskomponenten) via et tæt samarbejde med en CPR-datakilde og herigennem få mulighed for at se barnet/den unge i en samlet relationsmæssig kontekst. Fagligt er det valgt at basere sig på et anerkendt metodeværk indenfor området udsatte børn og unge - ICS metoden (der opfyldes via ICS komponenten), til struktureret opsamling af informationer for vurdering af - og opfølgning på barnet/den unges behov. Et centralt element i sagsbehandlingen, og hermed i alle processer og delprocesser, vil være håndteringen af sager og dokumenter (via Sags- og dokumentarkivet). Registreringen af handlinger (via Journalarkkomponenten), der er foretaget på de sager, der gennemløber sagsbehandlingen og som via et tæt samarbejde med kommunernes ESDH-systemer vil skabe et større forvaltningsmæssigt overblik over kommunens sager. En vigtig del af sagsbehandlingen af udsatte børn og unge er, at kunne planlægge de bedste indsatser overfor det enkelte barn/ung, og at sagsbehandlingen understøttes gennem de landsdækkende og kommunale tilbud, som (via Tilbudssystemet) stilles til rådighed for sagsbehandleren, når der fastlægges handleplaner for barnet/den unge. Sagsbehandlingen kan medføre behov for at videresende, notificere via s og eskalere sager til andre sagsbehandlere, og derfor stiller Systemet den mulighed til rådighed (via Organisationskomponenten), at de dele af kommunens organisationer, der er relevante for en sammenhængende sagsbehandling, kan registreres. Sagsbehandlingen giver anledning til, at der tages beslutning om en eller flere indsatser rettet mod det enkelte barn/den unge indsatser, som har en økonomisk konsekvens for kommunen. Systemet (via Økonomikomponenten) gør det muligt, at skabe et økonomisk overblik i forbindelse med sagsbehandlingen af barnet/den unge, både som fremskrivninger af de forventede økonomiske udgifter samt muligheden for at sammenholde fremskrivningerne med de faktisk afholdte udgifter. De faktiske afholdte udgifter hentes fra kommunens økonomisystem, enten direkte eller via en fil-upload. Systemet understøtter endvidere (via Blanketsystemet), at F o r t r o l i g t S i d e 23/ d e c e m b e r

24 give aktøren af Systemet en online-tilgang til de mest brugte blanketter samt sikre et antal muligheder for udtræk af data, fx i form af de lovpligtige indberetninger til Ankestyrelsen, Danmarks Statistik og udtræk til Statens Arkiver samt mere ad hoc prægede udtræk af Ledelsesinformationer (LI-udtræk). For at understøtte edag3 4, som træder i kraft 1. november 2010, vil en modtager af breve fra Systemet (såfremt modtageren er tilmeldt) kunne få tilsendt dette brev via Dokumentboks. For at tilgodese de krav det faglige område har, er der - udover de funktionelle og ikke-funktionelle krav - benyttet nogle de facto-analyseværktøjer til at beskrive fagområdet for udsatte børn og unge. Disse analyseværktøjer benyttes til at belyse fagområdet fra flere vinkler og efterfølgende sammenholde disse til ét samlet System. Følgende figur illustrerer nogle af de analyseværktøjer, der er benyttet til at beskrive Systemet: Figur 4 Analyseværktøjer til beskrivelse af det faglige område for udsatte børn og unge Som det fremgår af figuren, er der anvendt følgende analyseværktøjer: DUBU-aktører er en samling af de indgange, det er besluttet skal være ind i Systemet - forstået som, hvilke typer af brugere og eksterne systemer, som 4 Aftale om edag3: jf. underbilag 3.1M. F o r t r o l i g t S i d e 24/ d e c e m b e r

25 Systemet på en eller anden måde skal interagere med. Samlingen af aktører vil illustrere, hvilke dele af et fagområde, der skal understøttes. Udvælgelsen af disse aktører giver derfor vigtige input til de DUBU-Processer og DU- BU-Use Cases, der defineres. Fravælgelsen af andre aktører giver ligeså vigtige input til, hvad Systemet ikke skal kunne. DUBU-Aktører bliver nærmere gennemgået i afsnit 4.1. DUBU-begreber er en samling af begreber for det faglige område, som Systemet omhandler dvs. faglige begreber centreret omkring udsatte børn og unge. Disse begreber benyttes til at give en forståelsesmæssig kontekst som medvirker til, at definere de data Systemet skal rumme. Som det fremgår af figuren, giver DUBU-Begreberne input til de fleste andre elementer i beskrivelsen af Systemet. Der er en overordnet gennemgang af DUBU-begreber i afsnit 4.2. DUBU-blanketter er strukturerede samlinger af DUBU-begreber, som repræsenterer en slags pseudoskærmbilleder med fokus på data i forhold til de processer, der skal afvikles af Systemet. DUBU-blanketter er nærmere gennemgået i afsnit 4.3. DUB- processer/delprocesser, er de længerevarende proceser/delprocesser, der skal afvikles i Systemet. Længerevarende processer/delprocesser, som understøtter de arbejdsgange, som aktørerne i Systemet, defineret via DU- BU aktører, skal kunne udføre. DUBU-processer/delprocesser vil være beskrevet indenfor den begrebsmæssige kontekst som DUBU-begreber opstiller. DUBU-processer/delprocesser er nærmere gennemgået i afsnit 4.4 og DUBU-begreberne er defineret i underbilag 3.1B. DUBU-Use Cases i Systemet er karakteriseret ved at være korte sammensatte transaktioner med en tidsmæssig kort udbredelse. DUBU-Use Cases kan opfattes som byggeklodser til at sammensætte DUBUprocesser/delprocesser således, at én proces/delproces kan være sammensat af flere Use Cases, og hver Use Case kan indgå i flere processer/delprocesser. DUBU-Use Cases er nærmere gennemgået i afsnit 4.5. DUBU-services er de systemnære kald, der skal foretages for at eksekvere de ønskede operationer i Systemet. En DUBU-Use Case vil indeholde et kald til en service, hver gang der foretages en operation mod Systemet. En DU- BU-Use Case kan således indeholde mange kald til DUBU-Services, og en DUBU-Service kan kaldes fra mange DUBU-Use Cases. DUBU-Services gennemgås nærmere i afsnit 4.6. De enkelte elementer gennemgået ovenover repræsenterer således en sammenhæng mellem den faglige understøttelse og den tekniske udvikling af Systemet. I de følgende afsnit vil de enkelte elementer blive gennemgået nærmere. F o r t r o l i g t S i d e 25/ d e c e m b e r

26 4.1. DUBU aktører De centrale aktører i Systemet kan opdeles i to hovedgrupper: Brugeraktører, dvs. brugere som via en brugergrænseflade arbejder på Systemet. Systemaktører, dvs. andre it-systemer, som interagerer med Systemet, enten via systemkald/webservice-kald eller ved filbaseret udveksling af data. Følgende brugeraktører af Systemet, der varetager den faglige håndtering af alle sager vedrørende udsatte børn og unge, er identificeret: Sagsbehandler, der behandler sager vedrørende udsatte børn og unge indenfor de faglige rammer, som lovgivningen opstiller. Sagsfordeler, der danner sig et overblik over afdelingens/kontorets aktiviteter og herfra fordeler sager til de relevante sagsbehandlere. Administrativ medarbejder, der aflaster sagsbehandleren ved at kunne lave en del af de samme opgaver som sagsbehandleren, men som ikke foretager selve sagsbehandlingen. Leder, som medvirker i dele af sagsbehandlingen, og i at foretage konkrete beslutninger. Tilbudslæser, som har ret til at læse tilbud i Tilbudssystemet (se afsnit 5.8). Tilbudsvedligeholder, som kan vedligeholde (oprette, redigere og deaktivere) egne tilbud, som ikke er indeholdt i Tilbudsportalen (se afsnit 5.8). Økonomimedarbejder, skal kunne vedligeholde og rette økonomiske grunddata (herunder kontonummer m.v. i handleplan) samt igangsætte betalinger og opkrævninger. Derudover er der nogle brugeraktører, som håndterer opsætning og tilpasninger af Systemet: Kommunal administrator: Kan foretage visse opsætninger og tilpasninger af Systemet sådan, at der tages hensyn til kommunernes specifikke ønsker og Krav inden for rammerne af lovgivningen. Central administrator (hos Kunden eller Leverandør): Varetager opsætning af fælles parametre (fx baseret på national lovgivning) samt mere driftsmæssige opgaver. Følgende systemaktører er identificeret: Kommunens økonomisystem: Systemet vedligeholder budget- og regnskabstal for omkostninger på barnet/den unge. Finansposter kan overføres fra kommunens økonomisystem. Som option kan Systemet overføre opkrævnings- og betalingsanmodninger til kommunens økonomisystem. Udtræk af Ledelsesinformationer: Der kan udtrækkes ad hoc baserede data, som eventuelt kan bruges selvstændigt og uafhængigt af Systemet importeres i andre systemer. F o r t r o l i g t S i d e 26/ d e c e m b e r

27 Udtræk til Ankestyrelsen: Der kan leveres periodiske indberetninger til Ankestyrelsen. Udtræk til Statens Arkiver: Der kan leveres periodiske indberetninger til Statens Arkiver. Udtræk til Danmarks Statistik: Der kan afleveres årlige udtræk til Danmarks Statistik. Blanketsystem: Systemet anvender en række standardiserede blanketter. Disse elektroniske blanketter kan hentes fra et eksternt blanketsystem. CPR: Ved oprettelse af nye personer i Systemet samt ved identifikation af flytning, kan basisinformationer omkring personen hentes fra en ekstern CPR-datakilde. Kommunens ESDH-system: Udveksling af sager og dokumenter med de af kommunernes ESDH-systemer, der opfylder kravene til standardiserede snitflader. Kommunens og kontorapplikationer: Anvendes til produktion, redigering og udveksling af tekstbehandlingsdokumenter, brevfletning og standardformularer samt udveksling af s. Tilbudsportalen: Servicestyrelsens tilbudsportal anvendes ved søgning, udtræk og fastlæggelse af relevante tilbud for klienten. Dokumentboks. Til fremsendelse af breve til modtagere, som er tilmeldt Dokumentboks. På følgende figur visualiseres Systemets forskellige aktører: F o r t r o l i g t S i d e 27/ d e c e m b e r

28 Figur 5 Aktørernes interaktion med Systemet Krav 3. Brugeraktører som understøttes af Systemet Kategori: Minimumskrav Type: Funktionelt Beskrivelse: Systemet skal understøtte følgende brugeraktører: Sagsbehandler. Sagsfordeler. Administrativ medarbejder. Leder. Tilbudslæser. Tilbudsvedligeholder. Økonomimedarbejder. Kommunal administrator. Central administrator. Krav 4. Systemaktører som understøttes af Systemet Kategori: Minimumskrav Type: Funktionelt Beskrivelse: Systemet skal understøtte følgende systemaktører: Kommunens økonomisystem. Udtræk af Ledelsesinformation. Indberetning til Ankestyrelsen. Indberetning til Danmarks Statistik. Udtræk til Statens Arkiver. Eksternt Blanketsystem 5. Ekstern CPR-datakilde. Kommunens ESDH-system. Dokumentboks. Kommunens og kontorapplikationer. Tilbudsportalen. Krav 5. Beskrivelse af aktører, som understøttes af Systemet Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvordan de enkelte aktører realiseres i Systemet. 5 Såfremt Leverandøren vælger at Blanketsystemet er en del af Systemet, udgår Eksternt blanketsystem som systemaktør. F o r t r o l i g t S i d e 28/ d e c e m b e r

29 4.2. DUBU begreber Formålet med, at definere begreber i arbejdet med udsatte børn og unge er, at sikre en fælles begrebsverden for de parter, som arbejder med området. Dette uafhængigt af, om disse er faglige eksperter, sagsbehandlere, it-leverandører eller andre interessenter. Brugen af disse begreber i udviklingen af Systemet er derfor af stor vigtighed. Følgende tabel gennemgår eksempler på begreber 6 i arbejdet med udsatte børn og unge, og derudover henvises til underbilag 3.1B for en oversigt over de begreber, som ikke indgår i OIO: Begreb Handleplan Indsats Ydelse Børn og unge med særlige Krav Beskrivelse Handleplanen er et dokument i den del af sagsbehandlingen, der i terminologien for sagsbehandling kaldes for planlægning af indsats, og som består i at fastlægge rammer og formål for indsatsen. Indsats er det, kommunen gør for en borger. Indsatsen er det sæt af ydelser, der leveres af en eller flere leverandører af tilbud til en bestemt borger, og som kan bestå af: Enkeltindsats, der tilkendes en borger i én afgørelse. Samlet indsats, der omfatter alle enkeltindsatser i relation til en borger. Tilbudsindsats, der leveres af ét tilbud. Visiteret indsats, der iværksættes på baggrund af en eller flere afgørelser. Ikke-visiteret indsats, der iværksættes på en anden baggrund end en afgørelse. Ydelser er det, en borger kan få bevilget fra det offentlige. Det kan fx dreje sig om ophold, støttet samvær, økonomisk støtte m.m. Det er alle de forskellige ydelser, en sagsbehandler kan bevilge. Børn og unge med særlige behov er gruppen af individer, i aldersgruppen 0 år (inkl. det ufødte barn) til 17 år (23 år ved efterværn), som kan have behov for særlig støtte, jf. Serviceloven. Krav 6. Begrebsanvendelse Kategori: Krav Type: Ikke funktionelt 6 Begreber hentet fra det fællesoffentlige OIO projekt: Digitalisering af Udsatte Børn og Unge, datastandardisering af centrale DUBU begreber: jf. underbilag 3.1M. F o r t r o l i g t S i d e 29/ d e c e m b e r

30 Beskrivelse: Systemet skal i skærmbillederne, navngivning af funktioner, tabeller og felter mm. anvende den terminologi, der anvendes i Kravspecifikationen, herunder de begreber, der er defineret i begrebslister i underbilag 3.1B. Begreberne vedrørende udsatte børn og unge fremgår af underbilag 3.1N DUBU-blanketter Der skelnes mellem følgende elektroniske blanketter: DUBU-blanketter for delprocesser. DUBU-blanketter øvrige. DUBU-outputblanketter. KL-blanketter. Derudover er der udviklet særlige ICS blanketter til at understøtte indhentning af sagsinformation fra samarbejdsparter som fx folkeskoler og daginstitutioner 7. Følgende diagram illustrerer et eksempel på et udsnit af en blanket: Figur 6 Eksempel på blanket Alle blanketter repræsenterer data i sagsbehandlingen, data i kommunikationen mellem sagsbehandler og borger eller data der, i medfør af sagsbehandlingen, skal indberettes til andre myndigheder. De vil blive gennemgået i de følgende afsnit DUBU-blanketter for delprocesser Denne type blanketter betegner de forskellige delprocesser, der skal digitaliseres. Digitaliseringen af procesforløbene skal ske med udgangspunkt i procesdiagrammerne i underbilag 3.1C og DUBU-blanketterne i underbilag 3.1E. Disse DUBU- 7 Disse kan ses på jf. underbilag 3.1M. F o r t r o l i g t S i d e 30/ d e c e m b e r

31 blanketter skal ikke fungere som praktiske administrationsværktøjer, men som illustrationer af datafangst i Systemet en slags pseudoskærmbilleder. De er typisk delt op i sagsstyring, der vedrører vigtige aktiviteter, som indgår i processen og oftest håndteres af Sagsstyringskomponenten og det øvrige, der vedrører den materielle sagsbehandling. Der er lavet en introduktion til disse blanketter, der indgår i underbilag 3.1E. Se i øvrigt en gennemgang af delprocesser i afsnit DUBU-blanketter - øvrige Øvrige dækker over DUBU-blanketter til illustration af datafangst, der ikke illustrerer en delproces. Det gælder: Oversigt over sammenhæng mellem ydelser, tilbud, lovhjemmel og kontoplansnummer, DUBU-blanket 19, underbilag 3.1E. Stam- og grundoplysninger, DUBU-blanket 20, underbilag 3.1E. Øvrige DUBU-blanketter fremgår også af underbilag 3.1E DUBU-outputblanketter Dele af informationerne, som indsamles i løbet af de forskellige delprocesser, skal kunne printes ud som samlede dokumenter, der skal kunne læses af andre, fx af forældre eller børne- og ungeudvalget. Det drejer sig om: Undersøgelsesplan i to udgaver: o Den enkle. o Den guidende. 50 undersøgelse i to udgaver: o Individuel for et enkelt barn eller en ung. o Fælles for flere børn/unge i familien. Handleplanen og eventuelle senere reviderede handleplaner. Opfølgningen på indsatser. Disse blanketter skal fremstå læsevenlige for udenforstående. DUBUoutputblanketterne illustrerer, hvilke informationer der skal være tilgængelige i disse dokumenter, og i hvilken rækkefølge de skal fremstå, jf. underbilag 3.1D. Dokumentet Kilder til outputblanketter, der er en del af underbilag 3.1D, forklarer, fra hvilke felter i DUBU-outputblanketterne oplysningerne skal hentes fra. Kun udfyldte felter skal dog medtages i outputblanketten KL-blanketter Særligt en del af den eksterne kommunikation håndteres gennem KL s blanketter 8, som skal hentes fra et eksternt blanketsystem. Der er henvisninger til disse blanketter i underbilag 3.1C og underbilag 3.1F. Særligt følgende er relevante: Børn og unge Anbringelse. 8 Blanketterne kan ses på jf. underbilag 3.1M. F o r t r o l i g t S i d e 31/ d e c e m b e r

32 Børn og unge Andre foranstaltninger Børn og unge Generel administration Børn og unge Nedsat funktionsevne Børn og unge Plejeforhold DUBU Processer/delprocesser Nedenfor vises et eksempel på en hovedproces med delprocesser: Figur 7 Hovedprocesser og delprocesser Hoved- og delprocesser understøtter lov om social service (Serviceloven), som regulerer hjælpen til afgrænsede målgrupper, herunder udsatte børn og unge. Serviceloven omfatter regler om særlig støtte til børn og unge, men der er ikke tale om en detaljeret lovgivning hvad angår indsatsen. Der er tale om en rammelov, da børn, unge og deres familier er forskellige, hvilket afspejler sig i problemstillingerne og valget af indsatser. Serviceloven sikrer, at de F o r t r o l i g t S i d e 32/ d e c e m b e r

33 børn og unge der har behov for særlig støtte, som ikke kan dækkes af deres forældre alene, har ret til at få hjælp fra kommunen. Området er endvidere præget af mange krav til processen i sagsbehandlingen. Der er ofte tale om forebyggende foranstaltninger i nærmiljøet, men der kan også ske anbringelser uden for hjemmet, om nødvendigt. Kommunens sagsbehandlere skal så vidt muligt inddrage både børn, unge og forældre i sagsbehandlingen, men der er også mulighed for visse tvangsmæssige afgørelser. På dette sagsområde er der stærk fokus på god sagsbehandling og opfølgning, fordi den gode sagsbehandling ofte hænger sammen med kvalitativt gode afgørelser og vurderinger i sagerne. Dette afspejler sig i lovgivningen, som stiller krav til både proces og indhold i sagsbehandlingen. De fire vigtigste delprocesser er. Delproces vedrørende underretning eller henvendelse, DUBU-blanket 1, underbilag 3.1E. Delproces vedrørende 50-undersøgelse, DUBU-blanket 2, underbilag 3.1E. Delproces vedrørende visitation, DUBU-blanket 3.a og 5, underbilag 3.1E. Delproces vedrørende indsats og opfølgning, DUBU-blanket 4.a, underbilag 3.1E. Disse delprocesser håndterer en række vigtige afgørelser efter Servicelovens 52, det vil sige ydelser, der særligt er målrettede udsatte børn og unge, og som det er centralt at få realiseret i forhold til Systemets målsætninger. Hertil kommer en række delprocesser, der enten er ekstraaktiviteter ( sløjfer ) på sagsgangen eller afgørelser om supplerende eller alternative indsatser, der indebærer en selvstændig afgørelse eller vigtig procesbeslutning. Det gælder: Ekstraaktiviteter i sagsgangen: Delproces vedrørende formandsbeslutning, DUBU-blanket 12, underbilag 3.1E. Delproces vedrørende tvangssager til forelæggelse for børne- og ungeudvalget, DUBU-blanket 13, underbilag 3.1E. Klage og anke. o Delproces vedrørende genvurdering efter klage, DUBU-blanket 14, underbilag 3.1E. o Delproces vedrørende afgørelse i det sociale nævn, DUBU-blanket 15, underbilag 3.1E. o Delproces vedrørende afgørelse i Ankestyrelsen frivillige foranstaltninger, DUBU-blanket 16, underbilag 3.1E. o Delproces vedrørende afgørelse i Ankestyrelsen tvangsmæssige foranstaltninger, DUBU-blanket 17, underbilag 3.1E. o Delproces vedrørende afgørelse i landsretten, DUBU-blanket 18, underbilag 3.1E. F o r t r o l i g t S i d e 33/ d e c e m b e r

34 Delproces vedrørende løbende indsatser/anbringelser, DUBU-blanket 11a, underbilag 3.1E. Delproces vedrørende kommunes underretning til ny bopælskommune, DU- BU-blanket 11b, underbilag 3.1E. Gennemførelse af undersøgelse efter 51 (ikke dækket af særskilt blanket, men indgår i DUBU-blanket 2, underbilag 3.1E). Supplerende indsatser: Delproces vedrørende rådgivning og konsulentbistand (ikke dækket af særskilt blanket). Delproces vedrørende dækning af merudgifter, DUBU-blanket 6, underbilag 3.1E. Delproces vedrørende tabt arbejdsfortjeneste, DUBU-blanket 7, underbilag 3.1E. Delproces vedrørende samvær og kontakt, DUBU-blanket 10, underbilag 3.1E. Delproces vedrørende særlige dagtilbud ( 32) eller klubtilbud ( 36), DU- BU-blanket 8, underbilag 3.1E. Delproces vedrørende undervisningsindsats (ikke dækket af særskilt blanket). Lægebehandling med tvang (ikke dækket af særskilt blanket). Delproces vedrørende pålæg, DUBU-blanket 3.b, underbilag 3.1E. Delproces vedrørende opfølgning af pålæg, DUBU-blanket 4.b, underbilag 3.1E. Delproces vedrørende særskilt plan for forældre ved anbringelse af barnet, DUBU-blanket 9, underbilag 3.1E. Delproces vedrørende økonomisk støtte efter 52a (ikke dækket af særskilt blanket). Leverandøren kan få et samlet overblik over de centrale processer gennem følgende underbilag til Kravspecifikationen: DUBU-procesdiagrammer: Består dels af et oversigtsdiagram (der viser forløbet gennem de fire vigtigste delprocesser (vist herover) og dels består bilaget af detaljerede diagrammer, som hver især beskriver de aktiviteter og sammenhænge mellem disse som skal udføres i hver delproces. Derudover er der en oversigt over enkeltsager, der ligeledes er delprocesser i Systemet, underbilag 3.1C. DUBU-blanketter: Illustrerer den datafangst, der knytter sig til de enkelte delprocesser, underbilag 3.1E. Krav 7. Opsætning af administrative processer Kategori: Minimumskrav Type: Funktionelt Beskrivelse: Systemet skal understøtte en opsætning af de administrative delprocesser på børne- og ungeområdet, således at sagsbehandleren F o r t r o l i g t S i d e 34/ d e c e m b e r

35 kan gennemløbe alle de delprocesser, som er illustreret i procesdiagrammerne i underbilag 3.1C, og som det fremgår af DUBUblanketterne i underbilag 3.1E. Der er følgende centrale delprocesser: De fire primære delprocesser: o Underretning eller henvendelse. o 50-undersøgelse. o Visitation. o Indsats og opfølgning. Ekstraaktiviteter i sagsgangen: o Formandsbeslutning. o Tvangssager for børne- og ungeudvalget. o Klage og anke. o Løbende indsatser/anbringelser. o Underretning til ny bopælskommune. Gennemførelse af undersøgelse efter 51. Supplerende indsatser: o Forældre- og ungepålæg. o Rådgivning og konsulentbistand. o Dækning af merudgifter. o Tabt arbejdsfortjeneste. o Samvær og kontakt. o Særlige dag- og klubtilbud. o Undervisningsindsats. o Lægebehandling med tvang. o Plan for forældre ved anbringelse. o Økonomisk støtte. Krav 8. Systemet skal leveres med en standardopsætning Kategori: Minimumskrav Type: Funktionelt Beskrivelse: Systemet skal fra Leverandørens side leveres med en standardopsætning, der opfylder de lovgivningsmæssige krav, jf afsnit 9, til sagsbehandling i børn- og ungesager, således at kommunerne får et System, der umiddelbart kan anvendes uden lokale tilpasninger. De ovennævnte delprocesser gennemgås kort i de følgende afsnit Delproces vedrørende underretning eller henvendelse Delprocessen vedrører modtagelse og behandling af en underretning eller henvendelse fra det øjeblik den modtages, til det er afgjort, hvordan der skal reageres på underretningen. Hvis sagen fortsætter, vil det typisk være med delproces vedrø- F o r t r o l i g t S i d e 35/ d e c e m b e r

36 rende 50-undersøgelse, men der kan også være andre udfald, jf. underbilag 3.1C, procesdiagram Behandler underretning el. henvendelse. Delprocessen illustreres desuden i DUBU-blanket 1, underbilag 3.1E. Figur 8 Procesdiagram eksempel Ovenstående diagram er et eksempel på et procesdiagram. Der er designet tilsvarende diagrammer for et flertal af de processer der gennemgås i det følgende. Alle procesdiagrammer kan ses i underbilag 3.1C Procesdiagrammer. Hvad sker der i delprocessen? Formålet med delprocessen vedrørende underretning eller henvendelse er, at foretage en indledende vurdering af de børn, som kommunen bliver (gjort) opmærksom på, kan have brug for særlig støtte. Ved personlig eller telefonisk henvendelse og/eller underretning, vil sagsbehandleren ofte være i gang med andre sager, og skal hurtigt kunne åbne eller oprette den sag, som henvendelsen handler om. I delprocessen skal sagsbehandleren guides til at få et hurtigt overblik over barnets situation, så man kan reagere med en tidlig indsats, hvor det er nødvendigt. Systemet skal bidrage til dette overblik ved at: Give sagsbehandleren nem adgang til hjælpespørgsmål, som kan bruges ved en personlig og/eller telefonisk henvendelse eller underretning. Give sagsbehandleren en nem mulighed for at få et overblik over eventuelle tidligere indsatser overfor barnet/den unge eller andre i familien. Give sagsbehandleren de samme muligheder for at inddrage familien og indhente sagsinformation fra fagpersoner, som i 50-undersøgelsen, men i en enklere form, som ikke nødvendigvis følger ICS. F o r t r o l i g t S i d e 36/ d e c e m b e r

37 Delproces vedrørende 50-undersøgelse Delprocessen vedrørende 50-undersøgelse oprettes automatisk af Systemet, når sagsbehandleren i delprocessen vedrørende underretning eller henvendelse har vurderet, at barnet/den unge muligvis er udsat. En anden indgang til delprocessen er, når sagsbehandleren i delprocessen vedrørende indsats og opfølgning har vurderet, at ændringer af formålet nødvendiggør en fornyet 50-undersøgelse. Delprocessen skal understøtte sagsbehandleren i at foretage en kvalificeret socialfaglig og dokumenteret afdækning af, om der i forhold til barnet/den unge forekommer problemer, som bør resultere i en indsats. Herunder en vurdering af, hvilke forhold hos barnet/den unge, der bør være mål for indsatsen og hvilken indsatstype, der kunne tænkes at sikre disse mål. Delprocessen afsluttes med en vurdering af, om barnet/den unge er udsat. Hvis barnet/den unge er udsat, igangsættes delproces vedrørende visitation, mens sagen afsluttes, hvis barnet/den unge ikke er udsat. Delprocessen er illustreret i DUBU-blanket 2, underbilag 3.1E, samt i procesdiagram Undersøgelse-Foretager, underbilag 3.1C. Hvad sker der i delprocessen? Formålet med delproces vedrørende 50-undersøgelse er, at understøtte sagsbehandleren i at foretage en faglig vurdering af, om barnet/den unge har brug for særlig støtte. Sagsbehandleren udarbejder sin faglige vurdering på baggrund af en socialfaglig undersøgelse til hvilken, der er en række indholdsmæssige og processuelle krav i Serviceloven, som Systemet skal understøtte. En socialfaglig undersøgelse er en større arbejdsopgave, som tager tid og kræver planlægning. Dels fordi, der typisk skal indhentes sagsinformation fra familien og fagpersoner dels fordi, der er krav om, at undersøgelsen er helhedsorienteret, og som minimum omfatter seks lovbestemte punkter. Derfor kan sagsbehandleren sjældent udarbejde undersøgelsen i én arbejdsgang, men vil oftest være nødt til at dele den op i mindre dele. Der kan også være andre hasteopgaver, som betyder at sagsbehandleren bliver afbrudt i arbejdet. Dette skal Systemet understøtte ved at: Gøre det let for sagsbehandleren at overskue, hvor langt man er nået i delprocessen, når man vender tilbage til arbejdsopgaven. Give sagsbehandleren mulighed for nemt at planlægge og følge op på undersøgelsesaktiviteter, fx samtaler med barnet/den unge og familien, tværfaglige møder, indhentning af statusudtalelser fra fagpersoner m.v. Karakteren af en 50-undersøgelse kan være meget forskellig og en undersøgelse må aldrig være mere omfattende end formålet tilsiger. Derfor har sagsbehandleren brug for at kunne justere niveauet i 50-undersøgelsen, til at være mere eller F o r t r o l i g t S i d e 37/ d e c e m b e r

38 mindre omfattende alt efter barnets forhold (se mere uddybende om fleksibilitet i ICS i afsnit 0). En socialfaglig undersøgelse skrives i fritekst, og kræver en høj grad af socialfaglig viden, som i en analyse og faglig vurdering skal sammenholdes med et overblik over barnets situation. Systemet skal understøtte denne delproces ved at: Stille hjælpetekster (fx aldersopdelte fokusområder) til rådighed for sagsbehandleren i de dele af processen, hvor det er relevant. Give sagsbehandleren en nem mulighed for at få et overblik over eventuelle tidligere indsatser overfor barnet/den unge eller andre i familien. Give sagsbehandleren mulighed for at hente tekstfelter fra selve undersøgelsen, som skal bearbejdes i analysen Delproces vedrørende visitation Delproces vedrørende visitation oprettes automatisk af Systemet, når sagsbehandleren i delproces vedrørende 50-undersøgelse har vurderet, at barnet/den unge har behov for særlig støtte, jf. procesdiagram Visiterer og iværksætter indsats, underbilag 3.1C. En anden indgang til delprocessen kan være, når sagsbehandleren i en opfølgning på en indsats vurderer, at der er behov for at revidere indsats eller handleplan, jf. procesdiagram Opfølgning på indsats, underbilag 3.1C. I delprocessen skal der udarbejdes mål og eventuelt delmål i en handleplan. Sagsbehandleren kan tilføje indsatstype og indsats, og kan desuden hente forslag med priser og leverandører fra Tilbudssystem og genanvende disse data til udarbejdelse af indstillingen og afgørelsen. Delprocessen afsluttes med en afgørelse om iværksættelse af indsats. Delprocessen er illustreret i DUBU-blanket 3.a og DUBU-blanket 5 i underbilag 3.1E, samt procesdiagram Visiterer og iværksætter indsats, underbilag 3.1C. Hvad sker der i delprocessen? Formålet med delprocessen er, at understøtte sagsbehandleren i at samarbejde med forældrene og barnet/den unge om at udarbejde mål og eventuelle delmål, der tager udgangspunkt i barnets behov, som afdækket i 50-undersøgelsen. Når sagsbehandleren arbejder med handleplanen, skal det være muligt at genbruge relevante data fra 50-undersøgelsen. Da handleplanen er opbygget omkring samme systematik som 50-undersøgelsen, skal ICS komponenten også være tilgængelig i denne delproces. Det er en del af formålet, at sagsbehandleren skal have mulighed for at integrere økonomiovervejelser i sagsbehandlingen 9. Derfor skal Systemet hjælpe sagsbehandleren med at hente forslag til indsatser med priser og leverandør fra Tilbudssy- 9 Integration af økonomiovervejelser i sagsbehandlingen, Hoved- og bilagsrapport, KR, (august 2004)), jf. underbilag 3.1M. F o r t r o l i g t S i d e 38/ d e c e m b e r

39 stem og genanvende disse data til udarbejdelse af indstillingen og afgørelsen. Indsatserne skal samtidig kunne grupperes i flere indstillingsalternativer. Det er vigtigt at vide om delprocessen, at sagsbehandleren på den ene side skal understøttes i at tænke mål før indsats, men på den anden side først kan konkretisere handleplanen fuldstændigt, når det er afgjort, hvilke indsatser der skal iværksættes. Processen er derfor ikke altid fuldstændig lineær, og der kan fx være behov for at gemme forskellige udgaver af handleplanen (fx før og efter afgørelse om konkret indsats). Det kan variere fra kommune til kommune, hvem der har den visiterende kompetence i forskellige typer sager, og Systemet skal kunne håndtere disse forskellige procedurer Delproces vedrørende indsats og opfølgning Delproces vedrørende indsats og opfølgning oprettes automatisk af Systemet, når der i delproces vedrørende visitation er foretaget en afgørelse om indsats efter Servicelovens 52. I sagsforløbet kan der være gentagne opfølgninger på indsatsen og målene i handleplanen, hvilket tidsfastsættes på baggrund af forskellige hændelser, jf. procesdiagram Opfølgning på indsats, underbilag 3.1C. Hver opfølgning afsluttes med en faglig vurdering af, om indsatsen fortsat er passende. Hvis indsatsen eller handleplanen er uændret efter en opfølgning, fortsætter sagen. Sagen afsluttes først, når formålet med handleplanen er opfyldt eller ved beslutning om at udarbejde revideret handleplan eller 50-undersøgelse. Formålet med delprocessen vedrørende indsats og opfølgning er at understøtte, at sagsbehandleren kan føre løbende notater om den igangværende indsats. Derudover at planlægge og gennemføre de lovgivningsbestemte opfølgninger, sådan at man altid sikrer, at indsatsen er tilpasset barnets aktuelle behov. Delprocessen illustreres i DUBU-blanket 4.a, underbilag 3.1E, og i procesdiagram Opfølgning på indsats, underbilag 3.1C. Hvad sker der i delprocessen? Da der kan gå helt op til seks måneder mellem opfølgninger er det vigtigt, at Systemet kan minde sagsbehandleren om, hvornår det er ved at være tid til den næste opfølgning. Som ved 50-undersøgelsen vil det ofte være nødvendigt at inddrage sagsinformation fra fagpersoner, ligesom der skal planlægges samtaler med barnet/den unge og forældre. Derfor skal Systemet understøtte denne proces med de samme planlægningsmuligheder, som ved 50-undersøgelsen. Den primære del af opfølgningen sker i fritekst, som følger ICS-systematikken og de mål, der er knyttet hertil. Desuden er der mulighed for, at sagsbehandleren på en skala kan evaluere opfyldelsen af mål i handleplan og tilfredsheden med Leverandøren. Tilfredshedsvurderingerne lagres i det lokale Tilbudssystem, så de kan bruges i forbindelse med senere visitationer. F o r t r o l i g t S i d e 39/ d e c e m b e r

40 Supplerende delprocesser De fire ovenstående delprocesser angiver det mest almindelige forløb i forbindelse med afgørelse, der træffes efter gennemførelse af en 50-undersøgelse og med forventning om, at der skal tildeles en forebyggende eller anbringende foranstaltning efter Servicelovens 52. Foruden de fire centrale delprocesser eksisterer et antal supplerende delprocesser, som fremgår af lovgivningen på området og de vedlagte underbilag; underbilag 3.1C og underbilag 3.1E. Generelt er der tale om delprocesser, der enten afspejler: 1. Ekstra aktiviteter i sagsgangen, altså nogle ekstra sløjfer på sagsgangen før eller efter en afgørelse om indsats eller 2. Supplerende indsatser, ved behov for at supplere de vigtigste forebyggende eller anbringende foranstaltninger med øvrige indsatser, der kræver en særskilt afgørelse. Fælles for alle disse delprocesser er, at de udløser oprettelsen af en ny enkeltsag. Det er også kendetegnende, at it-understøttelsen på disse delprocesser ikke er så omfattende eller kritisk i forhold til Systemets mål som på de fire ovenstående delprocesser, og derfor heller ikke beskrevet så detaljeret. Typisk vedrører de nogle få sagsstyringsaktiviteter samt registrering af afgørelse. Herudover trækkes der på de generelle funktionaliteter i forbindelse med journalark og håndtering af dokumenter. Der er følgende supplerende delprocesser: 1. Ekstraaktiviteter i sagsgangen Tvangssager til forelæggelse for børne- og ungeudvalget. Formandsbeslutning. Klage og anke. Løbende indsatser/anbringelser. Underretning til ny bopælskommune. Gennemførelse af undersøgelse efter Supplerende indsatser Forældre- og ungepålæg. Rådgivning og konsulentbistand. Dækning af merudgifter. Tabt arbejdsfortjeneste. Samvær og kontakt. Særlige dag- og klubtilbud. Undervisningsindsats. Lægebehandling med tvang. Plan for forældre ved anbringelse. F o r t r o l i g t S i d e 40/ d e c e m b e r

41 I forhold til de supplerende indsatser (punkt 2 ovenfor) er det afgørende, at kunne registrere afgørelser vedrørende disse med pris og varighed, for at kommunen kan få et helhedsbillede af indsatsen i forhold til barnet/den unge, både i socialfaglig og økonomisk forstand. Det betyder også, at disse indsatser skal indgå i Tilbudssystemet med mulighed for, at kommunen kan registrere priser 10. Det skal i den forbindelse bemærkes, at disse supplerende indsatser også kan iværksættes uafhængigt af indsatser efter 52. Nedenfor følger en kort beskrivelse af de enkelte delprocesser. Ad 1). Ekstraaktiviteter i sagsgangen Delproces vedrørende tvangssager til forelæggelse for børne- og ungeudvalget En tvangssag for børne- og ungeudvalget er en tvangsmæssig afgørelse, som behandles i børne- og ungeudvalget. It-understøttelsen fokuserer på at guide sagsbehandleren igennem de lovbundne aktiviteter ved forelæggelse og godkendelse, samt muligheden for at registrere afgørelsen. Delprocessen er illustreret i DUBU-blanket 13, underbilag 3.1E, og procesdiagram Indsats Træffer afgørelse, underbilag 3.1C. Delproces vedrørende formandsbeslutning En formandsbeslutning er en tvangsmæssig afgørelse, som af hensyn til barnet/den unges øjeblikkelige behov, ikke kan afvente at sagen behandles i børne- og ungeudvalget. I akutte tvangssager kan en sagsbehandler fx vurdere, at der skal træffes en formandsbeslutning om en indsats, hvorefter 50-undersøgelsen fortsættes parallelt. It-understøttelsen fokuserer på at guide sagsbehandleren igennem de lovbundne aktiviteter ved forelæggelse og godkendelse, samt muligheden for at registrere afgørelsen. Delprocessen er illustreret i DUBU-blanket 12 - delproces vedrørende formandsbeslutning, underbilag 3.1E, og procesdiagram Formandsbeslutning, underbilag 3.1C. Delproces vedrørende klage og anke 10 Jf. OIO begreber jf. underbilag 3.1M. F o r t r o l i g t S i d e 41/ d e c e m b e r

42 I disse delprocesser behandler kommunen, Det Sociale Nævn, Ankestyrelsen eller Landsretten klager eller anker over kommunernes afgørelser om borgerens rettigheder og pligter efter den sociale lovgivning. Kommunerne skal kunne holde styr på, hvordan deres klage- og ankesager ender, herunder hvor mange, de får medhold i. Understøttelsen fokuserer derfor primært på at sikre, at kommunerne kan registrere, til hvilken instans sagerne går og hvad udfaldet bliver. Da der træffes afgørelser i hver instans, er der et antal delprocesser vedrørende klage og anke, jf. DUBU-blanketter i underbilag 3.1E med samme benævnelser: Tvangssager: DUBU-blanket 17 og procesdiagram Behandler Ankesag over børne- og ungeudvalgets afgørelse. DUBU-blanket 18. Der er ikke lavet et procesdiagram til delprocessen. Øvrige sager: DUBU-blanket 14 og procesdiagram Genvurderer sag efter klage. DUBU-blanket 15 og procesdiagram Behandler det sociale nævns afgørelse. Procesdiagrammerne fremgår af underbilag 3.1C. Delproces vedrørende løbende indsatser/anbringelser I denne delproces videregives handlekommuneforpligtelsen efter nærmere aftale mellem to kommuner. Handlekommunen er den kommune, der er kompetent til at træffe afgørelse om at yde hjælp eller støtte efter reglerne om særlig støtte til børn og unge. Overdragelsen sker typisk, fordi den unge har boet i en anden kommune end handlekommunen i lang tid, og snart skal overgå til en form for voksenbistand. It-understøttelsen fokuserer på nogle få sagsstyringsaktiviteter samt yderligere sagsinformation, der skal indberettes til Ankestyrelsen. Delprocessen er illustreret i DUBU-blanket 11a, underbilag 3.1E. Der er ikke lavet et procesdiagram til delprocessen. Delproces vedrørende underretning til ny bopælskommune I denne delproces, som initieres, når en familie flytter og kommunen vurderer, at et barn eller en ung i familien har behov for særlig støtte, har kommunen underretningspligt til den nye bopælskommune. I delprocessen videregives oplysninger om forhold vedrørende barnet eller den unge, som giver en formodning om behov for særlig støtte. F o r t r o l i g t S i d e 42/ d e c e m b e r

43 It-understøttelsen fokuserer på nogle få sagsstyringsaktiviteter som skal sikre, at overleveringen af den relevante sagsinformation understøttes. Delprocessen er illustreret i DUBU-blanket 1 og DUBU-blanket 11.b samt i Use Case 001 Opret sag, Use Case 015 Modtag underetning/henvendelse, Use Case 032 Afslut sag og Use Case 036 Overflytning af sagsinformation til anden kommune. DU- BU-blanketterne fremgår af underbilag 3.1E, Use Cases af underbilag 3.1F og af procesdiagram Mellemkommunal underretning. Delproces vedrørende gennemførelse af undersøgelse efter 51 Delprocessen vedrører kommunens afgørelse om at foretage en undersøgelse af barnet/den unge uden samtykke fra forældrene. Afgørelsen foretages af børne- og ungeudvalget, og it-understøttelsen fokuserer alene på enkelte sagsstyringsaktiviteter samt registrering af afgørelsen i udvalget. Delprocessen er dækket af DUBU-blanket 13, underbilag 3.1E, og procesdiagrammer Undersøgelse-Foretager samt Børne- og ungeudvalget træffer afgørelse, begge underbilag 3.1C. Ad 2. Supplerende indsatser Delproces vedrørende forældre- og ungepålæg Delprocessen vedrører kommunens afgørelse om, at forældre eller unge skal foretage forskellige aktiviteter, fx kan forældrene skulle følge børn i skole eller deltage i forældremøder og den unge kan fx skulle være hjemme på et bestemt tidspunkt. Derudover et mere generelt, fremadrettet krav, pålagt af kommunen, om en eller flere konkrete opgaver og pligter, som forældremyndighedsindehaveren skal påtage sig, jf. Servicelovens 57a eller den unge skal følge, jf. Servicelovens 57b. Afgørelsen forudsætter ikke en handleplan, og indgår derfor ikke i det almindelige sagsforløb. Afgørelsen kan dog træffes samtidig med en indsats efter Servicelovens 52 fx om, at barnet skal gå i vuggestue og i så fald kan dette indgå i handleplanen. Der er dog tale om selvstændige afgørelser. It-understøttelsen fokuserer på enkelte sagsstyringsaktiviteter, den vurdering der skal finde sted for at kunne træffe afgørelsen, samt registrering af afgørelsen jf. procesdiagrammet Forældre-ungepålæg giver, underbilag 3.1C og KLblanket BU Der er udarbejdet en særlig DUBU-blanket til at illustrere datafangsten, både ved afgørelse om - og ved opfølgning på forældre- og ungepålæg, DUBU-blanket 3.b og DUBU-blanket 4., begge underbilag 3.1E. Desuden fremgår forældre- og ungepålæg i DUBU-blanket 20, underbilag 3.1E. Delproces vedrørende rådgivning og konsulentbistand 11 Jf. jf. underbilag 3.1M. F o r t r o l i g t S i d e 43/ d e c e m b e r

44 Delprocessen vedrører gratis tilbud til børn, unge, forældre og vordende forældre om familieorienteret rådgivning til løsning af vanskeligheder i familien (eventuel anonym rådgivning) samt tilbud om konsulentbistand. It-understøttelsen begrænser sig til at registrere rådgivning og konsulentbistand som et udfald af delproces vedrørende henvendelse og underretning samt oprettelsen af en sag med mulighed for, løbende at lægge journalarksnoter eller dokumenter på en sag. Oprettelsen af en sag forudsætter, at borgeren ikke har ønsket at være anonym, da der ikke er notatpligt ved denne type sager. Rådgivning og konsulentbistand som udfald er beskrevet i DUBU-blanket 1, underbilag 3.1E, og i procesdiagram Rådgiver borger om sociale problemer, underbilag 3.1C. Delproces vedrørende dækning af merudgifter Merudgifter er en kompenserende foranstaltning, der indeholder nødvendige merudgifter ved forsørgelse i hjemmet af et barn under 18 år, med betydelig og varigt nedsat fysisk eller psykisk funktionsevne eller indgribende kronisk eller langvarig lidelse, jf. Servicelovens 41. Tidligere analyser har peget på, at de vigtigste effektiviseringsmuligheder knyttes til administrative lettelser. Fx oprettes der i dag ofte parallelle papirsager og elektroniske sager, og der er megen genindtastning af data fx i forbindelse med udveksling af data mellem sagsbehandler og et lønkontor. Herudover peger de foretagne analyser på, at der i dag ikke sker en hensigtsmæssig registrering af afgørelser om ydelser med priser på området. Dette gør, at man i dag ikke kan trække Ledelsesinformation om samlede udgifter og udgifter til det enkelte barn på tværs af de forskellige lovgivningsmæssige områder og systemer. It-understøttelsen fokuserer på forholdsvis få sagsstyringsaktiviteter samt registrering af selve afgørelsen om indsats med pris og varighed. Hertil kommer en beregning af henholdsvis en månedlig merudgiftsydelse og beløb betalt efter regning, jf. Use Case 033 Foretag beregning, underbilag 3.1F, og KL-blanket BU Udregningen af merudgift kan understøttes ved, at de aktuelle satser for 41 er indlagt i Systemet. Delprocessen er illustreret i DUBU-blanket 6, underbilag 3.1E, og procesdiagram Behandler ansøgning om merudgifter efter Servicelovens 41, underbilag 3.1C. Delproces vedrørende tabt arbejdsfortjeneste Tabt arbejdsfortjeneste er en kompenserende foranstaltning, der indeholder hjælp til dækning af tabt arbejdsfortjeneste til personer, der i hjemmet forsørger et barn 12 Jf. jf. underbilag 3.1M. F o r t r o l i g t S i d e 44/ d e c e m b e r

45 under 18 år med betydelig og varig nedsat fysisk eller psykisk funktionsevne eller indgribende kronisk eller langvarig lidelse. Beskrivelsen af delprocessen og it-understøttelsen er i stort omfang identisk med ovenstående delproces vedrørende dækning af merudgifter. I forhold til beregning henvises til Use Case 033 Foretag beregning, underbilag 3.1F, og KL-blanket 925a 13. Delprocessen er illustreret i DUBU-blanket 7, underbilag 3.1E og procesdiagram Behandler ansøgning om tabt arbejdsfortjeneste efter Servicelovens 42, underbilag 3.1C. Delproces vedrørende samvær og kontakt I denne delproces tages der stilling til frekvens - og karakter af forbindelsen mellem barnet/den unge og forældre og andre i netværket efter Servicelovens 71. Denne type afgørelser er altid en følge af afgørelse om en anbringende foranstaltning. Derudover kan der tages stilling til brev og telefonkontrol efter 123, når barnet eller den unge er anbragt på en institution beregnet til døgnophold. Afgørelsen træffes af børne- og ungeudvalget om kontrol af barnets eller den unges brevveksling, telefonsamtaler og anden kommunikation med nærmere angivne personer uden for den institution, hvor barnet/den unge er anbragt. It-understøttelsen fokuserer på en række sagsstyringsaktiviteter primært vedrørende kommunikationen med sagens parter samt registrering af afgørelsen med pris og varighed. Delprocessen er illustreret i DUBU-blanket 10, underbilag 3.1E, samt procesdiagram Træffer afgørelse om samvær og kontakt, underbilag 3.1C. Delproces vedrørende særlige dag- og klubtilbud Delprocessen vedrører afgørelse om en specialiseret dagtilbudsindsats for børn og unge med nedsat fysisk funktionsevne. It-understøttelsen er igen fokuseret på ganske få sagsstyringsaktiviteter samt registrering af afgørelse med pris og varighed, jf. DUBU-blanket 8, underbilag 3.1E. Der er ikke lavet særlige procesdiagrammer til denne delproces. Delproces vedrørende undervisningsindsats Delprocessen vedrører afgørelse om undervisningsindsats enten i form af specialklasse i kommunen, specialundervisning på specialskoler (i kommunen), specialundervisning (i regionen) eller undervisning på opholdssted og lign. (interne skoler, heldagsskoler mv.). 13 Jf. jf. underbilag 3.1M. F o r t r o l i g t S i d e 45/ d e c e m b e r

46 Det særlige ved delprocessen er, at: Undervisningsindsatsen er meget vigtig i forhold til at sikre helhed i indsatsen og opfyldelse af målsætningen om bedre tværgående samarbejde. Der har traditionelt været problemer vedrørende koordinering mellem skole- og socialsektoren. Afgørelse og registrering af specialundervisningsindsatser foregår ofte i en anden afdeling eller forvaltning. Der er kommuner, der i varierende omfang er begyndt at arbejde med fælles visitationsudvalg i forhold til at træffe afgørelser på tværs af skole- og socialområdet. It-understøttelsen i Systemet er meget begrænset og omfatter kun registrering af afgørelse med pris og varighed. Afgrænsningen af den fremtidige systemunderstøttelse har fokuseret på, at det som minimum skal være muligt at sikre en tværgående projektøkonomi for barnet/den unge med angivelse af afgørelse om indsatser og dertil hørende priser. Dette skal både kunne sikre tværgående Ledelsesinformation og sagsinformation om det enkelte barn. Derimod skal særlige begreber for behov, ressourcer, effekter og lignende fra specialundervisningsområdet og pædagogisk psykologisk rådgivning ikke indarbejdes i Systemet. På denne baggrund er det konkret besluttet at sikre følgende systemunderstøttelse: Registrering af afgørelser om specialundervisning sker i Systemet med angivelse af indsats og økonomi på linje med øvrige indsatser, jf. DUBU-blanket 20, underbilag 3.1E. Det giver mulighed for at adskille og samle sager på tværs af de to forvaltningsområder efter både CPR-nummer og enkeltsager, alt efter behov i forhold til sagsbehandling og lovgivning, herunder krav om samtykke. Det giver ligeledes mulighed for at samle oplysninger om forbrug på tværs af forvaltninger som led i opfølgningen på indsatsen overfor det enkelte barn eller som baggrundsinformationer i forbindelse med fælles visitation på tværs af forvaltningerne. Samarbejdet med skolesektoren er derudover understøttet gennem en række sagsstyringsaktiviteter i såvel delproces vedrørende 50-undersøgelse, herunder indhentning af statusudtalelser, som delproces vedrørende visitation herunder sikring af, at barnets skoleforhold er på plads inden en anbringelse iværksættes. Delproces vedrørende undervisningsindsatsen er udelukkende beskrevet gennem DUBU-blanket 20, underbilag 3.1E. Herudover skal bemærkes, at registreringen af indstillinger og afgørelser kan følge den samme struktur som øvrige indsatser i DU- BU-blanket 3.a, underbilag 3.1E. F o r t r o l i g t S i d e 46/ d e c e m b e r

47 For en uddybende beskrivelse af denne delproces og sammenhængen til Systemet henvises til Afrapportering: indsatsområdet udsatte børn og unge, afsnit 2.1. og Delproces vedrørende lægebehandling med tvang Der er tale om en undersøgelse af barnet/den unge udført af læge - gennemført uden forældrenes samtykke, jf. Servicelovens 63. Denne type afgørelser træffes af børne- og ungeudvalget. It-understøttelsen fokuserer på enkelte sagsstyringsaktiviteter samt registrering af afgørelsen i udvalget og er illustreret i DUBU-blanket 13, underbilag 3.1E, og procesdiagram Træffer afgørelse om lægebehandling uden samtykke samt Børne- og ungeudvalget - Træffer afgørelse, begge underbilag 3.1C. Delproces vedrørende plan for forældre ved anbringelse Når et barn eller en ung anbringes, skal der træffes afgørelse om eventuel støtte til forældrene. Støtten skal beskrives i en særskilt plan for forældrene. It-understøttelsen fokuserer på enkelte sagsstyringsaktiviteter samt registrering af afgørelsen, og er illustreret i DUBU-blanket 9, underbilag 3.1E, og underbilag 3.1C DUBU Use Cases Kravene, der ligger til grund for Systemet, er centreret om en række arbejdsgange, og disse krav illustreres bedst og mest effektivt for Leverandøren via procesorienterede Use Cases end via rene kravskemaer. Use Cases, som er illustreret i underbilag 3.1F, udgør derfor en integreret del af kravene til Systemet. Der er i kravene henvist til de relevante Use Cases. Use Cases suppleres derudover af en række funktionelle krav, der dækker de områder, som de vedlagte Use Cases på nuværende tidspunkt ikke beskriver. Procesdiagrammerne, underbilag 3.1C, illustrerer grafisk, hvilken proces aktøren er i gang med, og DUBU-blanketterne, underbilag 3.1E, beskriver, hvilke felter aktøren har brug for i situationen. Use Cases er de byggeklodser, som procesdiagrammerne kan opbygges af. Sammenhængen mellem Use Cases og DUBU-blanketterne er illustreret i de enkelte Use Cases i underbilag 3.1F. Den samme Use Case kan bruges flere steder i delprocesserne, og felter fra DUBU-blanketterne kan bruges i flere Use Cases. Nogle Use Cases benytter sig af andre Use Cases. I de situationer, vil der i selve Use Casen være henvisning til den pågældende Use Case. 14 Jf. jf. underbilag 3.1M. F o r t r o l i g t S i d e 47/ d e c e m b e r

48 Nummereringen af Use Cases er tilfældig og hverken fortløbende, kronologisk eller på anden måde meningsbærende. Følgende diagram viser i form af en Use Case model en oversigt over alle Use Cases vedlagt Kravspecifikationen: Figur 9 Use Case model Leverandøren skal betragte opbygningen af de vedlagte Use Cases og de funktionelle krav som den samlede sum af funktionalitet i Systemet. Hvis Leverandøren har samme funktionalitet til rådighed, struktureret på en anden måde, kan dette præciseres i Løsningsbeskrivelsen. F o r t r o l i g t S i d e 48/ d e c e m b e r

49 Krav 9. Aktøren skal kunne oprette sager Beskrivelse: Systemet skal understøtte aktøren således, at der kan oprettes sager som beskrevet i Use Case 001 Opret Sag. Krav 10. Aktøren skal kunne oprette stam- og grundoplysninger om personer Beskrivelse: Systemet skal understøtte aktøren således, at der kan oprettes stam- og grundoplysninger om personer som beskrevet i Use Case 012 Opret stam- og grundoplysninger. Krav 11. Aktøren skal kunne foretage sagsbehandling til at understøtte modtagelser af underretninger og henvendelser Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan indhente og registrere informationer ved modtagelse af underretninger og henvendelser, som beskrevet i Use Case 015 Modtag underretning/henvendelse. Krav 12. Aktøren skal kunne foretage den indledende vurdering i forbindelse med underretning og henvendelse Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan registrere den indledende vurdering, som beskrevet i Use Case 017 Foretag vurdering og registrer beslutning/afgørelse. Krav 13. Aktøren skal kunne indhente samtykke Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan indhente og registrere samtykke, som beskrevet i Use Case 018 Indhent samtykke. F o r t r o l i g t S i d e 49/ d e c e m b e r

50 Krav 14. Aktøren skal kunne formidle en afgørelse til sagens parter Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan formidle en afgørelse til sagens parter, som beskrevet i Use Case 019 Formidl afgørelse. Krav 15. Aktøren skal kunne udarbejde handleplan Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan udarbejde en handleplan for barnet/den unge, som beskrevet i Use Case 021 Udarbejd handleplan. Krav 16. Aktøren skal kunne afgøre og registrere, hvorda forældre skal have samvær og kontakt med barnet/den unge Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan afgøre og registrere kontakt og samvær, som beskrevet i Use Case 022 Afgør kontakt og samvær. Krav 17. Aktøren skal kunne planlægge, afholde og registrere indholdet af børnesamtaler Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan planlægge, afholde og registrere indholdet af børnesamtalen, som beskrevet i Use Case 023 Hold børnesamtale. Krav 18. Aktøren skal kunne bestille en indsats Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan bestille den indsats, som er indeholdt i handleplanen for barnet/den unge, som beskrevet Use Case 024 Bestil indsats. F o r t r o l i g t S i d e 50/ d e c e m b e r

51 Krav 19. Aktøren skal kunne træffe afgørelse om indsats Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan træffe afgørelse om indsatser både med og uden samtykke, som beskrevet i Use Case 025 Afgørelse om indsats. Krav 20. Aktøren skal kunne udarbejde en indstilling Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan udarbejde en indstilling til forelæggelse for den, der har kompetencen til at visitere, både ved administrative beslutninger (normalforløbet) og ved beslutning i et politisk udvalg (personsagsudvalg og børn- og ungeudvalg) som beskrevet Use Case 026 Udarbejd indstilling. Krav 21. Aktøren skal kunne indhente og registrere holdninger og kommentarer fra sagens parter Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan indhente og registrere holdninger og kommentarer fra de parter som er involveret i sagen, som beskrevet Use Case 029 Indhent holdning og kommentarer fra parter. Krav 22. Aktøren skal kunne foretage en opfølgning på barnet/den unge Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan udføre og registrere en opfølgning på barnet/den unge, som beskrevet i Use Case 031 Foretag opfølgning. Krav 23. Aktøren skal kunne afslutte en sag Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan afslutte en sag, som beskrevet i Use Case 032 Afslut sag. F o r t r o l i g t S i d e 51/ d e c e m b e r

52 Krav 24. Aktøren skal kunne foretage beregninger af ydelser og udfylde bevillingsmeddelelser Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan foretage beregning af ydelser og udfylde bevillingsmeddelelser, som beskrevet i Use Case 033 Foretag beregning. Krav 25. Aktøren skal kunne forberede indsamling af oplysninger Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan forberede indsamling af oplysninger, som beskrevet i Use Case 034 Forbered indsamling af oplysninger. Krav 26. Aktøren skal kunne efterbehandle indsamlede oplysninger Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan efterbehandle indsamlede oplysninger, som beskrevet i Use Case 035 Efterbehandl indsamlede oplysninger. Krav 27. Aktøren skal kunne overflytte sagsinformation til anden kommune Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at aktøren kan overflytte sagsinformation til anden kommune, som beskrevet i Use Case 036 Overflytning af sagsinformation til anden kommune. Krav 28. Beskrivelse af Leverandørens Use Cases Kategori: Info Type: Beskrivelse: Såfremt Leverandøren har en anden struktur til Use Cases end den i Kravspecifikationen vedlagte, men mener at opfylde den ønskede funktionalitet, skal Leverandøren detaljeret beskrive den anden struktur på en sådan måde, at det fremgår tydeligt, at denne struktur alligevel opfylder kravene til funktionalitet i Systemet. F o r t r o l i g t S i d e 52/ d e c e m b e r

53 Leverandøren gøres opmærksom på, at antallet af Use Cases ikke er dækkende for det funktionelle omfang af Systemet, men alene beskriver de mest centrale arbejdsgange i Systemet DUBU Services Use Cases refererer i de enkelte trin til de serviceoperationer, der leverer den funktionalitet og de data, som skal anvendes i trinene, som illustreret i følgende udsnit af en Use Case: Normalforløb: Trin Aktør: System: Service operation: 1 Vælger Opret sag Åbner sagsvinduet og viser en tom sag 2 Indtaster og evt. redigerer relevant sagsinformati on 3 Vælger Gem sag Sluttilstand Hvis der er sagsinformation der automatisk kan overføres til sagen skal denne overføres og fremvises. Validerer den indtastede sagsinformation og opretter en ny sag, hvis der ikke findes valideringsfejl. Sagen er oprettet. Kan være en eller flere af: Afgørelse.Hent [ ] 50Undersøgelse.Hent [ ] Handleplan.Hent [ ] Person.Hent [ ] Sag.Hent [ ] Vurdering.Hent [ ] Indsats.AlternativHent [ ] Sag.Opret [ ] Journalarknote.Opret [ ] Figur 10 Eksempel på, hvordan Use Case kalder serviceoperation Disse serviceoperationer er angivet ved det forretningsbegreb de arbejder på, og dernæst hvilken funktionalitet (serviceoperationer) de kan levere. Listen over serviceoperationer udgør ikke den endelige mængde, men er blot medtaget som oplæg, hvorfor der ikke er specificeret input- og outputparametre for operationerne. Sammenhængen mellem Use Cases og serviceoperationer samt en liste over serviceoperationer fremgår af underbilag 3.1G. F o r t r o l i g t S i d e 53/ d e c e m b e r

54 5. Det komponentopdelte System 5.1. Sagsstyringskomponenten Sagsstyringskomponenten er en del af grundfunktionaliteten (Fase 1). Sagsstyringskomponenten er en central komponent i Systemet, som har ansvaret for at afvikle arbejdsgange, hvilket blandt andet involverer de andre komponenter. Sagsstyringskomponenten skal guide sagsbehandleren igennem aktiviteter i et sagsforløb og på den måde sikre, at de krav der følger af lovgivningen, kommunens sagsbehandlingsstandarder og lokal praksis i øvrigt overholdes. Et sagsforløb omfatter typisk frister, kvitteringer, orienteringer, samtaler mv. Sagsstyringskomponenten skal kunne: Give sagsbehandleren og lederen et fremadrettet og visuelt overblik over eksisterende sager og aktiviteter med markering af, hvor meget de haster. Understøtte fordeling af sager, fx ved barsel eller sygdom. Give adviser til sagsbehandleren, når frister er overskredet eller er tæt på at blive det. Give sagsbehandleren og lederen oversigt over eksisterende indsatser. Krav 29. Sagsbehandleren skal procesunderstøttes Kategori: Minimumskrav Type: Funktionelt Beskrivelse: Sagsstyringskomponenten skal kombinere proces og aktivitetsunderstøttelse, så Systemet aktivt hjælper sagsbehandleren igennem, påminder om og skaber overblik over aktiviteter i processerne, og på den måde sikrer, at de krav der følger af lovgivningen og kommunens sagsbehandlingsstandarder, overholdes. Sagsstyringen er primært rettet mod sagsbehandlerens egne aktiviteter, men kan også være rettet mod andres aktiviteter. Det betyder fx, at Systemet skal hjælpe sagsbehandleren med at holde styr på undersøgelser og statusudtalelser fra andre fagpersoner. Forsinkelser her kan få store konsekvenser for den samlede sagsbehandlingstid. Ud fra en betragtning om, at procesreglerne på området er komplicerede, og at det derfor er vigtigt at skabe det fornødne overblik over aktiviteterne er det vigtigt, at have en Sagsstyringskomponent, der er fleksibel. Fleksibilitet er vigtig, fordi der er variation mellem processen i de forskellige sager og i de forskellige kommuner. Fx benytter nogle kommuner familien som udgangspunkt for sagsbehandlingen, mens andre går ud fra barnet. Fleksibilitet skal blandt andet sikres på følgende måde: Ofte er det nok at sikre, at aktiviteter gennemføres på et tidspunkt i løbet af en delproces, mens der ikke er grund til at sikre, om det sker i en bestemt rækkefølge. F o r t r o l i g t S i d e 54/ d e c e m b e r

55 Hver delproces har flere udfaldsmuligheder, og der er altid mulighed for at gå tilbage og gentage tidligere delprocesser. En henvendelse eller underretning behøver fx ikke at munde ud i en undersøgelse, den kan også ende i en rådgivningssag eller afsluttes. Systemet giver mulighed for lokal opsætning af aktiviteter med frister. Det betyder fx, at hvis en kommune har et lokalt krav om, at der skal laves et underretningsmøde senest 2 dage efter en underretning kan det tilføjes Systemets checkliste over aktiviteter med en frist. En sagsbehandler kan have behov for at handle hurtigt. Sagsstyringskomponenten må derfor ikke stå i vejen for, at sagsbehandleren i akutte situationer handler på det foreliggende grundlag og efterfølgende foretager den endelige dokumentation. Men Systemet bør være opbygget, så dokumentationen i videst mulige omfang integreres i arbejdet. Når en sagsbehandler har registreret, at en aktivitet (fx børnesamtale) er gennemført, skal informationen automatisk overføres til: Ledelsesinformation. Overbliksbillede til sagsbehandler og leder. Journalark. Ankestyrelsens statistik. Dette for at undgå, at den samme sagsinformation ikke skal skrives flere gange. Herved understøtter Systemet målsætningen om at spare tid på administrative sagsgange. Sagsstyringskomponenten skal sikre, at hvis sagsbehandleren registrerer en beslutning om at gå videre fra fx delprocessen vedrørende henvendelse eller underretning til delprocessen vedrørende 50-undersøgelse, skal den næste delproces automatisk startes op. Dette gælder ved overgang mellem alle delprocesser. Samtidig skal Systemet automatisk registrere, at en ny undersøgelsessag er startet. Alle dokumenter og noter i delprocessen vedrørende 50-undersøgelse tildeles automatisk et journalnummer efter KL s emneplan 15. Herved opnås flere fordele: Sagsbehandlerens journaliseringsbyrde lettes. Det bliver muligt at holde sagens forskellige akter ud fra hinanden, fx i forbindelse med aktindsigtssager eller klagesager. Der kan laves en standardrapport vedr. sagsbelastning der viser, hvor mange undersøgelsessager, visitationssager, opfølgningssager etc. man har haft. Det giver et mere reelt billede af belastningen end oversigter over familiesager Prioritering og håndtering af flere sager En sagsbehandler eller en sagsfordeler skal kunne danne sig overblik over - og prioritere de sager, den enkelte sagsbehandler eller hele kontoret/afdelingen er an Emnesystematik/, jf. underbilag 3.1M. F o r t r o l i g t S i d e 55/ d e c e m b e r

56 svarlig for. Derudover skal en sagsfordeler kunne fordele sagerne dvs. definere, hvem der er den ansvarlige sagsbehandler for en given sag. Nedenfor præsenteres et skærmbillede centralskærmbilledet som eksempel på, hvordan Systemet kan understøtte sagsbehandleren i at få overblik over og prioritere egne sager: Familiens sager Figur 11 Eksempel på centralskærmbillede, der viser sagsoverblik Sagsbehandleren eller en sagsfordelerrolle skal kunne danne sig et overblik over status, og hvor mange dage der er til en frist eller hvor mange dage en frist er overskredet for henholdsvis egne, kontorets og afdelingens sager. Sagsbehandleren eller en sagsfordelerrolle skal desuden kunne søge og sortere i centralskærmbilledet. Krav 30. Centralskærmbillede til overblik og prioritering Beskrivelse: Med henblik på at understøtte sagsbehandleren eller sagsfordeleren i at overskue og prioritere sit arbejde, skal sagsbehandleren og sagsfordeleren ved aktivering af Systemet præsenteres for et centralskærmbillede, der indeholder et sagsoverblik. F o r t r o l i g t S i d e 56/ d e c e m b e r

57 Krav 31. Visning af sagsinformation Beskrivelse: Listevisningerne i centralskærmbilledet skal som minimum indeholde: Indikation af, om sagen er en hastesag, kritisk sag eller normal sag. Barnets/den unges CPR-nummer. Barnets/den unges navn. Forældremyndighedsindehaver(er)s CPR-nummer. Igangværende delproces. Frist for delproces. Aktivitetens navn. Frist for aktivitet. Indsats. Det skal være muligt at sortere efter sagsbehandlerens sager, kontoret/afdelingens sager, kommunens sager og familiens sager. Dertil skal listerne ved visning af kontorets/ afdelingens sager vise initialerne på den ansvarlige sagsbehandler. Sagsbehandler-aktøren Kravene i dette afsnit relaterer sig til, hvordan sagsbehandleren skal kunne agere i Systemet. Udover de nævnte krav er der også en række Use Cases præsenteret i underbilag 3.1F. Krav 32. Sagsbehandler kan arbejde i flere forløb Beskrivelse: Systemet skal understøtte, at en sagsbehandler kan arbejde i flere parallelle forløb i en delproces, og at en sagsbehandler/systemet kan samle parallelle forløb. Dette er ensbetydende med, at der skal kunne eksistere to eller flere samtidigt aktive aktiviteter på en delproces. Det skal dermed være muligt, at have flere versioner af arbejdsgange og processer åbne parallelt. Krav 33. Sagsbehandler kan vælge efterfølgende aktivitet F o r t r o l i g t S i d e 57/ d e c e m b e r

58 Beskrivelse: Hvis Systemet ikke automatisk kan afgøre, hvilken aktivitet, der følger den aktuelle aktivitet, skal sagsbehandleren kunne vælge den efterfølgende aktivitet. Krav 34. Sagsbehandler beslutter at opstarte en delproces Beskrivelse: Hvis en sagsbehandler har afsluttet en delproces med beslutning om at opstarte en af de øvrige delprocesser, skal Systemet automatisk aktivere denne delproces. Krav 35. Sagsbehandler kan begynde sagsbehandling med en vilkårlig delproces Beskrivelse: Systemet skal understøtte sagsbehandleren i, at kunne påbegynde sagsbehandlingen med en vilkårlig delproces, uafhængigt af den ideale rækkefølge i sagsstyringsprocessen herunder for eksempel: Genstarte en tidligere delproces med en ny version af delprocessen og dets produkter. Dette selvom delprocessen allerede er helt eller delvis gennemløbet Påbegynde udarbejdelsen af en handleplan og evaluering før de aktiviteter, der går forud for procesforløbene Visitation, jf. afnit og Indsats og opfølgning, jf. afsnit er afsluttet. Undtaget herfra er muligheden for at påbegynde en 50- undersøgelse, jf. afsnit før delprocessen Underretning eller henvendelse, jf. afsnit er afsluttet med en beslutning om initiering af en 50-undersøgelse. Krav 36. Beskrivelse af, hvordan sagsbehandleren kan håndtere undtagelser i forhold til den normale delproces Kategori: Info Type: Beskrivelse: Leverandøren skal redegøre for, hvordan det sikres, at Systemet kan håndtere sagsbehandlingsmæssige undtagelser i relation til den normale administrative delproces. F o r t r o l i g t S i d e 58/ d e c e m b e r

59 Krav 37. Sagsbehandler vælger visning af sagens historik og detaljeringsgrad Beskrivelse: Systemet skal understøtte sagsbehandleren i, at kunne vælge om vedkommende ønsker at få præsenteret visningen af sagshistorikken fordelt på aktiviteter, fordelt på delprocesser eller (kun for projektsager) fordelt på enkeltsager. Sagsbehandleren skal endvidere kunne folde historikkens detaljeringsgrad ud og ind, med henblik på bedre overblik. Krav 38. Sagsbehandler igangsætter en 50-undersøgelse Beskrivelse: Såfremt sagsbehandleren registrerer, at der skal igangsættes en 50-undersøgelse for et andet barn/en ung i familien, skal Systemet herefter automatisk starte en ny Henvendelses- /underretnings- sag op på det (de) pågældende barn (børn)/de(n) pågældende unge. Krav 39. Sagsbehandler viderefører indhold af sag til en ny sag Beskrivelse: Systemet skal understøtte, at sagsbehandleren skal kunne videreføre allerede registreret indhold fra en sag til ny sag indenfor samme familie, fx indhold registreret under ICS trekantens sider i en afsluttet 50-undersøgelse til en ny version af denne, handleplan og/eller opfølgning. Krav 40. Beskrivelse af, hvordan sagsbehandler genbruger udvalgte informationer Kategori: Info Type: Beskrivelse: Leverandøren skal redegøre for, hvordan det kan sikres, at en sagsbehandler har mulighed for at genbruge udvalgte elementer indenfor samme familie i fx 50-undersøgelse, handleplan og/eller enslydende breve til et antal berørte parter. F o r t r o l i g t S i d e 59/ d e c e m b e r

60 Krav 41. Sagsbehandler kan overdrage sag til anden sagsbehandler Beskrivelse: Systemet skal understøtte sagsbehandleren i, at kunne registrere en anden sagsbehandler til opfølgning på sagen. Systemet skal i så fald sende advis til denne. Krav 42. Sagsbehandleren skriver noter, tilføjer dokumenter og påfører advis-tidspunkter Beskrivelse: Sagsbehandleren skal kunne skrive en note, tilføje et dokument samt påføre et advis-tidspunkt. Krav 43. Sagsbehandler sætter sag til at afvente modtagelse af dokumenter Beskrivelse: Sagsbehandleren skal, i samspil med Systemet, kunne sætte sager, i form af en aktivitet, til at afvente, at nye dokumenter kommer ind på sagen enten af sagsbehandleren eller automatisk af Systemet. Systemet skal kunne registrere, hvis en sagsbehandler afventer et dokument til en sag og understøtte, at det fremgår tydeligt af skærmbilledet, når der indkommer et dokument på sagen. Krav 44. Sagsbehandler kan se lovpligtige aktiviteter Beskrivelse: Systemet skal synliggøre for sagsbehandleren, hvorvidt en aktivitet er lovpligtig at udføre samt hvorvidt en tidsfrist er fastsat ved lov (se afsnit 7.2 for yderligere informationer omkring sikring af lovmedholdighed). Krav 45. Sagsbehandler kan markere sager som hastesager eller kritiske F o r t r o l i g t S i d e 60/ d e c e m b e r

61 Beskrivelse: En sagsbehandler skal kunne markere, om en sag er en hastesag eller en kritisk sag (eventuelt med en modificering af fristdato). Krav 46. Sagsbehandler kan få et overblik over tidligere indsatser Beskrivelse: En sagsbehandler skal kunne få et overblik over eventuelle tidligere indsatser overfor barnet/den unge eller andre i familien. Sagsfordeler aktøren Kravene i dette afsnit relaterer sig til, hvordan sagsfordeleren skal kunne agere i Systemet. Krav 47. Sagsfordeler danner sig et overblik Beskrivelse: Systemet skal gøre det muligt for sagsfordeleren, at danne sig et overblik over afdelingens/kontorets aktiviteter og herfra fordele sager. Det kan eksempelvis være under Afdelingens sager/kontorets sager i centralskærmbilledet. Krav 48. Sagsfordeler fordeler sager Beskrivelse: Systemet skal kunne understøtte en sagsfordeler i at fordele sager, der endnu ikke har en ansvarlig sagsbehandler tilknyttet. Det indbefatter: At en modtaget henvendelse eller underretning fremgår af en oversigt. At Systemet skal foreslå sagsfordeleren én eller flere sagsbehandlere, hvis disse allerede har eller har haft sager på samme CPR-nr. At Systemet skal understøtte sagsfordeleren i at fordele sager efter parametre som fx fordeling ud fra et CPR-nr. interval. At Systemet skal kunne præsentere en sagsfordeler for et sammenligneligt overblik over antallet af åbne sager tildelt sagsbehandlerne i afdelingen. F o r t r o l i g t S i d e 61/ d e c e m b e r

62 Krav 49. Sagsfordeler ændrer sagsbehandler på en sag Beskrivelse: Det skal være muligt for en sagsfordeler at ændre, hvilken sagsbehandler der er ansvarlig for en sag i tilfælde af fx sygdom, barsel, opsigelse. Krav 50. Sagsfordeler massefordeler sager til en sagsbehandler Beskrivelse: Det skal være muligt for en sagsfordelerrolle, at foretage massefordeling af flere sager til en sagsbehandler Administration af Sagsstyringskomponenten Systemet er en central løsning, der skal dække alle tilsluttede kommuners behov, således at lovens krav som et minimum kan opfyldes. Der er dog administrative forskelle kommunerne imellem, og det er derfor vigtigt for Systemets modtagelse og succes i kommunerne, at anvendelsen af Sagsstyringskomponenten kan tilpasses lokalt, så det afspejler den enkelte kommunes administrationspraksis. Det skal dog understreges, at lokale tilpasninger stadig skal understøtte de lovgivningsmæssige krav. I Systemet arbejdes der derfor med 2 typer af administratorer; en central administrator og et antal kommunale administratorer. Den centrale administrator varetager central opsætning af blandt andet centrale lovgivningsbestemte processer og den kommunale administrator varetager kommunale opsætninger/tilpasninger, der dog stadig skal opfylde lovens krav. Denne arbejdsfordeling skitseres i følgende figur: Figur 12 Rollefordeling mellem central og kommunal administrator F o r t r o l i g t S i d e 62/ d e c e m b e r

63 Krav 51. Central administrator skal kunne foretage systemvedligeholdelse Beskrivelse: Systemet skal understøtte, at en central administrator med krævede rettigheder kan foretage relevant systemvedligeholdelse. Krav 52. Kommunal administrator skal kunne definere fordelingsmønstre Beskrivelse: Det skal, fra administrationsklienten, være muligt for en kommunal administrator at parameteropsætte, om der skal anvendes fordelingsmønster, som fx kan være CPR-nr., interval, postnummer/distriktsinddeling, KLE-systematik eller organisatoriske parametre. Krav 53. Kommunal administrator skal kunne korrigere proces- og brugerfejl Beskrivelse: En kommunal administrator skal kunne rette op på procesfejl begået af en aktør. Med procesfejl menes fx hvis en aktør har sendt en sag til en forkert aktivitet, er kommet til at afslutte en aktivitet for tidligt, har registreret et forkert dokument i forbindelse med en aktivitet eller har afsluttet en delproces ved en fejl. Krav 54. Administrator skal kunne tilpasse elementer i delprocesserne Beskrivelse: En administrator, central og kommunal, kan tilpasse følgende elementer i delprocesserne: Ændre på indstillinger og regler for hovedproces. Ændre på indstillinger og regler for delproces. Oprette og opsætte delproces. Fjerne og tilføje aktiviteter. Ændre på indstillinger for aktiviteter. Knytte aktiviteter til en eller flere aktiviteter. F o r t r o l i g t S i d e 63/ d e c e m b e r

64 Krav 55. Administrator kan danne et overblik over elementernes sammenhæng Beskrivelse: Den centrale og kommunale administrator skal, via administrationsklienten, kunne danne sig et overblik over projektsager, delprocesser, aktiviteter etc. og deres indbyrdes sammenhæng. Krav 56. Opdeling i centrale og lokale processer og aktiviteter Beskrivelse: I Systemet skal der opereres med en proces-/aktivitetstabel, der skal indeholde to typer processer/aktiviteter for sagsbehandlingen: Centrale lovgivningsbestemte processer. Lokale kommunale processer. Krav 57. Beskrivelse af tilpasning af kommunale aktiviteter Kategori: Info Type: Beskrivelse: Leverandøren skal redegøre for, hvordan en kommunal administrator kan tilføje egne aktiviteter, som kan supplere de centralt definerede aktiviteter. Krav 58. Omfanget af indstillinger for processer og aktiviteter Kategori: Krav Type: Ikke funktionelt Beskrivelse: Leverandøren skal sikre de nødvendige indstillinger for processer og aktiviteter bl.a.: Opsætning af, om de er valgfrie eller obligatoriske at udføre for sagsbehandleren. Opsætning af tidsfrister. Opsætning af rettigheder. Krav 59. Kommunale opsætninger skal respekteres af central opdatering Kategori: Krav Type: Ikke funktionelt Beskrivelse: Leverandøren skal sikre, at den centrale opdatering ikke overskriver kommunespecifikke fastsatte parametre i Systemet. F o r t r o l i g t S i d e 64/ d e c e m b e r

65 Krav 60. Beskrivelse af central og kommunal administration Kategori: Info Type: Beskrivelse: Leverandøren skal redegøre for designstrategi i forhold til, hvordan central og kommunal administration af Systemet kan tilrettelægges i et miljø, hvor en rolle forestår central vedligeholdelse og en anden rolle vedligeholder kommunespecifikke data. Herunder skal Leverandøren fremkomme med forslag til den optimale model for opdatering af Systemet og skitsere fordele og ulemper, samt redegøre for: Forskelle på, hvad den centrale og den kommunale administrator kan foretage sig. Hvordan delprocesser kan udvikles og tilpasses og af hvem. Hvilken funktionalitet, der vil blive leveret til brug for administratorerne. Hensynet til dokumentation i forbindelse med korrektion af procesfejl Workflow understøttelse Workflow understøttelsen er en væsentlig mekanisme i Sagsstyringskomponenten, som anvendes til understøttelse af de sagsgange, der afvikles i Systemet og som benyttes til at understøtte: Sammensatte løsninger (microflow). Længerevarende processer (macroflow). En elementær håndtering af hændelser. Krav 61. Aktør har fleksibilitet i valg af aktiviteter Beskrivelse: Det skal være muligt for en aktør, at gennemføre en aktivitet i et workflow på et ikke-planlagt tidspunkt, så længe den blive gennemført som en del af den korrekte delproces. Aktiviteter i hver delproces skal altså ikke nødvendigvis foregå i en bestemt rækkefølge. Workflow - sammensatte løsninger (microflow) Sammensatte løsninger understøtter korte processer (microflow), der typisk kan involvere en aktør og én eller flere services i en transaktion. Sammensatte løsninger kan aggregere, sammensætte, transformere og filtrere informationer fra flere services til brug for en specifik arbejdssituation. F o r t r o l i g t S i d e 65/ d e c e m b e r

66 Krav 62. Microflow Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal understøtte korte transaktionsorienterede processer (microflow), der er kendetegnet ved at involvere én aktør og én eller flere services. Krav 63. Processer udstilles som services Kategori: Krav Type: Ikke funktionelt Beskrivelse: Processer skal kunne udstilles som services, således at disse kan initieres, kontrolleres, og interageres via andre services. Processer skal fremvises således, at der på ethvert tidspunkt kan skabes overblik over, hvilke processer der er tilgængelige. Krav 64. Tilpasse og sammensætte services Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal kunne sammensætte, aggregere, transformere og filtrere informationer fra flere services og udstille disse til brug i specifikke arbejdssituationer. Krav 65. Microflow har en samlet dynamisk kontekst Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal understøtte, at et helt microflow har en samlet dynamisk kontekst, der som minimum kan: 1. Håndtere formidling af kontekst til og fra servicekald. 2. Håndtere flow/transformation af data mellem services. 3. Håndtere fejl og afvigelser, fx kompenserende transaktioner. Krav 66. Beskrivelse af kontekstsammenhænge Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvorledes kontekst integreres på tværs af Systemets forskellige lag, fx mellem workflowmekanismen, GUI og services. F o r t r o l i g t S i d e 66/ d e c e m b e r

67 Workflow længerevarende processer (macroflow) Workflow understøtter længerevarende processer (macroflow), der typisk involverer flere aktører samt eksterne og interne services. Krav 67. Macroflow Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal understøtte længerevarende processer (macroflow), der er kendetegnet ved at involvere flere aktører, systemer og services. Krav 68. Tilpasning af workflow-parametre Kategori: Krav Type: Ikke funktionelt Beskrivelse: Workflow-parametre som fx deadlines, eskaleringsregler mv. skal kunne konfigureres af den centrale og kommunale administrator. Krav 69. Beskrivelse af workflow muligheder Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvordan det tilbudte System understøtter følgende: Definition af start og slut for en proces. Beslutninger, der har indflydelse på proces. Opsætning af rækkefølge af aktiviteter i proces. Forgrening i parallelle processer. Sammenføjning af parallelle processer. Abonnement på hændelser (afvent hændelse). Definition af aktiviteter, der kan genbruges. Definition af delproces, der kan genbruges. Definition af manuelle og automatiske operationer i aktiviteter. Definition af procesroller i relation til proces. Regelbaseret fordeling af ansvar (procesrolle) for en specifik procesinstans. Opsætning af tidsfrister for aktiviteter og delproces. Kompenserende transaktioner. Behandling af undtagelsessituationer. Håndtering af hændelser Hændelseshåndtering understøtter publicering af - og abonnement på hændelser. Håndteringen består i at modtage hændelser og på baggrund af aftaleinformation F o r t r o l i g t S i d e 67/ d e c e m b e r

68 sikre, at disse når interessenterne. Interessenter vil typisk være personer eller procesinstanser (eventuelt procestrin). Krav 70. Håndtering af hændelser Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal indeholde funktionalitet til at publicere og håndtere hændelser og således understøtte et mere løst koblet samarbejde: Et procestrin skal kunne defineres til at agere på en specifik hændelse eller en specifik type af hændelser. Et procestrin skal kunne publicere en hændelse, fx skal et procestrin defineres til, at aktivere en specifik hændelse. Krav 71. Publicering/abonnement og advisering Kategori: Krav Type: Ikke funktionelt Beskrivelse: Hændelseshåndtering skal omfatte et publicerings/abonnementssystem, hvor services kan udveksle hændelser dynamisk, og hvor aktøren adviseres. Hændelseshåndtering skal understøtte, at aktøren bliver adviseret om hændelser via kommunens system. Indholdet i s skal være i anonymiseret form. Krav 72. Beskrivelse af hændelsestyper Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvilke hændelsestyper der kan håndteres, fx procestilstandsændringer, objektændringer (oprettet, ændret, slettet), fejl-afvigelser samt sammensatte og betingede hændelsestyper Procesmodulet Procesmodulet er den del af Sagsstyringskomponenten, der kan håndtere at afvikle workflows. Krav 73. Sagsstyringskomponenten indeholder procesmodul Kategori: Krav Type: Ikke funktionelt Beskrivelse: Sagsstyringskomponenten skal indeholde et procesmodul, hvor workflows kan opsættes og afvikles. F o r t r o l i g t S i d e 68/ d e c e m b e r

69 Krav 74. Beskrivelse af procesmodulets arkitektur og teknologier Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive procesmodulets arkitektur og teknologier. Beskrivelsen skal som minimum omfatte: Overordnet arkitekturbeskrivelse. Komponentbeskrivelser. Snitfladebeskrivelser. Beskrivelse af anvendte standarder, herunder i hvilket omfang BPMN, BPEL og BPEL4WS overholdes. Hvordan aktører aktiveres i en proces, herunder metode for notifikation af aktøren og interaktion mellem aktøren og proces. Procesmodulets brugerfaciliteter samt hvilke værktøjer der kan anvendes. Krav 75. Sagsbehandler kan se tilstanden af en proces Beskrivelse: Det skal være muligt for en sagsbehandler, til enhver tid at se tilstanden af de processer som afvikles. Systemet skal med en grafisk fremvisning af en delproces/sagsgang visualisere, i hvilken delproces sagsbehandleren befinder sig, når vedkommende åbner en given aktivitet. Dette indbefatter at synliggøre, hvilke aktiviteter der er gået forud for den aktuelle aktivitet, og hvilke der er forestående, samt hvilke aktiviteter, der kan udføres Frister og adviser Systemet skal styre, at frister i forbindelse med sagsbehandlingens delprocesser og aktiviteter overholdes hensigtsmæssigt. Derfor skal Systemet anvende en fristautomat, som styrer relevante frister. Der skal skelnes mellem lovgivningsbestemte frister og lokale kommunale frister. Der skal kunne opstilles en lokal kommunal fristregel, som skærper eller udvider en lovgivningsbestemt minimum- eller maksimumfrist, men kun i tilfælde af, at det er til fordel for borgeren og ikke indskrænker dennes rettigheder. Fx har lovgivningen en frist for kvittering på 6 dage, som kommunen ønsker skærpet, så sagsbehandleren afsender kvittering indenfor 4 dage. Under frister optræder også påmindelses-, advis- og videregivelses- eller eskalationsfrister. Fx skal Systemet kunne videregive/eskalere en aktivitet, hvis aktiviteten nærmer sig sin frist eller hvis den delproces, som aktiviteten er en del af, nærmer sig sin frist. F o r t r o l i g t S i d e 69/ d e c e m b e r

70 I skærmbilledet herunder vises et eksempel på, hvordan den kommunale administrator kan justere lokale kommunale frister i forhold til kommunens standarder: Figur 13. Justering af lokale kommunale frister Krav 76. Sagsbehandler understøttes af friststyring Beskrivelse: Systemet skal understøtte friststyring af sagsbehandlingen. Friststyringen skal indeholde tre typer frister for sagsbehandlingen: Nationale lovgivningsbestemte frister. Lokale kommunale fristregler. Lokale kommunale frister for påmindelse, advis og videregivelse/eskalation. På den enkelte frist skal det være muligt for aktøren at se, om fristen er lovgivningsbestemt eller lokalt opsat. Krav 77. Administrator kan vedligeholde tidsfrister F o r t r o l i g t S i d e 70/ d e c e m b e r

71 Beskrivelse: Systemet skal understøtte, at en administrator kan fastsætte, ændre og deaktivere tidsfrister (dage og timer), samt frister for påmindelser, advis og videregivelse/eskalation for delprocesser og aktiviteter på en sådan måde at: Central administrator vedligeholder lovgivningsbestemte frister. Kommunal administrator kan vedligeholde ikkelovgivningsbestemte frister samt skærpe eller udvide en lovgivningsbestemt minimum- eller maksimumfrist. Kommunal administrator kan fastsætte frister for påmindelse, advis og videregivelse/eskalation samt niveauet for frister (hvor mange frister der er nødvendige). Den kommunale administrator er begrænset af, at fristvedligeholdelsen er til fordel for borgeren, og ikke indskrænker dennes rettigheder. Krav 78. Opsætning af frister for behandling af dokumenter Beskrivelse: For dokumenttyper, skal der kunne opsættes centrale eller kommunale regler. Fx hvis en sagsbehandler overskrider fristen for, hvornår vedkommende skal have læst et dokument, hvortil der er tilknyttet en frist, skal Systemet fx kunne: Eskalere (videregive) dokumentet. Afsende en mail til den ansvarlige sagsbehandler og en eventuel sagspart eller anden rolle. Advisere den ansvarlige sagsbehandler, når vedkommende logger på Systemet. Krav 79. Automatisk generering af adviser Beskrivelse: Systemet skal automatisk generere adviser til aktører i minimum følgende situationer: For at understøtte sagsbehandleren i at overholde fristen for gennemførelse af 50-undersøgelsen. For at minde en sagsbehandler om bevillingens ophør. Når en sagsbehandler overdrager en sag til en anden sagsbehandler til opfølgning af sagen. Når en sagsfordelerrolle har visiteret et dokument til en sag, skal den ansvarlige sagsbehandler for sagen adviseres. I advisen skal der være et direkte link til et skærmbil- F o r t r o l i g t S i d e 71/ d e c e m b e r

72 lede, der giver sagsbehandleren adgang til at åbne og behandle dokumentet, herunder markere dokumentet som læst. Når en aktivitet, eller den delproces som aktiviteten er en del af nærmer sig sin frist, skal aktiviteten kunne eskaleres. Hvor mange dage og timer før en aktivitet skal eskalere, skal den kommunale administrator kunne definere. Såfremt indbudte ikke overholder svarfristen. Senest den tidligere registrerede opfølgningsdato, for at iværksætte en opfølgning på barnets/den unges sag. Krav 80. Administrator kan udskrive oversigt med alle lovgivningsbestemte frister Beskrivelse: Den centrale eller kommunale administrator kan udskrive oversigt med alle lovgivningsbestemte frister. Denne skal bruges med henblik på opsætning af lokale kommunale frister, samt frister for påmindelse, advis og videregivelse/eskalation. Krav 81. Beskrivelse af visualisering af fristoverskridelser Kategori: Info Type: Beskrivelse: Leverandøren skal redegøre for, hvordan Systemet kan tilrettelægges så det visualiseres, hvilke sager der har overskredet eller er i fare for at overskride en frist, hvem der er ansvarlig for en sag og hvornår den givne frist er overskredet Spørgsmålsadministration I forbindelse med indberetning af statistikdata til Ledelsesinformationer, Ankestyrelsen og Danmarks Statistik samt opsamling af erfaringsdata skal sagsbehandleren besvare en række spørgsmål undervejs i sagsbehandlingen. En administrator (kommunal og central) skal i denne forbindelse kunne opstille spørgsmål og koble dem til en aktivitet, fx i forbindelse med evalueringen i delprocessen vedrørende indsats og opfølgning. Spørgsmålene der skal opstilles, knytter sig til forskellige perioder, faser, delprocesser og aktiviteter, hvor det falder naturligt at samle oplysningen op fra den tilrettelagte og gennemførte sagsbehandling. Det skal ligeledes være muligt at identificere et punkt, hvor dataindsamlingen skal gentages og hvor oplysningen valideres for sin aktualitet og eventuelt ajourføres. F o r t r o l i g t S i d e 72/ d e c e m b e r

73 Krav 82. Administrator kan opsætte evaluerings- og statistikspørgsmål Beskrivelse: Systemet skal understøtte, at en central og kommunal administrator via en administrationsklient kan tilføje, ændre og deaktivere evaluerings- og statistikspørgsmål herunder: Om spørgsmålet er lovgivningsbestemt eller lokalt relevant. Tilhørende forældelsesfrister for revision af besvarelser af spørgsmål. Krav 83. Central administrator kan opsætte svarmetoder Beskrivelse: Systemet skal understøtte, at en central administrator kan tilføje, ændre og deaktivere svarmetoder (fx radioknapper, multiple choice, faste svarmuligheder til afkrydsning, afkrydsning på en skala, indtastning af et tal, indtastning af en tekst) Krav 84. Central administrator kan opsætte udfaldsrum Beskrivelse: Systemet skal understøtte, at en central administrator kan tilføje, ændre og deaktivere svarudfaldsrum (fx Ja/Nej, Opfyldelsesgrad med Ikke opfyldt, Opfyldt i nogen grad, Opfyldt i høj grad, Passer meget godt, Passer godt, Passer ikke, Passer slet ikke, Ikke relevant ) Krav 85. Administrator kan opsætte tidspunkt for adspørgelse F o r t r o l i g t S i d e 73/ d e c e m b e r

74 Beskrivelse: Systemet skal understøtte, at en central og kommunal administrator kan tilføje, ændre og deaktivere tidspunkt for adspørgelse, herunder Hvornår et spørgsmål skal stilles (til hvilken proces eller aktivitet). I hvilke situationer et spørgsmål skal stilles (fx i forbindelse med sagsbehandling af en bestemt aldersgruppe, i forbindelse med et barn af forældre under 18 år eller i forbindelse med et barn uden biologiske forældre i Danmark etc.). Om et spørgsmål skal gentages ved en bestemt hændelse, efter en bestemt periode eller ved en bestemt kombination af grunddata (fx alder og svar) Familieadministrationskomponent Familieadministrationskomponenten er en del af grundfunktionaliteten (Fase 1) med undtagelse af Krav 93 der, som option, skal håndteres samtidig med ESDHintegrationen beskrevet i afsnit Systemet skal indeholde en Familieadministrationskomponent, hvor stam- og grundoplysninger om barnet/den unge, familie og netværk registreres. De basale oplysninger om husstanden og familierelationer hentes fra en CPR-datakilde, men sagsbehandleren har mulighed for yderligere registreringer af fx netværk og professionelle kontakter, jf. DUBU-blanket 19, underbilag 3.1E. Formålet med komponenten er, i stort omfang at skabe lette og smidige administrative arbejdsgange for sagsbehandleren. Sagsbehandleren skal bruge komponenten til opslag af fx telefonnumre samt til visning af almene oplysninger. Familieadministrationskomponenten sikrer også, at der er data til rådighed til hent af navn og adresse til et dokument eller en blanket. Familieadministrationskomponenten har imidlertid også en rolle i forhold til Systemets mål om kvalitet i sagsbehandlingsproces og indhold. Et godt overblik over familie og netværk bidrager til, at undersøgelse og handleplan kan udarbejdes med bedst mulig inddragelse af barnets omgivelser, i både proces og løsningsforslag. For yderligere at understøtte dette formål, er der beskrevet en mulighed for at danne familiebilleder i form af genogrammer o.l., der kan anvendes til at skabe et mere visuelt overblik over barnets relationer i forbindelse med sagsbehandlingen. Denne mulighed er medtaget som option. Mange kommuner er herudover interesserede i, at kunne registrere baggrundsoplysninger om fx tilknytning til arbejdsmarked, uddannelse, økonomi o.l. til statistisk brug. Dette er for at øge viden om de børn og unge, der modtager hjælp og for at F o r t r o l i g t S i d e 74/ d e c e m b e r

75 kunne skabe viden om, hvornår (og for hvem) målene med kommunens indsats nås. Til håndtering af dette, har Systemet en række baggrundsspørgsmål indbygget og giver mulighed for, at man kan supplere lokalt. For flere informationer omkring spørgsmålsadministration henvises til afsnit Følgende skærmbillede viser et eksempel på et overbliksbillede i Familieadministrationskomponenten: Figur 14 Eksempel på skærmbillede til familieadministrationsoverblik Krav 86. Sagsbehandler kan få overblik over familiesammensætningen Kategori: Minimumskrav Type: Funktionelt Beskrivelse: Fra det tidspunkt, hvor en sag er blevet oprettet, skal Familieadministrationskomponenten gøre det muligt for en sagsbehandler, at registrere sagsinformation om barnet/den unge, dets familie og omgivelser, for dermed at få overblik over familiesammensætningen og netværk. Krav 87. Sagsbehandler kan kvalificere personer i barnets netværk F o r t r o l i g t S i d e 75/ d e c e m b e r

76 Beskrivelse: Sagsbehandleren skal kunne kvalificere (eller diskvalificere ) personer i barnets netværk til at indgå i de forskellige oversigter fx i tilfælde, hvor en lejer indføres som registreret beboer på bopælsadressen, selvom vedkommende ikke har nogen relevans for den konkrete sag. Krav 88. Sagsbehandleren kan angive relationer og roller for personer i barnets netværk Beskrivelse: Hvis data fra CPR-datakilden ikke kan klassificeres automatisk, skal Familieadministrationskomponenten understøtte sagsbehandleren i at kunne angive relation og rollebetegnelse for personer i den biologiske familie, husstandsfamilien eller barnets/den unges øvrige netværk. Krav 89. Sagsbehandler kan registrere standard-ydelsesmodtager Beskrivelse: Familieadministrationskomponenten skal understøtte, at en sagsbehandler skal kunne registrere en standard-ydelsesmodtager, typisk barnets mor, for et barn under 18 år. Krav 90. Understøttelse af adressebeskyttelse Beskrivelse: Familieadministrationskomponenten skal kunne håndtere adressebeskyttelse, så beskyttede adressedata ikke medtages i udskrifter og skærmbilledoverskrifter, men kun er tilgængelige for den ansvarlige sagsbehandler. Krav 91. Sagsbehandler kan se, hvem der er forældremyndighedsindehaver Beskrivelse: Det skal i Familieadministrationskomponenten fremgå, hvem der er forældremyndighedsindehaver(e) således, at det fremgår tydeligt for sagsbehandleren. F o r t r o l i g t S i d e 76/ d e c e m b e r

77 Krav 92. Sagsbehandler adviseres, når barnet/den unge flytter til anden kommune Beskrivelse: Når der sker væsentlige ændringer i Familieadministrationskomponenten, skal der ske en advisering til den eller de sagsbehandlere, der ansvaret for familien. Fx ved adresseændring og flytning til anden kommune. Krav 93. Forslag til relation via kommunens ESDH-system Kategori: Option Type: 2 Beskrivelse: Med udgangspunkt i sagspartregistret i kommunens ESDHsystem, skal Systemet automatisk fremkomme med et forslag til væsentlige relationer til barnet/den unge. Leverandøren skal i sin Løsningsbeskrivelse tage udgangspunkt i den samme Sags- og dokumentstandard som den øvrige ESDHintegration (se afsnit 5.4) og tilhørende Krav vedrørende tilgængelighed af kommunale ESDH-systemer, jf. afsnit og skal designes som en del af Sags- og dokumentarkivet således at Familieadministrationskomponenten integrerer til Sags- og dokumentarkivet som illustreret i følgende tegning: Figur 15 Integration til sagspart registret i kommunens ESDHsystem 16 Part serviceinterfacet fra OIO Sag og dokumentstandarden F o r t r o l i g t S i d e 77/ d e c e m b e r

78 Krav 94. Beskrivelse af Familieadministrationskomponenten Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive funktionaliteten og arkitekturen i Familieadministrationskomponenten, centreret omkring barnet/den unge. Herunder skal beskrives: Om Familieadministrationskomponenten kunne bruges i andre sammenhænge. Fx, hvor data i komponenten ikke er centreret omkring et barn/en ung, men hvor samme funktionalitet snarere er centreret omkring en generisk person. Hvordan kommunerne deler adgangen til persondata i Familieadministrationskomponenten, således at lovgivningen omkring beskyttelse af persondata hele tiden overholdes, specielt hvordan dette håndteres, når et barn/en ung flytter til en anden kommune. Om der er relevante områder af afsnit 5.13, 6 og 9, der ikke vil blive overholdt (forudsat der ikke er tale om minimumskrav) Persontyper Persontypebetegnelse anvendes i Familieadministrationskomponenten til at definere, hvilken rolle en person i barnets/den unges omgivelser har med barnet/den unge som omdrejningspunkt, fx mor, far, lillebror, plejemor osv. Listen over persontypebetegnelser er tænkt som en generisk liste, hvor en sagsbehandler kan foreslå nye typer, som en central administrator efterfølgende kan vælge at oprette i en central liste over persontyper, gældende på tværs af kommuner. Persontyperne kan eksempelvis være: Persontypebetegnelse Overkategori Hyperkategori Mor Forældre Biologisk familie Far Forældre Biologisk familie Søster Søskende Biologisk familie Bror Søskende Biologisk familie Halvsøster Søskende Biologisk familie Halvbror Søskende Biologisk familie Stedmor Husstandsfamilie/samværsfamilie Stedfar Husstandsfamilie/samværsfamilie Stedsøster Husstandsfamilie/samværsfamilie Stedbror Husstandsfamilie/samværsfamilie Plejemor Plejeforældre Plejefamilie Plejefar Plejeforældre Plejefamilie Plejesøster Plejesøskende Plejefamilie F o r t r o l i g t S i d e 78/ d e c e m b e r

79 Plejebror Plejesøskende Plejefamilie Mormor Morforældre Bedsteforældre Morfar Morforældre Bedsteforældre Farmor Farforældre Bedsteforældre Farfar Farforældre Bedsteforældre Moster Mors side Biologisk familie Faster Fars side Biologisk familie Morbror Mors side Biologisk familie Farbror Fars side Biologisk familie Tante Indgiftet Onkel Indgiftet Pædagog Lærer Træner Krav 95. Central administrator vedligeholder persontyper Beskrivelse: Systemet skal understøtte, at en central administrator via en administrationsklient kan tilføje, ændre og deaktivere persontyper. Derudover anvendes relationer i Familieadministrationskomponenten til at definere, i hvilken grad en person i barnets/den unges omgivelser er relateret til barnet/den unge, fx biologisk, indgiftet, husstand og netværk. Krav 96. Central administrator vedligeholder relationstyper Beskrivelse: Systemet skal understøtte, at en central administrator via en administrationsklient kan tilføje, ændre og deaktivere relationstyper Genogram En sagsbehandler skal kunne anvende Familieadministrationskomponenten til at koble personer i barnets/den unges omgivelser sammen i familier og netværk i et genogram. Systemet skal understøtte sagsbehandleren i, at kunne tilgå dette fra den samlede oversigt, husstandsfamilie, biologisk familie eller netværk. Genogrammet skal hjælpe sagsbehandleren til at kunne danne sig et overblik over indbyrdes relationer og konflikter imellem barnet/den unge og personer i dennes omgivelser. Nedenfor er illustreret et eksempel på, hvordan et genogram kan fremstå: F o r t r o l i g t S i d e 79/ d e c e m b e r

80 Figur 16 - Eksempel på genogram Krav 97. Sagsbehandler kan visualisere overblik over indbyrdes relationer og konflikter Kategori: Option Type: F o r t r o l i g t S i d e 80/ d e c e m b e r

81 Beskrivelse: Genogrammet skal hjælpe sagsbehandleren med at danne et overblik over indbyrdes relationer og konflikter imellem barnet/den unge og personer i dennes omgivelser således, at: En sagsbehandler skal kunne vælge visualiseringen af relationerne mellem barnet/den unge og dennes familie og netværk i et genogram ved brug af Familieadministrationskomponenten. En sagsbehandler skal kunne koble personer i barnets/den unges omgivelser sammen i familier og netværk i genogrammet, så den indbyrdes relation mellem de enkelte personer fremgår af den grafiske visning. En sagsbehandler skal kunne tilføje oplysninger om indbyrdes forhold og relationer mellem personer i barnets/den unges omgivelser, så det fremgår klart i genogrammet. Det kan fx være relationen til barnet/den unge, oplysninger om skilsmisse, konflikter, brud på social arv, aktuel alder, køn, eventuel dødsfaldsdato, jf. skærmbilledeksemplet ovenfor. Systemet skal automatisk oprette relationer og informationer i genogrammet, ud fra de tilgængelige oplysninger i Familieadministrationskomponenten om barnet/den unge, og dennes familie og omgivelser. Krav 98. Beskrivelse af genogrammet Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvordan genogrammet og Familieadministrationskomponenten arbejder sammen Integration til en CPR-datakilde I Systemet bruges CPR-oplysninger til at berige og opdatere stamdata om personer i sagsbehandlingen. CPR-oplysninger hentes fra en passende CPR-datakilde og de returnerede data vil blive registreret i Familieadministrationskomponenten. Familieadministrationskomponenten har også ansvaret for at eksekvere hent af data, som det fremgår af følgende tegning: F o r t r o l i g t S i d e 81/ d e c e m b e r

82 Figur 17 Familieadministrationskomponentens integration til CPR datakilde Krav 99. Hent af persondata fra CPR-datakilde Kategori: Minimumskrav Type: Ikke funktionelt Beskrivelse: Systemet skal integrere til en CPR-datakilde for hent af persondata i følgende situationer: Hent af persondata ved oprettelse af ny person i Systemet. Opdatering af persondata i Familieadministrationskomponenten (med tilhørende advisering af sagsbehandler) såfremt det registreres, at en person får ændrede informationer i CPR-datakilden. Krav 100. Intelligent understøttelse af dataoverførsel fra CPR Kategori: Krav Type: Ikke funktionelt Beskrivelse: Familieadministrationskomponenten skal understøtte intelligent dataoverførsel af CPR-oplysninger. Når sagsbehandleren har angivet fx relation, rollebetegnelse eller andre oplysninger, der ikke fremgår af data fra CPR-datakilden, skal angivelserne gemmes og en senere automatisk opdatering ved download af CPR-data må ikke automatisk overskrive de indtastede oplysninger. Krav 101. Forslag til familieoversigt via CPR-datakilde Kategori: Krav Type: Ikke funktionelt F o r t r o l i g t S i d e 82/ d e c e m b e r

83 Beskrivelse: Systemet skal ved sagsoprettelsen automatisk fremkomme med et forslag til en familieoversigt for barnet/den unge på baggrund af en CPR-datakildes oplysninger om slægtskab imellem personer, dvs. barnets/den unges forældre og forældres børn. Følgende informationer bør kunne udledes af CPR-datakilden: Biologiske forældre. Helsøskende til barnet/den unge. Halvsøskende til barnet/den unge. Stedfar/stedmor og stedsøskende, når en af forældrene er gift med en, som ikke er biologisk far eller mor til barnet/den unge. Krav 102. Beskrivelse af CPR-datakilde Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive den valgte CPR-integration således, at det fremgår: Hvordan arkitekturen af integrationen til CPR-datakilden er tiltænkt, inkl. en illustration heraf. Om integrationen er central for Systemet eller om den er decentral pr. kommune. Om integrationen består af system-til-system integration, udveksling af filer eller anden løsning. Hvor opdaterede (realtids) henholdsvis forsinkede flytteinformationer vil være, når Systemet bliver adviseret om, at en person er flyttet. Hvordan det sikres, at brug af CPR-datakilden udnyttes så økonomisk optimalt som muligt, såfremt hvert opslag er pålagt forbrugsafgift. Hvilke data Leverandøren mener, er relevante at hente fra CPR-datakilden, for at det understøtter Systemets Krav. Hvilke krav til sikkerhed, der er i den valgte løsning. Hvordan Leverandøren vil sikre, at det kun er aktive personer i Familieadministrationskomponenten, der opdateres med nyere CPR-persondata ICS-komponenten ICS-komponenten er en del af grundfunktionaliteten (Fase 1). F o r t r o l i g t S i d e 83/ d e c e m b e r

84 Integrated Children s System (ICS) 17 er en systematik, der kan anvendes af sagsbehandlere, når de skal afdække barnets forhold i forbindelse med en socialfaglig undersøgelse (Servicelovens 50), opstille mål for en eventuel indsats (Servicelovens 140) eller følge op på en indsats (Servicelovens 70). Systematikken illustreres ved en trekant (ICS-trekanten) med følgende tre domæner (med underliggende dimensioner): Barnet/den unges udviklingsmæssige behov: Omfatter barnets/den unges udvikling og behov på en række punkter (fordelt på en række behovsområder). Forældrekompetencer: Omfatter forældrenes evne, muligheder og barrierer for at imødekomme barnets behov (fordelt på en række forskellige forældrekompetencer). Familieforhold familie og omgivelser: Omfatter familiens baggrund, funktion og historie samt de omgivelser, der præger og påvirker forældrenes og barnets/den unges livssituation. Herunder især hvilke ressourcer, der kan registreres i familiens netværk og de nære omgivelser (fordelt på en række faktorer i familie og omgivelser). Figur 18 ICS-trekanten 17 jf. underbilag 3.1M. F o r t r o l i g t S i d e 84/ d e c e m b e r

85 Ovenstående ICS-trekant illustrerer den systematik, som sagsbehandleren arbejder efter: Når der indsamles og analyseres informationer om barnets/den unges forhold. Når denne viden skal omsættes til en passende indsats for barnet/den unge. Når der skal følges op på barnets/den unges situation og eventuelt iværksættes efterfølgende indsats. Systemet skal understøtte denne systematik. Samtidig anvendes ICS-trekanten som et visuelt redskab i samtalen med forældrene og barnet/den unge som illustration af, hvad sagsbehandleren lægger vægt på i vurderingen af barnets/den unges forhold. Dette skal Systemet ikke understøtte, men systematikken i Systemet skal være i overensstemmelse med ICS-trekanten, så disse understøtter hinanden ICS-systematikken ICS-trekanten er baseret på et helhedssyn på børns udvikling. Det betyder, at barnets udvikling skal ses og forstås ud fra den sociale sammenhæng barnet/den unge og familien indgår i, herunder samspillet mellem barn og forældre og mellem familien og dens omgivelser, herunder familiens sociale integration i samfundet. ICS-systematikken skal understøtte, at man som sagsbehandler igennem hele forløbet med barnet/den unge, fra socialfaglig undersøgelse til opstilling af - og opfølgning på mål, har opmærksomhed på det stadige samspil mellem barn, forældre og det omgivende miljø. I praksis betyder det, at sagsbehandlerne skal undersøge barnets behov samt hvilke fremskridt barnet/den unge gør i sin udvikling, forældrenes varetagelse af deres forældrerolle og familie- og miljøfaktorernes påvirkning 18. ICS-trekanten er tilpasset de seks dimensioner for undersøgelse og handleplan, som anbringelsesreformen kræver, skal anvendes (Servicelovens 50 og 140). Blandt andet er dimensionen fritidsforhold og venskaber tilføjet, og en række emner er placeret under overskriften "udvikling og adfærd", mens andre relevante forhold er indarbejdet i de øvrige dimensioner 19. ICS-komponenten skal sikre, at sagsbehandleren kan anvende ICS som systematik for de delprocesser, der knytter sig til undersøgelser, handleplaner og opfølgning. ICS-systematikken bygger på faglig teoretisk viden om børns udvikling, som sagsbehandleren har brug for at inddrage i arbejdet. Formålet med ICS-komponenten er at understøtte sagsbehandlerne i, at arbejde efter en fælles systematik, med 18 Jf. En vurdering af børns behov og udvikling: Integrated Children s System (ICS), side 3: jf. underbilag 3.1M. 19 Jf. Vejledning til DUBU-blanketter 5, jf. underbilag 3.1E og En vurdering af børns behov og udvikling: Integrated Children s System (ICS), side 32: jf. underbilag 3.1M. F o r t r o l i g t S i d e 85/ d e c e m b e r

86 henblik på at øge kvaliteten i sagsbehandlingen. Sagsbehandleren arbejder først og fremmest i fritekst i forbindelse med undersøgelser, handleplaner og opfølgning. Der er altså ikke tale om, at sagsbehandleren skal undersøge gennem afkrydsning. ICS-komponenten skal derimod være en fleksibel faglig referenceramme, som skal sikre systematik, der kan tilpasses den enkelte sagsbehandlers måde at arbejde på, niveauet i den enkelte sag samt den konkrete families behov. Balancen mellem fleksibilitet og struktur er defineret i ICS-licensaftalen 20, hvor der er beskrevet på hvilken måde, man kan tilpasse anvendelsen af ICS, defineret ved forskellige frihedsgrader, som Systemet skal understøtte. ICS-komponenten knytter sig også til Systemets mål om en bedre matchning af behov og tilbud, ud fra en betragtning om, at bedre undersøgelser, handleplaner og opfølgninger, giver bedre mulighed for at finde en indsats, der passer til barnet/den unge. Krav 103. Sagsbehandleren skal kunne arbejde fleksibelt i ICSkomponenten Kategori: Minimumskrav Type: Ikke Funktionelt Beskrivelse: Systemet skal understøtte, at sagsbehandleren kan arbejde fleksibelt med ICS-systematikken, i undersøgelser, handleplaner og opfølgninger, så disse kan tilrettelægges og skaleres efter behov. Bl.a. ved, at sagsbehandleren kan vælge felter i ICS komponenten til og fra og/eller knytte forskellige felter sammen 21 alt efter sagens karakter, og at et print til fx forældrene kun viser de udfyldte felter. De delprocesser, hvor ICS indgår som en central komponent, er ofte præget af at dokumenterne skal kunne læses af udenforstående, fx forældre, visitationsudvalg eller børne- og ungeudvalget. Derfor er det vigtigt, at fleksibilitet og systematik spiller sammen på en måde, som bidrager til inddragelse af disse. Fleksibiliteten betyder fx, at sagsbehandleren kan vælge felter i ICS-komponenten til og fra, alt efter sagens karakter, og at et print til forældrene fremstår læsevenligt og kun viser de udfyldte felter, der er relevante. For at lette den administrative byrde for sagsbehandlerne, skal ICS-komponenten desuden understøtte: At sagsbehandleren ikke skal bruge tid på at slå op forskellige steder, dvs. at hjælperedskaber i forhold til ICS er tilgængelige på relevante steder i processen jf. underbilag 3.1M. 21 I overensstemmelse med bilag 1 til ICS-licensaftalen jf. underbilag 3.1M. F o r t r o l i g t S i d e 86/ d e c e m b e r

87 At sagsbehandleren kan skalere anvendelsen af ICS-systematikken til både lette og vanskelige sager. At tekst og data genbruges, fx genanvendelse af den faglige vurdering fra undersøgelsen i handleplanen og målene fra handleplanen i forbindelse med opfølgningen. At Systemet præsenterer sagsbehandleren for obligatoriske spørgsmål, fx til indberetning til Ankestyrelsen i den sammenhæng, hvor det passer med ICS-systematikken. Det vil fx være naturligt at indtaste data om barnets skolesituation i forbindelse med dimensionen skoleforhold og læring, jf. afsnit for flere informationer. Krav 104. Sagsbehandler kan til- og fravælge felter i ICS komponenten Beskrivelse: Sagsbehandleren skal kunne til- og fravælge felter i ICS komponenten alt efter sagens karakter som let eller vanskelig sag. Dog skal anvendelsen opfylde Minimumsstandarder for ICS i 50 undersøgelse, handleplan og opfølgning, i ICS-licensens bilag Processtøtte ICS-komponenten ICS-komponenten skal indeholde en række værktøjer til at understøtte sagsbehandleren til, at gennemføre socialfaglige undersøgelser, handleplaner og opfølgninger. Adgang til ICS-værktøjerne er administreret af Sagsstyringskomponenten. Systemet skal således kunne aktivere ICS-komponenten, når en sagsbehandler iværksætter: En 50-undersøgelse. En handleplan. En opfølgning. Som det fremgår tidligere i afsnittet, er ICS-trekanten opdelt i tre domæner. Under hvert af disse domæner findes en række dimensioner. Domæner og dimensioner bringes i anvendelse på forskellig vis i de tre delprocesser, som ICS komponenten skal understøtte, hvilket er beskrevet nedenfor. ICS-anvendelse ved 50-undersøgelsen Når sagsbehandleren arbejder med 50-undersøgelsen er det vigtigt, at der er en god balance mellem understøttelse af en fælles systematik gennem ICS og mulighed for at tilpasse systematikken til kommunens og sagsbehandlerens måde at arbejde på samt barnets situation. Nedenstående figur viser, hvordan ICS-komponenten kunne fremstå ved en 50- undersøgelse i Systemet: F o r t r o l i g t S i d e 87/ d e c e m b e r

88 Figur 19 Anvendelsen af ICS i en 50-undersøgelse I skærmbilledet nedenfor er det søgt illustreret, at en sagsbehandler har valgt dimensionen Sundhedsforhold i ICS-trekanten, hvorefter Systemet præsenterer vedkommende for inddateringsfelter for denne dimension. Sagsbehandleren skal kunne vælge, hvilke felter der er relevante under hver dimension og skal desuden kunne angive en begrundelse, hvis en dimension slet ikke er relevant i den konkrete sag: F o r t r o l i g t S i d e 88/ d e c e m b e r

89 Figur 20 Beskrivelse af 50-undersøgelse Krav 105. Sagsbehandler får præsenteret en kontekstafhængig visning af indholdet i dokumenterne Beskrivelse: Systemet skal, alt efter hvilken dimension sagsbehandleren aktuelt har klikket ind på, kunne præsentere sagsbehandleren for hjælpespørgsmål og en kontekstafhængig forklaring af domæner og dimensioner 22. Således skal Systemet fx præsentere afsnittet om sundhedsforhold (punkt 259, nr. 4) 23, hvis sagsbehandleren aktiverer en funktion til visning af vejledning af Serviceloven undervejs i sin udredning af sundhedsforhold eller relevante hjælpespørgsmål knyttet til sundhedsforhold, hvis sagsbehandleren aktiverer en funktion til visning af de aldersopdelte fokusområder. 22 I henhold til følgende kilder: De seks punkter i anbringelsesreformen (jf. Servicelovens 50, stk. 2. i Vejledning om særlig støtte til børn og unge og deres familier og Håndbog om anbringelsesreformen), samt ICS-fokusområderne (Aldersopdelte fokusområder og jf. underbilag 3.1M f3, jf. underbilag 3.1M. F o r t r o l i g t S i d e 89/ d e c e m b e r

90 Krav 106. Sagsbehandler aktiverer kontekstafhængig visning af ICSbegreber Beskrivelse: Sagsbehandleren skal i løbet af arbejdet i ICS-komponenten, kunne aktivere kontekstafhængig forklaring på de begreber, der anvendes i ICS-metoden. Krav 107. Sagsbehandleren kan angive målkategori for flere dimensioner Beskrivelse: Systemet skal understøtte sagsbehandleren i, at kunne angive målkategori fra prædefinerede lister for hver af dimensionerne under domænet Barnets udviklingsmæssige behov 24. Krav 108. Central administrator tilpasser ICS-trekantens målkategorier Beskrivelse: Systemet skal understøtte, at central administrator via en administrationsklient kan tilføje, ændre og deaktivere indhold i en liste over målkategorier tilknyttet ICS-dimensionerne. Krav 109. Hierarki af mål Beskrivelse: Systemet skal understøtte forskellige mål således, at en målkategori skal kunne bestå af ét eller flere mål, og et mål skal kunne bestå af ét eller flere delmål. Når sagsbehandleren har udfyldt alle relevante felter for dimensionen, skal vedkommende kunne vælge at skrive en analyse for den enkelte dimension, i form af en beskrivelse af barnets udækkede behov i fritekst. Dette kan være nyttigt, hvis undersøgelsen strækker sig over en længere periode. Her vil analysen af den enkelte dimension give sagsbehandleren et hurtigt overblik, når undersøgelsen genoptages senere. Samtidig giver det sagsbehandleren mulighed for, når alle dimensioner er undersøgt, at overføre indholdet fra én, flere eller alle dimensioner til den samlede analyse. 24 ICS begreber offentliggjort på jf. underbilag 3.1M. F o r t r o l i g t S i d e 90/ d e c e m b e r

91 Ønsker sagsbehandleren, at indholdet overføres til analysen i en anden rækkefølge end standardindstillingen, skal vedkommende kunne ændre rækkefølgen, eksemplificeret i følgende skærmbilledeksemplet med knappen Prioritér rækkefølge : Figur 21 - Ændring af prioriteret rækkefølge Krav 110. Sagsbehandler kan prioritere rækkefølge af felter Beskrivelse: Sagsbehandleren skal kunne prioritere rækkefølgen af felter i overførslen af elementer til analysen. ICS-komponenten skal understøtte, at sagsbehandleren kan udarbejde en analyse af barnets/den unges udviklingsmæssige behov ud fra en sammenfatning af det, sagsbehandleren har indskrevet under dimensionerne på trekantens tre domæner i løbet af 50-undersøgelsen. Den faglige vurdering foretager sagsbehandleren på baggrund af analysen. Systemet skal sikre, at en sagsbehandler ikke kan afslutte en 50-undersøgelse i ICS komponenten, før vedkommende har foretaget en socialfaglig undersøgelse inden for alle de dimensioner i ICS, som vedrører de seks indholdsmæssige lovkrav i Servicelovens 50 eller alternativt har angivet begrundelse for, hvorfor dimensionen ikke er relevant i for det konkrete barn. F o r t r o l i g t S i d e 91/ d e c e m b e r

92 Krav undersøgelsen skal afsluttes, før undersøgelsen må indgå i journalarket Beskrivelse: Systemet skal sikre, at sagsbehandlerens undersøgelse først indgår i journalarket, når 50-undersøgelsen er afsluttet. Krav 112. Sagsbehandleren kan generere en ny version af 50- undersøgelsen, handleplan, opfølgning Beskrivelse: Systemet skal, på sagsbehandlerens opfordring, generere en ny version af 50-undersøgelsen, handleplan, opfølgning. Krav 113. Tydelig versionsmarkering af 50-undersøgelser Beskrivelse: Såfremt der er tale om flere versioner af 50-undersøgelser, skal det fremgå, hvor mange versioner der er tale om og angives, hvilken version, der er aktiv og hvilke(n), der er afsluttet. Knappen begrebsdefinitioner 25 i tidligere skærmbillede-eksempel illustrerer, at sagsbehandleren skal kunne aktivere en forklaring på de begreber, der anvendes i ICS-metoden. Denne funktion skal dels præsentere en definition af konkrete begreber, dels guide sagsbehandleren til, hvad der skal beskrives i de forskellige indtastningsfelter. Krav 114. Sagsbehandler får vist beskrivelse af de forskellige dimensioner om den unge Beskrivelse: I forbindelse med, at en sagsbehandler udarbejder sin analyse skal Systemet gøre det muligt for sagsbehandleren samtidigt at få præsenteret visning af det, der er beskrevet om barnet/den unge under de forskellige dimensioner. 25 Begrebsdefinitioner kan ses på jf. underbilag 3.1M. F o r t r o l i g t S i d e 92/ d e c e m b e r

93 Krav 115. Administrator tilpasser ICS-trekantens felter under dimensioner Beskrivelse: Systemet skal understøtte, at en central og kommunal administrator via en administrationsklient kan tilføje, ændre og deaktivere felter under ICS-trekantens dimensioner. Krav 116. Central administrators vedligeholdelse af ICS-trekantens dimensioner Kategori: Minimumskrav Type: Funktionelt Beskrivelse: Systemet skal understøtte, at en central administrator via administrationsklienten kan foretage oprettelse, ændring og sletning af dimensioner (linkene) under domænerne på ICS-trekanten. Krav 117. Administrator opsætter rækkefølgen af dimensionerne Beskrivelse: Rækkefølgen af dimensionerne i skærmbillede og systemanvendelsen i øvrigt skal kunne bestemmes af en central og kommunal administrator. Krav 118. Dimensioner skal organiseres i over- og underordningsforhold Beskrivelse: Systemet skal understøtte, at dimensioner organiseres i et overog underordningsforhold, som det fremgår af beskrivelsen af dimensionerne under domænerne Barnets udviklingsmæssige krav og Familieforhold Familie og omgivelser. Knappen fokusområder udgør en række aldersopdelte hjælpespørgsmål, der relaterer sig til de tre domæner og de underliggende dimensioner 26. Fokusområderne er tænkt som en støtte for sagsbehandleren i undersøgelsen af barnets/den unges udviklingsmæssige behov, forældrekompetencer samt familieforhold familie og omgivelser. Der er ikke tale om en egentlig spørgeramme, men snarere et inspirationskatalog, som kan guide sagsbehandleren til at fokusere på det, der er relevant. 26 Aldersopdelte fokusområder, version 3.3, jf. underbilag 3.1M. F o r t r o l i g t S i d e 93/ d e c e m b e r

94 I Systemet skal sagsbehandleren kunne aktivere de aldersopdelte fokusområder henholdsvis fra ICS komponentens forside, og under hver af dimensionerne på trekantens sider. Hvis sagsbehandleren aktiverer funktionen til visning af de aldersopdelte fokusområder, skal Systemet automatisk angive det alderstrin, som fremgår af CPR-nr. for den igangværende sag og de aldersopdelte fokusområder, der relaterer sig til den dimension sagsbehandleren er i gang med. Dog skal sagsbehandleren også kunne vælge et andet alderstrin og andre dimensioner, som vedkommende ønsker visning af. Krav 119. Sagsbehandler kan få vist de aldersopdelte fokusområder Beskrivelse: Hvis sagsbehandleren aktiverer funktionen til visning af de aldersopdelte fokusområder, skal Systemet som udgangspunkt automatisk angive det alderstrin, som fremgår af CPR-nr. for den igangværende sag. Krav 120. Sagsbehandleren kan vælge alderstrin Beskrivelse: Sagsbehandleren skal desuden kunne vælge, inden for hvilke(t) alderstrin vedkommende ønsker visning af de aldersopdelte fokusområder. Krav 121. Sagsbehandler bekræfter valgt aldersopdeling Beskrivelse: Systemet skal hvis dateringen af sagsbehandlerens valg af aldersopdelt fokusområde er mere end 12 mdr. gammel anmode sagsbehandleren om at bekræfte, at den valgte aldersopdeling stadig er relevant. Krav 122. Central administrator opsætter aldersopdelte spørgsmål Beskrivelse: Systemet skal understøtte, at en central administrator kan tilføje, ændre og deaktivere spørgsmål i lister for aldersopdelte fokusområder, herunder ligeledes rækkefølgen. F o r t r o l i g t S i d e 94/ d e c e m b e r

95 Krav 123. Kommunal administrator kan tilføje aldersopdelte spørgsmål Beskrivelse: Systemet skal understøtte, at en kommunal administrator kan tilføje spørgsmål i lister for aldersopdelte fokusområder. Krav 124. Central administrator kan modificere aldersopdelingen Beskrivelse: Systemet skal understøtte, at en central administrator kan modificere aldersopdelingen, og at berørte spørgsmål i den forbindelse reorganiseres. Nedenfor er et skærmbillede, der viser et eksempel på, hvordan man ved at trykke på Fokusområder får adgang til aldersopdelte fokusområder for den dimension sagsbehandleren arbejder med. Systemet skal understøtte, at en sagsbehandler via valg af fx alderstrinet 3-4-årige får præsenteret de aldersopdelte fokusområder for denne gruppe: Figur 22 - Aldersopdelte fokusområder F o r t r o l i g t S i d e 95/ d e c e m b e r

96 Krav 125. Sagsbehandler får vist tidligere fremvisningsmåde Beskrivelse: Hvis sagsbehandleren vælger at basere sig på en anden gruppering i de aldersopdelte fokusområder, skal Systemet huske dette, så der ved en senere åbning automatisk vælges den ønskede gruppering. ICS-anvendelse ved handleplan Systemet skal indeholde en funktion, som sagsbehandleren kan benytte til at opstille en handleplan i løbet af delproces vedrørende visitation. I udarbejdelsen af handleplanen, skal sagsbehandleren opsætte mål for hver ICSdimension under domænet med barnets udviklingsmæssige behov og samlet til domænet vedrørende familieforhold familie og omgivelser. Endvidere skal Systemet give mulighed for samlet opstilling af mål for domænet Forældrekompetencer i situationer, hvor det kan være vanskeligt at beskrive forholdet under barnets udviklingsmæssige behov, fx ved ufødte børn. Under hver dimension skal Systemet understøtte, at sagsbehandleren kan vælge målkategori og efterfølgende formulere mål og eventuelt delmål. Krav 126. Sagsbehandleren kan foretage socialfaglig udredning af den unge Beskrivelse: Under den socialfaglige undersøgelse skal Systemet understøtte sagsbehandleren i, for hver dimension på trekantens venstre side, at kunne beskrive; Barnets/den unges udviklingsmæssige Krav i form af ressourcer og problemer. Forældrekompetencer. Barnets/den unges udækkede Krav. Krav 127. Sagsbehandleren kan beskrive forældrekompetencen Beskrivelse: Systemet skal understøtte sagsbehandleren i, at kunne udføre en samlet beskrivelse af forældrekompetencen for flere eller alle dimensioner på trekantens venstre side på én gang eller i forhold til hver enkelt dimension på trekantens venstre side. F o r t r o l i g t S i d e 96/ d e c e m b e r

97 Følgende skærmbilledeksempel illustrerer, hvordan Systemet kunne præsentere målformuleringen for sagsbehandleren: Figur 23 - Præsentation af målformulering ICS-anvendelse ved opfølgning på mål og indsats Når sagsbehandleren skal foretage opfølgninger på indsatser, skal dette understøttes af ICS-komponenten. Som en aktivitet i delproces vedrørende indsats og opfølgning, skal sagsbehandleren kunne foretage en evaluering med en visning af de mål, der er blevet opstillet i handleplanen. Systemet skal understøtte sagsbehandleren i, at angive for hvert mål, i hvilken grad målet er nået. Dette er søgt illustreret ved skærmbilledeksempel umiddelbart nedenfor: F o r t r o l i g t S i d e 97/ d e c e m b e r

98 Figur 24 - Evaluering af mål Når en sagsbehandler aktiverer en funktion til visning af et givent mål, skal Systemet præsentere vedkommende for detaljer om målet og eventuelle tidligere opfølgninger med vurderinger af målopfyldelsen. Systemet skal understøtte sagsbehandleren i at kunne tilføje nye vurderinger af målopfyldelsesgraden, så længe delprocessen vedrørende indsats og opfølgning er i gang. På lignende vis skal sagsbehandleren kunne registrere tilfredsheden med henholdsvis den samlede indsats og med hver af de anvendte aftalepartnere, baseret på udtalelser fra henholdsvis barnet/den unge, forældre, samt sagsbehandlerens egen vurdering. Krav 128. Sagsbehandleren kan evaluere tilfredsheden med ydelser Beskrivelse: Systemet skal understøtte sagsbehandleren i at kunne evaluere tilfredsheden med henholdsvis den samlede indsats og med hver af de anvendte ydelser med tilknyttet leverandør. Evalueringen skal baseres på udtalelser fra henholdsvis barnet/den unge, forældre, eventuelt andre relevante parter samt sagsbehandlerens egen vurdering. F o r t r o l i g t S i d e 98/ d e c e m b e r

99 Systemet skal kunne registrere sagsbehandlerens mål- og tilfredshedsvurderinger både kvalitativt og kvantitativt. De kvantitative tilfredshedsvurderinger kan samtidig indgå som søgedata i Tilbudssystemet til indsatssøgning. Krav 129. Beskrivelse af ICS-komponenten Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive funktionaliteten og arkitekturen i ICSkomponenten herunder: Muligheder for parameteropsætning i ICS-komponenten. Hvordan, og med hvilke konsekvenser ICS komponenten vil kunne udskiftes med en anden komponent, der baserer sig på en anden faglig metode. Om der er relevante områder af afsnit 5.13, 6 og 9, som ikke vil blive opfyldt (forudsat der ikke er tale om minimumskrav) Håndtering af sager og dokumenter Det Interne Arkiv i er en del af grundfunktionaliteten (Fase 1), mens Sags- og dokumentarkivet (der efterfølgende vil indeholde det Interne Arkiv) er en del af Fase 2. Håndteringen af sager og dokumenter har til formål at sikre, at Systemet kan danne det forvaltningsmæssige arkiv, hvori al sagsinformation på en sag kan registreres. Ansvaret for at sagsbehandle en sag ligger i Sagsstyringskomponenten mens det Interne Arkiv og efterfølgende Sags- og dokumentarkivet har ansvaret for at lagre de sager og dokumenter, der bruges i Systemet. Kommunen har behov for en løsning til registrering, styring, håndtering og henlæggelse af sager og dokumentet fra Systemet, dels for at sikre lovgivningens dokumentationskrav, og dels for at sikre en fortsat god administrativ praksis. Det Interne Arkiv og efterfølgende Sags- og dokumentarkivet skal derfor give et fuldstændigt overblik og kontrol over de dokumenter, der indgår i en given sag. Dette afsnit er opdelt således: Generelle krav til håndtering af sager og dokumenter. Det Interne Arkiv, der skal benyttes af Systemet til at lagre sager og dokumenter internt. Denne del vil blive bygget i grundfunktionaliteten (Fase 1). Et Sags- og dokumentarkiv indeholdende både det Interne Arkiv og ESDHintegrationer således, at der kan udveksles sager og dokumenter direkte i kommunernes ESDH-systemer. Sags- og dokumentarkivet vil blive bygget i Fase 2. F o r t r o l i g t S i d e 99/ d e c e m b e r

100 Følgende krav skal opfyldes både af Det Interne Arkiv og Sags- og dokumentarkivet. Krav 130. Fordelt ansvar for en sag Beskrivelse: En sag skal initieres og sagsbehandles i Sagsstyringskomponenten og opbevares i det Interne Arkiv (i Fase 1) og/eller Sags- og dokumentarkivet (i Fase 2). Krav 131. Dokumenter skal knyttes til sag Beskrivelse: Et dokument skal altid knyttes til en sag. Krav 132. Sag følger KL s emneplan Beskrivelse: Alle dokumenter og noter som oprettes, tildeles automatisk et journalnummer efter KL s emnesystematik 27. Krav 133. Sagsbehandler tilknytter dokument til aktivitet Beskrivelse: Det skal være muligt for sagsbehandleren at oprette et link fra en aktivitet til et dokument/notat tilknyttet sagen, enten i forbindelse med udførelsen af aktiviteten eller i forbindelse med oprettelse/redigering af dokumentet/notatet. Fx skal aktiviteten lav handleplan kunne tilføjes et link til handleplanen. Krav 134. Sagsbehandler har let tilgængelig liste over ulæste dokumenter 27 KL Emnesystematik: jf. underbilag 3.1M. F o r t r o l i g t S i d e 100/ d e c e m b e r

101 Beskrivelse: Liste over afdelingens/sagsbehandlerens ulæste dokumenter skal være let tilgængelig, fx fra Centralskærmbilledet, jf. afsnit 5.1. Dokument skal først fjernes fra listen over ulæste dokumenter, når en sagsbehandler har markeret dokumentet som læst Det Interne Arkiv Formålet med det Interne Arkiv er at stille en komponent til rådighed, hvori der kan gemmes sager og dokumenter i Systemet. Det Interne Arkiv kan ikke integrere til kommunernes ESDH-systemer, men har udelukkende ansvar for at tilgodese Systemets behov for at have ét sted at gemme sager og dokumenter. Som det fremgår af nedenstående konceptuelle arkitekturtegning vil Systemet i grundfunktionaliteten udelukkende arbejde med det Interne Arkiv. Dette skal gøres således, at alle sager og dokumenter oprettes som en del af Systemet, men dog stadig så afkoblet fra resten af Systemet og så standardiseret, at sager og dokumenter i det Interne Arkiv i fremtiden, vil kunne deles med andre via en åben snitflade: Figur 25 Konceptuel tegning af Det Interne Arkiv Ovenstående tegning viser Systemet med fokus på det Interne Arkiv. Den blå kasse Arkiv er snitfladen ind til det Interne Arkiv, og her vil Systemet tilgå arkivet. Derudover vil der være en brugergrænseflade Arkiv GUI som en kommunal administrator kan benytte til at vedligeholde basisdata, eksempelvis klassifikationer for den kommune, administratoren er tilknyttet. Via Import/Eksport snitfladen er der F o r t r o l i g t S i d e 101/ d e c e m b e r

102 mulighed for import og eksport af filer med sager og dokumenter. De udtrukne sager og dokumenter kan efterfølgende manuelt, såfremt kommunen måtte ønske dette, importeres ind i et kommunalt ESDH-system. Derudover vil der også kunne udtrækkes data til Statens Arkiver. Formålet med det Interne Arkiv er således at sikre, at kommuner som enten ikke har et kommunalt ESDH-system af relevans for Systemet eller har et kommunalt ESDH-system, der ikke overholder kravene til integration, alligevel kan få adgang til at gemme sager og dokumenter. Derudover kan formålet med det Interne Arkiv også være at fungere som en form for cache, når Sags- og dokumentarkivet begynder at integrere med de kommunale ESDH-systemer (se afsnit 5.4.2). Formålet er således ikke at tilvejebringe et nyt ESDH-system da der ikke vil være funktionalitet nok til rådighed i det Interne Arkiv til at opfylde dette behov! Krav 135. Funktionalitet tilbudt af Interne Arkiv Beskrivelse: Det Interne Arkiv skal som udgangspunkt tilbyde følgende funktionalitet inden for rammerne af mulighederne i den valgte snitflade standard (se Krav 138): Oprettelse af en sag. Opdatering af en sag. Hent af sagsdata. Oprettelse af en note/hændelse 28. Opdatering af en note/hændelse. Hent af note/hændelse. Oprettelse af et dokument. Gem af dokument som ny version. Opdatering af et dokuments data og stamdata. Hent af dokument. Håndtering af dokumenter af forskellige type (fx indgående/udgående, notat). Låsning af dokument for redigering. Modtagelse og visitering (fordeling) af indkommet dokument. Håndtering af forskellige typer af dokumenter; s, elektroniske blanketter, billedfiler, gængse filformater (herunder ODF og OOXML). Visning af liste (væsentlige metadata) over alle dokumenter på en sag. 28 Sagsservice-specifikationen i OIO Sags- og dokumentstandarden benytter sig af en Journalpost enhed, som kan være relevant at benytte til registrering af hændelser sammen med begrebet virkning, hvorpå det er muligt at tilknytte en note. F o r t r o l i g t S i d e 102/ d e c e m b e r

103 Visning af liste (væsentlige metadata) over afdelingens/sagsbehandlerens ulæste dokumenter. Krav 136. Beskrivelse af Det Interne Arkiv Kategori: Info Type: Beskrivelse: Leverandøren skal nøje skitsere og beskrive funktionaliteten og arkitekturen af det Interne Arkiv, herunder også gennemgå: Muligheden for, enten fra starten at understøtte hændelser fra ESDH-systemerne mod Systemet (for eksempel ved modtagelse af et dokument via kommunens ESDH-system) eller alternativt en beskrivelse af, hvilke tiltag der skal til for på sigt, at udvide Systemet med hændelser (med baggrund i den valgte Sags- og dokumentstandard). Hvor robust Systemet vil være overfor eventuelle fremtidige versioner af Sag og dokumentstandarden. Beskrive, om der er relevante områder af afsnit 5.13, 6 og 9 som ikke opfyldes (forudsat der ikke er tale om minimumskrav). Krav 137. Kommunal administratoradgang til det Interne Arkiv Beskrivelse: En kommunal administrator skal have adgang til det Interne Arkiv specielt med henblik på at kunne tilpasse basisdata, som for eksempel klassifikationer. Systemet skal kunne opdatere og læse sager og dokumenter i det Interne Arkiv, via de åbne snitflader, som det Interne Arkiv udstiller. De åbne standarder skal baseres på en delmængde af de godkendte OIO serviceinterfaces under sag- og dokumentstandarden 29. Krav 138. Snitflade standard for det Interne Arkiv Kategori: Krav Type: Ikke funktionelt Beskrivelse: Det Interne Arkiv skal udstille snitfladerne beskrevet via et passende udvalg af de godkendte OIO-serviceinterfaces fra Sags- og 29 jf. underbilag 3.1M. F o r t r o l i g t S i d e 103/ d e c e m b e r

104 dokument standarden 30. Krav 139. Beskrivelse af dataudveksling for det Interne Arkiv Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvorledes standarden anvendes, hvor store dele af standarden, der skal bruges og især, hvilke tilføjelser og afvigelser som er nødvendige, for at kunne foretage dataudvekslingen. I beskrivelsen bør medtages overvejelser omkring opfyldelse af: Krav 43 Sagsbehandler sætter sag til at afvente modtagelse af dokumenter. Krav 93 Forslag til relation via kommunens ESDH-system. Krav 162, Journalarksnoter skal knyttes til enkeltsager. Krav 358 Overholdelse af arkivloven. Krav 140. Mulighed for import og eksport fra det Interne Arkiv Beskrivelse: Det skal være muligt at foretage en simpel import og eksport af sager og dokumenter (fx i et PDF-format/åbent dokumentformat) fra det Interne Arkiv, og hermed give kommunerne mulighed for, manuelt at overføre sager og dokumenter mellem Systemet og de kommunale ESDH-systemer, der kan modtage de valgte formater. Krav 141. Beskrivelse af formater for import og eksport fra det Interne Arkiv Kategori: Info Type: Beskrivelse: Leverandøren skal angive, hvilke filformater det er mest hensigtsmæssigt at anvende til import og eksport af sager og dokumenter fra det Interne Arkiv med udgangspunkt i et ambitionsniveau, der omfatter eksempelvis PDF format/åbne dokumentformater e.lign for dokumenter og et format for sagsoplysninger og metadata, der er åbent og tilgængeligt (Excel eller lignende). Le standarder/standardisering/datastandardisering/tvergaende-sags-og- dokumenthandtering/filer-og- dokumenter/referencearkitektur/itst_referencearkitekturesdh_web.pdf. Endvidere Specifikation af serviceinterface for sag, OIO-udvalget for sags- og dokumentområdet, 18. december 2009 og Specifikation af serviceinterface for dokument, OIO-udvalget for sags- og dokumentområdet, 18. december 2009, jf. underbilag 3.1M. F o r t r o l i g t S i d e 104/ d e c e m b e r

105 verandøren skal angive eventuelle fordele og ulemper ved de valgte formater herunder eventuelle begrænsninger for de kommunale ESDH-systemer. For at gøre det muligt på sigt, at udskifte det Interne Arkiv med en integration til de kommunale ESDH-systemer i kommunerne, skal det være muligt i Systemet at konfigurere, hvilken snitflade(r) sager og dokumenter gemmes i. Hermed sikres, at der ikke kræves en eventuel recompilering af kode og ny deployment af resten af Systemet når ESDH-integrationen (gennemgået senere) udvikles. Snitfladen, der skal benyttes i stedet, skal derfor opfylde de samme krav til åbne standarder, som er gældende for det Interne Arkiv (se Krav 138). Krav 142. Konfigurerbar udskiftning af snitflader Kategori: Krav Type: Ikke funktionelt Beskrivelse: Det skal være konfigurerbart i Systemet, gennem hvilke snitflader der skal gemmes sager og dokumenter. Det er et krav, at den snitflade der skal konfigureres imod, skal opfylde de samme Krav til åbne standarder, som snitfladen i det Interne Arkiv (se Krav 138). De sager og dokumenter, der skal overføres fra Systemet til det Interne Arkiv, vil oftest indeholde personfølsomme data, og det er derfor af højeste vigtighed, at data og kommunikationen mellem Systemet og det Interne Arkiv er behørigt sikret. Krav 143. Sikring af data mellem det Interne Arkiv og den øvrige del af Systemet Kategori: Krav Type: Ikke funktionelt Beskrivelse: Overførslen af sager og dokumenter mellem det Interne Arkiv og den øvrige del af Systemet skal sikres på et sådant niveau, at personfølsomme data ikke risikerer at blive kompromitteret (eksempelvis OIORASP, OIOIDWS, OWSA model T). Krav 144. Beskrivelse af sikker transport af data, til og fra det Interne Arkiv Kategori: Info Type: F o r t r o l i g t S i d e 105/ d e c e m b e r

106 Beskrivelse: Leverandøren skal skitsere og beskrive den valgte sikring af transport mellem Systemet og det Interne Arkiv. Beskrivelsen bør inkludere, hvorledes samspillet er med hele den valgte sikkerhedsarkitektur i Systemet for hermed at synliggøre, at den samlede sikkerhedsarkitektur bliver en konsistent løsning. Ligeledes er det også vigtigt, at sager og dokumenter i det Interne Arkiv er adskilt på et sådant niveau, at kun aktører tilhørende en kommune kan se kommunens egne sager og dokumenter, og dermed ikke ved en fejl får adgang til at se andre kommuners sager og dokumenter. Med baggrund i Krav 161 er det vigtigt, at det kun er Systemets aktører, der får adgang til Systemets sager og dokumenter. Krav 145. Sikring af adgang til data i det Interne Arkiv Kategori: Krav Type: Ikke funktionelt Beskrivelse: Det skal ikke være muligt at tilgå sager og dokumenter på tværs af kommuner i det Interne Arkiv. Ligeledes (med baggrund i Krav 161) må kun Systemets aktører få adgang til Systemets sager og dokumenter, og kun til de sager og dokumenter, som aktøren har rettigheder til. Krav 146. Beskrivelse af sikring af kommuners data i det Interne Arkiv Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvordan det sikres at sager og dokumenter i det Interne Arkiv kun kan tilgås af Systemets aktører fra den kommune, som er ejer af data Sags- og dokumentarkiv Af forvaltningsmæssige hensyn er det vigtigt, at det er muligt at overføre sager og dokumenter mellem Systemet og kommunernes ESDH-systemer. Dette kan i grundfunktionaliteten lade sig gøre via import- og eksportfunktionaliteten i det Interne Arkiv, som en manuel - og af Systemet helt uafhængig - arbejdsgang. En sagsbehandler kan importere eller eksportere sager og dokumenter såfremt data lever op til de formater, der er forventet af import- og eksportfunktionaliteten (se Krav 140). Udvidelsen af funktionalitet i dette afsnit afspejler en mere automatiseret udveksling, som skal gennemføres i Fase 2, hvor Sags- og dokumentarkivet automatisk overfører sager og dokumenter mellem Systemet og de kommunale ESDHsystemer, som er tilknyttet Systemet. F o r t r o l i g t S i d e 106/ d e c e m b e r

107 Følgende konceptuelle arkitekturtegning skitserer integrationerne til de kommunale ESDH-systemer i forhold til Systemet: Figur 26 Konceptuel tegning over ESDH-integrationen Ovenstående tegning viser samspillet med Systemets værende Sags- og dokumentarkivintegration og de kommunale ESDH-systemer. Den gule firkant illustrerer afgrænsningen af Sags- og dokumentarkiv, mens den stiplede linje illustrerer Systemet. I stedet for, som i grundfunktionaliteten, at benytte sig af den åbne snitflade foran det Interne Arkiv, vil Systemet tilgå den fælles ESDH-snitflade, som vil være underlagt de samme krav til standarder som den åbne snitflade i det Interne Arkiv og hermed være identisk (se Krav 138). Internt i Sags- og dokumentarkiv er der en såkaldt Orkestreringskomponent, som har ansvaret for at vurdere, på baggrund af den besked, som er modtaget fra den fælles ESDH-snitflade, hvilken af de eksterne snitflader, der skal kommunikeres med. Orkestreringskomponenten får informationer omkring den relevante snitflade via opslag i elementet ESDH-Fordeler, som er et element, der mapper en kommune med en snitflade og et element, som aktøren Central Administrator kan vedligeholde. Efterfølgende vil Orkestreringskomponenten redirigere sager og dokumenter til de datastrukturer, der er i den eksterne snitflade. Når aktøren Central Administrator registrerer et nyt eksternt ESDH-system i ESDH- Fordeleren, skal Orkestreringskomponenten opdage dette, og straks derefter påbe- F o r t r o l i g t S i d e 107/ d e c e m b e r

108 gynde overflytningen af sager og dokumenter fra det Interne Arkiv til det eksterne ESDH-system. De kommuner, som har ESDH-systemer, der ligeledes udstiller snitflader i samme standard og omfang som det Interne Arkiv, vil som del af Systemet skulle tilkobles Sags- og dokumentarkivet under den forudsætning, at der dermed ikke skal foretages transformationer mellem snitfladerne. Således vil tilkoblingen reelt bestå af en opsætning af placering af kommunens snitflade. Såfremt der ved igangsættelse af Fase 2 (se Krav 147) findes ESDH-systemer, som ikke udstiller samme åbne snitflader som det Interne Arkiv, vil disse ikke være en del af Systemet, og integration til disse ESDH-systemer vil derfor skulle håndteres enten via de vedlagte optioner eller udenfor nærværende udbud. Leverandørens ansvar stopper, hvor snitfladen til kommunens ESDH-system starter. Leverandøren har således ikke ansvar for at lave ændringer internt i kommunens ESDH-system eller at lave en åben snitflade foran kommunens ESDH-system medmindre Kunden vælger at tilkøbe Krav 150. Leverandøren har til ansvar at sørge for, at konfigurere Sags- og dokumentarkivet til at transportere sager og dokumenter til og fra den snitflade kommunens ESDH-system udstiller jf. kravene angivet i dette afsnit, og at deltage i en end-to-end test som angivet i Kontraktens bilag 14, afsnit 2.2. Leverandøren har endvidere ansvar for at medvirke til at diagnosticere, hvor en eventuel fejl måtte være placeret. Krav 147. Integration til ESDH-systemer Kategori: Minimumskrav Type: Ikke funktionelt 2 Beskrivelse: Systemet skal kunne integrere til de ESDH-systemer i de kommuner, der har indgået kontrakt med Kunden om anvendelse af Systemet, og som ved igangsættelse af Fase 2 (dog tidligst primo ) lever op til kravet om snitfladestandard (se Krav 138). Krav 148. Beskrivelse af den fælles ESDH-integration Kategori: Info Type: Beskrivelse: Leverandøren skal nøje skitsere og beskrive funktionaliteten og arkitekturen af Sags- og dokumentarkivet, herunder: Muligheden for, enten fra starten at understøtte hændelser fra ESDH-systemerne mod Systemet (for eksempel ved modtagelse af et dokument via kommunens ESDH-system) eller alternativt, hvilke tiltag der skal til for på sigt, at udvide Systemet med hændelser (med baggrund i den valgte sags- og dokumentstandard). Beskrive, om der er relevante områder af afsnit 5.13, 6 og F o r t r o l i g t S i d e 108/ d e c e m b e r

109 8 der ikke opfyldes (forudsat der ikke er tale om minimumskrav). Mulighed for unik identifikation af sager og dokumenter (UUID). Krav 149. Mulighed for tilknytning af yderligere ESDH-systemer Kategori: Option Type: 2 Beskrivelse: Leverandøren skal prissætte, hvad det vil koste for ét kommunalt ESDH-system, som opfylder kravene til standard snitflader (jf. Krav 138), at blive tilknyttet Systemet efter Fase 2 er færdiggjort, og i den forbindelse tydeligt angive de forudsætninger, der danner baggrund for prissætningen. Krav 150. Mulighed for tilknytning af ESDH-systemer med proprietære snitflader Kategori: Option Type: 2 Beskrivelse: Leverandøren skal beskrive og prissætte udvidelsen af Orkestreringskomponenten med en transformeringsmekanisme, som giver mulighed for at tilslutte kommunale ESDH-systemer, som ikke opfylder kravene til åbne standarder (se Krav 138). Derudover skal Leverandøren udfra en række meget veldefinerede forudsætninger prissætte tilknytningen (design, udvikling og idriftsættelse af en transformation) af ét ESDH-system med proprietære snitflader til Systemet 31. Leverandøren skal beskrive og prissætte konsekvenser for driftsmiljøet ved idriftsættelse af nye transformationer samt tydeligt angive de forudsætninger, der danner baggrund for prissætningen. Krav 151. Genbrug af det Interne Arkiv Kategori: Krav Type: Ikke funktionelt 2 Beskrivelse: Det Interne Arkiv, udviklet som en del af grundfunktionaliteten, skal genbruges som et element i Sags- og dokumentarkivet 31 Det er vigtigt, at forudsætninger er nøje beskrevet i optionen, da disse forudsætninger vil blive benyttet i forbindelse med ændringshåndtering på det tidspunkt, hvor der skal integreres til et navngivet ESDH-system. F o r t r o l i g t S i d e 109/ d e c e m b e r

110 (jævnfør den konceptuelle arkitekturtegning ovenover) og det skal sikres, at de sager og dokumenter, der allerede er oprettet, ikke går tabt. Krav 152. Beskrivelse af genbrug af det Interne Arkiv Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvordan det Interne Arkiv vil blive genbrugt i Sags- og dokumentarkivet og hvorledes det sikres, at sager og dokumenter oprettet som en del af grundfunktionaliteten ikke går tabt. Krav 153. Det Interne Arkiv bruges til performanceforbedring Kategori: Krav Type: Ikke funktionelt 2 Beskrivelse: Det Interne Arkiv skal kunne bruges til performanceforbedrende overførsel af sager og dokumenter mellem Systemet og det kommunale ESDH-system, såfremt kommunikationen med kommunale ESDH-systemer viser sig, at være meget langsom og dermed forstyrrende for aktørens oplevelse af Systemet. Krav 154. Overflytning af sager og dokumenter til kommunale ESDHsystemer Kategori: Krav Type: Ikke funktionelt 2 Beskrivelse: Når Orkestreringskomponenten registrerer, at den centrale administrator har registreret et nyt kommunalt ESDH-system, skal overflytning af sager og dokumenter fra interne arkiver til eksterne ESDH-systemer påbegyndes. Overflytningen skal foretages på en sådan måde, at data ikke mistes undervejs. Krav 155. Brugertransparens ved skift mellem ESDH-systemer Kategori: Krav Type: Ikke funktionelt 2 Beskrivelse: Leverandøren skal sikre, at den funktionalitet der stilles til rådighed for brugerne af Systemet er ens, ligegyldigt om der anvendes det Interne Arkiv eller et kommunalt ESDH-system. F o r t r o l i g t S i d e 110/ d e c e m b e r

111 Krav 156. Beskrivelse af overflytning af sager og dokumenter Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvordan overflytning fra det Interne Arkiv til det kommunale ESDH-system vil ske, med udgangspunkt i: At sager, sagsdata, journalarksnoter, dokumenter, indskannede dokumenter, e-post, elektroniske blanketter, billedfiler mm., skal kunne konverteres fra Systemets sagsog dokumentarkiv til kommunens ESDH-system. At overflytningen af dokumenter kan foretages af performanceforbedrende hensyn. At sager og dokumenter ikke risikerer at blive mistet undervejs. At brugertransparensen sikres ved skift af ESDH-system. Da sager og dokumenter kan indeholde personfølsomme informationer er det vigtigt, at de udveksles sikkert mellem Systemet og det kommunale ESDH-system, og at kommunikationen er sikret mod både utilsigtet adgang, tab af data og midlertidig manglende adgang til kommunale ESDH-systemer. Det er ligeledes vigtigt, at Leverandøren forholder sig til, hvordan der i Sags- og dokumentarkivet sker en håndtering af de sikkerhedsmæssige krav, der vil være i forhold til de kommunale ESDH-systemer, jf. Persondataloven i afsnit 9.7 og afsnit Krav 157. Sikker udveksling af data til og fra et kommunalt ESDHsystem Kategori: Krav Type: Ikke funktionelt 2 Beskrivelse: Sager og dokumenter skal udveksles sikkert til og fra et kommunalt ESDH-system således, at kommunikationen er sikret mod både utilsigtet adgang samt tab af data (garanteret sikker levering) og overholdelse af lovgivning (jf. Persondatalovens krav i afsnit 9.7). Krav 158. Beskrivelse af sikringen af data i Sags- og dokumentarkivet Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvordan det sikres at sager og dokumenter, som kan indeholde personfølsomme informationer, behørigt udveksles med det kommunale ESDH-system. Følgende F o r t r o l i g t S i d e 111/ d e c e m b e r

112 områder bør beskrives: Sikring af garanteret modtagelse, behandling og videresendelse af informationer til og fra kommunale ESDH-systemer uden tab af data. Sikring af tilgængelighed af Sags- og dokumentarkivet således, at den øvrige del af Systemet ikke oplever uhensigtsmæssige nedetider i forhold til ESDH-integrationen. Sikring af gensendelse af sager og dokumenter til kommunale ESDH-systemer, såfremt disse systemer ikke er tilgængelige i en periode. Sikring af, at Systemet ikke oplever dårlig performance, såfremt forbindelsen til kommunale ESDH-systemer er dårlig. Sikring af logning af de transaktioner, der er foretaget i ESDHintegrationen. Sikring af, at modtagelse, behandling og videresendelse af sager og dokumenter er skaleret til at omfatte de datamængder, der er relevante for Systemet nu og uden store konsekvenser kan udvides til at omfatte flere kommuner og ESDH systemer i fremtiden. Krav 159. Sikring af data mellem Systemet og Sags- og dokumentarkivet Kategori: Krav Type: Ikke funktionelt 2 Beskrivelse: Overførslen af sager og dokumenter mellem Systemet og Sagsog dokumentarkivet skal sikres med certifikater og på et sådant niveau, at personfølsomme data ikke risikerer at blive kompromitteret (eksempelvis OIORASP, OIOIDWS, OWSA model T) jævnfør persondataloven i afsnit 9.7. Krav 160. Beskrivelse af sikker transport af data til og fra de kommunale ESDH-systemer Kategori: Info Type: Beskrivelse: Leverandøren skal skitsere og beskrive den valgte sikring af transport mellem Systemet og de kommunale ESDH-systemer, herunder hvordan det håndteres, såfremt de kommunale ESDHsystemer har anderledes krav til adgangs- og rettighedsstyring. Beskrivelsen bør inkludere, hvordan samspillet er med hele den valgte sikkerhedsarkitektur på Systemet så det synliggøres, at den samlede sikkerhedsarkitektur bliver en konsistent løsning, som beskrevet i afsnit F o r t r o l i g t S i d e 112/ d e c e m b e r

113 Sags- og dokumentarkivets snitflader stilles til rådighed Med baggrund i Sags- og dokumentarkivets relevans for andre leverandører ønsker Kunden, at den snitflade (snitfladen betegnet som Fælles ESDH snitflade i Figur 26) som Sags- og dokumentarkivet udstiller, skal gøres tilgængelig for andre leverandører. Krav 161. Udlevering af snitfladebeskrivelser til Sags- og dokumentarkivet Kategori: Krav Type: Ikke funktionelt 2 Beskrivelse: Leverandøren skal uden vederlag stille snitfladebeskrivelser af Sags- og dokumentarkivets snitflade (snitfladen betegnet som Fælles ESDH snitflade i Figur 26) til rådighed for andre leverandører Journalarkskomponenten Journalarkskomponenten er en del af grundfunktionaliteten (Fase 1). Der er inkluderet en Journalarkskomponent i Systemet af to grunde: Sagsbehandleren har brug for et sted at gøre af de løse noter, fx i forbindelse med telefonsamtaler (traditionelt journalark). Sagsbehandleren har brug for at kunne se, hvad der er sket i en sag i kronologisk rækkefølge og på tværs af enkeltsager (log). Sagsbehandlerens primære indgang til sagsbehandling i Systemet skal være via Sagsstyringskomponenten, hvorfra det bedste overblik over sagens fremadrettede forløb skal gives. Når sagsbehandleren benytter Journalarkskomponenten som et traditionelt journalark og opretter noter, skal vedkommende kunne vælge en notetype og tilføje en overskrift og tekst til noten, jævnfør nedenstående eksempel på skærmbillede: F o r t r o l i g t S i d e 113/ d e c e m b e r

114 Figur 27 - Journalarksnote i Journalarkskomponenten Når sagsbehandleren benytter Journalarkskomponenten som en log, fungerer journalarket som en visning, der skal give overblik over journalarksnoter, dokumenter samt afgørelser og aktiviteter. Denne visning kan efterfølgende sammenstilles for enkeltsager, et barn, en familie eller for en udvalgt periode. Aktiviteter andre steder i Systemet registreres automatisk i Journalarkskomponenten ved, at Systemet automatisk genererer noter i journalarket om disse hændelser. De enkelte posteringer kan vises kronologisk eller sorteres i kategorierne dokumenter, noter, afgørelser og aktiviteter, jf. nedenstående eksempel på skærmbillede: F o r t r o l i g t S i d e 114/ d e c e m b e r

115 Figur 28 - Overblik over journalarksnoter Visninger kan gemmes som dokumenter og om nødvendigt udprintes således, at de kan indgå i dokumentationen på sagen. Nedenstående model illustrerer samspillet mellem Journalarkskomponenten, de øvrige komponenter i Systemet og sagsbehandlerne. Eksempelvis opretter sagsbehandlerne journalsarksnoter og Systemet genererer noter med datostemplinger (om fx afgørelser i sagsforløbet) samt noter med registrering af ændringer i familieforhold: Figur 29 - Samspillet mellem Journalarkskomponenten og Systemet F o r t r o l i g t S i d e 115/ d e c e m b e r

116 Kravene til journalarket er, af Kunden, udviklet med baggrund i KL-projektet vedrørende God administrativ praksis for journalark på det sociale område 32. Krav 162. Journalarksnoter skal knyttes til enkeltsager Beskrivelse: Det skal være muligt at oprette en journalarksnote, der knytter sig til én eller flere enkeltsager i Sags- og dokumentarkivet. Krav 163. Sagsbehandler vælger sag til journalarksnoten Beskrivelse: Som udgangspunkt skal Systemet være indstillet til at tilføje journalarksnoten til den enkeltsag som er aktiv, men sagsbehandleren skal kunne vælge at føje journalarksnoten til en anden enkeltsag, fx under en anden delproces. Krav 164. Struktur for journalarksnoter Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal sikre, at journalarksnoter uafhængigt af typen har samme struktur, og som minimum indeholder angivelse af følgende: Id for enkeltsag. CPR-nummer. KLE-nummer. Sagsbehandlerinitialer. Dato. Journalarksnotetype. Overskrift (fritekst). Notattekst (fritekst). Muligvis et kommuneid. Journalarksnoter kan genereres af Systemet eller aktøren. Krav 165. Systemgenerering af journalarksnoter Kategori: Krav Type: Ikke funktionelt 32 jf. underbilag 3.1M. F o r t r o l i g t S i d e 116/ d e c e m b e r

117 Beskrivelse: Systemet skal automatisk generere journalarksnoter ved for eksempel: Sagsstyringsaktiviteter i Sagsstyringskomponenten, fx beslutninger og afgørelser, procesinitiering og afslutning. Registrering af dokumenter i Sags- og dokumentarkivet. Ændringer i stamoplysninger på barnet/den unge (og barnets/den unges relationer) i Familieadministrationskomponenten. Krav 166. Funktionalitet i teksteditor Beskrivelse: Teksteditoren i Journalarkskomponenten skal have tekstbehandlingsfunktionalitet, fx fed, understregning, indrykning, stavekontrol, udskrivning samt kopiering af tekst. Krav 167. Indhold i journalark Beskrivelse: Journalarket skal indeholde 3 typer information: Metadata, der refererer til dokumenter lagret i Sags- og dokumentarkivet, bl.a. dokumenttitler og oplysninger om afsender/modtager. Noter med afsæt i sagsbehandlerens notatpligt, bl.a. telefonsamtaler, kontakt og personligt fremmøde, hvor sagsbehandleren skal kunne angive notetypen ved at vælge, fx fra en dropdownliste. Sagsstyringsstempler, fx initierings/afslutningsdatoer, milepæle og afgørelser mv. fra Systemet. Krav 168. Sagsbehandler fremsøger indhold til journalark Beskrivelse: Journalarkskomponenten skal indeholde en søgefunktionalitet, hvor sagsbehandleren fremsøger indhold (jævnfør Krav 167) til journalark, med følgende søgekriterier: En sag for den enkelte person. På tværs af flere sager for den enkelte person. På tværs af flere personers sager, dog begrænset til familiesager (fx relevant i familiesager/børn og unge-sager). Ovenstående skal kunne søges i kombination med: F o r t r o l i g t S i d e 117/ d e c e m b e r

118 Indenfor datointerval. På KLE-nummer. I fritekst, til søgning i tekst, i titelfeltet eller i notatfeltet. Krav 169. Rækkefølge og sortering af journalarksnoter Beskrivelse: Journalarket skal automatisk fremkomme i omvendt kronologisk rækkefølge efter dato. Metadata for journalarksnoter skal i øvrigt kunne anvendes som sorteringskriterier ved visning af journalarket. Krav 170. Sagsbehandler får vist detaljer i den enkelte journalarksnote Beskrivelse: Sagsbehandleren skal kunne få vist detaljer om de enkelte journalarksnoter, der sammenstilles i et journalark. Krav 171. Link til dokument Beskrivelse: Systemet skal kunne oprette et link fra en journalarksnote til et dokument, så det kan åbnes direkte fra noten. Krav 172. Ændringer i familiens stam- og grundoplysninger i Familieadministrationskomponenten Beskrivelse: Når en sagsbehandler gemmer en ny udgave af et datasæt af familieoplysninger (inklusive det første datasæt overhovedet) eller der modtages oplysninger maskinelt fra CPR-datakilden, skal Systemet indføre de nye og tidligere oplysninger om de personer, som stamdata vedrører i en journalarksnote. Familieoplysningerne skal registreres for: Barnet/den unge samt vedkommendes biologiske forældre i det tilfælde, hvor der er ændringer i den biologiske familie, eller For barnet/den unge samt de(n) person(er), som barnet/den unge bor sammen med, hvor der er ændringer i familien på F o r t r o l i g t S i d e 118/ d e c e m b e r

119 barnets/den unges officielle adresse, fx far eller mor og deres eventuelle partnere. Krav 173. Parameterstyring af lås for redigering af journalsarksnote Beskrivelse: Systemet skal understøtte, at en central og kommunal administrator kan fastsætte parametre for, hvordan og hvornår en journalarksnote skal låses for redigering. Eksempelvis skal en systemoprettet journalarksnote være låst for redigering, hvorimod en journalarksnote oprettet af sagsbehandleren skal kunne fastsættes til, at sagsbehandleren kan vælge enten at låse den umiddelbart efter oprettelsen eller udskyde låsningen. Det skal fremgå at loggen, hvad der sker med journalarksnoten i den periode, hvor den ikke er låst. Journalarkskomponenten skal registrere journalarksnoter på de sager og dokumenter, der er i Sags- og dokumentarkivet som skitseret i følgende figur: Figur 30 Overførsel af journalark til sag og dokumentarkiv. F o r t r o l i g t S i d e 119/ d e c e m b e r

120 Krav 174. Beskrivelse af Journalarkskomponenten Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive funktionaliteten og arkitekturen i Journalarkskomponenten. Samspillet mellem Journalarkskomponenten og Sags- og dokumentarkivet skal nøje beskrives. Leverandøren skal endvidere beskrive, om der er relevante områder af afsnit 5.13, 6 og 9 (forudsat der ikke er tale om minimumskrav) Journalarksnotetyper Det skal være muligt at klassificere alle journalarksnotater med en kategoriserende betegnelse, som sagsbehandleren herefter kan anvende som søge- og opstillingskriterier, når Systemet skal danne journalark til skærmvisning eller print. Sagsinformationen skal så vidt muligt klassificeres automatisk, fx når journalarket har et notat om, at der er ajourført personoplysninger fra CPR-datakilden eller når en delproces er afsluttet. Sagsbehandlerne kan derefter fremfinde data ved en søgning på metadataniveau, fx information klassificeret med Familieoplysninger. Journalarksnoter kan være brugergenererede eller systemgenererede. Krav 175. Tilpasning af journalarksnotetyper Beskrivelse: Systemet skal understøtte, at central og kommunal administrator via en administrationsklient kan tilføje, ændre og deaktivere journalarksnotetyper. Som default-opsætning skal som minimum være følgende journalarksnotetyper: Indgående brev, Underretningsskrivelse, Ansøgning, Anke, Fax, Webhenvendelse, , Udgående brev, Partshøring, Dataindsamling, Notat/dokument, Vurdering, Henvendelsesreferat, Telefonreferat, Samtalereferat, Besøgsreferat, Mødereferat, Erindringsnote, Aftale og Øvrige Økonomikomponenten Håndtering af økonomiske fremskrivninger er en del af grundfunktionaliteten (Fase 1), mens håndtering af det faktiske forbrug og udsendelse af opkrævninger/betalinger (som option) via integration til kommunernes økonomisystemer er en del af Fase 3. F o r t r o l i g t S i d e 120/ d e c e m b e r

121 Økonomien spiller en stor rolle i kraft af, at nogle af Systemets succeskriterier hænger nøje sammen med økonomirapporteringen. Der er som udgangspunkt to overordnede behov for Økonomikomponten i Systemet: For den enkelte sagsbehandler er der behov for, at kunne få et samlet overblik over det enkelte barns - og familiens økonomi. Dvs. hvor meget koster de samlede indsatser for det enkelte barn i givne tidsintervaller, fx pr. måned eller pr. år. Den enkelte sagsbehandler kan derudover have behov for at kunne igangsætte en betaling eller en opkrævning fra Systemet. For den administrative og politiske ledelse er der behov for, at kunne få et samlet overblik over, hvor meget de samlede indsatser for alle børn koster og at kunne sammenholde dette med et budget. Ligeledes skal mængdeudviklinger kunne følges, således at antal helårspersoner i den enkelte indsatstype skal kunne opgøres månedsvis og årligt. Der er behov for, at få et overblik over økonomien løbende: Som beslutningsstøtte, før indsatser iværksættes (dvs. når sagsbehandleren overvejer indsatser, ofte på baggrund af gennemsnitspriser). I forbindelse med omdisponeringer frem til endelig afgørelse. For at følge udviklingen i de faktiske omkostninger efter afgørelsen er truffet, hvor der er valgt konkret indsats og aftale er indgået. Nedenfor vises diagrammatisk økonomiprocessernes placering i den samlede hovedproces: Figur 31 - Økonomiprocessernes placering i den samlede hovedproces F o r t r o l i g t S i d e 121/ d e c e m b e r

122 Der er behov for en dataudveksling mellem Systemet og kommunernes økonomisystemer. Denne dataudveksling illustreres i følgende figur: Figur 32 Samspil mellem Systemet og kommunens økonomisystem Økonomi-integrationen vil have ansvaret for dataudvekslingen til kommunernes økonomisystemer og denne er gennemgået nærmere i afsnit Undervejs i visitationsprocessen, inden en indsats sættes i værk for barnet/den unge, er der behov for at kunne se de samlede forventede omkostninger for indsatserne til barnet/den unge, og sammenholde dette med et overblik over hele familien. Sagsbehandleren skal kunne tilføje og fjerne indsatser og løbende se, hvordan dette ændrer de samlede forventede omkostninger (= simulering af et forbrug). Dvs., at der for det enkelte barn/den unge opstilles et periodiseret forventet forbrug der viser, hvordan de enkelte indsatser forventes at ville påvirke afdelingens samlede budget i den periode, hvor barnet/den unge er i Systemet (modtager en eller anden form for indsats). Dette simulerede forbrug kaldes fremskrivninger og kan strække sig over flere kalender- og budgetår. Kravene til fremskrivninger er gennemgået i afsnit Når indsatserne sættes i værk og afregnes, er der behov for at kunne sammenholde den aktuelle/realiserede pris for indsatsen, med det fremskrevne beløb. I hele opfølgningsprocessen skal man kunne få overblik over økonomien. Det faktiske forbrug for indsatser vedrører bl.a. de fakturaer, som kommunerne modtager fra institutioner eller de lønudgifter, som afholdes etc. Der er typisk adskillige måneders forsinkelser på afregningen af indsatserne, og det er derfor en udfordring at få overblik over økonomien, hvis man kun benytter det faktiske forbrug i det kommunale økonomisystem. Fremskrivningerne kan bruges som hjælp til løbende at beregne budgettet. Det faktiske forbrug fremgår af kommunens økonomisystem som finansposteringer, og det er disse informationer, der overføres til Systemet. Hent af finansposteringer er gennemgået mere detaljeret i afsnit F o r t r o l i g t S i d e 122/ d e c e m b e r

123 Hvis sagsbehandleren (eller en økonomimedarbejder) kan igangsætte udbetalinger og opkrævninger fra Systemet, bliver det muligt at periodisere den enkelte betaling i Systemet. Dette vil give en administrativ lettelse, da det ellers bliver nødt til at ske i det kommunale økonomisystem ved fakturamodtagelse, således at en økonomimedarbejder her manuelt fordeler beløbene på regninger på de måneder, hvor forbruget har været. Muligheden for at igangsætte betalinger vil også indebære en lettelse i og med: At data ikke skal genindtastes i betalingssystemer. At der ikke opstår fejl i forbindelse med genindtastninger. Udbetalinger og opkrævninger er gennemgået mere detaljeret i afsnit Desuden er Use case 021 Udarbejd handleplan, underbilag 3.1F, et eksempel på, hvor i det socialfaglige sagsforløb økonomien især spiller en rolle i sagsbehandlerens beslutningsproces. Økonomikomponenten i Systemet vil blive håndteret i flere tempi: Fase 1 vil indeholde mulighed for økonomiske fremskrivninger. Fase 3 vil gøre det muligt at sammenholde fremskrivninger med det faktiske forbrug. Fase 3 vil gøre det muligt at effektuere betalinger og opkrævninger. Denne funktionalitet er medtaget som en option. De tre områder beskrives i de følgende afsnit. Funktionaliteten med at sammenholde fremskrivninger med det faktiske forbrug og effektuere betalinger og opkrævninger, vil kræve en kommunikation med kommunernes økonomisystemer, dette gennemgås via Økonomi-integrationen i afsnit Økonomiske fremskrivninger De økonomiske fremskrivninger i Systemet svarer til følgende delmængde af den samlede økonomifunktionalitet: Figur 33 Økonomiske fremskrivninger i Systemet Fremskrivninger sammensættes med informationer om de priser, som sagsbehandleren selv angiver i Systemet. Det gælder både udgifter til indsatser, fx bevilling af tøj og lommepenge eller indtægter i forbindelse med indsatser, fx egenbetaling eller statsrefusion (ved særligt dyre enkeltsager). F o r t r o l i g t S i d e 123/ d e c e m b e r

124 Fremskrivninger opgøres med udgangspunkt i Systemets indsatsgrupper. Denne oversigt over indsatser er mere detaljeret end lovgivningens opdeling i hovedparagraffer. Der er 6 indsatsgrupper, der hver indeholder en række indsatser, se DUBUblanket 20, underbilag 3.1E. En fremskrivning kræver, at alle indsatser har både en start- og en slutdato indenfor hvilke, der forventes udgifter. Engangsudgifter har således samme start- og slutdato. Desuden skal fremskrivningen både kunne håndtere priser opgjort pr. dag og priser opgjort pr. måned. Helårspersoner beregnes som antal dage i en indsats, således at fx 15 dage kun tæller som ½ helårsperson i en given måned. Nogle indsatser bevilges ikke i dage, fx enkeltudbetalinger til dækning af merudgifter. Disse indsatser tælles som antal bevillinger pr. måned. Den enkelte fremskrivning opstilles pr. CPR-nr. Desuden skal det være muligt, at få overblik over økonomien på hele familien, beskrevet i Use Case 021 Udarbejd handleplan, underbilag 3.1F. De enkelte fremskrivninger skal summeres op, således at det er muligt for fx en leder at få overblik pr. afdeling eller for hele kommunen, pr. kontonummer - over: Fremskrivninger af barnets økonomi per tilbud, per indsats, pr. indsatsgruppe og barnets samlede økonomi per måned og per år. Fremskrivninger af familiens økonomi per tilbud, per indsats, pr. indsatsgruppe og familiens samlede økonomi per måned og pr år. Fremskrivninger per ydelse og tilbud per måned og per år. Fremskrivninger per ydelse og tilbudsgruppe per måned og per år. Opgørelse af helårspersoner per ydelse og tilbud, per ydelse og tilbudsgruppe, per måned og per år. Krav 176. Sagsbehandleren skal kunne få økonomioplysninger om fremskrivninger af omkostninger Beskrivelse: Systemet skal stille funktionalitet til rådighed således, at sagsbehandleren kan få økonomioplysninger om fremskrivninger, som beskrevet i afsnittet ovenfor. F o r t r o l i g t S i d e 124/ d e c e m b e r

125 Krav 177. Sagsbehandleren angiver beregningsgrundlag for fremskrivninger Beskrivelse: En sagsbehandler skal kunne angive, hvordan fremskrivning skal beregnes - på baggrund af priser opgjort pr. dag, pr. måned eller pr. enkeltbetaling - og beregninger skal kunne opgøres i helårspersoner eller antal bevillinger. Krav 178. Sagsbehandleren ser fremskrivninger for enkelt personer og familier Beskrivelse: Systemet skal kunne vise såvel fremskrivninger for personer (CPR-nr. niveau) som for familier. Sammenstillingen på familien skal ske med basis i registreringen i Familieadministrationskomponenten. Krav 179. Prisregulering på iværksatte indsatser Beskrivelse: Prisregulering på iværksatte indsatser må kun ske pr. den dato, hvor reguleringen træder i kraft. Dvs. fremskrivningen må ikke rettes som helhed, da perioden bagud fortsat skal stå med den faktiske pris for denne periode. Krav 180. Betaling mellem kommuner - betalingstilsagn Beskrivelse: På den enkelte sag skal det være muligt at angive, om man har betalingstilsagn fra anden kommune, således at det kan indgå i fremskrivningen, at kommunens egen udgift bliver 0 kr. Betalingstilsagnet afgives altid på CPR-nr.-niveau, så denne angivelse skal ske ved en markering (fx Ja/nej felt med default Nej) Det faktiske forbrug Inkorporeringen af det faktiske forbrug i Systemet, sammenholdt med fremskrivninger, giver anledning til følgende delmængde af den samlede økonomiske funktionalitet i Systemet: F o r t r o l i g t S i d e 125/ d e c e m b e r

126 Figur 34 Hent af det faktiske forbrug sammenholdt med fremskrivninger Ovenstående figur illustrerer dataudvekslingen, som skal finde sted mellem Systemet og kommunens økonomisystem, hvor finansposter - dvs. det faktiske forbrug - skal kunne importeres til Systemet fra kommunens økonomisystem således, at disse kan sammenholdes med Systemets fremskrivninger. Sagsbehandleren må i Systemet ikke kunne ændre på de beløb, som Systemet modtager fra det kommunale økonomisystem. Såfremt der skal rettes i beløb fra det kommunale økonomisystem, skal disse rettelser altid ske direkte i det kommunale økonomisystem. I økonomisystemerne er finansposteringerne organiseret i en kontoplan, og hver postering (der dækker en vilkårlig periode) kan henføres til et specifikt CPR-nr. I Systemet er det faktiske forbrug organiseret efter tilbud og ydelser, lovhjemmel og CPR-nr. Desuden er den enkelte omkostning henført til en periode typisk pr. måned. For at kunne henføre finansposteringer fra økonomisystemerne til fremskrivningerne i Systemet, skal der være overensstemmelse mellem kontoplanerne og tillæg for lovhjemmel i Systemet, jf. datastandardisering af centrale DUBU-begreber 33. Dette er en forudsætning for, at kunne få det faktiske forbrug ind i Systemet. Ansvaret for at sammenholde kontoplanerne i det kommunale økonomisystem med Indenrigsministeriets autoriserede kontoplan for udsatte børn og unge-fagområdet 34 befinder sig hos kommunerne, mens Leverandøren har ansvaret for at implementere mapningen. Muligheden for mapning mellem økonomisystemer og Systemet skitseres i følgende figur: 33 jf. underbilag 3.1M F o r t r o l i g t S i d e 126/ d e c e m b e r

127 Figur 35: Skematisk oversigt, der viser mapning mellem økonomisystem og Systemet Ved modtagelse af fakturaer i det kommunale økonomisystem, skal opsplitningen af fakturaen i finansposteringer (kontonummer, CPR-nr. og periode) derfor ske ved oversendelse fra det kommunale økonomisystem til Systemet. Når økonomimedarbejderen (eller sagsbehandleren) skal attestere en faktura, er det muligt at se i Systemet, om den pågældende indsats er bevilget. I de situationer, hvor medarbejderen ikke foretager den kontrol, vil eventuelle fejlbehæftede betalinger dog alligevel blive opdaget, da Systemet kun vil modtage betalinger på bevilgede indsatser. For at kunne sammenstille det faktiske forbrug med fremskrivningerne, skal finansposteringerne, der modtages fra de kommunale økonomisystemer, indeholde følgende informationer: Henførbarhed til CPR-nr.: det skal være muligt, at henføre et fakturabeløb til et givent barn hvilket betyder, at familierettede ydelser skal splittes op, så alle i familien, der har modtaget familieydelsen, bliver registreret med en procentdel af den samlede udgift. Henførbarhed til given indsats: det skal være muligt at henføre et fakturabeløb til et givent kontonummer for et givent barn. Udgifter skal konteres på den korrekte gruppering med angivelse af institutionens navn, have en lokal udbygning af Socialministeriets kontoplan, så forbruget (herunder egenbetaling og statslig og mellemkommunal refusion) fordeles på indsatstyper. Henførbarhed til periode: Det skal være muligt at henføre en postering til en given periode, dvs. at omkostninger skal være periodiseret. Det kræver, at det kommunale økonomisystem leverer periodiserede finansposter. Hvis det kommunale økonomisystemet ikke kan håndtere dette (eller hvis kommunerne ikke anvender omkostningsstyring) må det foretages ved, at økonomimedarbejder manuelt taster det ind i det kommunale økonomisystem. Tilstedeværelsen og kvaliteten af disse informationer afhænger af, dels hvordan F o r t r o l i g t S i d e 127/ d e c e m b e r

128 fakturaer er specificeret over for kommunen, dels den enkelte kommunes registreringspraksis. Såfremt finansposteringer i det kommunale økonomisysteme ikke overholder disse tre typer af henførbarhed, vil de ikke kunne overføres til Systemet. Dette er dog op til kommunerne at sørge for og ikke Leverandørens ansvar. Krav 181. Sagsbehandleren skal kunne få økonomioplysninger om det faktiske forbrug 3 Beskrivelse: Systemet skal stille funktionalitet til rådighed, således at sagsbehandleren kan få økonomioplysninger omkring det faktiske forbrug, som beskrevet ovenfor. Krav 182. Sagsbehandleren skal kunne se det faktiske forbrug for enkeltpersoner og familier 3 Beskrivelse: Systemet skal kunne vise det faktiske forbrug for enkeltpersoner (CPR-nr. niveau) og for familier. Sammenstillingen på familien skal ske med basis i registreringen i Familieadministrationskomponenten. Krav 183. Sagsbehandleren kan modregne det faktiske forbrug på aftalte fremskrivninger 3 Beskrivelse: Det faktiske forbrug skal kun kunne modregnes en fremskrivning, der er aftalt/kontrakt på, jf. DUBU-blanket 3.a, felt 31, underbilag 3.1E. Krav 184. Sagsbehandleren kan manuelt sagsbehandle afviste posteringer 3 Beskrivelse: Hvis en postering fra det kommunale økonomisystem ikke kan modtages i Systemet (fordi Systemet afviser på grundlag af modregning af faktisk forbrug på aftalte fremskrivninger eller Krav 185), skal den afviste postering fremgå, så den kan sagsbehandles manuelt efterfølgende. F o r t r o l i g t S i d e 128/ d e c e m b e r

129 Krav 185. Mapning af det kommunale økonomisystems finansposteringer Kategori: Krav Type: Ikke funktionelt 3 Beskrivelse: Systemet skal ved modtagelse af posteringer fra det kommunale økonomisystem kunne mappe finansposteringerne til Systemets faktiske forbrug relateret til CPR-nr., indsatstype efter kontonummer og periode. Systemet har ansvaret for mapningen mellem Systemet og det kommunale økonomisystem, og skal derfor have kendskab til økonomisystemets kontoplan Betalinger og opkrævninger Hvis sagsbehandleren (eller en økonomimedarbejder) kan igangsætte udbetalinger og opkrævninger fra Systemet, bliver det muligt at periodisere den enkelte betaling i Systemet. Denne funktionalitet er visualiseret i Figur 32 Samspil mellem Systemet og kommunens økonomisystem. Når betalingen igangsættes, sætter aktøren periode (start- og slutdato) på betalingen således, at når det faktiske forbrug kommer tilbage til Systemet, er perioden allerede kendt i Systemet. Sagsbehandleren kan have behov for at igangsætte en udbetaling (enkelt eller løbende) eller en opkrævning direkte fra Systemet. Sagsbehandleren kan fremsætte en anmodning i Systemet om, at en udbetaling eller opkrævning skal foretages. Igangsætning af udbetaling skal kun være mulig hvis den indsats, som betalingen/opkrævningen vedrører, er markeret som aftalt. Selve udbetalingen og opkrævningen vil blive håndteret i kommunens økonomisystem, når der er foretaget godkendelse af udbetalingen. Udbetalingen og opkrævningen skal kunne foretages af en sagsbehandler eller økonomimedarbejder. Der skal dog være 2 personer involveret i processen, jævnfør afsnit 9.9, om overholdelse af regnskabsbekendtgørelsen. I forbindelse med, at sagsbehandleren igangsætter udbetalingen eller opkrævningen, sættes periode på, og ved løbende udbetalinger skal det være muligt at sætte udbetalingsterminer på. Systemet kan håndtere periodiseringen uden at involvere det kommunale økonomisystem. Betaling og opkrævning håndteres forskelligt i de enkelte kommuner. Det er et ønske, at sagsbehandleren involveres i disse processer. Derfor skal Systemet (som option) kunne understøtte et workflow, som styrer udveksling af betalingsgodkendelser og opkrævningsanmodninger. F o r t r o l i g t S i d e 129/ d e c e m b e r

130 Krav 186. Sagsbehandleren skal kunne igangsætte betalinger og opkrævninger Kategori: Option Type: 3 Beskrivelse: Systemet skal stille funktionalitet til rådighed, således at sagsbehandleren kan igangsætte betalinger og opkrævninger. Krav 187. Betalingsgodkendelser og opkrævningsanmodninger Kategori: Option Type: 3 Beskrivelse: Leverandøren skal tilbyde workflow og snitfladesupport, således at Systemet automatisk adviserer aktøren, når vedkommende skal godkende en betaling/opkrævning Integration til kommunale økonomisystemer I forbindelse med hent af det faktiske forbrug og igangsættelse af betalinger og opkrævninger er der behov for udveksling af data med kommunernes økonomisystemer i form af Økonomi-integrationen. Kunden har lavet en undersøgelse af kommunernes brug af økonomisystemer og har identificeret 3 økonomisystemer, som tilsammen dækker 80 % af kommunernes behov. Det drejer sig om KMD Opus, KMD ØS og Fujitsu Prisme. Med baggrund i dette er det besluttet, at disse økonomisystemer skal indgå som fundament i Økonomi-integrationen, og at dataudveksling med andre økonomisystemer af relevans eventuelt kan tilkøbes som optioner senere. Følgende diagram viser den konceptuelle arkitektur for integrationen til kommunernes økonomisystemer: F o r t r o l i g t S i d e 130/ d e c e m b e r

131 Figur 36 Integrationer til kommunale økonomisystemer Diagrammet viser et udvalgt snit igennem den lagdelte arkitektur i Systemet startende med en aktør i venstre side og sluttende med et antal kommunale økonomisystemer i højre side. Den stiplede firkant illustrerer omfanget af Systemet. Som det fremgår af diagrammet, sker håndteringen af økonomi i Økonomikomponenten, som har ansvaret for at registrere økonomidata for Systemet samt at kommunikere med Økonomi-integrationen symboliseret ved den blå silo, hvor der er adgang via den Fælles økonomi snitflade. Økonomi-integrationen har ansvaret for at orkestrere adgangen til de kommunale økonomisystemer således, at Systemet altid tilgår økonomisystemerne via den samme snitflade, ligegyldigt hvilket kommunalt økonomisystem, der ønskes integreret til. Økonomi-integrationen sørger således for at transformere data til og fra den fælles økonomi-snitflade, hvorved andre snitflader end den Fælles Økonomisnitflade fremstår transparent for Systemet. Krav 188. Integration til kommunernes økonomisystemer Kategori: Minimumskrav Type: Ikke funktionelt 3 F o r t r o l i g t S i d e 131/ d e c e m b e r

132 Beskrivelse: Systemet skal kunne integrere med følgende økonomisystemer: KMD Opus. KMD ØS. Fujitsu Prisme I integrationen skal der benyttes de snitflader, som de 3 økonomisystemer udstiller: I forhold til hent af posteringer: GQ311001Q I forhold til igangsættelse af opkrævninger og udbetalinger: GF200001Q, GJ510001Q og GQ418001Q (kun relevante såfremt Krav 186 tilkøbes). Snitfladerne er vedlagt underbilag 3.1H. Krav 189. Transparent snitflade mod Systemet Kategori: Krav Type: Ikke funktionelt 3 Beskrivelse: Det skal fremstå transparent for Systemet, hvilke og hvor mange økonomisystemer Systemet skal integrere til. Systemet skal tilgå én snitflade og eventuel kompleksitet ved integrationerne til økonomisystemerne skal placeres bagved denne snitflade. Krav 190. Central administrator har adgang til at konfigurere integrationerne med de kommunale økonomisystemer 3 Beskrivelse: Den centrale administrator skal have mulighed for at konfigurere adgang til funktionalitet for de kommuner, der har en integration til deres økonomisystem. Derudover vil det være muligt for kommuner, der ikke som udgangspunkt får integration til deres økonomisystem, at importere filer med det faktiske forbrug samt som option, at udtrække betalinger og opkrævninger. I denne situation vil det dog være kommunens eget ansvar at importere henholdsvis eksportere data til og fra relevante kommunale økonomisystemer, og Kunden kan ikke garantere at de udtrukne data rent faktisk kan importeres til det kommunale økonomisystem. Krav 191. Sagsbehandler kan importere det faktiske forbrug 3 F o r t r o l i g t S i d e 132/ d e c e m b e r

133 Beskrivelse: Det skal være muligt for sagsbehandleren, at importere data vedrørende det faktiske forbrug via en kommasepareret fil, som lever op til en veldefineret struktur defineret af Leverandøren. Krav 192. Sagsbehandler kan eksportere data vedrørende betalinger og opkrævninger Kategori: Option Type: 3 Beskrivelse: Det skal være muligt for sagsbehandleren, at eksportere data vedrørende igangsættelse af betalinger og opkrævninger via en kommasepareret fil, som lever op til en veldefineret struktur defineret af Leverandøren. Krav 193. Sikring af adgang til data i Økonomi-integrationen Kategori: Krav Type: Ikke funktionelt 3 Beskrivelse: Med baggrund i blandt andet Krav 198 må kun Systemets aktører få adgang til Systemets data, og kun til de data som aktøren har rettigheder til. Krav 194. Sikring af overførsel af data mellem Systemet og Økonomiintegrationen 3 Beskrivelse: Overførslen af data mellem Systemet og Økonomi-integrationen skal sikres med certifikater og på et sådant niveau, at data ikke risikerer at blive kompromitteret (eksempelvis OIORASP, OIOIDWS, OWSA model T, OIOREST 35 ). Krav 195. Beskrivelse af integration til økonomisystemer Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvorledes Systemet integrerer til kommunernes økonomisystemer med fokus på: Arkitekturen af Økonomi-integrationen (webservices eller filoverførsel) jf. underbilag 3.1M. F o r t r o l i g t S i d e 133/ d e c e m b e r

134 Hvordan overførslen af data fra det kommunale økonomisystem påtænkes at foregå (periodisk eller lignende). Hvorvidt der vil blive lagret data fra økonomisystemerne lokalt. Hvordan mapningen mellem finansposteringer og det faktiske forbrug vil blive realiseret. Hvorledes overførsel af data fra de kommunale økonomisystemer sikres, så der undgås tab af data og det undgås, at data bliver kompromitteret. Hvordan tilgængelighed af de kommunale økonomisystemer sikres, således at Systemet ikke oplever uhensigtsmæssige nedetider i forhold til økonomisystemerne. Hvordan gensendelse af data til de kommunale økonomisystemer sikres, såfremt økonomisystemet ikke er tilgængeligt i en periode. Hvordan - og om relevant - at Systemet sikres mod dårlig performance, såfremt forbindelsen til det kommunale økonomisystem i perioder er dårlig. Hvorledes logning af de transaktioner, der sendes fra Systemet til økonomisystemet, sikres. Hvorledes det sikres, at modtagelse, behandling og videresendelse af data er skaleret og yderligere kan skaleres til at omfatte de datamængder, der er relevante for Systemet nu og i fremtiden. Hvorledes det sikres, at der opnås en samlet og konsistent sikkerhedsarkitektur, med den i Systemet valgte sikkerhedsløsning, og sikkerheden i de kommunale økonomisystemer ikke bliver kompromitteret (Jf. endvidere afsnit 9.7) Integration til et fjerde økonomisystem Som gennemgået tidligere baserer dataudvekslingen med kommunernes økonomisystemer sig på de 3 største økonomisystemer på det kommunale marked med baggrund i, at disse 3 økonomisystemer dækker 80 % af kommunernes behov. For at tilgodese de resterende kommuners behov for dataudveksling skal Leverandøren prissætte integrationen til et fjerde økonomisystem under nogle meget præcist angivne forudsætninger, som gør det muligt at estimere og prissætte integrationen, uden der direkte er sat navn på dette økonomisystem. Eventuelle afvigelser fra disse forudsætninger behandles som ændringsønsker såfremt optionen effektueres i forhold til et eller flere navngivne økonommisystemer. Følgende figur 36 skitserer, hvorledes et fjerde økonomisystem kan tilknyttes økonomiintegrationen: F o r t r o l i g t S i d e 134/ d e c e m b e r

135 Figur 37 Integrationer til fjerde økonomisystem Som figuren illustrerer, skal det fjerde økonomisystem tilkobles på samme måde som de 3 oprindelige, ved at det fjerde økonomisystem udstiller et antal webservices, hvor data transformeres til de behov, som den Fælles Økonomi snitflade har. Krav 196. Integration til fjerde økonomisystem Kategori: Option Type: 3 Beskrivelse: Leverandøren skal prissætte en integration til et fjerde økonomisystem under forudsætning af: At Kunden leverer bekrivelser af de relevante snitflader. At det fjerde økonomisystem udstiller præcis de webservices, som dækker det funktionelle og datamæssige behov som Systemet har. At der skal udvikles en transformation mellem de webservices som det fjerde økonomisystem udstiller og den snitflade, som Økonomi-integrationen udstiller mod Systemet. At denne transformation skal tilknyttes Økonomiintegrationen på samme måde, som de andre transformationer til kommunale økonomisystemer. F o r t r o l i g t S i d e 135/ d e c e m b e r

136 At kommunikation mellem Økonomi-integrationen og det fjerde økonomisystem foregår via OWSA model T 36. Leverandøren beskriver yderligere forudsætninger for prissætningen af Økonomi-integrationen for at give en så nøjagtig prissætning af optionen som muligt. Krav 197. Beskrivelse af integration til fjerde økonomisystem Kategori: Beskrivelse: Info Leverandøren skal, i sammenhæng med ovenstående option, beskrive: Integrationen til det fjerde økonomisystem i forhold til den af Leverandøren foreslåede arkitektur af den samlede Økonomi-integration. Hvilke projektaktiviteter, der skal udføres i forbindelse med afklaring, udvikling og test af integration Økonomi-integrationens snitflader stilles til rådighed Med baggrund i Økonomi-integrationens relevans for andre leverandører, ønsker Kunden, at den snitflade (snitfladen betegnet som Fælles Økonomi snitflade i Figur 356) som Økonomi-integrationen udstiller, skal gøres tilgængelig for andre leverandører. Krav 198. Udlevering af snitfladebeskrivelser til Økonomiintegrationen Kategori: Krav Type: Ikke funktionelt 2 Beskrivelse: Leverandøren skal uden vederlag stille snitfladebeskrivelser af Økonomi-integrationens snitflade (snitfladen betegnet som Fælles Økonomi snitflade i Figur 36 til rådighed for andre leverandører Blanketsystem Blanketsystemet er en del af grundfunktionaliteten (Fase 1) med undtagelse af præudfyldelse af blanketterne, som er en del af Fase 2 eller kan leveres som en del af Fase 1 sammen med den resterende del af blanketsystemet. Der skelnes mellem flere typer af blanketter i Systemet: 36 jf. underbilag 3.1M. F o r t r o l i g t S i d e 136/ d e c e m b e r

137 DUBU-blanketter, underbilag 3.1E. DUBU-blanketter øvrige, underbilag 3.1E. DUBU-outputblanketter, underbilag 3.1D. KL-blanketter eksterne blanketter De forskellige typer af blanketter, er gennemgået i afsnit 4.3 DUBU-blanketter. Alle blanketter repræsenterer data i sagsbehandlingen, data i kommunikationen mellem sagsbehandler og borger, eller data, der i medfør af sagsbehandlingen, skal indberettes til andre myndigheder. Krav 199. Der skal være adgang til blanketter Kategori: Minimumskrav Type: Ikke funktionelt Beskrivelse: Systemet skal understøtte adgang til relevante blanketter, uanset om der tale om blanketter registreret internt i Systemet eller blanketter hentet fra et eksternt blanketsystem. Krav 200. Beskrivelse af organisering og anvendelse af blanketter Kategori: Info Type: Beskrivelse: Leverandøren skal redegøre for den mest hensigtsmæssige organisering og løsning af sagsbehandlerens brug af blanketter undervejs i sagsbehandlingen Eksternt blanketsystem En del af specielt den eksterne kommunikation, håndteres gennem eksterne blanketter (KL s). Disse skal kunne hentes via et eksternt blanketsystem 37. Særligt følgende er relevante: Børn og unge Anbringelse Børn og unge Andre foranstaltninger Børn og unge Generel administration Børn og unge Nedsat funktionsevne Børn og unge Plejeforhold. I forbindelse med sagsbehandlingen vil en aktør få brug for at hente og udfylde en række forskellige blanketter. For at gøre denne proces så enkel som muligt, skal der være en integration til et eksternt blanketsystem, hvor aktøren kan hente den aktuelle blanket, der er brug for Blanketterne kan ses på jf. underbilag 3.1M. 38 Skulle Leverandøren dog, eksempelvis, have et andet (og hermed ikke eksternt) blanketsystem som opfylder de stillede krav til OIOXML opmærkede blanketter og serviceorienteret F o r t r o l i g t S i d e 137/ d e c e m b e r

138 For at lette arbejdsgangene med blanketter yderligere, skal Systemet kunne rekvirere blanketter, hvor kendt information er præudfyldt. Krav 201. Eksternt blanketsystem skal kunne levere blanketter Kategori: Krav Type: Ikke funktionelt Beskrivelse: Via et eksternt blanketsystem, skal der kunne hentes blanketter ind i Systemet til understøttelse af sagsbehandlerens arbejde 39. Krav 202. Blanketter skal være OIOXML-opmærkede Kategori: Krav Type: Ikke funktionelt Beskrivelse: Blanketter, der benyttes i Systemet, skal være OIOXML opmærkede, også når de hentes fra et eksternt blanketsystem. Krav 203. Blanketter skal kunne forudfyldes Kategori: Krav Type: Ikke funktionelt 2 eller tidligere Beskrivelse: Blanketter skal kunne forudfyldes med kendt information, for at spare aktøren for at genindtaste informationer. Krav 204. Beskrivelse af eksternt blanketsystem Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive det valgte eksterne blanketsystem og som minimum beskrive: En overordnet teknisk beskrivelse af det eksterne blanketsystem og de indeholdte blanketter. Hvordan blanketterne er opmærkede og dermed bliver arkitektur (blanketsystemet fysisk afkoblet fra resten af Systemet), vil KOMBIT ikke betragte dette som værende en dårligere teknisk løsning. Leverandøren bedes dog i sin besvarelse være opmærksom på, at definitionen af Systemet, som illustreret i referencearkitekturen i figur 43 i bilag 3.1 afsnit får en bredere udstrækning end den i udbudsmaterialet angivne. 39 Skulle Leverandøren i sine arkitekturovervejelser finde, at det er en bedre løsning at genbruge de kommunale blanketløsninger vil KOMBIT ikke betragte dette som værende en dårligere teknisk løsning, såfremt det kommer til at fremstå transparent for resten at Systemet, at der foretages decentrale integrationer (de decentrale integrationer indkapsles bag én blanketsystem snitflade). F o r t r o l i g t S i d e 138/ d e c e m b e r

139 gjort operationelle i Systemet. Hvilke typer af blanketter, der er til rådighed. Hvordan, og hvor præudfyldelsen af blanketter vil foregå i praksis. Den teknologiske integration til det eksterne blanketsystem. Et eventuelt behov for specialudvikling/tilpasning af det eksterne blanketsystem for at det lever op til Systemets Krav. Hvordan, og af hvem, blanketterne fremadrettet vedligeholdes og holdes opdaterede Tilbudssystemet Tilbudssystemet inklusive integration til Tilbudsportalen er en del af Fase 4 eller tidligere Fase. En del af Systemet er et Tilbudssystem, hvor aktøren kan fremsøge oplysninger om forskellige tilbud til udsatte børn og unge, både kommunens lokale tilbud, og tilbud hentet centralt fra Tilbudsportalen 40. Tilbudssystemet baserer sig derfor på informationer om indsatser fra to forskellige kilder: Tilbudsportalen og lokale kommunale indsatser, bestående af fx forebyggende foranstaltninger, specialundervisningstilbud, dækning af merudgifter og tabt arbejdsfortjeneste som illustreret i følgende figur: 40 jf. underbilag 3.1M. F o r t r o l i g t S i d e 139/ d e c e m b e r

140 Figur 38 - Tilbud i Tilbudssystemet Formålet er, at sagsbehandleren let skal kunne opstille alternative forslag til indsatser med pris, og overføre disse til indstillinger, afgørelser og handleplaner således, at data omkring indsats og priser genbruges. Det understøtter, at sagsbehandleren let kan orientere sig bredt i mulighederne og inddrage økonomiske overvejelser på en saglig måde. Det letter også den administrative byrde for sagsbehandlerne. Inddragelsen af tilgrænsende indsatser, som fx specialundervisning, sker for at understøtte den tværgående visitation der anvendes i mange kommuner, og for at opgørelser over barnets projektøkonomi kan komme tilstrækkeligt bredt omkring 41. Både af hensyn til den faglige kvalitet og det økonomiske overblik er det vigtigt, at Systemet kan omfatte den samlede indsats overfor barnet/den unge. Som det fremgår af afsnittet om ICS komponenten, skal en sagsbehandler i forbindelse med delprocessen Indsats og opfølgning kunne evaluere målopfyldelsesgrad samt tilfredshed med den samlede indsats og med de anvendte aftalepartnere. Tilbudssystemet indeholder disse målinger af tilfredshed således, at sagsbehandleren kan inddrage dem i valg af leverandør af tilbud eller aftalepartner. 41 Det skal bemærkes, at understøttelsen af de tilgrænsende indsatser oftest er fokuseret på muligheden for at registrere afgørelse med økonomi på en enkeltsag og ikke indeholder den samme procesunderstøttelse som for Systemets kerneydelser. Se nærmere i afsnit F o r t r o l i g t S i d e 140/ d e c e m b e r

141 Det samlede behov for data i Tilbudssystemet inklusiv priser, kan ses i Datastandardisering af centrale DUBU-begreber Fællesoffentligt OIO projekt, afsnit Det skal bemærkes, at samlet indsats, enkeltindsats og leverandørindsats ikke er relevante for Tilbudssystemet disse opstår først i forbindelse med en afgørelse. Prisstrukturen for de enkelte indsatser følger i stort omfang Tilbudsportalens. Det vil sige, at priser opgøres som enhedspriser, enten pr. tidsenhed eller som stykpriser, og priserne kan sammensættes af hoved-/delydelser. Herudover skal det bemærkes, at der er en særlig prisstruktur for plejefamilier, hvor prisen er baseret på antal plejevederlag. Leverandøren skal levere et Tilbudssystem, der kan løfte det totale behov for at søge i og vedligeholde tilbud. Systemet skal tage afsæt i og overtage mest muligt fra Tilbudsportalen, men udbygges så de ovenfor nævnte krav indfries. Systemet skal understøtte, at en funktion i kommunen kan vedligeholde kommunens egne øvrige tilbud og ydelser på udsatte børn- og ungeområdet og samle dem med tilbud og ydelser fra Tilbudsportalen i det lokale Tilbudssystem. Derudover skal data fra de evalueringer, der foretages i forbindelse med sagsbehandlingen i Systemet, overføres til Systemets Tilbudssystem, så en sagsbehandler kan se evalueringsdata for de tilbud, vedkommende fremsøger via Tilbudssystemet, se følgende eksempel på skærmbillede: Figur 39 Eksempel på skærmbillede fra Tilbudssystemet 42 jf. underbilag 3.1M. F o r t r o l i g t S i d e 141/ d e c e m b e r

142 Krav 205. Tilbudssystem til samlet søgning i landsdækkende og lokale tilbud Kategori: Minimumskrav Type: Funktionelt Beskrivelse: 4 eller tidligere Med henblik på at støtte sagsbehandlerne med at finde de bedste tilbud til et/en udsat barn/ung, skal Leverandøren udvikle et Tilbudssystem (en intern komponent i Systemet). Dette Tilbudssystem skal bruges til at registrere kommunens egne tilbud, og skal derudover kunne bruges til at fremsøge både landsdækkende tilbud (via integration til Tilbudsportalen) og kommunens egne tilbud. Kildekoden såvel som dokumentation til Tilbudsportalen er tilgængelig for Leverandøren og kan anvendes til at opbygge Tilbudssystemet 43. Krav 206. Indhold i Tilbudssystemet Kategori: Krav Type: Ikke funktionelt Beskrivelse: 4 eller tidligere Tilbudssystemet skal indeholde den sagsinformation, der fremgår af Datastandardisering af centrale DUBU-begreber Fællesoffentligt OIO-projekt, afsnit samt underbilag 3.1B. Krav 207. Gennemsnitlig vurdering af indsatser Beskrivelse: 4 eller tidligere Den gennemsnitlige vurdering af ydelser knyttet til et tilbud, jf. DUBU-blanket 4.a, felt 20-25, underbilag 3.1E, skal indgå i visningen af søgeresultater. I den sammenhæng skal det også vises, hvor mange evalueringer der ligger til grund for gennemsnitsberegningen. Krav 208. Tilgang til de enkelte vurderinger af indsatser 4 eller tidligere 43 jf. underbilag 3.1M jf. underbilag 3.1M. F o r t r o l i g t S i d e 142/ d e c e m b e r

143 Beskrivelse: Det skal, fra visningen af den gennemsnitlige vurdering af ydelser knyttet til tilbud, være muligt for sagsbehandleren at tilgå yderligere information, som viser samtlige evalueringer, der ligger til grund for gennemsnittet samt de kvalitative kommentarer, der følger med. Krav 209. Kommunen kan vedligeholde egne tilbud 4 eller tidligere Beskrivelse: Systemet skal understøtte, at kommunen kan vedligeholde (oprette, redigere og deaktivere) egne tilbud, som ikke er indeholdt i Tilbudsportalen (aktør Tilbudsvedligeholder se afsnit 4.1). Krav 210. Begrænset adgang til kommunale tilbud Kategori: Krav Type: Ikke funktionelt 4 eller tidligere Beskrivelse: Systemets oversigt over kommunens egne tilbud skal kunne læses af andre medarbejdere i kommunen, dvs. at udvalgte brugerroller tillades adgang til at se de kommunale tilbud (en tilbudslæser aktør se afsnit 4.1). Krav 211. Bevaring af data i forbindelse med opdatering Kategori: Krav Type: Ikke funktionelt 4 eller tidligere Beskrivelse: Når Tilbudssystemet opdateres med data fra Tilbudsportalen, skal evalueringsdata, som historik, forblive knyttet til et tilbud fra Tilbudsportalen, selvom dette tilbud opdateres. Dato for seneste opdatering fra Tilbudsportalen fremgår af det enkelte tilbud i Tilbudssystemet således, at det er muligt for en sagsbehandler at blive opmærksom på, hvis evalueringsdata for det pågældende tilbud er ældre end opdateringen Tilbudsportalen Tilbudsportalen er et landsdækkende system, som indeholder en række tilbud til bl.a. udsatte børn og unge. Her kan en sagsbehandler blandt andet søge på tilbud, målgruppe og ydelse, og kombinere sig frem og finde relevante tilbud og sammenligne disse på indhold og pris. F o r t r o l i g t S i d e 143/ d e c e m b e r

144 Tilbudsportalen indeholder en række tilbud til bl.a. udsatte børn og unge. Tilbudsportalen er tilgængelig via internettet 45 og stiller endvidere sin funktionalitet til rådighed i form af webservices 46. På Tilbudsportalens hjemmeside er der en vejledning til de forskellige informationer, der skal indtastes i portalen. Krav 212. Indhentning af tilbudsoversigt fra Tilbudsportalen Kategori: Krav Type: Ikke funktionelt 4 eller tidligere Beskrivelse: Med jævne mellemrum skal det være muligt at importere en fil fra Tilbudsportalen til Tilbudssystemet i Systemet, som indeholder bestemte og prædefinerede tilbud registreret i Tilbudsportalen. Denne import kunne eksempelvis opsættes af den centrale administrator som et batch-program, der afvikles om natten, med fx ugentlig frekvens. Krav 213. Beskrivelse af Tilbudssystemet Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvordan Tilbudsportalen vil arbejde sammen med resten af Tilbudssystemet. I den forbindelse skal der beskrives, hvordan Tilbudssystemet vil være robust over for ændringer i Tilbudsportalen. Leverandøren skal redegøre for, hvordan og i hvilket omfang denne robusthed vil blive imødekommet Organisationskomponent Organisationskomponenten er en del af grundfunktionaliteten (Fase 1). Til brug for håndtering af organisatoriske sammenhænge i arbejdsgangene i relation til Systemet, er der behov for en Organisationskomponent. Organisationskomponentens ansvar bliver at håndtere aktørernes organisatoriske tilhørsforhold, så det bliver muligt blandt andet at: Registrere informationer omkring aktøren, så som navn, rolle, og aktørens organisatoriske tilhørsforhold. Understøtte sagsbehandleren i, at kunne registrere en anden sagsbehandler til opfølgning på sagen jf. underbilag 3.1M jf. underbilag 3.1M. F o r t r o l i g t S i d e 144/ d e c e m b e r

145 Kunne videregive/eskalere en aktivitet til en sagsbehandler eller leder, hvis aktiviteten nærmer sig sin frist eller overskrides. Gøre det muligt afsende en mail til en sagsbehandler. Kunne medvirke til at give sagsfordelerrollen et overblik over afdelingens/kontorets bemanding, og herfra fordele sager. Følgende citat: Der findes typisk flere organisationssystemer i en organisation. Det betyder, at oplysninger om organisations- og personaledata skal vedligeholdes i en lang række systemer, det være sig lønsystemer, økonomisystemer, fagsystemer og ESDH-systemer. I praksis giver det anledning til stort vedligeholdelsesarbejde, usikkerhed om hvilke oplysninger, der er de rigtige samt x antal ikkestandardiserede integrationer 47, illustrerer, at begrebet organisation er et komplekst område med mange datakilder. Derudover er der mange begrebsmæssige fortolkninger: Forskellige organisationssystemer vil typisk beskrive forskellige aspekter af organisationen: en organisation (juridisk enhed), funktionel organisation, sikkerhedsmæssig organisation, projektorganisation, matrixorganisation, teams, grupper, systemer. 48 Organisationskomponenten vil dog ikke spille så central en rolle i Systemet som beskrevet ovenover. Der er ikke lagt et så højt ambitionsniveau i denne, at den skal kunne orkestrere alle de mulige datakilder og fortolkninger, der er i kommunerne. Tværtimod skal Organisationskomponenten som udgangspunkt opfattes som en intern komponent (dog stadig med åbne snitflader), indeholdende en delmængde af kommunernes organisation af relevans for Systemet, en delmængde der kan vedligeholdes af den kommunale administrator. Følgende konceptuelle arkitekturtegning skitserer omfanget af Organisationskomponenten: 47 Citat fra pjecen: Specifikation af serviceinterface for organisation, OIO-udvalget for sagsog dokumentområdet, 18. december 2009, jf. underbilag 3.1M. 48 Citat fra pjecen: Specifikation af serviceinterface for organisation, OIO-udvalget for sags- og dokumentområdet, 18. december 2009, jf. underbilag 3.1M. F o r t r o l i g t S i d e 145/ d e c e m b e r

146 Figur 40 Opbygning af Organisationskomponenten Ovenstående tegning illustrerer, at Organisationskomponenten skal være en service i Systemet, en service som ikke behøver at have integrationer til omgivelserne. Sagsbehandleren og Systemet kan læse alle data og den kommunale administrator kan vedligeholde kommunens egne data via dedikerede brugergrænseflader. Organisationskomponenten skal stille de data og operationer til rådighed, som understøttes af den OIO-godkendte organisationsstandard under sags- og dokument standarden. Krav 214. Organisationskomponent Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal have adgang til en Organisationskomponent, hvori de dele af kommunens organisation, af relevans for Systemet, kan vedligeholdes. I Organisationskomponenten skal det være muligt at relatere forskellige typer af elementer i en organisation til hinanden, således at en dækkende organisationsstruktur kan opbyg- F o r t r o l i g t S i d e 146/ d e c e m b e r

147 ges. Krav 215. Snitfladestandard for Organisationskomponent Kategori: Krav Type: Ikke funktionelt Beskrivelse: Organisationskomponenten skal udstille snitfladerne beskrevet via serviceinterfaces for forretningsservicen Organisation fra Sag og dokument-standarden 49. Krav 216. Sikring af data i Organisationskomponent Kategori: Krav Type: Ikke funktionelt Beskrivelse: Data i Organisationskomponenten skal sikres således, at alle aktører må læse data, mens kun den kommunale administrator må redigere kommunens egne data. Krav 217. Sikring af transport af data i Organisationskomponent Kategori: Krav Type: Ikke funktionelt Beskrivelse: Da data ikke vil indeholde personfølsomme informationer, skal transport af data sikres på et niveau, der svarer til OIOREST. Krav 218. Beskrivelse af Organisationskomponent Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive arkitekturen og funktionaliteten af Organisationskomponenten generelt og med fokus på: Hvordan en hierarkisk organisationsstruktur kan opbygges, og hvordan Sagsstyringskomponenten kan benytte sig af komponenten. Hvorledes snitfladestandarden anvendes, og især hvilke tilføjelser og afvigelser der er nødvendige, for at kunne foretage dataudvekslingen. Hvorledes transporten af data sikres mellem den øvrige del 49 dokumenthandtering/filer-og- dokumenter/referencearkitektur/itst_referencearkitekturesdh_web.pdf. Endvidere Specifikation af serviceinterface for organisation, OIO-udvalget for Sags- og dokumentområdet, 18. december 2009, jf. underbilag 3.1M. F o r t r o l i g t S i d e 147/ d e c e m b e r

148 af Systemet og Organisationskomponenten Dokumentboks Dokumentboks er en del af Fase 2 eller kan leveres som en del af Fase 1. Regeringen har indgået en aftale med KL og Danske Regioner om at give den digitale borgerkommunikation et betydeligt løft og skub fremad. Regeringen, KL og Danske Regioner er enige om at afholde en edag3 den 1. november 2010 under overskriften Nem adgang til det offentlige på nettet. Formålet med edag3 er, at give borgerne en væsentligt mere effektiv og fleksibel service på internettet. Efter edag3 kan borgerne blandt andet få en digital Dokumentboks, hvorigennem de kan modtage og sende post fra og til de offentlige myndigheder. Det betyder, at den enkelte borger kan vælge at få post fra fx sin kommune i sin digitale Dokumentboks i stedet for på brev. Borgerne vil også kunne kommunikere digitalt med fx deres kommune igennem Dokumentboksen frem for fx via telefon eller personlig henvendelse. Den digitale Dokumentboks sparer det offentlige for penge til porto og giver samtidig borgerne en mere fleksibel service 50. Krav 219. Afsendelse af breve til Dokumentboks Kategori: Minimumskrav Type: Funktionelt 2 eller tidligere Beskrivelse: Systemet skal understøtte, at borgere der er tilmeldt Dokumentboks, får breve fra Systemet via Dokumentboks. Borgere, der ikke er tilmeldt Dokumentboks, skal have tilsendt breve via postvæsenet. Følgende diagram skitserer forløbet omkring afsendelse af korrespondance via Dokumentboks: 50 Se specifikationer på: jf. underbilag 3.1M. F o r t r o l i g t S i d e 148/ d e c e m b e r

149 Figur 41 Procesforløb for afsendelse af breve 51 Ovenstående tegning skitserer følgende procesforløb: Systemet skal afsende et brev til en borger. Systemet spørger derfor Dokumentboks om den pågældende borger er tilknyttet Dokumentboks. Såfremt borgeren er tilknyttet Dokumentboks, sendes brevet til Dokumentboks, og borgeren kan efterfølgende læse sin digitale post via Borger.dk. Hvis borgeren ikke er tilknyttet Dokumentboks, sendes brevet til print lokalt hos kommunen og skal sendes til borgeren med almindelig post. Krav 220. Afsendelse af breve via REST Kategori: Krav Type: Ikke funktionelt 2 eller tidligere Beskrivelse: Systemet skal, via REST-kald, integrere med Dokumentboks med følgende operationer: Check af, at en borger er tilmeldt Dokumentboks. Afsend brev til borger. Afviklingen af operationerne skal foregå via system-til-system integration, baseret som kravsat af Styregruppen for Tværoffentligt 51 Billede lånt fra MS/Integration/REST-forsendelse.jpg, jf. underbilag 3.1M. F o r t r o l i g t S i d e 149/ d e c e m b e r

150 Samarbejde (STS) 52. Via NemSMS kan den enkelte myndighed sende SMS'er med ikke-personfølsomt indhold til alle borgere og virksomheder, der har registreret deres mobiltelefonnummer - og samtidig har tilkendegivet, at de ønsker at modtage SMS'er fra den pågældende myndighed 53. Denne funktionalitet kan være af relevans for brugerne af Systemet, da en del af sagsbehandlernes arbejde omfatter deltagelse i møder med borgere. En adviseringsløsning med udsendelse af SMS kan dermed hjælpe borgerne med at huske de aftalte møder. Krav 221. Afsendelse af påmindelser via NemSMS Kategori: Option Type: 2 eller tidligere Beskrivelse: Leverandøren skal beskrive og prissætte en løsning, hvor borgere, der er tilmeldt NemSMS, bliver påmindet om et snarligt aftalt møde. Sagsstyringskomponenten skal kunne parameteropsættes med adviser med fokus på denne påmindelse. En journalarksnote på sagen skal angive, at en påmindelse er afsendt til den pågældende borger Rapportering Den del af rapportering, der omhandler filudtræk af ledelsesinformation er en del af grundfunktionaliteten (Fase 1), mens generering af ledelsesinformationsrapporter er en del af Fase 3 eller en tidligere Fase. Udtræk til Danmarks Statistik og til Ankestyrelsen er en del af grundfunktionaliteten (Fase 1) og udtræk til Statens Arkiver er en del af Fase 4. Dette afsnit beskriver de forskellige typer af rapporteringer, der skal foregå i Systemet. I relation til Systemet omtales i dette afsnit følgende typer af rapportering: Ledelsesinformation: Ledelsesinformation filudtræk. Ledelsesinformation rapporter. Udtræk til Danmarks Statistik. 52 Se nærmere specifikationer på debeskrivelser/, jf. underbilag 3.1M. 53 Se specifikationer på: jf. underbilag 3.1M. F o r t r o l i g t S i d e 150/ d e c e m b e r

151 Udtræk til Ankestyrelsen. Udtræk til Statens Arkiver. Krav 222. Beskrivelse af håndtering af følsomme persondata Kategori: Info Type: Beskrivelse: Leverandøren skal redegøre for, hvordan Systemet vil håndtere den udfordring, at der ikke må forekomme lovstridig eller forskriftstridig udveksling af Ledelsesinformation indeholdende følsomme persondata til modtagere, som ikke er autoriseret af Systemet. For eksempel via anonymisering af oplysninger om enkeltpersoner og generel overholdelse af lovgivning i afsnit 9 Lovmæssige og politiske krav Ledelsesinformation Det er et selvstændigt succeskriterium for Systemet, at Ledelsesinformation til planlægning og styring af indsatsen på udsatte børn og unge området forbedres, jf. afsnit 1.1. For at realisere dette succeskriterium ønsker Kunden, at Systemet indeholder en funktionalitet til Ledelsesinformation. Ledelsesinformation, inden for rammerne af Systemet, har til formål at forbedre indsatsen på området udsatte børn og unge, gennem en øget indsigt i proces, økonomi og resultater. Det er i den forbindelse meget vigtigt at fremhæve, at målgruppen ikke kun er ledere, men at informationen skal bruges til at sikre en bedre og faktabaseret dialog mellem politikere, ledere og medarbejdere i øvrigt. Det forudsætter, at informationen er let tilgængelig. Det følger også heraf, at oplysninger om fx målopnåelse, overholdelse af frister, budgetter eller sagsbelastning ikke forudsættes kun at være relevant for enkelte af disse målgrupper, men skal indgå i en tværgående dialog. Der vil formentlig være en naturlig tendens til, at der i den enkelte afdeling eller enhed vil være en større interesse i at se, hvordan det går med vores sager, mens man på et overordnet ledelsesniveau vil have en større interesse for data fra hele kommunen. Ledelsesinformationen skal kunne tilgås på forskellige måder: Ad hoc-baseret udtræk, hvor Ledelsesinformation kan udtrækkes og viderebearbejdes i separate lokale løsninger, der er målrettet til dette formål, og som ikke er en del af Systemet (se afsnit vedrørende Ledelsesinformation filudtræk nedenfor). Et antal foruddefinerede rapporter, baseret på en række faste udtræk af strukturerede data fra Systemet (se afsnit vedrørende Ledelsesinformationsrapporter nedenfor). Det er et succeskriterium for Systemet, at Ledelsesinformation anvendes i dialogen mellem politikere, medarbejdere og ledere. Dette forudsætter, at brugerne af Systemet kan få en forholdsvis direkte adgang til relevant statistik. Der etableres der- F o r t r o l i g t S i d e 151/ d e c e m b e r

152 for en række standardrapporter, som kan tilgås af brugere, uden at de er afhængige af, at en stabsfunktion eller lignende i kommunen først skal producere dem. Der er forskellige typer af standardrapporter, herunder: Rapportering om den enkelte sag: Der er et sagsbehandler- og ledelsesbehov for at se den enkelte sags status, fremdrift og summariske indholdsbeskrivelse, fx procestrin, sagens materielle indhold samt det økonomiske ressourcetræk i organisationen. Produktion, sagsstyring og sagsfordeling: En sagsbehandler eller leder skal kunne sammenstille information om initiering, afslutning og fremdrift for sagerne generelt, herunder overskredne deadlines ol. Økonomi og ressourcerapportering, herunder projektøkonomi og fremskrivninger: En sagsbehandler eller leder skal kunne sammenstille information om nøgletal for de fremskrevne og afholdte udgifter på området. Erfaringsopsamling, herunder årsag til indsats, tilfredshed med leverandører af tilbud og målopfyldelse i forhold til handleplan. Benchmarking mellem kommuner: Systemet skal understøtte indbyrdes benchmarking mellem de kommuner, der anvender Systemet. Systemet skal derfor kunne producere rapporter med ledelsesinformation i et datasæt, som er ensartet mellem kommunerne. Der kan findes en behovsoversigt over de foruddefinerede rapporter i underbilag 3.1I. Krav 223. Data skal struktureres, så der kan dannes rapporter på tværs af kommuner og indenfor kommunen Kategori: Krav Type: Ikke funktionelt Beskrivelse: Leverandøren skal sikre, at data gemmes på en struktureret måde i Systemets database(r), så data kan sammenstilles som ledelsesinformation på tværs af de kommuner, der bruger Systemet samt indenfor kommunen. Krav 224. Beskrivelse af strukturering af data Kategori: Info Type: Beskrivelse: Leverandøren skal vedlægge et eksempel på, hvordan data struktureres for at give kommuner mulighed for, at sammenstille ledelsesinformationer på tværs af kommuner. F o r t r o l i g t S i d e 152/ d e c e m b e r

153 Krav 225. Kommuner kan frigive eller afskærme adgang til data Beskrivelse: Den kommunale administrator kan konfigurere, hvorvidt kommunens egne data skal frigives eller afskærmes for benchmarking mellem de kommuner, som benytter Systemet Ledelsesinformation filudtræk Systemet skal indeholde mulighed for filudtræk af data. De mulige filudtræk skal baseres på et relevant udsnit af de begreber, der er til rådighed i Systemet, jf. OIO begreber 54 og underbilag 3.1B. Krav 226. Mulighed for udtræk af data Kategori: Minimumskrav Type: Funktionelt Beskrivelse: Systemet skal understøtte mulighed for udtræk af data, som baserer sig på de begreber, der er til rådighed i Systemet. Udtrækket skal omfatte rådata, og der skal således ikke foretages nogen former for aggregeringer og beregninger. En aktør skal kunne åbne en brugergrænseflade og på denne side få lov til, enten at vælge en søgning, som vedkommende tidligere har afviklet eller sammensætte felter og kriterier for en ny søgning. Dette skal kunne gøres på en forholdsvis simpel og fleksibel måde, hvor brugergrænsefladen giver mulighed for, at de felter som skal udtrækkes, skal kunne markeres, at kriterier som er en del af lister skal kunne vælges i en dropdown liste, og at der kan skrives tekstuelle kriterier, hvor dette er muligt og hensigtsmæssigt. Aktøren skal kunne få vist enten hele eller dele af resultatet af søgningen på en resultatside, og skal kunne vælge at downloade resultaterne i et filudtræk, som aktøren efterfølgende kan vælge at bearbejde i et andet program. De data der udtrækkes er rådata, og indeholder således ikke aggregeringer og andre beregninger, da dette ansvar bør dækkes af andre programmer udenfor Systemet, som fx Excel eller lokale Ledelsesinformationssystemer. Krav 227. Aktør understøttes i at sammensætte filudtræk 54 jf. underbilag 3.1M. F o r t r o l i g t S i d e 153/ d e c e m b e r

154 Beskrivelse: Systemet skal, via en brugergrænseflade, understøtte aktøren i at udvælge de data som skal udtrækkes. Aktørens valg fra eksempelvis dropdown lister, indskrivning af kriterier og afkrydsning af ønskede felter skal fleksibelt sammensætte det dataomfang, som aktøren ønsker at udtrække. Krav 228. Dataudtræk vises på resultatside Beskrivelse: Systemet skal vise resultatet af den udførte søgning i en resultatside i listeform. Såfremt Systemet vurderer, at mængden af data returneret er for omfattende at vise på resultatsiden, kan en mindre del af data vises med det formål at give aktøren et indtryk af, hvad søgningen indebærer. Systemet skal kunne eksportere data i et filformat som kan benyttes til fx import til databaser, til Excel, til et statistikprogram, til lokale Ledelsesinformationssystemer og/eller til kommunens intranet - hvor data skal kunne bearbejdes, kombineres og sammenstilles af en administrator/superbruger lokalt i den enkelte kommune. Krav 229. Filudtræk som kommaseparerede filer. Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal kunne eksportere data i et gængst filformat (som for eksempel CSV, XML). Krav 230. Store datamængder Kategori: Krav Type: Ikke funktionelt Beskrivelse: Hvis Systemet vurderer, at mængden af data der skal udtrækkes i et filudtræk er så stort, at det kan virke belastende på performance i Systemet, kan det vælges at køre filudtræk af data i et baggrundsjob, som senere kan tilsendes brugeren. Alternativt kan brugeren få adgang til selv at hente det færdige filudtræk. Krav 231. Gem af søgninger Beskrivelse: Systemet skal understøtte, at de søgninger der bliver sammensat, skal kunne gemmes til senere genbrug. F o r t r o l i g t S i d e 154/ d e c e m b e r

155 Krav 232. Beskrivelse af Ledelsesinformation dataudtræk Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvordan filudtræk af data kommer til at fungere. Herunder: Hvordan aktøren, på en simpel og fleksibel måde, kan vælge det sæt af data der ønskes udtrukket, underbygget med en skitse på en brugergrænseflade. Hvordan de udtrukne data kan leveres til aktøren på en måde, som både er brugervenlig og ikke forstyrrer den daglige drift unødigt. Hvordan kriterier for udtræk af data kan gemmes til senere søgninger samt, hvem der får adgang til at afvikle disse gemte søgninger. Hvordan det sikres, at de data aktøren vælger til ét udtræk har en indbyrdes relationel afhængighed. Hvordan det sikres, at aktøren ikke får utilsigtet adgang til data, der ikke er rettigheder til at se Ledelsesinformationsrapporter Ledelsesinformationsrapporter er en videreudvikling af Ledelsesinformationsfiludtræk, som vil bibringe aktørerne mere strukturerede rapporter. Til dannelse af disse rapporter kan foretages aggregeringer og beregninger, for at bringe data på et Ledelsesinformationsmæssigt relevant niveau. Derudover skal det være muligt, såfremt den enkelte kommune åbner op for den mulighed, at udtrække nøgletal på tværs af de deltagende kommuner. Rapporterne skal kunne distribueres til interessenter periodisk, på nærmere skedulerede tidspunkter. I underbilag 3.1I findes et oplæg til en række faste rapporter, der bredt dækker de behov, som de forskellige aktører af Systemet har for Ledelsesinformation. Krav 233. Faste dataudtræk til rapportgenerering Kategori: Krav Type: Ikke funktionelt 3 eller tidligere Beskrivelse: De foruddefinerede rapporter med Ledelsesinformation skal sammenstilles på basis af en række faste dataudtræk, som fremgår af underbilag 3.1I. Der skal i definitionen af rapporterne være mulighed for, at aggregere og beregne på rådata. Kunden forventer, at brugen af Ledelsesinformation vil udvikle sig, efterhånden som fx sagsbehandlere og ledere oparbejder erfaring med funktionaliteten og nye anvendelsesområder viser sig. F o r t r o l i g t S i d e 155/ d e c e m b e r

156 Derfor skal svarene på de nye spørgsmål, det er muligt at indsætte forskellige steder i sagsgangen, jf. afsnit 5.1.6, kunne indgå i de faste dataudtræk. Krav 234. Faste dataudtræk skal også kunne indeholde svar på spørgsmål Kategori: Krav Type: Ikke funktionelt 3 eller tidligere Beskrivelse: Svarene på de spørgsmål det er muligt at indsætte forskellige steder i sagsgangen, skal kunne indgå i de faste dataudtræk, jf. afsnit Krav 235. Grafisk præsentation af indholdet i rapporterne Kategori: Krav Type: Ikke funktionelt 3 eller tidligere Beskrivelse: Ledelsesinformationen i rapporterne skal kunne præsenteres i faste tabeller, samt grafisk i form af faste diagrammer. Krav 236. Leder/sagsbehandler kan skedulere rapportafvikling Kategori: Krav Type: Ikke funktionelt 3 eller tidligere Beskrivelse: Det skal være muligt for en leder/sagsbehandler, at kunne skedulere gentagne tidspunkter for rapportafvikling. Krav 237. Rapportgenereringen skal kunne ske i dagtimerne uden performance-forringelse for Systemet Kategori: Krav Type: Ikke funktionelt 3 eller tidligere Beskrivelse: Systemet skal kunne generere rapporter med Ledelsesinformation i dagtimerne, uden at det påvirker Systemets performance. Krav 238. Rapportdesign Kategori: Krav Type: Ikke funktionelt 3 eller tidligere Beskrivelse: Designet af rapporter skal tage udgangspunkt i Økonomistyrelsens designparadigme for rapporter, vedlagt som underbilag 3.1J. Derudover gælder: At rapporterne skal kunne udskrives i udskriftvenligt format. At visning ikke bør fylde mere end skærmbredden. F o r t r o l i g t S i d e 156/ d e c e m b e r

157 Krav 239. Aktør parameteropsætter modtagere af rapporter 3 eller tidligere Beskrivelse: En aktør skal efter rapportgenerering - kunne parameteropsætte på den enkelte rapport, hvem der skal modtage rapporten via mail. Krav 240. Beskrivelse af ledelsesinformationsrapporter Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvorledes: Ledelsesinformationsrapporter generelt vil blive udviklet, hvilken teknologi der benyttes samt hvilken fleksibilitet der er i disse, herunder: Om brugergrænsefladen er webbaseret. Om brugerobjekter kan indlejres i andre webløsninger eller portaler. Om rapportløsningen er opbygget af standardkomponenter med modulær arkitektur, der er kendt og baseret på moderne platforme. Om rapporteringsløsningen er baseret på et standard SQL database-produkt. Om det er muligt at sammensætte data, lave analyser, pivot-tabeller, OLAP-kuber osv. Hvordan, og i hvilke formater, rapporterne vil blive præsenteret, gerne med baggrund i et eller flere beskrivende eksempler på rapporter. De faste udtræk kan håndtere svar på de spørgsmål, der kan opsættes i sagsgangen. Generering og distribution af de faste rapporter kan foretages uden påvirkning af Systemets krav til performance Udtræk til Danmarks Statistik Kommunen foretager ved årets udgang dataindberetning til Danmark Statistik. Skemaer til indberetning for Systemet er endnu ikke lagt på Virk.dk 55, så indberetningerne skal foregå via blanketterne, der er tilgængelige og kan downloades fra Danmarks Statistiks hjemmeside 56 og 57. De udvekslingsmetoder Danmarks Statistik stiller til rådighed, er beskrevet i underbilag 3.1K. Oversigt over, hvor spørgsmål 55 jf. underbilag 3.1M =161, jf. underbilag 3.1M m, jf. underbilag 3.1M. F o r t r o l i g t S i d e 157/ d e c e m b e r

158 skal hentes i Systemet kan ses i tabellen Kobling mellem anbringelsesstatistik_danmarks stastistik og DUBU-blanketter i underbilag 3.1E. Krav 241. Indberetning til Danmarks Statistik Kategori: Minimumskrav Type: Ikke funktionelt Beskrivelse: Systemet skal understøtte periodisk eller løbende indberetning af statistikdata. Krav 242. Aktør anvender data til Danmarks Statistik lokalt Beskrivelse: Systemet skal understøtte, at en aktør kan anvende data fra det sæt af data til lokal statistik, som sagsbehandleren skal indberette til Danmarks Statistik. Krav 243. Beskrivelse af lokal anvendelse af data til Danmarks Statistik Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvordan indberetningen til Danmarks Statistik vil blive udviklet og i den forbindelse beskrive, hvor automatisk indberetningen vil blive Udtræk til Ankestyrelsen Kommunerne skal løbende - og inden 4 uger - indberette afgørelser og sagshændelser i forhold til børn og unge som anbringes eller er anbragt uden for hjemmet. Indberetningspligten til Ankestyrelsen har været gældende siden 1. januar Indberetningen foregår automatisk via afsendelse af en sikker mail til en mail adresse hos Ankestyrelsen. Oversigt over hvor spørgsmål skal hentes i Systemet ses i tabellen Kobling mellem anbringelsesstatistik_danmarks stastistik og DUBUblanketter i underbilag 3.1E. Krav 244. Aktørs indberetning til Ankestyrelsen Kategori: Minimumskrav Type: Funktionelt Beskrivelse: Systemet skal understøtte, at aktøren på relevante tidspunkter foranlediges til at afsende en afrapportering til Ankestyrelsen. F o r t r o l i g t S i d e 158/ d e c e m b e r

159 Krav 245. Aktør kan anvende data til Ankestyrelsen lokalt Beskrivelse: Systemet skal understøtte, at en aktør kan anvende data fra det sæt af data til lokal statistik, som sagsbehandleren skal indberette til Ankestyrelsen. Krav 246. Automatisk opsamling af data til ankestyrelsen Kategori: Krav Type: Ikke funktionelt Beskrivelse: De sagsstyringsaktiviteter, som giver anledning til at der skal indberettes til Ankestyrelsen, skal kunne opsamles, for sidenhen at kunne udtrækkes til indberetning til Ankestyrelsen. Indberetningen vil være én-vejs, med afsendelse fra Systemet til Ankestyrelsen og vil ske via en vedhæftet fil til en sikker . Ved brug af sikker , sikres fortroligheden af indberetningsdata. Krav 247. Indberetning pr. sikker Kategori: Krav Type: Ikke funktionelt Beskrivelse: Indberetningsdata til Ankestyrelsen skal overføres som en komma-separeret fil i txt-format, og fremsendes som vedhæftede filer til en sikker . Eftersom Ankestyrelsen ikke sender kvitteringer for modtaget data, er det nødvendigt at Systemet registrerer alle indberetninger til Ankestyrelsen lokalt og registrerer et eventuelt retursvar angående fejl, som Ankestyrelsens mailserver måtte fremsende. Den kommunale administrator bør underrettes, hvis en indberetning ikke går igennem. Krav 248. Logning af indberetninger Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal kunne logge afsendte indberetninger og eventuelle retursvar angående fejl, som Ankestyrelsens mailserver måtte fremsende. F o r t r o l i g t S i d e 159/ d e c e m b e r

160 Krav 249. Beskrivelse af indberetning til Ankestyrelsen Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvordan indberetning til Ankestyrelsen udvikles, specielt med fokus på: Hvordan indberetningen til Ankestyrelsen arkitekturmæssigt spiller sammen med resten af Systemet. Hvordan det dokumenteres, at en indberetning er foretaget, eller at der er opstået en fejl. Hvordan det tænkes, at en aktør notificeres omkring afsendelse af indberetning. Hvordan en aktør kan udtrække de samme data, som indberettes til Ankestyrelsen Udtræk til Statens Arkiver Data fra elektroniske arkivsystemer, der er truffet bevaringsbeslutning om, skal afleveres i kopi (arkiveringsversion) til offentligt arkiv senest før sletning eller når data går ud af administrativ brug. Kommuner og regioner skal aflevere arkivalier, der er omfattet af lov om behandling af personoplysninger - og som skal bevares - til et offentligt arkiv. Arkivalier, der er omfattet af lov om personoplysninger, vil typisk være elektroniske journaler, ESDH-systemer eller registre og fagsystemer. Afleveringen skal ske senest på det tidspunkt, hvor de pågældende oplysninger ellers skal slettes af kommunen. ESDH-systemer skal opdeles i 5-årige arkivperioder. Ved afslutningen af en arkivperiode kan myndigheden i op til 6 måneder benytte en såkaldt overlapningsperiode, hvor der stadig kan registreres dokumenter på sager fra den afsluttede periode. På den måde kan så mange sager som muligt lukkes inden arkiveringsversionen produceres. For ESDH-systemer gælder, at ca. 6 måneder efter afslutningen af perioden (+ en eventuel overlapningsperiode), skal der afleveres en arkiveringsversion til Statens Arkiver. Se desuden afsnit 7.2 for yderligere informationer om det lovmedholdige. Statens arkiver har desuden lavet en del vejledninger i den elektroniske aflevering 58. Krav 250. Beskrivelse af indberetning til Statens Arkiver Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvordan indberetning til Statens Arkiver vil foregå, specielt med fokus på: 58 fra_elektroniske_arkivsystemer, jf. underbilag 3.1M. F o r t r o l i g t S i d e 160/ d e c e m b e r

161 Hvordan arkitekturen af Systemet understøtter håndtering af periodeskift. Hvilke formater der forventes at skulle udtrækkes data i. Hvilke forretningsprocesser og -funktioner (hos Kunden og Leverandøren selv) Leverandøren forventer, der understøtter opgaven, og af hvilke aktører Brugergrænseflader og kontorapplikationer Brugergrænseflader er en del af grundfunktionaliteten (Fase 1) samt de efterfølgende faser, hvor de specifikke brugergrænseflader er relevante ift. den funktionalitet, der understøttes af Fasen. Integrationen til kontorapplikationer er en del af Fase 4 eller tidligere Fase. Præsentationslaget realiseres som web-baserede skærmbilleder. Disse skærmbilleder udformes efter fælles skabeloner, som sikrer sammenhæng, genbrug, genkendelighed og eventuel personalisering mv. Det er vigtigt for accepten af Systemet, at brugervenligheden er i top, og at Leverandøren lader sig inspirere af nye fremskridt inden for webudvikling, som har til formål at minimere antallet af klik og sideopdateringer. Krav 251. Konsistente og sammenhængende brugergrænseflader Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal for aktørerne fremstå som en konsistent og sammenhængende løsning og opbygget efter Best Practices for strukturering af web skærmbilleder 59. Krav 252. Layout Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemets skærmbilleder skal baseres på XHTML 1.0 eller nyere. Skærmbilledernes layout skal implementeres med CSS 2.0, hvor alle muligheder i CSS 2.0 skal anvendes. Skærmbillederne skal kunne gennemgå W3C HTML/XHTML og CSS 2.0 validering. 59 Fx jf underbilag 3.1M. F o r t r o l i g t S i d e 161/ d e c e m b e r

162 Krav 253. Skærmopløsning Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemets nye skærmbilleder skal optimeres til skærmopløsning 1024*786 og 16/32 bit farver samt være skalerbare til større skærmopløsninger. Krav 254. Tilgængelighed Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal opfylde WCAG 2.0 tilgængelighedskravene på niveau AA 60. Opfyldelsen af tilgængelighedskravene kan tjekkes via følgende halv- og helautomatiske værktøjer: Tilgængelighedsværktøjslinje: AChecker: Worldspace: Krav 255. Browser-understøttelse Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemets skærmbilleder skal som minimum være optimeret til visning med MS Internet Explorer 7.X og 8.X samt Mozilla Firefox version 3.X 61. Krav 256. Understøttelse af alternative browsere Kategori: Option Type: Beskrivelse: Leverandøren skal prissætte understøttelse for visning i MS Internet Explorer og jf. underbilag 3.1M. 61 Foreningen af Danske Interaktive Medier (FDIM) opsamler statistik omkring brugen af store danske udgivelser ( sites ). De statistiske informationer FDIM har opsamlet er blevet benyttet til at kvalificere, hvilke browsere DUBU skal understøtte. Der er taget udgangspunkt i statistikken for forbrug i december 2009, jf. underbilag 3.1M. F o r t r o l i g t S i d e 162/ d e c e m b e r

163 Krav 257. Fokus på brugervenlighed Kategori: Krav Type: Ikke funktionelt Beskrivelse: Brugergrænseflader skal udvikles med fokus på brugervenlighed, hvilket blandt andet omfatter: At de skal kunne betjenes med og uden mus og med færrest mulige tryk. Der skal findes genvejstaster til de mest brugte funktioner, og det skal være muligt at navigere mellem indtastningsfelter ved brug af tab-tasten. At de skal have en konsistent reaktion på brug af Entertasten. At bruge Enter-tasten på tastaturet bør oftest svare til, at vælge OK- eller Gem-funktionen på brugergrænsefladen. At navigation skal fungere korrekt i henhold til de specificerede procesmodeller og Use Cases. At valg af nyt skærmbillede medfører, at cursor vil være logisk placeret i indtastningsfelter (typisk feltet længst oppe til venstre) og være aktiv. At knapper, som ikke kan vælges, skal sløres. At brugeren, hvor det er muligt, skal kunne vælge værdierne i en dropdown menu. At det i dropdown-menuer og lister skal være muligt at tilgå den rigtige post ved tryk på 1. og 2. bogstav i den pågældende post. At dynamiske dropdownlister understøttes, så eksempelvis værdierne, der fremkommer i liste B, afhænger af hvilken værdi, der vælges i liste A etc. At en kommunal og central administrator - via en administrationsklient - kan foretage oprettelse, ændring og sletning af valgmuligheder og rækkefølgen i alle dropdownlisters visning ved åbning. At brugeren skal kunne sortere indholdet i kolonner alfabetisk, numerisk eller i relationer og roller, ved at aktivere kolonneoverskrifterne. At det skal være muligt for brugeren, selv at vælge rækkefølgen og bredden af kolonnerne i oversigtsbilleder. At brugergrænsefladen skal være så fleksibel som mulig. Derfor skal alle tekster, links, datoer og grænseværdier ikke hard-codes, men skal kunne konfigureres af en central eller kommunal administrator. At alle skærmbilleder skal kunne skjules, minimeres og lukkes. F o r t r o l i g t S i d e 163/ d e c e m b e r

164 Krav 258. Beskrivelse af design af GUI Kategori: Info Type: Beskrivelse: Leverandøren skal, som en del af det samlede tilbud, levere et forslag til, hvordan Systemets GUI design kan se ud. Forslaget skal indeholde screenshots/mock-ups af den mest almindelige funktionalitet og omfatte: Eksempler på brug af den designguide/best Practices, der bliver benyttet til design af skærmbilleder. Eksempler på principper for brugervenlighed inklusive forslag, som ikke er nævnt i denne kravspecifikation. Krav 259. Forståelige fejlmeddelelser Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal indeholde klart forståelige fejlmeddelelser, som hjælper brugeren til at korrigere fejl, og som ikke forstyrrer workflowet mere end højst nødvendigt. Indholdet af fejlmeddelelserne skal kunne redigeres på en enkel måde af en central eller kommunal administrator, afhængig af den kontekst fejlmeddelelserne tilhører. Krav 260. Opsætning og brug af kontekstafhængige hjælpetekster Kategori: Krav Type: Ikke funktionelt Beskrivelse: Brugergrænsefladen skal indeholde links til hjælpetekster på relevante steder for eksempel i forhold til: It-system. Procesoverblik/forretningsgange. Begreber. Aldersopdelte fokusområder. Udformningen skal følge de facto-standarden for Windows Help. Hjælpeteksterne skal kunne indeholde punktopstillinger, fed tekst, understreget tekst, kursiv tekst og hyperlinks til filer og hjemmesider og diagrammatiske fremstillinger i billedeform. Teksten skal kunne oprettes, ændres og slettes på en enkel måde af en central og kommunal administrator. F o r t r o l i g t S i d e 164/ d e c e m b e r

165 Søgning I Systemet er der i flere af skærmbillederne mulighed for, at kunne opsætte søgekriterier til fremsøgning af elementer, der opfylder søgekriterierne. Der vil være prædefinerede felter til indtastning af søgekriterier og felter til fritekstsøgning. Krav 261. Fremsøgning af sager Kategori: Minimumskrav Type: Funktionelt Beskrivelse: Systemet skal indeholde en søgefunktionalitet, så sagsbehandleren let kan fremsøge de sager, der er relateret til et CPR-nr., navn, adresse eller via fritekstsøgning. Krav 262. Søgning efter data Beskrivelse: I Systemet skal der være nem tilgang til at fremsøge data, og som minimum gælder: At der skal være mulighed for udsøgning af en person ud fra relations- eller rollebetegnelsen eller ved fritekstsøgning. Familien skal fremgå af søgeresultatet. At der skal være mulighed for udsøgning af de indsatser, der er relateret til et CPR-nr., navn, adresse eller ved fritekstsøgning. At alle skærmbilleder skal indeholde en tekstboks til fritekstsøgning. Ved søgning vha. denne tekstboks, bør brugeren præsenteres for en resultatside med matchende resultater. At journalarksnoter skal kunne findes vha. søgning i metadata. At der skal kunne søges i tilfredshedsevalueringer. Krav 263. Søgekriterier skal kunne gemmes Beskrivelse: Søgekriterier skal kunne gemmes til brug på et senere tidspunkt, og listen med gemte søgninger skal være centralt placeret og nemt tilgængelig. Krav 264. Visning af søgeresultater F o r t r o l i g t S i d e 165/ d e c e m b e r

166 Beskrivelse: Sorteringen på søgeresultater skal kunne modificeres fx via: Klik i kolonneoverskrifterne. Markering af forfatter, redigeringsdato og kategori (journalark, dokument, person etc.). Krav 265. Beskrivelse af mulige søgninger Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvilke typer af søgning det vil være muligt at afvikle i Systemet, hvordan de vises, hvordan de kan genbruges samt hvordan de teknisk implementeres (specielt med fokus på fritekstsøgning) Lokalt Office miljø Det skal være muligt for en aktør, at bruge kommunens kontorsoftware i forbindelse med de daglige processer i relation til Systemet. Denne integration er primært nødvendig i følgende tilfælde: Når aktøren skriver eller redigerer dokument eller brev i tekstbehandlingssystemet, skal det være muligt at gemme og tilknytte dokumentet til en sag i Systemet. Når aktøren skriver et dokument, bør stamoplysninger i dokumentet hentes for den aktuelle person i Systemet. Når aktøren korresponderer med brugere pr. , skal ud- og indgående beskeder gemmes i Systemets Sags- og dokumentarkiv. Krav 266. Integration til kommunernes MS Office versioner Kategori: Minimumskrav Type: Ikke funktionelt 4 eller tidligere Beskrivelse: Leverandøren skal sikre, at der kan etableres integration til følgende MS Office versioner for de medvirkende kommuner: MS Office 2003 (Word og Outlook). MS Office 2007 (Word og Outlook). Krav 267. Aktør gemmer dokument på sag 4 eller tidligere Beskrivelse: En aktør, som arbejder på et dokument via kommunens kontorsoftware, skal kunne gemme dokumentet på en sag i Systemets Sags- og dokumentarkiv. F o r t r o l i g t S i d e 166/ d e c e m b e r

167 Krav 268. Aktør får stamoplysninger på dokument 4 eller tidligere Beskrivelse: En aktør, som arbejder på et dokument via kommunens kontorsoftware, skal kunne hente stamoplysninger om den aktuelle person fra Systemet, eksempelvis via en knap/menu e. lign. Krav 269. Aktør får genereret et dokument 4 eller tidligere Beskrivelse: En aktør skal kunne generere et dokument fx et aftaledokument, hvori der flettes data fra Systemet. Krav 270. Aktør gemmer mail på sag 4 eller tidligere Beskrivelse: En aktør, som arbejder med mails via kommunens kontorsoftware, skal kunne gemme en indgående eller udgående mail (selve en og eventuelle vedhæftede filer i binært format) på en sag i Systemets Sags- og dokumentarkiv. Krav 271. Integration med tekstbehandling Kategori: Krav Type: Ikke funktionelt 4 eller tidligere Beskrivelse: Systemet skal kunne uploade/downloade dokumenter i et dokumentformat, der kan bruges af kommunens kontorsoftware til tekstbehandling. Dette format skal følge de obligatoriske åbne standarder, som fremsat af IT- og Telestyrelsen Sikkerhed og brugerstyring Sikkerhed og brugerstyring er en integreret del af både grundfunktionaliteten (Fase 1) og de efterfølgende Faser. Dette afsnit vil gennemgå de sikkerhedsmæssige krav til Systemet, som skal betragtes som tværgående krav til alle Systemets komponenter. Udover de krav, der 62 Jf. OOXML: og ODF: jf. underbilag 3.1M. F o r t r o l i g t S i d e 167/ d e c e m b e r

168 er i dette afsnit, kan der være krav til sikkerhed i de komponentbaserede afsnit, som afspejler specifikke krav til den konkrete komponent Administration og styring af brugere En kommunal administrator vil få ansvaret for at administrere kommunens brugere, oprette dem med basisinformationer samt aktivere og deaktivere dem. Krav 272. Kommunal administrator administrerer brugere Beskrivelse: En kommunal administrator skal kunne oprette og deaktivere brugere (en bruger og til denne relaterede data vil af revisionsmæssige hensyn ikke kunne slettes) i Systemet. En bruger skal som minimum kunne registreres med følgende informationer: Fornavn. Efternavn. Initialer. Entydig nøgle (fx ObjectGUID i AD). Mailadresse. Postadresse. Kontoradresse. Mobilnummer. Telefonnummer. Organisatorisk placering (kontor). Organisatorisk rolle (sagsbehandler, leder etc.). Da Systemet indeholder personfølsomme oplysninger, er der høje krav til sikring af autenticitet. Derfor er det et ufravigeligt krav, at Systemets brugere autentificerer sig ved brug af medarbejder-certifikat. Krav 273. Brugere logger på med medarbejdercertifikat Kategori: Minimumskrav Type: Funktionelt Beskrivelse: Brugere, der har fået brugeradgang til Systemet, skal autentificere sig ved brug af OCES medarbejdercertifikater (MOCES). ). Alternativt kan benyttes en autentifikationsmetode, der sikrer en mindst lige så pålidelig identifikation af brugeren som OCES medarbejdercertifikatet KOMBIT gør opmærksom på, at det i kontrakten mellem Kunden og kommunen omkring brugen af Systemet fremgår at kommunen er ansvarlig for, i situationer hvor der benyttes en federeret brugerstyring, at sikre at brugerne autentificeres på et niveau svarende til krav 273, hvorfor Leverandøren ikke kan stilles til ansvar såfremt kommunen misligeholder denne del af aftalen. Skulle dette afstedkomme et F o r t r o l i g t S i d e 168/ d e c e m b e r

169 Når brugeren har fået adgang til Systemet skal det sikres, at brugeren - såfremt denne indenfor et parameteropsat tidsrum ikke benytter Systemet - bliver lukket ud af Systemet. Brugeren skal efterfølgende autentificere sig overfor Systemet for at få adgang igen. Krav 274. Brugeren autentificerer sig på ny Beskrivelse: Såfremt Systemet ikke anvendes indenfor et parameteropsat tidsrum, skal brugeren logges af Systemet. Brugeren skal efterfølgende autentificere sig overfor Systemet for at få adgang igen. Et vigtigt aspekt i bibringelse af et sikkert System er at registrere, hvem og hvornår, der er foretaget operationer i Systemet. Dette sikrer, at der til enhver tid kan etableres et entydigt revisionsspor omkring brugen af Systemet. Krav 275. Etablering af revisionsspor Kategori: Krav Type: Ikke funktionelt Beskrivelse: Det skal være muligt at registrere og benytte information omkring brugeres (eller services) aktiviteter således, at det i relevante tilfælde er muligt at etablere et revisionsspor eller udføre andre kontroller i forhold til anvendelsen af Systemet. Da Systemet indeholder personfølsomme data, skal revisionssporet endvidere indeholde informationer om, hvilke data den enkelte bruger har læst. Krav 276. Beskrivelse af forslag til revisionsspor Kategori: Info Type: behov hos Leverandøren for at præcisere yderligere forventninger/krav til kommunerne og aktuelle ansvarsfordeling, kan dette ske i bilag 2. F o r t r o l i g t S i d e 169/ d e c e m b e r

170 Beskrivelse: Leverandøren skal beskrive, hvordan et meningsfuldt revisionsspor vil kunne sammensættes i Systemet, og hvordan dette på en sikker måde kan tilgås af den centrale og kommunale administrator. Beskrivelsen bør omfatte: Hvilke logninger der vil blive foretaget. Hvordan disse proaktivt kan monitoreres. Hvordan de kan dokumenteres via udtræk af kontrolrapporter. Hvordan der er forskel på de logs, som den centrale og den kommunale administrator får adgang til at tilgå Administration af brugerroller og funktioner Brugerroller betegner roller som tildeles Systemets brugere mens funktioner betegner de opgaver, der kan udføres i Systemet. Analysen af Systemets aktører og Use Cases (inklusive funktionelle krav) danner fundament for, hvilke brugerroller og funktioner, der skal være til rådighed i Systemet. Krav 277. Brugerroller og funktioner Kategori: Krav Type: Ikke funktionelt Beskrivelse: Som udgangspunkt fastsættes omfanget og betydningen af brugerroller og funktioner via Systemets aktører og Use Cases (inklusive funktionelle krav). En aktør realiseres som en brugerrolle og en Use Case realiseres som en funktion. Krav 278. Kommunal administrator tildeler brugerroller Beskrivelse: En kommunal administrator kan tildele én eller flere brugerroller til en bruger. En sagsbehandler skal kunne tildeles forskellige brugerroller i forskellige typer af sager. Brugerrollen skal kunne tildeles for en periode. En relation mellem en aktør og en Use Case angiver, om aktøren har ret til at udføre Use Casen. I praksis giver dette anledning til, at der kan laves en matrice mellem brugerroller og funktioner, som benyttes som udgangspunkt til at realisere, hvilke brugerroller der må udføre hvilke funktioner: Brugerrolle 1 Brugerrolle 2 Brugerrolle 3 Funktion 1 X Funktion 2 X X Funktion 3 X X F o r t r o l i g t S i d e 170/ d e c e m b e r

171 Krav 279. Kommunal administrator opretter og ændrer brugerroller Beskrivelse: En kommunal administrator kan oprette, ændre og deaktivere brugerroller samt hvilke funktioner disse har ret til at udføre. En brugerrolle og relaterede data til denne, skal bevares af revisionsmæssige hensyn. Jf. Driftskontraktens krav om sikkerhedsrevisionserklæring, punkt Udover, at en bruger får tildelt rettigheder baseret på brugerroller, vil brugerens rettigheder være begrænset af, hvilken kommune brugeren har et tilhørsforhold til. Dette bestemmes ud fra brugerens organisatoriske tilhørsforhold. Krav 280. Bruger får adgang til kommunens egne data Beskrivelse: En bruger får adgang til kommunens egne data ud fra det tilhørsforhold, som brugeren har til kommunen. Krav 281. Historik på brugerrollen Beskrivelse: Systemet skal indeholde historik på: Autorisation af brugeren Sammensætning af brugerroller og funktioner således, at det til enhver tid er muligt at få oplyst, hvilke funktioner der er indeholdt i en konkret brugerrolle. Sammensætning af bruger og brugerroller således, at det til enhver tid er muligt at få oplyst, hvilke brugerroller en konkret bruger har eller har haft. Med baggrund i de brugerroller, som den enkelte bruger har fået tildelt, er det Systemets ansvar, at autorisere brugerens brug af de tilgængelige funktioner. Denne autorisation foregår på serviceniveau og således er det den enkelte services ansvar, at sikre adgang til den data og funktionalitet som servicen indkapsler. Krav 282. Autorisation af brugeren Kategori: Krav Type: Ikke funktionelt F o r t r o l i g t S i d e 171/ d e c e m b e r

172 Beskrivelse: Hver service i Systemet er ansvarlig for, at autorisere brugeren i forhold til de data og funktionaliteter, som servicen indkapsler Sikring af data Et vigtigt parameter til sikring af data er, kun at arbejde med de absolutte nødvendige informationer således at data, der ikke er relevante for Systemet, heller ikke eksisterer i Systemet. Krav 283. Kun nødvendige data eksisterer i Systemet Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal understøtte, blandt andet ved integration af data fra eksterne systemer, at der kun indhentes og gemmes oplysninger, som er nødvendige og relevante Brugerstyringsløsning Systemet skal kunne tilgås via single sign-on (SSO), og det er vigtigt for de deltagende kommuner, at der med introduktionen af Systemet ikke introduceres en ny central brugerstyringsløsning som kommunerne skal anvende ved siden af deres øvrige brugerstyringsløsninger. Krav 284. Eksisterende brugerstyringsløsning Kategori: Krav Type: Ikke funktionelt Beskrivelse: Sikkerhedsarkitekturen i Systemet skal basere sig på en allerede eksisterende central brugerstyringsløsning 64. Derudover er det vigtigt, at der tænkes fremtidssikring ind i sikkerhedsarkitekturen således, at Systemet kan benytte sig af fællesoffentlige initiativer, uden at det betyder omkodning af store dele af Systemet. Krav 285. Fremtidig brug af fællesoffentlig brugerstyring Kategori: Krav Type: Ikke funktionelt Beskrivelse: Sikkerhedsarkitekturen i Systemet skal på sigt uden problemer kunne anvende/integrere til den fællesoffentlige brugerstyring (FOBS 65 ). 64 Som for eksempel Miljøportalens Brugerrettigheds system (DMP BRS). 65 FOBS: jf. underbilag 3.1M. F o r t r o l i g t S i d e 172/ d e c e m b e r

173 Krav 286. Brug af anerkendte standarder Kategori: Krav Type: Ikke funktionelt Beskrivelse: Sikkerhedsløsningen skal baseres på offentlige anerkendte standarder heriblandt SAML 2.0. Krav 287. Adgang via HTTPS Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal basere sig på adgang via HTTPS. Krav 288. Sikring af adgang via både webapplikationer og webservices Kategori: Krav Type: Ikke funktionelt Beskrivelse: Sikkerhedsløsningen skal sikre adgang til data og operationer, både via en brugers tilgang til Systemets brugergrænseflader samt via Systemets forsøg på adgang til webservices (hvor webservices har ansvar for at autorisere til egne data og operationer). Krav 289. Sikring af adgang via brug af claims Kategori: Krav Type: Ikke funktionelt Beskrivelse: En SAML-token, indeholdende de til brugeren knyttede claims, benyttes til validering og autorisation af brugeren. Krav 290. Central autorisationsmekanisme Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemet skal indeholde en central autorisationsvalidering, som er kompatibel med den tilbudte brugerstyringsløsning. Krav 291. Webservices skal kunne aftage tokens Kategori: Krav Type: Ikke funktionelt Beskrivelse: Systemets webservices skal kunne aftage tokens, således som disse bliver præsenteret, når der anvendes en WS trust-baseret protokol. F o r t r o l i g t S i d e 173/ d e c e m b e r

174 Krav 292. Fremtidssikret kodeopbygning Kategori: Krav Type: Ikke funktionelt Beskrivelse: For at fremtidssikre Systemet for eventuelle nyere føderationsstandarder, skal applikationen være baseret på et kodebibliotek (og hermed afskærme den tekniske implementering), framework eller tilsvarende. Ovenstående krav vil eksempelvis kunne opfyldes ved brug af WCF/Windows Identity Foundation 66 i en.net baseret applikation. Følgende diagram skitserer et muligt forløb for en brugers forsøg på adgang til Systemet 67 : Figur 42 Autentifikations- og autorisationsforløb Diagrammet skitserer, hvordan en bruger, ved forsøg på adgang til et system redirigeres til brugerstyringsløsningen for autentifikation og udstedelse af en billet (op og jf. underbilag 3.1M. 67 Eksemplet baserer sig på DMP BRS. For yderligere informationer se jf. underbilag 3.1M. F o r t r o l i g t S i d e 174/ d e c e m b e r

175 bygning af SAML token). Billetten indeholder blandt andet de roller, som brugeren har fået tilknyttet. Billetten returneres herefter til systemet. Brugeren har efterfølgende adgang til systemet med baggrund i de roller, der er medsendt til systemet. Krav 293. Beskrivelse af den tilbudte brugerstyringsløsning Kategori: Info Type: Ikke funktionelt Beskrivelse: Leverandøren skal beskrive og skitsere den tilbudte brugerstyringsløsning blandt andet med fokus på: Systemets nuværende udbredelse i kommunerne. Systemets egnethed til håndtering af brugere i en kommunal kontekst, og hvilke ændringer der skal foretages i brugerstyringsløsningen, for at tilgodese dette. Hvorledes den tilbudte brugerstyringsløsningen modsvarer det ovenfor skitserede autentifikations- og autorisationsforløb (i en tilsvarende skitse). Hvor konsistent arkitekturen i Systemet er med den sikkerhedsarkitektur, som brugerstyringsløsningen stiller krav til. Om der skal foretages fundamentale tilpasninger i Systemet, for at få de 2 løsninger til at spille sammen. Hvor konsistent arkitekturen er med fokus på en brugers adgang til Systemet via brugergrænsefladen og Systemets forsøg på adgang til data og operationer udstillet af webservices, samt Systemet samarbejde med eksterne systemer. Hvordan den kommunale administrator administrerer brugere og roller. Dvs., om dette sker i kommunens AD eller i et centralt administrationsværktøj (eventuel med baggrund i ADFS), og hvordan samspillet er med Organisationskomponentens organisatoriske registrering af aktører. Understøttede standarder og fremtidssikring specielt med fokus på SAML 2.0 og standardens fremtidige udvikling. Teknologisk opbygning af brugerstyringsløsningen. Sikkerhedsmæssige fordele ved brug af brugerstyringsløsningen. Hvilke informationer, der logges i brugerstyringsløsningen, og hvordan en kommunal administrator kan få adgang til at udtrække disse. Hvordan det er muligt, at videregive identitetsoplysninger og rollebeskrivelser, samtidig med udvekslingen af transaktioner mhp. personfølsomme oplysninger. Hvorledes den enkelte service vil håndtere autorisation af brugeren set i forhold til en central autorisationsmekanisme. F o r t r o l i g t S i d e 175/ d e c e m b e r

176 Eventuelle tekniske og geografiske begrænsninger af, hvilke brugere der vil kunne få adgang til at tilgå Systemet og Systemets brugergrænseflader. Brugen af OCES medarbejdercertifikatet set i forhold til resten af sikkerhedsarkitekturen, og herunder muligheden for at spærre en bruger ved brugerens mislykkede forsøg på adgang. Hvordan, og med hvilke kriterier, Systemet vil kunne håndtere, at en sagsbehandler tildeles forskellige brugerroller i forskellige typer af sager. Hvordan, og hvor driften af brugerstyringsløsningen vil foregå. Krav 294. Central administration hos udbyder af brugerstyringsløsningen Kategori: Option Kravtype: Beskrivelse: Udgået Leverandøren skal beskrive og prissætte et scenarie, hvor udbyderen af brugerstyringsløsningen varetager så mange opgaver som muligt i forhold til håndtering af brugere og support, som ellers skulle have været håndteret af den kommunale administrator. F o r t r o l i g t S i d e 176/ d e c e m b e r

177 6. Reference arkitektur Dette afsnit beskriver de arkitekturmæssige og tekniske krav til Systemet. Kravene vil danne det arkitekturmæssige fundament for alle de komponenter, der indgår og kommer til at indgå i Systemet. Udover de fundamentale og tværgående krav til arkitektur og teknik som angivet i dette afsnit, vil der også forekomme krav til konkrete tekniske områder i det komponentbaserede afsnit i afsnit 5, hvor der eksempelvis er krav til konkrete integrationer o. lign. Afsnittet er opbygget efter følgende struktur: Først en gennemgang af retningslinjer og standarder, der har udefrakommende indflydelse på kravene til arkitekturen. Dette er retningslinjer og standarder fra henholdsvis IT- og Telestyrelsen samt den fællesoffentlige digitaliseringsstrategi. Herefter er der en gennemgang af den konceptuelle referencearkitektur for Systemet, som skitserer overordnede krav til opbygningen af arkitekturen. Til sidst er den konceptuelle referencearkitektur nedbrudt til en række tekniske krav. Systemet skal etableres som en central webbaseret sagsbehandlerløsning, der underbygger sagsbehandlingen på området for udsatte børn og unge for alle danske kommuner, såfremt disse indgår aftale med Kunden herom. Krav 295. Central ASP løsning Kategori: Minimumskrav Type: Ikke funktionelt Beskrivelse: Systemet skal etableres som en central løsning (ASP 68 ), som kan stilles til rådighed for alle danske kommuner, såfremt disse indgår aftale med Kunden herom. Krav 296. Beskrivelse af central løsning Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive, hvordan de opfylder kravet om en central løsning, specielt med fokus på de dele af Systemet, som vil blive håndteret decentralt. Som det fremgår af Fase-oversigten i afsnit 2.2 vil Systemet blive udviklet via 4 Faser, hvilket Leverandøren skal tage hensyn til i sine tekniske overvejelser. 68 ASP forstået som Application Service Provider. F o r t r o l i g t S i d e 177/ d e c e m b e r

178 Krav 297. Beskrivelse af konsekvenser af Faseopdelingen Kategori: Info Type: Beskrivelse: Leverandøren skal beskrive eventuelle systemmæssige konsekvenser af Faseopdelingen, herunder hvordan Leverandøren vil imødegå disse konsekvenser IT- og Telestyrelsens anbefalinger IT- og Telestyrelsen har gennem mange år udgivet retningslinjer og standarder for etableringen af it-arkitektur inden for det offentlige. I forbindelse med Systemet ønsker Kunden, at alle relevante anbefalinger og standarder formuleret af IT- og Telestyrelsen overholdes, hvilket vil blive konkretiseret i dette afsnit. Krav 298. Anvendelse af standarder i OIO-kataloget Kategori: Krav Type: Ikke funktionelt Beskrivelse: Anvendelse af standarder skal følge anbefalingerne i OIOkataloget. Systemet skal anvende den stærkest anbefalede itstandard indenfor de relevante kategorier. Som skæringsdato for fastfrysning af relevante standarder i OIO kataloget benyttes 1. september Krav 299. Beskrivelse af anvendelse af standarder i OIO-kataloget Kategori: Info Type: Beskrivelse: Leverandøren skal redegøre og argumentere for, hvilke standarder i OIO-kataloget der benyttes samt eventuelle afvigelser, og hvorfor disse afvigelser vil forekomme. Krav 300. Begreber og snitflader skal følge OIO retningslinjerne Kategori: Krav Type: Ikke funktionelt Beskrivelse: Standardiseringen af begreber og web-service snitflader skal følge de retningslinjer som OIO angiver - og relevante standardiserede begreber og allerede publicerede web-services skal genbruges. F o r t r o l i g t S i d e 178/ d e c e m b e r

179 Fællesoffentlig digitaliseringsstrategi Strategien for Digitalisering af den Offentlige Sektor indeholder en vision for digitaliseringens rolle, med at skabe en effektiv og sammenhængende offentlig sektor med høj servicekvalitet, hvor borgere og virksomheder er i centrum. Strategien er et afsæt for, at potentialet kan realiseres i form af at skabe bedre service til færre omkostninger. Strategien indeholder flg. tre indsatsområder: Bedre digital service. Øget effektivisering. Stærkere tværgående samarbejde. Strategien påpeger behovet for mere forpligtende samarbejder mellem de forskellige myndigheder inden for de enkelte domæner. Her peges bl.a. på følgende: Sammenhæng mellem forvaltningsprocesser og it-understøttelse. Udvikling af fælles services baseret på fælles infrastruktur Overholdelse af fællesoffentlige standarder, snitflader og arkitekturkrav. Systemet skal udvikles som en fælleskommunal service, og anvender en række centrale services hos andre myndigheder, og Systemet baseres på fællesoffentlige standarder, hvor disse findes på de relevante områder. Arkitekturen i Systemet skal derfor være åbent overfor integration til andre offentlige it-løsninger, såvel eksisterende som kommende. Krav 301. Lagdelt og modulær arkitektur skal anvendes Kategori: Minimumskrav Type: Ikke funktionelt Beskrivelse: Leverandøren skal sikre, at arkitekturen er fleksibel, modulær og lagdelt opbygget, og at der er veldefinerede og dokumenterede åbne snitflader mellem de enkelte moduler. Hermed skal understøttes kommende behov for nye sammenhænge indenfor domæneområdet, og gøre det muligt at konfigurere, ændre eller udskifte de enkelte komponenter, services og workflows, uden at det kræver ændring/erstatning på de andre områder. Krav 302. Beskrivelse af lagdelt og modulær arkitektur Kategori: Info Type: 69 ital_forvaltning_2007_2010/, jf. underbilag 3.1M. F o r t r o l i g t S i d e 179/ d e c e m b e r

180 Beskrivelse: Leverandøren skal dokumentere, hvorledes det tilbudte System lever op til den ønskede lagdelte og modulære arkitektur som beskrevet i Krav 301, herunder hvordan Systemet fremstår fleksibelt i forhold til fremtidig videreudvikling med fokus på: Udvidelse med nye aktører. Opsætning af nye processer. Tilknytning af nye komponenter. Kravet om åbne snitflader fremgår af Kontraktens punkt Referencearkitektur for Systemet Med henblik på at overholde ovennævnte strategier og anbefalinger, skal Systemet bygges ud fra følgende referencearkitektur: Figur 43 Referencearkitektur for Systemet 70 Systemet er angivet inden for den stiplede kasse i figuren ovenfor samt klientintegration til lokale Office-miljøer markeret ovenover. Systemet skal kunne integreres til kommunernes forskellige systemplatforme som skitseret. Derudover skal det samlede System bestå af en række funktionelt forskellige komponenter i henhold til afsnit Bemærk at Journalarkkomponenten også integrerer til Sags- og dokumentkomponenten, hvilket, for simplicitetens skyld, ikke fremgår af ovenstående arkitekturtegning. Denne integration gennemgås nærmere i afsnittet om journalarkkomponenten (jf. afsnit 5.5). F o r t r o l i g t S i d e 180/ d e c e m b e r

181 Komponentopdelingen i Systemet skal understøtte Kundens behov for en løsning, der skal være let at vedligeholde og robust overfor fx lovgivningsmæssige ændringer. Samtidig skal komponenterne været kodet sådan, at de er tilstrækkeligt fleksible til at imødekomme - og kunne tilpasses - kommunernes individuelle behov i forhold til Systemet, når dette er hensigtsmæssigt. Indholdet af ovenstående referencearkitektur-tegning gennemgås i det følgende. Systemet er opbygget i en lagdelt arkitektur med tre centrale lag: Web brugergrænseflade, som realiserer brugergrænsefladen og understøtter dialogen med brugerne. Tekniske krav til brugergrænsefladen er beskrevet i afsnit Workflow og integrationslag, som varetager sagsbehandlingsprocesserne, udstiller services og synkroniserer de forskellige kald af services. Tekniske krav til dette lag er beskrevet i afsnit samt i afsnit 5.1. Servicelag, som tilvejebringer dels en række interne forretningsservices, som er specifikke for Systemet og dels en række services, som er etableret på basis af de eksterne services. Tekniske krav til dette lag er beskrevet i afsnit Systemet bygger på et antal integrationer med eksterne systemer, hvor kommunikationen kan være både envejs og tovejs, webservicebaseret eller baseret på filudveksling, og disse er beskrevet i de komponenter, der interagerer med dem: Integrationen til en CPR datakilde er beskrevet i afsnit Integrationen til kommunale ESDH-systemer er beskrevet i afsnit Integrationen til kommunale økonomisystemer er beskrevet i afsnit 5.6. Integrationen til eksternt blanketsystem er beskrevet i afsnit Integrationen til Tilbudsportalen er beskrevet i afsnit Integrationen til Dokumentboks er beskrevet i afsnit Udtræk af Ledelsesinformationer, Danmarks Statistik, Ankestyrelsen og Statens Arkiver er beskrevet i afsnit Integrationen til er beskrevet i afsnit Krav 303. Snitflader som OIOXML-baserede webservices Kategori: Krav Type: Ikke funktionelt Beskrivelse: De veldefinerede og dokumenterede snitflader mellem de enkelte moduler i hvert lag bør udvikles som OIOXML-baserede webservices. Kravet om åbne snitflader fremgår endvidere af Driftskontraktens punkt F o r t r o l i g t S i d e 181/ d e c e m b e r

182 Krav 304. Beskrivelse af applikationsarkitekturen Kategori: Info Type: Beskrivelse: Leverandøren skal, via sammenligning med ovennævnte referencearkitektur, skitsere og beskrive den logiske opbygning af det tilbudte System inklusive: Hvorledes Systemet er lagdelt. Opsplitningen i moduler/komponenter. Benyttede standarder for snitfladerne. Hvilke muligheder der er for konfiguration. Hvilke muligheder der er for udskiftning af komponenter. Konsekvenser for Systemet ved udskiftning af komponenter. Eksempelvis hvis ICS metoden skal udskiftes med en anden metode. Konsekvenserne for Systemet, såfremt en ny komponent skal tilføjes. Eksempelvis hvis ICS metoden skal suppleres med en anden metode. Ovenfor viste arkitektur afspejler udelukkende den logiske applikationsarkitektur. I systemmæssig sammenhæng er der behov for at supplere den logiske model med ikke-funktionelle og tekniske egenskaber. Dette beskrives dels i afsnit 6.2 vedrørende tekniske krav og dels i de enkelte komponenter, såfremt der er særskilte krav til eksempelvis sikring af data ved integration etc Principper for DUBU services Med udgangspunkt i de generelle principper for serviceorienteret arkitektur (jf. ITog Telestyrelsen 71 ), beskrives nedenfor de principper for services, som ønskes anvendt i Systemets arkitektur. Krav 305. Systemet skal opbygges efter SOA principper Kategori: Krav Type: Ikke funktionelt Beskrivelse: Arkitektur, interoperabilitet og standarder skal så vidt muligt udvikles og styres efter SOA-principperne, som de er formuleret af IT- og Telestyrelsen 72. Princip Beskrivelse #1 En service skal understøtte forretningsprocesser En service bør udvikles som en komplet forretningsfunktionalitet, 71 jf. underbilag 3.1M soa/pjece_serviceorienteret_arkitektur.pdf, jf. underbilag 3.1M. F o r t r o l i g t S i d e 182/ d e c e m b e r

183 der stilles til rådighed for andre forretningsfunktioner og processer. Eksempler på forretningsfunktioner kunne være opdater klientstamdata, opkræv restskat, hent oplysninger i XX-registeret, udarbejd transportplan og omkostninger. Disse services skal kunne tilgås af servicekonsumenter, der enten kan præsentere resultatet direkte for en bruger i en browser, eller kan anvende dem i andre programmatiske sammenhænge, som fx et bookingsystem. Services kan dog også være af teknisk karakter, fx understøtte den tekniske infrastruktur, sikkerhed, print, arkivering mv. #2 Genbrugelige services En service bør udvikles med genbrug for øje også selv om en service ikke umiddelbart skal genbruges. Hermed sikres, at man med en relativ lille indsats kan gøre servicen tilgængelig for andre systemer. #3 Kontraktbaserede services Services beskrives af en kontrakt en præcis og bindende aftale mellem serviceudbyder og serviceanvender. Al anvendelse af servicen skal ske udelukkende på grundlag af kontrakten, og anvendelsen af servicen må ikke være baseret på implicitte aftaler mellem udbyder og anvender. Servicekontrakten beskriver også de servicekvaliteter, som serviceleverandøren skal leve op til, og dermed er alle aktører bekendt med de præcise serviceforpligtelser. Endelig indeholder servicekontrakten en beskrivelse af den semantiske og tekniske snitflade. Udformning af servicekontrakter på snitflader stiller store krav i den indledende specifikationsfase til vedligeholdelsen og versioneringen af servicen. I et udviklingsprojekt med mange aktører og forskellige systemer er det nødvendigt, at servicekontrakterne specificeres så tidligt i forløbet som overhovedet muligt. #4 Løs kobling Services i SOA er løst koblede, dvs. services kan findes og anvendes, uden at anvenderen behøver at have kendskab til, hvordan serviceudbyder har implementeret servicen. Servicekontrakten er eneste fælles reference. Services skal netop udvikles som services, der kan genbruges i forskellige sammenhænge. Det betyder konkret, at der generelt ikke må designes med baggrund i en bestemt servicekonsuments behov. Løs kobling gør det også muligt for serviceudbyder at ændre i implementeringen, at flytte til en ny platform mv. #5 Services er en abstraktion over forretningsfunktionalitet og information Services er en abstraktion over forretningsfunktionalitet og information, der stilles til rådighed for serviceforbrugere via en offent- F o r t r o l i g t S i d e 183/ d e c e m b e r

184 liggjort servicekontrakt. Servicens funktionalitet er kun kendt og tilgængelig via det interface, den tilbyder ( Black box ). En service består af et service-interface og en serviceimplementering. Det essentielle i en service-orienteret arkitektur er relationen mellem service-interfaces. En servicekonsument må aldrig være afhængig af andet end beskrivelsen af service-interfacet. Dette princip betyder også, at implementeringen kan ske uafhængigt af servicekonsumenten i form af en eksisterende applikation eller ved nyudvikling. En service er en gruppering og indkapsling af funktionalitet og data. En service udstiller funktionaliteten til andre i form af operationer. Services har følgende overordnede egenskaber: Services er veldokumenterede og udstillede De kan tilgås fra alle platforme via en veldefineret snitflade De er autonome løst koblet Hvor en service er ansvarlig for et sæt data, kan data kun tilgås via dens operationer Dette illustreres i figuren nedenfor: Figur 44 - En service er en black box #6 Lokationsuafhængig anvendelse af services Services skal være lokationstransparente. Det skal være muligt, at tilgå services uafhængigt af, hvor servicekonsumenten befinder sig fysisk. Det betyder bl.a. også, at sikkerhedsmodellen ikke må bygge på, at servicekonsumenten befinder sig på et bestemt netværk. #7 Platformsuafhængig anvendelse af services Anvendelse af en service bør foregå uafhængigt af den platform, servicen er implementeret på. En platform er i denne sammenhæng kombinationen af programmeringssprog, operativsystem, kommunikationsprotokoller mv. For at opnå en platformsuafhængig anvendelse af en service, er F o r t r o l i g t S i d e 184/ d e c e m b e r