Eksempel fra KOMBIT – integrationskrav og snitfladekatalog fra SKI-rammeaftale 02.19 SaaS- Cloud
Eksempel fra KOMBIT – integrationskrav og snitfladekatalog fra SKI-rammeaftale 02.19 SaaS- Cloud
I dette dokument har KOMBIT samlet bilag fra aftaledokumenter på SKI-rammeaftale
02.19 SaaS-Cloud (2019), delaftale 02: Kommune. Bilagene deles til inspiration for kommuners arbejde med at stille krav til løsningers anvendelse af den fælleskommunale infrastruktur.
Kommunen bør i hvert konkrete tilfælde vurdere, om det er relevant at stille krav til anvendelse af snitflader og fælleskommunal infrastruktur, og i givet fald hvilke specifikke komponenter og snitflader, der er relevante.
Dette dokument indeholder:
• Bilag 1 – KOMBIT integrationskrav til snitflader
• Bilag 2 – KOMBIT Snitfladekatalog
KOMBIT integrationskrav til snitflader
KOMBIT gør opmærksom på, at dette bilag oprindeligt stammer fra aftaledokumenterne for SKI-rammeaftale 02.19 SaaS-Cloud (2019), delaftale 02: Kommuner.
Der er sket ændringer for at gøre teksten mere generisk.
Indhold
2 Integration med den fælleskommunale infrastruktur 4
2.3 Undtagelser fra integrationskrav 5
Dette bilag specificerer krav om integration med den fælleskommunale infrastruktur som den er implementeret af KOMBIT.
Formålet med bilaget er at sikre, at Leverandøren på relevante områder anvender den fælleskommunale infrastruktur, med henblik på at:
• Styrke sammenhængen mellem systemer
• Fremme genbrug og standardisering
• Lette tilpasninger
• Lette leverandørskift
Bilaget skal ses i lyset af de arkitekturmål, der fremgår af de Fælleskommunale arkitekturprincipper fra februar 2013, jf. Kommunernes Landsforenings hjemmeside1.
Bilaget specificerer derfor krav til hvilke snitflader i den fælleskommunale infrastruktur, Leverandøren skal integrere med.
2 Integration med den fælleskommunale infrastruktur
Kapitlets afsnit 2.1 vedrører bruttolisten over de snitflader, der kan være krav om, at der skal integreres med. I afsnit 2.2 afgrænses integrationskravet i forhold til, hvilke snitflader i bruttolisten der konkret skal integreres med. I afsnit 2.3 beskrives undtagelser fra integrationskravene i afsnit 2.1 og 2.2.
Snitfladekataloget udgør bruttolisten over de snitflader i den fælleskommunale infrastruktur, der kan være krav om, at der skal integreres med.
Til hver snitflade i Snitfladekataloget hører en ”Integrationsbeskrivelse” med bilag, der forretningsmæssigt og teknisk beskriver snitfladen og vilkårene for dens anvendelse. Integrationsbeskrivelser og bilag er tilgængelige via xxx.xxxxxxxxxxxxxxxxx.xx [red.: Integrationsbeskrivelser og bilag er pr. 27. februar 2020 tilgængelige på Xxxxxxxxxxxxxxxxxxxxxxxx.xx].
Ligeledes eksisterer der et ”Beskedtypekatalog”. Beskedtypekataloget opregner de beskeder, det kan være relevant at sende og/eller modtage ifm. beskedfordeling. Beskedtypekataloget er tilgængeligt på KOMBITs hjemmeside, xxxxx-xxxx.xxxxxx.xx/X000/Xxxxxxx%00xxxx%00xxxxxxxxxxx/xxxxxxx.xxxx.
Kravene til, hvilke snitflader der konkret skal integreres med, udgør en delmængde af snitfladerne i Snitfladekataloget. Afgrænsningen af, hvilke snitflader i Snitfladekataloget, jf. bilag 2, man konkret skal integrere med, sker på basis af nedennævnte generelle og specifikke integrationskrav.
1 xxx.xx.xx/XxxxxXxxxxXxxxx/xx_00000/xx_000/X-xxxxxxxxxxxxx_xxxxxxxxxxxxxxxxxxxx_0.XXX
Generelle integrationskrav
Det er et generelt krav, at der integreres med den fælleskommunale infrastruktur under områderne i Tabel 1 ved at anvende relevante snitflader på området.
Område | Snitflader |
Adgangsstyring | SF1511, SF1512, SF1514 og SF1515 |
Beskedfordeling | SF1460_A, SF1460_B, SF1460_C og SF1460_D |
Tabel 1 Områder, hvor der er et generelt integrationskrav.
Specifikke integrationskrav
Ud over de generelle integrationskrav er der følgende specifikke integrationskrav.
Hvis der er overlap mellem en snitflades funktionalitet eller forretningsdækning på den ene side og funktionalitet eller forretningsdækning i en leverance på den anden side, skal leverancen integrere med snitfladen.
En leverance anses bl.a. for at have funktionalitet eller forretningsdækning, der overlapper snitfladens, hvis leverancen arbejder med et informationsobjekt, der håndteres af snitfladen. For eksempel skal en leverance til Erhvervelse af kørekort, der håndterer sager og dokumenter samt indeholder fakturering, integrere med henholdsvis snitflade SF1470 og SF1590_B.
Omvendt skal en leverance, der udelukkende understøtter ”Sagshåndtering - Myndigheders opgaver vedrørende journalisering og genfinding af sager i administrative systemer, herunder ESDH, Elektronisk Sags- og Dokumenthåndtering”, men som ikke har sager i leverancen, ikke understøtte snitfladerne til opdatering af sags- og dokumentindeksene.
Vedligehold
Såfremt KOMBIT opdaterer en snitflade skal leverandøren opdatere sin implementering af snitfladen indenfor 6 (seks) måneder.
2.3 Undtagelser fra integrationskrav
Afsnittet beskriver undtagelser fra integrationskravene i afsnit 2.1 og 2.2.
Hvis flere snitflader, som en leverance skal integrere med, dækker samme behov, er der kun krav om, at leverancen integrerer med en af snitfladerne.
Et integrationskrav til en snitflade bortfalder, hvis leverancen omfatter mindst samme funktionalitet ved at integrere direkte med en offentlig serviceplatform eller direkte med et offentligt stamdataregister, som hvis leverancen havde integreret med en snitflade fra Snitfladekataloget, jf. bilag 2. For eksempel kan en leverance til Erhvervelse af kørekort, der anvender CPR-oplysninger, enten hente CPR-oplysningerne gennem Grunddataprogrammet eller gennem den fælleskommunale infrastruktur.
Snitfladekatalog
KOMBIT gør opmærksom på, at dette bilag oprindeligt stammer fra aftaledokumenterne for SKI- rammeaftale 02.19 SaaS-Cloud (2019), delaftale 02: Kommuner. Dokumentet indeholder således udelukkende de snitflader, som leverandører på SKI 02.19 er forpligtiget til at benytte inden for de FORM-områder, en løsning omfatter og hvor en snitflade har relevans.
I forbindelse med en kommunes anskaffelse af en it-løsning kan det være relevant at skrive anvendelse af et eller flere infrastrukturkomponenter ind i aftalen. Kommunen bør i det konkrete tilfælde vurdere, om det er relevant at stille krav til anvendelse af snitflader og fælleskommunal infrastruktur, og i givet fald hvilke specifikke komponenter og snitflader, der er relevante.
Den fulde liste over snitflader (integrationer) stillet til rådighed gennem Støttesystemer og Serviceplatformen kan ses i Digitaliseringskataloget.
Forord
Dette snitfladekatalog beskriver de snitflader, KOMBIT stiller til rådighed gennem kommunernes Støttesystemer og Serviceplatform. Kataloget angiver de snitflader, som leverandørerne er forpligtigede til at benytte indenfor de FORM områder en given løsning omfatter og hvor den enkelte snitflade har relevans.
Alle snitflader i kataloget er tilgængelige i KOMBIT test- og produktionsmiljøer – kaldet Extest og Prod. Snitfladerne er alle beskrevet i detaljerede integrationsbeskrivelser, som kan findes via Xxxxxxxxxxxxxxxxx.xx [red.: Integrationsbeskrivelser og bilag er pr. 27. februar 2020 tilgængelige på Xxxxxxxxxxxxxxxxxxxxxxxx.xx]. Eftersom snitfladerne alle er konkrete og tilgængelige indgår de som en del af det egentlige udbud og prissættes dermed ikke selvstændigt.
Indhold
Snitflader der indgår i selve udbuddet 10
SF0741 - Sagshændelser fra AES 10
SF0810 - Indlæggelser og Udskrivninger 10
SF0830 - Sygesikringsudtræk 10
SF1411_A - Hent informationer om social pension 10
SF1411_B - Hent information om helbredsprocent 11
SF1411_D - Besked om information om social pension 11
SF1411_E - Besked om tillægsprocent 12
SF1460_B - Vedligehold værdiliste i beskedabonnement 13
SF1460_D - Modtag besked via pull 13
SF1470 - Sags- og Dokumentindeks 14
SF1500 - Organisation services 15
SF1510 - Klassifikation services 16
SF1511 - Sikkerhed Hent token fra Context Handler 16
SF1512 - SikkerhedSecurity Token Service, indgående 16
SF1514 - Sikkerhed Security Token Service, udgående 17
SF1515 - Sikkerhed SAMLSingleLogout 18
SF1518 - Sikkerhed Administrationsmodul webservice 18
SF1520 - CPR replica opslag 18
SF1590_A - ØiR - Afsend økonomipostering til ØiR (Finans) 18
SF1590_B - Afsend debitorregistrering til Debitor 19
SF1590_D - ØiR - Godkend faktura 19
SF1590_E - Afsend Betalingsanmodning til NemKonto 20
SF1600 - Print på Serviceplatformen 20
SF1605 - Modtag Digital post 21
SF1630 - Ledelsesinformation - dataload 21
SF1690 - Jobcenter - Kontanthjælp Modtag jobcentersag 21
SF1780 - Jobcenter - Send bevilling til jobcentersag 21
SF2090 - Jobcenter SDP Hændelser vedr. sygedagpengefravær 21
SF2093 - Jobcenter SDP Afsend anmodning om forlængelse 22
SF2095 - Jobcenter SDP Afsend status på jobcentersag 22
SF2096 - Jobcenter SDP Opslag på sag og sagsresume 22
SF2250 - NemSMS - Afsend SMS og tilmeld borger 22
SF2900 - Fordelingskomponenten 23
SF7001 - Overfør Klassifikation til abonnent 24
SF7002 - Overfør Sortiment til abonnent 24
Snitflader der indgår i selve udbuddet
SF0741 - Sagshændelser fra AES
Formålet med integrationen er at advisere kommunebrugere om oprettelser af og ændringer i status på arbejdsskadesager, der bliver registreret hos Arbejdsmarkedets Erhvervssikring (AES) samt oplysninger om evt. indhentede speciallægeerklæringer.
SF0810 - Indlæggelser og Udskrivninger
Integrationen har til formål at udstille adviser om borgeres indlæggelser og udskrivninger fra de regionale sygehuse til kommunale fagsystemer. Disse sygehusadviser er vigtige i den kommunale sagsbehandling, fx fordi en indlæggelse eller en udskrivning kan have betydning for stop eller start af kommunale ydelser. Adviserne omfatter MedCom-meddelelsesstandarderne:
• Indlæggelsesadvis (XDIS20/ILA)
• Udskrivningsadvis (XDIS17/USA)
Integrationen fungerer via Beskedfordeleren, men brugsscenariet beskrives selvstændigt for at tydeliggøre forretningsfunktionen
SF0830 - Sygesikringsudtræk
Formålet med integrationen er at vise oplysninger om en borgers sygesikring og læge. Oplysninger om sygesikring har indvirkning på afgørelser i en række sager på både beskæftigelses-, sundheds- og socialområdet.
Integrationen fungerer via Beskedfordeleren, men brugsscenariet beskrives selvstændigt for at tydeliggøre forretningsfunktionen.
SF1320_A - CPR - Hændelser
Integrationen har til formål at tilvejebringe og videresende relevante personhændelser på CPR- området for fagsystemer, der benyttes af offentlige myndigheder via det fælleskommunale støttesystem Beskedfordeler. Dette vil gøre fagsystemer i stand til at kunne reagere på personhændelser ift. de myndighedssager og arbejdsgange i forbindelse med forvaltningsvirksomhed som fagsystemet it-understøtter. Integrationen leverer kun hændelser fra CPR-registret og således ikke personhændelser fra fx udlændingeområdet.
SF1411_A - Hent informationer om social pension
Formålet med integrationen er at hente informationer for en given persons social pensionssag hos UDK, herunder oplysninger om:
• Sagens status
• Sagens ejer, bopælskommune, bevillingskommune og administrationskommune
• Pensionstype
• Pensionsstatus
• Samliv (herunder eventuel samlevers CPR-nummer)
• Formue
• Personlig tillægsprocent
• Pensionsbrøk eller procentpension
• Datoer for afslag på folkepension, tilkendelse og bevilling
• Udlandsophold over to måneder
• Forud- eller bagudbetalt pension
• Bistand / plejehjælp
• Angivelse af om personen er under administration
Der vil kun blive sendt de informationer, der er hjemmel til at modtage. Dataafgrænsning på de forskellige typer af information vil blive aftalt ifm. indgåelse af aftale om brug af integrationen, og UDK vil implementere filtre til håndtering af dette.
Snitfladen benyttes i sammenhæng med SF1411_D - Besked om information om social pension, som beskrives nedenfor.
SF1411_B - Hent information om helbredsprocent
Formålet med integrationen er at hente oplysninger om en given persons helbred og tilknyttede sag, herunder oplysninger om:
• Sagens (helbredskort) status
• Sagens ejer
• Helbredsprocent
• Sygeforsikring
Fagsystemet må kun modtage de informationer, der er hjemmel til at anvende. Dataafgrænsning på de forskellige typer af information vil blive aftalt ifm. indgåelse af aftalen om brug af integrationen.
Integrationen benyttes bl.a. af fagsystemer, som beregner ydelser med anvendelse af helbredsprocenten, f.eks. kommunale fagløsninger, der håndterer helbredstillæg.
Snitfladen benyttes i sammenhæng med 1.8 SF1411_E - Besked om tillægsprocent.
SF1411_D - Besked om information om social pension
Formålet med integrationen er at sende beskeder med ændringer i en given persons pensionssag hos UDK, herunder oplysninger om:
• Sagens status
• Sagens ejer, bopælskommune, bevillingskommune og administrationskommune
• Pensionstype
• Pensionsstatus
• Samliv (herunder eventuel samlevers CPR-nummer)
• Formue
• Personlig tillægsprocent
• Pensionsbrøk eller procentpension
• Datoer for afslag på folkepension, tilkendelse og bevilling
• Udlandsophold over to måneder
• Forud- eller bagudbetalt pension
• Bistand / plejehjælp
• Angivelse af om personen er under administration
Informationerne vil være kategoriseret i en række beskedhandlinger, så fagsystemerne kan abonnere på de informationer, der er hjemmel til at modtage. Dataafgrænsning på de forskellige typer af information vil blive aftalt ifm. indgåelse af aftalen om brug af integrationen.
Beskederne kommer fra UDK Pension (UDK PE). Beskederne leveres f.eks. til fagsystemerne KMD Social Pension Kommunedel, Social Pension Kommune (SPK) og Kommunernes Ydelsessystem (KY).
Informationerne i denne snitflade bliver indtil ibrugtagningen af UDK PE håndteret af KMD Social Pension (KMD SOP).
SF1411_E - Besked om tillægsprocent
Formålet med integrationen er at sende beskeder med ændringer i en given persons kommunale pensionssag, herunder oplysninger om:
• Helbredskort bevilges
• Helbredskort/bevilling stoppes
• Personlig helbredsprocent
• Sygesikringsgruppe
Informationerne vil være kategoriseret i en række beskedhandlinger, så fagsystemerne kan abonnere på de informationer, der er hjemmel til at modtage. Dataafgrænsning på de forskellige typer af information vil blive aftalt ifm. indgåelse af aftalen om brug af integrationen.
Beskederne leveres til fagsystemer, f.eks. Kommunernes Ydelsessystem (KY).
SF1460_A - Modtag besked
Det er kommunernes ambition at den fælleskommunal rammearkitektur skal være hændelsesdrevet og den fælleskommunale infrastruktur understøtter dette ved at stille Beskedfordeleren til rådighed for kommunerne og deres leverandører. Beskedfordeleren muliggør at et system kan abonnere på hændelser og dermed agere når en hændelse der er signifikant for forretningslogikken opstår.
Snitfladen er en beskrivelse af det REST endpoint hos Modtagersystemet, som muliggør at få leveret beskeder fra det fælleskommunale støttesystem Beskedfordeler. Snitfladen skal kunne modtage et HændelsesBesked objekt ud fra Beskedfordelers input. Snitfladen skal kunne håndtere at modtage samme besked flere gange.
Når beskeder havner i et dueslag, som endpointet er tilknyttet, kalder Beskedfordeler servicen og forsøger at aflevere beskeder fra dueslaget. Beskeder afleveres i samme rækkefølge, som de er distribueret til dueslaget. Beskedfordeler afleverer kun beskeder fra dueslag, der er markeret som aktiv i Beskedfordelers brugergrænseflade.
SF1460_B - Vedligehold værdiliste i beskedabonnement
Vaerdilister er lister af værdier (f.eks. personnumre eller KLE-emner), der i et Beskedfordelerabonnement ønskes sammenlignet med indholdet af et enkelt felt i en Beskedkuvert. Vaerdilister oprettes af Modtagersystemer der ønsker, at listen skal indgå i deres abonnementsudtryk, via den beskrevne snitflade. De generelle egenskaber for livscyklus for et Vaerdiliste forretningsobjekt er defineret som importeret eller oprettet og slettet. Servicens operationer kaldes med de inputparametre, angivet under hver enkelt operation.
Operationerne Importer, Opret, Passiver, Ret, Slet, TilfoejVærdier og FjernVærdier ændrer objektet ud fra operationens input, og eventuelt ændres objektets livscyklus. Livscyklus er enten Importeret, oprettet eller slettet. Operationerne List, Laes og Soeg ændrer ikke objektet. Vaerdiliste operationerne er inspireret af OIO Sag og Dokument standarderne version 1.1 men understøtter ikke virkningstid og fremdrift. Der er således ikke implementeret dobbelthistorik på Vaerdiliste og ønskede opdateringer på Vaerdiliste kan ikke angives frem eller tilbage i tiden.
SF1460_C - Aflever besked
Det er kommunernes ambition at den fælleskommunal rammearkitektur skal være hændelsesdrevet og den fælleskommunale rammearkitektur understøtter dette ved at stille Beskedfordeleren til rådighed for kommunerne og deres leverandører. Beskedfordeleren muliggør at et system kan sende hændelser til beskedfordeleren som dermed kan videredistribuere til .de fagsystemer der abonnerer på den enkelte hændelse.
Anvendersystemet kan anvende snitfladen Afsend besked over AMQP. Anvendersystemet kalder Beskedfordeler via AMQP med den token der autoriserer Anvendersystemet til at sende beskeder. Herved etablerer Anvendersystemet en TLS sikret kanal til Beskedfordeler. Ved anvendelse af AMQP etableres via mønstret RPC en todelt forbindelse til aflevering af beskeder og til modtagelse af svar fra Beskedfordeler. Når først AMQP-forbindelsen er etableret, kan der afsendes flere beskeder over samme kanal. Forbindelsen lever så længe at det medsendte token er gyldigt. Til hver besked medsendes et sikkerhedstoken der angiver at Afsendersystemet er autoriseret til at sende netop denne besked.
Mønstret der benyttes ved AMQP er RPC (Remote Procedure Call). Der benyttes RPC direct- reply-to jævnfør, RabbitMQ specifikationen. Derved kan sikkerhedstoken understøttes, og Afsendersystemet kan modtage svar på Beskedfordelers modtagelse af beskeder uden at give afkald på den fleksibilitet, skalering og performance, som den asynkrone kommunikation giver. Beskeder kan ikke anses for afsendt af Afsendersystemet, før at der er modtaget et positivt svar om beskedens modtagelse via forbindelsens svarkanal. Svarkanalen er temporær og eksisterer derfor kun så længe Afsendersystemets session med servicen er aktiv. Anvendersystemet skal sørge for at modtage svar på alle afsendte beskeder før at sessionen lukkes. Beskeder der ikke er modtaget svar for skal gensendes.
SF1460_D - Modtag besked via pull
Anvendersystemet kan anvende snitfladen afhent besked over AMQP. Anvendersystemet kalder Beskedfordeler via AMQP med dueslagets ID samt den token der autoriserer Anvendersystemet til dueslaget. Herved etablerer Anvendersystemet en sikker kanal til Beskedfordeler.
Ved succes opretter Beskedfordeler’s AMQP klient en konsumer, som afleverer beskeder efterhånden som beskederne ankommer i udbakke-dueslaget. Anvendersystemet bliver kontaktet straks, når der er nye beskeder i dueslaget. Beskederne afleveres til Anvendersystemet, og først når beskeden bliver acknowledged af Anvendersystemet, fjernes den fra udbakke-dueslaget. En acknowledge betyder, at klienten nu er ansvarlig for, at beskeden er leveret til Anvendesystemet. Hvis der allerede findes beskeder i dueslaget ved etablering af forbindelsen, afleveres den første besked straks når Anvendersystemet begynder at lytte til den åbne forbindelse. Efter Anvendersystemets acknowledge af modtagelse af beskeden sendes den næste besked, indtil at dueslaget et tomt.
SF1470 - Sags- og Dokumentindeks
Overordnet er formålet med indekserne at indeholde og udstille data der kan bruges til at etablere sagsoverblik, sådan som SAPA gør det. Derudover gives adgang til andres fagsystemers sager i et andet fagsystem eller ESDH-system.
Integrationen benyttes til at vedligeholde en kopi af anvendersystemets sager i Sagsindekset og tilhørende dokumenter i dokumentindekset. Herudover udstilles en operation til fremsøgning af sager og dokumenter.
Der udstilles tre services:
• SagDokumentIndeks der kan Importere, Opdatere, Fjerne, eller Fremsøge en eller flere sager og/ eller dokumenter.
• SagIndeks der kan ændre status på en sag til Passiveret eller Slettet samt kassere (fysisk) Sager.
• DokumentIndeks der kan ændre status på et dokument til Passiveret eller Slettet samt kassere (fysisk) Dokumenter
Der er to anvendelsesscenarier:
1. Opdatering
Dette anvendes af fagsystemer til at vedligeholde kopier af sags- og dokumentobjekter i indekset. Der benyttes Import til at tilføje nye sager og eller dokumenter, Opdater til at ændre indholdet af eksisterende sager og eller dokumenter (herunder at tilføje journalnotater). Der kaldes en særlig service til at passivere eller logisk slette et sagsobjekt. Det samme gælder for dokumenter. Endelig kan sager og dokumenter fjernes (dvs. fysisk slettes).
2. Fremsøg
Dette anvendes typisk af systemer der har behov for overblik over sager og dokumenter. Operationen kan levere information omkring sager og dokumenter på diverse kriterier.
SF1490 - Ydelsesindekset
Overordnet er formålet med indekserne at, indeholde og udstille data, der kan bruges til at etablere sagsoverblik, sådan som SAPA gør det. Derudover gives adgang til andres fagsystemers sager i et andet fagsystem eller ESDH-system.
Denne integration har til formål at give fagsystemerne mulighed for at vedligeholde kopier af deres ydelser i indekset, samt at kunne understøtte ydelsesoverblik i f.eks. SAPA og KMD Bevilling.
Herudover benyttes ydelsesindekset til at udveksle ydelsesinformation mellem fagsystemer for at understøtte deres forretningsprocesser (f.eks. ydelsesberegninger og kontrol).
Ydelser opdeles i bevillinger der informerer om hvilke ydelser ydelsesmodtageren har fået bevilget, og effektueringer der informerer om ydelser der er leveret til modtageren (f.eks. en udbetaling af en økonomisk ydelse).
Der udstilles tre services:
1. YdelsesIndeks der kan Importere, Opdatere, eller Fremsøge en eller flere bevillinger og/ eller effektueringer
2. BevillingIndeks der kan ændre status på en bevilling til Passiveret/ Slettet eller fysisk slette en bevilling med tilhørende effektueringer
3. OekonomiskEffektueringIndeks der kan ændre status på en effektuering til Passiveret/ Slettet eller fysisk slette en effektuering
Der er to anvendelsesscenarier:
1. Opdatering
Dette anvendes af fagsystemer til at vedligeholde kopier af bevillings- og effektueringsobjekter i indekset. Der benyttes Import til at tilføje nye bevillinger og eller effektueringer, Opdater til at ændre indholdet af eksisterende bevillinger og eller effektueringer. Der kaldes en særlig service til at passivere eller logisk slette et bevillingsobjekt. Det samme gælder for effektueringer. Endelig kan bevillinger og effektueringer fjernes (dvs. fysisk slettes).
2. Fremsøg
Dette anvendes typisk af systemer der har behov for overblik over bevillinger og effektueringer. Operationen kan levere information omkring bevillinger og effektueringer på diverse kriterier.
Hvis der ønskes udveksling af ydelsesinformation mellem myndigheder, henvises til integration SF2860 Terminalservice.
SF1500 - Organisation services
Organisationssystemer anvendes i mange af kommunernes it-løsninger. Et Organisationssystem kan eksempelvis være en forvaltning, en del af en forvaltning, kommunalbestyrelsen eller andre for It-løsninger individuelle Organisationer. Et Organisationssystem kan godt bestå af blot 1 objekt.
Støttesystemet Organisation giver mulighed for at:
• Anvendersystemer kan offentliggøre egne organisationssystemer til brug i andre løsninger
• Anvendersystemer kan hente organisationssystemer og anvende disse
Støttesystemet Organisation udstiller 11 services, én service for hvert domæneområde (Adresse, Bruger, Interessefaellesskab, ItSystem, Myndighed, OrganisationEnhed, OrganisationFunktion, Organisation, OrganisationSystem, Person, Virksomhed). For 10 af disse services gælder det, at de hver har 8 operationer, der kan deles op i to kategorier; dem som ændrer i objekter (importer, opret, passiver, ret og slet) og dem som ikke ændrer i objekter (list, laes og soeg). Fagprojekterne vil typisk anvende operationerne list, laes og soeg, Den undtagne service (OrganisationSystem) udstiller tre operationer: import, eksport og fremsoegobjekthierarki.
SF1510 - Klassifikation services
Klassifikationssystemer anvendes i mange af kommunernes it-løsninger. Et klassifikationssystem kan eksempelvis være KLE, FORM eller andre for it-løsningen individuelle klassifikationer. Et Klassifikationssystem kan godt bestå af blot 1 objekt.
Støttesystemet Klassifikation giver mulighed for at:
• Anvendersystemer kan offentliggøre egne klassifikationssystemer til brug i andre løsninger
• Anvendersystemer kan hente klassifikationssystemer og anvende disse
• Anvendersystemer kan hente klassifikationssystemer, herunder mapninger mellem klassifikationssystemer og anvende disse
Støttesystemet Klassifikation udstiller 4 services. For 3 af disse services gælder det, at de hver har 8 operationer, der kan deles op i to kategorier; dem som ændrer i objekter (importer, opret, passiver, ret og slet) og dem som ikke ændrer i objekter (list, laes og soeg). Fagprojekterne vil anvende operationerne list, laes og soeg, Den undtagne service (KlassifikationSystem) udstiller tre operationer: import, eksport og fremsoegobjekthierarki.
SF1511 - Sikkerhed Hent token fra Context Handler
Adgangsstyring for brugere er en af hjørnestenene i sikkerhedsmodellen i den fælleskommunale infrastruktur. Adgangsstyring for brugere gør det muligt for kommunen at konsolidere deres adgangsstyring i én løsning, som de selv har kontrol over. For leverandører af brugervendte systemer betyder det, at der ikke skal laves brugerstyring i selve fagløsningen, men blot håndhæves nogle brugersystemroller.
Med Adgangsstyring for brugere er det muligt for kommunerne at implementere Single Sign On til alle deres løsninger.
Adgangsstyring for brugere er en sikkerhedsmodel rettet mod brugervendte systemer – dvs. it- systemer med en brugergrænseflade. Sikkerhedsmodellen understøttes af støttesystemerne Context Handleren og STS Administration. Både det brugervendte system og kommunens lokale Identity Provider integrerer til Context Handler, og begge systemer er registreret i STS Administration, hvor rettighederne modelleres.
SF1512 - SikkerhedSecurity Token Service, indgående
Denne snitflade beskriver hvorledes et it-system skal understøtte at være serviceudbyder med rammearkitekturens token-baserede sikkerhedsmodel.
En række it-systemer kræver myndighedsgodkendelse, før der kan opnås adgang til servicen. Myndighedens godkendelse kan eksempelvis være påkrævet, fordi servicen udleverer data, som myndigheden er dataansvarlig for, eller fordi myndigheden skal betale for anvendelse af servicen.
Adgangsstyringen i rammearkitekturen understøtter sådanne services (benævnt fælleskommunale services), hvor et it-system udstiller en service, der kan anvendes i kontekst af forskellige myndigheder, men hvor adgang til servicen godkendes individuelt af hver enkelt myndighed. I rammearkitekturens adgangsstyringsmodel kan en service både benyttes til at udlevere data fra en
serviceudbyder, til at indlevere data til serviceudbyderen eller til at få serviceudbyderen til at udføre en handling for anvenderen it-systemet.
Anvendersystemer vil typisk være fagsystemer, der skal anvende et af støttesystemerne. Anvendersystemer kan også være et støttesystem, der ønsker at anvende en service, der udstilles af et andet støttesystem. Et givet it-system kan således optræde i flere forskellige roller i rammearkitekturen samtidigt.
Når et anvendersystem tilgår en serviceudbyder, foregår adgangsstyring ved at anvendersystemet først anmoder støttesystemet Security Token Service om et security token med de servicesystemroller, som anvendersystemet er tildelt den aktuelle serviceudbyder gennem serviceaftaler.
Security Token Servicen i Støttesystemerne har til formål at udstede security tokens, der er en signeret XML-billet, der beskriver et givet Anvendersystems adgang til en specifik service i kontekst af en specifik Myndighed. Adgangstokens er baseret på SAML standarden og anmodninger til Security Token Servicen forgår ved brug af OIO WS-Trust protokollen.
SF1514 - Sikkerhed Security Token Service, udgående
Denne snitflade beskriver hvorledes et it-system skal understøtte at være anvendersystem og anvende rammearkitekturens token-baserede sikkerhedsmodel.
En række it-systemer kræver myndighedsgodkendelse, før der kan opnås adgang til servicen. Myndighedens godkendelse kan eksempelvis være påkrævet, fordi servicen udleverer data, som myndigheden er dataansvarlig for, eller fordi myndigheden skal betale for anvendelse af servicen.
Adgangsstyringen i rammearkitekturen understøtter sådanne services (benævnt fælleskommunale services), hvor et it-system udstiller en service, der kan anvendes i kontekst af forskellige myndigheder, men hvor adgang til servicen godkendes individuelt af hver enkelt myndighed. I rammearkitekturens adgangsstyringsmodel kan en service både benyttes til at udlevere data fra en serviceudbyder, til at indlevere data til serviceudbyderen eller til at få serviceudbyderen til at udføre en handling for anvenderen it-systemet.
Anvendersystemer vil typisk være fagsystemer, der skal anvende et af støttesystemerne. Anvendersystemer kan også være et støttesystem, der ønsker at anvende en service, der udstilles af et andet støttesystem. Et givet it-system kan således optræde i flere forskellige roller i rammearkitekturen samtidigt.
Når et anvendersystem tilgår en serviceudbyder, foregår adgangsstyring ved at anvendersystemet først anmoder støttesystemet Security Token Service om et security token med de servicesystemroller, som anvendersystemet er tildelt den aktuelle serviceudbyder gennem serviceaftaler.
Security Token Servicen i Støttesystemerne har til formål at udstede security tokens, der er en signeret XML-billet, der beskriver et givet Anvendersystems adgang til en specifik service i kontekst af en specifik Myndighed. Adgangstokens er baseret på SAML standarden og anmodninger til Security Token Servicen forgår ved brug af OIO WS-Trust protokollen.
SF1515 - Sikkerhed SAMLSingleLogout
Integrationen er direkte integration til Støttesystemet Context Handler og vedrører den situation, hvor Fagsystemet eller Context Handler ønsker at logge en person ud. Hvis en bruger ønsker at logge ud af Fagsystemet og trykker på en ”logout” knap, så kan fagsystemet danne et LogoutRe- quest og sendes til Context Handleren, for at bede den afslutte brugerens session. Det kan også være Context Handleren der initierer logout, og her vil fagsystemet skulle modtage et LogoutRe- quest og foretage et logud af brugeren i fagsystemet på baggrund af dette request.
SF1518 - Sikkerhed Administrationsmodul webservice
Jobfunktionsrollesnitfladen giver mulighed for at hente og uploade de Jobfunktionsroller, der administreres i Støttesystemet Administrationsmodul for en given Myndighed.
Snitfladen giver mulighed for at:
• liste alle Jobfunktionsroller for en given Myndighed.
• hente information om en Jobfunktionsrolle med et specificeret ID for rollen.
• uploade Myndighedens Jobfunktionsroller til Støttesystemet Administrationsmodul.
Snitfladen er sikret som en Fælleskommunal webservice, hvor Støttesystemet Administrationsmodul optræder som Serviceudbyder.
En Myndighed kan alene anvende snitfladens funktionalitet inden for egen Anvenderkontekst.
Anvenderkontekst, dvs. Myndighedens CVR-nummer, er indeholdt i Anvendersystemets kald til Støttesystem Adgangsstyring for systemer og vil via Servicesystemtoken blive leveret til Servicen. Herfor skal Anvenderkontekst ikke medgives ved kald af de tre snitflade operationer.
Snitfladen Jobfunktionsrolle indeholder tre operationer; List, Hent og Importer.
SF1520 - CPR replica opslag
Formålet med integrationen er at give kommunernes fagsystemer mulighed for at fremsøge de per- sonoplysninger, der er nødvendige, for den kommunale sagsbehandling og forvaltningsvirksom- hed.
Integrationen indeholder en service, der kan bruges til at fremsøge personer ud fra udvalgte søge- kriterier (Query), samt en service, der kan bruges til opslag af detaljerede personoplysninger på en enkeltperson ud fra CPR-nummer. Den hedder ”Person stamdata, udvidet (lokal)” på Serviceplat- formen.
SF1590_A - ØiR - Afsend økonomipostering til ØiR (Finans)
ØiR – Økonomi i Rammearkitekturen – indeholder en række snitflader, som benyttes af fagsystemerne til at give en ensartet snitflade mod de bagvedliggende ERP-systemer til håndtering af finans-, debitor-, kreditorposteringer samt udbetalinger.
Denne integration dækker finanspostering, dvs. fagsystemets aflevering af finansbilag med finans- poster til myndighedens bogføringssystem.
Integrationens begrebsmodel har sit primære udspring i Indenrigsministeriets retningslinjer for kontering i kommunerne. Det giver et fælles og leverandøruafhængigt ophæng, samtidig med at det sikrer, at myndighederne kan foretage den lovpligtige regnskabsindberetning. Som supplement hertil giver begrebsmodellen samt det tilhørende klassifikationssystem mulighed for at supplere og erstatte dele af den primære model efter regler fastsat af myndigheden.
Det er det enkelte fagsystem, som fastsætter konteringsmodellen inden for denne ramme. Det er bogføringssystemet opgave og ansvar at mappe den modtagne finanspostering til myndighedens kontoplan i bogføringssystemet.
SF1590_B - Afsend debitorregistrering til Debitor
ØiR – Økonomi i Rammearkitekturen – omfatter services til brug for dataudveksling mellem fagsystemet og ERP-systemer indenfor områderne finans, kreditor, ordre og fakturering samt debitor og betalinger.
Integration dækker debitorregistrering, dvs. fagsystemets aflevering af og opdatering af debitorregistrering i myndighedens debitorsystem. Integrationen giver endvidere fagsystemet mulighed for at søge og hente debitorregistreringer, foretage indbetalinger, gennemføre ejerskifte
m.m. samt at hente mange debitorkontis status for betalingsservice og indbetalinger på krav.
Debitorregistreringer er samlet om en debitorkonto eller en indbetaling. Debitorkontoen er formålsangivet med en debitorkontotype. Debitorkontotyper er fastlagt i en fælleskommunal klassifikation. Det enkelte fagsystem fastlægger sine delfordringstyper for de specifikke krav. Tilsvarende gør debitorsystemet for de krav, som alene håndteres af debitorsystemet.
SF1590_D - ØiR - Godkend faktura
ØiR – Økonomi i Rammearkitekturen – omfatter services til brug for dataudveksling mellem fagsystemet og ERP-systemer indenfor områderne finans, kreditor, ordre og fakturering samt debitor og betalinger.
Integrationen, beskrevet i dette dokument, giver kommunen mulighed for at foretage decentral fakturakontrol og godkendelse i et fagsystem uden, at kommunen mister den samlede kontrol og overblik over sine fakturaer og indkøb, som kommune har i sit centrale fakturahåndteringssystem.
Integrationen understøtter dokumenttyperne faktura, rykker og kreditnota også kaldet
Fakturainformationer.
I forbindelse med den decentrale fakturagodkendelse forudsættes det, at det enkelte fagsystem har information om bevillingsramme, ordre eller de aftalte ydelser, som en faktura vedrører.
I tillæg til fakturagodkendelse kan fakturahåndteringssystemet, hvor det giver forretningsmæssig mening, angive, at fagsystemet skal medsende posteringsinformation til brug for fakturahåndteringssystemets driftskontering.
Integrationen understøtter fremsendelse af fakturainformation i formatet OIOUBL, som er det format som i dag benyttes af NemHandel. Integrationen er forberedt til at kunne understøtte andre formater, både nye offentlige standarder samt lokale standarder indenfor kommuneområdet.
SF1590_E - Afsend Betalingsanmodning til NemKonto
Integrationen giver et fagsystem adgang til udbetaling via NemKonto. NemKonto understøtter komplette og ukomplette betalinger, som resulterer i en pengeoverførsel mellem betalers bankkonto og modtagers bankkonto.
NemKonto er understøttet i systemet NemKonto System, NKS.
Integrationens er tiltænkt de fagsystemer, som ikke ønsker at tilgå NKS direkte, fx hvor fagsystemet har behov for at sende mere end 25.000 betalingsanmodninger pr. år2, og samtidig ikke ønsker at etablere en infrastruktur med en MQ Server.
Integrationen formidler betalingsanmodninger uændret fra fagsystem til NKS.
SF1600 - Print på Serviceplatformen
Formålet med servicen er at muliggøre afsendelse af breve til borgere og virksomheder enten via Digitaliseringsstyrelsens Digital Post-løsning eller som fysisk brev via kommunens Fjernprintløsning. Løsningen giver også mulighed for at sende breve mellem myndigheder, dette sker på helt samme vis, som for virksomheder.
Fagsystemerne har tre muligheder for kanalvalg ved afsendelse af breve til hhv. Digital Post og Fjernprint:
• Fagsystemet kan selv foretage valg af kanal ud fra bl.a. tilmeldingsstatus fra Digital Post, som kan hentes via Serviceplatformen.
• Fagsystemet kan lade Serviceplatformen vælge kanalen ud fra den dagligt indlæste tilmeldingsliste fra Digital Post placeret på Serviceplatformen.
• Fagsystemet kan lade den valgte Fjernprint-løsning forestå som kanalvalg under forudsætning af, at det understøttes af den valgte løsning.
De tre muligheder er understøttet af en og samme service udstillet på Serviceplatformen. Det betyder, at fagsystemet, såfremt der er et forretningsmæssigt behov herfor, løbende kan skifte mellem de tre muligheder for kanalvalg.
For at kunne fordele breve til borgeren og virksomheder mellem Digital Post og Fjernprint (kanalvalg), udstiller Serviceplatformen en service, hvor fagsystemet kan forespørge på status for tilmelding til Digital Post for borgeren. Dette giver også mulighed for at fagsystemet kan differentiere indholdet afhængig af om brevet sendes, som et digitalt eller fysisk brev.
Integration kan benyttes af kommuner, som har valgt en fjernprintleverandør, som er tilsluttet Ser- viceplatformen. Omkostninger i forbindelse med tilslutning og fremsendelse af breve til Digital post og fjernprintleverandører afholdes direkte af kommunen. Kommunen har nogle mulighed for gennem opsætning og/eller parameterangivelse for forsendelser at foretage detaljeret opfølgning af forbruget hos Digital post og fjernpostleverandøren.
2 De 25.000 betalingsanmodninger pr. år er en tærskelværdi sat af NKS. Under tærskelværdien kan fagsystemet benytte en MQ Client opkobling. Over tærskelværdien skal fagsystemet benytte en MQ Server, som alt andet lige giver en anden omkostning for fagsystemet.
Fjernpostleverandørerne understøtter alle Prioritaire (Quickbrev), Economique (brev). Enkelte leverandører understøtter yderligere Bulk, Rekommanderet med digital underskrift.
SF1605 - Modtag Digital post
Formålet med snitfladen er, at et fagsystem kan modtage digitale meddelelser fra Digital post. De digitale meddelelser kan enten være et nyt brev, eller svar på et brev, der tidligere er fremsendt af en kommune. Begge dele kan være sendt af en borger, virksomhed eller anden offentlig myndighed.
SF1630 - Ledelsesinformation - dataload
Formålet med snitfladen er at kunne levere et dataudtræk til Serviceplatformen, så kommunerne kan udarbejde detaljeret ledelsesinformation på ydelsesområdet. Fagsystemet skal således stille data til rådighed for den kommunale eller fælleskommunale ledelsesopfølgning gennem kommunernes egne ledelsesinformationssystemer (LIS) eller gennem det fælleskommunale ledelsesinformationssystem (FLIS). Dataudtrækket skal derfor i udgangspunktet dels leveres til FLIS som flere kommuner pt. er tilsluttet og dels op til 98 separate kommuners LIS systemer.
Det konkrete dataudtræk kan være afgrænset tidsmæssigt og vil bestå af udvalgte entiteter fra den pågældende datamodel. Dataudtrækket vil være specificeret ens, hvad enten det leveres til FLIS eller kommunernes egne ledelsesinformationssystemer (LIS).
SF1690 - Jobcenter - Kontanthjælp Modtag jobcentersag
Kommunernes Ydelsessystem (KY) skal udstille en snitflade, til brug for jobcentrenes fagsystemer, således at ydelsessystemet kan modtage information om forskellige hændelser fra jobcentrene; herunder kontaktforløb, visitationsgruppe, tilkendegivelse, aktivitet, godtgørelser, fravær, sanktionsanmodninger og målgruppeskift.
SF1780 - Jobcenter - Send bevilling til jobcentersag
Kommunernes Ydelsessystem (KY) skal kalde en service udstillet af jobcentersystemerne til at sende informationer om bevillinger, når der er ændringer i borgerens ydelse. Der overføres bevillingsoplysninger på en borger, når en bevilling oprettes eller ændres (herunder slettes). Evt. relation til kendt kontaktforløb og sag overføres i form af identifikationer for kontaktforløbet og Jobcenter systemets sag.
SF2090 - Jobcenter SDP Hændelser vedr. sygedagpengefravær
Sygedagpengesystemet opretter en sygefraværssag. Såfremt der ikke er angivet en sidste fraværsdag, sendes oplysninger om sygefraværssagen videre til Jobcenter systemerne, så de kan
iværksætte en parallelt løbende opfølgningssag. Når sygefraværssagen ændres, skal der ligeledes sendes besked herom til Jobcenter systemerne.
SF2093 - Jobcenter SDP Afsend anmodning om forlængelse
Når en sygefraværssag nærmer sig revurderingstidspunktet, skal der i kommunens Jobcenterløsning (JCS) tages stilling til, om sygefraværssagen kan forlænges.
Sygedagpengesystemet (KSD) forespørger derfor JCS, om sygefraværssagen kan forlænges. JCS svarer med et afslag, eller med en forlængelseskode.
Ydermere er det muligt for JCS at udsende besked om igangsat forlængelse til KSD, uden at der har været sendt forudgående anmodning.
SF2095 - Jobcenter SDP Afsend status på jobcentersag
Når en jobcentersag ændres i Jobcenter systemet, opdaterer Jobcenter systemet sygedagpenge- systemet. Sygedagpengesystemet modtager således et kald fra Jobcenter systemet (JCS), hvorefter indholdet valideres og sygefraværssagen opdateres. Efterfølgende sender sygedagpengesystemet en forretningsmæssigt svar.
SF2096 - Jobcenter SDP Opslag på sag og sagsresume
Formålet med integrationen er at gøre det muligt for et jobcenter at hente en angiven borgers sygefraværssag fra sygedagpengesystemet, herunder når der for sygefraværssagerne oprettes et resume af sagen.
SF2250 - NemSMS - Afsend SMS og tilmeld borger
Denne integration bruges til at sende borgeren beskeder omkring f.eks. udbetalinger, samt ad-hoc beskeder som f.eks. ”Der er sket ny i din sag. Se mere på Selvbetjeningen”. Snitfladen forbinder brugeren med NemSMS.
Det er en forudsætning at borgeren forudgående har tilmeldt sig SMS.
SF2860 - Terminalservice
Terminalservicen har til formål at understøtte styret og datafiltreret adgang til ydelsesdata på tværs af myndigheder, ved udveksling af ydelsesdata mellem kommunerne og Udbetaling Danmark (UDK). Udveksling af ydelsesdata er underlagt lovgivningsmæssige begrænsninger, hvorfor der er behov for at styre dels adgangen og dels graden af data, der udveksles, hvilket ikke kan lade sig gøre via Ydelsesindeksets eksisterende servicegrænseflade.
SF2900 - Fordelingskomponenten
Fordelingskomponenten har til formål at sikre juridisk overdragelse af objekter og data fra en myndighed til en anden myndighed med et forretningsmæssig formål og accept. En myndighed på Serviceplatformen er enten en kommune eller Udbetaling Danmark. Efter genudbud af Serviceplatformen kan der ske en udvidelse af myndigheder – formodentlig i 2019.
Objekter der fordeles er:
• Sags-journalnotater
• Sags-dokumenter
• Blanketter og formularer (semistruktureret data)
Indhold af data i blanketter og formularer defineres af de myndigheder, som ønsker at udveksle disse, men fordelingsmekanismen er den samme, som for Journalnotat og dokument. Det er myndighedernes ansvar at indgå aftale om udveksling af disse data, hvilket bør fremgå af servicebeskrivelsen.
Man kan i fordelingskomponenten skelne mellem de forskellige type af dataindhold her under forskellige typer af blanketter og formularer.
Fordelingskomponent giver mulighed for at:
• Fordeling sker fra èt IT-system til ét andet IT-system, inden for samme myndighed, eller mellem to forskellige myndighed
• Fordeling af blanketter og formularer også kan ske fra en myndigheds IT-system til en myndigheds Digital post
Der er således tale om en 1-1 overdragelse. Èn myndighed overdrager til eller èn anden myndighed (ofte myndigheden selv), samtidig gælder at det er fra èt system til èt anden system.
Fordelingskomponenten kan fordele objekter på følge to måder: Ny sag:
Myndigheden modtager en henvendelse, som ikke kan henføres til en kendt sag. Henvendelsen oprettes i et IT-system, og klassificeres med KLE emne og facet, samt CVR-nr. på den myndighed, som skal eje henvendelse. Henvendelsen sende via fordelingskomponenten til det modtager IT-system og myndighed. Afsendere kender ikke det IT-system, som skal modtage henvendelsen. Rutningen af henvendelse sker ved at fordelingskomponenten fortager et opslag i fordelingsregler, og på baggrund af CVR-nr., KLE emne og KLE facet, finder det IT-system, som henvendelsen skal afleveres til. Findes der ikke en rutningsregel eller er der flere rutningsregler, som tilfredsstiller kriteriet, vil fordelingen blive afvist. Er der flere rutningsregler, som tilfredsstiller kriterierne, skal der vælges et specifik modtager IT-system.
Eksisterende sag:
Myndigheden modtager en henvendelse, som kan henføres til en kendt sag. Henvendelsen oprettes i et IT-system, og der foretages opslag på sagen mod Sag og dokument indekset for at finde det IT-system, som ejer sagen.
Fordelingskomponenten kaldes med det IT-systemet og CVR-nr. på modtager, og fordelingskomponenten videresender til denne.
Det er den modtagende myndighed, som opsætter rutningsregler. Det er også fordelingsregler, som angiver om blanketter og formularer skal videresendes via Digital post.
Modtageren af et objekt skal afgive en forretningsmæssig kvittering, som angiver om objektet kan accepteres eller skal afvises. Afsenderen kan først betragte objektet, som overdraget efter en positiv forretningskvittering. Dette gælder dog ikke Digital post, hvor overdragelse sker umiddelbart. Bemærk af journalnotat og sagsdokument ikke kan sendes via Digital post.
SF7001 - Overfør Klassifikation til abonnent
Integrationen tilvejebringer i forbindelse med SF1590 eksport af Klassifikationer til abonnenter af disse.
SF7002 - Overfør Sortiment til abonnent
Integrationen tilvejebringer i forbindelse med SF1590 eksport af Sortimenter til abonnenter af disse. Sortimenter indeholder Registreringsværdier med reference til klassifikation. Hvert Sortiment udtrykker definerede Registreringsværdier i kontekst af udvalgte it-systeminstansers brug ift. en snitflade.
Dialogintegration med SAPA
Dialogintegration har til formål at understøtte en smidig transport af en bruger fra et it-systems brugergrænseflade til SAPAs brugergrænseflade og vice versa. Der er altså tale om at en bruger via en brugergrænseflade kan navigere imellem it-systemer og ikke at it-systemerne kommunikerer eller integrerer direkte med hinanden.
Dialogintegration tillader en sagsbehandler i et it-system at hoppe med udgangspunkt i et konkret forretningsobjekt, der vises i it-systemets brugergrænseflade, til det samme eller relateret forretningsobjekt i et andet it-system. Det kunne fx være at en bruger, som arbejder med en bestemt borger i et fagsystem har behov for at få et overblik over denne borgers øvrige sager i kommunen, hvorfor brugeren ved et enkelt klik fra fagsystemet ønsker at hoppe over i kommunens overblikssystem SAPA og få vist et overblik for den konkrete borger. På samme vis kunne det fx være, at en bruger i SAPA har behov for at vide mere om en konkret sag, hvorfor brugeren med et enkelt klik kan hoppe fra SAPAs liste af sager for borgeren til visning af den konkrete sag i det fagsystem, som sagen bor i.
Specifikationen af snitfladen kan tilgås her: xxxxx://xxxxx- xxxx.xxxxxx.xx/X000/Xxxxx%00xxxxxxxxxx/Xxxxx/XXXX%00xxxxxxxxxxxxxxxxx.xxxx