Forprojekt vedr. digitalisering af handicap og udsatte voksne-området. Leverance 3: Oplæg om samlet it-arkitektur Velfærdsministeriet og KL Juni 2009 Revision.Skat.Consulting.Financial Advisory.
Indholdsfortegnelse 1. Indledning... 4 1.1 Leverancens indhold... 6 2. Vision for it-understøttelse af handicapog udsatte voksne-området... 8 2.1 Vision for it-understøttelsen... 8 2.3 Principper for it-understøttelsen... 11 3. It-arkitektur... 15 3.1 Sagsmodul... 17 3.2 Øvrige opgaver... 22 3.3 Generelle moduler... 23 3.4 Systemintegrationer... 26 3.5 Data... 31 4. Model for implementering af itarkitekturen... 32 4.1 Trin 1 etablering af den grundlæggende funktionalitet33 4.2 Trin 2 etablering af avanceret funktionalitet... 35 4.3 Trin 3 etablering af den resterende funktionalitet... 37 Bilag Bilag A. Enterprise arkitektur-metoden ift. digitalisering på handicap- og udsatte voksne-området... 39 Revision.Skat.Consulting.Financial Advisory.
Copyright Deloitte Business Consulting A/S. All rights reserved. Rapportens anvendelse Denne rapport er alene udarbejdet til Deloittes opdragsgiver ud fra det givne opdrag. Deloitte påtager sig intet ansvar for andres anvendelse af rapporten. Kontakt Spørgsmål til denne rapports indhold kan stiles til: Mette Lindgaard, partner, telefon 36 10 26 53 René Dan Adrian, seniormanager, telefon 36 10 23 20 Om Deloitte Business Consulting Fra idé til virkelighed Deloitte Business Consulting fokuserer på udvikling og effektivisering af kundernes organisation, kerneprocesser, økonomistyring og it for at bidrage til realisering af kundernes strategiske målsætninger. Vi kender den offentlige sektor til bunds og kombinerer vores faglige kompetencer med evnen til at lede, styre og gennemføre projekter i et politisk miljø. Det kan være som rådgivere eller som ansvarlige for processer fra idéstadie til implementering. Deloitte er Danmarks største revisions- og rådgivningsfirma. Vi tilbyder en bred vifte af ydelser og kombinerer konsulentrollen i Deloitte Business Consulting med Deloittes kompetencer inden for revision, skat og finansiering. Det giver vores kunder en unik mulighed for at få integrerede løsninger, som er skræddersyet til de enkelte opgaver. Vi er en del af den globale virksomhed Deloitte Touche Tohmatsu med 165.000 medarbejdere på verdensplan. Vi udvikler og deler viden på tværs af kontorer i mange lande. Inspirationen fra udlandet kombineret med systematisk metodeudvikling på tværs af landegrænser sikrer, at vores løsninger altid tager udgangspunkt i den seneste viden. Det er forudsætningen for, at vi i dag og i fremtiden kan være en attraktiv og værdiskabende rådgiver. Deloitte Business Consulting A/S Telefon 36 10 20 30 Fax 36 10 20 40 E-mail: businessconsulting@deloitte.dk www.deloitte.dk Besøgsadresse Weidekampsgade 6 2300 København S Postadresse Deloitte Business Consulting A/S Postboks 1600 0900 København C 3
1. Indledning Velfærdsministeriet og KL gennemfører et forprojekt vedrørende digitalisering af handicap- og udsatte voksne-området. Forprojektet vedrørende digitalisering af handicap- og udsatte voksneområdet er igangsat af Velfærdsministeriet og KL og skal danne baggrund for et egentligt digitaliseringsprojekt på området. Målet med digitaliseringen er at skabe grundlaget for en sammenhængende og helhedsorienteret indsats med borgeren i centrum. Det egentlige digitaliseringsprojektet skal således sikre etablering af itunderstøttelse af den kommunale sagsbehandling, ledelsesinformation, smidig kommunikation mellem de relevante aktører, herunder koordinering af indsatsen mellem myndighed og udfører, samt en yderligere udbredelse af allerede udviklede socialfaglige it-systemer i udførerleddet. I lyset af de omfattende ressourcer, der anvendes på handicap- og udsatte voksne-området, og den store kompleksitet i opgaveløsningen, som er af afgørende betydning for mange borgere, er der et stort kommunalt behov for at forbedre it-understøttelsen. Digitaliseringen af området indgår således også som et element i den fællesoffentlige strategi for digitalisering på det sociale område, ligesom utallige analyser peger på behovet for it-understøttelse. Da formålet med forprojektet er at skabe grundlag for det egentlige digitaliseringsprojekt, er der i projektdesignet lagt vægt på, at de analyser, der udarbejdes i forprojektet, skal have en sådan karakter, at de vil kunne indgå direkte i det egentlige digitaliseringsprojekt, herunder ligge til grund for udarbejdelse af kravspecifikationer m.v. Forprojektet skal således overordnet munde ud i detaljeret projektplan og businesscase, som skal kunne anvendes direkte som grundlag for at tilrettelægge digitaliseringsprojektet. Leverancen tager udgangspunkt i en række dokumenter, herunder: Leverancerne fra kortlægnings- og begrebsarbejdet. Domænebestyrelsen Social & Omsorgs retningsgivende principper for arbejdet med en fælles it-arkitektur. Hvidbog om it-arkitektur. Fællesoffentlig strategi for digitalisering på det sociale område. Afdækning af behov for lokal ledelsesinformation på handicapområdet og området for udsatte voksne. 4
Kortlægning Forprojekt vedr. digitalisering: Leverance 3 OIO EA-metoden. Referencearkitekturen for ESDH (FESD2). Kommunernes digitale strategi (KL). KL s it-strategiske anbefalinger på social- og sundhedsområdet. Forprojektet omfatter følgende fem hovedleverancer: Leverance 1: Kortlægning af arbejdsgange og kommunikationsstrømme. 1 2 3 Faglig struktur IT-arkitektur 4 5 Projektplan Business case Leverance 2: Faglig struktur for god sagsbehandling på handicap- og udsatte voksne-området, herunder udvikling af indsatskatalog, målgruppeklassifikation og plan for udvikling af funktionsudredningsmetode. Leverance 3: Oplæg om samlet it-arkitektur. Leverance 4: Detaljeret projektplan for det samlede digitaliseringsprojekt fra primo 2009 og 3-4 år frem. Leverance 5: Businesscase, succeskriterier og effektmål for det samlede digitaliseringsprojekt. Der foretages selvstændige afrapporteringer for hver enkelt leverance. Nærværende notat samt bilag udgør leverance 3. Således udgør leverance 1 og 2, herunder den generiske sagsbehandlingsmodel for handicap og udsatte voksne-området, jævnfør figuren nedenfor, et væsentligt input til it-arkitekturen. Heri angives, hvilke processer der skal understøttes, samt hvilke afhængigheder der er mellem de enkelte procestrin. 5
Generisk model: Handicap og udsatte voksne Henvendelse Sagsoplysning Vurdering Afgørelse Bestilling Opfølgning Henvendelser fra: - Borgere (tlf./mail) - Pårørende/værge/ kontaktperson (tlf./mail) - Bekymrede borgere (tlf./mail) - Andre forvaltninger (mail/system) - Visitatorer (system/mail) - Hospital (mail/snitflade til Medcom) - Kommunale leverandører (system) -Andre leverandører (tlf./mail/system) - Undervisningsvejledere (mail) Hvis CPR er oplyst hentes personoplysninger i KMD A850, ellers A040. Screening af relevans dvs. om borgeren kan ansøge, om det er rette myndighed. I modsat fald henvises videre, vejledes eller afvises Sag oprettes i journal og/eller KMD (ansøgning dokumenteres) Sager fordeles efter CPR, specialistfunktioner, team, belastning eller lign. (advis til ansvarlig sagsbehandler/elektronisk sagsliste) Evt. aftale om besøg i borgerens hjem/udskrivningskonference/ møde dokumenteres (system med kalender/ advis/ elektronisk besøgsliste) Skalérbar udredningsmetode (adgang til funktionsevnemetoden fx. i 100-sager) Evt. indhentning af samtykke pr. brev (dokumenteres i journal) Evt. indhentning af supplerende oplysninger fra fx læge, hjemmehjælp, specialteam, aktivitetstilbud, værested, værksted og bostøtter. Elektronisk adgang til eksisterende oplysninger og evt. kontakt til VISO (tlf./mail/system/medcom) Tilbud om handleplan (dokumenteres i system) Evt. udarbejdelse/ revidering af handleplan efter fast skabelon; registreres i journal (evt. automatisk generering) Hvis hjemmebesøg hos borger/ udskrivningskonference/ møde: Oplysninger dokumenteres på bærbar pc evt. via on-line adgang; borger validerer oplysninger Hvis off-line overføres noter fra bærbar pc til system efter besøg/ udskrivningskonference/ møde Evt. beregning (adgang til beregningssystem fx. i 100- sager) Faglig vurdering sammenfattes; målgruppe, tilbuds- og ydelsesbegreber anvendes foreløbigt (digital adgang) Afklaring af hvilket tilbud, der vil være bedst for den konkrete borger (snitflade til Tilbudsportal, autosøgning på tilbud/ydelser) Evt. handleplan drøftes/skriftlig dialog med borger Udarbejdelse af bevillingsindstilling. Indstilling genereres elektronisk fra udredning og faglig vurdering og kan redigeres Indstilling sendes til høring på tilbud (mail/system) Indstilling sendes i partshøring hos borgeren (brev/mail) Evt. behandling af indstilling i visitationsudvalg/ledelse (indstilling sendes med advis) Evt. tilbagemelding fra visitationsudvalg/ledelse: Oplysninger mangler; Imødekommelse af indstilling; Ikke imødekommelse af indstilling (indstilling sendes med advis) Afgørelse udarbejdes i skabelon (Faste skabeloner samles, evt. elektronisk overførsel af elementer fra indstilling) Ved bevilling: Borger modtager afgørelsesbrev (brev/mail) Afgørelsen registreres i journal (elektronisk overførsel af data). Endelig registrering af målgruppe, tilbud og ydelser (digital adgang) Evt. registrering af borger på venteliste (ventelistesystem) Ved registrering på venteliste evt. vurdering af midlertidig ydelse i ventetidsperioden; ny sagsoplysning starter Ved ledig plads orienteres sagsbehandler (advis) Ved ledig plads orienteres borger og tilbud (mail/system) Borger accepterer eller afviser tilbud (mail/tlf./brev) Ved afslag: Borger modtager afgørelse og oplyses om klagemulighed (mail/brev) Kopi af bevillingsskrivelse sendes til økonomiafdeling (advis/ direkte registrering i økonomisystem) Bestilling udarbejdes/ genereres til leverandør indeholdende bevilling, elementer fra handleplan, mål for indsatsen, rammer for opfølgning m.m. (system) Evt. andre forvaltninger og jobcenter underrettes (mail/advis) Opfølgning defineres i handleplan og bestilling (advis) Opfølgning efter x mdr. (advis) Individuelt tilsyn (advis, registrering i system) Opfølgning ad hoc, hvis tilbuddet evt. skal ændres eller ved ændringer i borgerens behov (mail/system) Evt. manglende oplysninger indhentes og der foretages ny vurdering 7 Figur 1: Generisk sagsbehandlingsmodel fra projektets leverance 1 Den offentlige sektor Kommunen Socialområdet Handicapog udsatte voksneområdet It-arkitekturen er beskrevet på et overordnet niveau, således at den vil kunne fungere i samtlige 98 kommuner og er dermed robust over for de forskellige valg, kommunerne har foretaget med hensyn til konkrete teknologier og systemarkitekturer. Handicap- og udsatte voksne-området er endvidere kendetegnet ved at udgøre en afgrænset delmængde af kommunens samlede opgaveportefølje, jævnfør figuren til venstre. Projektgruppens oplæg skal derfor kunne fungere i sammenhæng med en strategi for socialområdet, for kommunen og for den offentlige sektor som helhed. 1.1 Leverancens indhold Leverance 3 vedrørende it-arkitektur indeholder følgende delleverancer: Vision for it-understøttelse af handicap- og udsatte voksneområdet: Visionen skal anvendes som en rettesnor for etableringen af en fælles it-arkitektur for området, herunder angive de principper, der skal lægge til grund for konkrete arkitekturvalg. 6
It-arkitektur: It-arkitekturen skal angive de moduler og funktioner, som arkitekturen skal indeholde. Arkitekturen beskrives på logisk niveau og vil således ikke indeholde angivelse af konkrete systemer eller teknologier, som modulerne skal/kan implementeres i, da den konkrete implementering vil afhænge af de enkelte kommuners konkrete it-arkitektur og systemer, der anvendes. Snitflader: Som en integreret del af it-arkitekturen beskrives de snitflader, der skal etableres for at få den beskrevne arkitektur til at fungere i praksis. Angivelsen af snitflader vil være koblet til modulerne i arkitekturen og vil på overordnet niveau angive, hvilke data der udveksles samt formålet med snitfladen. Der vil i udarbejdelsen af leverancerne være særligt fokus på: Snitflader til andre områder inden for og uden for kommunens it-miljø. Muligheden for integration til eller genanvendelse af kommunens tværgående systemer. At allerede foretagne it-investeringer i kommunerne skal respekteres i videst muligt omfang. 7
2. Vision for it-understøttelse af handicap- og udsatte voksneområdet Visionen for it-understøttelse af handicap- og udsatte voksne-området angiver de retningslinjer og principper, som skal være styrende for it-udviklingen på området. Visionen for den fremtidige it-understøttelse af handicap- og udsatte voksne-området omfatter to dele, herunder dels den egentlige vision, som sætter de overordnede retningslinjer for it-understøttelsen i kommunerne, og dels en række principper for det fremadrettede arbejde med digitalisering på området. Visionen og principperne sætter rammerne for det videre forløb i digitaliseringen af handicap- og udsatte voksne-området. Både fordi de udgør et pejlemærke for den arkitektur, der er udarbejdet i forprojektet, og fordi principperne udstikker retningslinjerne for den efterfølgende kravspecificering af modulerne i arkitekturen. I forprojektet er der således udviklet en målarkitektur, der kan tilpasses lokale prioriteringer og faktiske muligheder og hermed være rammen for udviklingen af it-understøttelsen på handicap- og udsatte voksneområdet over en årrække. I forlængelse af dette vil næste fase i digitaliseringsprojektet omfatte kravspecifikation, som kan anvendes lokalt og danne grundlag for senere tilretninger i systemerne i forhold til både funktionalitet og arbejdsdeling mellem moduler og systemer. 2.1 Vision for it-understøttelsen Visionen for den fremtidige it-understøttelse af handicap- og udsatte voksne-området skal anvendes som en rettesnor for etableringen af en fælles it-arkitektur, herunder angive de principper, der skal ligge til grund for valg af arkitektur. Visionen for it-udviklingen inden for handicap- og udsatte voksneområdet er udarbejdet med henblik på at imødekomme de udfordringer, som området står over for i dag og i fremtiden, både for den enkelte borger, sagsbehandleren og den daglige ledelse af området. 8
Visionen for it-understøttelsen af handicap- og udsatte voksne-området er: Handicap- og udsatte voksne-området skal understøttes effektivt af en fleksibel og åben it-arkitektur, der tilgodeser den enkelte kommunes behov, herunder digital kommunikation med relevante interessenter. Målet med digitaliseringen er at skabe grundlaget for en sammenhængende og helhedsorienteret indsats med borgeren i centrum. Derfor skal it-arkitekturen: Understøtte bedre overblik og mere systematik i sagsbehandlingen og leverancen af sociale tilbud. Understøtte en målrettet indsats på baggrund af valide og opdaterede oplysninger. Understøtte udtræk af ledelsesinformation og måling af effekt med henblik på bedre faglig og økonomisk styring. Lette kommunikationen mellem relevante interessenter, herunder borgeren, kommunens sagsbehandlere, andre sektorområder internt i kommunen, sundhedsvæsenet, leverandører og centrale myndigheder. 2.2 Sammenhængen til it-arkitektur- og standardiseringsarbejdet på det sociale område Mulighederne for at realisere visionen for it-understøttelsen på handicap- og udsatte voksne-området skal ses i tilknytning til den markedsbaserede udbredelsesmodel, der påtænkes anvendt, og de overordnede principper for arbejdet med it-understøttelse, som i øvrigt gælder for det sociale område. Overordnet set opereres der i arbejdet med standardisering på det sociale område med en række principper: Den fælles arkitektur etableres og implementeres med respekt for de allerede foretagne investeringer. It-løsninger etableres med udgangspunkt i forretningens behov. Strategiske it-investeringer og -initiativer skal tage udgangspunkt i den fælles arkitektur. 9
Den fælles it-arkitektur tager udgangspunkt i og understøtter fællesoffentlige og tværgående initiativer. Der anvendes en komponentbaseret it-arkitektur. Dokumentation af arkitektur og standarder deles med og stilles til rådighed for andre myndigheder. Der sker en løbende overvågning af og opfølgning på den teknologiske udvikling. Disse principper er formuleret med udgangspunkt i det gældende markedsparadigme, som både den fællesoffentlige nationale strategi og digitaliseringsstrategien på det sociale område er et udtryk for, og som også er klart udtrykt i KL s Kommunernes digitale strategi : It i legoklodser har store fordele for kommunerne. Det bliver lettere og billigere at ændre opgaveløsningen og at konkurrenceudsætte og udskifte leverandører. Og legoklodsernes åbne, standardiserede grænseflader gør det muligt for både kommunen og borgeren at følge med i den digitale sagsgang. Med dette afsæt opereres der med en markedsbaseret udbredelsesstrategi. Handicap- og udsatte voksne-området kendetegnes til forskel fra fx udsatte børn og unge-området ved, at der er flere it-leverandører. Der sigtes derfor mod markedsbaserede løsninger, hvor flere leverandører på baggrund af funktionelle kravspecifikationer udvikler de ønskede funktionaliteter, som man kender det fra blandt andet elektroniske omsorgsjournaler på ældreområdet. Herved søges der taget højde for, at løsningerne skal kunne implementeres i kommunernes forskelligartede miljøer. Ud fra en it-arkitekturbetragtning indebærer denne model imidlertid også en række udfordringer for det konkrete projekt. Ikke mindst fordi der i stedet for ét samlet udbud opereres med en række lokale udbud/købsbeslutninger, hvorved det bliver vanskeligere at sikre efterlevelsen af de anvendte it-arkitekturprincipper, standarder m.v. 1 It-arkitekturen i digitaliseringsprojektet på handicap- og udsatte voksne-området skal således spænde over to hensyn. For det første at opstille retningsgivende målsætninger for it-understøttelsen og udvikle standarder, der kan lette dataudvekslingen, mindske bindinger til enkeltleverandører osv. For det andet skal principperne være så fleksible, at de kan tilpasses den mangeartede forskellighed ved forskellige løsninger og strategivalg, som eksisterer i kommunerne og hos itleverandørerne. Det vil sige, at man gerne vil påvirke udviklingen 1 Leverance 4: Projektplanen vil blandt andet forholde sig til denne problematik, da den indeholder en gennemgang af projektets forudsætninger, herunder risikovurdering, konsekvensanalyse og vurdering af udgifter. 10
uden at have den adgang til at konkretisere it-arkitekturen, som et udbud giver mulighed for. I forlængelse af disse principper og strategier lægges der i den konkrete it-arkitekturleverance op til, at der etableres en retningsgivende, komponentbaseret it-arkitektur, hvor sammenhængende funktionaliteter er grupperet sammen. Samtidig søges der i videst mulig udstrækning anvendt fællesoffentlige komponenter og standarder (fx FESDstandarder, fællesoffentlig brugerstyring m.v.), ligesom de standardiseringsarbejder, som skal igangsættes, stilles til rådighed for andre og i øvrigt anvender det fællesoffentlige standardiseringssetup (OIO- XML). Ambitionen med leverancen er således at opstille en målarkitektur med en realistisk komponentdefinition, som kommuner og it-leverandører kan arbejde sig hen imod, og som understøttes af fællesoffentlige standarder og komponenter. 2.3 Principper for it-understøttelsen For at sikre, at den fremtidige it-understøttelse lever op til visionen for it-understøttelse af området, opstilles en række principper, der skal fungere som rettesnor for specificering og udvikling af konkrete løsninger på området. Principperne er grupperet efter it-arkitekturhvidbogens fem områder: Interoperabilitet Sikkerhed Åbenhed Fleksibilitet Skalerbarhed. De fem grundlæggende principper skal sikre en fleksibel og åben itarkitektur, som understøtter de enkeltes kommuners individuelle krav og de it-investeringer, som kommunerne allerede har foretaget. Principperne er blevet til på baggrund af en konkret prioritering af og tilpasning til området. Principperne er nedenstående uddybet yderligere. Interoperabilitet Interoperabilitet beskriver principper, der skal sikre, at kommunens systemportefølje kan udveksle data automatisk på tværs systemer og moduler og samtidig understøtter udveksling af data med andre myndigheder, interessenter og samarbejdspartnere. Interoperabilitet er således et centralt element for at kunne effektivisere processer og arbejdsgange via digitalisering i kommunerne og er tæt knyttet til visionen om, at it-arkitekturen skal lette kommunikationen mellem relevan- 11
te interessenter, at der skal ligge valide og opdaterede oplysninger til grund for indsatser over for borgeren, samt at der skal kunne udtrækkes ledelsesinformation. Fælles begrebsmodel. Data i systemerne bør i videst muligt omfang overholde en fælles begrebsmodel for området og FESD. En fælles begrebsmodel vil gøre det muligt at etablere en række standardelementer til dataudveksling på tværs af området. En fælles begrebsmodel kan med fordel baseres på de standardiserede begreber vedrørende tilbud, ydelser og målgrupper, som er udarbejdet i forbindelse med forprojektet. De fælles begreber er en forudsætning for at få sammenhæng i indsatsen og er som sådan meget vigtige i en kommende itunderstøttelse. Samtidig vurderes det, at det kan være en udfordrende opgave at implementere begreberne, da implementeringen også vil påvirke eksisterende systemer, i det omfang de skal være i stand til at anvende den fælles begrebsmodel til udveksling af data med andre systemer. Flere integrationsmuligheder. Systemerne skal understøtte flere former for integration. Systemerne skal således som standard i et vist omfang kunne integreres på flere forskellige måder, herunder fx portalintegration til fremstilling af data på en borgerportal samt system-system-integration til udveksling af data mellem systemer, fx udveksling af sagsdata mellem EOJog ESDH-systemer. Standardiseret dataoverførsel. Dataoverførsler via veldefinerede grænseflader. Overførsel af data bør i udgangspunktet ske via servicekald, der ved hjælp af veldefinerede snitflader tillader systemerne at udveksle data. Dette vil mindske bindinger mellem systemerne og øge mulighederne for at dele data, således at de samme data ikke manuelt skal oprettes i flere forskellige systemer med deraf følgende mulighed for fejl. Fordelen for kommunerne er også, at dataoverførslerne bliver mere standardiserede og dermed lettere at vedligeholde. Sikkerhed Sikkerhed beskriver principper, som skal sikre nem adgang til data og systemer i kommunen for både borgere, leverandører af ydelser, sundheds- og plejepersonale, sagsbehandlere osv., og som samtidig lever op til sikkerhedskrav i lovgivningen. Sikkerhedsprincipperne vil blandt andet bidrage til at opfylde ønskerne fra kommunale sagsbehandlere om at mindske behovet for at skulle logge ind i flere forskellige systemer for at kunne udføre selv simple handlinger. Single sign-on. Det skal være transparent for brugeren, at forskellige funktioner understøttes af forskellige systemer. Der vil også fremadrettet være behov for en blanding af forskellige systemer. Derfor får sagsbehandleren behov for at skifte mel- 12
lem flere systemer, hvilket skal kunne gøres mere gnidningsløst end i dag. Rollestyret adgang. Adgang til data skal styres af roller, således at forskellige interessenter kan tilgå de samme data samtidig med, at databeskyttelsesloven overholdes. Åbenhed Åbenhed beskriver principper, som skal sikre, at data kan anvendes på tværs af kommunens systemer og moduler, og at eksterne parter kan læse og forstå de data, der udveksles med kommunen. Der er således centrale principper for at understøtte visionen om en åben it-arkitektur, der gør det muligt at kommunikere digitalt med relevante interessenter. Webstandarder til dataudveksling. Åbne webstandarder, der skal anvendes som udgangspunkt for udveksling af data mellem systemer, herunder blandt andet (OIO)XML, XSD, NDR, WSDL og SOAP. Webstandarder til præsentation. Åbne webstandarder som fx HTML, XHTML, CSS og WCAG skal danne grundlaget for systemernes understøttelse af borgerens selvbetjening og indsigt i egen sag. Fleksibilitet Fleksibilitet beskriver principper, som skal sikre, at de udviklede løsninger kan fungere i kommunernes forskellige it-miljøer. Principperne skal således sikre, at de udviklede it-løsninger kan understøtte både nugældende og fremtidige behov i kommunerne, herunder blandt andet understøttelse af lovgivningen på området. Komponentbaseret/serviceorienteret arkitektur. Løsninger bør udvikles, således at kernefunktionalitet kan genanvendes, og således at en kommunes samlede it-portefølje kan sammensættes efter behov og uden synlige snitflader for sagsbehandleren. Jo flere komponenter, der defineres, jo større fleksibilitet vil kommunerne få med hensyn til at kunne sammensætte deres systemer efter behov. Erfaringer fra andre områder viser dog, at mange og små moduler kan øge kompleksiteten i en sådan grad, at vedligeholdelse og systemernes svartider bliver negativt påvirket. Platformsuafhængighed. Løsninger skal kunne installeres på forskellige platforme. 13
Skalerbarhed Skalerbarhed beskriver principper, som skal sikre, at de udviklede løsninger kan tilpasses ændringer i krav til håndtering af datamængder og brugere. Skalerbarhed. De enkelte services skal individuelt kunne skaleres, således at de kan understøtte forskellige behov for håndtering af datamængder og brugere på tværs af kommunerne og ændrede behov for håndtering af datamængder og brugere på grund af ændringer i fx lovgivning, metoder osv. 14
3. It-arkitektur Med afsæt i visionen for it-udviklingen på handicap- og udsatte voksne-området er der udarbejdet en itarkitektur, der skal styrke kommunernes muligheder for effektivt at understøtte området og på samme tid tage hensyn til de allerede foretagne investeringer i it. En it-arkitektur kan beskrives på flere niveauer, jævnfør nedenstående figur fra hvidbogen om it-arkitektur. Figur 2: Forskellige niveauer for beskrivelse af it-arkitektur Da arkitekturen skal kunne fungere i samtlige landets 98 kommuner og respektere de it-investeringer, der allerede er foretaget i videst muligt omfang, jævnfør it-visionen, er det centralt, at arkitekturen beskrives på en måde, som gør det muligt at implementere denne i kommunernes forskelligartede miljøer. I figur 3 nedenfor beskrives it-arkitekturen som en modulbaseret applikationsarkitektur 2 svarende til det næstnederste niveau i figur 2 ovenfor, idet denne model opfylder ovenstående krav. Den modulbaserede applikationsarkitekturmodel er teknologiuafhængig, hvilket gør det muligt for de enkelte kommuner at tilpasse løsningen til deres konkrete it-arkitektur. Arkitekturen er endvidere dels baseret på kortlægningen af kommunale arbejdsgange og it-anvendelse, dels på den generiske sagsbehandlingsmodel, der er udarbejdet som del af forprojektets leverance 1, hvilket er med til at sikre, at modellen kan anvendes på tværs af kom- 2 Hvilket svarer til leverance C2. Applikationsarkitektur i OIO EA-metoden. 15
muner. Moduler skal i denne sammenhæng forstås som it-systemer, der enten kan fungere for sig selv, eller indbygges i andre it-systemer, hvor modulet vil fungere som en integreret del af systemet. Modulerne er opbygget af en eller flere funktioner, der udfører bestemte opgaver, fx at understøtte udarbejdelsen af handleplaner. En væsentlig forudsætning for, at den modulbaserede applikationsarkitektur vil fungere i praksis, er, at der etableres en fælles begrebs- og datamodel for området. Der er i forbindelse med forprojektets leverance 2 etableret en fælles begrebsmodel på udvalgte områder. Det er centralt, at efterfølgende projekter etablerer fælles begrebs- og datamodeller for de øvrige områder. Fælles begrebs- og datamodeller sikrer, at data kan udveksles mellem de forskellige moduler, uden at informationer går tabt i processen. Figur 3: It-arkitektur (komponentopdelt applikationsarkitektur) for handicap- og udsatte voksne-området Arkitekturen består af et sagsmodul med en række funktioner, der er nærmere beskrevet nedenfor, en række moduler vedrørende øvrige opgaver, som ikke er relateret til den generiske sagsbehandlingsmodel, samt en række tværgående generelle moduler, der kan anvendes inden for alle områder i kommunen. 16
Endvidere angiver it-arkitekturen, hvilke integrationer der skal etableres, herunder om de skal etableres som systemintegrationer (servicekald) eller som filudvekslinger. I det følgende beskrives de elementer, der indgår i arkitekturen konkret. 3.1 Sagsmodul Sagsmodulet er tæt knyttet til det faglige indhold i sagsbehandlingen inden for handicap- og udsatte voksne-området og samler funktionerne i den generiske sagsmodel, der er udviklet i forprojektet. Sagsmodulet er inddelt i 8 funktionsområder, som anvendes i løbet af et standardsagsforløb. Funktionerne i sagsmodulet tager blandt andet højde for kommunernes ønske om at få overblik over sagsbehandlingen samt om at få mulighed for at danne meningsfuld ledelsesinformation på tværs af sager. Funktionerne er grupperet i ét samlet modul af flere årsager. For det første er funktionerne målrettet de særlige behov og vilkår i sagsbehandlingen på handicap- og udsatte voksne-området og er derfor i mindre grad anvendelige på andre områder. For det andet vurderes det, at markedet i højere grad kan tilgodeses gennem funktioner, der på forskellig vis kan kobles til de eksisterende systemer, som i meget varierende grad understøtter nogle af funktionerne i dag. Afhængig af hvilke leverandører kommunerne vil samarbejde med, kan de enkelte funktioner således bygges på de eksisterende løsninger. 3.1.1 Sagsadministration Sagsadministration sætter rammerne for registrering og sammenstilling af data og aktiviteter på en sag og er således en vigtig funktionalitet i sagsbehandlingen. Funktionen strukturerer både stamdata knyttet til borger, sag og sagsbehandler samt sagsdata knyttet til selve sagsforløbet. Funktionsområdet sikrer således, at der er sammenhæng mellem de hændelser, der er på en sag, herunder udredning, handleplaner, journalnotater, dokumenter, ind- og udgående kommunikation osv. 17
Sagsadministrationsfunktionen strukturerer ligeledes en række nøgledata knyttet til de forskellige procestrin i den generiske sagsbehandlingsmodel 3 : Henvendelse: Det skal angives, hvor henvendelsen, der startede sagen, kom fra og eventuelt, hvilket medie der blev anvendt. Sagsoplysning: I forbindelse med sagsoplysningen skal sagsadministrationsfunktionen indeholde et link til de centrale funktioner i sagen, herunder udredning, beregning og handleplan. Det skal ligeledes være muligt at registrere et eventuelt samtykke, ligesom der skal være links til et samtykkedokument. Der skal endvidere være links til kommunikation i forbindelse med sagsoplysningen, herunder kommunikation med borgeren, VISO, læger, behandlere samt eventuelt tilknyttet referat fra hjemmebesøg/udskrivningskonference. Alle relevante aktiviteter skal automatisk registreres i journalen. Vurdering: Vurderingen skal indeholde den faglige vurdering med angivelse af målgruppe, tilbud og ydelser med støtte i udviklede begreber. Der skal være mulighed for at angive den faglige vurdering i et tekstfelt, alternativt i et tilknyttet dokument. Konkrete tilbud skal kunne identificeres og registreres via integration til Tilbudsportalen. Det skal i den forbindelse vurderes, om Tilbudsportalens eksisterende webservices er dækkende. Det skal endvidere være muligt at registrere de tilbud, der har været afsøgt i forbindelse med afklaringen. I de sager, hvor der skal udarbejdes en indstilling, baseres denne på en standarddisposition, der skal kunne tilpasses de enkelte sager. Standarddispositionen kan med fordel opbygges i forbindelse med udarbejdelse af en eventuel metode for sagsbehandling på området. Indstillingen dannes på baggrund af funktionalitet indbygget i afgørelsesfunktionen, jævnfør nedenfor. Afgørelse: Afgørelsen registreres dels som strukturerede data, dels som et konkret dokument, der delvist genereres ved hjælp af afgørelsesfunktionen. Ved at registrere afgørelsen som strukturerede data forbedres mulighederne for at udarbejde statistikker og ledelsesinformation med udgangspunkt i afgørelsen. Endelig skal bevillingen registreres som strukturerede data, der omfatter både den konkrete ydelse og økonomiske data. Ved hjælp af workflowmodulet (beskrives nærmere nedenfor) genereres afgørelsesdokumentet, og afgørelsen registreres automatisk i journalen. 3 Sagsadministrationsfunktionen gør brug af mange af de øvrige funktioner i systemet, og de vil derfor kort blive beskrevet i dette afsnit, men vil blive yderligere uddybet i de følgende afsnit. 18
Bestilling: Sagsadministrationsfunktionen skal registrere bestillingen af ydelsen i sagen, og funktionen skal anvende workflowmodulet til at generere et bestillingsdokument til leverandøren ved hjælp af afgørelsesfunktionen, sende en standardbesked til relevante afdelinger i kommunen som e-mail, XML osv. afhængig af systemkonfiguration, registrere bestillingen i journalen og gemme bestillingen som et dokument på sagen. Herudover skal der være mulighed for at sende bestillingen til leverandøren, jævnfør beskrivelsen i kommunikationsfunktionaliteten og systemintegration via filer nedenfor. Opfølgning: Sagsadministrationsfunktionen skal automatisk oprette en påmindelse på sagen ved bestilling, således at sagsbehandleren adviseres, når der skal følges op på sagen. Dette skal sikre, at der løbende følges op på indsats og mål. Under opfølgning hører også tilsyn med den enkelte borger. Det skal derfor være muligt at registrere dato (planlagt/faktisk) for tilsyn, og hvilken type tilsyn der er gennemført/skal gennemføres, samt at angive et link til en tilsynsrapport i dokumenthåndteringsmodulet. Det gælder for samtlige sagsskridt nævnt ovenfor, at workflowmodulet skal anvendes til at strukturere og automatisere sagsforløbet i videst mulige omfang, således at kommunernes ønske om en mere struktureret proces understøttes. Endvidere skal alle relevante hændelser på sagen automatisk registreres i journalen, således at de data, der registreres i sagsadministrationsfunktionen, automatisk anvendes i journalen. Endelig gælder, at sagsadministrationsfunktionen automatisk skal anvende planlægningsfunktionen til at oprette påmindelser på de elementer i sagen, hvor dette er relevant, fx ved opfølgning på handleplaner, bevillinger, der er ved at udløbe, påmindelser om tilsyn m.v. 3.1.2 Udredning Udredningen af borgerens situation og funktionsniveau er kernen i sagsoplysningen og dermed en central del af sagsbehandlingen på handicap- og udsatte voksne-området. Udredningen skal således understøtte tildelingen af den rette indsats og understøtte en systematisk dokumentation af sagsoplysningen. Udredningsfunktionen kan med fordel baseres på en standardiseret metode, jævnfør også den generiske model. Udredningen skal kunne omfatte alle sagstyper og varierende kompleksitet. Det er derfor væsentligt, at udredningen er dynamisk i opbygningen. Ved opfølgning og nye ansøgninger skal det være muligt at generere nye versioner, som (delvist) baserer sig på gamle sagsoplysninger, der derefter kan rettes i fornødent omfang. 19
3.1.3 Beregning I nogle sagstyper, typisk sager om merudgifter, er beregning af den støtte, som borgeren er berettiget til, et vigtigt element i sagsbehandlingen, og der er ofte tale om komplekse beregninger. Derfor er det relevant at automatisere beregningen i en særskilt funktionalitet. Beregningsfunktionen skal indeholde relevante standardberegninger og regelsæt, herunder fx grænseværdier m.m. Der skal også være mulighed for at lave ad hoc-beregninger, fx i en regnearksfunktion. 3.1.4 Handleplan Udarbejdelsen af handleplaner er et væsentlig element i sagsbehandlingen, da det er handleplanen, der tilgodeser sammenhængen på tværs af tilbud og ydelser, de langsigtede mål, som opstilles i samarbejde med borgeren, m.m. Derfor er handleplansfunktionen en vigtigt funktion i en it-løsning for handicap- og udsatte voksne-området. Handleplansfunktionen skal kunne håndtere alle aktiviteter i forbindelse med handleplaner (oprette, redigere osv.) og skal oprette et dynamisk element på sagen, som udfyldes med strukturerede data fra sagen. Handleplanen skal i indhold og omfang kunne tilpasses kompleksiteten i den enkelte sag og kan med fordel baseres på standarddispositioner. I det videre digitaliseringsprojekt vil det således være relevant at definere en standarddisposition for handleplanen, som med fordel kan opbygges i forbindelse med udarbejdelse af en eventuel metode for sagsbehandling på området. 3.1.5 Kommunikation Kommunikation med både interne og eksterne parter er en central del af sagsbehandlingen. Der skal derfor være mulighed for at generere dokumenter og/eller informationspakker, som kan sendes til andre parter, der ikke har adgang til systemet. Det skal også være muligt at indlæse data, som modtages fra andre parter, og placere dem i de rette elementer på sagen. Det skal være muligt at udvælge, hvilke elementer på en sag, der skal indgå, herunder dokumenter, journalnotater, handleplaner, funktionsudredninger, beregninger, strukturerede data osv. Det skal endvidere være muligt at anvende standarddispositioner for dokumenter, således at fx indstillinger, afgørelser og bestillinger altid bygges op på samme måde og indeholder de samme elementer. Sådanne standarddispositioner kan med fordel opbygges i forbindelse med udarbejdelse af en eventuel metode for sagsbehandling på området. Der skal kunne vælges mellem forskellige outputformater (XML, XPS, PDF, ODF, OOXML osv.). 20
3.1.6 Afgørelse Afgørelsen fastsætter borgerens retskrav og er derfor et meget vigtigt dokument i sagen. Det samme gælder de dokumenter, der knytter sig til afgørelsen i form af en eventuel indstilling og bestilling til leverandøren. Det er derfor væsentligt, at disse dokumenter indeholder den nødvendige dokumentation og er målrettet modtagernes behov. I denne funktion kan der således udarbejdes forslag til indstilling, afgørelse og bestilling på baggrund af sagens oplysninger. Indstilling, afgørelser og bestillinger skal baseres på en standarddisposition, der skal kunne tilpasses de enkelte sager. Standarddispositionen kan med fordel opbygges i forbindelse med udarbejdelse af en eventuel metode for sagsbehandling på området. Indstillingen, afgørelsen eller bestillingen skal både indeholde strukturerede og ustrukturerede data. 3.1.7 Planlægning Planlægningsfunktionen skal sikre en effektiv udnyttelse af ressourcerne og er således en vigtig funktion i sagsforløbet. Planlægningsfunktionen skal gøre det muligt for sagsbehandleren at planlægge møder med borgere, behandlere og pårørende samt at følge op på sager osv. direkte fra sagsadministrationsfunktionen, således at aftaler oprettes med links til den rette kontekst i sagen. Planlægningen skal foregå fra sagsniveauet, men planlægningsfunktionen skal ligeledes gøre det muligt at se samtlige planlagte aktiviteter for en sagsbehandler på tværs af sager, herunder også de planlagte adviser. Således skal planlægningsmodulet sikre, at adviser på sager indgår i sagsbehandlerens kalender med konkrete opgaver som fx opfølgning på sager. Det skal endvidere være muligt at danne sig et overblik over planlagte aftaler for flere personer, herunder en afdeling i kommunen. Funktionen skal integreres med kommunens valgte kalendersystem. Funktionen skal tage hensyn til det forhold, at der ikke må fremgå personfølsomme oplysninger i kalenderen, det vil sige, at den fx skal henvise til journalnummer. 3.1.8 Indsatskatalog Indsatskataloget skal beskrive de indsatser, der er tilgængelige på handicap- og udsatte voksne-området. Indsatskataloget skal gøre det muligt at sammenkæde indsatser, tilbud og ydelser på en ensartet og standardiseret måde, således at der er en fælles begrebsramme for dette på tværs af kommuner og udførerleddet. 21
Indsatskataloget skal spille tæt sammen med afgørelsesfunktionen, hvor de generiske indsatser fra indsatskataloget kædes sammen med specifikke ydelser fra fx Tilbudsportalen. 3.2 Øvrige opgaver Øvrige opgaver er opgaver, der ikke ligger inden for den generiske sagsbehandlingsmodel, men i stedet er relateret til den øvrige myndighedsudøvelse i kommunen inden for handicap- og udsatte voksneområdet. Nedenfor beskrives tre moduler, der understøtter øvrige myndighedsopgaver og styring. 3.2.1 Magtanvendelse Kommunerne skal indberette hændelser, hvor det har været nødvendigt at anvende magt over for en borger i en af kommunens ydelser, således at kommunen kan udarbejde statistikker over magtanvendelsen og eventuelt sætte ind over for overdreven eller uhensigtsmæssig magtanvendelse. På den vis skal modulet understøtte målsætningen om at understøtte udtræk af ledelsesinformation og måling af effekt med henblik på bedre faglig og økonomisk styring. Modulet skal anvendes til at registrere den magtanvendelse, der har fundet sted over for en borger, således at kommunens registreringspligt overholdes. Data skal kunne anvendes i forbindelse med indberetninger og udarbejdelse af ledelsesinformation og statistikker. Indberetningerne vil sandsynligvis kunne overføres elektronisk fra systemer i udførerleddet til magtanvendelsesmodulet. 3.2.2 Tilsyn Kommunerne har pligt til at gennemføre tilsyn på de institutioner, som kommunen anvender, såvel som til at gennemføre tilsyn med, at borgerne modtager den hjælp, de har krav på. Det er derfor væsentligt, at der er systemunderstøttelse til at sikre en struktureret og systematisk registrering af tilsynet. På den vis vil modulet understøtte målsætningerne om, at kommunen skal kunne yde en målrettet indsats på baggrund af valide og opdaterede oplysninger, samt om, at kommunen skal kunne udtrække ledelsesinformation og måle effekt med henblik på bedre faglig og økonomiske styring. Det personrettede tilsyn forventes at indgå i opfølgningen på den enkelte sag og vil således være omfattet af sagsmodulet. Tilsynsmodulet er målrettet det institutionelle tilsyn, og modulet skal understøtte kommunen i forbindelse med planlægning og gennemførelse af kommunens tilsyn med tilbuddene på området. Det skal således være muligt at registrere både planlagte og gennemført tilsyn, herunder datoer 22
for disse, typen af tilsyn, resultat af tilsyn, links til eventuelt supplerende dokumenter osv. 3.2.3 Økonomi/fremskrivning Kommunerne efterspørger bedre muligheder for at foretage en kvalificeret opfølgning på økonomien på området. Herunder er der behov for at kunne foretage fremskrivninger af økonomien på baggrund af foretagne disponeringer, således at der opnås et klart overblik over kommunens samlede økonomi. Modulet skal gøre det muligt for kommunen at opsamle og bearbejde de økonomiske data på baggrund af registreringerne i blandt andet sagsmodulet, herunder udgifter relateret til borgere på ventelister, som på sigt vil belaste budgettet. Modulet vil ligeledes trække på informationer indsamlet i ledelsesinformationsmodulet. Det skal være muligt at foretage fremskrivninger, således at der kan lægges budgetter for området og ske en løbende opfølgning, herunder sammenholde faktisk og forventet forbrug på området, og det skal ligeledes være muligt at gennemføre hvad hvis -analyser. Funktionaliteten i dette modul og samspillet med kommunens økonomisystem skal nøje overvejes i det fremadrettede projektforløb. 3.3 Generelle moduler De generelle moduler repræsenterer funktioner, som med fordel kan anvendes på tværs af kommunens områder, og er således ikke unikke for handicap- og udsatte voksne-området. En del af disse moduler findes ikke i kommunerne p.t., men er defineret i forbindelse med digitaliseringen af handicap- og udsatte voksne-området. Der er seks generelle moduler, herunder: ledelsesinformation, borgeroverblik, ventelistehåndtering, dokumenthåndtering, journal og workflow. Kortlægningen i leverance 1 har vist, at disse moduler/systemer ikke altid findes som separate moduler/systemer, men i stedet som en integreret del i forskellige systemer. Således indeholder EOJ-systemerne oftest deres egen journal- og dokumenthåndtering og nogle gange også funktioner til håndtering af ventelister. Kommunernes udtrykte ønske om bedre ledelsesinformation og udveksling af oplysninger på tværs af afdelinger kan dog ikke understøttes tilfredsstillende på denne måde. Det er derfor vurderingen, at kommunerne opnår den bedste løsning med den største synergi, hvis de seks moduler holdes som separate moduler, der kan anvendes til at understøtte kommunens samlede systemportefølje. Således vil det facilitere videns- og dataudveksling på tværs af kommunens afdelinger, hvis fx journal- og dokumenthåndteringen foreta- 23
ges i fælles systemer. Det skal dog sikres, at sagsbehandlerne kun får adgang til de relevante informationer i henhold til lovgivningen. Modulerne beskrives nærmere i det følgende. 3.3.1 Ledelsesinformation Modulet ledelsesinformation skal sammenstille data fra de øvrige moduler og systemer med henblik på at levere information, som kan anvendes til at styre indsatsen på området. Informationen skal omfatte statistik og information for hele området, og det er således ikke hensigten, at modulet skal anvendes til at give konkret information om en enkelt borger. Informationen skal dog (i anonymiseret form) være CPR-henførbar med henblik på anvendelig statistik, således at fx effekterne af indsatser kan opgøres i forhold til indsatser. Kommunerne har i vidt omfang efterspurgt bedre ledelsesinformation på handicap- og udsatte voksne-området, som kan understøtte styringen af området. Herunder er det vigtigt at få overblik over både målgruppe, aktiviteter og økonomi. Det er ikke muligt i de nuværende løsninger. Ledelsesinformationen giver således mest værdi for kommunerne, hvis det er muligt at sammenstille information fra budgetsystem og afregningssystem samt data fra flere områder, herunder beskæftigelses- og ældreområdet. 3.3.2 Borgeroverblik Modulet borgeroverblik skal anvendes til at præsentere et overblik over kommunens engagement med en borger, herunder hvilke ydelser der leveres til borgeren, hvilken kommunikation der har været med borgeren osv. Modulet kan anvendes til at give overblik for både borger og sagsbehandler samt eventuelt andre relevante interessenter under hensyntagen til, hvilke informationer de må få adgang til i henhold til blandt andet persondataloven. Modulet er centralt for sagsbehandleren i forbindelse med relevansafklaringen under procestrinnet henvendelse i den generiske sagsbehandlingsproces, idet modulet giver sagsbehandleren det nødvendige overblik til at afklare, om borgeren er hjemhørende i kommunen, om borgeren har en eksisterende sag i kommunen, hvilken sagsbehandler borgeren skal visiteres til osv. Modulet vil dog også være et naturligt startsted senere i processen, idet sagsbehandleren ved senere henvendelser eller ved systemadviser hur- 24
tigt kan danne sig et overblik over borgerens engagement med kommunen. For borgeren vil modulet kunne fungere som udgangspunktet for indblik i egne sager i kommunen. Det bør i den forbindelse overvejes, hvorvidt borger.dk kan anvendes som indgang til dette. 3.3.3 Ventelistehåndtering Ventelistehåndtering er et generelt modul, som kun understøttes i ringe grad i dag, hvor ventelister ofte håndteres i tekstbehandling eller regneark. Ventelister skal kunne oprettes for relevante ydelser, typisk botilbud og dagtilbud. Det skal være muligt at tilføje en borger på en venteliste for en konkret ydelse eller for et ydelsesområde, og der skal sendes en advis til sagsbehandleren, når en ydelse bliver ledig. Ventelistefunktionen er også relevant på andre områder, fx ældreområdet. Udvikling af en ventelistehåndtering skal ske under hensyntagen til de særlige forhold, som gør sig gældende på området, herunder at anciennitet ikke (nødvendigvis) er afgørende for, om en borger skal tilbydes en ledig plads, og at kommunen ikke nødvendigvis har driftsansvar for konkrete tilbud (gælder for private, regionale eller andre kommuners tilbud). Der kan her med fordel hentes inspiration fra tilsvarende arbejde med at etablere ventelistehåndtering i Region Midt og Syd. 3.3.4 Brugerstyring Funktionen brugerstyring skal anvendes til at kontrollere brugernes adgang til systemet og dets forskellige funktioner og data. Det skal blandt andet være muligt at angive forskellige roller, som har forskellige rettigheder i systemet. Til hver rolle skal der kunne knyttes flere personer. Modulet skal kunne trække på oplysninger fra kommunens generelle brugerkontrol, fx Windows Active Directory (AD), og understøtte offentlige standarder inden for brugerstyring, herunder fx digitale signaturer (OCES), SAML 2.0 og den fællesoffentlige loginløsning Nem- Log-in i forhold til eksterne brugere. 3.3.5 Dokumenthåndtering Dokumenthåndteringsmodulet er forventeligt baseret på FESDstandarden og skal fungere som dokumentlager for alle dokumenter på sagen. Det skal være muligt at registrere alle tilknyttede data på dokumenterne (metadata som fx sagsbehandler, borger, sag osv.), og do- 25
kumenthåndteringsmodulet skal kunne håndtere alle relevante operationer på et dokument, herunder opret, rediger, slet, versionsstyring osv. Dokumenthåndteringen skal kunne tilgås på et vilkårligt tidspunkt i sagsforløbet, men det skal også være muligt at knytte dokumenter til et specifikt sagsskridt, jævnfør den generiske model. 3.3.6 Journal Journalmodulet skal håndtere kommunens journal og sikre, at kommunens notatpligt overholdes. Journalnotater skal kunne oprettes på et vilkårligt tidspunkt i sagsforløbet, men det skal også være muligt at knytte journalnotater til et specifikt sagsskridt. Det er væsentligt, at oprettelsen af journalnotater automatiseres mest muligt, således at hændelser på sagen så vidt muligt oprettes automatisk i journalen, eventuelt med muligheden for, at sagsbehandleren kan tilføje yderligere informationer til automatisk oprettede journalnotater. Modulet kan med fordel overholde anbefalingerne i KL s rapport vedrørende God Administrativ Praksis (GAP) for de kommunale journalark. 3.3.7 Workflow Workflowunderstøttelse er centralt for digitaliseringen af handicap- og udsatte voksne-området, da etablering af workflows kan automatisere og standardisere arbejdsgange og processer. På den måde kan workflow sikre, at væsentlige sagstrin udføres, og at nødvendige data registreres, hvilket vil understøtte kommunernes ønske om en øget systematik i sagsbehandlingen. Workflowmodulet skal kunne anvendes af de forskellige moduler og systemer i kommunen til både at sikre en ensartet og automatiseret gennemførelse af aktiviteter og sagsskridt på en sag og sikre den nødvendige skalerbarhed og fleksibilitet i sagsbehandlingen. Det er således funktionalitet, som kan være relevant for alle moduler, men især sagsmodulet kan anvende workflow til at automatisere og standardisere sagsskridt og understøtte en standardisering af sagsbehandlingsprocessen i det omfang, det giver mening. 3.4 Systemintegrationer 3.4.1 Strategi for systemintegration Systemintegrationerne er væsentlige for at sikre opfyldelsen af målene med digitaliseringen af handicap- og udsatte voksne-området, herun- 26
der især målsætningerne om bedre overblik og mere systematik i sagsbehandlingen og leverancen af sociale tilbud, om en mere målrettet indsats på baggrund af valide og opdaterede oplysninger og om at lette kommunikationen mellem relevante interessenter, herunder borgeren, kommunens sagsbehandlere, andre sektorområder internt i kommunen, sundhedsvæsenet, leverandører og centrale myndigheder. Det er væsentligt, at der defineres en fælles standard for, hvordan de forskellige systemer og moduler skal udveksle data. I afsnit 2.2 ovenfor er angivet tre principper for interoperabilitet: 1) Fælles begrebsmodel, 2) Flere integrationsmuligheder og 3) Standardiseret dataoverførsel. Af disse principper følger, at dataudveksling i videst muligt omfang skal foregå via webservices, det vil sige, at data, der udveksles, pakkes ind i et webservicekald. Dette behandles i afsnit 3.4.2. Det vurderes dog, at der er en række eksisterende systemer, som ikke i dag understøtter webservices, og hvor transaktionsmængden er for lille til, at det kan betale sig at udveksle webservices til at håndtere dataudvekslingen. For disse systemer etableres dataudveksling via filer. Dette behandles i afsnit 3.4.3. Det vil bero på en konkret vurdering, hvorvidt en given dataudveksling vil ske som webservice eller filudveksling. Indplaceringen af de enkelte dataudvekslinger i henholdsvis afsnit 3.4.2 og 3.4.3 er således foreløbig og kan ændre sig i forbindelse med udarbejdelsen af funktionelle krav i det videre projekt. Grundlaget i integrationen er den fælles begrebsmodel, idet en fælles definition af sager, dokumenter og øvrige relevante entiteter på området vil gøre det nemmere at udveksle data, da behovet for konverteringer vil være minimale, når en fælles begrebsmodel anvendes. 3.4.2 Systemintegration via services For at tilgodese en smidig og effektiv sagsbehandling på handicap- og udsatte voksne-området er det relevant at sikre integration mellem de ovenfor nævnte moduler og en række øvrige systemer inden for såvel som uden for kommunen. Den foretrukne metode til integration er servicekald, hvor der er direkte kommunikation mellem de to systemer, som udveksler data. CPR Det er centralt for sagsbehandlingen, at sagsbehandleren er i besiddelse af korrekt information for at kunne foretage en fyldestgørende screening og visitering af borgeren. Til dette anvendes CPR-registeret, idet det her er muligt at se, hvilken kommune borgeren er bosiddende 27
i. Endvidere anvender mange kommuner adresse eller CPR-nummer som sagsfordelingsnøgle. Det skal være muligt at kalde CPR-registeret, således at stamdata på en borger kan hentes og/eller opdateres på baggrund af oplysninger i dette register med henblik på ensartet og korrekt registrering af data, hvilket er væsentligt for at sikre høj datakvalitet. Umiddelbart vil borgeroverblik og sagsmodulet have størst behov for at anvende denne integration. Hjælpemiddelsystemer Det er væsentligt, at sagsbehandleren har adgang til relevante informationer i forbindelse med sagsoplysningen og afklaring af behov. I hjælpemiddelsystemerne er der oplysninger om, hvilke hjælpemidler de enkelte borgere eventuelt er tildelt. Det er ligeledes muligt at se, om der er udarbejdet en udredning eller registreret andre dokumenter på sagen, som kan være relevante i forbindelse med sagsbehandlingen. Adgangen skal naturligvis være tilrettelagt, således at den tilgodeser reglerne på området, herunder at borgeren skal give samtykke til indhentning af oplysninger. Umiddelbart vil borgeroverbliksmodulet have størst behov for at anvende denne integration. Beskæftigelsessystemer Det er væsentligt, at sagsbehandleren i forbindelse med henvendelse og vurdering er i stand til at se i blandt andet kommunens beskæftigelsessystem, om der er relevante verserende eller historiske sager. Inden der kan opnås adgang til at se indholdet af disse sager, skal der indhentes samtykke. Umiddelbart vil borgeroverbliksmodulet have størst behov for at anvende denne integration. Børneområdesystemer Når handicappede børn fylder 18 år, overgår sagsbehandlingen typisk fra kommunens børn og unge-forvaltning til voksen- og handicapforvaltningen. Ofte er der endvidere aftaler om, at der skal være et samarbejde om børnene, fra de er 16 år, således at overdragelsen af sagen mellem forvaltninger kan ske på en smidig måde, ikke mindst for børnene. I dag er det dog ikke muligt at udveksle data på tværs af forvaltningsområderne, hvorfor en sådan adgang skal etableres. Overdragelsen må dog ikke ske uden borgerens samtykke. 28
Ældreområdesystemer Det er relevant at integrere med systemerne, der anvendes på ældreområdet, idet en del af de borgere, der betjenes på handicap- og udsatte voksne-området, modtager ydelser, der leveres af ældreområdet i kommunen, fx modtager nogle hjemmehjælp eller bor i plejeboliger. Det er især i forbindelse med dannelse af borgeroverblikket, at det kan være relevant at kalde systemerne med henblik på at vise, at der er igangværende sager på en borger registreret i disse systemer. 3.4.3 Systemintegration via filer Der er i dag en række systemer, som ikke stiller servicekald til rådighed for integration i forhold til andre systemer, og hvor det vurderes, at fordelen ved at anvende servicekald er mindre end omkostningerne forbundet med at etablere denne funktionalitet i systemerne. Det skyldes blandt andet, at antallet af transaktioner relateret til disse systemer er forholdsvis begrænset. Økonomisystemer Det er centralt, at kommunen er i stand til at følge op på økonomien på handicap- og udsatte voksne-området. Der er derfor behov for at integrere med kommunens økonomisystemer, således at økonomien i forbindelse med bevilgede tilbud automatisk registreres på både sagen og i økonomisystemet. Alternativt kan et ønske om at sammenholde faktiske og forventede udgifter nødvendiggøre, at der skabes adgang til de fakturerede udgifter i økonomisystemerne, således at sammenligningen sker i sagsmodulet. Afregningssystemer Det er væsentligt, at fremskrivninger af økonomien kan beregnes korrekt. Derfor er der behov for at kunne tilgå informationer fra afregningssystemerne, da disse systemer indeholder information omkring priser for de enkelte ydelser. Sygehus, læge, apotek Kommunerne udveksler data med især læger. Der er ofte tale om anmodning om lægefaglige udtalelser, som foregår via LÆblanketudveksling. Der findes i dag en ny løsning, Netforvaltning fra Kommuneinformation, som gør det muligt at håndtere udveksling af blanketter på en standardiseret og struktureret måde. I dag er løsningen primært tænkt i forhold til samarbejdet mellem praktiserende læger og kommunens arbejdsmarkedsløsning, men løsningen kunne også sagtens være relevant for handicap- og udsatte voksne-området. 29
Øvrig kommunikation med læger, sygehus og apoteker foregår i dag via MedCom-meddelelser, men umiddelbart vurderes disse løsninger ikke som relevante for projektet, da der her primært er tale om kommunikationsbehov i udførelse af det sociale arbejde (udførerleddet). Ankestyrelsen Kommunerne skal årligt indsende data for antallet af magtanvendelser til Ankestyrelsen. Det skal derfor være muligt at udveksle sagsoplysninger i et struktureret format. Andre kommuner Der vil i forbindelse med overtagelse af sager fra andre kommuner være behov for kommunikation med disse kommuner. Det skal derfor være muligt at udveksle sagsoplysninger i et struktureret format. Systemer i udførerleddet For at sikre en smidig udveksling af sager og sagsdata mellem de kommunale sagsbehandlere og leverandørerne er det centralt, at det er muligt at udveksle data elektronisk mellem systemerne. Der er derfor behov for at aftale og implementere OIOXMLstandarder i forbindelse med design af sagsmodulet. Der er således behov for blandt andet at kunne gennemføre en høring på en institution vedrørende potentielle nye borgere samt for at kunne afsende en konkret bestilling til en leverandør. Center for Rusmidler Kommunerne skal kunne sende indberetninger om misbrug til Center for Rusmiddel, som vedligeholder en statistik om dette. Tilbudsportalen Det skal være muligt at oprette tilbud på Tilbudsportalen fra kommunens systemer, hvor oplysninger om tilbud vedligeholdes. Det skal være muligt at søge i data fra Tilbudsportalen fra handleplans- og afgørelsesfunktionen, således at relevante tilbud smidigt kan afsøges og registreres på sagen. Danmarks Statistik Kommunerne skal periodisk sende en række oplysninger om deres sager til Danmarks Statistik (DST). Det skal være muligt at sende disse oplysninger automatisk fra systemerne i et standardiseret og struktureret format. 30
3.5 Data Definitionen af en standardiseret datamodel for handicap- og udsatte voksne-området er central for at sikre, at det er muligt at anvende forskellige moduler og systemer og stadig være i stand til at udveksle informationer mellem kommuner og systemer og moduler fra forskellige leverandører. 3.5.1 Datamodel I figur 4 nedenfor er angivet en overordnet datamodel for handicap- og udsatte voksne-området. Datamodellen angiver de væsentligste entiteter på området og er således ikke en fuldstændig model for de data, der er på området. Det anbefales, at der i forbindelse med udarbejdelsen af kravspecifikationerne for de i arkitekturen angivne moduler etableres en detaljeret fælles datamodel, herunder at der udarbejdes fælles begreber/værdilister for alle væsentlige områder i modellen, således at dataudveksling og etableringen af ledelsesinformation smidiggøres i størst muligt omfang. Datamodellen er koordineret med OIO-projektet om datastandardisering i forbindelse med DUBU, men der skal i arbejdet med detaljering af datamodellen koordineres yderligere med DUBU-projektet. Sagsbehandler 1 Samtykke Aftale Dokument Udredning * * Henvendelse 1..* Venteliste * Bevilling * * Sag Målgruppe 0..* Borger 1 1..* Sagsnummer Sagstype * Bestilling 1..* 1 1..* 0..1 * 1 Indsatskatalog <<Versionert>> Handleplan Faglig vurdering 0..* Ydelseskategori 1 1 0..1 Samlet Indsats Indstilling 1..* 1..* 0..1 Tilbud Godkendt til * 1..* Ydelse 1..* Indsats Varighed /Kategori[1..*] 1 1 Afgørelse Afgørelsestype Begrundelse Formål Leverandørindsats 1..* Figur 4: Overordnet datamodel for handicap- og udsatte voksne-området (UML 2.0 Static Structure) Figuren viser, at sag er et helt centralt dataelement, som knytter mange af dataene på borgeren sammen. Datamodellen er blevet til på baggrund af arbejdet med arkitekturen for handicap- og udsatte voksneområdet og er blevet afstemt med det arbejde, der pågår omkring DUBU. Datamodellen er medtaget for at dokumentere og viderebringe 31
de overvejelser, der har ligget til grund for etableringen af arkitekturen for digitaliseringen af handicap- og udsatte voksne-området. 3.5.2 Overordnet beskrivelse af dataflowet per systemintegration I tabellen nedenfor angives overordnet, hvilke data der overføres via de angivne grænseflader. Grænseflade Integrationsmetode Data Modul, der anvender grænseflade CPR Service Personstamdata. Sagsadministration Hjælpemiddelsystemer Service Udredning, ydelser (hjælpemidler) Borgeroverblik Ledelsesinformation Ventelistehåndtering Magtanvendelse Borgeroverblik Ledelsesinformation Tilbudsportalen Fil Ydelser Sagsadministration (afgørelse, indsatskatalog) Beskæftigelsessystemer Service Data til brug for udredning Sagsadministration Børneområdesystemer Service Historik på borger, herunder sagsdata, tidligere udredninger, handleplaner osv. Borgeroverblik Ledelsesinformation Sagsadministration Borgeroverblik Ledelsesinformation Ældreområdesystemer Service Sagsdata Ledelsesinformation Borgeroverblik Økonomisystemer Fil Økonomidata, bestillinger Økonomi/fremskrivning Ledelsesinformation Sagsadministration Afregningssystemer Fil Bestillinger Sagsadministration Sygehus, læge, apotek Fil LÆ-blanketter (filer sendes til og fra Netforvaltning via servicekald) Ledelsesinformation Sagsadministration Ankestyrelsen Fil Magtanvendelser Magtanvendelse Andre kommuner Fil Sagsdata, sagsakter (handleplaner, udredninger osv.) Sagsadministration Leverandørsystemer Fil Sagsdata Sagsadministration Borgeroverblik Ledelsesinformation Center for Rusmidler Fil Sagsdata (udvalgte) Sagsadministration Danmarks Statistik Fil Sagsdata (udvalgte) Sagsadministration Ledelsesinformation Figur 5: Tabel over data der overføres via grænseflader 32
4. Model for implementering af it-arkitekturen Kortlægningen af it-anvendelsen i kommunerne i forprojektets leverance 1 har tydeliggjort, at der er store mangler i it-understøttelsen i kommunerne, og at kommunerne allerede i et vist omfang arbejder på at forbedre it-understøttelsen. Implementeringen af den ovenfor beskrevne it-arkitektur må antages at være en stor opgave for selv de største kommuner, idet arkitekturen er forholdsvis kompleks med mange moduler og grænseflader mellem modulerne og til andre systemer. Det forventes derfor, at implementeringen af it-arkitekturen vil foregå i en række trin for at imødegå risici forbundet med implementeringen af it-arkitekturen og for at håndtere koordineringen med allerede planlagte og igangsatte initiativer i kommunerne. Det vurderes, at det mest sandsynlige scenarie er en implementering i tre trin: 1. Etablering af den grundlæggende funktionalitet. 2. Etablering af avanceret funktionalitet. 3. Etablering af den resterende funktionalitet. Indholdet af de tre trin beskrives i de følgende afsnit. 4.1 Trin 1 etablering af den grundlæggende funktionalitet Det første trin handler om at etablere den mest grundlæggende funktionalitet i arkitekturen. Det forventes, at kommunerne i første omgang vil etablere itunderstøttelse af følgende områder: Sagsmodulet: Forventes implementeret i eksisterende systemer. Dynamiske dokumenter og udpræget genbrug af data forventes ikke at være en del af understøttelsen. Systemet vil ikke være så fleksibelt som ønsket med hensyn til muligheder for lokal tilpasning, workflow osv. Systemet vil anvende de 33
definerede fælles begreber, herunder indsatskatalog og målgrupper, og systemet vil i en vis udstrækning understøtte struktureret dataindsamling. Alt i alt forventes det, at cirka 50-75 procent af den efterspurgte funktionalitet vil være til stede. Sagsadministration: Forventes indbygget i eksisterende sagshåndtering. Vil omfatte de mest basale strukturerede data, men umiddelbart ingen workflowunderstøttelse. Udredning: Simpel version med strukturerede data, men ingen dynamisk udvidelse af udredningen forventes understøttet. Handleplan: Simpel version med strukturerede data, men ingen dynamisk udvidelse af handleplanen forventes understøttet. Afgørelse: Forventes implementeret som fx skabeloner og data registreres i et vist omfang i struktureret form, herunder sammenhæng mellem indsatser og økonomi (bevillinger). Planlægning: Etableres via eksisterende funktionalitet i systemerne. Indsatskatalog: Etableres som beskrevet. Ledelsesinformation: De eksisterende systemer har i et vist omfang mulighed for at udtrække ledelsesinformation. Informationen er dog begrænset til de data, der er registreret i det aktuelle system, og vil derfor ikke give et tværgående overblik. Brugerstyring: Der anvendes den brugerstyring, der er i systemet i forvejen. Der vil derfor efter overvejende sandsynlighed ikke være tale om single sign-on eller synkronisering af brugernavn og password. Dokumenthåndtering: Der anvendes den eksisterende funktionalitet, hvilket i nogle tilfælde vil betyde, at der ikke anvendes et tværgående EDH. Journalisering: Der anvendes den journalisering, som er indbygget i det aktuelle system. 34
Figur 6: Trin 1 - etablering af grundlæggende funktionalitet 4.2 Trin 2 etablering af avanceret funktionalitet Det andet trin handler om at etablere den mere avancerede funktionalitet i arkitekturen. Det forventes, at kommunerne som en del af trin 2 vil etablere itunderstøttelse af følgende områder: Sagsmodulet. Sagsadministration: Udbygges med blandt andet workflow for udvalgte områder og yderligere understøttelse af processen. Udredning: Udvidet understøttelse med blandt andet dynamisk opbygning af struktur og genanvendelse af data. Handleplan: Udvidet understøttelse med blandt andet dynamisk opbygning af struktur og genanvendelse af data. 35