Introduktion til Støttesystemet 1. Om dokumentet Dette dokument formidler et overblik over brugen af den fælleskommunale. Formålet er at give læseren en forståelse af, de væsentligste begreber, forudsætninger for brugen, samt de tiltænkte brugsscenarier. Målgruppen er primært teknisk-orienterede personer, der har behov for at danne sig et overblik på arkitekturniveau. Dette dokument udgør sammen med de dokumenterede vilkår for brug af se http://www.kombit.dk/integrationsvilkaar en beskrivelse af hvorledes støttesystemet anvendes, og hvordan der organiseres omkring anvendelsen. 2. Formål med en er en mekanisme, der giver fagsystemer mulighed for at informere hinanden om forretningsmæssige hændelser. Rent praktisk bevirker en, at fagsystemer kan abonnere på beskeder af en given type, fx beskeder om udbetalinger. Når et givent fagsystem rent faktisk udfører en udbetaling, sender fagsystemer en besked til beskedfordeleren om, at fx en udbetaling er foregået. en videredistribuerer så denne besked til alle de systemer, som abonnerer på beskedtypen udbetalinger. At kunne udveksle beskeder om hændelser er en afgørende forudsætning for effektiv digitalisering i kommunerne. Hændelser, der optræder i en forretningsproces vil forvaltningsmæssigt kunne igangsætte en anden forretningsproces. Eksempelvis vil en registrering af ægteskab kunne afstedkomme en genberegning af kontante ydelser. IT-systemet hvor hændelsen registreres, kan derfor udsende en besked, som andre interesserede it-systemer ønsker at modtage og behandle. har, efter modtagelse af en besked fra et afsendende it-system, ansvaret for at alle interesserede it-systemer får leveret beskeden. Efter leverance af beskeden, har det modtagende it-system ansvaret for håndtering af beskeden eksempelvis en advisering af en sagsbehandler. sikrer således at beskeder når frem til alle modtagere, uden at beskeder tabes eller mistes, og uden at it-systemer skal have punkt-til-punkt integrationer mellem hinanden. giver det enkelte fagsystem mulighed for at kunne aflevere beskeder, som herefter distribuerer med udgangspunkt i abonnementer, som modtagerne har tegnet. Det er centralt, at der tegnes abonnementer på beskeder frem for på beskedens afsender. Dette gør, at afsender og modtager af en besked afkobles, og de dermed ikke skal være bekendte med hinandens identiteter. Det er det autoritative system for forretningsobjekterne dvs. det IT-system hvor data opbevares og opdateres der har ansvaret for at udsende beskeder via KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/14
. Der skal sendes beskeder når data dvs. forretningsobjektet udsættes for hændelser, således at nye data registreres (fx ny adresse). Derefter er det centralt, at overtager ansvaret for leverancen af beskederne, og ikke mister beskeder før de når modtagerne. Afsenderen kan forlade sig på, at alle afleverede beskeder leveres til alle relevante modtagere. Dette grundlæggende integrationsmønster afkoblingen af afsender fra modtagere sammen med den asynkrone leverance skal realiseres af. På nedenstående figur vises i den tiltænkte rolle som formidler af beskeder fra afsendende og til modtagende IT-systemer. Fagsystem (fx KMD Sag) Fagsystem (fx KY) Fagsystem (fx KY, JC løsning) Fagsystem (fx JC løsning) Fællesoff. System (fx CPR) Fagsystem (fx KMD Sag) Afsendersystemer Modtagersystemer Figur 1 i rollen som formidler af beskeder mellem af Afsendersystemer og Modtagersystemer Som vist på Figur 1 muliggør at fagsystemer mv. kan aflevere henholdsvis modtage beskeder om hændelser ét sted. er skal indeholde tilstrækkelige informationer til at Modtagersystemer kan indikere interesse for modtagelse via definition og opsætning af abonnementer. vil være bekendt med en bestemt del af beskeders indhold beskedkuverten hvorimod det øvrige indhold er ubekendt for. kuverten er under standardisering i KOMBIT, i samarbejde med Digitaliseringsstyrelsen og KL. befinder sig i en kontekst af fællesoffentlige og fælleskommunale IT-systemer, såvel som fagsystemer og andre systemer for den enkelte kommune. Det forventes at potentielt kan interagere med en lang række af fællesoffentlige systemer, som vist på nedenstående figur. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 2/14
Figur 2 Kontekstdiagram for, der viser hvilke systemer, tiltænkes at interagere med. Som Figur 2 illustrerer, interagerer med både kommunale, regionale og statslige IT-systemer. Interoperabilitet er derfor centralt for, både mellem systemer i kommunerne, men også andre fællesoffentlige systemer. kan ligeledes modtage beskeder fra eller levere beskeder til de andre støttesystemer i den Fælleskommunale Rammearkitektur. Alle disse systemer udgør Anvendersystemer for. har ikke ansvaret for det forretningsmæssige indhold af, hvad der udveksles. Dette defineres i den beskedtype, som der kan abonneres på. Det vil være ønskeligt at dette sker via fælleskommunal eller fællesoffentlig standardisering. Leverandører af afsendende og modtagende IT-systemer kan via selvbetjening foretage den nødvendige opsætning af eksempelvis af abonnementer, der sikrer modtagelse af beskeder. Det administrative personale til kan foretage opsætning af denne, eksempelvis af de typer af beskeder, der kan abonneres på. skal være en robust infrastrukturkomponent, der sikkert og pålideligt distribuerer beskeder, også ved et stort antal beskeder der afleveres til distribuering. 3. Vigtigste forretningsbegreber Den fælleskommunale understøtter hændelsesorienteret arkitektur. Hændelsesorientering opererer med det grundlæggende begreb hændelse, med afledte begreber besked, meddelelse og advisering. Begreberne abonnement og dueslag er relevante at forstå, givet at de styrer hvilke beskeder en modtager får leveret: KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 3/14
Hændelse at noget sker forretningsmæssigt, eksempelvis at en borger flytter, eller en borger udebliver fra et møde, og at dette registreres i et itsystem. informationen om en hændelse, der er afsendt fra et system, og via distribueres til andre (interesserede) systemer fx en flyttebesked der identificerer borgeren samt dennes nye og tidligere bopæl. Meddelelse informationen om en hændelse der ønskes kommunikeret fra et type system til et andet system af en bestemt type fx en udbetal kontanthjælp meddelelse fra et ydelsessystem til et udbetalingssystem. Meddelelser er en særlig type besked. Advisering at en person informeres om at en hændelse er indtruffet, så personen fx kan vælge at foretage en forvaltningshandling så som at standse udbetaling af tildelt støtte. Abonnement repræsenterer et it-systems indikation af, hvilke beskeder det ønsker at modtage. Dueslag et opbevaringssted for beskeder, som det tilknyttede abonnement indikerer at it-systemet ønsker at modtage, men som it-systemet ikke har fået leveret endnu. En hændelse kan derfor give anledning til at en besked distribueres nemlig hvis det system, hændelsen opstår i forbindelse med, vælger at udsende en besked. En besked, der modtages af et it-system, kan give anledning til at en person (fx kommunal sagsbehandler) adviseres om den hændelse, der ligger bag den modtagne besked. 4. Vigtigste tekniske begreber distribuerer beskeder, der modtages fra Afsendersystemer, til Modtagersystemer, ved at placere beskederne i Modtagersystemernes dueslag. For at Modtagersystemet kan indikere overfor, hvilke beskeder der opfattes som interessante, oprettes der for Modtagersystemet et abonnement. Abonnementet indeholder en række udtryk, der samlet set angiver, hvilke beskeder der ønskes modtaget. Det skal i denne forbindelse bemærkes, at en myndighed på forhånd skal have givet tilladelse til hvilke beskeder, der må abonneres på for et givet Modtagersystem. Følgende er definitionen af de vigtigste tekniske begreber for : Abonnementsudtryk et udvælgelseskriterium for beskeder, et Modtagersystem ønsker at abonnere på. kuvert en standardiseret definition af en række informationer om en besked, der gælder for alle beskeder, der distribueres af. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 4/14
data udgør det forretningsmæssige indhold af den besked, der sendes fra et Afsendersystem. metadata relevante informationer om beskeddata, der typisk ikke hidrører direkte fra den hændelse, der forårsagede afsendelse af beskeden. type en angivelse af den forretningsmæssige art (type) af en besked, der typisk angives som et navn i et katalog. Følgende figur illustrerer en delmængde af s begrebsmodel, hvor relationen mellem de vigtigste begreber omkring abonnementer, dueslag og beskeder er vist. Abonnement Definerer indhold i Dueslag Abonnementsudtryk Udpeger type Matcher data i Har en kuvert -metadata data Figur 3 Udsnit af begrebsmodel for En kort forklaring af diagrammet i Figur 3 følger. Et abonnement er altid knyttet til netop et dueslag, hvor beskederne placeres til senere levering. Det er abonnementet, der definerer indholdet af dueslaget. Modtagersystemet kan have flere dueslag, og der oprettes et abonnement for hvert dueslag. Hvert abonnement består af ét eller flere abonnementsudtryk. Et abonnementsudtryk udpeger en beskedtype, og definerer hvilke kriterier, der skal være opfyldt af beskedens beskedkuvert, for at beskeden ønskes modtaget i det pågældende dueslag. er har en givet beskedtype, og indeholder beskedkuvert, beskeddata og beskedmetadata. er er placeret i et eller flere dueslag. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 5/14
5. Arbejdsgange relateret til I det følgende beskrives de centrale arbejdsgange relateret til. Forud for at beskeder kan udveksles, skal Anvendersystemerne have rettigheder hertil. Dette forklares i afsnit 5.1 og 5.2. Herefter kan Anvendersystemerne aflevere beskeder til henholdsvis modtage beskeder fra. Endelig kan Anvendersystemernes opsætning i vedligeholdes. Dette forklares i afsnit 5.3 til og med afsnit 5.6. 5.1 Tilslutning af Anvendersystem Forud for at et Anvendersystem i rollen som afsender eller modtager af beskeder kan få adgang til, skal det tilsluttes til rammearkitekturens Støttesystemer. Dette foretages via støttesystemet Administrationsmodul, af den ansvarlige for et Anvendersystem (typisk en systemleverandør eller kommunen selv herefter kaldet tilslutningsparten ). Der henvises til arbejdsgangene omkring Administrationsmodulet for detaljer om, hvorledes dette foretages. Efter at Anvendersystemet er tilsluttet, kan tilslutningsparten anmode en eller flere myndigheder om rettigheder til afsendelse af og/eller modtagelse af beskeder via Administrationsmodulet. Der henvises til arbejdsgangene omkring Administrationsmodulet for detaljer om måden, hvorpå anmodningen foregår. 5.2 Oprettelse af serviceaftaler om aflevering eller modtagelse af beskeder Rettigheden til at afsende eller modtage beskeder fastlægges via serviceaftaler, der via Administrationsmodulet indgås mellem myndigheden og tilslutningsparten. opererer med to rettigheder: 1. Afsend der tillader Anvendersystemet at afsende beskeder 2. Modtag der tillader Anvendersystemet at abonnere på og modtage beskeder Rettighederne afgrænses altid til en mængde af konkrete beskedtyper. Det er desuden muligt at afgrænse i forhold til det kommunale forvaltningsområde, afsendende myndighed, ansvarlig/modtagende myndighed, og følsomheden for beskedens indhold. Der henvises til arbejdsgangene omkring Administrationsmodulet for detaljer om, hvorledes dette foretages. Når en serviceaftale er indgået, vil Administrationsmodulet via en integration opdatere, således at tilføjelser, ændringer og sletninger af rettighederne til afsendelse henholdsvis abonnement og modtagelse tilgår. 5.3 Oprettelse og vedligehold af abonnementer Når en serviceaftale er indgået, der indeholder rettigheden Modtag (se ovenfor), kan der oprettes et dueslag og et abonnement for det Anvendersystem, der er identificeret i serviceaftalen. Det vil være tilslutningsparten, der opretter KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 6/14
abonnementet på vegne af Anvendersystemet. Arbejdsgangen for at oprette og vedligeholde abonnementer er skitseret på følgende Figur 4: Tilslutningspart Behov for at modtage beskeder Igangsæt ændring af abonnement Ændring foretaget Verificer abonnements-udtryk Opret abonnement eller tilpas eksisterende abonnement Nej Er udtryk tilladt ihht serviceaftale? Ja Inaktiver udtryk Effektuer udtryk Udtryk gjort passiv Udtryk tilføjet eller ændret Abonnement opdateret Figur 4 Arbejdsgangen for registrering af abonnement på beskeder i. Det skal bemærkes, at er ansvarlig for at sikre at abonnementet ikke går ud over det tilladte jf. serviceaftalen, før det oprettede eller ændrede abonnementsudtryk aktiveres. Hvis en serviceaftale efterfølgende ændres, vil blive informeret af Administrationsmodulet, hvorefter de foreliggende abonnementer kontrolleres og evt. passiveres hvis de går ud over de opdaterede rettigheder jf. den opdaterede serviceaftale. 5.4 Aflevering af beskeder til Når et Afsendersystem afleverer en besked, modtages denne først af, hvorefter den valideres og det kontrolleres at afsenderen må sende den, jf. nedenstående arbejdsgang i Figur 5: KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 7/14
Tilslutningspart Afsendersystem udløsende hændelse opstået Aflever besked afleveret afvist Nej Send afvisning Modtag besked tilladt jf. serviceaftale? afvist Ja Distrbuér besked distribueret Figur 5 Arbejdsgang for modtagelse af beskeder. Afsendersystemet skal selv håndtere, hvis beskeden ikke kan afleveres, fx grundet manglende rettigheder. 5.5 Modtagelse af beskeder fra Forudsat at Afsendersystemet kan aflevere beskeden, distribuerer beskeden til alle de dueslag, hvis abonnement matcher beskedens beskedkuvert. Herefter kan beskeden leveres til Modtagersystemet, enten ved aktivt at forsøge at aflevere beskeden til Modtagersystemet, eller ved at Modtagersystemet selv forespørger på nye beskeder. Dette er skitseret på følgende Figur 6: Tilslutningspart Modtagersystem Forespørg på besked(er) modtaget aflevering distribueret til dueslag Aflevering eller afhentning jf. serviceaftale? Aflever besked afhentning Slet besked Modtag forespørgsel Lever besked Slet besked leveret afhentet Figur 6 Arbejdsgang for levering af beskeder. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 8/14
Når beskeden er leveret til Modtagersystemet, markerer beskeden til efterfølgende sletning, der sker med forsinkelse (målt i et antal timer). Indtil da vil det være muligt at få beskeden genleveret. 5.6 Andre arbejdsgange Ud over de ovenstående arbejdsgange, understøtter en række andre arbejdsgange: Vedligehold af et Modtagersystems dueslag, herunder aktivering og inaktivering, og administrativ fjernelse af beskeder. Angivelse af om et Afsendersystem ønsker modtagelse af beskeder, dette selv har afsendt, hvis det har et dueslag med et matchende abonnement. Aktivering og inaktivering af Afsendersystemer. Administration af, herunder oprettelse og vedligehold af beskedtyper. forventes derfor at understøtte en række use cases, der er rettet imod den ansvarlige for et Anvendersystem samt administratoren af. Disse er vist på et use-case diagram på Figur 7: <<include>> Administrer abonnementer Use case UC-2B-07 <<include>> Administrer indenfor aftaler <<include>> Administrer dueslag <<include>> Administrer beskedfordeler Tilslutningspart Use case UC-2B-06 Use case UC-2B-08 <<include>> Use case UC-2B-05 administrator Administrer beskedkatalog Se beskedkatalog Use case UC-2B-09 Use case UC-2B-10 Figur 7 Use cases for administration af Anvendersystemer i. Use cases for administration af Anvendersystemer anvendes af to aktører, som vist på Figur 7. De to aktører deler 2 use cases vedrørende administration af abonnementer og af dueslag. En tilslutningspart, der repræsenterer Anvendersystemet, kan kun administrere egne systemer inden for de aftaler, der er indgået. administratoren kan administrere hele. Det er beskedfordeler administratoren der kan tilføje nye beskedtyper og vedligeholde eksisterende beskedtyper, der udstilles til tilslutningsparten via beskedkataloget. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 9/14
6. Generelle beskedagenter og føderering I forbindelse med distribuering af beskeder understøtter mulighed for at beskeder behandles. Denne behandling kan ske i en såkaldt Generel agent. Den forklares kort i afsnit 6.1. For at beskeder kan udveksles mellem mange interessenter, understøtter føderering. Ved føderering forstås at forskellige interessenters beskedfordelere kan kobles sammen og udveksle de beskeder, der gensidigt er aftale om. Dette forklares kort i afsnit 6.2. 6.1 Generelle beskedagenter understøtter at beskeder kan behandles, før de tilbydes modtagerne via deres abonnementer. Denne behandling skal ske uden for, da denne kun forholder sig til distribueringen af beskeder. er der ankommer til kan behandles forud for distribuering af en såkaldt Generel agent, der abonnerer på de beskeder, den ønsker at behandle. Termen Generel agent anvendes da den ikke er specifik til et bestemt Anvendersystem, men generel typisk for en eller flere relaterede beskedtyper. For at sikre at den original besked ikke modificeres, beriger og/eller transformerer Generelle agenter en kopi af en afleveret besked. Efter behandlingen distribueres kopien baseret på Modtagersystemernes abonnementer. Formålet er med en Generel agent er at tilpasse indholdet af beskeden til modtagerne, eksempelvist ved at gøre det lettere at definere Modtagersystemernes abonnementer, eller at generere en fraflytningsbesked og en tilflytningsbesked ud fra en flyttebesked fra CPR. Generelle beskedagenter forventes at blive driftsafviklet nær for at sikre høj ydeevne og hurtig behandling. 6.2 Føderering understøtter sammenkobling med andre beskedfordelere. Formålet hermed er at beskeder kan udveksles mellem disse på vegne af Anvendersystemer. skal understøtte føderering med andre ellers identiske instanser af, samt desuden med andre beskedfordelere der udstiller de krævede snitflader og implementerer de krævede integrationer. Fødereringen indebærer at beskedfordelerne stoler på hinanden til en vis grad. Et tænkt anvendelseseksempel kunne være en kommunal beskedfordeler, der ønsker at videresende (og modtage) beskeder til (fra) den fælleskommunale, på de lokale kommunale it-systemers vegne. Fødererede beskedfordelere forventes at blive driftsafviklet decentralt. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 10/14
7. Anvendelsesscenarier Den fælleskommunale skal bringes i spil i det kommunale landskab. Dette kan ikke ske øjeblikkeligt i stedet skal gradvist bringes ind. Der tages udgangspunkt i en forventning om, at de eksisterende integrationer gradvist føres over til brug af, når informationer om hændelser skal kommunikeres. Dette afføder behov for identifikation af, hvornår det forventes at hændelser genereres, samt transitionen fra den eksisterende integration til den fuldt hændelsesorienterede, med brug af. Dette beskrives kort i det følgende. 7.1 Transition til brug af fra de kommunale it-systemer I dette afsnit beskrives kort en skitse af den nuværende situation AS-IS scenariet, efterfulgt af transitions scenariet, og endelig TO-BE scenariet som er målet for hændelsesorienteringen. Beskrivelsen tager udgangspunkt i et tænkt eksempel omkring Jobcenter integration til sygedagpengeområdet eksemplet er ikke udtryk for den endelige løsning. 7.1.1 AS-IS scenariet I det tænkte eksempel er eller en pendant hertil kun delvist udrullet i få kommuner. AS-IS scenariet kendetegnes derfor ved en integration mellem fagsystemer og eventuelle sagsbærende systemer. På figuren nedenfor illustreres dette med et tænkt eksempel om integration mellem et ESDH system og Jobcenter løsninger. Eksempel: Direkte kald fra ESDH system l JC løsning om at sag opre es ESDH system Eksempel (alterna v): Kald fra ESDH system via Servicepla ormen der iden ficerer og kalder den korrekte JC løsning. ESDH system Servicepla orm Medialogic Workbase KMD Opera Schultz FASIT Medialogic Workbase KMD Opera Schultz FASIT Jobcenterløsninger Jobcenterløsninger Figur 8 Eksempel på AS-IS scenariet med punkt-til-punkt integrationer mellem systemerne, eller alternativt indirekte via Serviceplatformen. På Figur 8 vises direkte integrationer mellem ESDH system og Jobcenterløsninger, eller som alternativ, integrationer via Den Fælleskommunale Serviceplatform. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 11/14
I AS-IS scenariet informerer det kaldende ESDH system derfor synkront kommunens konkrete Jobcenterløsning eventuelt løst koblet via Serviceplatformen. 7.1.2 Transitions scenariet Transitions scenariet anvender både Serviceplatformen og. På nedenstående Figur 9 vises i et tænkt eksempel hvordan eksempelvis KSD kunne kommunikere med Jobcenterløsningerne via Serviceplatformen, men samtidigt udsende beskeder, og vice-versa når Jobcenterløsningerne skal kommunikere med KSD. Kald + om sygedagpengesag opre et eller ændret fra KSD KSD Kald (+ ) om manglende deltagelse i opfølgning ophør af udbetaling af sygedagpenge KSD Servicepla orm Servicepla orm Medialogic Workbase KMD Opera Schultz FASIT Medialogic Workbase KMD Opera Schultz FASIT Jobcenterløsninger Jobcenterløsninger Figur 9 Et tænkt eksempel på transitions scenariet, med fagsystem (KSD) og jobcenterløsninger, hvor der kaldes via Serviceplatformen og desuden publiceres beskeder. I transitions scenariet vist på Figur 9 vil KSD ved oprettelse af eller ændringer til sygedagpengesager både sende beskeder ud samt kalde via Serviceplatformen. Denne viderestiller til en konkret Jobcenterløsning (her FASIT). Jobcenterløsningerne abonnerer ikke initialt på beskeder. Ved hændelser i Jobcenterløsningen fx manglende deltagelse kalder Jobcenterløsningen (FASIT) fagsystemet (KSD) via Serviceplatformen. Jobcenterløsningerne skal i transitionsscenariet udvides til at de også sender beskeder. Fagsystemet etableres initialt så det kan modtage opdateringer både via Serviceplatformen og via beskeder. 7.1.3 TO-BE scenariet I TO-BE scenariet anvendes primært, selvom fagsystemerne fortsat kan opdateres via Serviceplatformen. På nedenstående Figur 10 vises i et tænkt eksempel hvordan eksempelvis KSD kommunikerer med Jobcenterløsningerne via, og vice-versa når Jobcenterløsningerne skal kommunikere med KSD. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 12/14
om sygedagpengesag opre et eller ændret fra KSD KSD om manglende deltagelse i opfølgning ophør af udbetaling af sygedagpenge KSD (Andet Fagsystem) Servicepla orm Medialogic Workbase KMD Opera Schultz FASIT Medialogic Workbase KMD Opera Schultz FASIT Jobcenterløsninger Jobcenterløsninger Figur 10 Eksempel med fagsystem (KSD) og jobcenterløsninger, der alene kommunikerer via beskeder om relevante hændelser. Som vist i TO-BE scenariet på Figur 10, sender KSD beskeder ud ved oprettelse af eller ændringer til sygedagpengesager. Serviceplatformen kaldes ikke. Jobcenterløsningerne abonnerer på beskeder fra fagsystemet et af dem modtager i eksemplet beskeden (FASIT) og behandler denne. Ved hændelser i Jobcenterløsningerne fx manglende deltagelse sender Jobcenterløsningerne en besked. Fagsystemet (KSD) abonnerer på beskeden og modtager opdateringerne. Andre fagsystemer kan desuden abonnere på beskeden. Fagsystemet (KSD) kan fortsat opdateres via Serviceplatformen. 7.2 Generering af hændelser i kontekst I det følgende skitseres genereringen af hændelser i kontekst af fagsystemerne. Der tages udgangspunkt i et tænkt eksempel omkring Jobcenter integration til sygedagpengeområdet eksemplet er ikke udtryk for den endelige løsning. Figur 11 Eksempel med fagsystem (KSD) og jobcenterløsning. I det tænkte eksempel på Figur 11 anmelder arbejdsgiveren sygefravær via NemRefusion. Sagen kommer ind i Kommunernes Sygedagpengesystem (KSD). Da der ikke er en slutdato på fraværet skal der foretages opfølgning i Jobcenteret. Oplysning om sagens oprettelse sendes via en. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 13/14
Jobcenterløsningerne abonnerer på forretningsmæssige hændelser fra KSD. I løbet af hændelser på sagen tilflyder der derfor beskeder til Jobcenteret, som vist på figuren. Tilsvarende abonnerer KSD på forretningsmæssige hændelser fra Jobcenteret, fx at sygemeldte ikke dukker op til opfølgningen, da det får betydning for udbetalingen. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 14/14