Integration 1411 A V3 Hent informationer om social pension - Hent... · Integration 1411_A_V3 Hent informationer om social pension Integrationsbeskrivelse - version 3.2.1 Kommunernes

Integration 1411_A_V3 Hent informationer om social pension

Integrationsbeskrivelse - version 3.2.1

Kommunernes Data & Infrastruktur - KDI

Integrationsbeskrivelse 1411_A Hent informationer om social pension

KOMBIT A/S Halfdansgade 8 2300 København S www.kombit.dk CVR 19 43 50 75 Side 2 af 50

Versionshistorik

Relevans Dato Initialer Version Kommentarer

2017-11-13 XMHL 3.0.0 Dataspecifikation opdateret til version 3.0.0 udstillet af UDK PE.

2018-02-08 XMHL 3.0.1 Opdateringer inkl. kommentarer fra SPK.

2018-04-04 XMHL 3.0.2 Opdateringer på baggrund af kommentarer fra UDK.

Mindre redaktionelle rettelser:

Fjernet referencen [SPref], tilføjet referencen [GVF], der var henvist til i dokumentet.

Opdateret afsnit 1.3.2 om Servicemanagement med ny kontakt-email.

Opdateret afsnit 1.4.1 om test i forbindelse med udvikling.

2018-05-30 XMHL 3.0.3 Opdateret med informationer relateret til KMD Structura i afsnit 2.4 og sagsområdekode i for KMD Structura i afsnit 3.1.3.2.1.

2018-06-25 XMHL 3.0.4 Afsnit 2.4 opdateret med Information om KMD Structura.

Afsnit 3.1.3.2 opdateret, så der kan sendes både myndighedskode og CVR-nummer for myndigheder i elementet ReferenceID i strukturen Psagsaktoer.

2018-09-19 XMHL 3.1.0 Referencer er opdateret:

- [Hovedoplysninger] og [HO-præciseringer] tilføjet

- [WSDL-SP] og [WSDL-EXT] opdateret

Afsnit 2.1.2, 2.2.2, 2.3.2, 2.4.2 og 2.5.2 er opdateret ift. kapacitet og spidsbelastning.

Afsnit 3.1.3.2 er opdateret med følgende:

- PSags-elementet i de tekniske pakker er gjort optionelt

- Nye illustrationer

- HovedOplysninger og HovedOplysningerSvar

2018-11-08 XMHL 3.1.1 Afsnit 3.1.3.1.4 og 3.2.3.1.4 opdateret med ændring af SOAP version 1.2 til 1.1.

Afsnit 3.1.3.2.2 opdateret med ny FormueType for indefrosset grundskyld.

2018-11-29 XMHL 3.2.0 Afsnit 3,1,3,2,2 opdateret med ændring ift. BevillingDato og TilkendelsesDato:

- BevillingDato er fjernet. PensionistType:Virkning har fået semantisk betydning som BevillingDato.

- Feltet TilkendelsesDato er flyttet til PensionistType.

[WSDL-EXT], [Bilag] og [Sagsomraade] opdateret.

2018-12-05 XMHL 3.2.1 Afsnit 1.3.1 og 3.2.3.5.1 opdateret med servicemål for UDK PE.

Referencer

Ref. Titel Kommentarer

[STS-Sikkerhed] Se vilkår Bilag 2 - Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen version 2.2 på nedenstående link https://share-komm.kombit.dk/P133/Referencedokumenter/STS%20Vilk%C3%A5r

https://share-komm.kombit.dk/P133/Referencedokumenter/STS%20Vilk%C3%A5r





[WSDL-SP] Integrationsbeskrivelsen refererer til SF1411_A_V3 Teknisk Spec 20181130.zip som indeholder WSDL på Serviceplatformen, og er placeret i samme mappe som integrationsbeskrivelsen, se link https://share-komm.kombit.dk/P133/Integrationsbeskrivelser/Forms/Grp%20snitfladengler%20Release.aspx

[Bilag] Integrationsbeskrivelsen refererer til SF1411_A_V3 Bilag 20181130.zip, som indeholder den eksterne dokumentation, der refereres til i integrationsbeskrivelsen. Filen er placeret i samme mappe som integrationsbeskrivelsen, se link https://share-komm.kombit.dk/P133/Integrationsbeskrivelser/Forms/Grp%20snitfladengler%20Release.aspx

[WSDL-EXT] SocialPensionHent_UDK.r1672.zip Se gældende version af [Bilag]

[Hovedoplysninger]

Transaktionsspor og Fejlbehandling ved servicekald.docx

https://share-komm.kombit.dk/P133/_layouts/15/start.aspx#/Referencedokumenter/Forms/Samlet.aspx

Den generelle guideline for transaktionsspor og fejlbehandling.

[Map] Samlivsmapning v1.0 Se gældende version af [Bilag]

Mapning mellem UDK PE, KMD SP og KMD SPK interimsløsning (8.1)

[Sagsomraade] SF1411_A SagsomraadeKoder og datastrukturer v1.1 Se gældende version af [Bilag]

Tildelte sagsområdekoder med tilhørende dataafgrænsning

[SF1411_A]

[SF1411_A_V3] [SF1411_B] [SF1411_D] [SF1411_D_V3]

[SF1411_E]

SF1411_X Integrationsbeskrivelserne for de relaterede integrationer vedr. social pension ligger på https://share-komm.kombit.dk/P133/Integrationsbeskrivelser/Forms/Grp%20snitfladengler%20Release.aspx såfremt de udstilles som services på Serviceplatformen. Pt. er der ikke planer om at udstille SF1411_A og SF1411_D.

De seks beskrivelser om social pension er indbyrdes afhængige og bør læses i sammenhæng.

[GVF] Reference til Generelle vilkår og forudsætninger, der skal være på plads før Snitflader kan anvendes:

Filen ”Generelle vilkår og forudsætninger.pdf”, som ligger her:

https://share-komm.kombit.dk/P133/Referencedokumenter

[KDIDrift] Hjemmeside med informationer om drift og forvaltning af KDIs Services

https://www.kombit.dk/indhold/drift-og-forvaltning-af-kdis-services

[KDITest] Hjemmeside med informationer om ibrugtagning og test af KDIs Services:

https://www.kombit.dk/indhold/hj%C3%A6lp-til-test-og-ibrugtagning-kdi

https://share-komm.kombit.dk/P133/Integrationsbeskrivelser/Forms/Grp%20snitfladengler%20Release.aspx









https://share-komm.kombit.dk/P133/Referencedokumenter







Indholdsfortegnelse

1 Overordnet beskrivelse ............................................................................................ 5

1.1 Integrationens formål ........................................................................................ 5

1.2 Overordnet forretningsflow i integrationen ............................................................ 8

1.3 Servicebetingelser for den samlede integration ..................................................... 9

1.4 Teststrategi .................................................................................................... 10

1.5 Forudsætninger for produktionssætning af integration social pension ..................... 10

2 Kontekst for integrationsparter ............................................................................... 12

2.1 Kontekst for KY (ydelsessystem) ....................................................................... 12

2.2 Kontekst for KMD Social Pension Kommunedel .................................................... 14

2.3 Kontekst for Social Pension Kommune ............................................................... 17

2.4 Kontekst for KMD Structura (ejendomsskattelånsystemet) ................................... 19

2.5 Kontekst for UDK Pension ................................................................................. 21

3 Specifikation for integrationsparter .......................................................................... 23

3.1 Specifikation af endpoints for KMD Social Pension Kommunedel, Social Pension

Kommune, KY og KMD Structura .................................................................................. 23

3.2 Specifikation af endpoints for UDK Pension ......................................................... 44

4 Beskrivelse for integrationsplatforme ....................................................................... 47

4.1 Beskrivelse for Serviceplatformen...................................................................... 47



1 Overordnet beskrivelse

1.1 Integrationens formål

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.

Informationerne kommer fra UDK Pension (UDK PE). Integrationen benyttes af fagsystemerne KMD Social

Pension Kommunedel, det kommende Social Pension Kommune (SPK), Kommunernes Ydelsessystem (KY)

og KMD Structura.

Informationerne i denne snitflade bliver indtil ibrugtagningen af UDK PE udstillet af KMD Social Pension

(KMD SOP). Dette er beskrevet i SF1411_A Hent informationer om social pension v2 (se også afsnittet

’Sammenhæng til andre snitflader’).

Servicen SF1411_A_V3, som er beskrevet i dette dokument, aktiveres ved ibrugtagningen af UDK Pension.

1.1.1 Sammenhæng til andre snitflader

I forbindelse med monopolbruddet sker der en løbende udskiftning af det nuværende pensionssystem KMD

Social Pension. KMD Social Pension består af to dele: KMD Social Pension Kommunedel, som varetager

systemunderstøttelsen af de kommunale opgaver, og KMD Social Pension UDK-del, som varetager

systemunderstøttelsen af opgaver for UDK. KMD Social Pension Kommunedel erstattes fremadrettet af

Social Pension Kommune og KMD Social Pension UDK-del erstattes af UDK Pension.

Dette afsnit giver en introduktion til den samlede løsning for området social pension og sammenhængen

mellem integrationerne. Det er en fælles tekst, som går igen i alle integrationsbeskrivelser, der omhandler

social pension (SF1411). Følgende integrationsbeskrivelser indgår i gruppen:



• SF1411_A – Hent informationer om social pension [SF1411_A]

• SF1411_A_V3 – Hent informationer om social pension [SF1411_A_V3]

• SF1411_B – Hent helbredsprocent [SF1411_B]

• SF1411_D – Besked om informationer om social pension [SF1411] – SKAL PT. IKKE BRUGES

• SF1411_D_V3 – Besked om informationer om social pension [SF1411_D_V3]

• SF1411_E – Besked om helbredsprocent [SF1411_E]

Formålet med gruppen af snitflader er at udveksle informationer om social pension samt ændringer i

informationer om social pension. Informationerne udveksles mellem fagsystemer (f.eks. Kommunernes

Ydelsessystem – herefter KY) og de tre pensionssystemer KMD Social Pension, UDK Pension og Social

Pension Kommune (andre systemer kan komme til).

Serviceplatformen samt fag- og pensionssystemernes snitflader til støttesystemet Beskedfordeler (herefter:

Beskedfordeler) beskrives i følgende integrationsbeskrivelser:

• SF1460_A – Modtag besked [SF1460_A]

• SF1460_B – Vedligeholde værdiliste i beskedabonnement [SF1460_B]

• SF1460_C – Aflever besked [SF1460_C]

• SF1460_D – Modtag besked via pull [SF1460_D]

Transitionen består af fire faser, som er beskrevet nedenfor. Forventet tidsplan for de to nye

pensionssystemer kan ses på https://www.kombit.dk/monopolbrudstidsplan.

Nuværende: Begge snitflader er udstillet af KMD Social Pension

Data udstilles af det nuværende pensionssystem, KMD Social Pension.

KMD Social Pension udstiller:

• SF1411_A – Hent informationer om social pension [SF1411_A]


• SF1411_D – Besked om informationer om social pension [SF1411_D] – forventes ikke idriftsat


UDK Pension idriftsættes – big bang med ibrugtagning af UDK PE og nedlukning af KMD Social Pension på

samme tid

UDK Pension idriftsættes og afløser KMD Social Pension. Den kommunale del af løsningen kører videre hos

KMD i en interimsløsning.

UDK Pension udstiller:





KMD Social Pension interim udstiller:



Social Pension Kommune idriftsættes – big bang med ibrugtagning af Social Pension Kommune og

nedlukning af KMD Social Pension Kommune på samme tid (forventet)

Social Pension Kommune idriftsættes og afløser KMD Social Pension interim.




Social Pension Kommune udstiller:



Målarkitektur: UDK Pension og Social Pension Kommune

De to nye pensionssystemer er taget i brug. Det forventes, at de to services udstillet af UDK Pension

tilpasses den ønskede målarkitektur og udgives som en ny version af servicen, V4.




Social Pension Kommune udstiller følgende for migrerede kommuner:





1.2 Overordnet forretningsflow i integrationen

Følgende forretningsflow indgår i integrationen:

IF01 – Hent oplysninger om social pension:

• Fagsystemet forespørger om informationer om social pension for en person via en synkron service

udstillet på Serviceplatformen.

• Serviceplatformen gennemstiller kaldet til en synkron service hos UDK Pension.

Integrationen er en gennemstillingsintegration.

Integrationens forretningsflow er illustreret på nedenstående diagram:

Fags

yste

m(n

)U

DK

Pe

nsi

on

Serv

ice

pla

tfo

rme

n

IF01 – Hent oplysninger om social pension

Hent oplysninger

EP_FS1

Send oplysninger

EP_UDK1

Gennemstilling



1.3 Servicebetingelser for den samlede integration

1.3.1 Servicemål

Parameter Flow IF01

Tidsrum Serviceplatformen driftsafvikles hele døgnet alle dage bortset fra når der udføres ændringer/hvor der er servicevinduer. UDKPE driftsafvikles hele døgnet alle dage bortset fra ved planlagte servicevinduer. SPK forventer, at servicen er tilgængelig inden for almindelig arbejdstid.

Svartid Serviceplatformen har forskellig SLA på svartid alt efter hvilken integrationskompleksitet, der er tale om: Simpel = 1 sekund (denne) Mellem = 1,5 sekund Kompleks = 4 sekunder UDKPE har målsat intern procestid på 1 sek. og maksimum 2 sek. Dertil kommer den tid, der anvendes af eksterne systemer, i transportlaget, etc. SPK forventer maks. 2 sek. svartid på den samlede integration.

Tilgængelighed Servicemålene for Serviceplatformen driftseffektivitet er 99,8% for perioden 06:00 -18:00 på arbejdsdage samt 98,5 % i den øvrige tid. Servicemålet for UDKPE’s tilgængelighed er 98,5 % inden for planlagt oppetid. SPK forventer, at servicen har samme oppetid som Serviceplatformen.

Spidsbelastningsperiode Spidsbelastningen for Serviceplatformen må antages at være i perioden 06:00 -18:00 på arbejdsdage. UDKPE’s forskellige moduler vil have forskellige spidsbelastningsperioder, så der kan ikke siges noget generelt.

Servicevinduer Ved mindre opdateringer for Serviceplatformen: En gang om ugen i tidsrummet 05:00 -06:00. Varsling: 1. uge, varighed (naturligvis) max en time. Ved større og kritiske opdateringer: Optil 1 gang om måneden i tidsrummet mandag kl. 03:00 til mandag kl. 06:00. Varsling: 1. uge, Varighed: max 3 timer Ved omlægning af miljøer, arkitektur og services for Serviceplatformen: 1 gang pr. kvartal i tidsrummet søndag kl. 22:00 til mandag kl. 06:00. Varsling 1. måned, varighed max 8 timer. Servicevinduer for UDKPE aftales mellem Netcompany og ATP udmeldes efter behov. De placeres udenfor Kritisk forretningstid, som er arbejdsdage fra kl. 06.00 til 22.00.



SPK forventer, servicevinduer udføres uden for almindelige arbejdstid.

1.3.2 Service Management

Informationer om driftsmeddelelser, forespørgsler og kontaktinformationer, findes på siden for Drift og

Forvaltning af KDIs Services her: [KDIDrift].

1.4 Teststrategi

Den planlagte test af services til installation på Serviceplatformen omfatter pt., at der udføres

automatiserede tests af services og unittests.

Der er tale om en robust test af sikkerhed, routing og anden kernefunktionalitet i integrationen, samt mere

en simpel test af, om de enkelte operationer kan benyttes, ”stikprøvekontrol’. Testen omfatter ikke

samtlige dataelementer i operationerne.

Leverandøren af Serviceplatformen er ansvarlig for denne test.

Det generelle udgangspunkt for KOMBITs teststrategi er, at alle involverede parter har gennemført en robust systemtest af egen løsning, før der gennemføres test parterne imellem. Generelle informationer om ibrugtagning og test, samt kontaktinformationer for specifikke ønsker, kan

findes via [KDITest].

1.5 Forudsætninger for produktionssætning af integration social pension

For at kunne anvende snitfladen er der en række vilkår og forudsætninger, som skal være opfyldt af den

integrationspart, der skal tilsluttes. Ved integrationspart skal forstås anvendersystemer, kildesystem osv.

Disse vilkår og forudsætninger er opdelt i en generelle vilkår og forudsætninger, som gælder på tværs af

snitfladerne og i specifikke vilkår og forudsætninger for tilslutning til selve snitfladen.

De generelle vilkår og forudsætninger er beskrevet i et samlet dokument [GVF], mens de specifikke

aktiviteter, der skal udføres som forudsætning for tilslutning af en integrationspart, er beskrevet for hver

enkelt integrationspart i kapitel 2

1.5.1 Køreplan for Implementering

Nedenstående diagram viser køreplanen for udrulningen, som anvendersystem inden for KOMBITs

rammearkitektur under monopolbrudsprojektet følger. Det væsentlige i køreplanen er faserne, mens en

egentlig tidsplan vil følge den faktiske implementeringsplan. Aktiviteter, som er forudsætninger og

betingelser i forbindelse med ibrugtagning af en snitflade, som følge af en udrulning af et anvendersystem,

vil referere til den fase, den hensigtsmæssigt kan udføres i.

Serviceplatformen: Ved idriftsættelse af en snitflade er alle aktiviteter afsluttet, og snitfladen er klar til

anvendelse.

Eksternt system: Alle aktiviteter i forhold til Serviceplatformen er afsluttet, men der kan være yderligere

aktiviteter i forbindelse med tilslutning af et anvendersystem eller en kommune i forhold til kildesystemet.



Anvender-/fagsystem og kommune: Ved tilslutning af et anvendersystem og/eller en kommune, er der en

række aktiviteter op til idriftsættelse, dels af aftalemæssig karakter, og dels også af konfigurationsmæssig

karakter, som skal udføres. Er der aktiviteter, som medfører konfiguration på Serviceplatformen, vil dette

ske i forbindelse med leverandørens oprettelse af serviceaftalen for kommunen.

1.5.2 Særlige vilkår

[Til brug for servicekataloget på Serviceplatformen er der behov for kort at beskrive vilkår der er specifikke

for den pågældende integration. Det vil typisk være indgåelse af aftale mellem anvendersystem og

kildesystem. Aftale inde for rammearkitekturen skal ikke beskrives.

Er der ingen specifikke vilkår for integrationen anvendes nedenstående tekst.

Vilkår for servicen Der er ingen specielle vilkår for brug af nærværende service ud over de generelle vilkår, der er beskrevet

under vilkår for hhv. leverandører og kommuner.]



2 Kontekst for integrationsparter

2.1 Kontekst for KY (ydelsessystem)

KY er datamodtager.

2.1.1 Lovhjemmel og forvaltningsmæssigt formål

Administration af en pensionists pension kan ske ud fra

• En frivillig aftale om administration

• En afgørelse truffet af kommunen om, hvordan pensionen skal udbetales

• En beslutning om iværksættelse af værgemål efter værgemålslovens § 5

Personkredsen

Afgørelsen kan træffes i forhold til personer, der modtager førtidspension eller folkepension efter lov om

social pension, § 36 og personer, der modtager førtidspension efter lov om højeste, mellemste, forhøjet

almindelig og almindelig førtidspension m.v. § 35 (førtidspensionsloven før 2003).

Når en pension skal administreres, giver kommunen Udbetaling Danmark (UDK) besked om aftalen eller

afgørelsen. UDK overfører herefter den pension, den pågældende skulle have haft udbetalt, til kommunen,

jf. § 36, stk. 3 i pensionsloven og § 35, stk. 3 førtidspensionsloven før 2003.

Aftale om administration

Hvis en pensionist ikke mener at kunne klare de praktiske opgaver, der er forbundet med at administrere

sin pension, kan pågældende indgå en aftale med kommunen om administration af pensionen, jf. § 36, stk.

2 i pensionsloven og § 35, stk. 2 i førtidspensionsloven før 2003.

Det aftales heri hvorledes administrationen skal foregå, fx

• Hvilke beløb der skal betales og hvortil

• Hvem der skal føre regnskab

• Hvem der har kompetence til at træffe de nødvendige beslutninger osv.

Lovhjemlen

• Lov om retssikkerhed og administration § 5, § 5 a og kap. 10.

• Lov om social pension § 36 og § 50.

• Lov om højeste, mellemste, forhøjet almindelig førtidspension m.v., § 35 og § 49

Det anførte hjemmelsgrundlag er bestemt af det enkelte og relevante fagprojekt i KOMBIT på

bestillingstidspunktet. Det er fastsat på baggrund af en rimelig og dækkende analyse. Henvisningen til

hjemmelsgrundlaget bliver ikke vedligeholdt, hvorfor KOMBIT naturligvis ikke kan indestå for, at denne

henvisnings indehold og retsvirkning til alle tider vil være korrekt. KOMBIT skal derfor understrege, at

læseren af dette dokument udelukkende skal læse hjemmelsgrundlaget som en orientering.



Det forvaltningsmæssige formål med integrationen er, at Kommunernes Ydelsessystem indhenter oplysninger, der påvirker udbetalinger for borgere under administration, så KY assistere pensionister, der er under administration.

2.1.2 Kapacitets- og servicekrav

Flowet IF01 har et forventet lavt antal transaktioner (ca. 1000 pr. måned, jævnt fordelt).

2.1.3 Specifikke forhold for tilslutning af system

Dette kapitel beskriver de opgaver, som skal gennemføres i relation til snitfladen, for at en kommune

gennem KY kan benytte snitfladen.

ID Aktivitet Opgave- kategori

Komponent Ansvarlig Udførende Fase og afhæn-gighed

Kommentar

TS101 Indgåelse af Dataudvekslingsaftale (Dataoverdragelsesaftale)

Aftale UDK (ATP som administrator) /Kommune

UDK UDK Fase 1 Direkte relateret til TS201, TS301 og TS401

Aftale er indgået. Samme aftale som for SF1411_D

TS105 Indgåelse af Databehandleraftale

Aftale UDK/KOMBIT

UDK KOMBIT Fase 1 Direkte relateret til TS207, TS303 og TS405

Samme aftale som for SF1411_D

TS106 Indgåelse af aftale om dataafgrænsning

Aftale KY UDK UDK Fase 1 Direkte relateret til TS305

TS102 Anmodning om Serviceaftale

Konfigura-tion

Administra-tionsmodul

Leveran-døren af fagsystem


Fase 2.2

TS103 Godkendelse af serviceaftale

Konfigura-tion

Administrationsmodul

Kommune Kommune Fase 2.2

TS104 Initialload af sager

Migrering KY Leveran-døren af fagsystem


Fase 2.3

TS101 - Kommunerne skal indgå Dataudvekslingsaftale med UDK. Dataudvekslingen er en generel rammeaftale mellem UDK og Kommunen med baggrund i UDK loven. Der er tale om en overdragelse af data fra en myndighed til en anden. Aftalen er allerede indgået.

TS105 - KOMBIT skal indgå databehandleraftaler med UDK vedrørende behandling af UDKs data i den fælleskommunale infrastruktur. Der er tale om behandling af personfølsomme data.



Der indgås en databehandleraftale pr. løsning, da der er en under-underdatabehandler pr. løsning. Der skal derfor indgået en aftale i forhold til behandling af data på Serviceplatformen og en for behandlingen i støttesystemerne. UDK er dataejer, ATP er databehandler, KOMBIT er underdatabehandler og leverandøren er under-underdatabehandler. Det er UDK, som dataansvarlig, der har ansvaret for at udarbejde aftalen. KOMBIT skal kun tiltræde. Parterne er dog enige om, at aftalen tager udgangspunkt i KOMBITs skabelon.

TS106 KY og UDK skal indgå aftale om, hvilke data KY skal modtage jf. KY lovgrundlag. Aftalen medfører dataafgrænsning på den sagsområdekode, der tildeles KY. Sagsområdekoden skal indgå i KYs forespørgsler mod UDK PE.

TS102 - Leverandøren skal anmode om indgåelse af serviceaftale for de Kommuner og

myndigheder, der skal bruge servicen, i rammearkitekturens administrationsmodul, og

myndigheden skal godkende denne anmodning jf. Vilkår for anvendelse af

sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed].

Det kan antages at KY allerede er tilsluttet STS og Serviceplatformen, og derfor kan

serviceaftalen umiddelbart konfigureres i Administrationsportalen.

TS103 - Kommune skal godkende ovenstående serviceaftale.

TS104 - KY skal i forbindelse med idriftsættelse hente information i UDK PE på eksisterende sager.

2.2 Kontekst for KMD Social Pension Kommunedel

KMD Social Pension Kommunedel er datamodtager.


Udbetaling Danmark loven §8:

§ 8. Udbetaling Danmark og kommunen har til brug for vurdering af, om oplysningen skal videregives til den

anden myndighed, jf. §§ 6, 7 og 9, og til brug for myndighedsopgaver efter den sociale og den

beskæftigelsesmæssige lovgivning terminaladgang til et register med nødvendige oplysninger om, hvilke

typer af kontante ydelser og økonomiske tilskud borgeren har modtaget de seneste 3 måneder, samt

oplysninger om størrelsen på ydelsen og tilskuddet.

Stk. 2. Udbetaling Danmark og kommunen har terminaladgang til et register med nødvendige oplysninger

til brug for beregning af pension efter lov om social pension og lov om højeste, mellemste, forhøjet

almindelig og almindelig førtidspension m.v.

Stk. 3. Kommunerne og Udbetaling Danmark har pligt til at stille de nødvendige oplysninger efter stk. 1 og 2

til rådighed for de nævnte registre.








Det forvaltningsmæssige formål med integrationen er oplysning af sag i forbindelse med ansøgning om

helbredskort / helbredstillæg / personligt tillæg. Beregning af helbredsprocent. Styring af proces til Bistand

/ Plejetillæg. Opstart af sag ved afvisning af ansøgning om eller tildeling af brøkpension til folkepension.

Initiering af proces til bestemmelse af medfinansieringskommune for alle bevillinger med kommunal

medfinansiering (NB! Inkluderer medfinansiering via Ydelsesrefusion). Styring af proces for borger under

administration. Styring af proces for forskudsvise udlæg og øvrige kommunale træk. Styring af proces for

den kommunale førtidspensionssag. Generel rådgivning for pensionister. (Listen kan muligvis udvides

senere)

UDK skal henvise borgerne til kommunen ved spørgsmål om social pension. Kommunen skal derfor have de

datamæssige forudsætninger for at kunne foretage en helhedsorienteret vejledning.



2.2.3 KDISpecifikke forhold for tilslutning af system


gennem KMD Social Pension Kommunedel kan benytte snitfladen.



Kommentar


Aftale UDK/Kommune




Aftale UDK/KOMBIT



TS202 Verificer at instruks for databehandling er gældende og korrekt

Aftale KMD Social Pension Kommune-del

Kommune Leveran-døren af KMD Social Pension Kommune-del

Fase 2.1 Samme aftale som SF1411_D

TS203 Rekvirering af certifikat til tilslutning til

Koordina-tion

KMD Social Pension Kommune-del

KDI Leveran-døren af KMD Social Pension

Fase 2.1



Rammearkitektur

Kommune-del

TS204 Oprettelse i STS organisation

Konfigura-tion

STS Organisation

KDI Leveran-døren af KMD Social Pension Kommune-del

Fase 2.2 Konfiguration sker også i SF1411_B – TS


Konfigura-tion


KDI Leveran-døren af KMD Social Pension Kommune-del

Fase 2.2


Konfigura-tion



TS201 - Kommunerne skal indgå Dataudvekslingsaftale med UDK. Dataudvekslingen er en generel

aftale mellem UDK og Kommunen med baggrund i UDK loven. Aftalen er allerede indgået.

TS207 - KOMBIT skal indgå databehandleraftaler med UDK vedrørende udveksling af data i denne snitflade. Aftale har baggrund i UDK loven, og er en underaftale til den generelle dataudvekslingsaftale mellem UDK og Kommunerne. Det er UDK der har ansvaret for at udarbejde aftalen. KOMBIT skal kun tiltræde.

TS202 - Når en leverandør behandler personfølsomme data for en kommune, får denne leverandør rollen som databehandler. Der skal derfor både foreligge en databehandleraftale og en specifik instruks for håndtering, opbevaring og behandling af disse data fra kommunen. Når datamassen eller dataudvekslingen ændres, skal denne instruks gennemgås og opdateres, hvilket er tilfældet i forbindelse med integration via Serviceplatformen. Det er den dataansvarliges ansvar at sikre, at kommunen gennemgår og om nødvendigt opdaterer databehandler instruks eller aftale for leverandørens løsning. Efter 25. maj 2018 skal databehandleren dog være behjælpelig.

TS203 KMD Social Pension Kommunedel har valgt at tilsluttes sig KOMBITs rammearkitekturen med et VOCES eller FOCES certifikat. Såfremt KMD ikke allerede har et certifikat, som kan anvendes ved tilslutning af KMD Social Pension Kommunedel kan det bestilles hos NemID.

TS204 - KMD Social pension skal oprettes i STS Organisation, såfremt dette ikke allerede er sket.

TS205 - Leverandøren af anvendersystemet (KMD) skal anmode om indgåelse af serviceaftale for

de Kommuner og myndigheder, der skal bruge servicen, i rammearkitekturens

administrationsmodul, og myndigheden skal godkende denne anmodning jf. Vilkår for

anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed].

Serviceaftalen skal anvende det OCES certifikat, som KMD har registreret ved tilslutning

til Rammearkitekturen i Administrationsmodulet.




2.3 Kontekst for Social Pension Kommune

Social Pension Kommune er datamodtager.


Udbetaling Danmark loven §8:

§ 8. Udbetaling Danmark og kommunen har til brug for vurdering af, om oplysningen skal videregives til den

anden myndighed, jf. §§ 6, 7 og 9, og til brug for myndighedsopgaver efter den sociale og den

beskæftigelsesmæssige lovgivning terminaladgang til et register med nødvendige oplysninger om, hvilke

typer af kontante ydelser og økonomiske tilskud borgeren har modtaget de seneste 3 måneder, samt

oplysninger om størrelsen på ydelsen og tilskuddet.











Det forvaltningsmæssige formål med integrationen er oplysning af sag i forbindelse med ansøgning om

helbredskort / helbredstillæg / personligt tillæg. Beregning af helbredsprocent. Styring af proces til Bistand

/ Plejetillæg. Opstart af sag ved afvisning af ansøgning om eller tildeling af brøkpension til folkepension.

Initiering af proces til bestemmelse af medfinansieringskommune for alle bevillinger med kommunal

medfinansiering (NB! Inkluderer medfinansiering via Ydelsesrefusion). Styring af proces for borger under

administration. Styring af proces for forskudsvise udlæg og øvrige kommunale træk. Styring af proces for

den kommunale førtidspensionssag. Generel rådgivning for pensionister. (Listen kan muligvis udvides

senere)

UDK skal henvise borgerne til kommunen ved spørgsmål om social pension. Kommunen skal derfor have de

datamæssige forudsætninger for at kunne foretage en helhedsorienteret vejledning.







gennem Social Pension Kommune kan benytte snitfladen.



Kommentar






Aftale UDK/KOMBIT




Konfigura-tion




Fase 2.2


Konfigura-tion




Migrering KY Leveran-døren af fagsystem


Fase 2.3

TS401 - Kommunerne skal indgå Dataudvekslingsaftale med UDK. Dataudvekslingen er en generel

rammeaftale mellem UDK og Kommunen med baggrund i UDK loven. Der er tale om en

overdragelse af data fra en myndighed til en anden. Aftalen er allerede indgået.

TS405 - KOMBIT skal indgå databehandleraftaler med UDK vedrørende behandling af UDKs data i den fælleskommunale infrastruktur. Der er tale om behandling af personfølsomme data. Der indgås en databehandleraftale pr. løsning, da der er en under-underdatabehandler pr. løsning. Der skal derfor indgået en aftale i forhold til behandling af data på Serviceplatformen og en for behandlingen i støttesystemerne. UDK er dataejer, ATP er databehandler, KOMBIT er underdatabehandler og leverandøren er under-underdatabehandler. Det er UDK, som dataansvarlig, der har ansvaret for at udarbejde aftalen. KOMBIT skal kun tiltræde. Parterne er dog enige om, at aftalen tager udgangspunkt i KOMBITs skabelon.







Det kan antages at SPK allerede er tilsluttet STS og Serviceplatformen, og derfor kan

serviceaftalen umiddelbart konfigureres i Administrationsportalen.


TS404 - KY skal i forbindelse med idriftsættelse hente information i Social pension på eksisterende sager.

2.4 Kontekst for KMD Structura (ejendomsskattelånsystemet)

KMD Structura er datamodtager.


Kommunernes adgang til data findes i henhold til Bekendtgørelse af lov om lån til betaling af

ejendomsskatter § 1, stk. 4 (https://www.retsinformation.dk/Forms/R0710.aspx?id=158265)






Det forvaltningsmæssige formål med integrationen er at kunne tildele pensionister lån til betaling af ejendomsskatter. KMD Structura laver opslag på personniveau. KMD Structura bruger pensionstypen til at tildele lån til betaling af ejendomsskatter. Det er kun pensionister, der kan få lånet.





gennem KMD Structura kan benytte snitfladen.



Kommentar



UDK UDK Fase 1 Direkte relateret til TS101, TS201, TS301 og TS401



Aftale UDK/KOMBIT

UDK KOMBIT Fase 1 Direkte relateret til




TS101, TS207, TS303 og TS405


Aftale KMD Structura

UDK UDK Fase 1 Direkte relateret til TS305


Konfigura-tion




Fase 2.2


Konfigura-tion




Migrering KMD Structura



Fase 2.3

TS101 - Kommunerne skal indgå Dataudvekslingsaftale med UDK. Dataudvekslingen er en generel rammeaftale mellem UDK og Kommunen med baggrund i UDK loven. Der er tale om en overdragelse af data fra en myndighed til en anden. Aftalen er allerede indgået.

TS105 - KOMBIT skal indgå databehandleraftaler med UDK vedrørende behandling af UDKs data i den fælleskommunale infrastruktur. Der er tale om behandling af personfølsomme data. Der indgås en databehandleraftale pr. løsning, da der er en under-underdatabehandler pr. løsning. Der skal derfor indgået en aftale i forhold til behandling af data på Serviceplatformen og en for behandlingen i støttesystemerne. UDK er dataejer, ATP er databehandler, KOMBIT er underdatabehandler og leverandøren er under-underdatabehandler. Det er UDK, som dataansvarlig, der har ansvaret for at udarbejde aftalen. KOMBIT skal kun tiltræde. Parterne er dog enige om, at aftalen tager udgangspunkt i KOMBITs skabelon.

TS106 KMD Structura og UDK skal indgå aftale om, hvilke data KMD Structura skal modtage jf. KMD Structuras lovgrundlag. Aftalen medfører dataafgrænsning på den sagsområdekode, der tildeles KMD Structura. Sagsområdekoden skal indgå i KMD Structuras forespørgsler mod UDK PE.






TS104 - KMD Structura skal i forbindelse med idriftsættelse hente information i UDK PE på eksisterende sager.



2.5 Kontekst for UDK Pension

UDK Pension er dataleverandør.


I henhold til lov om Udbetaling Danmark kapitel 3 §8 Stk. 2 og 3.











Det forvaltningsmæssige formål med integrationen er at udstille nødvendige oplysninger til brug for

kommunens afgørelser og vejledning vedrørende ydelser under loven om social pension.


Flowet IF01 har et forventet lavt antal transaktioner (ca. 9000 pr. måned, hvilket er det totale antal

transaktioner i flowet).


Dette kapitel beskriver de opgaver, som skal gennemføres i relation til snitfladen for KMD Social pension,

for at en kommune gennem et anvendersystem kan benytte snitfladen.



Kommentar

TS301 Indgåelse af Dataudvekslingsaftale(Dataoverdragelsesaftale)

Aftale UDK Pension




Aftale UDK Pension

UDK KOMBIT Fase 1 Direkte relateret til TS105,




TS207 og TS405

TS304 Verificer at instruks for databehandling er gældende og korrekt

Aftale UDK Pension

UDK Leveran-døren af UDK Pension

Fase 2.1 Samme aftale som SF1411_D


Aftale UDK UDK UDK Fase 1 Direkte relateret til TS106

TS301 - UDK skal indgå Dataudvekslingsaftale med Kommunerne. Dataudvekslingen er en generel aftale mellem UDK og Kommunen med baggrund i UDK loven. Aftalen er allerede indgået.

TS303 - UDK skal indgå databehandleraftaler med KOMBIT vedrørende behandling af personfølsomme data i løsningerne i den fælleskommunale infrastruktur, Serviceplatformen og støttesystemerne. Det er UDK, der som dataansvarlig, er ansvarlig for at udarbejde aftalen. KOMBIT skal kun tiltræde. Faktuelt er parterne dog enige om, at benytte KOMBITs aftaleskabelon, hvorfor KOMBIT er udførende. Der indgås en aftale pr. løsning, da løsningerne har forskellige under-underdatabehandlere. UDK er dataansvarlig, ATP er databehandler, KOMBIT er underdatabehandler og leverandøren er under-underdatabehandler.

TS304 - Når en leverandør behandler personfølsomme data for UDK, skal der foreligge en databehandleraftale mellem parterne med en specifik instruks for håndtering, opbevaring og behandling af disse data for UDK. Når datamassen eller dataudvekslingen ændres, skal denne instruks gennemgås og opdateres, hvilket er tilfældet i forbindelse med integration via Serviceplatformen. Det er den dataansvarlige ansvar, at sikre denne opdatering. Databehandler har dog fra en den 25. maj 2018 et ansvar for at rådgive den dataansvarlige.

TS305 KY og UDK skal indgå aftale om, hvilke data KY skal modtage jf. KY lovgrundlag. Aftalen medfører dataafgrænsning på den sagsområdekode, der tildeles KY. UDK skal implementere et filter, der håndhæver dataafgrænsningen.



3 Specifikation for integrationsparter

3.1 Specifikation af endpoints for KMD Social Pension Kommunedel, Social Pension Kommune, KY og KMD Structura

Integrationen benyttes til at udstille en service på Serviceplatformen, således at fagsystemet kan foretage

et opslag på informationer om social pension for en person.

3.1.1 Overordnet forretningslogik

Fagsystemet kalder Serviceplatformen, som udstiller en synkron service, der udstiller informationer om

social pension for en given person:

1. Fagsystemet kalder EP_FS1

2. Serviceplatformen returnerer et synkront svar til fagsystemet

3.1.2 Oversigt over endpoints

ID Navn Reference til wsdl Servicenavn på Serviceplatformen

Version på Serviceplatformen

EP_FS1

SocialPensionHent [WSDL-SP] Servicenavn: SocialPensionHentService_3 Operationsnavn: SocialPensionHent

SocialPensionHent [KDI indsæt efter leverance fra SSE]

3.1.3 Beskrivelse af endpoint [EP_FS1] – SocialPensionHent

3.1.3.1 Transportspecifikation

3.1.3.1.1 Integrationsmønster

Integrationen er en synkron web service udstillet af Serviceplatformen og kaldt af fagsystemer.

3.1.3.1.2 Serviceudstiller

Serviceplatformen er serviceudstiller.

3.1.3.1.3 Serviceanvender

Fagsystemet er serviceanvender.

3.1.3.1.4 Teknologisk understøttelse

Snitfladen udstilles som en SOAP 1.1 web service.

3.1.3.1.5 Teknisk endpoint

Oplysninger om endpoint er angivet i tabellen i afsnit Fejl! Henvisningskilde ikke fundet..



3.1.3.1.6 Teknisk retning for udveksling

Fagsystemet kalder service udstillet på Serviceplatformen.

3.1.3.1.7 Dataretning for udveksling

Serviceplatformen udstiller data fra UDK Pension.

3.1.3.1.8 Service invokation / Triggers

Endpoint kaldes af fagsystemet, når der opstår behov for at få oplysninger om en persons social

pensionssag f.eks. i forbindelse med udregning af helbredsprocent.

3.1.3.2 Dataspecifikation

3.1.3.2.1 Forespørgsler

Der forespørges på informationer om social pension for én person ad gangen. Forespørgsler sker med

nedenstående input parametre til webservicen.

Hovedoplysninger:

Fagsystemet skal udfylde og håndtere HovedOplysninger som beskrevet i afsnit ’2.1 Transaktionsspor’ for

synkrone kald og ’2.2 Kaldskontekst’ for rollen ”Kalder” (og ”anvender”) i [Hovedoplysninger]. UDK PE skal

håndtere oplysningerne som angivet for rolle ”Serviceudstiller”/”Udstiller”.

Følgende felter skal udfyldes:

Feltnavn Type Beskrivelse

TransaktionsId string UUID som udstedes af fagsystemet.

TransaktionsTid dateTime Kaldstidspunktet.



AuthorityContext CVRNummer Udfyldes med CVR-nummer for den myndighed, der kaldes i kontekst af. Feltet udfyldes kun, hvis kalder benytter certifikat i kaldet.

Se i øvrigt afsnit Fejl! Henvisningskilde ikke fundet. og [STS-Sikkerhed].

CallContext og Request:

CallerServiceCallerIdentifier skal altid udfyldes af fagsystemet. De andre felter i CallContext bruges pt. ikke.


OnBehalfOfUser string Udfyldes ikke.

CallerServiceCallerIdentifier string Samme værdi som i HovedOplysninger:TransaktionsId.

AccountingInfo string Udfyldes ikke.

Alle felter i Request skal udfyldes.


ID URN Pensionistens CPR-nr:”urn:oio:cpr-nr:nnnnnnnnnn”

FraTidspunkt dateTime bool

Se beskrivelse nedenfor

TilTidspunkt dateTime bool

Se beskrivelse nedenfor

Myndighed (ReferenceID) URN Udfyldes med forespørgende kommunes cvr-nummer eller myndighedskode (kommunekode): ’’urn:oio:cvr-nr:nnnnnnnn’’ ”urn:oio:kombit:myndighedkode:nnnn”



Det er forespørgende kommunes ansvar at sikre, der er hjemmel til forespørgslen. Myndighedskode som defineret i CPR af Indenrigsministeriet.

SagsomraadeKode String Fagsystemet tildeles en SagsomraadeKode ifm. indgåelse af aftale om brug af servicen. Informationen bruges til dataafgrænsning jf. lovhjemmel angivet i afsnit Fejl! Henvisningskilde ikke fundet.. Dataafgrænsningen sker i kildesystemet. Opslag i relation til ’Social pension’ skal indeholde koden ”Pension”. Opslag i relation til ’Udbetalinger under administration’ skal indeholde koden ”UdbetalingerUnderAdm”. Opslag i relation til ’Ejendomsskattelån’ skal indeholde koden ”Ejendomsskattelån”. Se [Sagsomraade] for sammenhæng mellem sagsområdekoder og felter relateret til sagsområdet.

Der forespørges og returneres oplysninger om pensionister på personniveau - dvs. uafhængigt af

sagsbegrebet i UDK PE. Hvis personen ikke har en sag i UDK PE, eller hvis personen kun har været

international pensionist, returneres en response-kode 100 = "OK. Ingen sag fundet". Hvis der spørges på en

død eller forsvundet person, svares som normalt.

Datosøgning sker i henhold til OIO:

• Der returneres alle de virkninger, der er i søgeperiodens datointerval

• Startdato er inklusive og slutdato er eksklusive

• Der returneres alle virkninger, der slutter på eller efter startdato og starter før slutdato

• Hvis startdato udelades eller sættes til ”true” returneres alt fra minus uendelig

• Hvis slutdato udelades eller sættes til ”true” returneres alt til plus uendelig

• Hvis begge datoer udelades returneres kun virkning her-og-nu

• Hvis begge datoer sættes til ”true” returneres samtlige virkninger

I UDKPE fremfindes alle virkningsperioder, som ligger indenfor det angivne tidsinterval. Der returneres dog

kun oplysninger om den "pensionistkategori", som personen pt. tilhører. Med "Pensionistkategori" forstås

følgende:

• FØP, hvis der er en aktiv FØP eller IY-sag

• FOP, hvis der en FOP eller udskudt FOP sag, og personen ikke stadig er FØP'er.

Dvs. hvis borger er FOP'er på forespørgselstidspunktet, men tidligere har været FØP'er, returneres kun

oplysninger om FOP-sagen/sagerne, men ikke oplysninger om FØP-sagen/sagerne, selvom

forespørgselsperioden omfatter FØP-tiden.



Der returneres altid kun seneste registrering af oplysningerne.

3.1.3.2.2 Svar

Servicen returnerer information om social pension for én person ad gangen. Omfanget af registreringer på

sagen afhænger af datointervallet, der er søgt på i forespørgslen.

Omfanget af data, der kan ses hos modtageren, skal afgrænses på baggrund af den SagsområdeKode, der er

indsendt i forespørgslen (se afsnit Fejl! Henvisningskilde ikke fundet.).

HovedOplysningerSvar:

UDK PE skal udfylde og håndtere HovedOplysningerSvar som beskrevet i afsnit 2.1 ’Transaktionsspor’ for

synkrone kald og 2.3 ’Fejlhåndtering’ for rollen ”Serviceudstiller”/”Udstiller” i [Hovedoplysninger].

Fagsystemet skal håndtere oplysningerne som angivet for rollen ”Kalder”.

Følgende felter skal udfyldes:


TransaktionsId string Udstedes af kalder. UDK PE indsætter UUID fra HovedOplysninger.

TransaktionsTid dateTime Udstedes af kalder. UDK PE indsætter tidspunkt fra HovedOplysninger.

AdvisId/FejlId string Se tabel i afsnit Fejl! Henvisningskilde ikke fundet..

AdvisTekst/FejlTekst string Se tabel i afsnit Fejl! Henvisningskilde ikke fundet..

KildeId string UUID for UDK PE.

HeaderResponseStructure og PSag:



Det forretningsmæssige indhold i HeaderResponseStructure skal svarer til indholdet i

HovedOplysningerSvar. Dvs. de samme værdier sendes to gange i svaret til fagsystemet. Dog udfyldes

ReturnMessage også ved positivt svar.


RequestResponseIdentifier string Samme værdi som i HovedOplysningerSvar:TransaktionsId.

ResponseGenerationDateTime dateTime Samme værdi som i HovedOplysningerSvar:TransaktionsTid.

ResponseReturnIdentifier string Se tabel i afsnit Fejl! Henvisningskilde ikke fundet..

ResponseReasonIdentifier string Se tabel i afsnit Fejl! Henvisningskilde ikke fundet.. Ved fejl (værdi≠0) sendes samme værdi som i HovedOplysningerSvar:SvarReaktion

ResponseReasonText string Se tabel i afsnit Fejl! Henvisningskilde ikke fundet.. Ved fejl (værdi≠0) sendes samme værdi som i HovedOplysningerSvar:SvarReaktion

PSag indeholder det forretningsmæssige svar på forespørgslen. Strukturen indeholder en AttributListe,

TilstandListe og RelationListe, som udgør OIOs generelle objektdele.

PSag-strukturen er optionel og sendes ikke med i svaret ifm. fejl.




ID UUID/ URN

Sagens unikke identifikation i det system, der udstiller servicen. Vil svare til det UUID, der identificerer sagen i Sagsindekset. UDK PE: URN med følgende indhold (Hovedsagen): urn:oio:udk:sag:leverandoer_coid_sagsnoegle:nnnnnnnnnnnnnnnnnnnnnnn OBS! Dette sagsID kan skifte over tid, hvis hovedsagen hos UDK PE ændres.

NoteTekst string Note tilknyttet registreringen (ren tekst), hvis der findes en sådan. UDK PE: Udfyldes ikke.

Tidspunkt dateTime Udfyldes med tidsstempel for ændring hhv. oprettelse af sagsobjektet. Tidsstemplet udfyldes med seneste registreringstidspunkt for pensionistens hovedsag i UDK PE.

LivscyklusKode string Udfyldes med ”Oprettet” (Ny sag) eller ”Rettet” (Ændret sag). UDK PE: Udfyldes altid med ”Rettet”.

BrugerRef UUID/ URN

Udfyldes med bruger, der har ændret eller oprettet sagen, hvis kendt. Brug af UUID vil kræve at denne er oprettet som Bruger-aktør i STS-Organisation. UDK PE: Udfyldes ikke.

AttributListe Se nedenfor

TilstandListe Se nedenfor

RelationListe Se nedenfor

Denne definition er fælles for alle virkninger, og beskrives derfor kun her. Virkninger returneres, hvis de

helt eller delvist har gyldighed inden for de datoer, der søges på. Dvs. søgning fra < TilTidspunkt og søgning

til >= FraTidspunkt.

Flere instanser af virkninger for et element må ikke overlappe i tid, da det ellers ikke er muligt entydigt at

bestemme, hvad der er gældende til et givet tidspunkt.




FraTidspunkt dateTime bool

Dato (og eventuel tid) for virkningens start. Tidspunkt er inklusive. Hvis værdien udelades eller GraenseIndikator sættes til ”true” antages uendelig fra.

TilTidspunkt dateTime bool

Dato (og eventuel tid) for virkningens slut. Tidspunkt er eksklusive – OBS! Hvis kun dato er udfyldt, skal det være dagen efter sidste dag. Hvis værdien udelades eller GraenseIndikator sættes til ”true” antages uendelig til. Hvis TilTidspunkt angives som dato(/tid) skal det være større end (dvs. efter) FraTidspunkt

AktoerRef Udfyldes med bruger, der har ændret eller oprettet sagen hvis kendt "urn:oio:objekttype:KSPID:<RACFID>" UDK PE: Udfyldes ikke.

AktoerType Kode

string Udfyldes med ”Bruger” hvis ”AktoerRef” er angivet UDK PE: Udfyldes ikke.

NoteTekst URN Udfyldes ikke

TilstandListe:


FremdriftStatus Kode

string Udfyldes med sagens status i henhold til OIO-Sag: (Mappes bedst muligt til sagsstatus i systemet) ”Opstået”: Noget kræver myndighedens ageren. ”Oplyst”: Sagen er fuldt oplyst. ”Afgjort”: Der er truffet afgørelse om sagen, fx bevilling eller afslag. Der må ikke tilføjes mere til sagen. ”Bestilt”: Indsats, betalingsrække etc. er bestilt hos udfører. ”Udført”: Det bestilte er udført. ”Afsluttet”: Sagsbehandling er fuldført. UDK PE: Det er den aktuelle hovedsags fremdrift, som returneres. Udfyldes med ”Opstået”, ”Afgjort” og ”Afsluttet”.

Fremdriftskode ”opstået”:

• Benyttes generelt fra oprettelse af sagen indtil den er afgjort

• Benyttes hvis sagen ryger til manuel behandling (ved ikke automatisk tilkendelse af pension)

• Benyttes hvis en opgave går i et ”ventetrin” der afventer en fremtidig dato før sagen viderebehandles

• Benyttes hvis sagen afventer en borger, dvs. der er udsendt en anmodning om oplysninger, og der endnu ikke er modtaget svar



Fremdriftskode ”afgjort”:

• Benyttes når sagen afgøres med afgørelsestype BEVILLING.

• Benyttes når sagen afgøres med afgørelsestype AFSLAG.

Fremdriftskode ”afsluttet”:

• Benyttes når sagen er stoppet.

Der returneres alle virkningsperioder med forskellig FremdriftStatusKode for hovedsagen indenfor det

forespurgte tidsinterval. Virkningsperioderne dækker de tidspunkter, hvor hovedsagen har haft den givne

fremdrift i UDKPE. For en FØP-sag vil starttidspunktet for fremdrift Afgjort således ikke nødvendigvis være

det samme som det tidspunkt, hvor FØP'en er tilkendt i kommunen.

AttributListe:

Egenskaber beskriver generelle attributter for pensionssagen.




Brugervendt Noegle

string Udfyldes med den nøgleværdi der anvendes i præsentationen (f.eks. sagsnummer) UDK PE: Udfyldes ikke

Afgørelsen udgør information om, hvilken afgørelse der er truffet på sagen: Er den bevilget eller afslået?

Der returneres den afgørelse, som knytter sig til personens hovedsag og "hovedydelse". Hvis hovedsagen

endnu ikke er afgjort, returneres dette element ikke.


AfslaaetDato dateTime Den dato hvor at afslag er sket.

ForudBagud Kode

string Markering for om udbetaling af pensionen er forud eller bagudrettet jf. effektueringsplanen. Udfyldes med ”Forud” eller ”Bagud”.

BistandPleje Kode

string+ string

Udfyldes med en af følgende (Kode, Tekst): - ”Plejetillæg”, ”Plejetillæg” - ”Bistandstillæg”, ”Bistandstillæg”

Returneres kun, hvis "hovedsagen" har eller har haft en bevilget ydelse af typen Bistandstillæg eller Plejetillæg indenfor søgeperioden. Hvis "hovedsagen" har en bevilget ydelse af typen Bistandstillæg returneres "Bistandstillæg". Hvis "hovedsagen" har en bevilget ydelse af typer Plejetillæg, returneres "Plejetillæg".

PensionsStatus Kode

string Status for pensionsbevillingen: ”Aktiv” (Der udbetales i henhold til plan) ”Inaktiv” (Der udbetales ikke - Sat på pause) ”Stoppet” (Alle ydelser er udbetalt, og der er ikke planlagt flere udbetalinger) Hvis hovedsagens fremdrift er Afgjort, og sagen ikke er sat i bero, returneres "Aktiv" Hvis hovedsagens fremdrift er Afgjort, men sagen er sat i bero, returneres "Inaktiv". Denne status vil skulle anvendes ved f.eks. udskudt pension, fængselsophold og forsvundet borger. Hvis hovedsagens fremdrift er Afsluttet, returneres "Stoppet".



Der returneres kun virkningsperioder for hovedsagen.

Disse elementer beskriver detaljer omkring bevillingen.




FormueDel (SamletFormue)

Gruppe Formuen udfyldes med pensionistens konkluderede formuegrundlag. Hvis der ikke er en konkluderet formue, returneres 0 med formueType=Uoplyst. Der returneres både en samlet formue og de enkelte formuedele. Hvis pensionisten er samlevende, og der derfor er fælles formuegrundlag, vil den oplyste samlede formue være en fælles formue. I de enkelte formuedele vil der dog fortsat kun blive oplyst individuel formue. I dette tilfælde kan den samlede formue altså være forskellig fra summen af formuedelene.

FormueType string Der anvendes følgende formuetyper: - Uoplyst: Angiver at der ikke er en konkluderet formue for perioden. - Samlet_likvid_formue: Det samlede formuegrundlag. Hvis pensionisten er samlevende, er der tale om en samlet fælles formue. - Indestaaende_pengeinstitut: Formuedel - Kursvaerdi_af_obligationer: Formuedel - Pantebreve_i_depot: Formuedel - Aktie_og_investeringsbeviser: Formuedel - Kontantbeholdning: Formuedel - Andre_vaerdipapirer_kursvaerdi: Formuedel - Ubrugt_raadighed_nedsparing: Formuedel - Fradrag_formue: Formuedel - Anden_formue: Formuedel - Indefrosset_grundskyld: Formuedel Bemærk at indestående i pengeinstitut vil være fratrukket december måneds pensioner, når formuen er opgjort på baggrund af årsopgørelsen.

FormueBeloeb Komma decimal evt. med fortegn

Angivelse af formuebeløbet for den tilhørende FormueType. For den samlede likvide formue vil der være tale om en individuel formue, hvis pensionisten er enlig, og en fælles formue, hvis pensionisten er samlevende (både S-, O- og Z-samlevende), gift eller modtager efterlevelsespension. For alle de øvrige formuetyper er der tale om individuelle formuer.

TillaegsProcent Heltal Personlig tillægsprocent. Værdisæt: 0-100. Returneres, hvis pensionistens tillægsprocent er fastsat, ellers udelades elementet (hvis sagen endnu ikke er afgjort).

BroekTaeller Heltal Antal år med optjening. Værdisæt: 0-40. For fuld pension angives 40.

BroekNaevner Heltal Maks antal år (Konstant 40). Skal være > 0.



ProcentPension Heltal Brøkpension vil jf. 2025 planen blive defineret i % for nye pensionister fremfor i dag som en brøk. dvs. at der skal kunne angives en procentsats, som angiver hvor lang tid borger har været i landet i forhold til beregning af Pension. De nuværende pensionister fastholder deres Brøkpension. Dvs. at snitfladen skal både kunne håndtere Brøk og Procent.”

Ophold Landekode

string Landekode for ophold i henhold til ISO-3166-Alpha2 standard. Kun opholdsperioder uden for Danmark angives her

UDKAnsoegAccept bool Feltet kan udfyldes på tre måder: - Hvis ”true” har borgeren accepteret at UDK indhenter pension fra udenlandsk myndighed. ”UdlandsPension” vil da indeholde det beløb der er indhentet (såfremt det var muligt) - Hvis ”false” har borgeren afvist at UDK skal indhente pensionen fra udenlandsk myndighed - Hvis udeladt har UDK ikke mulighed for at indhente pensionen fra det pågældende land på borgerens vegne.

Landekode string Landekode for det land, der modtages pension fra i henhold til ISO-3166-Alpha2 standard.

Valuta string Angiver den valuta beløbet udbetales i (hvis udeladt antages DKK)

Beloeb Heltal/ Komma decimal evt. med fortegn

Angiver det beløb der udbetales pr. måned. Beløbet kan enten angives pr. land eller med et samlet beløb for alle lande. Hvis beløbet angives pr. land, skal der udfyldes en struktur pr. land.

TraekPct Heltal Angiver den trækprocent, der anvendes ved beregning af A-skat i forbindelse med pensionsudbetalingen. Værdisæt: 0-100.

FradragMaaned Heltal/ Komma decimal evt. med fortegn

Angiver det månedlige fradrag, der anvendes ved beregning af A-skat i forbindelse med pensionsudbetalingen. Hvis der anvendes bikort udelades månedsfradraget. Hvis der benyttes frikort, vil fradrag udgøre frikortets skattefri del. Dette skal hver måned reduceres med den udbetalte pension (angives via virkning)

Administration Bool

bool Angiver om pensionen leveres i henhold til administrationsaftale. Værdisæt: ”true”, ”false”.

Udbetalingskonto string Angiver om administrationsbeløbet overføres til kommunens NemKonto (udfyldes med "kommune"), eller til en specifik konto, som borgeren er tilknyttet i NemKonto ("specifik")”. Værdisæt: ”kommune”, ”specifik”.



PSagsAktoer indeholder oplysninger om myndighederne relateret til pensionssagen.

Der udfyldes op til 4 instanser af sagsaktører (Psagsaktoer): Ejer, Bopælskommune, Bevillingskommune og

Administrationskommune.

• Ejer medsendes altid.

• Bopælskommune medsendes altid. Der returneres aktuel bopælskommune og ikke alle

bopælskommuner i søgeperioden.

• Bevillingskommune oplyses for FØP'ere. For FOP'ere medsendes ikke oplysninger om

bevillingskommune (UDK).

• Administrationskommune medsendes kun, hvis personen er under administration.

Administrationskommunen vil ikke altid være det samme som bopælskommunen, da der i forbindelse

med flytninger kan gå noget tid, inden administrationsaftalen flyttes til ny kommune.

Bemærk at ”Rolle” skal være unik, da den benyttes til at adskille de forskellige aktørroller i forhold til sagen.

Der udfyldes 1-2 instanser af ReferenceID. Myndighedskode medsendes altid (mandatory). Hvis

myndighedskoden tilhører en dansk myndighed med registreret CVR-nummer, så medsendes ekstra instans

med CVR-nummeret også.

For pensionister med bopæl i udlandet vil der kun blive sendt myndighedskode i instansen indeholdende

rollen Bopælskommune, og for pensionister med udenlandsk pension vil der kun blive sendt

myndighedskode i instansen indeholdende rollen Bevillingskommune. I interimsperioden vil

myndighedskoden i disse tilfælde være 997.


Rolle URN Fast værdi: "urn:oio:rolle:Ejer"

Type URN Fast værdi: "urn:oio:objekttype:Myndighed"



Indeks string Udfyldes ikke

ReferenceID URN Sagens ejers myndighedskode (=UDK. Medsendes altid) og cvr-nummer (medsendes altid): ”urn:oio:kombit:myndighedkode:nnnn” og "urn:oio:cvr-nr:nnnnnnnn"


Rolle URN Fast værdi: "urn:oio:rolle:Bopælskommune"



ReferenceID URN Bopælskommunens myndighedskode (medsendes altid) og cvr-nummer (medsendes hvis bopæl er registreret i DK): ”urn:oio:kombit:myndighedkode:nnnn” og "urn:oio:cvr-nr:nnnnnnnn"


Rolle URN Fast værdi: "urn:oio:rolle:Bevillingskommune"



ReferenceID URN Bevillingkommunens myndighedskode (medsendes altid) og cvr-nummer (medsendes hvis pension er bevilliget i DK): ”urn:oio:kombit:myndighedkode:nnnn” og "urn:oio:cvr-nr:nnnnnnnn"


Rolle URN Fast værdi: "urn:oio:rolle:Administrationskommune"



ReferenceID URN Administrationskommunens myndighedskode (medsendes altid) og cvr-nummer (medsendes altid): ”urn:oio:kombit:myndighedkode:nnnn” og "urn:oio:cvr-nr:nnnnnnnn"



PSagsklasse indeholder sagens KLE emnenummer og handlingsfacet.

Der udfyldes to instanser af Psagsklasse: KLE emnenummer og KLE handlingsfacet.

• KLE emnenummer medsendes altid for aktuel hovedsag, men ikke for tidligere sager

• KLE handlingsfacet medsendes altid. Handlingsfacet for personens "hovedsag" vil altid være "G01"


Rolle URN Fast værdi: "urn:oio:rolle:PrimaerKlasse"

Type URN Fast værdi: "urn:oio:objekttype:Klasse"


ReferenceID URN Sagens primære KLE emneklasse: "urn:oio:kle:nn.nn.nn" Der udfyldes kun en instans af ReferenceID.


Rolle URN Fast værdi: "urn:oio:rolle:HandlingKlasse"

Type URN Fast værdi: "urn:oio:objekttype:Klasse"


ReferenceID URN Sagens primære KLE handlingsfacet: "urn:oio:klehandling:Xnn" Der udfyldes kun en instans af ReferenceID.



PSagspart indeholder oplysninger om sagens part og eventuelt dennes samlever.

Der angives en instans for parten på sagen (PsagsPart), Pensionisten. Hvis der findes en eller flere

samlevere inden for søgeperioden, returneres der en instans for hver af disse.

Primær part (Pensionisten)


Rolle URN Fast værdi: "urn:oio:rolle:PrimaerPart" (For element se Psagsaktoer ovenfor)

Type URN Fast værdi: "urn:oio:objekttype:Person" (For element se Psagsaktoer ovenfor)


ReferenceID URN Pensionistens CPR-nr: "urn:oio:cpr-nr:nnnnnnnnnn"



Der udfyldes kun en instans af ReferenceID.

SamlivsStatus string+ string

Returneres, hvis der er en konkluderet samlivstype på pensionisten. Udfyldes med en af følgende (Kode, Tekst):

- ”ErkEnlig”, ”Erklæret enlig” - ”AdskGift”, ”Gift faktisk adskilt” - ”PlejeGift”, ”Gift faktisk adskilt pga. plejehjem” - ”Enke”, ”Enke, enkemand” - ”Gift”, ”Gift” - "O-Samlev", "O-Samlevende" - "S-Samlev", "S-Samlevende" - "Z-Samlev", "Z-Samlevende"

Se mapning til tidligere samlivskoder i tabel nedenfor og i [Map]. UDK sender i denne version af servicen Samlivsstatus koder, som umiddelbart kan oversættes til de statuskoder, der i version 2.2 udstillet af KMD Social Pension. I en forventet version 4 af integrationen forventes der en ny angivelse af samliv.

PensionistType:Virkning complexType OBS! Virkningsperioden for pensionstypen er den periode, hvor pensionisten er berettiget til den pågældende type pension. Dvs. Virkning.FraTidspunkt vil være første dag, hvor borgeren er berettiget til den pågældende pensionstype (svarende til den tidligere BevillingDato).

Pensionist Gruppe

string+ string

Udfyldes med en af følgende (Kode, Tekst): - ”FOP”,”Folkepension” - ”Opsat”,”Opsat folkepension” - ”FTPG”,”Gl. førtidspension” - ”FTP”,”Ny førtidspension (fra 2003 og frem)”

Der returneres alle perioder indenfor søgeperioden. Virkningsperioder er alle bevillingsperioder for hovedydelsen på en FØP-sag, en IY-sag eller en FOP-sag, samt perioder med udskudt pension. For FOP-sager kan virkningsperioden yderligere være opdelt efter bevillingsperioder for invaliditetsbeløb, førtidsbeløb eller erhvervsudygtighedsbeløb.

PensionsType string+ string

Udfyldes med en af følgende (Kode, Tekst): - ”IY”,”Invaliditetsydelse” - ”FTPM”,”Mellemste FØP” - ”FTPH”,”Højeste FØP” - ”FTPF”,”Forhøjet alm. FØP” - ”FTPA”,”Almindelig FØP” - ”FTP2003”,”Førtidspension 2003” - ”FPFT”,”Folkepension med førtidsbeløb” - ”FPIN”,”Folkepension med invaliditetsbeløb” - ”FPIE”,”Folkepension m inv. + erhv.u. beløb” - ”FPA”,”Folkepension, alm.”



- ”FPIT”,”Folkepension m invaliditetstillæg” - ”FPOP”,”Folkepension, opsat” - ”Ingen”,”Ingen pension”

Der returneres alle perioder indenfor søgeperioden. Virkningsperioder er alle bevillingsperioder for hovedydelsen på en FØP-sag, en IY-sag eller en FOP-sag, samt perioder med udskudt pension. For FOP-sager kan virkningsperioden yderligere være opdelt efter bevillingsperioder for invaliditetsbeløb, førtidsbeløb eller erhvervsudygtighedsbeløb.

TilkendelsesDato dateTime Den dato pensionstypen er tilkendt. For FØP-pensionstyper vil det være datoen, hvor kommunen har tilkendt den pågældende FØP-type. For FOP-pensionstyper vil det være den dato, hvor Folkepension er bevilget i UDKPE.

FormueDel (Personlig Formue)

Gruppe Udfyldes ikke

FormueType string Udfyldes ikke.

FormueBeloeb Heltal/ Komma decimal evt. med fortegn

Udfyldes ikke

Sekundær part (samlever)


Rolle URN Fast værdi: "urn:oio:rolle:SekundaerPart" (For element se Psagsaktoer ovenfor)

Type URN Fast værdi: "urn:oio:objekttype:Person" (For element se Psagsaktoer ovenfor)


ReferenceID URN Pensionistens CPR-nr: "urn:oio:cpr-nr:nnnnnnnnnn" Der udfyldes kun en instans af ReferenceID.

SamlivsStatus string+ string

Udfyldes ikke

Pensionist Gruppe

string+ string

Udfyldes ikke

PensionsType string+ string

Udfyldes ikke

FormueDel (Personlig Formue)

Gruppe Udfyldes ikke

FormueType string Udfyldes ikke.

Beloeb Heltal/ Komma decimal evt. med fortegn

Udfyldes ikke



UDK PE sender koder for samlivsstruktur (se kolonnen ’8.1 (samliv)’ i tabellen), som umiddelbart kan

oversættes til de statuskoder, der benyttes i KMD Social Pension i SF1411_A (se kolonnen ’KMD Social

Pension’ i tabellen). Der benyttes dog en anden mapning i UDK PE. Det betyder at UDK PE sender i den

eksisterende samlivsstatusstruktur, men på en måde, så den kan rumme den nye beregningsstatus, som

benyttes i UDK PE (se kolonnen ’UDK Pension (Pensionsberegningsstatus, civilstand, institution)’ i tabellen)

[Map]:

Overblik over hvad UDK foreslår der leveres

UDK Pension (Pensionsberegningsstatus, civilstand, institution)

KMD Social Pension 8.1 (samliv)

O-Samlevende (O-Samlevende, n/a, n/a) Overgangsordning - før 26.4.1990 (O) O-Samlev

S-Samlevende (S-Samlevende, n/a, n/a) Overgangsordning - før 01.03.1999 (S) S-Samlev

Samlevende (Samlevende, ugift, n/a) Samlevende efter 01.03.1999 Z-samlev

Samlevende (Samlevende, enke-enkemand, n/a) Samlevende efter 01.03.1999 Z-samlev

Samlevende (Samlevende, fraskilt, n/a) Samlevende efter 01.03.1999 Z-samlev

Enlig (Enlig, ugift, n/a) Erklæret enlig ErkEnlig

Enlig (Enlig, fraskilt, n/a) Erklæret enlig ErkEnlig

Enlig (Enlig, gift, ja) Gift faktisk adskilt pga. plejehjem PlejeGift

Enlig (Enlig, gift, nej) Gift faktisk adskilt AdskGift

Samlevende (Samlevende, gift, n/a) Gift/registreret partnerskab Gift

Enlig (Enlig, enke/enkemand, n/a) Enke/enkemand reelt enlig Enke

UDK vil ikke levere disse værdier (KMD SOP) men dem i 8.1

KMD Social Pension 8.1 (samliv)

Enke/enkemand efter ægteskab, modtager efterlevelsespension Enke

Enke/enkemand efter samliv (Z), modtager efterlevelsespension Enke

Enke/enkemand efter samliv (S), modtager efterlevelsespension Enke

Enke/enkemand efter samliv (O), modtager efterlevelsespension Enke

Separeret – reelt enlig AdskGift

Fraskilt - reelt enlig ErkEnlig

OBS! Pensionister, som bruger de nuværende koder fra KMD SP vil ifm. ibrugtagningen af UDK PE, vil fortsat

bruge disse. Det er altså kun ved nye pensionister eller ændringer til eksisterende, den nye angivelse vil

blive brugt.

3.1.3.3 Sikkerhed

Servicen skal udstilles som en fælleskommunal service, der benytter det fælleskommunale støttesystem

Adgangsstyring til at autentificere og autorisere, som defineret i RA STS [STS-Sikkerhed]. Servicen skal

understøtte en dual sikkerhedsmodel med både token og certifikat (VOCES/FOCES).



Se relation mellem valg af sikkerhedsmodel og krav til udfyldelse af HovedOplysninger som beskrevet i

afsnit 2.2 Kaldskontekst for rollen ”Kalder” (og ”anvender”) i dokumentet [Hovedoplysninger]. Der henvises

i øvrigt til de generelle regler for brug af Serviceplatformen [STS-Sikkerhed].

Det kan være relevant for sagen at lave opslag på borgere, der bor i en anden kommune end den, der ejer

pensionssagen. Det er det kommunale fagsystems ansvar at sikre, at en myndighed kun kan forespørge på

borgere, der indgår i myndighedens egne sager.

3.1.3.4 Leverancesikkerhed og fejlhåndtering

Såfremt endpointet er utilgængelig, er det fagsystemets ansvar at gentage kaldet.

I retursvaret vil der indgå en HovedOplysningerSvar-struktur og en HeaderResponseStructure, som begge

indeholder oplysninger om eventuelle fejl.

HovedOplysningerSvar er den generelle svarstruktur for Serviceplatformen. Strukturen indeholder både fejl

registeret af UDK PE og af Serviceplatformen (f.eks. ifm. timeout hos UDK PE eller teknisk validering på

Serviceplatformen). Fejl registeret og sendt af Serviceplatformen er beskrevet i servicebeskrivelsen på

Serviceplatformen.dk.

Håndteringen af fejlsituationer angivet i HovedOplysningerSvar, hos både Kalder, Mediator

(Serviceplatform) og Udstiller, er beskrevet generelt i dokumentet [Hovedoplysninger]. Denne integration

er af typen ”synkront kald”. Fagsystemet skal bl.a. forholde sig som beskrevet i afsnit 2.3 Fejlhåndtering for

rollen ”Kalder” i dokumentet [Hovedoplysninger].

HeaderResponseStructure er en specifik svarstruktur for denne service. Strukturen indeholder kun fejl

registreret af UDK PE.

Forretningsmæssige fejl registreret af UDK PE sendes i begge strukturer. Beskrivelsen af fejl i de to

strukturer er angivet i tabellerne nedenfor. Det er op til fagsystemet, hvordan denne redundans håndteres.

Følgende fejl afsendt af UDK PE indgår i HovedOplysningerSvar:SvarReaktion:

SvarReaktion type Id Tekst

Advis 100 OK. Ingen sag fundet

Fejl 201 Valideringsfejl: EndDate er mindre end StartDate.

Fejl 204 Personnummer er ikke udfyldt.

Fejl 251 Forespørgende kommune er ukendt

Fejl 900 Teknisk fejl

Følgende fejl afsendt af UDK PE indgår i HeaderResponseStructure:ReturnMessage:

ResponseReturnIdentifier ResponseReasonIdentifier ResponseReasonText

0 0 Ok. Data returneres



100 100 OK. Ingen sag fundet

200 201 Valideringsfejl: EndDate er mindre end StartDate.

200 204 Personnummer er ikke udfyldt.

200 251 Forespørgende kommune er ukendt

900 900 Teknisk fejl.

3.1.3.5 Servicemål

Følgende underafsnit indeholder oplysninger vedrørende servicemål for aftalt driftstid.

3.1.3.5.1 Aftalt driftstid

Parameter Værdi

Tidsrum Serviceplatformen driftsafvikles hele døgnet alle dage bortset fra når der udføres ændringer/hvor der er servicevinduer.

Svartid Serviceplatformen har forskellig SLA på svartid alt efter hvilken integrationskompleksitet, der er tale om: Simpel = 1 sekund Mellem = 1,5 sekund Kompleks = 4 sekunder

Tilgængelighed Servicemålene for Serviceplatformen driftseffektivitet er 99,8% for perioden 06:00 -18:00 på arbejdsdage samt 98,5 % i den øvrige tid.

Spidsbelastningsperiode Spidsbelastningen for Serviceplatformen må antages at være i perioden 06:00 -18:00 på arbejdsdage.

Servicevinduer Ved mindre opdateringer for Serviceplatformen: En gang om ugen i tidsrummet 05:00 -06:00. Varsling: 1. uge, varighed (naturligvis) max en time. Ved større og kritiske opdateringer: Optil 1 gang om måneden i tidsrummet mandag kl. 03:00 til mandag kl. 06:00. Varsling: 1. uge, Varighed: max 3 timer Ved omlægning af miljøer, arkitektur og services for Serviceplatformen: 1 gang pr. kvartal i tidrummet søndag kl. 22:00 til mandag kl. 06:00. Varsling 1. måned, varighed max 8 timer.

3.2 Specifikation af endpoints for UDK Pension

Snitfladen benyttes til at udstille informationer om social pension for en given person via et online opslag.

Opslaget foretages af Serviceplatformen på vegne af det forespørgende system.

3.2.1 Overordnet forretningslogik

Serviceplatformen kalder pensionssystemet, som udstiller en synkron service, der udstiller informationer

om social pension for en given person:

1. Serviceplatformen kalder EP_UDK1

2. Pensionssystemet returnerer et synkront svar til Serviceplatformen



3.2.2 Oversigt over endpoints

ID Navn Reference til wsdl

EP_UDK1 SocialPensionHentUDK [WSDL-EXT]\ Servicenavn: SocialPensionHentService Operationsnavn: SocialPensionHent

3.2.3 Beskrivelse af endpoint EP_UDK1 – SocialPensionHentUDK

3.2.3.1 Transportspecifikation

3.2.3.1.1 Integrationsmønster

Serviceplatformen kalder UDK Pension via Web Service snitflade.

3.2.3.1.2 Serviceudstiller

UDK Pension er serviceudstiller.

3.2.3.1.3 Serviceanvender

Serviceplatformen er serviceanvender.

3.2.3.1.4 Teknologisk understøttelse

Servicen er implementeret som en SOAP 1.1 web service snitflade og benytter http via en krypteret kanal.

3.2.3.1.5 Teknisk endpoint

Oplysninger om endpoint er angivet i tabellen i afsnit Fejl! Henvisningskilde ikke fundet..

3.2.3.1.6 Teknisk retning for udveksling

Serviceplatformen foretager en forespørgsel mod UDK Pension.

3.2.3.1.7 Dataretning for udveksling

UDK Pension udleverer oplysninger om social pension for en given person.

3.2.3.1.8 Service invokation / Triggers

Endpoint kaldes af fagsystemet i forbindelse med udregning af helbredsprocent.

3.2.3.2 Dataspecifikation

Der henvises til afsnit Fejl! Henvisningskilde ikke fundet. for yderligere information om indholdet i d

ataelementer.

Valideringer fremgår af ovennævnte dokument og/eller WSDL defineret i afsnit Fejl! Henvisningskilde ikke f

undet..



3.2.3.3 Sikkerhed

Servicen skal udstilles som en fælleskommunal service, der benytter det fælleskommunale støttesystem

Adgangsstyring til at autentificere og autorisere, som defineret i [STS-Sikkerhed].

3.2.3.4 Leverancesikkerhed og fejlhåndtering

Status- og fejlkoder afsendt af UDK PE er beskrevet i afsnit Fejl! Henvisningskilde ikke fundet..

Håndteringen af fejlsituationer angivet i HovedOplysningerSvar, hos både Kalder (fagsystemet), Mediator

(Serviceplatform) og Udstiller (UDK PE), er beskrevet generelt i dokumentet [Hovedoplysninger]. Denne

integration er af typen ”synkront kald”. UDK PE skal bl.a. forholde sig som beskrevet i afsnit 2.3

Fejlhåndtering for rollen ”Udstiller” i dokumentet [Hovedoplysninger].

I tilfælde af fejl / timeout i kommunikationen UDK Pension vil Serviceplatformen informere det kaldende

fagsystem med angivelse af fejlen.

Da der er tale om en forespørgsel, der kan kaldes gentagne gange for samme person, vil fagsystemet selv

være ansvarlig for at kalde igen.

3.2.3.5 Servicemål

Følgende underafsnit indeholder oplysninger vedrørende servicemål for aftalt driftstid.

3.2.3.5.1 Aftalt driftstid

Parameter Værdi

Tidsrum UDKPE driftsafvikles hele døgnet alle dage bortset fra ved planlagte servicevinduer.

Svartid UDKPE har målsat intern procestid på 1 sek. og maksimum 2 sek. Dertil kommer den tid, der anvendes af eksterne systemer, i transportlaget, etc.

Tilgængelighed Servicemålet for UDKPE’s tilgængelighed er 98,5 % inden for planlagt oppetid.

Spidsbelastningsperiode UDKPE’s forskellige moduler vil have forskellige spidsbelastningsperioder, så der kan ikke siges noget generelt.

Servicevinduer Servicevinduer for UDKPE udmeldes efter behov. De placeres udenfor Kritisk forretningstid, som er arbejdsdage fra kl. 06.00 til 22.00.



4 Beskrivelse for integrationsplatforme

4.1 Beskrivelse for Serviceplatformen

Nærværende afsnit angiver den integrationsfunktionalitet, som Serviceplatformen håndterer i

interaktionen mellem integrationsparter.

En integration kan understøttes af flere integrationsflow, som vil være beskrevet hver for sig i nærværende

afsnit. I hvert integrationsflow vil der indgå en række endpoints. Hvert endpoint vil være specificeret i

integrationsbeskrivelserne for integrationsparterne, jf. ovenstående afsnit Fejl! Henvisningskilde ikke f

undet..

Jf. figuren nedenfor indgår følgende komponenter og endpoints i integrationen.

IF01 Hent information om social pension

UDK Pension Fagsystem(n)EP_FS1

EP_UDK1

Serviceplatformen

4.1.1 Oversigt over integrationsflows

ID Navn

IF01 Hent information om social pension

4.1.2 Integrationsflow IF01: Hent information om social pension

4.1.2.1 Anvendte service endpoints

Endpoint ID Navn på endpoint Dokument-reference

EP_FS1 SocialPensionHent Fejl! Henvisningskilde ikke fundet.

EP_UDK1 SocialPensionHentUDK Fejl! Henvisningskilde ikke fundet.

4.1.2.2 Integrationstype

Integrationen er en gennemstillingsintegration.



4.1.2.3 Diagram over integrationsflowet

Jf. figuren nedenfor indgår følgende integrationsflows i integrationen.

Fagsystem(n) Serviceplatformen UDK Pension

EP_UDK1

Sekvens:

1. Fagsystemet kalder Mediator (Serviceplatformen/SP) med søgeparametre (synkront kald)

2. SP validerer skemaet og returnerer eventuel valideringsfejl til Kalder (se punkt 6.)

3. SP viderestiller kald med søgeparametre til UDK PE (synkront kald)

4. UDK PE returnerer synkront svar på forespørgslen til SP i servicekaldets returparameter

5. SP viderestiller svaret til fagsystemet. I tilfælde af timeout, genererer SP retursvaret

6. SP returnerer svaret til Kalder i servicekaldets returparameter

Serviceplatformen skal håndtere kaldet som angivet for rollen ”Mediator” i [Hovedoplysninger].

4.1.2.4 Datatransformering

N/A

4.1.2.5 Datapersistering

Ingen krav til payload, men TransaktionsId og TransaktionsTid fra kaldets HovedOplysninger og svarets

HovedOplysningerSvar persisteres i SP, så kald og svar kan matches.

4.1.2.6 Databerigelse

N/A

4.1.2.7 Routing

N/A



4.1.2.8 Orkestrering

N/A

4.1.2.9 Sikkerhed

Kildesystemet er token baseret. Fagsystemet kan enten være token baseret eller certifikat baseret.

EP_FS1 er udstillet som en fælleskommunal service med dual sikkerhedsmodel med både token og

certifikat (AuthorityContext) .

EP_UDK1 autentificeres og autoriseres via token.

Jf. [STS-sikkerhed].

4.1.2.10 Logning

Ingen ekstrakrav til logning ud over de generelle logningskrav på Serviceplatformen.

4.1.2.11 Testdata og testfaciliteter

N/A

4.1.2.12 Konfiguration

N/A

4.1.2.13 Supplerende information

Der skal ikke udføres forretningsvalidering på Serviceplatformen.

4.1.3 Tilslutning til integrationspart: Serviceplatformen

Dette kapitel liste de forudsætninger, som skal være opfyldt for at Serviceplatformen kan udstille den

pågældende snitflade.



Kommentar

TSP02 Registrering af UDK Pension og udstillede services i STS Organisation

Konfigura-tion

STS Organisation

KDI KDI Fase 1

Kan udføres samme SF1411_B TSP01

TSP04 Registrering af Serviceinformation for services udstillet af UDK Pension i Serviceplatformen

Konfigura-tion

Serviceplatformen

KDI KDI Fase 1




TSP06 Registrering af UDK Pension og udstillede services i Administra-tionsmodul

Konfigura-tion


KDI KDI Fase 1


TSP02 - UDK Pension skal oprettes STS Organisation, hvis dette ikke allerede er sket, med de services, som udstilles af denne, og som er beskrevet i denne Snitflade.

TSP04 - Der skal registres information vedrørende UDK Pension services i Serviceplatformen, så der kan oprettes serviceaftaler for kommunerne, bl.a. skal logiske og fysiske endpoint skal være relateret.

TSP06 - UDK Pension skal oprettes STS Administrationsmodul, hvis dette ikke allerede er sket, med de services, som udstilles af denne, og som er beskrevet i denne snitflade.

Documents

Integration 1411 A V3 Hent informationer om social pension - Hent... · Integration 1411_A_V3 Hent informationer om social pension Integrationsbeskrivelse - version 3.2.1 Kommunernes