Kommentarer til dokumentet MOX et forretningsmønster for fagsystemers udveksling af hændelser

KL Kommentarer til dokumentet MOX et forretningsmønster for fagsystemers udveksling af hændelser 15. august 2012 Ref. MWL-STE-TXK KL har inviteret til review af dokumentet, MOX et forretningsmønster for fagsystemers udveksling af hændelser. Overordnet finder KMD, at der i dokumentet fremlæges mange spændende tanker og forslag. Vi er glade for at få lejlighed til at kommentere dette foreløbige udkast. KMD s kommentarer er opdelt i to dele. Først en række mere generelle og overordnede betragtninger. Dernæst en række mere tekstnære kommentarer. Generelle kommentarer I de følgende afsnit beskrives KMD kommentarer, der går tværs af de konkrete cases og som har en mere principiel karakter. Behov for hændelsesbeskeder, men hvor skal man starte? KMD er helt enige i udgangspunktet: der er behov for at udveksle hændelsesbeskeder på tværs af forskellige processer og at hændelsesbeskederne er en forudsætning for at kunne automatisere dele af de administrative procedurer. Når et behov er erkendt, kan det diskuteres, hvordan det så bedst kan tilfredsstilles og hvordan man kommer i gang. I dokumentet lægges op til, at konceptet hurtigt afprøves. KMD er af den opfattelse, at det vil være hensigtsmæssigt, at lidt flere af de overordnede rammer og betingelser er beskrevet lidt bedre inden konceptet afprøves. Vurdering af, hvilke situationer MOX vil være en gevinst Det er efter KMD s mening i høj grad usikkert om en MOX infrastuktur vil give billigere løsninger i alle situationer. Den vil uden tvivl give mulighed for bedre integration mellem forskellige løsninger og dermed bidrage til en mu- KMD A/S Lautrupparken 40-42 DK-2750 Ballerup Telefon 44 60 10 00 www.kmd.dk info@kmd.dk Side 1 af 14 Hjemsted: Ballerup CVR nr. DK 26911745

lighed for øget automatisering. Men det vil en Workflow baseret model implementeret ved hjælp af webservices også tilbyde. Det bør derfor beskrives i, hvilke situationer MOX-arkitektur vil være den mest hensigtsmæssige (gerne dokumenteret i en Business Case), herunder hvilke fordele og ulemper MOX har i forhold til andre metoder til at løse samme problemstilling. En eller flere mulige sluthændelser? Ud fra den generelle beskrivelse af forretningsmønsteret (kapitel 2) kan man godt fristes til at tro at en given forretningsproces altid kun vil afsluttes med en enkelt besked. Som KMD læser dette betyder det at den samme besked eksempelvis bruges af en proces til at signalere de 2 hændelser en borgers ansøgning er afvist og en borgers ansøgning er godkendt (sluthændelsen kunne være at sagen er afgjort og/eller at dokumentet er endeligt). Efterfølgende er det ikke nødvendigvis de samme processer som skal reagere på de to situationer (om ansøgning er godkendt eller afvist). Det er uklart, hvordan dette kan håndteres i praksis. Skal beskedfordeleren åbne hver enkelt besked for at aflevere dem til de rigtige abonnementer eller også vil begge de abonnerende processer modtage beskeden, og den ene vil så efter at have undersøgt den, være nødt til at smide den væk? Og hvordan afgøres det ansøgningen er godkendt eller afvist? En standard for hændelsesbesked og kontekst For at sikre, at de forskellige løsninger, der etableres på længere sigt kan fungere sammen er det afgørende, at der formuleres en standard for hændelsesbeskeder. Der er et udgangspunkt i den udarbejde anbefaling Anbefaling for en generel hændelsesbesked, version 1.0, men der er behov for at den præciseres og der udarbejdes en egentlig standard. Kontekst nævnes flere steder, og i afsnit 3.2.2.1 nævnes, at Kontekst medsendes, vi opfatter derfor Kontekst som en datastruktur, der skal kunne udveksles, hvilket forudsætter en standardisering af Kontekst. Præcisering af hvordan beskedfordelere kan abonnere hos hinanden I dokumentet beskrives det, at beskedfordelere kan abonnere på hinandens beskeder. Behovet er ubestrideligt, men det bør præciseres, hvordan det kan ske i praksis. Ud fra tankegangen om frit leverandørvalg, må det også forventes at der vil være forskellige leverandører af beskedfordelere. Det er uklart, hvordan de forskellige processer skal vide, hvilken beskedfordeler de skal henvende sig til. Hvis en kommune vælger at udskifte en beskedfordeler fra en leverandør med en beskedfordeler fra en anden leverandør, påtænker man så at leverandørerne af alle de processer som kommunen måtte have erhvervet skal ind og rekonfigurere deres processer for at få dem til at snakke med den Side 2 af 14

nye beskedfordeler, eller er der planer om at definere en standard for hvorledes abonnenter til- og afmelder sig en abonnementsordning? Sikring af at hændelsesbeskeder ikke går i ring Nedenfor er illustreret en situation, hvor tre beskedfordelere abonnerer på hinandens beskeder. Hvordan kan det i praksis sikres, at beskederne undgår en uendelig løkke, (Beskedfordeler B omformer en besked fra beskedfordeler A til en besked, som sender den videre til beskedfordeler C, som omformer den til en besked, som sendes videre til Beskededfordeler A, som omformer den og sender den videre til beskedfordeler B, som ). I forlængelse af ovenstående bør overvejelser om sikkerhed indgå i det videre arbejde. Opsætning (og vedligeholdelse) af abonnement kan for eksempel foregå via en (web)service, men det kan næppe tillades, at alle andre processer/services uden videre kan få adgang til hændelsesbeskeder. Det kunne lægge op til, at den enkelte service skal være kendt i beskedfor- Beskedfordeler A Beskedfordeler C Beskedfordeler B En anden situation, der skal findes en praktisk løsning på, er situationen, hvor beskedfordelerne findes i forskellige sikkerhedsdomæner. I casen om udveksling af dokumentation mellem myndigheder (beskrevet i afsnit 3.2) beskrives, hvordan en agent i en Kommune skal reagere på en besked sendt fra Udbetaling Danmark. Processen i Udbetalingen er altså afhængig af, at en proces i en anden myndighed abonnerer på bestemte hændelsesbeskeder. I casen er der implicit en pligt for alle landets kommuner til at implementere en MOX-agent, herunder at abonnere på de rigtige hændelsesbeskeder. Det er uklart, hvordan dette sikres i praksis. I forlængelse af ovenstående, så nævnes det i afsnit 2.4, at et af perspektiverne i MOX, er at processen kan skiftes uden at skifte system og at systemet kan skiftes uden at skifte proces. I begge situationer kan der være behov for at ændre abonnementet på hændelsesbeskeder på tværs af myndighedsskel. Det er uklart, hvordan det kan ske i praksis. Håndtering af sikkerhed Side 3 af 14

delerens sikkerhedsdomæne og at der foregår en eller anden form for autorisation i forhold til beskedfordeleren. Hvordan påtænkes det, at beskedfordeleren skal sikre, at beskeder kun udleveres til autentificerede og autoriserede abonnenter. Specielt tænkes her på beskeder, der indeholder personfølsomme data. Dette skal ske på tværs af sikkerhedsdomæner og på lovlig vis. Identifikation af sagsbehandleren som person med angivelse af bruger-id kan være nødvendig så en system bruger-id vil muligvis ikke være nok til at sikre logningsregler. Forskellige scenarier for håndtering af sikkerhed bør beskrives. Skift af ansvar MOX lægger op til en meget løs kobling mellem løsninger og beskedfordeler. Der siges ikke meget om, hvordan udveksling af hændelsesbeskeder mellem distribuerede beskedfordelere skal foregå. Der siges heller ikke noget om på hvilken måde ejerskab og ansvar for hændelsesbeskeder tilvejebringes, når der sker skift mellem forvaltninger og organisationer. Det er altid en god idé at være præcis, når ansvar skifter uanset om det er mellem organisationer, sikkerhedsdomæner eller datatransformering. Undlades dette får man ofte ubehagelige oplevelser i forbindelse med drift af den samlede løsning. Hvordan sikres integritet, hvis flere abonnerer på samme hændelsesbesked og kommer til forskellige resultater (et eksempel: den ene modtager siger o.k. sag kan afsluttes mens en anden modtager siger, at der er behov for yderligere information). Håndtering af end-to-end processer I dokumentet lægges op til en situation, hvor den samlede end-to-end proces udelukkende drives af hændelsesbeskeder. Der står: Det er altså abonnementet, der udtrykker en sammenhæng mellem processerne. Men abonnementet tegnes ikke af processen men af den bruger, repræsenteret ved de(n) myndighed(er), der forvalter det modtagende fagsystem (side 10). I beskrivelsen opstår abonnementer og de ønsker og regler som nødvendigvis må eksistere på magisk vis. Hvilket system/hvilken service ejer processen end-to-end? Et eller andet sted må der være behov for at kunne definere (og senere vedligeholde) den samlede proces, herunder opsætning af de abonnementer, de enkelte agenter skal sætte op for at den samlede proces kan afvikles automatisk. End-to-end procsser på tværs af myndigheds skel som casen med udveksling af dokumentation mellem kommunerne og Udbetaling Danmark bliver endnu mere komplekse. Se kommentarer til afsnit 3.2.2 i det efterfølgende. Revisionsspor/audit/logninger Det må antages at hver enkelt proces er ansvarlig for sit eget revisionsspor, men hvorledes påtænkes det at danne et revisionsspor for hele arbejdsgangen? Side 4 af 14

Da hver enkelt proces nu er afkoblet, og kun den/de involverede beskedfordelere ved, hvilke processer, der er indblandet i den pågældende arbejdsgang er dokumentation af den samlede arbejdsgang svær at få øje på. Der bør efter KMDs mening indtænkes en metodik til at sikre, at der kan dannes et fuldstændigt revisionsspor og sikre et overblik over hvem har gjort hvad i en given situation. System management. System management på tværs af distribuerede besked/hændelsesfordelere er ikke en simpel opgave. Hvordan håndteres fejl enten i infrastrukturen eller ved en eventuel brugerfejl? Regler, protokol og informationsflow mellem hændelsesfordelere bliver vanskelig, når disse ikke kender hinanden eller de systemer, der ligger bag. Hvordan sikres, at en (end-to-end)arbejdsgang ikke knækker eller går i stå midt i en proces, fordi der mangler en aftager? Relation til andre digitaliseringsinitiativer Det vil være hensigtsmæssigt, at MOX konkret tænkes ind i forhold til andre fælles offentlige og fælles kommunale digitaliseringsinitiativer. For eksempel har KL igangsat et projekt om realisering af gevinster i forhold til de fælles offentlige initiativer om fjernprint. Både KL s initiativ om realisering af gevinster og det fælleoffentlige initiativ om fjenprint har et overlap i forhold til de beskrevne cases. Det er vanskeligt at forstå at andre digitaliseringsinitiativer ikke tænkes ind i de forskellige to-be-situationer. Relation til kommunernes rammearkitektur Samtidigt med dette review foregår der et review af kommunernes rammearkitektur. Nogle af de principper, der beskrives heri er i direkte modstrid med MOX. Beskrivelsen af beskedfordeleren i rammearkitekturen er på visse dele i direkte modstrid med MOX, men også andre steder er MOX i modstrid med rammearkitekturen. For eksempel nævnes i dokumentet integrationsmønstre, at overdragelsen af ansvar vil foregå gennem støttesystemklienten og altså ikke gennem beskedfordeleren (side 20 i dokumentet integrationsmønstre, - http://kl.dk/imagevault/images/id_55742/scope_0/imagevaulthandler.asp x) MOX og kommunernes rammearkitektur skal hænge sammen. Side 5 af 14

Håndtering af krav om beskyttelse af følsomme oplysninger(persondataloven og andre love) Udveksling af beskeder synes umiddelbart ikke at være farlig i forhold til at udveksle følsomme data det er jo bare en besked om, at en hændelse er sket. Alligevel må en hændelsesbesked om, at der er oprettet en sag om venteliste til handicapbolig knyttet til en bestemt person (part) være at betragte som personfølsomme data, da man ud af beskeden kan udlede, at den pågældende person er handicappet. I dokumentet står: En besked bør som udgangspunkt ikke have en direkte modtager. Med det menes, at den der udsteder slutbeskeden ikke skal vide, hvem der har brug for at reagere på den (side 10). Samtidigt lægges der op til, at alle processer frit kan abonnere på hændelsesbeskeder. Umiddelbart synes der i den situation at være en risiko for at følsomme data kommer uberettigede i hænde. Hvordan kan det for eksempel sikres, at der leves op til Persondatalovens krav om personfølsomme data indsamlet til et formål ikke må anvendes til et andet formål, der er uforeneligt med det formål de er indsamlet til? KMD opfordrer derfor arbejdsgruppen og KL i det videre arbejde at indgå i dialog med Datatilsynet og andre relevante myndigheder om, hvordan hændelsesbeskeder kan udveksles uden, at Persondataloven og andre bestemmelser om beskyttelse af følsomme data overtrædes. Driftsplatform og sikker drift Besked fordeleren bliver en kritisk komponent i den samlede løsning. Derfor er sikring af, at denne komponent altid fungerer optimalt og er kørende, en væsentlig forudsætning for MOX. Antallet af MOX-hændelsesbeskeder som skal gennem beskedfordeleren vil være betragtelig, så en implementering vil stille store krav til driftssikkerhed og netværks båndbrede. Test, overvågning, fejlsøgning samt håndtering af fejl og driftshændelser (system management) nævnes ikke, men omfanget af disse opgaver kan næppe overvurderes. Systemmanagementopgaven med test, overvågning, fejlsøgning samt håndtering af driftshændelser vil næppe kunne løses tilfredsstillende uden omfattende automatiske testfaciliteter, og uden et centralt overvågningscenter med dedikeret overvågningsudstyr og højt kvalificeret personale, helst med døgnbemanding. Tekstnære kommentarer til MOX et forretningsmønster for fagsystemers udveksling af hændelser I det følgende gives de tekstnære kommentarer KMD har til dokumentet. Kommentarerne er så vidt det er muligt grupperet efter det afsnit kommentaren vedrører. Overskrifterne afspejler derfor overskrifterne i dokumentet. Side 6 af 14

Titlen MOX udvekling af hændelser For at undgå begrebsforvirring og for at være i tråd med de fælles offentlige initiativer anbefales, at der i stedet for at tale om udveksling af hændelser, i stedet tales om udveksling af hændelsesbeskeder. Afsnit 2.2 side 9-10 Der står i noten, at der ikke er overensstemmelse mellem KOMBITS scope for beskedfordeler og scopet for MOX. Det forventes, at disse to bringes til overensstemmelse i det efterfølgende arbejde. Afsnit 2.4 side 11 Der nævnes en række muligheder med MOX. En del af disse muligheder kan kun opfyldes, når en række forudsætninger er opfyldt vel at mærke forudsætninger, der langt fra er opfyldt på nuværende tidspunkt. Refleksioner om, hvilke betingelser, der skal være på plads inden mulighederne kan blive en realitet, savnes. Der står Men leverandørerne vil miste indtjening på integration og vi håber, at det bliver brugt på forbedring af systemernes kernefunktionalitet. Hvordan skal mistet indtjening kunne bruges til udvikling? Afsnit 3.1 side 13 Det bør præciseres, hvordan tildeling af UUID er for dokumenter tænkes gennemført i to-be-situationen. Afsnit 3.1.2.1 side 17-18 Der nævnes, at den ledige stilling registreres ved at oprette en ny stilling eller afslutte et ansættelsesforhold. Begrebet stilling findes ikke i OIO standarden for Organisataion. Det nævnes, at det ikke er nødvendigt at have en master. Alle systemer, der har behov for at kende afgang og tilgang bliver synkrone ved hjælp af abonnementer. Dette kan måske anvendes i forhold til brugere, men ikke i forhold til ansættelser, da OIO-standarden for organisation forholder sig brugere og ikke ansættelser. Det beskrives, at den ledige stilling, automatisk kan komme til rekrutteringssystemet. Det kan undre, hvor disse metadata kommer fra. Derudover er det ikke klart, hvilken standard, der definerer de relevante data. Afsnit 3.1.2.2 side 18 Det nævnes, at stillingsopslaget kan udformes som et dokument, som når det får tilstanden endelig automatisk kan overføres til en stillingsportal. Hvordan kan registreringsportalen skelne stillingsopslaget fra andre dokumenter med tilstanden endelig? Der står i dokumentet, at stillingsopslaget umiddelbart kan offentliggøres, når dokumentet får tilstanden publiceret. Jævnfør OIO-standarden for do- Side 7 af 14

kument er det omvendt, tilstanden ændres til publiceret, når det er offentliggjort. Der nævnes en mulighed for at fjerne tilstanden publicering. Jævnfør de tilladte tilstandsskift i standarden er det ikke muligt (eneste tilladte tilstandsskift fra tilstanden publiceret er afleveret ). Afsnit 3.1.2.3 side 19-20 Det nævnes, at der ikke skal ske en journalisering før, en ansøger har fået tilbudt stillingen. Jævnfør serviceteksterne til KL Emnesystematik (til gruppen 81.02) er der mulighed for at oprette en sag til stillingsopslag og udvælgelse af ansøgere. Derfor er skal det vel være muligt at sagsdanne allerede på dette tidspunkt? Derudover opstår der vel implicit en sag. Der skal ske en sammenknytning mellem stillingsopslaget og det dertil relaterede ansøgninger, og derved er der skabt noget, der ligner en sag. I processen indsender dokument er slutbeskeden dokument sendt. Ser man det fra myndighedens side og det er vel det, der det mest relevante i denne sammenhæng bør tilstanden vel være dokument modtaget (det svarer også til en af tilstande i OIO standarden for dokument)? Sluthændelsen er den samme, når et dokument modtages og når det vedligeholdes. Hvordan kan andre processer adskille om der er tale om et nyt dokument eller et dokument, hvor metadata er ændret? Derudover er det ikke klart, hvordan sluthændelsen udtrykkes. Er det dokumentet, der får en ny tilstand eller er det en sag, der får en relation til et dokument? I begge tilfælde er det desuden uklart, hvordan processen kan være sikker på, at dokumentet er registreret på den rigtige sag (den sag, der skal trigge at rekrutteringsagenten kan sende dokumentet). En anden proces, kan tilknytte dokumentet til en anden sag i en anden sammenhæng, hvorved den samme sluthændelse opnås. Det nævnes (side 20), at den udvalgte ansøgers ansøgning automatisk sendes til Løn og Personalesystemet, når dokumentet (det fremgår ikke klart, hvilket dokument, der er tale om, men det antages, at der menes den udvalgte ansøgers ansøgning og tilbuddet om ansættelse) får tilstanden endeligt. Hvordan sættes abonnementet op således, at det på baggrund af metadata kan afgøres, hvilke dokumenter, der er de relevante (alle afslag og ansøgninger fra andre ansøgere end den udvalgte har vel også tilstanden endelig )? Er sluthændelsen dokument sendt udtryk for at dokumentet skifter til tilstanden sendt? I så fald savnes denne tilstand i OIO-standarden for dokument. Afsnit 3.1.2.5 side 21 Der savnes i beskrivelsen af to-be-situationen sammenhæng til tiltag om løsning til outputmanagement, herunder det fællesoffentlige initiativ om fjernprint. Side 8 af 14

Afsnit 3.1.2.6 side 21-22 Se bemærkninger til afsnit 3.1.2.3 om dokument modtaget og dokument registreret Afsnit 3.1.2.7 side 22-24 Der beskrives en sluthændelse dokument rekvireret. Denne tilstand findes ikke i standarden. Desuden forudsætter en automatisering af dette at der findes en endelig liste af dokumenter, ellers er det ikke muligt for Rigspolitiets MOX-agent at skelne de relevante rekvireringer af dokumenter, fra alle de rekvireringer, som Rigspolitiet ikke skal reagere på. Der lægges op til, at der automatisk kan dannes et journalnotat på den relevante sag, når straffeattesten modtages. I dette er følgende uklart: Tilstanden journalnotat dannet, hvad afspejler den og hvor er den specificeret. Hvor foregår den manuelle proces, med at vurdere straffeattesten. Det giver næppe mening, at der opsættes en automatisk proces, der rekvirerer en straffeattest og automatisk, når den modtages automatisk danner et journalnotat og trigger, at ansættelsesprocessen kan gå videre. Hvad nu, hvis straffeattesten indeholder forhold, der udelukker en ansættelse? Processen bliver endda en tand mere vanskelig at automatisere, hvis man tager højde for at der i nogle tilfælde også skal indhentes en børneattest. Afsnit 3.1.2.8 side 24-26 Her dukker en sluthændelse op, Dokument besked. Det er uklart, hvad denne sluthændelse dækker over. Der beskrives en proces, der undersøger om der allerede er en sag. Det er uklart, hvordan dette automatisk kan undersøge dette. At der findes en sag med det relevante emne fra KL Emnesystematik og den pågældende part er ikke ensbetydende at et nyt dokument skal tilknyttes denne sag. Det nævnes, at en række dokumenter er relateret til hinanden. Det er uklart hvilken type relation, der tænkes på, da ingen af relationerne fra OIO-standarden for dokument synes oplagte. Typisk sammenkædes dokumenter ved at de tilknyttes samme sag. Afsnit 3.2 side 27-33 KMD har meget svært ved at se den positive businesscase i den beskrevne case. Behovet for udveksling af dokumentation mellem kommunerne og Udbetaling Danmark opstår som følge af, at Udbetaling Danmark overtager nogle af de opgaver kommunerne indtil nu har udført. I den forbindelse overtager Udbetaling Danmark ansvaret for en stor mængde sager, hvori kommunerne allerede på overtagelsestidspunktet har foretaget sagsbehandling. Kommunerne sagsdanner imidlertid på mange forskellige måder og sagen kan derfor indeholde en lang række oplysninger som enten er irrelevante for Side 9 af 14

Udbetaling Danmark eller som Udbetaling Danmark ikke må få adgang til jævnfør for eksempel Persondataloven. Problemstillingen er som der også står i casen to-delt. Dels hvilke sager skal overføres i første omgang og dels de løbende ad hoc forespørgsler. Med henblik på at minimere omkostningerne ikke mindst for kommunerne har KL i samarbejde med kommunerne, ATP og KMD designet en samlet løsning. KMD har deltaget som leverandør af KMD Sag. Løsningen, som implementeres i forbindelse med Udbetaling Danmark, er baseret på KMD Sag, som alle danske kommuner har selvom der er forskel på hvorledes den enkelte kommune anvender KMD Sag, vil alle sager fra kommunens KMD baserede fagsystemer, uanset brugen af KMD Sag, være reflekterede i sags- og journalbestanden i KMD Sag. Udbetaling Danmarks jurister har vurderet lovgivningen omkring adgang til data på tværs af myndigheder, og den løsning, der etableres, bygger på juristernes anbefalinger. Derudover er der taget højde for arkivregler og arkivering af sager, der flyttes fra kommunerne til Udbetaling Danmark. Udbetaling Danmarks jurister har i projektet anlagt en forholdsvis restriktiv fortolkning af lovgivningen om beskyttelse af persondata. Det betyder, at nogle arbejdsgange, som teknologisk set kunne have været enklere i deres anvendelse, er blevet mere arbejdskraft intensive. De arbejdsgange, der er tale om vedrører primært fremsendelse af sager og dokumenter af ældre dato fra kommunerne til Udbetaling Danmark. Det var i forbindelse med forarbejdet, vurderingen blandt Udbetaling Danmark, de kommunale repræsentanter og KL, at sager og dokumenter af ældre dato kun i meget begrænset omfang ville være relevante for Udbetaling Danmark. I disse relativt få tilfælde vil kommunen manuelt skulle sende sager og dokumenter til Udbetaling Danmark. Løsningen omfatter migrering (kopiering) af alle sager fra KMD Sag, samt journalnotater beliggende i KMD Sag Journal. For de kommuner, som har KMD Sag EDH, hentes desuden dokumenter herfra. For kommuner, hvor dokumenter ligger i et andet ESDH system, vil disse dokumenter ikke som udgangspunkt være en del af migreringen. Repræsentanter fra kommunerne, Udbetaling Danmark og KL vurderede, at det ville være for tungt at flytte papirarkiverne. I stedet valgtes en løsning baseret på KMD Sag, da langt de fleste relevante data findes der. Det er så Udbetaling Danmarks vurdering, at man kun har villet give sig selv lov til at få adgang til ca. 1 års dokumentation fra KMD Sag Journal og EDH. Et år er valgt, ud fra en vurdering om, at det kun vil være relativt sjældent, man har brug for at rekvirere ældre oplysninger. Denne vurdering blev den gang lavet i samarbejde med de kommunale repræsentanter og KL. Derfor er der kun givet Udbetaling Danmark adgang til dokumenter og journalnotater oprettet efter 2.6.2012. Løsningen 1 er med andre ord designet således, at Udbetaling Danmark får de oplysninger de må få og som dækker behovet for dokumentation i så 1 Yderligere oplysninger om løsningen kan fås på http://nykundenet.kmd.dk/systembrugere/social/kmd%20sag/servicebreve/ny%20version%2013%2 0-%202012/VR13%20Releasebeskrivelse%20-%20version%2013%202.pdf eller ved henvendelse til KMD Sag Side 10 af 14

mange tilfælde som muligt. Der vil derfor i de sager, som ikke er overført, i mange tilfælde være oplysninger som Udbetaling Danmark ikke må få udleveret. Som følge deraf vil processen med at finde lige præcis den dokumentation, som Udbetaling Danmark efterfølgende efterspørger (og som i nogle tilfælde kun findes på papir), kun i få tilfælde kunne automatiseres fuldstændigt den vil forblive med at være en manuel proces, forarbejdet sikrer dog at den kun skal udføres et minimalt antal gange. Afsnit 3.2.1, side 27-28 Afsnittet beskriver as-is situationen for udveksling af sager mellem kommunerne og Udbetaling Danmark, efter at Udbetaling Danmark er etableret. Udveksling via standardiserede grænseflader er mulig Det fremføres, at leverandøren (dvs. KMD) har meldt ud, at der ikke bliver etableret en standard grænseflade til udveksling af sager fra kommunerne til Udbetaling Danmark. KMD står helt uforstående overfor dette udsagn, idet KMD længe har tilbudt en OIO-grænseflade til Sag, og netop har frigivet en OIO-grænseflade til Dokument. Alle tekniske forhold er således til stede for standardiseret udveksling af sager og dokumenter. Problemet er muligvis, at såvel KMD, som EDSH-leverandørerne, optræder i rollen som serviceudbyder, mens der ikke er nogen, der optræder i rollen som serviceaftager. Dette er naturligt, da såvel KMD Sag, som ESDHleverandørerne, lagrer sager og dokumenter og derfor finder det naturligt at optræde i udbyderrollen, hvilket i øvrigt også er helt i overensstemmelse med gældende standarder. Integrationskomponent som serviceaftager Hvad der muligvis mangler, er en integrationskomponent, der optræder i rollen som serviceaftager ved at kalde henholdsvis KMD Sag og kommunens 3.parts ESDH-løsning, som vist på den følgende figur. Integrationskomponenten er i dette koncept den komponent, der er ansvarlig for at styre processen i forbindelse med dataudveksling på tværs af systemerne, og som derfor er den aktive part, der kalder de passive OIOservices hos serviceudbyderne. Side 11 af 14

I KMD er vi ikke bekendt med, at kommunerne har efterspurgt integration til kommunens ESDH. Endvidere kan det diskuteres om det er leverandøren af kommunens ESDH eller KMD Sag, der skal udvikle integrationskomponenten. MOX dokumentet nævner begrebet serviceanvender ganske kort på side 10, men forholder sig ellers ikke til begreberne serviceanvender og serviceudbyder. Man kan imidlertid opfatte MOX-agenterne som bærerne af procesansvaret, hvorved de kan ses som et mere generelt og avanceret alternativ til ovenstående integrationskomponent. Overvej lovligheden Se tidligere bemærkninger om behovet for at forhindre brugerne i - uautoriseret - at kunne få adgang til uvedkommende materiale (overholdelse af Persondataloven). Derfor kan det være problematisk at lade systemerne rekvirere oplysninger helt automatisk, uden autorisationskontrol og uden involvering af medarbejdere. Afsnit 3.2.2, side 29-33, Forslaget til to-be-situationen er teknisk set interessant, men i praksis ganske udfordrende udfordringer der ikke kun gælder i den konkrete case, men generelt, når der er tale om at gå på tværs af myndighedsskel. Teknisk svær at gennemføre Det er en forudsætning, for at løsningen kan benyttes af Udbetaling Danmark, at samtlige kommuner tilslutter sig løsningen. Alle kommunerne skal altså sikre sig, at de i samarbejde med deres respektive ESDH-leverandører, får udviklet MOX-agenter til deres respektive løsninger. Derudover skal samtlige kommuner etablere driftsovervågning, således at de kan garantere Udbetaling Danmark, at de er i stand til at reagere på Udbetaling Danmarks hændelsesbesked. Udover udvikling og driftsovervågning skal løsningen testes. Test af en enkelt kommune kan løseligt anslås til 50 timer for kommunen, og 50 timer centralt, og med 98 kommuner vil - alene testopgaven - have en størrelsesorden omkring 10.000 timer. Der er altså tale om en omfattende, distribueret løsning, der er kritisk for myndighederne, og som vil medføre betydelige omkostninger. Holder businesscasen? KMD vil derfor anbefale, at implementering af MOX starter med et mindre omfattende, mindre kritisk projekt, samt et hvor gevinsten vil være større også på det kortere sigt. Mængden af information, der forventes at passere beskedfordeleren i et fremtidigt Udbetaling Danmark scenarie, anses for at være begrænsede og gevinsten anses derfor at være lille i forhold til indsatsen. Endelig er det tvivlsomt om oversendelse af oplysninger kan foregå automatisk. De dokumenter, som findes kan indeholde oplysninger, som ikke er relevant for den rekvirerende myndighed, og som derfor skal udelades in- Side 12 af 14

den oversendelen. Der er behov for en manuel proces, hvor det vurderes, hvilke oplysninger, der skal videregives. På baggrund af behovet for den indblanding af et menneske synes hele denne proces unødigt kompliceret. I stedet kunne en rekvirerende myndighed via Digital Post bede myndigheden om supplerende oplysninger. Denne rekvisition kan, hvis den påføres det relevante emne fra KL Emnesystematik, automatisk fordeles til relevant sagsbehandler. Når sagsbehandleren har fundet de relevante oplysninger kan disse medsendes svaret i Digital Post. Da rekvisitionen indeholder Sags-ID, kan besvarelsen inklusiv de rekvirerede oplysninger automatisk journaliseres på den relevante sag. Afsnit 3.2.2.3 Side 31-32 Der refereres til et format, der kan anvendes ved udtræk af data fra ESDH. For god ordens skyld bør der henvises til (indsættes et link), hvor esdh_udvekslingsag v5 inklusiv dokumentation kan findes. Afsnit 3.2.2.5 Side 33 Der gøres opmærksom på, at KMD Sag har sørget for at passivere/afslutte alle de sager i kommunen, som er overført til Udbetaling Danmark. Derfor kan man ikke skrive journalnotater på den nedlagte sag. Afsnit 3.3.2.3 side 39 Her optræder en startbesked, kontekst kendt. Det er meget uklart, hvad der menes med dette og hvor den kommer fra. Afsnit 3.3.2.4 side 39 Dette afsnit bryder med tankegangen i Referancearkitektur for Sag og dokument. Her er det muligt, at en sag består af dokumenter fra forskellige dokumentservices. Afsnit 3.5.2.1 side 47 Her anvendes afslutter sag i en helt anden betydning end i standarden OIO sag, hvor afsluttet betyder, at sagsbehandlingen er fuldført. Der nævnes en mulighed for at sagerne kan lukkes via en proces. Det er uklart, hvad der menes med at lukke sagerne. Afsnit 3.5.2.2 side 48 Det er uklart, hvad der menes med Arkivet Side 13 af 14

Tekstnære kommentarer til MOX bilag Afsnit Metode, side 3: Forretningstjenesten Organisation skulle vel være Forretningsservicen Organisation Afsnit Organisation, side 9: Vedligeholder aktør beskrivelsen: I forbindelse med operationerne Slet og Passiver er anvendelsen af Aktør registreret meningsforstyrrende, det forslås i stedet at anvende Aktør opdateret. Afsnit Sag, side 12: MOX processerne for Replikerer sag, Vedligeholder sag og Opsæt søgekriterier for sag er ikke beskrevet. Der er vist to processer for Vedligeholder sag, men kun den ene er beskrevet (den manuelle proces). Vedligeholder sag med startbeskeden Sag fundet er ikke beskrevet. Afsnit Beskedfordeler, side 14: MOX processerne for Replikerer besked, Læser besked, Søger besked og Lister besked er ikke vist i service tegningerne. Til gengæld figurerer Erindrer besked og Annullerer erindring 2 gange. For Annullerer erindring er det vel muligt at erindring ikke annulleres, og bør derfor figurere som en mulig fejl. Afsnit MOX byggeblokke, side 17: I procesbeskrivelse mangler operationen Opret. Venlig hilsen Elo Munk Product Owner KMD Sag Telefon 4460 6628 e-post emu@kmd.dk Side 14 af 14